Cum funcționează un ruter LLM?

Un endpoint intră, un endpoint este ales

Un ruter de model preia o cerere care nu numește nicio mașină și returnează răspunsul uneia pe care o regulă a selectat-o. Aici este deliberat mic: o cerere compatibilă OpenAI ajunge la o singură URL de bază, iar o funcție pură — fără bază de date, fără ceas, fără rețea — decide ce endpoint îi răspunde. Intrările funcției sunt endpoint-urile candidate încărcate de apelant și timpul curent, ceea ce face ca fiecare regulă să fie testabilă fără un stack în funcțiune.

Câmpul model decide câtă alegere are ruterul. Trimiterea llmeu-auto (sau llmeu/auto, auto, llmeu:auto) îi oferă pool-ul. Numirea unui model fixează acel model: ruterul alege apoi dintre endpoint-urile acelui model și nu substituie niciodată altul, deoarece o substituție silențioasă ar face ca câmpul model din răspuns să fie o ghicitoare. ID-urile modelului sunt normalizate mai întâi, astfel încât un ID prefixat de furnizor sau sufixat cu dată se rezolvă la slug-ul pe care îl cunoaște catalogul.

Filtrul rulează înainte de scor, într-o ordine fixă

Fiecare endpoint candidat este testat în raport cu politica și cererea, iar fiecare respingere este înregistrată cu un șir de motive literal. Ordinea face parte din contract, deoarece primul motiv pentru care un endpoint este respins este cel care explică ruta.

Un endpoint al cărui tip este doar catalog merge primul: nimic din implementare nu răspunde cu el, deci este eliminat înainte de a fi luată în considerare orice altă regulă. Apoi cele al căror status nu este nici "up", nici "degraded". Apoi clasa de suveranitate, verificată atât în raport cu politica organizației, cât și cu rezidența numită în cerere. Apoi regiunea, când rezidența sau politica fixează una. Apoi un model care nu poate genera text — un model de recunoaștere vocală, de încorporare sau de reranker este refuzat aici, mai degrabă decât să i se ceară o completare pe care nu o poate produce. Apoi lista de interdicții a furnizorului, lista de permisiuni a furnizorului, lista de interdicții a modelului și lista de permisiuni a modelului, în această ordine. Apoi endpoint-urile partenerilor în timp ce flag-ul partenerului este oprit. Apoi un model fără modalitatea de viziune dacă cererea conține o imagine. Apoi fereastra de context, dacă fereastra documentată este mai mică decât intrarea plus ieșirea solicitată. Și în cele din urmă, prețul, în raport cu plafonul din politică sau din cerere.

Nimic nu supraviețuiește acelui filtru atunci când regula este cu adevărat imposibil de satisfăcut, iar apoi răspunsul este 409 no_endpoint_for_policy. Mesajul este propria propoziție a motorului despre rezidența solicitată, urmată de „Rezidența nu este niciodată relaxată în tăcere.” Nu este o eroare tranzitorie: aceeași cerere eșuează din nou în același mod, iar soluția este să numiți o rezidență pe care politica o permite sau să extindeți politica în mod deliberat în consolă.

Scorul și de ce nu este un concurs de popularitate

Ceea ce supraviețuiește este evaluat, nu clasat după dimensiune sau după tabelul de benchmark. Adecvarea sarcinii are o pondere de cinci, adecvarea limbii de trei, completitudinea documentației de unu, iar o clasă de suveranitate documentată de până la doi. Prețul, latența înregistrată și rata de eroare înregistrată se scad: doi, doi și respectiv trei. Prețul și latența sunt normalizate în setul supraviețuitor, astfel încât candidații sunt comparați între ei, mai degrabă decât cu o scară fixă, iar un candidat fără latență înregistrată este evaluat la 500 de milisecunde.

Deoarece adecvarea sarcinii domină, același pool de cereri se rutează diferit per sarcină. Sarcina ieftină preferă modelele cu 9B parametri sau mai puțin și scade un model de 753B la 0,15. Recuperarea este decisă de fereastra de context înregistrată, astfel încât un model care poartă tag-ul rag, dar nu poate reține fragmentele, nu câștigă. O cerere de codare preferă un slug specializat în cod, o cerere în germană câștigă puncte pentru un model a cărui listă de limbi puternice conține germana, iar o cerere multilingvă câștigă puncte odată ce un model declară șase sau mai multe limbi puternice. Egalitățile se rup la prețul mai mic, apoi la latența înregistrată mai mică, apoi la un identificator stabil — astfel încât aceeași cerere se rutează în același mod de două ori.

Câmpurile de politică care decid

Șase câmpuri de politică ajung la filtru: ce clase de rezidență și regiuni sunt permise, listele de permisiuni și interdicții ale furnizorului, listele de permisiuni și interdicții ale modelului, dacă endpoint-urile partenerilor sunt eligibile deloc și un plafon de preț per milion de token-uri. Cererea le poate doar restrânge. Solicitarea eu-owned într-o politică care permite eu-hosted restrânge setul; nu îl poate lărgi niciodată. Plafonul de preț al cererii poate doar reduce pe cel al politicii.

Alte trei coloane de politică sunt aplicate cu un strat deasupra motorului, în jurul aceleiași decizii: retenția, clasele de date permise și un buget zilnic. Un buget deja epuizat eșuează cererea înainte ca orice endpoint să fie evaluat, cu budget_exceeded. O cerere care nu numește nicio rezidență primește propriul set al politicii: eu-hosted în timp ce fiecare clasă pe care politica o admite este EU-hosted, și orice odată ce admite altceva.

Failover-ul rămâne în cadrul deciziei

La un 5xx sau un backend inaccesibil, este încercat următorul candidat cel mai bun, până la trei încercări, și fiecare încercare este înregistrată. O eroare pe care backend-ul o marchează ca finală nu este reîncercată deloc. Lista de reîncercări este construită din decizia care a fost deja filtrată, astfel încât o reîncercare se poate muta la un endpoint diferit în cadrul politicii dvs. și niciodată în afara acesteia — un failover care a scăpat de filtrul de rezidență ar fi o eroare de rezidență, care este clasa de defecte pe care acest design există pentru a o preveni.

Ce vă spune răspunsul

Răspunsul adaugă un bloc lângă câmpurile standard OpenAI: ID-ul de urmărire, modelul utilizat, versiunea sa, furnizorul, ID-ul endpoint-ului, regiunea de inferență, clasa de suveranitate, ID-ul politicii, retenția aplicată, o estimare a costului și un motiv de rutare. Acest motiv este o propoziție mai degrabă decât un cod și numește regiunea și clasa: rutare automată pentru o sarcină de codare cu rezidență eu-hosted, slug-ul și regiunea alese, clasa în cuvinte, câte endpoint-uri au fost excluse și dacă endpoint-urile partenerilor au fost permise. Aceeași propoziție este afișată verbatim în consolă, iar urma stocată este recuperabilă prin ID-ul său.

O notă de denumire, deoarece cuvintele se suprapun în rezultatele căutării: rutarea este utilizată pentru mai multe lucruri diferite în acest domeniu. Ceea ce este descris aici este ruterul din acest depozit, și fiecare regulă de mai sus este citită din codul care o aplică — motivele de respingere sunt șirurile sale literale, ponderile sunt funcția sa de scor, iar valorile implicite sunt valorile implicite ale coloanelor schemei bazei de date.