lachtan/nanobot-runtime
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
977a894cc8c33a7ca4cffd997348db90f121b7e5
nanobot-runtime/results/2026-09-20_deepseek-v4.1-flash-vs-glm-5.3-vs-kimi-k2.6.md
lachtan 6216bdfb90 nanobot: 2026-09-20 14:22:14
2026-09-20 14:22:16 +02:00

14 KiB
Raw Blame History

deepseek-v4.1-flash vs glm-5.3 vs kimi-k2.6 — agentní použití v nanobotu

Srovnání kandidátů pro Ollama Cloud endpoint (nvidia.hell), sběr 2026-09-20. Otázka: který z těch tří má jezdit jako agentní model v nanobotu (daily driver, cron/dream úlohy, detached tasky).

Tohle je rešerše z veřejných zdrojů + naše produkční data. Není to změřený A/B běh na našich úlohách — varianty A/B z plans/deepseek-v4.1-flash-eval.md jsou pořád neuzavřené, takže se zde neprezentuje žádné „skóre na našich úlohách".

1. Zdrojová základna (source-by-source)

# Zdroj Typ Co z něj je použitelné Spolehlivost
S1 ollama.com/library/<model>/tags vendor (Ollama) usage tier, kontext, modalita vstupu primární — jinak nedostupné
S2 ollama.com/library/<model> (readme) vendor (DeepSeek / Z.ai / Moonshot) vendor benchmark tabulky self-reported, číst jako marketing s daty
S3 artificialanalysis.ai/articles/...-v4-3 nezávislý benchmarker verze indexu, složení evals, poměr open-weights modelů vysoká, ale čísla per-model jsou jen v grafech
S4 artificialanalysis.ai/models/<model> nezávislý benchmarker metadata o indexu nízká při textovém fetchi — číselné hodnoty jsou v grafech, extrakce vrací boilerplate
S5 ollamatps.com (+ per-model stránky) nezávislé live měření našeho typu endpointu tok/s, TTFT, 24h reliabilita, mirror AA indexu vysoká pro latenci na Ollama Cloud, jednoduchá metoda (jeden 300-tokenový prompt / 10 min)
S6 github.com/ollama/ollama issues pozorované provozní poruchy konkrétní failure modes na cloud infrastruktuře vysoká — reprodukované s logy, ale incidentové
S7 github.com/vllm-project/vllm issues OSS/self-host cesta parser bugy, které Ollama Cloud nemusí mít střední — jiná serving cesta, nepřenášet 1:1
S8 db/ollama_usage.sqlite (samples) naše produkce reálné per-model request counts primární pro „co reálně jezdí"
S9 knowledge/models.md naše dřívější rešerše GLM řada jiná vintage indexu — viz §5

Lessons-learned pro budoucí hledání

  1. Hodnoty AA indexu nelze vytáhnout z /models/<model> — jsou v interaktivních grafech, Jina extrakce vrátí jen vysvětlující boilerplate. Čísla ber z (a) annonce verze indexu /articles/..., (b) ollamatps.com, který je mirroruje. Dnes to stálo 3 fetche, než to bylo jasné.
  2. ollamatps.com leaderboard je zkrácený na ~3057 znaků a modely pod GLM 5.2 se do výpisu nevejdou. Per-model URL /models/ollama/<slug> vrací kompletní stránku včetně 24h avg, TTFT a reliability.
  3. Usage tier je jen na .../tags, ne na hlavní stránce modelu. Bez toho fetch nemá smysl.
  4. Vendor tabulky se navzájem křižují — DeepSeek tech report tabulka obsahuje řádky pro GLM-5.3 i Kimi K3; Z.ai tabulka obsahuje DeepSeek-V4 Pro. Dobré na cross-check, ale obojí self-reported, tedy stejná rodina biasu.
  5. Issue search per model name je nepodceňovaný zdroj — bench tabulky nikdy neukážou „jeden request trval 10 minut 52 sekund". U kimi-k2.6 to našlo konkrétní cloud incident (#16845).

