Suscríbete a mi canal:
Qwen3.6-35B-A3B es un modelo Mixture of Experts de Alibaba: 35.000 millones de parámetros en total y solo unos pocos activos en cada token. En una gráfica de 12 GB puedes correrlo en local si dejas que llama.cpp separe lo que va a la GPU de lo que va a la CPU, con un flag que Ollama no te deja tocar.
En el vídeo de arriba lo cargo en mi RTX 4070 de 12 GB, te enseño la velocidad en llama.cpp (~62 tok/s en pantalla, a veces ~70 en la misma máquina), salgo y hago lo mismo en Ollama (~23 tok/s), te explico el -ncmoe, genero una landing en local y te digo cómo encontrar el número que funciona en tu VRAM.
¿Qué ves en la demo: llama.cpp contra Ollama?
Primero ves un 35B corriendo en casa a un ritmo que no esperas de 12 GB. El modelo está cargado en local, en mi RTX 4070 de 12 GB, y en pantalla llama.cpp marca 62,4 tokens por segundo.
Ese 62 no es un récord sacado de un Excel. Es lo que salió en esa toma, con el ordenador ya un poco cansado de tantas pruebas. En la misma máquina, el día anterior, llegué cerca de 70 tok/s. Cuando vas cargando y descargando modelos, la memoria se ensucia y el número baja un poco. Por eso el título habla de ~70 y en el vídeo te enseño el 62 que había en ese momento.
Salgo de llama.cpp y hago lo mismo con Ollama. Mismo modelo, misma gráfica, mismo tipo de trabajo. El contador se queda en 23 tokens por segundo.
De 62 a 23. Casi el triple, según el momento. No es que Ollama “esté roto”. Es que la comodidad te quita el mando fino, y en un MoE grande esa diferencia se nota en cuanto empiezas a escribir de verdad.
Abro el monitor de la GPU a propósito. La 4070 está a tope. No es un número inflado mientras la gráfica bosteza. El modelo de 35.000 millones está trabajando en un PC de casa, y la tarjeta lo está empujando.
Estos ~62 / ~70 y ~23 son de esta demo, en esta RTX 4070 de 12 GB (64 GB de RAM, WSL2 Ubuntu 22.04). No los tomes como benchmark universal. Otra cuantización, otro contexto u otra carga te van a dar otra cifra. Mide en tu máquina.
¿Por qué llama.cpp va más rápido que Ollama con este MoE?
Porque Ollama envuelve llama.cpp y te ahorra pelearte con flags, a costa de no dejarte el control que este modelo pide.
Si no lo sabías: debajo de Ollama hay llama.cpp, la herramienta que usa mucha gente “de terminal” para cargar modelos en GGUF. Ollama te la pone fácil. Eliges modelo, das a run, y funciona. A mí me encanta para el día a día.
El problema llega cuando el modelo es un MoE de 35B y tu gráfica es de 12 GB. Ahí no basta con “que quepa”. Hay que decidir qué se queda en la VRAM y qué se va a la RAM. Ollama hace un reparto automático que vale para casi todo, y por eso arranca limpio en cualquier tarjeta. En este tipo de Mixture of Experts ese automático se deja velocidad en el camino.
llama.cpp te deja añadir parámetros. Le dices dónde va cada cosa. Esa es la gracia de la diferencia que ves en el vídeo. No es magia de marca. Es un mando que en Ollama no tienes con la misma granularidad.
Si tu flujo de cada día es Ollama y no quieres pelearte aún, aquí dejé cómo usar Ollama en local sin pagar API. Para exprimir este Qwen en 12 GB, toca bajar un nivel y hablarle a llama.cpp en la cara.
En benches públicos pasa algo parecido, con otras cifras. Ken Imoto, en una 4070 de 12 GB con Qwen 35B en Q4_K_M, midió ~12 tok/s en Ollama y ~35 con llama.cpp y el flag de expertos en CPU (unas 2,8 veces). No es mi 62. Es otra quant y otro protocolo. La dirección sí coincide: el mismo hardware, distinto control, otro ritmo. Hay hilos e issues donde la gente pide a Ollama justo este tipo de mando sobre el MoE, y de momento no lo tienes igual de fino.
¿Qué hace el flag -ncmoe / --n-cpu-moe?
Decide cuántos expertos MoE se quedan en la CPU, para que la GPU no intente tragarse el modelo entero de un golpe.
En el vídeo el comando va así:
llama-cli -m ~/models/Qwen3.6-35B-A3B-UD-IQ3_XXS.gguf -ngl 99 -ncmoe 15 --cache-type-k q8_0 --cache-type-v q8_0 --ctx-size 32768El modelo es el GGUF de Unsloth en IQ3_XXS, unos 13 GB en disco. El repo de la herramienta es ggml-org/llama.cpp.
-ngl 99 es la forma habitual de decir “manda a la GPU todas las capas que puedas”. El 99 no es que el modelo tenga 99 capas. Es “todas”.
Si te quedaras ahí, con un 35B que no cabe entero en 12 GB, la gráfica se desborda o empiezas a empujar a RAM justo lo que más necesita ir rápido. Atención y caché KV quieren el carril de la VRAM. Los expertos del MoE, en cambio, son muchos y en cada token solo se usan unos pocos.
Ahí entra -ncmoe 15 (lo mismo que --n-cpu-moe 15). Le dices a llama.cpp que se lleve a la CPU los expertos de 15 capas. La GPU se queda con la atención, con la caché, y con los expertos que aún caben. La CPU mastica los que has sacado fuera.
En el vídeo lo cuento más a lo bruto: sin esa bandera intenta cargar todo de una vez, y en 12 GB se ahoga. Con el numerito, carga lo que toca y deja el resto para cuando haga falta. El detalle técnico es ese reparto de expertos, no un truco misterioso de “solo 15 capas mágicas”.
El 15 no es un número sagrado. Es el que a mí me funcionó en esa 4070 con esta quant. Un poco más, un poco menos, y cambia VRAM y velocidad. Más abajo te digo cómo encontrarlo en la tuya.
El resto del comando también cuenta. --cache-type-k q8_0 y --cache-type-v q8_0 comprimen la caché de atención. --ctx-size 32768 pide un contexto largo. En 12 GB, si dejas la caché a lo ancho, te comes la VRAM aunque el flag del MoE esté bien puesto.
¿Puede un 35B hacerte una landing en local?
Sí, y en el vídeo lo ves escribir de verdad, no un “hola mundo” de feria.
Le pido que cree una landing page de un consultor de marketing online. El prompt es malo. Se lo digo en el vídeo. Aun así el modelo se pone a trabajar.
Primero piensa. Qwen3.6 puede razonar antes de contestar, si no le dices lo contrario. En pantalla se ve ese tramo un poco más difuminado. Luego pasa a escribir HTML de verdad, más nítido.
También puedes pedirle que no piense y que ejecute directo. En esa toma no se lo pedí, para que vieras las dos fases.
No me quedo esperando a que termine la página en cámara. Te enseño una que le había pedido antes, ya generada, sirviendo en local. Se ve una landing decente. No es Claude Sonnet ni Opus. Tampoco es un juguete. Es un 35B en el PC de casa haciendo un trabajo que hace dos años mandabas a una API.
Lo paro para seguir con la explicación. El punto no es el HTML perfecto. El punto es que el modelo cabe, corre a un ritmo usable y te devuelve algo que puedes abrir en el navegador sin haber pagado un token.
El gráfico de las bombillas que sale después también nació en local. Se lo pedí a la propia herramienta, y para dibujarlo usé Excalidraw dentro de Obsidian. O sea: el mismo stack de casa te sirve para el modelo y para explicarte el modelo.
Si además del chat quieres otra carga local —digitalizar facturas sin subirlas a un tercero— el mismo espíritu está en el OCR con IA en tu PC.
¿Qué es un modelo MoE y por qué cabe en 12 GB?
Es un Mixture of Experts: muchos especialistas dentro del mismo modelo, y en cada token solo se encienden los que hacen falta.
Qwen3.6-35B-A3B guarda 35.000 millones de parámetros. La parte A3B te dice que lo activo por paso es del orden de 3.000 millones. Pagas memoria como un 35B. Pagas cómputo más cercano a un 3B.
La metáfora del vídeo es esta. Tienes 35 bombillas. En cada momento solo necesitas tres. Enciendes tres. El resto sigue ahí, pero no está chupando la gráfica a la vez.
Un modelo denso del mismo tamaño nominal no tiene ese truco. Cada token pasa por casi todo. En 12 GB un denso grande o no cabe, o se va a un tok/s triste. El MoE te deja tener “mucho modelo” en disco y “poco modelo” trabajando en cada palabra.
Eso es justo lo que llama.cpp te deja aprovechar con -ncmoe. No cargas los 35.000 millones a lo loco en la VRAM. Dejas en la GPU lo que más se beneficia del ancho de banda (atención y caché) y mandas expertos a la CPU. El router del MoE, en cada token, elige qué expertos tocar. Los demás no hacen el viaje.
Por eso un 35B “no debería caber” en 12 GB y, aun así, en la demo está generando a más de 60 tok/s. No es que la 4070 se haya vuelto una 4090. Es que no está encendiendo las 35 bombillas.
¿Cómo elegir el número de -ncmoe según tu VRAM?
Pruebas, miras el monitor de GPU y te quedas con el número más bajo que no te desborde la VRAM.
Si no pones bandera, llama.cpp tiende a cargar de forma más “todo a la vez”. En 12 GB, con este Qwen, eso es pedir un milagro o aceptar el swap. El swap es esa sensación de que de pronto va a 4 tok/s y el disco cruje. Ahí no estás midiendo la 4070. Estás midiendo el paginado.
Si pones -ncmoe con un número, le estás diciendo cuántas capas de expertos se van a la CPU. Sube el número y liberas VRAM (más trabajo en RAM, suele bajar el tok/s). Bájalo y dejas más expertos en la GPU (más velocidad, hasta que te pasas y la VRAM explota o empieza a hacer trampas con memoria del sistema).
En mi caso concreto jugué con eso. Acabé en 15, a veces 16. Ese es el rango que me hace funcionar bien esta IQ3_XXS en la 4070 de 12 GB. No es el número de tu 3060, ni el de una 4070 con Q4_K_M, ni el de una 4090. Es el mío, con este archivo de ~13 GB y este contexto.
La receta práctica es aburrida y es la que funciona. Empieza alto si tienes miedo al OOM. Mira VRAM con nvidia-smi o el monitor que uses. Si sobra gráfica y quieres más ritmo, baja de uno en uno. Si pega contra el techo o cae el tok/s de golpe, súbelo. El golpe de velocidad hacia abajo casi siempre es VRAM que se ha ido a RAM sin que tú lo hayas pedido.
Cierra Chrome pesado, cierra otra instancia de llama.cpp de ayer, cierra el Stable Diffusion que se te olvidó. En 12 GB no hay holgura para un segundo inquilino. En el vídeo lo digo sin drama: según la carga del ordenador, un día me va a 70 y al siguiente a 62.
Mide. Un número que leíste en un hilo no sustituye a tu gráfica, tu RAM y tu cuantización.
¿Qué cuantización Unsloth usar y qué tok/s esperar?
En el vídeo uso Unsloth IQ3_XXS (~13 GB). El ~62 / ~70 tok/s es de esa quant, en esa 4070, no de “Qwen 35B en cualquier 12 GB”.
IQ3_XXS es agresiva. Cabe mejor. Te deja más sitio para dejar expertos en GPU con un -ncmoe relativamente bajo (mi 15). El recorte es calidad respecto a un Q4. Para una landing, un borrador o un chat de trabajo, a mí me sirve. Si tu listón es más alto, sube de quant y asume que vas a tener que empujar más expertos a la CPU.
Q4_K_M (y las UD-Q4 de Unsloth) pesan más, del orden de 20 GB el archivo. En 12 GB no “casi cabe”. Ahí el flag suele tener que ser más agresivo. Ken Imoto, con Q4_K_M en una 4070, acabó con los expertos en CPU y ~34,6 tok/s frente a ~12,2 de Ollama. Mismo tamaño de tarjeta, otra quant, otro número. Por eso no copies mi 15 si estás en Q4.
InsiderLLM midió el 35B-A3B en una RTX 3060 de 12 GB con otra config y salió ~38,9 tok/s con offload de expertos (y avisaron que el punto más rápido que apenas cabía se iba a OOM en cuanto crecía el contexto). Otra tarjeta, otra quant, otro protocolo de medida. Te lo cuento para que no conviertas ni el 70 ni el 38 ni el 34 en ley.
La regla útil es una sola. Elige la quant más gorda que tu VRAM + -ncmoe puedan sostener sin swap. Luego mide tok/s con un prompt de generación de verdad, no con la primera frase de cortesía. Si activas el modo pensamiento, el contador puede verse “bien” y el tiempo hasta una respuesta útil se alarga, porque primero escribe el borrador interno.
El GGUF lo tienes en huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF. El modelo base está en Qwen/Qwen3.6-35B-A3B.
¿Qué aporta la KV cache en q8_0?
Te deja pedir más contexto sin que la caché de atención se coma la VRAM que acabas de ganar con el MoE.
Cada token que entra se guarda como claves y valores de atención. Si esa caché va en alto bit, un contexto de 32k se vuelve un segundo modelo escondido dentro de la gráfica. En 12 GB no hay sitio para dos inquilinos gordos.
--cache-type-k q8_0 --cache-type-v q8_0 comprime esa caché. En el comando del vídeo pido 32.768 de contexto con esa quant. No es un extra de postureo. Es lo que hace que el -ncmoe 15 no se ahogue en cuanto la conversación deja de ser un saludo.
Guías de Qwen3.6 en llama.cpp (Amine Raji, InsiderLLM) insisten en lo mismo: el q8_0 de la KV es de las palancas que Ollama no te pone tan a mano, y es de las que más sitio liberan cuando quieres ventana larga. El tok/s de generación casi no se resiente. Lo que ganas es que el 35B siga vivo a 16k o 32k en una tarjeta que, sin eso, ya estaba llena a 8k.
¿Cómo instalar llama.cpp con CUDA (incluida WSL2)?
El ejecutable “fácil” de Windows no te deja la GPU lista. Toca generar una build con CUDA para tu gráfica.
Esta es la pega, y es la razón por la que no todo el mundo usa llama.cpp aunque el flag sea gratis. Instalar no es ciencia ficción. Tampoco es un doble clic y a correr. Hay que jugar un poco con el terminal.
Cuando vas a descargar, tienes Windows, Linux, etc. Yo me bajé la vía Windows. El problema es que esa versión empaquetada no venía configurada para mi tarjeta. La gráfica está. Los drivers están. El binario, no. Si lo lanzas así, o va por CPU o no aprovecha la 4070 como en la demo.
Lo que toca es bajar el código fuente del repo y generar la versión con CUDA, con los drivers concretos de tu GPU. En mi máquina el entorno de esta demo es WSL2 con Ubuntu 22.04, 64 GB de RAM y la 4070 de 12 GB. En WSL2 se añade otra piedra típica: Windows puede tener el driver NVIDIA, y dentro de Ubuntu todavía te falta el toolkit CUDA para compilar. Sin eso, cmake no te arma el binario que habla con la gráfica.
La receta general (la que sale en las guías, no un conjuro mío) es clonar github.com/ggml-org/llama.cpp, configurar con CUDA y compilar. El espíritu es este:
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -jNo te asustes si la primera vez se hace largo. Baja fuente, genera la build, comprueba con nvidia-smi que la GPU se mueve cuando lanzas llama-cli. Si algo falla, copia el artículo o el error y pásaselo a tu IA. Que te lo traduzca a tu distro, tu versión de CUDA y tu tarjeta. Eso es exactamente lo que haría yo si me pierdo en un flag de cmake.
Un aviso con fuente, porque aquí sí duele: varias guías (InsiderLLM, Amine Raji) dicen que CUDA 13.2 ha dado salidas basura con quants bajas de Qwen3.6. Si el modelo “habla raro”, mira la versión del toolkit antes de tirar el GGUF. 13.1 o 13.3 salen como camino más sano en esas páginas.
Si te interesa que me pegue con estos comandos en cámara, que me veas sudar el WSL2 y el cmake, dímelo. Estoy pensando en una comunidad justo para el contenido que aquí se haría eterno. Abajo te dejo dónde estamos.
¿Necesitas mmproj para Qwen3.6 multimodal?
Solo si quieres visión. En el vídeo el trabajo es texto: una landing, un gráfico pedido por prompt. No hay foto de entrada.
Qwen3.6-35B-A3B puede ir con un archivo aparte, el mmproj, que es el proyector de visión. Guías de llama.cpp (Amine Raji, InsiderLLM) dejan claro que para multimodal hace falta ese sidecar. Sin él, tienes el modelo de texto. Ollama, además, históricamente ha ido más justo cableando ese mmproj que llama.cpp.
Si tu caso es “que me escriba la página” o “que me razone un texto”, no te compliques. Descarga el GGUF Unsloth y tira. Si tu caso es “que mire este pantallazo”, entonces sí: mmproj junto al modelo, y llama.cpp que lo acepte.
Cuando algo falla
Sin postureo. Piedras reales, las del vídeo y las que te vas a encontrar al copiar el comando:
- El .exe de Windows no usa tu GPU — es la pega del vídeo. El paquete fácil no trae CUDA listo para tu tarjeta. Baja fuente y genera la build con
GGML_CUDA=ON. En WSL2, instala el toolkit CUDA dentro de Ubuntu, no asumas que con el driver de Windows basta para compilar. - La VRAM se va a swap y el tok/s se hunde — sube
-ncmoe(más expertos a CPU), baja contexto o cierra lo que esté ocupando gráfica. Si ves 4 tok/s de pronto, casi nunca es “el modelo es malo”. Es memoria que se ha ido al disco. - Copiaste
-ncmoe 15y no te cabe o va lento — 15 es el mío con IQ3_XXS en una 4070 de 12 GB. Con Q4_K_M o con una 3060 el número cambia. No es un código que se pegue y ya. Sweeps de la comunidad (LocalLLaMA, Ken Imoto) van recorriendo el entero hasta que la VRAM aguanta y el tok/s no cae. - No te salen ~70 tok/s — normal. ~70 es el pico de esta demo en esta máquina. En pantalla salió ~62. Otras 12 GB publican ~35 o ~39 con otras quants. Compara en igualdad de archivo, flags y contexto. Y mide.
- El modelo suelta basura — mira CUDA (el aviso de 13.2), mira que el GGUF no esté a medias, mira que no estés mezclando un mmproj de otro modelo.
- Quieres visión y no carga o no “ve” — falta el mmproj adecuado. Sin él, solo hay texto.
¿Para qué me sirve (y para qué no)?
Me sirve para correr un MoE grande en casa a un ritmo de trabajo, cuando Ollama se me queda corto de mando. Me sirve para una landing, un borrador, un gráfico, un chat largo, sin pagar la API por cada token.
No me sustituye un Claude de pago cuando quiero el techo de calidad. Y no es “instalar y olvidar”. El precio del control es un rato de terminal, sobre todo la primera vez que compilas con GPU.
Si lo que te frena no es el tok/s sino traducir un EPUB entero sin destrozar el formato, aquí dejo cómo traducir libros completos con Ollama.
Repo otra vez: github.com/ggml-org/llama.cpp. Modelo: Unsloth GGUF Qwen3.6-35B-A3B.
Si te interesa seguir quitándote suscripciones y exprimiendo lo que ya tienes en el PC, en la comunidad dejo más de este tipo de cosas: Skool — Mis Ingresos Pasivos. Y si quieres que el siguiente vídeo sea yo compilando llama.cpp con CUDA en WSL2, sin cortar, dímelo.
Pruébalo, mide en tu gráfica, y nos vemos en el siguiente.
