Self-host de Kimi K3 el día 0: ruta vLLM vs el mito Ollama en el portátil

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

Tu feed dice que los open weights de Kimi K3 caen el 27 de julio. Alguien responde con captura de un Mac Mini. Otro pega un GGUF misterioso de «Ollama a un clic». Mientras tanto tú intentas contestar algo más simple: ¿puede mi equipo self-hostear esto, o es solo hype?

Versión corta: trata el self-host como un problema de cluster / vLLM, no como una app de chat en el portátil. Producto y API ya están vivos. Los pesos públicos completos siguen siendo un evento de calendario que re-verificas en Hugging Face—no una garantía de que ollama pull funcione esta noche.

Este sitio es independiente de Moonshot. Specs y fechas de abajo siguen docs públicas y blogs de partners a 27 de julio de 2026; re-chequea el blog de Kimi K3, la documentación de la plataforma y el preview de vLLM para K3 antes de comprar hierro o confiar en un repo random.

Respuesta corta (léela primero)

1. Dos trabajos distintos.
   • «Quiero calidad K3 hoy» → kimi.com, Kimi Code, o el id de API kimi-k3 en platform.kimi.ai.
   • «Quiero los pesos en mi VPC» → espera un repo de HF de Moonshot con archivos reales + un stack de serving del día 0 (vLLM es la ruta pública que Moonshot y partners están preparando).
2. A la fecha de este texto, HF moonshotai/Kimi-K3 sigue siendo una página de Upcoming release (countdown / notify)—no una descarga terminada con safetensors. Los posts que dicen «ya está open» casi siempre leen la promesa, no la pestaña Files.
3. Ollama en una sola GPU gaming es el modelo mental equivocado para el K3 completo de clase 2.8T. El lenguaje oficial de serving apunta a despliegue supernodo / multi-acelerador, no a un juguete de 24 GB.
4. El preview de vLLM del 22 de julio es la mejor nota pública de «cómo servirá la industria esto»: ruta de modelo día 0, prefix caching consciente de KDA, recetas Docker, NVIDIA + trabajo inicial en AMD—no un one-liner de consumidor.
5. Las líneas open de Kimi ya descargables (p. ej. K2.6 / K2.7 Code en Hugging Face) son lo que puedes self-hostear hoy si necesitas pesos offline mientras los archivos de K3 siguen pendientes.

En una frase: usa la API o el producto para inteligencia esta semana; usa vLLM + pesos reales para self-host cuando la pestaña Files sea real—no mezcles esas dos puertas.

Fuente: mensaje oficial de lanzamiento de K3 / blog técnico de Kimi K3, Moonshot AI, 16 de julio de 2026.

Para quién es esta guía (y para quién no)

Si solo buscaste «kimi k3 ollama», lee también nuestro post de VRAM y Ollama—esa página es el chequeo honesto de hardware local. Esta página es la ruta de self-host / serving.

Qué significa de verdad el «día 0 de open weights»

La historia pública de Moonshot (ver el anuncio de K3):

• Producto + API primero (vivos desde ~16 de julio de 2026): chat, Work, Code, API kimi-k3.
• Pesos completos del modelo para el 27 de julio de 2026—un compromiso de publicar archivos, no una magia de «ya está en todos los mirrors».
• Arquitectura que cambia el serving: Kimi Delta Attention (KDA), Attention Residuals, MoE sparse (framing oficial: 16 de 896 expertos activos por token), ~2.8T params totales, contexto de 1M, visión nativa.
• Nota explícita de que aportaron trabajo de prefix-cache relacionado con KDA a la comunidad vLLM, para liberarlo junto al modelo—porque KDA no se comporta como el KV cache clásico de full-attention.

Así que el «día 0» para quien self-hostea son en realidad dos caídas:

1. Pesos + LICENSE + model card (normalmente Hugging Face bajo moonshotai/…).
2. Código de serving que entienda K3 (el preview de vLLM apunta a model path, parsers, kernels, Docker, recetas).

Cualquiera de las dos sin la otra es una puerta a medias.