2. Co je ověřené o modelech

deepseek = deepseek-v4.1-flash glm = glm-5.3 kimi26 = kimi-k2.6
Usage tier (S1) Medium High High
Kontext (S1 / S1+API) 1M (API: 1 048 576) 1M 256K
Modalita (S1) Text + Image Text only Text + Image
Parametry (S1/S2) 552B backbone, 8B aktivní prefill / 16B decode 753B 1,04T
Capabilities (API /api/show) completion, thinking, tools, vision tools, thinking vision, tools, thinking
Stáří tagu (S1) 1 týden 3 týdny 5 měsíců
Cena/1M tok (S1) neuvedeno $1,40 in / $0,26 cached / $4,40 out $0,95 in / $0,16 cached / $4,00 out
AA Intelligence Index v4.3.2 (S5) 39,5 44,8 27
Live tok/s, 24h avg (S5) 183,4 144,3 45,9
Live TTFT (S5) 527 ms 439 ms 1,1 s
24h reliabilita (S5) 100 % 100 % 100 %

Poznámka k indexu: hodnoty výše jsou z ollamatps.com, který mirroruje AA v4.3.2 jako „(max)" variantu. Annonce v4.3 (S3) uvádí jako třetí nejsilnější open-weights model GLM-5.3 Flash (42) za GLM-5.3 a Kimi K3 — tedy GLM-5.3 i GLM-5.3-Flash sedí nad DeepSeek V4 Pro (36). DeepSeek V4.1 Flash v annonci výslovně zmíněn není; 39,5 pochází jen z ollamatps.

Kde se čísla rozcházejí

  • AA article vs AA model page vs ollamatps. Annonce píše o GLM-5.3 a Kimi K3 jako leaderech open weights; ollamatps dává GLM-5.3 = 44,8, ale Kimi K2.6 = 27 (K3 je jiný, novější model než K2.6 — nezaměňovat, je to stejná rodina, ale jiná generace). Není to rozpor, je to riziko záměny jmen.
  • DeepSeek V4.1 Flash v AA annonci chybí. Buď nebyl v době psaní článku změřen, nebo nespadá do top sestavy. 39,5 tedy nemám potvrzené druhým zdrojem.

3. Vendor benchmarky (S2) — co si navzájem tvrdí

Obě tabulky jsou self-reported. DeepSeek uvádí i konkurenci, což je užitečné na orientaci, ale ne na verdikt.

Benchmark DS-V4.1-Flash GLM-5.3 Kimi K3 (ref. Opus-5.0)
Terminal-Bench 2.1 90,6 88,2 88,3 89,1
Terminal-Bench 3.0 30,0 28,3 17,7 43,3
Terminal-Bench 4.0 31,2 37,9 12,6 51,8
DeepSWE v1.1 74,2 66,9 67,5 74,0
AutomationBench 54,8 48,8 46,7 50,3
HLE (bez tools) 36,8 42,0† 43,5 56,3
HLE w/ tools 63,9 62,5 59,8 63,6
CyberGym 88,1 84,5 80,0 —
SWE-Marathon v1.1 — 42,5 48,1 48,8
Toolathlon Verified — 73,0 76,5 —

† podle Z.ai; DeepSeek uvádí u GLM-5.3 42,0, Z.ai sám v readme neuvádí HLE.

Čtení: DeepSeek V4.1 Flash vede na benchích 2. generace (TB 2.1, DeepSWE, AutomationBench), GLM-5.3 vede na novějších/horizonovějších (TB 4.0, SWE-Marathon řada). Na TB 4.0 — což je metrika, kterou AA používá v aktuálním indexu v4.3.2 — je GLM-5.3 (37,9) nad DeepSeekem (31,2). To koreluje s AA: GLM-5.3 44,8 vs DS V4.1 Flash 39,5. Vendor 2.1-érová čísla DeepSeeku jsou tedy ze starší generace benchů a v aktuálním indexu se nepřenášejí.

