Kako dizajnirati zamjenske LLM-ove bez kršenja latencije, troška ili izlaznih ugovora

Rezervni model nije samo rezervni popis modela. Za inženjerske timove koji koriste nekoliko pružatelja LLM-a, zamjena je politika usmjeravanja koja odlučuje kada se zahtjev može premjestiti s jednog pružatelja ili modela na drugi, što mora ostati nepromjenjivo i kako sustav dokazuje da je alternativni put učinio aplikaciju pouzdanijom.

Problem čitača obično je jednostavan: smanjite neuspjele zahtjeve i smanjite latenciju repa bez tihe promjene kvalitete izlaza, valjanosti sheme, sigurnosnog ponašanja ili cijene. Rješenje je konkretnije od "pokušajte s drugim pružateljem". Pouzdana zamjenska strategija LLM-a zahtijeva klasifikaciju pogrešaka, rokove zahtjeva, pravila kompatibilnosti modela, ograničenja troškova, prekidače strujnog kruga i vidljivost na razini davatelja i rute.

Počnite s zamjenskom politikom, a ne s ponovnim kodom

Ponovni pokušaji i zamjena rješavaju različite probleme. Ponovni pokušaj traži od istog pružatelja da dovrši isti zahtjev nakon prolaznog kvara. Zamjenski model traži od drugog modela, pružatelja usluga, regije ili rute da umjesto toga dovrši posao. Kombinacija tih zabrinutosti stvara sustave o kojima je teško razmišljati tijekom incidenata.

Činjenica: Smjernice za pouzdanost pružatelja infrastrukture oblaka obično preporučuju ograničeno eksponencijalno odlaganje, podrhtavanje, maksimalna ograničenja ponovnih pokušaja, provjere idempotencije i izbjegavanje ponovnih pokušaja na više slojeva jer oluje s ponovnim pokušajima mogu pogoršati preopterećenje. Glavni pružatelji LLM-a također dokumentiraju prolazne pogreške, ograničenja stope, odgovore na preopterećenje, isteke vremena i SDK ponašanje ponovnog pokušaja.

Preporuka: implementirajte jedan sloj ponovnog pokušaja za svaki put zahtjeva. Ako aplikacijski pristupnik pokuša ponovno, niže usluge ne bi trebale ponovno pokušati neovisno osim ako vlasništvo ponovnog pokušaja nije eksplicitno. Svaki ponovni pokušaj trebao bi trajati isti rok za pozivatelja, a ne stvarati novo neograničeno vremensko ograničenje.

Minimalna politika trebala bi odgovoriti na ova pitanja prije nego što se napiše bilo kakav kod:

• Koje pogreške se mogu ponovno pokušati na istom pružatelju usluga?
• Koje pogreške dopuštaju vraćanje drugom pružatelju ili model?
• Koji kvarovi nikada ne smiju pokrenuti zamjenu?
• Koji izlazni ugovor mora ostati identičan?
• Koliko je maksimalno dopušteno povećanje troškova?
• Koliko se od roka zahtjeva može potrošiti prije nego što se zamjena onemogući?
• Koja telemetrija dokazuje je li zamjena pomogla ili sakrio nedostatak?

Klasificirajte pogreške prije nego što ih zaobiđete

Zamjena je opasna kada se svaki non-200 odgovor tretira na isti način. Istek pružatelja usluga nije isto što i neispravan zahtjev. Ograničenje brzine nije isto što i sigurnosno odbijanje.Neuspjeh provjere valjanosti izlaza nije isto što i neuspjeh mreže.

Praktična taksonomija trebala bi uključivati barem ove klase:

