Self-host Kimi K3 no dia 0: caminho vLLM vs mito do Ollama no notebook

Hub Kimi K3: Specs, preço, id da API → /kimi-k3. Timeline → /kimi-k3-status. Realidade Ollama/VRAM → /blog/34-kimi-k3-vram-ollama-local-requirements. Calendário de open weights → /blog/31-kimi-k3-open-weights-july-27.

Seu feed grita pesos open do Kimi K3 em 27 de julho. Alguém manda print de Mac Mini. Outro cola um GGUF misterioso de “Ollama em um clique.” Enquanto isso você só precisa responder uma pergunta bem mais simples: dá pra o time self-hostar isso de verdade, ou é só hype?

Versão curta: trate self-host como problema de cluster / vLLM, não como app de chat no notebook. Produto e API já estão no ar. Os pesos públicos completos ainda são um evento de calendário que você revalida no Hugging Face—não uma garantia de que ollama pull funciona hoje à noite.

Este site é independente da Moonshot. Specs e datas abaixo acompanham docs públicos e blogs de parceiros em 27 de julho de 2026; confira de novo o blog do Kimi K3, a documentação da platform e o preview do vLLM para o K3 antes de comprar ferro ou confiar em repo aleatório.

Resposta curta (leia isto primeiro)

1. Dois trabalhos diferentes.
   • “Quero qualidade K3 hoje” → kimi.com, Kimi Code ou o id de API kimi-k3 em platform.kimi.ai.
   • “Quero os pesos na minha VPC” → espere um repo HF da Moonshot com arquivos de verdade + uma stack de serving day-0 (vLLM é o caminho público que Moonshot e parceiros estão preparando).
2. Nesta data, o HF moonshotai/Kimi-K3 ainda é página de Upcoming release (countdown / notify)—não um download pronto com safetensors. Posts dizendo “já está open” em geral leem a promessa, não a aba Files.
3. Ollama em uma única GPU gamer é o modelo mental errado para o K3 completo classe 2.8T. A linguagem oficial de serving aponta para deploy supernode / multi-acelerador, não brinquedo de 24GB.
4. O preview do vLLM de 22 de julho é a melhor nota pública de “como a indústria vai servir isso”: path de modelo day-0, prefix caching ciente de KDA, receitas Docker, NVIDIA + trabalho inicial em AMD—não um one-liner de consumidor.
5. Linhas Kimi open já baixáveis (ex.: K2.6 / K2.7 Code no Hugging Face) são o que você consegue self-hostar hoje se precisa de pesos offline enquanto os arquivos do K3 ainda não saíram.

Uma frase: use API ou produto para inteligência esta semana; use vLLM + pesos reais para self-host quando a aba Files for real—não confunda essas duas portas.

Fonte: mensagem oficial de lançamento do K3 / blog técnico do Kimi K3, Moonshot AI, 16 de julho de 2026.

Para quem é este guia (e para quem não é)

Se a busca foi só “kimi k3 ollama”, leia também nosso post de VRAM & Ollama—aquela página é o honesty check de hardware local. Esta página é o caminho de self-host / serving.

O que “open weights day 0” significa de verdade

A narrativa pública da Moonshot (veja o anúncio do K3):

• Produto + API primeiro (no ar desde ~16 de julho de 2026): chat, Work, Code, API kimi-k3.
• Pesos completos do modelo até 27 de julho de 2026—um compromisso de enviar arquivos, não a mágica de “já está em todo mirror”.
• Arquitetura que muda o serving: Kimi Delta Attention (KDA), Attention Residuals, MoE esparso (enquadramento oficial: 16 de 896 experts ativos por token), ~2.8T params totais, contexto 1M, visão nativa.
• Nota explícita de que eles contribuíram trabalho de prefix-cache ligado a KDA para a comunidade vLLM, para soltar junto com o modelo—porque KDA não se comporta como KV cache clássico de full-attention.

Então o “day 0” para quem self-hosta é, na prática, dois drops:

