Self-host Kimi K3 jour 0 : vLLM sérieux vs mythe Ollama laptop

Hub Kimi K3 : Specs, tarifs, id API → /kimi-k3. Timeline → /kimi-k3-status. Réalité Ollama/VRAM → /blog/34-kimi-k3-vram-ollama-local-requirements. Calendrier open weights → /blog/31-kimi-k3-open-weights-july-27.

Ton fil dit poids open Kimi K3 le 27 juillet. Quelqu’un poste une capture de Mac Mini. Un autre colle un GGUF mystérieux « Ollama en un clic ». Toi, tu cherches juste à répondre : mon équipe peut-elle self-hoster ça, ou c’est du hype ?

Version courte : traite le self-host comme un problème cluster / vLLM, pas comme une appli de chat sur laptop. Produit et API sont déjà live. Les poids publics complets restent un événement calendaire à revérifier sur Hugging Face — pas une garantie que ollama pull marche ce soir.

Ce site est indépendant de Moonshot. Specs et dates ci-dessous collent à la doc publique et aux blogs partenaires au 27 juillet 2026 ; revérifie le blog Kimi K3, la doc plateforme et le preview K3 de vLLM avant d’acheter du fer ou de faire confiance à un repo random.

Réponse courte (lis ça d’abord)

1. Deux jobs différents.
   • « Je veux la qualité K3 aujourd’hui » → kimi.com, Kimi Code, ou l’id API kimi-k3 sur platform.kimi.ai.
   • « Je veux les poids dans mon VPC » → attendre un repo HF tenu par Moonshot avec de vrais fichiers + une stack de serving jour 0 (vLLM est le chemin public que Moonshot et les partenaires préparent).
2. Au moment où on écrit, HF moonshotai/Kimi-K3 est encore une page Upcoming release (compte à rebours / notify) — pas un téléchargement fini avec safetensors. Les posts qui crient « déjà open » lisent en général la promesse, pas l’onglet Files.
3. Ollama sur une seule carte gaming, c’est le mauvais modèle mental pour un K3 complet classe 2,8T. Le langage officiel de serving pointe vers un déploiement supernode / multi-accélérateurs, pas un jouet 24 Go.
4. Le preview vLLM du 22 juillet est la meilleure note publique « comment l’industrie va servir ça » : chemin modèle jour 0, prefix caching conscient de KDA, recettes Docker, travail NVIDIA + amorce AMD — pas une one-liner grand public.
5. Les lignes Kimi open déjà téléchargeables (ex. K2.6 / K2.7 Code sur Hugging Face) sont ce que tu peux self-hoster aujourd’hui si tu as besoin de poids offline tant que les fichiers K3 sont encore en attente.

En une phrase : API ou produit pour l’intelligence cette semaine ; vLLM + vrais poids pour le self-host quand l’onglet Files est réel — ne confonds pas ces deux portes.

Source : messaging de lancement officiel K3 / blog tech Kimi K3, Moonshot AI, 16 juillet 2026.

À qui s’adresse ce guide (et à qui non)

Si ta seule requête était « kimi k3 ollama », lis aussi notre post VRAM & Ollama — c’est le check d’honnêteté hardware local. Cette page, c’est le chemin self-host / serving.

Ce que « open weights jour 0 » veut vraiment dire

Le récit public de Moonshot (voir l’annonce K3) :

• Produit + API d’abord (live depuis ~16 juillet 2026) : chat, Work, Code, API kimi-k3.
• Poids complets du modèle d’ici le 27 juillet 2026 — un engagement à livrer des fichiers, pas une magie « déjà sur tous les miroirs ».
• Une archi qui change le serving : Kimi Delta Attention (KDA), Attention Residuals, MoE sparse (framing officiel : 16 experts actifs sur 896 par token), ~2,8T params totaux, contexte 1M, vision native.
• Note explicite : ils ont contribué du travail de prefix-cache lié à KDA à la communauté vLLM, pour une sortie en même temps que le modèle — parce que KDA ne se comporte pas comme un KV cache full-attention classique.

Donc le « jour 0 » pour les self-hosters, c’est vraiment deux drops :

1. Poids + LICENSE + model card (en général Hugging Face sous moonshotai/…).
2. Code de serving qui comprend K3 (le preview vLLM pointe vers le chemin modèle, parsers, kernels, Docker, recettes).