• Pogreška prijenosa koja se može ponoviti: poništavanje veze, problem s DNS-om, privremena pogreška mreže ili istek vremena pristupnika.
• Preopterećenje davatelja: dokumentirano preopterećenje ili prolaz na strani poslužitelja neuspjeh.
• Ograničenje brzine: zahtjev, token, ubrzanje ili ograničenje tempa kvote, posebno kada je navedena vrijednost Retry-After.
• Istek vremena pružatelja: pružatelj je prihvatio zahtjev, ali nije dovršio unutar svog prozora usluge.
• Nevažeće zahtjev: neispravan korisni teret, nepodržani parametar, nevažeća shema ili opcija nekompatibilna s modelom.
• Pogreška provjere autentičnosti ili konfiguracije: loš ključ, onemogućen račun, nedostaje ovlaštenje ili iscrpljena kvota na razini računa.
• Sigurnosno odbijanje ili blokiranje: pružatelj namjerno odbija ili blokira sadržaj na temelju sigurnosnih pravila.
• Neuspješna provjera valjanosti izlaza: model je odgovorio, ali odgovor ne zadovoljava ugovor o aplikaciji.

Preporuka: pokušajte ponovno samo s prolaznim pogreškama unutar proračuna latencije pozivatelja. Dopustite zamjenu samo za klase pogrešaka koje su timovi proizvoda i platforme izričito odobrili. Nemojte se oslanjati na pogreške provjere autentičnosti, neispravne zahtjeve, pogreške determinističke sheme ili sigurnosna odbijanja osim ako proizvod ne definira određeno alternativno sigurno ponašanje.

Ova je razlika važna jer zamjena inače može sakriti greške. Ako je shema nevažeća za primarnog pružatelja i slučajno je zanemari rezervni pružatelj, sustav se može činiti zdravijim dok vraća manje ograničen izlaz. To nije pouzdanost; to je pomicanje ugovora.

Koristite rokove, a ne samo isteke

Problemi s kašnjenjem repa često dolaze od ponovnih pokušaja koji su tehnički ograničeni, ali praktički presporo. Zahtjev s 15-sekundnim proračunom usmjerenim prema korisniku ne bi trebao potrošiti 14 sekundi na neuspjeh na primarnoj ruti, a zatim započeti potpuni zamjenski pokušaj koji se ne može dovršiti na vrijeme.

Koristite rok za zahtjev koji prolazi kroz cijeli stog. Svaka odluka o usmjeravanju trebala bi provjeriti preostalo vrijeme prije ponovnog pokušaja ili vraćanja. Na primjer:

request_deadline_ms = 6000
primary_attempt_timeout_ms = 3500
retry_backoff_budget_ms = 500
minimum_fallback_budget_ms = 1800

if remaining_deadline_ms < minimum_fallback_budget_ms:
    return controlled_failure

Točne brojke ovise o radnom opterećenju. Ruta završetka chata može rezervirati dovoljno vremena za jedan alternativni model. Posao ekstrakcije u pozadini može dopustiti više pokušaja. Putanja automatskog dovršavanja u stvarnom vremenu može dati prednost brzom kvaru u odnosu na kasni zamjenski odgovor.

Preporuka: definirajte proračune latencije prema klasi rute, a ne globalno. Ruta korisničkog sučelja s malom latencijom, ruta skupne klasifikacije i ruta analize dugog konteksta ne bi trebale dijeliti istu omotnicu za ponovni pokušaj i zamjenu.

Definiranje klasa modela prema radnom opterećenju

Imena dobavljača loša su apstrakcija za zamjenu. Aplikacija brine o svojstvima radnog opterećenja: duljini konteksta, dubini razmišljanja, podršci alata, ponašanju strukturiranog izlaza, latenciji, ograničenjima rukovanja podacima i trošku.Zamjenske rute trebaju biti organizirane oko tih svojstava.

Korisne klase modela uključuju:

• Brzu skicu: kratke odgovore, nisku latenciju, umjerenu toleranciju kvalitete.
• Strukturirano izdvajanje: strogi JSON izlaz, provjeru valjanosti sheme, nisku toleranciju za format drift.
• Obrazloženje: analiza u više koraka, viši zahtjevi za kvalitetom, veća prihvatljiva latencija.
• Dugi kontekst: veliki dokumenti, veliki prozori tokena, pažljiva pravila skraćivanja.
• Jeftina serija: asinkroni ili nehitni poslovi optimizirani za ekonomičnost jedinice.
• Premijum eskalacija: skupi, ali sposobni modeli koji se koriste samo kada pravila to dopuštaju.

