Kimi K3 y otros modelos grandes en local con cinco repos abiertos

Modelos frontera en el escritorio en vez de en un centro de datos

Los modelos alojados de los grandes laboratorios impresionan y salen caros. Construye algo serio encima y la factura sube rápido. Hace tiempo que existen modelos de pesos abiertos que se acercan a los de pago, pero con una máquina normal la mayoría acababa comprando inferencia a otro. Un puñado de proyectos open source está cambiando eso. Y no apuntan a modelos de juguete. Van a por modelos de clase frontera cuyo entrenamiento costó millones, ejecutándolos sin conexión en tu propio hardware y sin pagar por token.

Los cinco repos de abajo atacan el mismo problema: ¿cómo encoges algo pensado para un centro de datos hasta que quepa en un escritorio? Y lo resuelven de formas muy distintas.

Qué tienen en común estos proyectos

La distancia es enorme. Un modelo como Kimi K3 necesita 1,56 TB solo para guardar sus pesos, y un portátil suele tener 16 o 32 GB de RAM. Cada herramienta aquí es un rodeo para esa desproporción, y los rodeos se agrupan en tres familias:

• Transmitir los pesos desde el disco en vez de cargarlos todos en memoria.
• Comprimir el modelo tanto que acabe ocupando una fracción de su tamaño original.
• Saltarse las neuronas que no aportan nada al prompt actual: son la mayoría, así que no hay motivo para cargarlas.

También se diferencian en otras cosas. Algunos son motores de inferencia generales que manejan cientos de modelos; otros están construidos alrededor de una única arquitectura. Unos necesitan GPU y otros la evitan a propósito. Unos cuantos son experimentos de investigación que empujan los límites de lo posible, mientras que otros ya están listos para desplegar hoy.

1. Kimi K3 en C

Kimi K3 es un modelo mixture-of-experts de Moonshot AI con 2,78 billones de parámetros, y en varios benchmarks supera a Claude. Hasta hace poco habrías dado por hecho que la entrada costaba una granja de servidores del tamaño de un almacén.

Este repo no está de acuerdo. Es un motor de inferencia en C99 portable, 176 KB de código, sin ninguna dependencia: ni BLAS, ni PyTorch, ni GPU. Su autor consiguió ejecutar el modelo completo en un portátil con apenas 8 GB de RAM.

La salida es idéntica byte a byte en un portátil de 8 GB y en una estación de trabajo de 128 GB; solo cambia la velocidad. Con 8 GB esperas unos 26 segundos por token, lo cual es un suplicio, pero funciona. Dale RAM suficiente para mantener todo el modelo residente y la espera baja a 5,6 segundos por token.

El truco es el streaming desde disco. Como K3 es un modelo mixture-of-experts, para cada token solo está activo alrededor del 4 % de sus parámetros. El motor lee del disco únicamente los expertos que necesita, directamente al cálculo, y nunca intenta tener el modelo entero en memoria. Todo el motor es un único archivo C sin dependencias.

Para probarlo:

# Clone the repo
git clone https://github.com/FareedKhan-dev/kimi-k3-in-c.git
cd kimi-k3-in-c

# Build
make

# Run with a preset matching your hardware
./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop \
  --tok ~/k3model --prompt "The capital of France is" --gen 8

2. WARP

Si el motor en C de arriba es la prueba de concepto mínima, WARP es la versión con ingeniería de verdad. Viene del equipo de SQLiteAI y es un motor de inferencia embebible en C que mantiene la misma idea de leer desde disco y le suma optimización real.

El tronco compartido del modelo se queda en memoria, y solo los expertos elegidos para el token actual salen del disco. La RAM que sobra se convierte en una caché de expertos acotada, así que los expertos que se eligen a menudo se quedan residentes. Un router con anticipación va un paso más allá: predice qué expertos querrá la siguiente capa y empieza a leerlos antes.

Resultado: el contenedor de K3 baja de 1,56 TB a 982 GB y un MacBook Pro con 64 GB puede ejecutarlo, aunque solo a unos 0,6 tokens por segundo.

El proyecto se describe como dirigido por humanos y escrito por LLM. Su objetivo a largo plazo es un poco loco: lograr que WARP ejecute K3 lo bastante bien como para que el modelo pueda trabajar en mejorarse a sí mismo.

