Self-host di Kimi K3 al day 0: percorso vLLM vs mito Ollama sul laptop

Hub Kimi K3: Specs, prezzi, id API → /kimi-k3. Timeline → /kimi-k3-status. Realtà Ollama/VRAM → /blog/34-kimi-k3-vram-ollama-local-requirements. Calendario open-weights → /blog/31-kimi-k3-open-weights-july-27.

Il feed dice pesi open di Kimi K3 il 27 luglio. Qualcuno risponde con uno screenshot del Mac Mini. Qualcun altro incolla un GGUF misterioso «Ollama one-click». Tu intanto cerchi di rispondere a una domanda più semplice: il mio team può self-hostare questo, o è solo hype?

Versione breve: tratta il self-host come un problema da cluster / vLLM, non da app di chat sul laptop. Prodotto e API sono già live. I pesi pubblici completi restano un evento da calendario da ricontrollare su Hugging Face—non una garanzia che ollama pull funzioni stasera.

Questo sito è indipendente da Moonshot. Specs e date sotto seguono doc pubbliche e blog partner al 27 luglio 2026; ricontrolla il blog Kimi K3, le doc della platform e la preview K3 di vLLM prima di comprare ferro o fidarti di un repo a caso.

Risposta breve (leggi prima questa)

1. Due lavori diversi.
   • «Voglio la qualità K3 già oggi» → kimi.com, Kimi Code, o id API kimi-k3 su platform.kimi.ai.
   • «Voglio i pesi nella mia VPC» → aspetta un repo HF di proprietà Moonshot con file reali + uno stack di serving day-0 (vLLM è il percorso pubblico che Moonshot e i partner stanno preparando).
2. Al momento in cui scriviamo, HF moonshotai/Kimi-K3 è ancora una pagina Upcoming release (countdown / notify)—non un download finito con safetensors. I post social che dicono «già open» di solito leggono la promessa, non la tab Files.
3. Ollama su una sola GPU gaming è il modello mentale sbagliato per il K3 pieno di classe 2.8T. Il linguaggio ufficiale di serving punta a deploy supernode / multi-acceleratore, non a un giocattolo da 24GB.
4. La preview vLLM del 22 luglio è la nota pubblica migliore su «come l’industria servirà questo»: path del modello day-0, prefix caching KDA-aware, ricette Docker, lavoro NVIDIA + AMD iniziale—non una one-liner da consumer.
5. Le linee open Kimi già scaricabili (es. K2.6 / K2.7 Code su Hugging Face) sono ciò che puoi self-hostare oggi se ti servono pesi offline mentre i file K3 sono ancora in attesa.

Una frase: usa API o prodotto per l’intelligenza questa settimana; usa vLLM + pesi reali per il self-host quando la tab Files è vera—non confondere quelle due porte.

Fonte: Messaging ufficiale di lancio K3 / tech blog Kimi K3, Moonshot AI, 16 luglio 2026.

A chi serve questa guida (e a chi no)

Se hai cercato solo «kimi k3 ollama», leggi anche il nostro post VRAM & Ollama—quella pagina è l’honesty check sull’hardware locale. Questa pagina è il percorso self-host / serving.

Cosa significa davvero «open weights day 0»

La storia pubblica di Moonshot (vedi l’annuncio K3):

• Prodotto + API prima (live da ~16 luglio 2026): chat, Work, Code, API kimi-k3.
• Pesi completi del modello entro il 27 luglio 2026—un impegno a spedire i file, non una magia «già su ogni mirror».
• Architettura che cambia il serving: Kimi Delta Attention (KDA), Attention Residuals, MoE sparso (framing ufficiale: 16 di 896 expert attivi per token), ~2.8T di parametri totali, contesto 1M, vision nativa.
• Nota esplicita che hanno contribuito lavoro di prefix-cache legato a KDA alla community vLLM, da rilasciare insieme al modello—perché KDA non si comporta come la classica KV cache a full-attention.

Quindi il «day 0» per chi self-hosta è davvero due drop:

1. Pesi + LICENSE + model card (di solito Hugging Face sotto moonshotai/…).
2. Codice di serving che capisce K3 (la preview vLLM punta a path del modello, parser, kernel, Docker, ricette).