Za svaku klasu navedite dopuštene primarne modele, dopuštene zamjenske modele i zabranjene staze za vraćanje na stariju verziju. Zahtjev dugog konteksta ne bi se trebao vratiti na model kratkog konteksta koji tiho skraćuje upit. Zadatak strukturiranog izdvajanja ne bi se trebao vratiti na model koji ne može zadovoljiti ograničenja sheme. Zadatak vrhunskog obrazloženja može dopustiti povratak na drugi premium model, ali ne i na brzi model nacrta osim ako korisničko iskustvo izričito ne podržava degradirani odgovor.

Za timove koji grade poduzeće LLM API, ove bi klase trebale živjeti u podacima o konfiguraciji ili pravilima, a ne razbacane po aplikacijskim uslugama. To održava ponašanje usmjeravanja podložnim reviziji i lakšim za promjenu tijekom incidenata pružatelja usluga.

Zaštitite ugovore strukturiranog izlaza

Zamjena strukturiranog izlaza jedno je od najlakših mjesta za stvaranje suptilnih grešaka u proizvodnji. Dobavljači se razlikuju po tome kako podržavaju JSON način, JSON shemu, pozive alata, polja odbijanja, sigurnosne povratne informacije, razloge završetka i podskupove sheme. Nije zajamčeno da će shema koja radi s jednim modelom biti prenosiva na drugi.

Činjenica: Neka dokumentacija dobavljača opisuje striktno pridržavanje sheme za podržane modele, dok druga dokumentacija navodi podršku samo za podskup JSON sheme. Odgovori pružatelja mogu također uključivati ​​polja odbijanja, brze povratne informacije, sigurnosne ocjene, razloge završetka ili nema kandidata kada je upit blokiran ili nevažeći.

Preporuka: valjanost izlaza smatrajte dijelom rute, a ne izbornim problemom pozivatelja. Gateway bi trebao potvrditi konačni odgovor prije nego što ga vrati aplikaciji. Ako provjera valjanosti ne uspije, ruta bi trebala klasificirati neuspjeh i odlučiti je li dopušten zamjenski pokušaj.

Postoje dva funkcionalna obrasca:

Koristite prijenosni podskup shema

Zadržite sheme na sjecištu značajki podržanih kod odobrenih zamjenskih pružatelja usluga. To poboljšava prenosivost i smanjuje operativnu složenost. Kompromis je u tome što možete izgubiti bogatija ograničenja specifična za pružatelja usluga.

Koristite adaptere sheme specifične za pružatelja usluga

Održavajte adaptere koji prevode ugovor aplikacije u podržani format sheme svakog pružatelja usluge. Ovo čuva sposobnost, ali povećava teret testiranja i održavanja.Također zahtijeva matricu kompatibilnosti kako bi inženjeri znali koje se rute mogu sigurno vratiti.

Osnovni zapis kompatibilnosti može izgledati ovako:

{
  "route": "invoice_extraction_v3",
  "contract": "invoice_json_schema_v3",
  "primary": "provider_a.structured_model",
  "fallbacks": ["provider_b.extraction_model"],
  "disallowed": ["provider_c.fast_model"],
  "requires": ["json_schema", "enum", "required_fields"],
  "validation": "strict_before_return"
}

Preporuka: nikada ne vraćajte rezervni izlaz samo zato što je dobro oblikovan tekst. Vratite ga tek nakon što zadovolji isti ugovor na razini aplikacije koji se očekuje od primarne rute.

Kontrolirajte troškove prije nego što dođe do incidenata

Rezerva često prebacuje promet na skuplje modele točno u trenutku kada je promet povećan ili davatelj usluga smanjen. Bez kontrole troškova, mehanizam pouzdanosti može postati incident potrošnje.

Postavite zamjenska pravila koja uključuju:

