Qwen zapnul svému streamovacímu moderátoru vyrovnávací paměť až po roce

Moderační model Qwen3Guard-Stream od Alibaba Cloud posuzuje bezpečnost odpovědi průběžně, token po tokenu, jak ji jazykový model píše. Referenční kód, který k němu laboratoř přiložila do repozitářů vah, ale nikdy nezapnul vyrovnávací paměť klíčů a hodnot – takže při každém dalším tokenu prošel celý dosavadní text znovu od začátku. Opravu Qwen začlenil 27. září 2026 do všech tří velikostí. Váhy přitom vyšly 23. září 2025, tedy o 369 dní dřív.

Moderátor, který nečeká na konec odpovědi

Qwen3Guard vyšel ve dvou podobách a ve třech velikostech – 0,6B, 4B a 8B –, všechny pod licencí Apache 2.0. Generativní varianta dostane celý dotaz i celou odpověď a vrátí soud. Streamovací má navíc klasifikační hlavu nad jednotlivými tokeny, takže smí odpověď hodnotit za běhu, ještě než ji uživatel dočte.

Technická zpráva z 16. října 2025 z toho dělá hlavní důvod, proč ten model existuje: dosavadní hlídací modely potřebují hotový výstup, což se s průběžným generováním rozchází a nechává uživatele vidět škodlivé úryvky, než se zásah stihne. Za rychlost se platí přesností – podle zprávy je průměrný odstup streamovací varianty od generativní kolem dvou bodů. Zpoždění detekce zpráva měří v tokenech, ne v milisekundách, a o vyrovnávací paměti se v ní nepíše ani jednou. Tvrdí ale, že doba zpracování u streamovací varianty roste s délkou odpovědi zhruba lineárně.

Co v kódu chybělo

Soubor modeling_qwen3_guard.py je v repozitářích všech tří velikostí bajt po bajtu týž; shodují se v otisku, který Hugging Face u souboru posílá v hlavičce X-Linked-ETag. A je to kód, který si stáhne každý, kdo model načte přes Transformers s trust_remote_code=True – karta modelu to předepisuje jako podmínku, aby se architektura vůbec dala načíst.

Jeho smyčka stream_generate volala model bez parametru use_cache. Model ale obsah vyrovnávací paměti vrací jen tehdy, když je ten parametr zapnutý; jinak na jeho místo pošle None. Smyčka tedy do dalšího kola žádnou paměť nedostala a musela místo jednoho nového tokenu posílat celou dosavadní posloupnost. K tomu si sama skládala masku, která modelu říká, na které předchozí tokeny se smí dívat – a ta rostla s každým kolem.

Druhá polovina téže vady je v klasifikační hlavě. Volání neuvádělo ani logits_to_keep, jehož výchozí hodnota 0 se v kódu převádí na výřez slice(-0, None). A to je v Pythonu celá posloupnost, protože nula se znaménkem mínus je pořád nula. Hlava tedy počítala čtyři sady výstupů pro každou pozici, ne jen pro tu poslední.

Kolik práce z toho bylo navíc, se dá spočítat z rozměrů, na kterých se oprava měřila: dotaz o 64 tokenech a 16 dalších tokenů. Starý postup zpracuje 64 pozic v prvním kole a pak 65, 66 až 80, celkem tedy 1 224. Nový 64 plus šestnáct jednotlivých tokenů, tedy 80. Patnáctkrát méně; vlastní výpočet z těch dvou zadání.

Změřeno na nejmenší velikosti, na větších vůbec

Návrh podal 19. září 2026 na Hugging Face uživatel YxinMiracle, tedy někdo mimo tým Qwenu, a sám u něj napsal, co změřil a co ne. Na variantě 0,6B, na počítači s procesorem Apple M4 a 32 GiB paměti, v přesnosti float32 přes MPS, s PyTorch 2.8.0 a Transformers 4.55.4 spadl medián přírůstkové latence ze 116,26 na 28,66 ms na token a celkový čas včetně prvního průchodu z 1 958,92 na 516,25 ms. To je 4,06krát, respektive 3,79krát. Tři pokusy po zahřátí, se střídaným pořadím.

