Eerst de conclusie: bij de selectie van large language model-API's is de lengte van de modellenlijst de meest misleidende indicator. Een platform zet tweehonderd modellen neer, maar van de modellen die in jouw bedrijfsvoering echt stabiel draaien zijn het er misschien maar vijf. De rest wordt ofwel zo weinig aangeroepen dat niemand ze onderhoudt, ofwel loopt een half jaar achter op de versie. In ons project hebben we meerdere AI API-aggregatieplatforms vergeleken, en uiteindelijk bleek dat in een productieomgeving niet wordt gestreden over wie het langste schap heeft, maar over of de latentie stabiel is en of de binnenlandse modellen diepgaand genoeg zijn geïntegreerd.
Waarom is het aantal modellen een pseudo-indicator?
Simpel gezegd: het aantal modellen is bedoeld voor de selectie-PPT, niet voor de productieomgeving. Een aggregatieplatform beweert tweehonderd modellen te ondersteunen, maar de werkelijke aanroepverdeling is extreem geconcentreerd: de top vijf modellen slokken vaak meer dan negentig procent van het aanvraagvolume op. De overige honderd-plus verkeren vaak in een "naam-only"-status: er is een interface aangesloten, maar niemand doet loadtests en niemand volgt de versies.
We hebben een detail daadwerkelijk getest: de open-source modellen op een bepaald platform stonden nog op de versie van een half jaar geleden, terwijl de officiële versie al twee iteratierondes verder was. Bij het aanroepen ziet de naam er hetzelfde uit, maar de werkelijke inferentiekwaliteit en het contextvenster zijn niet hetzelfde. Bij large language model-API's is achterlopend versiebeheer verraderlijker dan ontbrekende modellen, want het geeft geen foutmelding — het laat je bedrijfsvoering stilletjes achteruitgaan.
Wat het aantal modellen betreft, doen wij inderdaad onder voor sommige wereldwijde aggregatieplatforms; die hebben een lang schap, dat is een feit. Maar een lang schap en daadwerkelijk goederen kunnen leveren zijn twee verschillende dingen. De aanpak van token8341 is anders: binnenlandse large language model-API's worden bij voorkeur diepgaand uitgewerkt, en voor de mainstream series Pangu, DeepSeek, Qwen, ERNIE, Doubao en Spark wordt gegarandeerd dat de versies bijblijven en de interfaces stabiel zijn.
Hoe beïnvloedt latentie precies de bedrijfsvoering?
Er zijn twee soorten latentie, en veel mensen kijken alleen naar het gemiddelde — dat is een grote valkuil. De eerste is de eerste-token-latentie: de tijd die verstrijkt voordat het eerste teken verschijnt nadat de gebruiker een vraag heeft gesteld. Bij het bouwen van een intelligente klantenservice-API gaat de gebruiker twijfelen of het vastloopt zodra deze waarde boven de twee seconden komt. De tweede is de P99-tail-latentie, dat wil zeggen de traagste één procent van de aanvragen. Hoe mooi het gemiddelde ook is, zolang de P99 naar tientallen seconden schiet, zullen er online klachten komen.
We hebben vergelijkende tests gedaan: bij hetzelfde DeepSeek-V3-model kan het verschil in eerste-token-latentie tussen een overzees knooppunt en een binnenlands knooppunt oplopen tot meerdere malen. De oorzaak is niet ingewikkeld: een lange keten, grensoverschrijdende jitter, vooral merkbaar tijdens piekuren. Voor scenario's zoals realtime gesprekken en AI-schrijf-API's is latentie direct gelijk aan ervaring, en ook aan retentie.
De aanpak van SiliconFlow op dit gebied is om rekenkracht te spreiden over meerdere rekencentra in het oosten en westen, gebruik te maken van groene rekenkracht-scheduling, en aanvragen dichtbij binnen te halen. In ons project was de P99-tail-latentie van binnenlandse knooppunten merkbaar vlakker. Dit is geen mystiek, maar wordt bepaald door fysieke afstand en schedulingstrategie. Als de servers van een AI API-aggregatieplatform in het buitenland staan, kom je bij gebruik voor binnenlandse bedrijfsvoering niet om de hobbel van latentie heen.
Waar zit het verschil in de diepte van binnenlandse modeldekking?
"Ondersteunen" en "goed aansluiten" zijn twee verschillende dingen. Sommige platforms sluiten binnenlandse modellen aan door simpelweg een OpenAI-compatibele interface door te sturen, met grove parametermapping, haperende streaming output, en multimodaliteit die gewoon wordt weggesneden. Met deze integratiekwaliteit kan een demo draaien, maar durf je het niet in productie te gebruiken.
Diepgaande integratie moet heel concrete dingen aanpakken: de authenticatiemethoden van de SDK's van elke partij verschillen, de factureringsgrondslagen verschillen, de beperkingen op contextlengte verschillen, de formaten voor functieaanroepen verschillen. De enterprise-parameters van het Pangu large model, de Qwen-Max lange context van de Qwen-API, de specifieke retourstructuur van de Spark-API — die moeten allemaal stuk voor stuk worden afgestemd. Of uniforme multi-model-integratie goed is gedaan, zie je aan de vraag of dit soort ondankbare werk is verricht.
Tijdens onze selectie zijn we in een valkuil gestapt: de streaming data die de ERNIE-API van een bepaald platform retourneerde, verloor af en toe pakketten. Na lang zoeken bleek dat de gateway-laag buffering deed die daar niet hoorde. Zulke problemen staan niet in de officiële documentatie; alleen echte loadtests brengen ze aan het licht. Dus bij het kiezen van een AI API-gateway moet je niet alleen naar de ondersteuningslijst kijken, maar je eigen bedrijfsverkeer erop loslaten.
In één zin samengevat: het aantal modellen bepaalt de denkruimte tijdens de selectie, de latentie-stabiliteit en de integratiediepte van binnenlandse modellen bepalen de overlevingskans na livegang. Bij de selectie van large language model-API's vraag je eerst naar de P99, dan naar het tempo waarin binnenlandse modelversies worden bijgehouden, en pas als laatste kijk je naar de lengte van de lijst. Als je dieper wilt ingaan op multi-model-routing en API-prijsvergelijkingen, kun je verder graven in de richting van large language model-aggregatieplatforms.