Kimi K3 sa dá nasadiť na AWS, no potrebuje osem GPU Blackwell Ultra

Moonshot AI sprístupnilo váhy modelu Kimi K3, no otvorený prístup k modelu ešte neznamená jednoduché nasadenie. AWS teraz zverejnilo technický postup pre dve cesty: riadený klaster SageMaker HyperPod s orchestráciou cez Amazon EKS alebo samostatný klaster EKS. Súčasťou materiálu sú konfiguračné súbory a recepty na GitHube, takže nejde iba o produktové oznámenie, ale o konkrétny základ pre tímy, ktoré chcú model prevádzkovať vo vlastnom cloudovom prostredí.

Kimi K3 má podľa dokumentácie 2,8 bilióna parametrov rozdelených medzi 896 špecializovaných expertov. Pri každom tokene sa aktivuje iba 16 expertov, takže jeden dopredný prechod používa približne 104 miliárd parametrov. Ide o architektúru mixture-of-experts: celková kapacita je obrovská, ale výpočet sa smeruje len do časti siete. Model používa aj Kimi Delta Attention, latentnú pozornosť MLA a rámec Stable LatentMoE.

Parametre sú distribuované vo formáte MXFP4, ktorý znižuje pamäťové a prenosové nároky pri inferencii. Ani štvorbitová reprezentácia však z Kimi K3 nerobí model pre bežný server. AWS uvádza inštanciu ml.p6-b300.48xlarge s ôsmimi GPU NVIDIA B300 Blackwell Ultra a vysokorýchlostným prepojením. Táto požiadavka je dôležitým korektívom k zjednodušenému tvrdeniu, že verejné váhy automaticky prinášajú lacnú lokálnu AI.

Na obsluhu modelu sa používa vLLM s podporou paralelizácie, expertových architektúr a kvantizácie MXFP4. V čase zverejnenia návodu sa podpora Kimi K3 nachádzala v špeciálnom obraze pripravenom na prvý deň nasadenia a príslušné zmeny ešte čakali na zlúčenie do hlavného kontajnera vLLM. Prevádzkovatelia preto musia sledovať konkrétnu verziu obrazu a nemali by bez overenia predpokladať, že ľubovoľná stabilná verzia vLLM model načíta.

Cesta cez SageMaker HyperPod je určená tímom, ktoré chcú spravovaný základ pre veľký akcelerátorový klaster, rezerváciu kapacity a integráciu s nástrojmi AWS. Druhá cesta používa EKS a dáva väčšiu kontrolu nad Kubernetes vrstvou. AWS pre obe zverejnilo vzorové súbory: konfiguráciu nasadenia pre HyperPod aj recept a hodnoty chartu pre inferenciu na EKS. Tieto artefakty uľahčujú reprodukciu, no stále vyžadujú skúsenosti s GPU plánovaním, sieťou a observabilitou.

Pre podniky je hlavnou výhodou možnosť držať model a spracúvané dáta vo vlastnom účte, nastavovať sieťové hranice a prispôsobiť škálovanie požiadavkám služby. To môže byť dôležité pri internom kóde, citlivých dokumentoch alebo regulovaných pracovných postupoch. Samostatné hostovanie však presúva na prevádzkovateľa zodpovednosť za aktualizácie kontajnerov, bezpečnostné opravy, kapacitné plánovanie, zlyhania uzlov a meranie kvality po každej zmene.

Ekonomika bude závisieť od vyťaženia. Osem špičkových GPU je opodstatnených pri trvalom objeme požiadaviek, dlhom kontexte alebo potrebe viacerých súbežných agentov, no pri prerušovanej prevádzke môže byť spravované API lacnejšie. Tím by mal pred rezervovaním kapacity zmerať počet tokenov, latenciu, využitie pamäte, dávkovanie a reálnu aktiváciu expertov. Dôležitý je aj čas štartu a dostupnosť konkrétneho typu inštancie v zvolenom regióne.

Miliónové kontextové okno a natívna práca s textom a obrazom rozširujú možné použitia, ale zároveň zvyšujú prevádzkové riziká. Dlhý vstup môže vyčerpať pamäť, zvýšiť latenciu a otvoriť priestor pre neoverený obsah v agentických pracovných tokoch. Produkčná vrstva preto potrebuje limity vstupu, kvóty, izoláciu nájomníkov, sledovanie chýb nástrojov a testy, ktoré porovnajú kvalitu odpovedí pri rôznych dĺžkach kontextu.

Zverejnený návod je významný najmä tým, že ukazuje úplnú infraštruktúrnu stopu moderného otvoreného modelu. Kimi K3 možno kontrolovať a hostovať samostatne, no táto sloboda prichádza s hardvérovým a operačným záväzkom. Pre organizácie, ktoré potrebujú dátovú suverenitu a majú stabilné vysoké využitie, ide o reálnu alternatívu. Pre ostatné je dokumentácia užitočným podkladom na presný výpočet, či sa vlastná prevádzka naozaj oplatí.