A Kimi K3 saját üzemeltetése 2026. július 27-én vált technikailag lehetségessé, amikor a Moonshot AI közzétette egy 2,8 billió paraméteres modell súlyait éles inferencia-támogatással együtt. Rengeteg szervezet olvasta a hírt, és azt a következtetést vonta le, hogy mostantól csúcskategóriás következtetést futtathat saját hardveren, és abbahagyhatja a tokenenkénti fizetést.

Ez a következtetés általában téves, de nem a várt okból. A mérnöki munka elvégezhető. A számítás az, ami a legtöbb projektet megbuktatja, méghozzá csendben, több hónappal a büdzsé jóváhagyása után.

A rövid válasz: MXFP4 pontosságon 2,8 billió paraméter nagyjából 1,4 TB-ot foglal, még mindenféle kulcs-érték gyorsítótár előtt. Egyetlen nyolcutas H100 csomópont 640 GB-ot tud, tehát ezt a modellt egyáltalán nem képes kiszolgálni. A reális telepítések 1,7 TB VRAM körül kezdődnek, azaz mai generációs, 288 GB-os gyorsítókkal szerelt csomópontok vagy az előző szint tizenhatutas konfigurációi, a Moonshot pedig hatvannégy vagy több gyorsítós fürtök felé irányítja az éles felhasználókat.

Mit adnak valójában a nyílt súlyok

A hardver előtt a licenc, mert az dönti el, érdemes-e mindezt egyáltalán tervezni.

A közzétett súlyok saját licencet viselnek, amelyet a modellkártya Kimi K3 License néven nevez meg. Ez nem egyszerű MIT vagy Apache engedély, és a harmadik felek ilyenként leíró összefoglalóira nem szabad támaszkodni. Olvasd el magad a licencszöveget, és nézesd át, mielőtt kereskedelmi bevezetés mellett köteleznéd el magad, különös figyelemmel a feltüntetési kötelezettségekre és az adott használati nagyságrendeknél életbe lépő feltételekre. Ez egy délutánba kerül, és megspórol egy kellemetlen beszélgetést.

Amit a súlyok valóban megvásárolnak, az az irányítás. Az adataid soha nem hagyják el a környezetedet. Senki nem szünteti meg alattad a modellt, és nem változtat árat. Finomhangolhatsz, tovább kvantálhatsz, vagy úgy módosíthatod a kiszolgálási viselkedést, ahogy egy API sosem engedné. A szuverenitási kötelezettségekkel bíró szervezeteknek éppen ezek a tulajdonságok a lényeg, a költség pedig másodlagos.

Amit nem vásárolnak meg, az egy olcsóbb mód arra, amit az API már megtesz. Ennek a különbségtételnek a tisztázása a leghasznosabb dolog, mielőtt bárki hardvert specifikálna.

Kimi K3 saját üzemeltetés: a hardveres számtan

Kezdd a súlyokkal, és haladj kifelé, mert minden más igény ebből következik.

Kétbillió-nyolcszázmilliárd paraméter négy bittel egyenként nagyjából 1,4 TB-ot tesz ki, és mindennek a gyorsító memóriájában kell lennie, hogy ésszerű sebességgel szolgálja ki a kéréseket. Már ez a szám kizárja azt a konfigurációt, amelyet a legtöbb csapat feltételez. Nyolc H100 kártya 80 GB-tal 640 GB-ot ad, ami kevesebb, mint a súlyok igényének fele.

Aztán jön a kulcs-érték gyorsítótár. Egy milliós kontextust hirdető modellnek tárolnia kell a figyelmi állapotot minden egyidejű kéréshez, és ez a foglalás a kontextushosszal és a köteg méretével együtt nő. A közzétett vLLM metaadatok a minimálisan életképes kiszolgálási igényt nagyjából 1680 GB-ra teszik, ami összhangban van a súlyokkal plusz egy szerény gyorsítótárral, ambiciózus kötegelésre szánt tartalék nélkül.

A gyakorlatban ez néhány alakzat egyikét jelenti. Nyolc mai generációs, egyenként 288 GB-os gyorsító, akár NVIDIA B300, akár AMD MI355X, körülbelül 2,3 TB-ot ad egyetlen csomópontban, és ez a legegyszerűbb megoldás. Tizenhat B200 vagy GB200 osztályú kártya hasonló összeget ér el nagyobb helyigénnyel. Tartós éles átbocsátáshoz és nem koncepcióbizonyításhoz a Moonshot saját ajánlása hatvannégy vagy több gyorsítós supernode konfigurációkra mutat.

Egy részlet nyomatékot érdemel, mert azokat kapja el, akik korábban sűrű modelleket telepítettek. Ez szakértőkeverék architektúra, amely minden tokent 896 szakértőből tizenhathoz irányít, és ez jelentős mindenki-mindenkivel kommunikációt generál a különböző szakértőket tartó eszközök között. Az összeköttetés sávszélessége itt nem kényelmi kérdés. Egy elegendő összmemóriájú, de gyenge összeköttetésű konfiguráció a specifikációban ígértnél sokkal alacsonyabb átbocsátást ad, és ezt vásárlás után diagnosztizálni drága lecke.