• Maksimalni množitelj zamjenske cijene po ruti.
• Dopuštene razine modela po organizaciji, radnom prostoru ili okruženju.
• Dnevna ili satna zamjenska potrošnja proračuni.
• Zasebna pravila za interaktivna i skupna radna opterećenja.
• Pravila o tome može li zamjena prijeći granice pružatelja, regije ili obitelji modela.

Preporuka: mjerite cijenu po uspješnom odgovoru, a ne samo cijenu sirovog zahtjeva. Skuplja zamjena može biti opravdana ako sprječava korisniku vidljiv kvar na kritičnoj ruti. Ista zamjena može biti neprihvatljiva za skupni rad niskog prioriteta.

Politika troškova također bi trebala biti vidljiva organizacijama koje koriste platformu. Timovi će možda htjeti dopustiti premium zamjenu za proizvodne tijekove korisničke podrške dok ga blokiraju za razvoj, testiranje ili interno eksperimentiranje. To je odluka o upravljanju, a ne samo odluka o usmjeravanju.

Dodajte prekidače po pružatelju, modelu, regiji i klasi pogreške

Naivna zamjena može štetiti degradiranom pružatelju. Svaki neuspjeli primarni zahtjev pokreće drugi primarni pokušaj, zatim još jedan rezervni pokušaj, dok ostale usluge čine isto. Prekidači smanjuju ponavljani pritisak i čine ponašanje usmjeravanja predvidljivijim.

Prekidač bi trebao biti dovoljno specifičan da izbjegne pretjeranu reakciju. Ne označavajte cijelog pružatelja kao neispravnog jer jedan model u jednoj regiji vraća strukturirane pogreške izlaza. Pratite zdravlje po pružatelju, modelu, regiji, ruti i klasi pogreške gdje je to moguće.

Jednostavan automat stanja prekidača dovoljan je za mnoge timove:

• Zatvoreno: normalni promet teče do rute.
• Otvoreno: ruta je privremeno izbjegnuta nakon pogreške pragovi su prekoračeni.
• Poluotvoreno: ograničeni promet sonde testira oporavak prije nego što se puni promet nastavi.

Pragovi bi trebali uzeti u obzir volumen. Deset neuspjeha u minuti može biti značajno za rutu male količine, ali nevažno za rutu koja obrađuje tisuće zahtjeva u minuti. Koristite minimalne veličine uzorka, pokretne prozore i filtre klase grešaka.

Preporuka: prekidači ne bi trebali brojati samo HTTP kvarova. Također bi trebali zasebno pratiti neuspjehe valjanosti izlaza, stope vremenskog ograničenja, stope ograničenja brzine i uzorke odbijanja ili blokiranja. Te klase podrazumijevaju različite operativne odgovore.

Zabilježite odluku o usmjeravanju, a ne samo konačnu pogrešku

Zamjena koja poboljšava korisničko iskustvo još uvijek može otežati dijagnosticiranje incidenata.Ako dnevnici prikazuju samo konačnog uspješnog pružatelja usluga, inženjeri gube dokaz da primarni pružatelj nije uspio.

Svaki zahtjev treba zabilježiti:

• Izvorni pružatelj, model i ruta.
• Zamjenski pružatelj, model i ruta kada se koristi.
• Klasa pogreške koja je pokrenula ponovni pokušaj ili backback.
• ID-ovi zahtjeva pružatelja usluga kada su dostupni.
• Broj ponovnih pokušaja i trajanje odgode.
• Rok iskorišten prije svakog pokušaja.
• Rezultat provjere valjanosti izlaza.
• Procijenjeni trošak za svaki pokušaj i konačni trošak.
• Je li stigao konačni odgovor od primarne ili zamjenske.
• Organizacija, radni prostor, okruženje i metapodaci aplikacije gdje to pravila dopuštaju.

Ova telemetrija podržava i inženjersko i komercijalno upravljanje. Također povezuje zamjensko ponašanje s AI API kontrolom troškova kada različiti timovi, proizvodi ili klijenti imaju različite politike pouzdanosti i proračuna.

