Betrouwbare LLM API-routing: time-outs, nieuwe pogingen en modelfallbacks zonder semantische regressies

Een terugvalverzoek is niet succesvol louter omdat een ander model HTTP 200 heeft geretourneerd. De vervanging kan het oorspronkelijke latentiebudget overschrijden, de vereiste JSON velden weglaten, een ander hulpprogramma aanroepen of een antwoord opleveren met een wezenlijk andere semantiek. Betrouwbare LLM API-routering vereist daarom meer dan een geordende lijst met modellen: er is een contract, een foutclassificator, een beleid voor begrensde pogingen en validatie vóór acceptatie nodig.

De centrale regel is simpel: probeer het alleen opnieuw als de fout plausibel tijdelijk is, en val alleen terug als de volgende route nog steeds aan het oorspronkelijke aanvraagcontract kan voldoen.

Definieer het routeringscontract voordat u modellen kiest

Begin met te beschrijven wat een succesvol antwoord moet opleveren. Dit routeringscontract moet machinaal leesbaar zijn en aan elke werklast of verzoekklasse worden gekoppeld.

{
  "workload": "invoice_extraction",
  "modalities": ["text", "image"],
  "max_input_tokens": 50000,
  "requires_tools": false,
  "structured_output": {
    "required": true,
    "schema_id": "invoice-v3",
    "strict": true
  },
  "allowed_model_classes": ["document-extraction"],
  "max_cost_usd": 0.08,
  "deadline_ms": 8000
}

Het contract moet de vereiste modaliteiten, contextcapaciteit, toolondersteuning, gestructureerd uitvoergedrag, acceptabele modelklassen, maximale kosten en de end-to-end deadline omvatten. Voeg waar nodig applicatiespecifieke beperkingen toe, zoals toegestane regio's, minimale uitvoerlengte of een vereiste eindreden.

Aanbeveling: onderhoud afzonderlijke, geteste routegroepen voor platte tekst, schema-beperkte uitvoer, toolgebruik, visie en verzoeken met lange context. Een model dat een acceptabele tekstfallback is, is niet automatisch een acceptabele fallback voor het aanroepen van tools of beeldinvoer.

Classificeer de fout voordat u actie onderneemt

Authenticatiefouten, verkeerd ingedeelde verzoeken, snelheidslimieten en serverstoringen vereisen verschillende reacties. Als u elke niet-succesvolle reactie behandelt als een hernieuwbare reactie, verspilt u capaciteit en kunt u defecten verbergen.

Feit: niet-succesvolle verzoeken met een tariefbeperking kunnen nog steeds meetellen voor de providerlimieten. Agressieve onmiddellijke nieuwe pogingen kunnen de beperking daarom verdiepen in plaats van oplossen. Nieuwe pogingen verbruiken ook extra capaciteit tijdens een storing, en het beleid voor nieuwe pogingen op verschillende applicatielagen kan de resulterende belasting vermenigvuldigen.

Aanbeveling: laat één laag eigen pogingen doen om modellen te genereren. In een typische architectuur is de AI API-gateway de juiste eigenaar, omdat deze de routestatus, de geschiedenis van pogingen, de latentie en de kosten ziet. Schakel waar mogelijk automatische nieuwe pogingen uit bij clients op een lager niveau, of tel ze expliciet mee in hetzelfde pogingsbudget.

Besteed één end-to-end latentiebudget

Time-outs per poging zijn onvoldoende. Drie pogingen met een time-out van vijf seconden kunnen een beoogde bewerking van vijf seconden omzetten in een reactie van vijftien seconden, voordat uitstel en validatie zijn inbegrepen.

Regel een absolute deadline wanneer het verzoek de gateway binnenkomt. Bereken vóór elke poging de resterende tijd:

remaining = deadline - current_time
required  = connect_allowance + generation_allowance + validation_allowance

if remaining < required:
    stop_without_launching_another_attempt

Voor een deadline van acht seconden kan een redelijke initiële toewijzing 300 ms reserveren voor gatewaywerk en uiteindelijke validatie, tot 4,5 seconden toestaan voor de primaire route en ongeveer 3,2 seconden vasthouden voor één fallback. Deze waarden zijn een voorbeeld en geen benchmark. Ze moeten worden afgeleid van gemeten latentieverdelingen voor de daadwerkelijke providers, modellen, regio's en uitvoergroottes.

Gebruik een beperkte exponentiële uitstel met jitter voor tijdelijke nieuwe pogingen:

