Cohere megakerneles kiszolgálót mutatott be a North Mini Code modellhez

Egyetlen tartós kernelre épül a kiszolgálás

A Cohere közlése szerint a legtöbb LLM-kiszolgáló verem ma is egymás után indított kernelek sorozataként kezeli az egyes forward pass lépéseket: külön indul a QKV, az attention, majd például a MoE. A vállalat szerint önmagában minden indítás rendben működik, a várakozási idők viszont különösen kis batchméretnél jelentős részt vehetnek el a dekódolási lépésből.

Az új kiszolgáló motor ezzel szemben dekódolási megakernelt használ. A Cohere leírása alapján ez egyetlen tartós GPU-kernel, amely egy teljes forward passt futtat: a rendszer pontosan egy threadblockot indít streaming multiprocessoronként, és az a teljes dekódolási lépés alatt rezidens marad. A blokkok a meghajtó helyett egy, a hoszton előkészített feladatlistából dolgoznak, az adatfüggőségeket pedig globális memóriában lévő számlálók jelzik.

A vállalat szerint ezzel az ütemezés egysége egy teljes műveletről egy művelet egy csempéjére csökken, a szinkronizáció pedig a teljes GPU helyett azokra a konkrét termelő feladatokra korlátozódik, amelyektől az adott feladat függ.

A szűk keresztmetszet a memória-sávszélesség

A Cohere magyarázata szerint az autoregresszív dekódolás, különösen alacsonyabb batchméreteknél, alapvetően memória-sávszélességhez kötött feladat. A kérdés ezért a cég szerint nem az, hogy mennyi lebegőpontos művelet érhető el, hanem az, mennyire hatékonyan használható a memória-sávszélesség.

A North Mini Code egy 30B modell, amely tokenenként 3,3B aktív paramétert használ. BF16 esetén ez dekódolási lépésenként 6,6 GB súly beolvasását jelenti, ehhez jön a Cohere szerint nagyjából 0,5 GB KV cache 8K kontextusnál. Egy H100 HBM-en keresztül 3,35 TB/s sávszélességet biztosít, ami a vállalat számítása szerint körülbelül 470 tok/s elméleti, úgynevezett Speed-of-Light értéket ad.

A Cohere mérése szerint a vLLM ugyanezt a modellt 185 tok/s sebességgel szolgálja ki, ami az elméleti érték 39 százaléka. A bemutatott megakernel batch size 1 mellett 292 tok/s sebességet ér el, ami az elméleti plafon 62 százaléka, és a cég szerint 1,58-szor gyorsabb, mint a vLLM.

Folyamatos batchkezelés, paged attention és OpenAI-kompatibilis végpont

A Cohere szerint a most bemutatott rendszer nem csak egy batch size 1-re optimalizált demó, hanem teljes kiszolgáló rendszer. Támogatja a folyamatos batchkezelést, a paged attentiont és az eltérő hosszúságú, úgynevezett ragged szekvenciákat, mindezt OpenAI-kompatibilis végpont mögött, tool calling támogatással.

A vállalat azt írja, hogy az OpenCode ráirányítható a végpontra, és így kódolási feladatokra használható. A kiszolgáló motor kódja a Cohere közlése szerint elérhető a GitHubon.

A cég azt is állítja, hogy az előny batchméreteken át és 256K kontextusig megmarad, mérhető pontosságvesztés nélkül. A közlemény szerint a megakernel következetesen felülmúlja a vLLM-et különböző kontextushosszoknál, batch size 1 mellett.

Honnan jön a gyorsulás?

A Cohere három fő okot emel ki a gyorsulás mögött. Az első az indítási és szinkronizációs többlet csökkentése: a hagyományos megközelítésben két egymást követő kernel között minden SM-nek be kell fejeznie a munkát, mielőtt a következő grid indulhatna. Egy sok kis kernelből álló dekódolási lépésnél ezek a rések összeadódnak, míg a megakernel ezt a költséget lépésenként egyszer fizeti meg.

A második a wave quantization csökkentése. A Cohere példája szerint ha egy kernelnek 200 csempényi munkája van, a GPU-n pedig 132 SM található, akkor az első 132 csempe párhuzamosan fut, a maradék 68 egy második hullámban, miközben 64 SM tétlen. Megakernelnél nincs olyan művelethatár, amelyre fel kellene kerekíteni a munkát: egy olyan csempe, amelynek bemenetei készen állnak, elindulhat azon az SM-en, amely éppen felszabadult.

A harmadik előny a hamis függőségek elhagyása. Kernelhatárnál a leglassabb SM diktálja a tempót, még akkor is, ha más SM-ek következő műveletéhez szükséges adatok már memóriában vannak. Finomabb szinkronizációval például egy adott KV csoport O-proj művelete elindulhat, amint az adott csoport attention kimenete elkészült. Hasonlóan, egy MoE down projection feladat elkezdődhet, amikor a megfelelő expert up projection feladata befejeződött.

A Cohere a súlyok előbetöltését is kiemeli. Mivel a súlyok változatlanok, a feladatok már az aktivációs függőség teljesülése előtt elkezdhetik a súlycsempék beolvasását HBM-ből a megosztott memóriába. A vállalat ezt különösen a router és a QKV projekciók esetében használja, a korábbi réteg O-proj műveletének végén.

Mit jelent ez a felhasználóknak és a piacnak?

A bejelentés jelentősége abban áll, hogy a Cohere a megakerneles megközelítést teljes kiszolgáló rendszerként mutatja be, nem X, hanem OpenAI-kompatibilis végponttal, tool callinggal és a szerveroldali működéshez szükséges funkciókkal. A vállalat szerint ez különbözteti meg a megoldást azoktól a munkáktól, amelyek főként automatikus megakernel-generáló fordítókat vagy batch size 1-re mért önálló demókat mutattak be.

A felhasználói oldalról a forrás alapján a legfontosabb állítás a kisebb késleltetéshez és nagyobb dekódolási áteresztőképességhez kapcsolódik, különösen olyan helyzetekben, ahol a dekódolás memória-sávszélességhez kötött. A piac szempontjából a Cohere példája azt jelzi, hogy az LLM-kiszolgálás gyorsításában nemcsak az egyes műveletek külön optimalizálása, hanem a teljes dekódolási lépés ütemezésének átalakítása is fontos irány lehet.