Izmjerite je li zamjena doista pomogla

Sirova stopa uspjeha nije dovoljna. Zamjenska strategija može povećati konačnih 200 odgovora dok istovremeno pogoršava kašnjenje p99, udvostručuje trošak ili vraća manje važeći strukturirani izlaz.

Izmjerite barem ove metrike putem:

• Primarna stopa uspjeha.
• Konačna stopa uspjeha nakon ponovnog pokušaja i zamjene.
• p50, p95 i p99 latencija prije i nakon vraćanja.
• Stopa zamjenskog pozivanja.
• Cijena po uspješnom odgovoru.
• Stopa odgovora koja vrijedi ugovorom.
• Sigurnosna stopa odbijanja ili blokiranja od strane pružatelja.
• Signali regresije kvalitete iz specifičnih aplikacija evaluacija.

Predviđanje: kako sve više tvrtki koristi LLM infrastrukturu s više pružatelja, zamjenska će pravila postati više poput prometnog inženjeringa, a manje kao ad hoc rukovanje iznimkama.Timovi će očekivati kontrole pravila prema radnom prostoru, okruženju i klasi radnog opterećenja, s revizijskim zapisima koji objašnjavaju zašto je model odabran.

Kontrolni popis implementacije

Upotrijebite ovaj kontrolni popis prije nego što omogućite zamjenu na produkcijskoj ruti:

• Definirajte proračun latencije rute i rok zahtjeva.
• Klasificirajte pogreške pružatelja u one koje se mogu ponoviti, zamjenski prihvatljivi i klase terminala.
• Dokumentirajte koji kvarovi ne smiju pokrenuti zamjenu.
• Navedite odobrene primarne i zamjenske modele prema klasi radnog opterećenja.
• Provjerite duljinu konteksta, podršku alata, podršku sheme i sigurnosno ponašanje za svaku zamjenu.
• Provjerite valjanost svakog konačnog odgovora u odnosu na aplikaciju ugovor.
• Postavite maksimalni broj ponovnih pokušaja, backoff, jitter i Retry-After rukovanje.
• Konfigurirajte prekidače prema dobavljaču, modelu, regiji i klasi pogreške.
• Postavite množitelje troškova i rezervna ograničenja potrošnje.
• Zabilježite ID-ove zahtjeva, klase pogrešaka, pokušaje, rezultate provjere, kašnjenje i trošak.
• Pregledajte kašnjenje p95 i p99 nakon uvođenja, a ne samo prosječno kašnjenje.
• Ispad pružatelja testa, ograničenje brzine, nevažeća shema, sigurnosno odbijanje i scenariji neuspjeha valjanosti izlaza.

Zaključak koji se može poduzeti

Dobra strategija LLM-a za zamjenu je regulirana politika usmjeravanja. Odvaja ponovni pokušaj od zamjene, precizno klasificira neuspjehe, čuva izlazne ugovore, poštuje rokove kašnjenja i čini trošak vidljivim prije nego što dođe do incidenata.

Ključno načelo dizajna je nepromjenjivost. Odlučite što mora ostati istinito kada promet prelazi s primarnog modela na zamjenski: valjanost sheme, sigurnosno ponašanje, rukovanje kontekstom, podrška alata, ograničenja troškova i vidljivost. Zatim dopustite zamjenu samo ako se te invarijante mogu očuvati.

Počnite s jednom visokovrijednom rutom umjesto globalnog zamjenskog prekidača. Definirajte njegovu taksonomiju pogrešaka, kompatibilne rezervne modele, pravila provjere valjanosti, prekidače strujnog kruga i metriku. Izvedite vježbe neuspjeha protiv te rute. Ako se konačna stopa uspjeha poboljša bez neprihvatljivog kašnjenja p99, gubitka odgovora valjanog ugovora ili povećanja troškova, proširite pravilo na sljedeću klasu radnog opterećenja.

Povezano čitanje

• raspodjela potrošnje LLM-a prema timu i aplikaciji