Ejecuta Kimi K3 Localmente en CPU: El Runtime de 55GB de K3Flight con un Modelo de 929GB

K3Flight ejecuta el modelo Kimi K3 de 2.8T parámetros en CPU con solo ~55GB de RAM al transmitir pesos desde el almacenamiento mediante cPilot Runtime. Un servidor de inferencia Linux de un solo archivo.

Kimi K3 es un modelo masivo de Mezcla de Expertos (MoE) con 2.8 billones de parámetros. Su checkpoint completo Q2_K pesa 929GB. Ejecutarlo localmente parece imposible, hasta que te das cuenta de que el modelo no necesita caber en memoria. K3Flight, un nuevo proyecto de código abierto, lo demuestra: un servidor de inferencia Linux de un solo archivo que ejecuta Kimi K3 en CPU con una huella de memoria de runtime medida de solo ~55GB.

El secreto no es compresión ni destilación. Es un enfoque de ingeniería de sistemas que trata el almacenamiento, la memoria y la CPU como una única ruta de ejecución coordinada. Así es como funciona y cómo puedes probarlo tú mismo.

El Problema: 929GB de Pesos vs. 64GB de RAM

La mayoría de la inferencia de LLM local asume que todo el modelo debe residir en RAM. Para un checkpoint de 929GB, eso significa una máquina con al menos 1TB de memoria, mucho más de lo que la mayoría de los desarrolladores tienen. Pero Kimi K3 es un modelo de Mezcla de Expertos (MoE). Según sus especificaciones públicas, cada token activa solo 16 de 896 expertos. El número total de parámetros describe la capacidad del modelo, no el conjunto de trabajo necesario para cualquier paso de inferencia individual.

K3Flight explota esta escasez. En lugar de cargar todo, el Runtime cPilot prepara solo los pesos y el estado necesarios para la ruta de ejecución actual. El checkpoint completo permanece en el almacenamiento, y los datos se transmiten a la CPU según sea necesario.

Los Números: Lo que Muestra la Ejecución de Referencia

Los mantenedores ejecutaron el checkpoint completo Kimi-K3-GGUF Q2_K en una máquina Linux x86-64 con estos resultados:

  • Parámetros totales: 2.8T
  • Memoria de runtime: ~55GB
  • Backend: solo CPU
  • Prefill: ~1 token/s
  • Decode: ~0.8 token/s

Estos son números preliminares de una sola ejecución de referencia, no una garantía. El modelo exacto de CPU y SSD no se divulga. El ancho de banda de almacenamiento, la capacidad de la CPU, la longitud del contexto y la versión del runtime pueden afectar significativamente el rendimiento. Pero el punto no es la velocidad, es que un modelo completo de 2.8T puede ejecutarse localmente sin mantener 929GB residentes.

Cómo Funciona K3Flight

K3Flight no encoge el modelo. El checkpoint de 929GB permanece en disco. En cambio, el Runtime cPilot gestiona un conjunto de trabajo vivo mucho más pequeño durante la inferencia. Lo hace:

  • Tratando el almacenamiento, la memoria del host y la CPU como una única ruta de ejecución coordinada
  • Preparando pesos y estado del runtime según el modelo los necesita
  • Orquestando el movimiento de datos y el cómputo para mantener la ruta activa en movimiento
  • Manteniendo el checkpoint completo Q2_K disponible sin residencia completa

Esto convierte un problema de tamaño de modelo en un problema de sistemas. El resultado es un servidor que puede ejecutarse en una máquina con 64GB de RAM y un SSD NVMe rápido.

Comenzando: Vista Previa de Inicio Rápido

K3Flight está actualmente en v0.1.0-preview. El primer binario de Linux se está empaquetando, y los mantenedores prometen una versión reproducible pronto. Así es como puedes prepararte.

1. Descarga el Binario

Una vez que la versión esté disponible, descarga el archivo Linux x86-64 desde GitHub Releases:

curl -L -O https://github.com/onetoken-oss/K3Flight/releases/download/v0.1.0-preview/cpilot-server-v0.1.0-preview-linux-x86_64.tar.gz
tar -xzf cpilot-server-v0.1.0-preview-linux-x86_64.tar.gz
sha256sum -c cpilot-server-v0.1.0-preview-linux-x86_64.sha256
chmod +x cpilot-server-v0.1.0-preview-linux-x86_64

Asegúrate de descargar el archivo de versión .tar.gz, no el archivo de código fuente.

2. Descarga el Modelo