Kimí K2.6 v těchto tabulkách vůbec není — je o generaci starší, oba vendory srovnávají s K3, ne s K2.6. Pro K2.6 tedy platí jen AA 27 a absence aktuálních agentních čísel.

4. Provozní realita (S5 + S8)

Latence

speed je největší rozdíl mezi K2.6 a zbytkem: 45,9 tok/s proti 183,4 (DeepSeek) a 144,3 (GLM). Při stejném výstupu je K2.6 ~3–4× pomalejší — souhlasí s dřívějším měřením z našeho endpointu i s K2.6 pozicí „output ~44 t/s" v knowledge/models.md. TTFT 1,1 s je také 2–2,5× nad ostatními dvěma.

Pro srovnání, preset kimi (= kimi-k2.7-code, coding fork) má 121,6 tok/s / TTFT 660 ms — tedy kimi-k2.7-code je na tom infrastrukturně výrazně lépe než kimi-k2.6, i když má nižší AA index (25,8 vs 27).

Naše reálné využití (db/ollama_usage.sqlite, 294 vzorků, 2026-09-15 → 09-20)

Model Peak weekly requests Peak session requests
glm-5.3 1 737 203
deepseek-v4.1-flash 94 94
glm-5.3-flash 78 46
kimi-k2.7-code 62 29
kimi-k2.6 5 —

Kvóta: session okno 10,1 %, weekly 34,9 % (stav při sběru).

Zajímavé: deepseek-v4.1-flash má 94 requestů v obou oknech, tj. celý jeho provoz se vešel do jednoho session okna. glmu 1 737/týden proti 203/session znamená, že jeho provoz je rozložený — na tenhle objem je potřeba jiný model než na jednorázový test.

Kimi K2.6 je fakticky nevyzkoušený — 5 requestů za týden. Cokoli o jeho chování v našem provozu je domněnka, ne měření.

Poruchy (S6)

  • ollama/ollama #16845 (červen 2026): kimi-k2.6:cloud vykazoval opakovaně (18 výskytů za 2 dny) dva failure modes — jednotlivý /api/chat request trval 10 min 52 s (HTTP 200, stream průběžně aktivní, klient nemá jak timeoutovat), a mid-stream INTERNAL_ERROR na upstream HTTP/2, kdy lokální Ollama server chybu klientovi vůbec nesdělí a jen přestane streamovat. Obě poruchy jsou na straně cloud infrastruktury, ne modelu — ale dopadají na model.
  • vllm-project/vllm #41739: Kimi K2 tool parser pouští malformovaný JSON v tool_call.arguments při dlouhých tool callech. Toto je OSS/self-host cesta, na Ollama Cloud se nemusí projevit — neprezentovat jako vlastnost modelu zde.

5. Vědomá past: míchání vintage indexu

knowledge/models.md uvádí GLM-5.3 = 60 a Kimi K3 = 60 na „AA Intelligence Index v4.1.1". Aktuální index je v4.3.2 (deset evals včetně Terminal-Bench 4.0 a AutomationBench-AA, zavedeno v v4.2/v4.3) a hodnoty jsou nesrovnatelně nižší napříč celým polem — Claude Fable 5.1 i GPT-6 Astra mají 53, GLM-5.3 44,8. Rozdíl 60 → 44,8 není regrese modelu, je to jiná sada testů.

Totéž platí pro „~37 % propad vendor vs produkce" a pro stará srovnání z results/2026-06-07_ollama-cloud-agent-model-comparison.md, kde byl baseline glm-5.1 a čísla pocházela z jiné generace benchů. Nemíchat.

6. Verdikt (per role, ne jeden model)