Že zrychlení nedosahuje spočítaných patnácti násobků, není rozpor. U modelu se šesti sty miliony parametrů spolyká velkou část času režie jednoho volání, která s délkou posloupnosti nesouvisí.

Varianty 4B a 8B autor nezměřil vůbec a napsal to do návrhu výslovně. Že výsledky zůstávají numericky stejné, ověřoval taky jen na 0,6B: výstupy spočítané s pamětí se od těch z plného průchodu lišily nejvýš o necelé čtyři milióntiny. K tomu proběhlo dvanáct regresních testů na drobném modelu na procesoru. Float32 přes MPS na notebooku navíc není nasazení, ve kterém by takový moderátor běžel v provozu, takže čísla ze serveru budou jiná. Nikdo je zatím nezveřejnil.

Proč na tom souboru záleží víc než obvykle

Referenční kód u tohohle modelu není jen ukázka. Karta nabízí dvě cesty, jak ho rozběhnout, a obě mají háček. První je Transformers s trust_remote_code=True, tedy právě ten soubor. Druhá je SGLang, ale nainstalovaný ze zdrojů a ne z hlavní větve: karta předepisuje git clone -b support_qwen3_guard. V té větvi je poslední commit z 3. listopadu 2025 a v hlavní větvi SGLangu se soubor se jménem Qwen3Guard nevyskytuje.

Karta zároveň slibuje, že tým na podpoře ve vLLM pracuje, a dodává „Stay tuned!“. Návrh na tu podporu vznikl 23. září 2025, tedy týž den jako repozitáře vah, a 11. května 2026 ho zavřel automat pro nečinnost, aniž byl začleněn; samostatnou žádost o podporu zavřeli dva dny předtím. Slib na kartě zůstal. U téhle značky to není poprvé – na nevydaném kódu SGLangu a vLLM se rozbíhal i draft model DFlash 2.

Jedna změna chování k tomu

Oprava mimoděk mění, co první volání vrátí. Dřív dala funkce stream_moderate_from_ids pro počáteční dotaz seznam soudů, jeden na každý jeho token; teď jediný, pro poslední token. Dokumentace té funkce přitom slibovala jen ten poslední už předtím a příklad na kartě modelu čte z výsledku poslední položku, takže ukázkový kód funguje dál. Rozejde se to jen tomu, kdo si ze seznamu bral i položky před ní.

Streamovací varianta je menšina

Qwen reagoval rychle: návrh visel osm dní a při začlenění mu tým poděkoval s tím, že zrychlení potvrdil. Sluší se ale dodat, o jak velké části uživatelů se to týká. Tři streamovací repozitáře měly za posledních třicet dní 3 768, 469 a 625 stažení, tři generativní 162 655, 59 078 a 26 798. Streamovací podoba tedy dělá 1,9 % stažení celé řady; vlastní výpočet z těch šesti čísel, čtených 28. září 2026.

Na celý případ se dá dívat ještě jednou stranou. Zápis trust_remote_code=True znamená, že se z repozitáře vah spouští cizí program, a obvykle se o tom mluví jako o bezpečnostní otázce. Tady z toho vyšla otázka výkonu – a ten soubor si stálo za to přečíst z obou důvodů.

Zdroje

• Repozitáře Qwen3Guard-Stream-0.6B, 4B a 8B – karty modelu, soubor modeling_qwen3_guard.py a historie revizí
• Návrh změny Fix KV cache reuse in streaming moderation včetně naměřených hodnot a vyjádření týmu Qwenu
• Qwen3Guard Technical Report, arXiv, 16. října 2025
• Repozitář QwenLM/Qwen3Guard a větev support_qwen3_guard v SGLangu
• Počty stažení jsou z rozhraní Hugging Face, čtené 28. září 2026; počty zpracovaných pozic jsou vlastní výpočet z rozměrů měření uvedených v návrhu