Multi-provider LLM routing — minek és mikor

Három hét. Ennyi idő telt el a „kéne egy router” mondat és az első per-request, négy-dimenziós, élesben működő provider-választás között. Most öt LLM-providerre routol-unk élesben: OpenAI, Anthropic, Azure OpenAI, Google Gemini, Mistral. Ez egy poszt arról, miért éri meg az erőfeszítés, és miért nem éri meg az egyetlen provider melletti maradás, ha komolyan veszed a cost/latency/SLO trojkát.

Miért nem elég egyetlen provider

Kezdetben mindenki egyetlen providerrel kezd. OpenAI, mert ez a default. Hat hónap múlva történik valami: egy provider-szintű outage (két óra, február 14-én, GPT-4o 503-as válaszok), vagy egy árváltozás (Anthropic Claude 3.5 Sonnet júniusban 40%-kal olcsóbb lett), vagy egy capability gap (Gemini 2M kontextus, ha hosszú dokumentumot kell beolvasni). Ekkor jössz rá, hogy az egyetlen provider egyúttal egyetlen vendor-lock, egyetlen failure mode, és egyetlen ár-szerződés.

A 4 dimenzió, amin a router döntést hoz

A RouterPolicyService minden kérést végigfuttat egy négy-dimenziós szűrőn:

1. Capability — tudja-e a modell amire szükség van? Function calling, JSON mode, vision input, 100k+ context, magyar nyelvi fluency. A eng_model_capabilities táblában tárolt mátrix, providerenként frissül.
2. Cost — a per-token ár × várt token count. A eng_pricing_table-ben él, 6 óránként refresh-el (lásd: cost-attribution poszt). Per-tenant cost-ceiling a eng_tenant_slo-ból.
3. Latency — a provider utolsó 30-perces p95 latenciája az adott modellre. Ha a provider 30 perce nem szállított, pessimistic estimate (worst published).
4. Fallback chain — ha az elsődleges választás hibázik (rate limit, 5xx, timeout), melyik a backup. Maximum 3 mélységű chain.

A routing kód magja

async route(req: LlmRequest): Promise<RoutingDecision> {
  const candidates = await this.capabilityFilter(req);
  const priced = await this.costAnnotate(candidates, req);
  const eligible = priced.filter(c => c.cost <= req.tenantSlo.costCeiling);
  const ranked = eligible.sort((a, b) =>
    a.p95LatencyMs - b.p95LatencyMs
  );
  return {
    primary: ranked[0],
    fallbacks: ranked.slice(1, 4),
    reason: this.explainChoice(ranked[0], req),
  };
}

Az explainChoice egy ember-olvasható string, amit a span attribute-ra is rátettünk. „picked anthropic/claude-3-5-sonnet because openai/gpt-4o p95=2400ms exceeds tenant SLO 1500ms”. Ez a debuggability legértékesebb mezője a teljes routerben.

A három hét, ami eltartott

1. hét: capability mátrix feltöltése, provider adapter interfész. Öt provider, mind másképp dokumentálja a function calling-ot.
2. hét: pricing-tábla és refresh worker. Két provider nem publikál ár-API-t, manual lookup.
3. hét: telemetria (latency-tracking), tenant SLO szerkesztő, és a fallback-chain. Az utolsó három nap a regressziós teszt: 200 kérdés, mind az öt providerre, hogy a routing reprodukálható és deterministic legyen ugyanazon SLO mellett.

A mai napi szám

Élesben naponta ~340 000 kérést routol-unk. A cost-ceiling sértést kérő tenantek aránya: 0.4%. A fallback-chain aktiválási rátája: 2.1%. A medián routing decision time: 8ms. A medián teljes request latency: 720ms. Egy év óta egyetlen tenant sem nyújtott be feature-request-et single-provider lock-ra való visszatérésre — de hatan kérték, hogy adjunk hozzá új providert. Most gyúrjuk a hatodikat (Cohere).

A tanulság: a multi-provider routing nem költségoptimalizálás, hanem opció-tartás. Opció a vendor-lock ellen, opció az outage-ek ellen, opció a piaci ár-mozgások ellen. És a három hét bizonyul az egyik legjobb ROI-jú befektetésnek, amit a platform 2026-ban hozott.