Necesitarás el checkpoint Kimi-K3-GGUF Q2_K de Hugging Face. Son 929GB, así que planifica tu almacenamiento en consecuencia. Sigue las instrucciones en MODEL.md para el repositorio y la revisión exactos.

3. Inicia el Servidor

Configura tu directorio de modelos y lanza el servidor:

export MODEL_DIR="$HOME/models/Kimi-K3-Q2_K"

./cpilot-server-v0.1.0-preview-linux-x86_64 \
  --model "$MODEL_DIR/Kimi-K3-Q2_K-00001-of-00094.gguf" \
  --host 127.0.0.1 \
  --port 8080

Mantén el enlace de loopback a menos que entiendas las implicaciones de seguridad de exponer un servidor de inferencia a una red.

4. Envía una Solicitud

Abre http://127.0.0.1:8080 en tu navegador para la interfaz web, o usa la API compatible con OpenAI:

curl http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "kimi-k3-q2_k",
    "stream": true,
    "messages": [
      {"role": "user", "content": "¡Hola!"}
    ]
  }'

Los registros del servidor informarán el rendimiento de prefill y decode.

Opciones de Runtime

Ejecuta ./cpilot-server-v0.1.0-preview-linux-x86_64 --help para ver todas las opciones. Las clave incluyen:

  • -m, --model: Ruta al fragmento GGUF (obligatorio)
  • --host: Por defecto 127.0.0.1
  • --port: Por defecto 8080
  • -t: Hilos de CPU (por defecto 12)
  • -c: Tamaño de contexto (por defecto 512)
  • -b: Tamaño de lote lógico (por defecto 64)
  • -ub: Tamaño de lote físico (por defecto 64)
  • --cpilot-memory: Nivel de ajuste de memoria (0-?)

Requisitos

La vista previa apunta a una configuración estrecha y verificable:

  • Linux en x86-64
  • Se recomiendan 64GB+ de memoria del sistema
  • Al menos 1TB de almacenamiento local libre
  • Se recomienda encarecidamente un SSD NVMe local
  • No se requiere GPU

El soporte para macOS está planeado a continuación.

Preguntas Frecuentes: Preguntas Comunes

¿Comprimiste 929GB en 55GB? No. Los archivos del modelo permanecen en ~929GB en el almacenamiento. ~55GB es la huella de memoria de runtime observada.

¿Es un modelo más pequeño o destilado? No. Es el checkpoint completo Kimi-K3-GGUF Q2_K. Q2_K es una representación cuantizada, por lo que no es numéricamente idéntico al original, pero es el modelo completo.

¿Por qué un modelo de 2.8T puede ejecutarse de esta manera? Kimi K3 activa solo 16 de 896 expertos por token. cPilot gestiona el conjunto de trabajo vivo en lugar de requerir residencia completa.

¿Es ~55GB el mínimo de RAM? No. Es un resultado medido preliminar. Se recomiendan 64GB para la vista previa.

¿Por qué la generación es lenta? La ruta de CPU intercambia residencia por movimiento de datos. Está diseñada para demostrar la ejecución local, no para competir con la latencia de un centro de datos.

Limitaciones Conocidas

  • Solo Linux x86-64; macOS aún no está disponible
  • Solo CPU, optimizado para viabilidad en lugar de latencia en la nube
  • El rendimiento varía con el almacenamiento y la CPU
  • Sin SLA de producción; no expongas a redes no confiables

Ayuda a Construir el Mapa de Hardware

Los mantenedores buscan resultados honestos, incluyendo ejecuciones lentas y fallos. Si lo pruebas, comparte tu ejecución con detalles como CPU, memoria, modelo de SSD y rendimiento. Los resultados negativos controlados son bienvenidos: ayudan a definir el límite real del hardware.

Reflexiones Finales

K3Flight es una notable prueba de concepto. Desafía la suposición de que los modelos grandes requieren memoria grande. Al aprovechar la escasez de MoE y la ingeniería de sistemas inteligente, hace que un modelo de 2.8T sea ejecutable en una sola máquina. No es rápido, pero es local, y eso abre posibilidades para IA en el borde, privacidad y experimentación.

Si te interesa la inferencia de LLM local, vale la pena seguir esto. Marca el repositorio con una estrella, prueba la vista previa cuando salga y contribuye con tus mediciones. El futuro de la IA local podría no requerir un centro de datos después de todo.

Fuente

onetoken-oss/K3Flight: Ejecuta Kimi K3 localmente en CPU con ~55GB de RAM de runtime medida. Un servidor de inferencia Linux de un solo archivo impulsado por cPilot Runtime.