Tohle není „vyber jeden a zahoď ostatní" — tři modely mají tři různé profily. Názor podložený výše uvedeným, ne měřením na našich úlohách:

  • glm (glm-5.3) — daily driver a cron/dream. Nejlepší AA index (44,8), nejnižší TTFT (439 ms), High Usage tier, text-only. Na TB 4.0 (metrika aktuálního indexu) vede nad DeepSeekem. Pro náš typ práce (dlouhé session, konvence, čeština) je to konzervativní správná volba a naše produkční data ukazují, že už to tak je (1 737 req/týden).
  • deepseek (deepseek-v4.1-flash) — legitimní alternativa, ne náhrada. Medium Usage tier je hlavní ekonomická výhoda (méně kvóty za stejný objem requestů), 183,4 tok/s je nejvyšší z trojice a 1M kontext + vision je širší než glm-5.3. Cena: nižší AA index (39,5), vendor agentní čísla jsou ze starší generace benchů, a není ověřeno, jak zvládá S6 (no-tool restraint) — u deepseek-v3 to byl fail a to je u čínské rodiny přesně ta vlastnost, kterou je potřeba změřit, ne předpokládat.
  • kimi26 (kimi-k2.6) — nedoporučuji pro tenhle provoz. Nejnižší AA index (27), ~4× pomalejší throughput, nejvyšší TTFT, 5 měsíců starý tag, High Usage tier (tedy dražší kvótou než DeepSeek) a konkrétní zdokumentovaný cloud incident s 10minutovými requesty a tichým dropem streamu (#16845). Jeho jediná strukturální výhoda proti glm-5.3 je vision vstup a 24/7 swarm orchestration — pro to ale máme flash (vision) a kimi (k2.7-code, 2,6× rychlejší).

Zásadní korekce oproti staršímu reportu: results/2026-06-07_...comparison.md řadil kimi-k2.6 mezi „blockers" kvůli random Chinese drift. To bylo postavené na community reportech. Při ověřování se ukázalo, že doložený případ je kimi-k2.5 přes OpenRouter (MoonshotAI/Kimi-K2 #144), kde model přešel do čínštiny po promptu „we are Chinese now" — tedy trigger-specific, ne spontánní. Pro K2.6 na Ollama Cloud doložený drift nemám. Blocker to tedy není, ale ani to není vyvrácené — je to neověřené a pro český provoz by to chtělo měření (regex na CJK v odpovědích), ne citaci issue.

7. Co zůstává neověřené

  1. S6 no-tool restraint na deepseek-v4.1-flash a glm-5.3. Netestováno. ollama-toolcall-test.py má whitelist lokálních modelů, cloudové tam nejsou.
  2. Jazykový drift (CJK) na všech třech. Bez měření.
  3. Cena deepseek-v4.1-flash per 1M tok — Ollama library stránku cenu neuvádí.
  4. DeepSeek V4.1 Flash v AA indexu — potvrzeno jen jedním zdrojem (ollamatps).
  5. Verbosity / poměr thinking:response u kterékoli z trojice na našich úlohách.
  6. Delta kvóty pro Medium vs High tier na stejném objemu práce — máme teď jen absolutní request counts, ne normalizovaný poměr.

8. Doporučené navazující kroky (čekají na odsouhlasení)

  1. Doplnit deepseek-v4.1-flash:cloud + glm-5.3:cloud do whitelistu projects/ai/artifacts/ollama-toolcall-test.py a pustit 10 scénářů na oba. Levné, deterministické, rozhodne o S6. (nedělal jsem — není odsouhlaseno)
  2. Doplnit presed deepseek do tabulky presetů v knowledge/models.md — chybí tam. (nedělal jsem)
  3. Označit v knowledge/models.md čísla z v4.1.1 jako stará vintage, aby se nemíchala s v4.3.2. (nedělal jsem)
  4. Zvážit, jestli kimi26 preset má v configu vůbec zůstat (5 req/týden, nejhorší profil z trojice). (nedělal jsem — nevratné, čeká na tebe)

Zdroje

Primární (vendor):

Nezávislé:

Provozní poruchy:

Naše data:

  • db/ollama_usage.sqlite (294 vzorků, 2026-09-15 → 2026-09-20)
  • knowledge/models.md, projects/ai/memory.md, plans/deepseek-v4.1-flash-eval.md
Reference in New Issue View Git Blame Copy Permalink