L’un sans l’autre, c’est une porte à moitié ouverte.

Chemin A — Produit & API (ce que la plupart devraient ouvrir aujourd’hui)

Tu n’as pas besoin du self-host pour sentir la qualité frontier de K3 :

Si ton but est « shipper une feature ce sprint », API + produit gagnent. Le self-host, c’est pour la résidence des données, l’air-gap, le fine-tune custom, ou l’économie d’échelle à très gros volume — pas pour le FOMO.

Source : médias de lancement officiels K3 / blog Kimi K3, 16 juillet 2026.

Chemin B — Self-host via vLLM (le vrai chemin jour 0)

Ce que vLLM a promis publiquement (22 juillet 2026)

Le preview de l’équipe vLLM est le post « readiness écosystème » le plus clair qu’on a avant le jour open-source complet. En clair, ils disent préparer :

• Serving open-source jour 0 pour la sortie des poids : implémentation modèle, images Docker, recettes de déploiement, validation prod
• Prefix caching conscient de KDA (les trucs paged KV classiques ne suffisent pas pour l’état récurrent KDA)
• Travail kernels / perf sur prefill & decode KDA, Attention Residuals, MoE (chemin MXFP4 dans leur framing de release), pièces multimodales
• Recettes NVIDIA en fin de réglage + un chemin AMD initial

C’est du langage d’infra. Ce n’est pas « colle ça dans Ollama sous Windows et discute ».

Comment penser le serving jour 0 (checklist, pas une CLI figée)

Quand les poids apparaissent, un runbook self-host sain ressemble à ça — préfère toujours la model card officielle et la doc vLLM à n’importe quel blog, y compris celui-ci :

1. Vérifie le repo
   • L’org doit être moonshotai (ou une autre source que Moonshot lie depuis le blog officiel).
   • De vrais Files (shards), pas seulement du marketing « Upcoming release ».
   • LICENSE lue de bout en bout (les lignes open Kimi précédentes utilisaient souvent une licence type Modified MIT ; ne présume pas pour K3 tant que le fichier n’est pas sorti).
2. Épingle un build de serving qui revendique le support K3 / KDA
   • Suis le post vLLM et la version qu’ils taguent pour le jour 0 — les branches nightly/main bougent.
   • Attends-toi à des parsers tool-call / reasoning et des flags multimodaux spécifiques à Kimi, comme sur les recettes de la famille K2.
3. Planifie le parallélisme comme un géant MoE
   • Un MoE sparse classe 2,8T, c’est de l’expert parallelism + bande passante, pas une expérience tensor-parallel-size 1.
   • La doc produit a pointé vers un serving multi-accélérateurs style supernode pour un throughput compétitif — lis ça comme forme datacenter.
4. Reste humble sur le contexte 1M
   • Le « 1M plat » de l’API cloud n’est pas la même chose que « j’ai mis --max-model-len 1048576 le jour un et ça vole ».
   • Commence avec une longueur max plus courte, mesure prefill/decode, puis étire.
5. Sépare « poids sur disque » et « SLO de prod »
   • Jour 0 veut souvent dire ça boot. La prod, c’est monitoring, désagrégation PD, taux de cache hit, domaines de panne — le post vLLM parle explicitement de ces parties dures.

On ne collera pas ici une ligne vllm serve … copier-coller avec des flags inventés comme si c’était béni. Les mauvais flags pourrissent en quelques heures ; la model card + les release notes vLLM sont la source de vérité le jour où les fichiers atterrissent.

Réalité hardware (sans inventer un faux tableau en Go)

Les gens veulent : « K3 Q4 = XX Go sur une 4090. »

On n’inventera pas ce tableau.

Ce que tu peux retenir :

• L’échelle totale (~2,8T) et l’activation sparse (framing 16/896) ne veulent pas dire « le laptop tient les params totaux ». Tu stockes toujours une empreinte de poids énorme ; tu n’actives qu’un sous-ensemble par token.
• Les estimations communautaires de taille de download tombent souvent dans la bande centaines de Go à ~1+ To selon l’histoire de quant (MXFP4 vs précision plus haute) — traite tout chiffre comme non officiel tant que la model card n’liste pas les tailles de fichiers.
• Le langage Moonshot 64+ accélérateurs / style supernode est une forme de serving, pas une note de bas de page hobby.
• Si tu ne fais pas déjà tourner des clusters GPU multi-nœuds (ou acheter de l’inférence managée), l’API ou un host managé battra un weekend héroïque pour la plupart des équipes.