Ruta A — Producto y API (lo que la mayoría debería abrir hoy)

No necesitas self-host para probar calidad frontier de K3:

Si tu meta es «sacar una feature este sprint», ganan API + producto. Self-host es para residencia de datos, air-gap, fine-tune custom o unit economics a volumen enorme—no para FOMO.

Fuente: medios oficiales de lanzamiento de K3 / blog de Kimi K3, 16 de julio de 2026.

Ruta B — Self-host con vLLM (la ruta seria del día 0)

Qué prometió vLLM en público (22 de julio de 2026)

El preview del equipo de vLLM es el post de «preparación del ecosistema» más claro que tenemos antes del día open-source completo. En castellano llano, dicen que están preparando:

• Serving open-source del día 0 para la salida de pesos: implementación del modelo, imágenes Docker, recetas de despliegue, validación en producción
• Prefix caching consciente de KDA (los trucos clásicos de paged KV no bastan para el estado recurrente de KDA)
• Trabajo de kernels / rendimiento en prefill y decode de KDA, Attention Residuals, MoE (ruta MXFP4 en su framing de release), piezas multimodales
• Recetas NVIDIA en afinado final + una ruta AMD inicial

Eso es lenguaje de infra. No es «pega esto en Ollama en Windows y chatea».

Cómo pensar el serving del día 0 (checklist, no un CLI congelado)

Cuando aparezcan los pesos, un runbook sano de self-host se ve así—prioriza siempre la model card oficial y la docs de vLLM por encima de cualquier blog, incluido este:

1. Verifica el repo
   • La org debería ser moonshotai (u otra fuente que Moonshot enlace desde el blog oficial).
   • Files de verdad (shards), no solo marketing de «Upcoming release».
   • Lee la LICENSE de punta a punta (líneas open previas de Kimi solían usar licencia estilo Modified MIT; no asumas K3 hasta que el archivo salga).
2. Fija un build de serving que reclame soporte K3 / KDA
   • Sigue el post de vLLM y la versión que etiqueten para el día 0—las ramas nightly/main se mueven.
   • Espera parsers de tool-call / reasoning y flags multimodales específicos de Kimi, parecidos a recetas anteriores de la familia K2.
3. Planifica el paralelismo como un MoE gigante
   • Un MoE sparse de clase 2.8T es cosa de expert parallelism + ancho de banda, no de un experimento con tensor-parallel-size 1.
   • Las docs de producto oficiales han apuntado a serving multi-acelerador estilo supernodo para throughput competitivo—léelo como forma de datacenter.
4. Sé humilde con el contexto de 1M
   • El «1M plano» de la API en la nube no es lo mismo que «pongo --max-model-len 1048576 el día uno y vuela».
   • Empieza con un max length más corto, mide prefill/decode, y luego estira.
5. Separa «pesos en disco» de «SLO de producción»
   • Día 0 a menudo significa arranca. Producción significa monitoring, PD disaggregation, tasas de cache hit, dominios de fallo—el post de vLLM habla explícitamente de esas partes duras.

No vamos a pegar una línea copy-paste de vllm serve … con flags inventados como si estuviera bendecida. Los flags malos se pudren en horas; la model card + release notes de vLLM son la fuente de verdad el día que aterrizan los archivos.

Realidad de hardware (sin inventar una tabla falsa de GB)

La gente quiere: «K3 Q4 = XX GB en un 4090».

No vamos a inventar esa tabla.

A lo que sí te puedes agarrar:

• La escala total (~2.8T) y la activación sparse (framing 16/896) no equivalen a «el portátil cabe con el total de params». Sigues almacenando un footprint enorme de pesos; solo activas un subconjunto por token.
• Las conjeturas de la comunidad sobre tamaño de descarga suelen caer en la banda de cientos de GB a ~1+ TB según la historia de quant (MXFP4 vs mayor precisión)—trata cualquier número como no oficial hasta que la model card liste tamaños de archivo.
• El propio lenguaje de Moonshot de 64+ aceleradores / estilo supernodo es una forma de serving, no una nota al pie de hobby.
• Si aún no operas clusters multi-nodo GPU (o compras inference gestionado), la API o un host managed le gana a un build heroico de fin de semana para la mayoría de equipos.