delay = random(0, min(cap, base * 2^retry_index))

Hints voor nieuwe pogingen van de aanbieder, zoals een 'retry-after'-waarde, moeten voorrang krijgen als ze binnen de resterende deadline vallen. Stop na een klein aantal pogingen. Een algemeen beleid is één primaire poging plus één fallback, met een optionele nieuwe poging via dezelfde route alleen voor een vroege verbindingsfout die geen factureerbare uitvoer had kunnen genereren.

Trade-off: sequentiële terugval verbetert de beschikbaarheid, maar verhoogt de staartlatentie. Parallelle of afgedekte verzoeken kunnen de latentie tijdens vertragingen verminderen, maar ze verbruiken meer capaciteit en kunnen kosten met zich meebrengen voor meerdere succesvolle generaties. Het afdekken moet worden beperkt tot latentiekritische productietaken zonder bijwerkingen, met annulerings- en kostenbeheersing.

Selecteer fallbacks op basis van capaciteit, niet op rang

Een reservetabel moet compatibiliteit coderen in plaats van een globale voorkeursvolgorde. Filter kandidaatroutes op basis van het contract voordat u rekening houdt met de status, latentie of prijs.

candidates = routes
  .filter(supports_required_modalities)
  .filter(context_limit >= estimated_input_size)
  .filter(supports_required_tools)
  .filter(supports_requested_schema_mode)
  .filter(model_class in allowed_model_classes)
  .filter(estimated_cost <= remaining_cost_budget)
  .filter(not_temporarily_suppressed)

selected = rank(candidates, health, latency, cost)

Ondersteuning voor gestructureerde uitvoer verdient expliciete tests. Zelfs als twee routes schema-beperkte generatie adverteren, kunnen ze verschillende JSON Schema-subsets ondersteunen of randgevallen anders interpreteren. Modellen die geschikt zijn voor tools kunnen eveneens verschillen wat betreft toolselectie, argumentconstructie en parallelle aanroepgedrag.

Feit: het wisselen van modelfamilies kan de transportbeschikbaarheid behouden, terwijl de stijl, redeneerkwaliteit, veiligheidsgedrag, tokenisatie en gereedschapsselectie veranderen. HTTP succes is geen bewijs van semantische gelijkwaardigheid.

Voorspelling: Naarmate modelcatalogi zich uitbreiden, zal het beleid voor productierouting steeds vaker gebruik maken van versiebeheerprofielen en werklastspecifieke acceptatietests in plaats van statische modellijsten. Beschouw dit als een ontwerprichting, en niet als een garantie voor het gedrag van de provider.

Valideer het antwoord voordat u het accepteert

Voer elk antwoord, inclusief het primaire antwoord, door dezelfde acceptatiepijplijn. Validatie moet plaatsvinden voordat het resultaat in de cache wordt opgeslagen, intern als succesvol wordt gefactureerd of wordt doorgegeven aan een tool-uitvoerder.

1. Bevestig dat het transport is voltooid en dat de antwoordenvelop kan worden geparseerd.
2. Controleer de reden van voltooiing en wijs afkapping af wanneer volledige uitvoer vereist is.
3. Valideer gestructureerde uitvoer aan de hand van het oorspronkelijke schema.
4. Verifieer de vereiste velden, opsommingswaarden en applicatie-invarianten.
5. Sta alleen geregistreerde toolnamen toe en valideer argumenten tegen elk toolschema.
6. Pas werklastspecifieke semantische controles toe waar valse acceptatie kostbaar zou zijn.

Voor factuurextractie kunnen semantische controles een niet-negatief totaal, een ondersteunde valutacode en regelitemtotalen vereisen binnen een expliciet gedefinieerde tolerantie. Voor classificatie is een label uit de toegestane set vereist. Voor het genereren van code kan parseren of compileren geschikt zijn. Deze controles bewijzen geen kwaliteit, maar voorkomen dat voorspelbare contractschendingen als succes worden beschouwd.

Repareer niet stilletjes elk verkeerd geformuleerd antwoord. Deterministische normalisatie, zoals het verwijderen van onschadelijke omringende witruimte, kan acceptabel zijn. Het raden van ontbrekende financiële velden of het herschrijven van toolargumenten verandert de betekenis van het model en zou tot afwijzing of menselijke beoordeling moeten leiden.

Gescheiden generatiepogingen van bijwerkingen