Uno senza l’altro è una porta mezzo aperta.

Percorso A — Prodotto e API (cosa aprire oggi la maggior parte delle persone)

Non ti serve il self-host per provare la qualità frontier di K3:

Se l’obiettivo è «spedire una feature in questo sprint», vincono API + prodotto. Il self-host è per residenza dati, air-gap, fine-tune custom o unit economics a volume enorme—non per FOMO.

Fonte: Media ufficiali di lancio K3 / blog Kimi K3, 16 luglio 2026.

Percorso B — Self-host via vLLM (il day-0 serio)

Cosa ha promesso vLLM in pubblico (22 luglio 2026)

La preview del team vLLM è il post più chiaro di «prontezza ecosystem» che abbiamo prima del giorno full open-source. In linguaggio piano, dicono di stare preparando:

• Serving open-source day-0 per il rilascio dei pesi: implementazione del modello, immagini Docker, ricette di deploy, validazione in produzione
• Prefix caching KDA-aware (i classici trucchi di paged KV non bastano per lo stato ricorrente di KDA)
• Lavoro su kernel / performance su prefill & decode KDA, Attention Residuals, MoE (path MXFP4 nel loro framing di release), pezzi multimodali
• Ricette NVIDIA in affinamento finale + un path AMD iniziale

Questo è linguaggio da infra. Non è «incolla questo in Ollama su Windows e chatta».

Come pensare al serving day-0 (checklist, non una CLI congelata)

Quando i pesi compaiono, un runbook di self-host sano assomiglia a questo—preferisci sempre model card ufficiale e doc vLLM a qualsiasi blog, incluso questo:

1. Verifica il repo
   • L’org dovrebbe essere moonshotai (o un’altra fonte che Moonshot linka dal blog ufficiale).
   • Files reali (shard), non solo marketing «Upcoming release».
   • LICENSE letta da cima a fondo (le linee open Kimi precedenti usavano spesso una licenza stile Modified MIT; non assumere K3 finché il file non esce).
2. Fissa un build di serving che dichiari supporto K3 / KDA
   • Segui il post di vLLM e la versione che taggano per day-0—i branch nightly/main si muovono.
   • Aspettati parser tool-call / reasoning e flag multimodali specifici Kimi, simili alle ricette della famiglia K2 precedente.
3. Pianifica il parallelismo come un MoE gigante
   • Un MoE sparso di classe 2.8T parla di expert parallelism + bandwidth, non di un esperimento tensor-parallel-size 1.
   • Le doc di prodotto ufficiali hanno puntato a serving multi-acceleratore stile supernode per throughput competitivo—leggilo come forma da datacenter.
4. Sii umile sul contesto 1M
   • Il «1M flat» dell’API cloud non è la stessa cosa di «metto --max-model-len 1048576 al day one e vola».
   • Parti con una max length più corta, misura prefill/decode, poi allunga.
5. Separa «pesi su disco» da «SLO di produzione»
   • Day-0 spesso significa si avvia. Produzione significa monitoring, PD disaggregation, cache hit rate, failure domain—il post di vLLM parla esplicitamente di quelle parti dure.

Non incolleremo una riga vllm serve … copia-incolla con flag inventati come se fosse benedetta. I flag sbagliati marciscono in ore; model card + note di release vLLM sono la fonte di verità il giorno in cui i file atterrano.

Realtà hardware (senza inventare una tabella GB fasulla)

La gente vuole: «K3 Q4 = XX GB su una 4090.»

Non inventeremo quella tabella.

Cosa puoi tenere a mente:

• Scala totale (~2.8T) e attivazione sparsa (framing 16/896) non equivalgono a «il laptop tiene tutti i parametri». Devi comunque memorizzare un’impronta di pesi enorme; attivi solo un sottoinsieme per token.
• Le stime community sulla size del download dei pesi finiscono spesso nella fascia centinaia di GB fino a ~1+ TB a seconda della storia di quant (MXFP4 vs precisione più alta)—trattale come non ufficiali finché la model card non elenca le size dei file.
• Il linguaggio Moonshot su 64+ acceleratori / stile supernode è una forma di serving, non una nota a piè di pagina da hobby.
• Se non fai già girare cluster GPU multi-nodo (o non compri inference gestita), API o un host managed batteranno un weekend eroico di build per la maggior parte dei team.

