A Novita AI új INT4 MoE-kernelt nyílt forráskódúvá tett a Kimi K2.x-hez

A Chord a Kimi K2.x kiszolgálására készült

A Chord egy nagy teljesítményű W4A16 MoE CUDA-operátor BF16 aktivációkhoz, INT4 súlyokhoz és 32-es csoportméretű skálákhoz. A Novita AI a Kimi K2.x modellcsalád kiszolgálási formáira optimalizálta. Az indexed útvonal a Humminggal kompatibilis importgyökeret használja, és kompatibilis vLLM-verziókon a --quantization humming kapcsolóval választható ki.

A vLLM és a Chord integrációja jelenleg nem teljes minden komponens esetében. Az indexed útvonal már használható a meglévő Humming-integráción keresztül, a grouped operátorok vLLM-es bekötése azonban még fejlesztés alatt áll.

Jelentős különbségek a H200 és a B300 méréseiben

A vLLM által közölt számok kernel-szintű mérésekből származnak, ezért nem jelentenek minden munkaterhelésre azonos, végponttól végpontig mérhető gyorsulást. A nyilvános Humming megfelelő útvonalához viszonyítva a Chord H200-on EP8 előfeldolgozásnál 1,11 és 1,20 közötti, TP8 egy példányos kiszolgálásnál pedig 1,17 és 1,33 közötti arányt ért el.

H200 EP8 dekódolásnál az eredmény 1,16 és 1,24 között alakult, a down szakaszban pedig 1,31-es értéket mértek. B300 EP8 dekódolásnál 1,81 és 2,15 közötti eredmény született. Ez az összevetés a Humming alapértelmezett, hangolás nélküli konfigurációjával készült, mivel a nyilvános Humming nem tartalmaz SM100 vagy SM103 hangolási táblát. A H200-as adatok hangolt konfigurációk összehasonlításából származnak.

A grouped útvonal H200 EP8 előfeldolgozásánál 1,00 és 1,31, dekódolásánál 1,16 és 1,35 közötti arányt mértek. A táblázatok EP16 esetében 1,18 és 1,34, EP32 esetében pedig 1,13 és 1,30 közötti értékeket is közölnek.

Két külön kernelcsalád eltérő munkaterhelésekhez

A Chord fő ága két egymástól független kernelcsaládot tartalmaz. Az indexed útvonal a Hummingből származik, és a vLLM rendezett routingtenzorait, köztük a sorted_ids, expert_ids és num_tokens_padded adatokat használja. Ez az útvonal H200 EP8 előfeldolgozást, H200 TP8 egy példányos kiszolgálást, H200 EP8 dekódolást, valamint B200 és B300 EP8 dekódolást fed le.

A második család a DeepGEMM Hopper GEMM-infrastruktúrájára épül. A grouped_contiguous előfeldolgozáshoz, a grouped_masked pedig dekódoláshoz készült, és mindkettő eltérő csomagolt súlyformátumot használ. Ezek a megoldások SM90-es GPU-kra készültek, és EP8, EP16, illetve EP32 konfigurációkat támogatnak.

A fejlesztők szerint egyetlen W4A16 MoE-kernel nem lehet ideális minden kéréshez. A szakértőkhöz irányított tokenek száma jelentősen eltérhet az előfeldolgozás és a dekódolás között, ezért a Chord a ténylegesen kapott alak alapján választ ütemezést. A kód és a kernel-táblázatok a 2026. szeptember 14-i, 7ca91d8 azonosítójú állapotot tükrözik.

Bekapcsolás vLLM-ben

A csomag a Novita AI GitHub-tárából telepíthető, majd a vLLM-ben a meglévő Humming-háttér választható ki. A forrás kifejezetten azt kéri, hogy a Chord telepítése mellett ne telepítsék együtt az inclusionAI/humming csomagot, mert a Chord szándékosan maga kezeli ezt az importnevet.

A megoldás támogatja az uint4 formátumot, a 32-es csoportméretet, a BF16 skálákat, valamint a Kimi K2.x által használt, tömörített INT4 group-32 ellenőrzőpont-formátumot. A nem támogatott kvantálási sémák betöltéskor hibát jeleznek, így a rendszer nem választ csendben nem megfelelő kernelt.

A vLLM automatikus WNA16-prioritása másik hátteret is kiválaszthat, ezért a Hummingot explicit módon kell megadni. A Novita AI szerint a grouped integráció továbbra is fejlesztés alatt áll, így jelenleg az indexed útvonal jelenti a készebb vLLM-es használati módot.