LLM-verzoeken maken doorgaans gebruik van HTTP POST, wat niet inherent idempotent is. Belangrijker nog is dat een modelreactie een externe actie kan initiëren, zoals het in rekening brengen van een betaalmethode, het verzenden van een bericht, het aanmaken van een ticket of het aanpassen van de infrastructuur. Het opnieuw proberen te genereren en de actie opnieuw af te spelen zijn afzonderlijke beslissingen.

Wijs een bewerkings-ID toe aan de applicatiegrens en een poging-ID aan elke modelaanroep. Houd de uitvoeringsstatus van het gereedschap aan tegen een deterministische sleutel, zoals:

execution_key = operation_id + tool_name + canonical_arguments_hash

Controleer voordat u een tool uitvoert of die sleutel in behandeling is, voltooid of mislukt is. Retourneer het opgeslagen resultaat voor een voltooide uitvoering in plaats van het opnieuw uit te voeren. Voor bewerkingen waarvan de argumenten legitiem kunnen veranderen, is goedkeuring op applicatieniveau of een nieuwe bewerkings-ID vereist.

Een dubbelzinnige time-out vereist speciale afhandeling. Als de verbinding mislukt nadat een verzoek is verzonden, weet de gateway mogelijk niet of er sprake is van generatie. Een door de provider ondersteunde idempotentiesleutel kan helpen, indien beschikbaar. Anders registreert u de uitkomst als onbekend en past u een werklastspecifiek herhalingsbeleid toe in plaats van aan te nemen dat er niets is gebeurd.

Onderdruk ongezonde routes en maak elke poging openbaar

Een stroomonderbreker of tijdelijke onderdrukking van de status voorkomt dat elk nieuw verzoek dezelfde falende route opnieuw ontdekt. Open het circuit na een gedefinieerde foutfrequentie of drempel voor opeenvolgende storingen en laat vervolgens beperkte sondes toe in een halfopen toestand. Stem de drempelwaarden af op route en foutklasse, zodat een onjuist opgemaakt clientverzoek er niet voor kan zorgen dat een gezond model niet beschikbaar lijkt.

Neem één gebeurtenis op verzoekniveau en één gebeurtenis per poging op. Nuttige velden zijn onder meer bewerkings-ID, poging-ID, geselecteerde provider en model, foutklasse, statuscode, latentie, tokenaantallen, geschatte kosten, terugvalreden, validatieresultaat, circuitstatus en uiteindelijke uitkomst. Bewerk of hash prompts, uitvoer en toolargumenten op basis van hun gevoeligheid en bewaarvereisten.

Nuttige operationele statistieken zijn onder meer het terugvalpercentage, het aantal pogingen per voltooid verzoek, het uitputtingspercentage van de deadline, het percentage afgewezen validaties, dubbelzinnige resultaten, de kosten per geaccepteerde reactie en de latentie per uiteindelijke route. Een stijgend succespercentage HTTP naast een stijgend percentage afwijzingen van validaties is een waarschuwing dat de beschikbaarheid van transport contractmislukkingen maskeert.

Checklist voor productie-uitrol

• Definieer een routeringscontract met versiebeheer voor elke werklastklasse.
• Breng providerfouten in permanente, tijdelijke, incompatibele, ongeldige respons- en dubbelzinnige categorieën in.
• Kies één eigenaar voor een nieuwe poging en beperk het totale aantal pogingen.
• Propageer een absolute deadline via gateway, providerclient, validatie en uitvoering van de tool.
• Bouw op mogelijkheden geteste reservegroepen in plaats van één globale modelketen.
• Valideer schema's, toolaanroepen, eindredenen en domeininvarianten.
• Dedupliceer bijwerkingen met bedienings- en uitvoeringssleutels.
• Voeg routeonderdrukking toe met begrensde halfopen onderzoeken.
• Log de latentie, tokens, kosten, mislukkingen en acceptatieresultaten op pogingsniveau.
• Time-outs voor injecteren, 429s, geselecteerde 5xx-fouten, onjuiste indeling JSON, contextoverloop en langzame successen in de fasering.

Begin met een primaire route en één compatibele fallback voor één enkele werklast met laag risico. Vergelijk de kwaliteit, latentie en kosten van geaccepteerde reacties voordat u het beleid uitbreidt. Het doel is niet het hoogst mogelijke terugvalpercentage. Het is een begrensd systeem dat ofwel een antwoord retourneert dat voldoet aan het oorspronkelijke contract, ofwel duidelijk faalt voordat het dubbel werk of semantische schade veroorzaakt.

Gerelateerd lezen

• eerdere API testopmerking
• vorig Engelstalig artikel