Kimi K2.6: GPU, API y vLLM antes de comprar hardware

Respuesta corta: no hay un “mínimo de GPU” oficial fiable

Con las fuentes disponibles, Kimi K2.6 cuenta con materiales públicos para despliegue, pero no aparece una especificación oficial mínima —modelo de GPU, número de tarjetas o VRAM— que pueda usarse sin más como pliego de compra.

Por eso conviene desconfiar de respuestas demasiado redondas del tipo: “con una RTX 4090 basta”, “un equipo de escritorio lo mueve bien” o “una sola GPU sirve para producción”. En este momento, esas afirmaciones no deberían presentarse como hechos confirmados.

La lectura prudente es esta: si solo quieres probar el modelo, conectarlo a una aplicación, usarlo en un agente de código o integrarlo en herramientas internas, empieza por un proveedor o una API. Si necesitas despliegue privado, red interna o control total del stack de inferencia, entonces plantea una prueba de concepto —PoC— como proyecto de servidor con varias GPU, y decide alquiler o compra después de medir.

Lo que sí está confirmado

Kimi K2.6 aparece en Hugging Face como moonshotai/Kimi-K2.6 y tiene un archivo de documentación docs/deploy_guidance.md asociado al despliegue. vLLM Recipes también tiene una página para Kimi K2.6 y lo etiqueta como 1T / 32B active · MOE · 256K ctx.

En paralelo, CloudPrice muestra Kimi K2.6 disponible a través de 3 proveedores, lo que implica que no hace falta desplegarlo en infraestructura propia para empezar a usarlo. Eso sí: disponibilidad, precio, límites de contexto, cuotas y condiciones pueden cambiar, así que antes de integrar nada en producción hay que verificar la página actual de cada proveedor.

Por qué no conviene tratar K2.6 como un modelo local pequeño

La propia ficha de vLLM Recipes lo resume bien: 1T de parámetros, 32B activos, arquitectura MoE —mezcla de expertos— y contexto de 256K. Aunque los parámetros “activos” sean menores que el total, estos datos bastan para orientar el despliegue como un problema de serving de modelo grande, no como algo equivalente a cargar un modelo pequeño en una sola GPU de consumo.

También hay que separar modelos y variantes. La guía de uso de vLLM para Kimi K2 se refiere a moonshotai/Kimi-K2-Instruct, no a Kimi K2.6; por tanto, no permite deducir el hardware mínimo de K2.6. Aun así, ese ejemplo usa Ray en node 0 y node 1 e incluye parámetros como --tensor-parallel-size 8, --pipeline-parallel-size 2, --dtype bfloat16, --quantization fp8 y --kv-cache-dtype fp8, lo que muestra una orientación hacia paralelismo, cuantización y configuración multi-GPU o multinodo dentro de la familia Kimi K2.

Las referencias de terceros van en una dirección parecida, pero deben leerse con cautela. AllThingsHow muestra un comando vLLM para moonshotai/Kimi-K2.6-INT4 con --tensor-parallel-size 4 y --max-model-len 131072. Otra guía de self-hosting afirma que el modelo INT4 ocupa aproximadamente 594 GB y puede ejecutarse con tan solo 4 GPU H100. Son datos útiles para diseñar una prueba, no una garantía oficial de Moonshot ni una recomendación de compra cerrada.

API o autoalojamiento: decide primero por el caso de uso

Checklist antes de autoalojar Kimi K2.6

1. Fija la versión exacta del modelo

No mezcles moonshotai/Kimi-K2.6, moonshotai/Kimi-K2.6-INT4 y moonshotai/Kimi-K2-Instruct como si fueran el mismo problema de despliegue. La página de K2.6, el ejemplo de terceros para K2.6 INT4 y la guía de vLLM para K2-Instruct apuntan a modelos o variantes distintas, y sus requisitos no se pueden intercambiar sin pruebas.

2. Fija la longitud de contexto

vLLM Recipes etiqueta Kimi K2.6 con contexto de 256K, mientras que el ejemplo de AllThingsHow para K2.6 INT4 configura --max-model-len 131072. Si tus pruebas se hacen con 131K de contexto, no puedes extrapolar automáticamente memoria, latencia o throughput para 256K.

3. Fija la cuantización y el KV cache

El ejemplo de vLLM para Kimi K2-Instruct usa cuantización FP8 y KV cache FP8; el ejemplo de AllThingsHow, en cambio, apunta a una variante INT4 de K2.6. Cambiar cuantización, tipo de KV cache, batch size o concurrencia puede cambiar de forma importante la memoria necesaria y el rendimiento.

4. Documenta el paralelismo

La guía de vLLM para K2-Instruct usa tensor parallel y pipeline parallel; el ejemplo de K2.6 INT4 de AllThingsHow también emplea --tensor-parallel-size 4. Cualquier informe interno debería registrar al menos tensor parallel, pipeline parallel, número de nodos y GPU por nodo. Sin esos datos, comparar resultados sirve de poco.

5. Alquila antes de comprar

Si vas a comprometer presupuesto en H100, RTX 4090 u otras GPU, lo más seguro es probar primero con la versión exacta del modelo, el contexto objetivo, la concurrencia esperada y el framework de serving que usarás en producción. Las fuentes disponibles no bastan para sostener una promesa del tipo “con X tarjetas funcionará seguro”.

Conclusión práctica

La decisión más importante sobre Kimi K2.6 no es elegir GPU, sino elegir ruta de acceso. Si tu objetivo es experimentar o integrar rápido, la vía proveedor/API ya existe. Si necesitas autoalojamiento, Hugging Face y vLLM Recipes son el punto de partida razonable, pero los ejemplos de terceros no deben convertirse en una especificación oficial mínima.

Para compras y arquitectura, la respuesta conservadora es clara: trata Kimi K2.6 como un proyecto de servidor con varias GPU; haz una PoC con la misma versión, cuantización, longitud de contexto y concurrencia que piensas usar; y, mientras no haya una cifra oficial mínima de GPU o VRAM, no prometas que una sola tarjeta, una GPU de consumo o un número fijo de H100 será suficiente.