aifeed.skAI Feed
AI modely5 min čítania

Cloudflare zrýchľuje inferenciu modelov Kimi a GLM kompresiou cache a váh

Cloudflare pri modeloch Kimi K2.6 a GLM 5.2 zmenšilo KV cache aj váhy, čím zvýšilo priepustnosť a uvoľnilo pamäť GPU. Výsledky sú sľubné, no pochádzajú z meraní samotného prevádzkovateľa.

Za text zodpovedá Redakcia AI Feed. Zodpovedný editor: Marek Považský. Ako používame AI.

Typ zdroja
Oficiálny zdroj
Zdroj / autorita
Cloudflare

Ako vznikol tento text

Redakcia spracovala verejné podklady do slovenského kontextu. Za výber, pravidlá kvality a prípadné opravy zodpovedá Marek Považský.

Text je zaradený v sekcii AI modely a opiera sa o 3 zdroje. Konkrétne odkazy sú uvedené pod článkom; podrobnosti o AI postupe vysvetľuje metodika redakcie.

Dve odlišné úzke miesta v pamäti GPU

Cloudflare podrobnejšie opísalo, ako v službe Workers AI prevádzkuje veľké modely Kimi K2.6 a GLM 5.2. Oproti pôvodnému súhrnu firma zverejnila konkrétne konfigurácie, priepustnosť, pamäťové úspory aj výsledky testov kvality. Obe rodiny patria medzi veľké modely typu mixture-of-experts s dlhým kontextom. Pri každom tokene síce aktivujú iba časť expertov, ich celkové váhy však zostávajú rozsiahle. K tomu sa pridáva KV cache, ktorá uchováva kľúče a hodnoty pozornosti pre už spracované tokeny. Cloudflare preto optimalizovalo dve rozdielne časti systému: dynamickú cache pri Kimi a statické váhy pri GLM.

KV cache rastie s dĺžkou vstupu, počtom súbežných požiadaviek a architektúrou modelu. Bez nej by model musel pri každom novom tokene opakovane spracovať celú konverzáciu. Pri dlhých dokumentoch, agentických slučkách alebo práci s veľkým repozitárom sa však cache môže stať väčším obmedzením než samotné váhy. Cloudflare uvádza, že zmena reprezentácie cache z 16-bitového formátu BF16 na 8-bitový FP8 vo variante e4m3 pri Kimi K2.6 približne zdvojnásobila množstvo kontextu, ktoré sa zmestí do pamäte: z približne 686-tisíc na 1,37 milióna tokenov v meranej konfigurácii.

Táto úspora neznamená, že každý jednotlivý výpočet je rýchlejší. FP8 jadro musí hodnoty pri čítaní spracovať a pri rovnakej úrovni súbežnosti bolo v meraniach Cloudflare o niekoľko percent pomalšie než BF16. Rozdiel sa prejavil až pri zaplnení GPU. BF16 konfigurácia dosiahla maximum 1 558 tokenov za sekundu pri 32 súbežných požiadavkách a ďalšiu požiadavku už pre nedostatok pamäte neprijala. FP8 zvládlo 64 požiadaviek a 2 192 tokenov za sekundu. To je približne o 41 percent viac než vrchol BF16; Cloudflare zároveň odhaduje asi o 30 percent nižšie náklady na token.

Kompresia sa oplatí inde pri vstupe a inde pri výstupe

Pri GLM 5.2 firma zvolila kompresiu váh z FP8 na štvorbitové celé čísla INT4. Veľkosť checkpointu podľa jej merania klesla zo 705 na 421 GB, teda približne o 40 percent. V nasadení s tensorovým paralelizmom cez osem GPU sa pamäť pripadajúca na jeden akcelerátor znížila asi z 88 na 52 GB. Uvoľnený priestor potom možno použiť na KV cache; Cloudflare uvádza kapacitu približne 1,18 milióna tokenov na rovnakej zostave. Čísla nemožno automaticky prenášať na iné modely alebo hardvér, pretože závisia od architektúry, formátu kvantizácie aj inferenčných jadier.

Dôležitým spresnením je rozdiel medzi fázami prefill a decode. Prefill spracúva celý vstup a býva obmedzený predovšetkým výpočtovým výkonom. Decode generuje nové tokeny postupne a často ho obmedzuje priepustnosť pamäte, pretože váhy treba opakovane načítavať. INT4 preto pomohlo najmä pri decode: pri jedinej požiadavke vzrástla priepustnosť GLM z 60 na 92 tokenov za sekundu a pri 32 požiadavkách z 994 na 1 267. Pri prefille bol výsledok opačný, keďže rozbalenie INT4 pridáva prácu navyše. FP8 dosiahlo približne 10 160 vstupných tokenov za sekundu, INT4 iba 8 660.