Pour les timelines Ollama/GGUF et « est-ce que je peux le lancer en local déjà », reste sur le guide VRAM.

Source : médias de lancement officiels K3 / blog Kimi K3, 16 juillet 2026.

Chemin C — Le mythe Ollama / « Mac Mini » (le tuer poliment)

La demande de recherche pour ollama, gguf, local, self host est réelle. L’erreur, c’est de les empiler en un seul fantasme :

Chemin local sain en attendant : self-host K2.6 / K2.7 Code (déjà sur HF) pour des agents coding offline ; utilise K3 via API pour les jobs durs. Les stacks hybrides battent les concours de pureté.

Checklist du jour J (quand la case calendrier tombe vraiment)

Utilise ça quand quelque chose apparaît vraiment — pas quand un repost dit « ça drop ».

Poids

• Blog/X officiel ou page HF passe d’Upcoming à des Files téléchargeables
• Repo sous moonshotai (ou clairement lié depuis kimi.com/blog/kimi-k3)
• LICENSE + model card + tailles de shards listées
• Pas de dépendance à un random « Kimi-K3-abliterated » tiers comme seule copie

Serving

• vLLM (ou autre moteur nommé par Moonshot) version / image qui documente K3
• Parsers tool-call / reasoning alignés avec la card
• Plan de parallélisme relu par quelqu’un qui a déjà fait tourner un gros MoE
• Smoke test : endpoint health, prompt court, un tool call, un prefill long contexte

Business

• Arbre de décision : API par défaut vs pilote self-host vs host managé
• Sécu : contrôle d’accès aux poids, eval hallucination / sécurité tools — pas « open = prod le soir même »

Que faire cette semaine (arbre de décision)

Si tu as besoin de la qualité K3 avant le déjeuner
→ Produit ou API. Ne bloque pas sur les poids.

Si tu montes un pilote self-host
→ Lis le preview K3 de vLLM ; réserve de la capacité cluster ; rédige la checklist ci-dessus ; entraîne-toi sur les poids K2.6 / K2.7 Code pour que la pipeline soit ennuyeuse le jour où les fichiers K3 arrivent.

Si tu n’as qu’un laptop gaming
→ Profite de K3 via le produit/API cloud. Utilise des modèles open plus petits en local. Ignore les miniatures « full K3 sur 24 Go ».

Si la compliance exige des open weights
→ Mets en favori HF moonshotai/Kimi-K3 et le blog officiel ; aucun design de prod tant que LICENSE + fichiers ne sont pas réels.

Points de vigilance (filtre à bruit)

1. Date promise ≠ onglet Files. Le 27 juillet est la cible publique de Moonshot ; vérifie les artefacts.
2. Threads hallucination / benches indépendants sur les réseaux varient — ne colle pas des % tiers dans ton runbook comme « officiel ».
3. Les mots-clés d’archi (KDA, AttnRes, MXFP4) sont de la vraie ingénierie ; ils ne prouvent pas que des runtimes grand public existent le jour un.
4. Ce site n’est pas le support Moonshot. En cas de doute, la doc officielle gagne.

Suite

• Hub statut : /kimi-k3-status · hub produit : /kimi-k3
• Calendrier open weights : /blog/31-kimi-k3-open-weights-july-27
• Honnêteté local / Ollama : /blog/34-kimi-k3-vram-ollama-local-requirements
• Portes d’essai gratuit : /blog/33-kimi-k3-free-how-to · comment utiliser : /blog/36-how-to-use-kimi-k3
• Maîtrise de facture : /blog/37-kimi-k3-api-pricing-cost-control
• Officiel : blog Kimi K3 · preview vLLM K3 · HF moonshotai

En bas de ligne : self-hoster Kimi K3, c’est un vrai projet de serving (vLLM + réalité multi-accélérateurs), pas un tour de passe-passe Ollama. Utilise les portes cloud tant que la page Upcoming est encore Upcoming — et quand l’onglet Files devient réel, vérifie org, licence et stack avant de faire confiance à un download.