Hogyan indítsd el a kiszolgálást

A szoftveroldal letisztultabb, mint egy éve volt, ami segít.

A modellkártya a vLLM-et, az SGLang-ot és a TokenSpeedet sorolja fel támogatott inferencia-motorként. Lényeges, hogy a Kimi Delta Attention támogatása a súlyokkal együtt érkezett, nem később, így egy friss vLLM build tartalmazza az architektúrához szükséges kerneleket. Egy régebbi telepítés nem, és ezt kell elsőként ellenőrizni, ha egy telepítés nem hajlandó elindulni.

A motoron túl tervezd meg a logisztikát. Több mint egy terabájtnyi súlyt töltesz le és tárolsz, tehát biztosíts gyors helyi tárolót, és számíts arra, hogy a kezdeti letöltés és betöltés valós időt vesz igénybe, nem perceket. Korlátozd a kérésenként elfogadott maximális kontextushosszt, mert ha minden hívónak megengedsz egymillió tokent, néhány egyidejű felhasználó kimeríti a gyorsítótár-keretedet. Döntsd el korán, késleltetésre vagy átbocsátásra optimalizálsz-e, mivel az agresszív kötegelés javítja a másodpercenkénti tokenszámot és rontja az első tokenig eltelt időt. Mindkettő nem megy.

Végül kezeld ezt éles infrastruktúraként, ne kutatási telepítésként. Monitorozást, kapacitástervezést, illesztőprogram- és kernelverzió-fegyelmet igényel, és valakit, aki elérhető, amikor leáll. Éppen ez az üzemeltetési teher marad ki leggyakrabban az üzleti indoklásból.

A költség-összehasonlítás, amit senki nem végez el

Íme az a számítás, amely a legtöbb ilyen projektet eldönti, és érdemes a hardveres beszélgetés előtt elvégezni, nem utána.

Egy K3 kiszolgálására alkalmas csomópont bérleti díja széles sávban mozog szolgáltatótól, régiótól és elköteleződéstől függően, de havi 25 000 és 50 000 dollár közötti összeg ésszerű tervezési sáv mai hardverre. A megvásárlás előre lényegesen többe kerül, és csak többéves horizonton van értelme.

Most vesd össze ezt az API-val. Nagyjából millió kimeneti tokenenként 15 dollárral egy havi 30 000 dolláros infrastruktúraszámla kétmilliárd kimeneti tokent vesz a szolgáltatott rendszerben. Havi kétmilliárd kimeneti token nagyjából napi hatvanhatmillió. Ha egy tipikus válasz 1500 token, az nagyjából napi negyvennégyezer válasz, tartósan, mielőtt a saját üzemeltetés pusztán költségalapon megtérülne.

Rosszabb, hogy ez az összehasonlítás feltételezi, hogy a fürtöd éjjel-nappal teljes kihasználtsággal fut. A legtöbb munkaterhelés nem így működik. Munkaidőben tetőzik, éjjel áll, és a tétlen időt pontosan úgy fizeted, mint a hasznosat. A harmincszázalékos tényleges kihasználtság, ami belső eszközöknél gyakori, nagyjából megháromszorozza a tokenenkénti tényleges költséget, és még távolabb tolja a megtérülési pontot.

A következtetés kényelmetlen, de következetes. A szervezetek elsöprő többségének a Kimi K3 saját üzemeltetése többe kerül, mint az API használata. Ha az üzleti indoklás a megtakarításon áll, számold végig ezeket a számokat valós árajánlatokkal és valós mennyiség-előrejelzésekkel, mielőtt bárki megrendelést írna alá.

Mikor helyes döntés valóban a saját üzemeltetés

A költség rossz indok. Ezek a jók.

Szabályozói vagy szerződéses kötelezettségek, amelyek megakadályozzák, hogy adatok elhagyják az infrastruktúrádat, helyetted döntenek, és ezen semmilyen kedvező API-árazás nem változtat. A védelmi szektor, az egészségügy és a pénzügyi szolgáltatások egyes részei rendszeresen ebben a helyzetben vannak, számukra a számítás egyszerűen az, mennyibe kerül a megfelelés.

A valóban magas, tartós volumen megfordítja a számtant. Ha havonta milliárdnyi tokent fogyasztasz egyenletes kihasználtság mellett, a fix költségű modell nyer, és a volumen növekedésével tovább nyer, ahelyett hogy lineárisan együtt nőne vele.

A kiszámíthatóságnak önmagában is értéke van. A telepítés birtoklása azt jelenti: nincs kivezetési értesítés, nincs szerződés közbeni árváltozás, és nincs más kapacitástervezéséből fakadó sebességkorlát. Egy olyan terméknél, amelynek alapfunkciója a modelltől függ, ez a stabilitás önmagában igazolhatja a kiadást.

Végül, ha finomhangolni, a kiszolgálási viselkedést módosítani vagy légrésesen elzárt környezetben futtatni szeretnél, az API semmilyen áron nem segít.