Cloudflare tento konflikt rieši oddelenými skupinami GPU pre prefill a decode. Vstupná fáza používa FP8 váhy a BF16 cache, kým dekódovanie využíva INT4 váhy a FP8 cache. Nejde teda o jeden univerzálne najlepší formát, ale o prispôsobenie presnosti konkrétnemu typu záťaže. Túto architektonickú logiku podporuje aj dokumentácia SGLang, inferenčného frameworku použitého v meraniach: rozlišuje online a vopred pripravenú kvantizáciu, viacero hardvérových backendov a výslovne odporúča overiť každý kvantizovaný model benchmarkmi, aby sa zachytil neobvyklý pokles kvality.

Kvalita odpovedí a integrita spoločnej cache

Cloudflare tvrdí, že rozdiely v kvalite zostali v jeho evaluačnej sade malé. Pri FP8 cache pre Kimi sa skóre na GSM8K, ARC, MMLU, MMLU-Pro a teste platnosti volaní nástrojov pohybovalo blízko výsledkov BF16; napríklad MMLU dosiahlo 89,04 oproti 89,11. Pri INT4 váhach GLM zostal rozdiel vo všetkých uvedených testoch do 0,8 bodu oproti FP8. Presnejšie je preto hovoriť o nerozlíšiteľnom výsledku v použitých testoch, nie o dokázanej nulovej strate kvality pri každej úlohe, jazyku a dĺžke kontextu. Časť hodnotenia navyše tvorí interný benchmark Cloudflare, ktorý nezávislá strana nemôže plne reprodukovať iba z článku.

Vyššia hustota požiadaviek prináša aj bezpečnostný problém. Paged attention, priebežné dávkovanie a opätovné používanie cache znamenajú, že mnoho požiadaviek pracuje so stránkami tej istej fyzickej pamäte. Chyba v prideľovaní stránky by mohla spôsobiť poškodený výstup alebo načítanie údajov patriacich inej požiadavke. Cloudflare preto každej stránke cache prideľuje značku, ktorá sa pri novom pridelení zmení. Server pred podporovanými operáciami decode porovná očakávané stránky a značky; pri nezhode požiadavku ukončí namiesto vrátenia potenciálne nesprávnych dát.

Firma namerala pri tejto kontrole menej než jednopercentnú zmenu priepustnosti aj p95 latencie v testovanej konfigurácii s 8 192 vstupnými a 1 000 výstupnými tokenmi. Overovanie vykonáva ako samostatnú dávkovú kontrolu, nie priamo v jadre pozornosti, kde by podľa nej mohli vzniknúť preteky medzi skupinami GPU vlákien. Ide o dôležitý posun oproti chápaniu kvantizácie iba ako úspory nákladov: čím viac relácií zdieľa jeden akcelerátor, tým dôležitejšia je izolácia ich medzivýsledkov. Zverejnený mechanizmus však nie je náhradou nezávislého bezpečnostného auditu ani dôkazom, že pokrýva všetky možné cesty práce s cache.

Čo to znamená pre európskych používateľov

Pre slovenské a európske firmy môže menšia pamäťová stopa znížiť cenu obsluhy dlhých dokumentov, programátorských agentov či interného vyhľadávania. Vyššia súbežnosť zároveň uľahčuje poskytovanie veľkých otvorených modelov bez vyhradeného GPU pre každého zákazníka. Samotná optimalizácia však nehovorí nič o umiestnení spracovania, právnom základe pre osobné údaje ani o zmluvných zárukách. Organizácia musí osobitne preveriť dátové toky, uchovávanie vstupov, región inferencie a subdodávateľov. Pri citlivom nasadení treba testovať aj slovenčinu, presné kopírovanie údajov a dlhé kontexty, ktoré všeobecné anglické benchmarky nemusia dostatočne pokryť.

Otvorenou otázkou zostáva reprodukovateľnosť deklarovaných ekonomických výsledkov. Cloudflare zverejnilo hardvér H200 pri teste Kimi, úrovne súbežnosti a viacero skóre, ale neposkytlo kompletný nezávislý experiment pokrývajúci všetky produkčné podmienky. SGLang je verejne dostupný a jeho výskumná práca opisuje RadixAttention, opätovné používanie KV cache a vysokopriepustné vykonávanie štruktúrovaných programov, čo umožňuje overiť všeobecný technický základ. Konkrétne tvrdenia o 41-percentnom zvýšení špičkovej priepustnosti, 30-percentnom poklese nákladov a zachovaní kvality však zatiaľ zostávajú výsledkami prevádzkovateľa. Najsilnejším záverom preto nie je, že INT4 alebo FP8 sú bezpodmienečne lepšie, ale že oddelené ladenie vstupu, dekódovania a integrity cache môže výrazne zmeniť ekonomiku inferencie bez viditeľného poklesu vo zverejnenej sade testov.

Zdroje

Súvisiace čítanie

Ďalšie články k téme

Viac z kategórie