Per timeline Ollama/GGUF e «posso farlo girare in locale già?», resta sulla guida VRAM.

Fonte: Media ufficiali di lancio K3 / blog Kimi K3, 16 luglio 2026.

Percorso C — Il mito Ollama / «Mac Mini» (ucciderlo con garbo)

La domanda di ricerca su ollama, gguf, local, self host è reale. L’errore è impilarli in un’unica fantasia:

Percorso locale sano mentre aspetti: self-hosta K2.6 / K2.7 Code (già su HF) per agent di coding offline; usa K3 via API per i job duri. Gli stack ibridi battono le gare di purezza.

Checklist del giorno (quando la cella del calendario scatta)

Usala quando qualcosa compare davvero—non quando un repost dice «dropping».

Pesi

• Blog/X ufficiale o pagina HF passa da Upcoming a Files scaricabili
• Repo sotto moonshotai (o chiaramente linkato da kimi.com/blog/kimi-k3)
• LICENSE + model card + size degli shard elencate
• Nessuna dipendenza da un «Kimi-K3-abliterated» di terze parti a caso come unica copia

Serving

• vLLM (o altro engine che Moonshot nomina) versione / immagine che documenta K3
• Parser tool-call / reasoning allineati alla card
• Piano di parallelismo rivisto da qualcuno che ha già fatto girare MoE grandi
• Smoke test: health endpoint, prompt corto, una tool call, un prefill long-context

Business

• Albero decisionale: API di default vs pilot self-host vs host managed
• Security: controllo accessi ai pesi, eval su allucinazioni / tool safety, non «open = deploy in prod la stessa sera»

Cosa fare questa settimana (albero decisionale)

Se ti serve qualità K3 prima di pranzo
→ Prodotto o API. Non bloccarti sui pesi.

Se stai costruendo un pilot self-host
→ Leggi la preview K3 di vLLM; prenota capacità di cluster; abbozza la checklist sopra; esercitati sui pesi K2.6 / K2.7 Code così la pipeline è noiosa quando atterrano i file K3.

Se hai solo un laptop gaming
→ Goditi K3 nel prodotto/API cloud. Usa modelli open più piccoli in locale. Ignora le thumbnail «K3 pieno su 24GB».

Se il team compliance serve open weights
→ Segna HF moonshotai/Kimi-K3 e il blog ufficiale; nessun design di produzione finché LICENSE + file non sono reali.

Attenzioni (filtro rumore)

1. Data promessa ≠ tab Files. Il 27 luglio è il target pubblico di Moonshot; verifica gli artefatti.
2. Thread di allucinazioni / benchmark indipendenti sui social variano—non incollare % di terze parti nel runbook come «ufficiali».
3. Le keyword di architettura (KDA, AttnRes, MXFP4) sono engineering reale; non sono prova che i runtime consumer esistano al day one.
4. Questo sito non è il supporto Moonshot. Nel dubbio, vincono le doc ufficiali.

Dove andare dopo

• Hub status: /kimi-k3-status · hub prodotto: /kimi-k3
• Calendario open-weights: /blog/31-kimi-k3-open-weights-july-27
• Onestà locale / Ollama: /blog/34-kimi-k3-vram-ollama-local-requirements
• Porte free: /blog/33-kimi-k3-free-how-to · come usare: /blog/36-how-to-use-kimi-k3
• Controllo bolletta: /blog/37-kimi-k3-api-pricing-cost-control
• Ufficiale: blog Kimi K3 · preview K3 vLLM · HF moonshotai

In sintesi: self-hostare Kimi K3 è un progetto di serving serio (vLLM + realtà multi-acceleratore), non un trucco da festa Ollama. Usa le porte cloud finché la pagina Upcoming è ancora Upcoming—e quando la tab Files diventa vera, verifica org, licenza e stack prima di fidarti di qualsiasi download.