Ezzel szemben légy őszinte azokkal az esetekkel, ahol rossz döntés: ingadozó vagy szerény volumen, GPU-üzemeltetési tapasztalat nélküli csapat, vagy elsősorban költségcsökkentésre épített üzleti indoklás. A Kimi K3 API-ról szóló útmutatónk a szolgáltatott utat tárgyalja, és a legtöbb szervezet számára az ésszerű sorrend az, hogy először az API-ra építenek, és csak akkor költöznek saját infrastruktúrára, amikor a volumen és a követelmények ezt indokolják.

Egy ésszerű középút

Nagyon kevés szervezetnek kell mindent vagy semmit válasz, és a hibrid elrendezés általában a legerősebb.

A forgalom nagy részét irányítsd a szolgáltatott API-ra, ahol csak a felhasználtért fizetsz. A saját üzemeltetésű telepítést tartsd fenn azoknak a konkrét munkaterheléseknek, amelyek olyan adatokat hordoznak, amelyek valóban nem hagyhatják el a környezetedet. Mivel a K3 mindkét út mögött ugyanazt a modellt kínálja, a kéréseket adatbesorolás szerint irányíthatod képesség helyett, és az alkalmazásnak nem kell tudnia, melyik úton ment.

Ez a megközelítés ugyanazt az absztrakciós réteget kívánja, amelyet az OpenAI API-integrációról szóló útmutatónk leír: egy proxyt, amelyé a hitelesítés, az útválasztás és a mérés, hogy a szolgáltató és a helyszín konfiguráció legyen, ne architektúra. Építsd meg egyszer, és mindkét lehetőség nyitva marad.

Tervezd a telepítést olyanokkal, akik már csinálták

A Mecanik MI-integrációs szolgáltatásokat nyújt szolgáltatott, saját üzemeltetésű és hibrid nyelvi modell telepítésekre, beleértve azt a kapacitásmodellezést, amely megmondja, melyiket indokolja ténylegesen a munkaterhelésed.

Elvégezzük a kihasználtsági és megtérülési számítást a valós forgalmadon, őszintén specifikáljuk a hardvert, és megmondjuk, mikor az API a jobb válasz, ami gyakran előfordul. Ahol a saját üzemeltetés indokolt, egyedi szoftverfejlesztési szolgáltatásaink lefedik a kiszolgálási réteget, az útválasztást, a monitorozást és a köré épülő adatbesorolási logikát. A teljes specifikáció a Kimi K3 modellkártyán érhető el.

Kapcsolódó bejegyzések: Létezik igazi MI? A mítoszok és a valóság feltárása , Retrieval-Augmented Generation (RAG) érthetően 2026 , OpenAI ChatGPT 5 vs Grok 4 - Melyik készít jobb Python kódot? , MI-ügynökség vagy házon belüli fejlesztés: UK AI 2026 ., Tiny BPE Trainer – Gyors és könnyű BPE-tréner C++ nyelven

Gyakran ismételt kérdések

Milyen hardver kell a Kimi K3 saját üzemeltetéséhez? MXFP4 pontosságon a súlyok nagyjából 1,4 TB-ot foglalnak, és a reális kiszolgálás a kulcs-érték gyorsítótárral együtt körülbelül 1,7 TB VRAM-ot kíván. Ez kizárja a nyolcutas, 640 GB-os H100 csomópontot, és nyolc mai generációs 288 GB-os gyorsító, előző generációs tizenhatutas konfigurációk vagy éles átbocsátáshoz nagyobb fürtök felé mutat.

Olcsóbb a Kimi K3 saját üzemeltetése az API-nál? Általában nem. Egy megfelelő csomópont nagyjából havi 25 000 és 50 000 dollár között van, ami körülbelül kétmilliárd kimeneti tokent vesz a szolgáltatott API-n. Amíg nem tartod ezt a volument éjjel-nappali magas kihasználtsággal, az API olcsóbb. A saját üzemeltetést az adatszuverenitás és az irányítás indokolja, nem a költség.

Milyen licenc alá esnek a Kimi K3 súlyai? A modellkártya saját licencet nevez meg, a Kimi K3 License-t, nem szokásos MIT vagy Apache engedélyt. Olvasd el közvetlenül a licencszöveget, és kérj jogi átvilágítást kereskedelmi bevezetés előtt, mivel a harmadik felek szabványos nyílt forráskódú licencként leíró összefoglalói nem megbízhatók.

Mely inferencia-motorok támogatják a Kimi K3-at? A modellkártya a vLLM-et, az SGLang-ot és a TokenSpeedet sorolja fel. A Kimi Delta Attention mechanizmus támogatása a súlyokkal együtt érkezett, tehát friss buildre van szükséged, amely tartalmazza ezeket a kerneleket. A régebbi telepítések nem tudják betölteni a modellt.

Futtatható a Kimi K3 egyetlen gépen? Csak csúcskategóriás, több gyorsítós szerveren. Egy nyolc darab 288 GB-os kártyát tartalmazó csomópont elbírja a modellt, de a fogyasztói hardver és az egy GPU-s munkaállomások meg sem közelítik. A szakértőkeverék irányítás miatt ráadásul a gyorsítók közötti összeköttetés sávszélessége is meghatározó tényező az elért átbocsátásban.