Para timelines de Ollama/GGUF y «¿puedo correrlo en local ya?», quédate en la guía de VRAM.

Fuente: medios oficiales de lanzamiento de K3 / blog de Kimi K3, 16 de julio de 2026.

Ruta C — El mito Ollama / «Mac Mini» (mátarlo con educación)

La demanda de búsqueda de ollama, gguf, local, self host es real. El error es apilarlos en una sola fantasía:

Ruta local sana mientras esperas: self-hostea K2.6 / K2.7 Code (ya en HF) para agents de coding offline; usa K3 vía API para los trabajos duros. Los stacks híbridos le ganan a los concursos de pureza.

Checklist del día (cuando la celda del calendario se cumple)

Úsalo cuando de verdad aparezca algo—no cuando un repost diga «está cayendo».

Pesos

• Blog/X oficial o página de HF pasa de Upcoming a Files descargables
• Repo bajo moonshotai (o claramente enlazado desde kimi.com/blog/kimi-k3)
• LICENSE + model card + tamaños de shards listados
• Cero dependencia de un «Kimi-K3-abliterated» de terceros random como única copia

Serving

• vLLM (u otro engine que nombre Moonshot) con versión / imagen que documente K3
• Parsers de tool-call / reasoning alineados con la card
• Plan de paralelismo revisado por alguien que haya corrido MoE grandes
• Smoke test: health endpoint, prompt corto, una tool call, un prefill de contexto largo

Negocio

• Árbol de decisión: API por defecto vs piloto de self-host vs host managed
• Seguridad: control de acceso a pesos, eval de alucinación / tool safety, no «open = a prod la misma noche»

Qué hacer esta semana (árbol de decisión)

Si necesitas calidad K3 antes de la comida
→ Producto o API. No te bloquees en los pesos.

Si estás montando un piloto de self-host
→ Lee el preview de K3 de vLLM; reserva capacidad de cluster; borra el checklist de arriba; practica con pesos de K2.6 / K2.7 Code para que el pipeline sea aburrido cuando aterrizen los archivos de K3.

Si solo tienes un portátil gaming
→ Disfruta K3 en el producto/API en la nube. Usa modelos open más pequeños en local. Ignora thumbnails de «K3 completo en 24 GB».

Si tu equipo de compliance necesita open weights
→ Guarda HF moonshotai/Kimi-K3 y el blog oficial; ningún diseño de producción hasta que LICENSE + archivos sean reales.

Alertas (filtro de ruido)

1. Fecha promesa ≠ pestaña Files. El 27 de julio es el target público de Moonshot; verifica artefactos.
2. Los hilos de alucinación / benchmarks independientes en redes varían—no pegues % de terceros en tu runbook como «oficiales».
3. Las keywords de arquitectura (KDA, AttnRes, MXFP4) son ingeniería real; no son prueba de que existan runtimes de consumo el día uno.
4. Este sitio no es soporte de Moonshot. Ante la duda, ganan las docs oficiales.

Siguientes pasos

• Hub de status: /kimi-k3-status · hub de producto: /kimi-k3
• Calendario open-weights: /blog/31-kimi-k3-open-weights-july-27
• Honestidad local / Ollama: /blog/34-kimi-k3-vram-ollama-local-requirements
• Puertas free: /blog/33-kimi-k3-free-how-to · cómo usar: /blog/36-how-to-use-kimi-k3
• Control de factura: /blog/37-kimi-k3-api-pricing-cost-control
• Oficial: blog de Kimi K3 · preview K3 de vLLM · HF moonshotai

Línea de fondo: self-hostear Kimi K3 es un proyecto serio de serving (vLLM + realidad multi-acelerador), no un truco de fiesta con Ollama. Usa las puertas cloud mientras la página Upcoming siga en Upcoming—y cuando la pestaña Files se vuelva real, verifica org, licencia y stack antes de confiar en cualquier descarga.