1. Pesos + LICENSE + model card (em geral Hugging Face sob moonshotai/…).
2. Código de serving que entende o K3 (o preview do vLLM aponta path de modelo, parsers, kernels, Docker, recipes).

Um sem o outro é porta pela metade.

Caminho A — Produto e API (o que a maioria deveria abrir hoje)

Você não precisa de self-host para sentir qualidade frontier do K3:

Se o objetivo é “entregar feature neste sprint,” API + produto ganham. Self-host é para residência de dados, air-gap, fine-tune custom ou unit economics em volume enorme—não para FOMO.

Fonte: mídia oficial de lançamento do K3 / blog Kimi K3, 16 de julho de 2026.

Caminho B — Self-host via vLLM (o path day-0 sério)

O que o vLLM prometeu publicamente (22 de julho de 2026)

O preview do time vLLM é o post mais claro de “prontidão do ecossistema” que temos antes do dia full open-source. Em linguagem direta, eles dizem que estão preparando:

• Serving open-source day-0 para o release dos pesos: implementação do modelo, imagens Docker, deployment recipes, validação de produção
• Prefix caching ciente de KDA (truques clássicos de paged KV não bastam para o estado recorrente do KDA)
• Trabalho de kernel / performance em prefill & decode do KDA, Attention Residuals, MoE (path MXFP4 no enquadramento do release deles), peças multimodais
• Receitas NVIDIA em afinação final + path AMD inicial

Isso é linguagem de infra. Não é “cola isso no Ollama no Windows e conversa.”

Como pensar o serving day-0 (checklist, não CLI congelada)

Quando os pesos aparecerem, um runbook de self-host são é mais ou menos assim—sempre prefira o model card oficial e a doc do vLLM a qualquer blog, inclusive este:

1. Verifique o repo
   • A org deve ser moonshotai (ou outra fonte que a Moonshot linkar no blog oficial).
   • Files de verdade (shards), não só marketing de “Upcoming release”.
   • Leia a LICENSE de ponta a ponta (linhas open Kimi anteriores costumavam usar license estilo Modified MIT; não assuma K3 até o arquivo sair).
2. Fixe um build de serving que declare suporte a K3 / KDA
   • Siga o post do vLLM e a versão que eles taguearem para day-0—branches nightly/main mudam.
   • Espere parsers de tool-call / reasoning e flags multimodais específicos do Kimi, no espírito das recipes da família K2.
3. Planeje paralelismo como MoE gigante
   • MoE esparso classe 2.8T é sobre expert parallelism + bandwidth, não um experimento tensor-parallel-size 1.
   • Docs de produto oficiais apontaram serving multi-acelerador estilo supernode para throughput competitivo—leia isso como formato datacenter.
4. Seja humilde com contexto 1M
   • “1M flat” na API cloud não é o mesmo que “coloquei --max-model-len 1048576 no dia um e voa.”
   • Comece com max length menor, meça prefill/decode, depois estique.
5. Separe “pesos no disco” de “SLO de produção”
   • Day-0 muitas vezes significa sobe. Produção é monitoring, PD disaggregation, taxa de cache hit, failure domains—o post do vLLM fala explicitamente dessas partes difíceis.

Nós não vamos colar aqui uma linha vllm serve … com flags inventadas como se fossem sagradas. Flag errada apodrece em horas; o model card + release notes do vLLM são a fonte da verdade no dia em que os arquivos pousarem.

Realidade de hardware (sem inventar tabela falsa de GB)

O povo quer: “K3 Q4 = XX GB numa 4090.”

Não vamos inventar essa tabela.

O que você pode segurar:

• Escala total (~2.8T) e ativação esparsa (enquadramento 16/896) não equivalem a “notebook cabe nos params totais.” Você ainda armazena um footprint enorme de pesos; só ativa um subconjunto por token.
• Chutes da comunidade sobre tamanho de download costumam cair na faixa de centenas de GB a ~1+ TB, dependendo da história de quant (MXFP4 vs precisão maior)—trate qualquer número como não oficial até o model card listar os tamanhos de arquivo.
• A própria linguagem da Moonshot de 64+ aceleradores / estilo supernode é um formato de serving, não rodapé de hobby.
• Se você ainda não roda clusters multi-node de GPU (nem compra inference gerenciado), API ou host gerenciado vai ganhar de um fim de semana heroico para a maioria dos times.