Instalación:

# Clone
git clone https://github.com/sqliteai/waste.git
cd waste

# Build (requires C compiler)
make

# Run with auto-detected memory budget
./waste run ~/models/k3.waste "What is the capital of Italy?"

# Or specify a memory budget manually
./waste run ~/models/k3.waste "Explain quantum computing" --budget 48GB

3. Deltafin

Deltafin parte de una pregunta que a pocos se les ocurre. ¿Y si ejecutaras K3 completo, los 16 expertos en cada token y sin podar nunca, en hardware de consumo, y luego lo hicieras tan rápido como fuera posible?

Es tanto una filosofía como una decisión técnica. Otros proyectos toman atajos: podan expertos, se saltan capas o usan un modelo borrador para especular. Deltafin no. Su regla de calidad dice más o menos así: solo K3 decide cada token. Los modelos borrador pequeños pueden adivinar por delante, y de ahí sale buena parte de la velocidad, pero K3 comprueba cada apuesta y nada te llega sin su visto bueno.

Las cifras son modestas y se cuentan con franqueza. Un portátil con M1 Max saca ahora unos 0,29 tokens por segundo. Lo interesante, eso sí, es la gráfica de progreso del README. En una semana más o menos el proyecto pasó de 0,014 a 0,29 tokens por segundo, una mejora de 20 veces a base de optimizar sin descanso. Su declaración de intenciones lo deja claro: la velocidad nunca debe salir de reducir la calidad del modelo.

El equipo considera un avance que un modelo frontera funcione en un equipo doméstico de unos 15.000 dólares en lugar de en una infraestructura de 2.000.000 de dólares.

Para empezar:

# Download the latest release from GitHub
# https://github.com/gavamedia/deltafin/releases

# Run with model path (auto-detects hardware)
./deltafin --model /path/to/k3-checkpoint


# The binary handles expert routing, memory management,
# and hardware acceleration automatically.

4. llama.cpp

Este es el nombre que con más probabilidad ya has oído. llama.cpp es lo que llevó la inferencia local al gran público.

Su creador, Georgi Gerganov, empezó con una idea sencilla: ejecutar modelos LLaMA en C/C++ puro con las menos dependencias posibles. Sin PyTorch, sin runtime de Python, solo rendimiento directo del metal al modelo. La idea creció hasta convertirse en el motor de inferencia local más usado. Admite cientos de modelos en CPU, GPU (CUDA, Metal, Vulkan, SYCL) y también en algún hardware poco común.

A su alrededor se formó todo un ecosistema. Ollama, LM Studio y GPT4All, junto con muchas otras herramientas de «ejecuta un modelo en local y ya», están construidas sobre llama.cpp. Podría decirse que es el kernel de Linux de la inferencia de IA local.

Uso:

# Install via Homebrew (easiest)
brew install llama.cpp

# Download and run any GGUF model from Hugging Face
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF

# Or launch an OpenAI-compatible API server
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

# Build from source
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp && cmake -B build && cmake --build build

5. FlexGen

FlexGen encaja en otra situación: tienes una GPU corriente y quieres pasar millones de tokens por un modelo durante la noche.

Es un motor de generación de alto rendimiento del equipo de FMInference para ejecutar modelos de lenguaje grandes con poca memoria de GPU. Se apoya en un offloading eficiente en E/S. Cuando los pesos no caben en la memoria de la GPU, pasan a la RAM de la CPU o incluso al disco, y todo el esquema está afinado para el rendimiento total en lugar de para la baja latencia.

Por ejemplo, puede ejecutar OPT-175B, que necesita 350 GB de memoria de GPU a precisión completa, en una sola T4 de 16 GB descargando pesos al disco. La latencia por token es mala para un chat. Para trabajos por lotes nocturnos como benchmarking (se integra con el framework HELM de Stanford) o procesamiento de datos, es justo lo que buscas.

Los cinco repos persiguen el mismo objetivo de ejecutar IA en local, cada uno desde un ángulo distinto. Juntos apuntan en una dirección: dejar de mandar tus datos a una granja de servidores y tener los modelos más potentes en tu propio dispositivo.