Váhy jsou jen jedna z vrstev, které určují odpověď
Router typu OpenRouter dává jeden endpoint na model a za ním drží dvacet poskytovatelů, kteří hostují tytéž váhy. Prodává se to jako komodita: stejný model, jen levněji. Provozní data z asistenta, který protočil přes osmnáct milionů zpráv, ukazují, že komodita to není.
Chování modelu určuje celý serving stack, ne jen checkpoint. Kvantizace, tokenizér, parser tool callů, výchozí sampling, verze runtime. Router z toho dělá volbu, kterou neděláš ty a která se mění mezi jednotlivými requesty.
Rozdíl není v šumu, je v desítkách bodů
Na DeepSeek V4 Flash 0731 dal první poskytovatel 90 % na GPQA a 81 % na TAU-Bench. Jiný poskytovatel se shodnými vahami dal 75 % a 58 %. Dvacet bodů na TAU-Bench, tedy na benchmarku, který u agentů rozhoduje, není odchylka měření. Je to jiný produkt pod stejným jménem.
Deklarovaná přesnost ti to nepomůže odfiltrovat. Měsíc měření filtru na fp4, fp8 a bf16 ukázal hosty s fp4, kteří skórovali stejně jako hosti s fp8, a nejhorší výsledky rozprostřené napříč všemi deklarovanými přesnostmi. Deklarace je metadato, ne měření.
Podobně to platí pro schopnosti. Někteří poskytovatelé hostují vision model, který obrázek nevidí. Jeden přečetl písmeno K jako R a červenou popsal jako modrou. Jiní vrátili „no image provided“ u modelu, který obrázky umí. Ve všech případech se stavovým kódem 200.
Parametry se přijímají, ne nutně plní
reasoning.effort je přijat univerzálně. Splněn není. Stejný prompt se stejným nastavením vygeneroval u části poskytovatelů zcela odlišný počet reasoning tokenů bez ohledu na to, co bylo v parametru.
To je nepříjemnější než tvrdá chyba, protože se to neprojeví jako výjimka. Projeví se to jako horší odpovědi a vyšší nebo nižší účet, tedy jako věci, které přičteš modelu.
Stejný vzor pokrývá i tool cally. Někteří poskytovatelé strukturovaný call neparsují a vrátí surový markup jako text odpovědi. A pak je tu nejtišší případ: HTTP 200, finish_reason: "stop" a content: null. Stav 200 říká, že request byl obsloužen, ne že v něm je odpověď.
Provoz se nechová jako tvůj notebook
Dva poskytovatelé fungovali bez chyby z autorova Macu a téměř každou sondu z produkční infrastruktury odmítli s 429. Stejný klíč, stejná minuta. Rate limiting se vázal na IP, ne na účet.
Z toho plyne pravidlo pro každé měření poskytovatele: měř z místa, odkud poběží produkce. Benchmark z lokálu ti řekne o síti a reputaci tvé IP, ne o tom, co dostanou uživatelé.
Pinnutí na jednoho ověřeného poskytovatele není řešení. Tři nezávisle spolehliví poskytovatelé selhali v kaskádě během dvou týdnů. Redundance musí zůstat, jen se k ní musí přidat měření.
Co si z toho odnést
Přestaň konfiguraci LLM volby chápat jako výběr modelu. Vybíráš dvojici model a poskytovatel a ta dvojice je to, co jsi otestoval. Když router nechá druhou půlku volnou, tvoje evaluace neplatí pro produkci.
Prakticky to znamená tři věci. Filtruj poskytovatele podle naměřeného skóre na tvé úloze, ne podle deklarované kvantizace nebo podporovaných modalit. Loguj si, který poskytovatel request obsloužil, a k němu počet reasoning tokenů, jinak regresi nikdy nepřiřadíš příčině. A validuj obsah odpovědi, ne stavový kód, protože prázdné content s dvoustovkou je běžný stav, ne anomálie.
Obecněji: kdykoli ti nějaká vrstva slibuje, že za tebe vybere levnější variantu téhož, ptej se, co přesně považuje za totéž. Tady je odpovědí soubor vah, zatímco tebe zajímá chování.