Para timelines de Ollama/GGUF e “já dá pra rodar local,” fique no guia de VRAM.

Fonte: mídia oficial de lançamento do K3 / blog Kimi K3, 16 de julho de 2026.

Caminho C — O mito Ollama / “Mac Mini” (mate com educação)

A demanda de busca por ollama, gguf, local, self host é real. O erro é empilhar tudo numa fantasia só:

Caminho local saudável enquanto espera: self-host K2.6 / K2.7 Code (já no HF) para agentes de coding offline; use K3 via API nos jobs difíceis. Stacks híbridas batem concurso de pureza.

Checklist do dia (quando a célula do calendário bate)

Use isto quando algo de fato aparecer—não quando um repost gritar “dropping.”

Pesos

• Blog oficial / X ou página HF sai de Upcoming para Files baixáveis
• Repo sob moonshotai (ou link claro a partir de kimi.com/blog/kimi-k3)
• LICENSE + model card + tamanhos de shard listados
• Zero dependência de um “Kimi-K3-abliterated” de terceiro aleatório como única cópia

Serving

• vLLM (ou outro engine que a Moonshot nomear) com versão / imagem que documente K3
• Parsers de tool-call / reasoning batem com o card
• Plano de paralelismo revisado por alguém que já rodou MoE grande
• Smoke test: health endpoint, prompt curto, uma tool call, um prefill de contexto longo

Negócio

• Árvore de decisão: API como default vs piloto de self-host vs host gerenciado
• Segurança: controle de acesso aos pesos, eval de alucinação / tool safety—não “open = prod na mesma noite”

O que fazer esta semana (árvore de decisão)

Se você precisa de qualidade K3 antes do almoço
→ Produto ou API. Não trave nos pesos.

Se está montando piloto de self-host
→ Leia o preview K3 do vLLM; reserve capacidade de cluster; rascunhe o checklist acima; treine com pesos K2.6 / K2.7 Code para a pipeline ficar chata quando os arquivos do K3 pousarem.

Se só tem um notebook gamer
→ Curta o K3 no produto/API na nuvem. Use modelos open menores no local. Ignore thumbnails de “K3 completo em 24GB.”

Se o time de compliance precisa de open weights
→ Favorite HF moonshotai/Kimi-K3 e o blog oficial; sem desenho de produção até LICENSE + arquivos serem reais.

Atenções (filtro de ruído)

1. Data prometida ≠ aba Files. 27 de julho é o alvo público da Moonshot; verifique artefatos.
2. Threads de alucinação / benchmark independente nas redes variam—não cole % de terceiro no seu runbook como “oficial.”
3. Keywords de arquitetura (KDA, AttnRes, MXFP4) são engenharia de verdade; não são prova de que runtimes consumer existem no dia um.
4. Este site não é suporte da Moonshot. Na dúvida, docs oficiais vencem.

Para onde ir

• Hub de status: /kimi-k3-status · hub de produto: /kimi-k3
• Calendário de open weights: /blog/31-kimi-k3-open-weights-july-27
• Honestidade local / Ollama: /blog/34-kimi-k3-vram-ollama-local-requirements
• Portas de teste grátis: /blog/33-kimi-k3-free-how-to · como usar: /blog/36-how-to-use-kimi-k3
• Controle de conta: /blog/37-kimi-k3-api-pricing-cost-control
• Oficial: blog Kimi K3 · preview vLLM K3 · HF moonshotai

Linha de fundo: self-hostar Kimi K3 é projeto sério de serving (vLLM + realidade multi-acelerador), não truque de festa do Ollama. Use as portas na nuvem enquanto a página Upcoming ainda for Upcoming—e quando a aba Files virar real, verifique org, license e stack antes de confiar em qualquer download.