¿Cómo Reducir los Tokens de Razonamiento de Gemma 4? ThinkingCap Explicado

ThinkingCap es una versión reentrenada de Gemma 4 26B-A4B de Google que usa, en promedio, un 38.9 por ciento menos de tokens de razonamiento con casi la misma precisión: 75.0 frente a 75.2 del modelo base en doce benchmarks. BottleCap AI lo publicó el 23 de octubre de 2026 bajo licencia Apache 2.0, con los pesos completos y versiones GGUF en Hugging Face.

https://huggingface.co/bottlecapai/ThinkingCap-gemma-4-26B-A4B-it

Es un reemplazo directo (drop-in replacement): solo cambian los pesos. La plantilla de chat, el tokenizador y la configuración de muestreo recomendada son los del modelo base. Todas las cifras son mediciones de la propia BottleCap: están bien hechas, pero nadie las ha reproducido de forma independiente todavía. Y, como muestra la ficha GGUF del mismo equipo, el ahorro no llega intacto a los archivos que la mayoría ejecuta en local.

¿Qué son los tokens de razonamiento y por qué conviene reducirlos?

Los tokens de razonamiento (reasoning tokens o thinking tokens, en inglés) son el texto que un modelo se escribe a sí mismo antes de responder: el borrador donde resuelve el problema paso a paso. Casi nunca lo lees, pero lo pagas entero en tiempo, en energía y en ventana de contexto.

En problemas de matemáticas difíciles, Gemma 4 26B escribe entre 15,000 y 22,000 tokens de razonamiento por pregunta. Recortar un tercio de eso cambia cuánto esperas cada respuesta y cuántas peticiones puede atender una sola máquina. La propuesta de BottleCap es exactamente esa: las mismas respuestas, con menos pensamiento por el camino.

¿Qué es Gemma 4 26B-A4B?

gemma-4-26B-A4B-it es el modelo intermedio de la familia Gemma 4 de Google DeepMind, con arquitectura de mezcla de expertos (mixture of experts, MoE). Almacena unos 26,000 millones de parámetros, pero activa solo alrededor de 4,000 millones por token: en cada paso se ejecutan 8 de sus 128 expertos. Eso le da el conocimiento de un modelo grande con un costo de cómputo cercano al de uno pequeño. También acepta imágenes como entrada.

Su modo de razonamiento está apagado por defecto: cada petición tiene que activarlo con enable_thinking. Todas las cifras de ThinkingCap se midieron con el razonamiento activado, así que si ejecutas el modelo sin él, no hay nada que ahorrar.

¿Cuántos tokens de razonamiento ahorra ThinkingCap?

En promedio, un 38.9 por ciento en doce benchmarks. Pero el ahorro varía mucho según la tarea:

Benchmark	Precisión base	Precisión ThinkingCap	Tokens base	Tokens ThinkingCap	Reducción
LongBench v2	59.43	60.88	9,486	2,934	69.1%
AA-LCR	64.62	60.62	6,519	2,655	59.3%
MMLU-Pro	84.55	84.64	3,907	1,989	49.1%
GPQA-Diamond	79.92	78.96	7,699	4,284	44.4%
AIME 2026	86.20	86.72	14,766	8,963	39.3%
HMMT (feb. 2026)	72.92	74.20	22,005	14,717	33.1%
LiveCodeBench v6	76.98	76.96	11,560	8,375	27.6%
τ²-bench	64.25	63.73	4,374	3,466	20.8%
IFBench	76.83	78.67	6,470	5,585	13.7%
Promedio (12 benchmarks)	75.2	75.0	8,773	5,398	38.9%

Selección de filas; la tabla completa de doce benchmarks está en la ficha del modelo.

Las tareas de contexto largo y de conocimiento son las que más recortan; el código recorta menos. El seguimiento de instrucciones y el uso de herramientas en modo agente apenas cambian. La explicación de BottleCap es que esas tareas no consisten en pensar mucho, sino en cumplir una lista de restricciones o una política fija.

La segunda mejora es menos evidente y quizá más útil en la práctica: menos bucles. El modelo base se queda repitiendo el mismo razonamiento en el 3.64 por ciento de sus respuestas; ThinkingCap, en el 0.76 por ciento. En el conjunto de matemáticas más difícil (HMMT de febrero de 2026), los bucles bajan del 17.0 al 4.5 por ciento. Una respuesta en bucle es una respuesta perdida: corre hasta el límite de tokens y no devuelve nada.

¿ThinkingCap pierde precisión frente a Gemma 4?

En promedio, casi nada: 0.15 puntos. Cinco de los doce benchmarks incluso salen ligeramente por delante. Pero "sin pérdida de calidad" es un promedio, no una garantía. Cuatro benchmarks se mueven más de lo que explica el ruido entre ejecuciones:

• AA-LCR (razonamiento sobre contexto largo): −4.00 puntos. BottleCap lo reconoce como el único costo real del conjunto. Si tu trabajo consiste en razonar sobre documentos muy largos, pruébalo antes de cambiar.
• GPQA-Diamond: −0.96 puntos, y MMMLU (multilingüe): −0.66 puntos.
• IFBench (seguimiento de instrucciones): +1.83 puntos, esta vez a favor de ThinkingCap.

En cuanto al método, la evaluación es más sólida que la mayoría de las cifras autodeclaradas:

• Ambos modelos medidos por ellos mismos. BottleCap ejecutó el modelo base en lugar de citar las cifras de Google, con el mismo arnés de evaluación, el mismo hardware y la misma configuración de muestreo para los dos.
• Muchas semillas por benchmark. Cada uno se ejecutó entre 4 y 64 veces, con intervalos de confianza del 95 por ciento.
• El entorno de servicio: vLLM 0.26.0 sobre una NVIDIA GB300 por servidor, con los pesos completos en bf16.

Ese último detalle importa si piensas ejecutarlo en tu propia máquina.

¿Se mantiene el ahorro con la cuantización GGUF en llama.cpp?

Solo en parte, según los propios números de BottleCap. El equipo probó su archivo GGUF recomendado (MXFP4_MOE, 16.6 GB) en llama.cpp frente al ThinkingCap en bf16, en nueve de los doce benchmarks. Con la cuantización, la longitud del razonamiento se desplaza en ambas direcciones:

• AIME 2026: 15.5 por ciento más tokens de razonamiento que la versión bf16
• IFBench: 6.9 por ciento más
• GPQA-Diamond: prácticamente igual
• MMLU-Pro: 8.0 por ciento menos
• HMMT (feb. 2026): 25.0 por ciento menos

La ficha añade que incluso el GGUF sin cuantizar (BF16) en llama.cpp piensa más que el checkpoint original servido con vLLM: un 6.1 por ciento más en AIME y un 14.7 por ciento más en GPQA. Es decir, el propio runtime cambia la longitud del razonamiento, al margen de la cuantización.

Lo que no se ha publicado es la comparación que de verdad le importa a quien trabaja en local: Gemma 4 base en GGUF frente a ThinkingCap en GGUF, en la misma máquina. Al momento de publicar esta nota (24 de octubre de 2026), ni BottleCap ni nadie más había publicado esa medición. Espera un ahorro real en local, pero no cuentes con el 38.9 por ciento completo.

¿Cómo usar ThinkingCap con llama.cpp u Ollama?

BottleCap documenta llama.cpp. Estos comandos vienen de su ficha GGUF:

# serve an OpenAI-compatible endpoint, thinking on, with the base model's recommended sampling
llama-server -hf bottlecapai/ThinkingCap-gemma-4-26B-A4B-it-GGUF:MXFP4_MOE \
  --jinja --chat-template-kwargs '{"enable_thinking":true}' --reasoning-format deepseek \
  --temp 1.0 --top-p 0.95 --top-k 64 -ub 2048 -b 2048

Con --reasoning-format deepseek, el servidor devuelve el razonamiento en reasoning_content y la respuesta en content, así que puedes contar los tokens de razonamiento tú mismo. BottleCap hace dos advertencias:

• Mantén la temperatura en 1.0. La decodificación greedy puede hacer que el modelo entre en bucle.
• Mantén -ub 2048 -b 2048 si envías imágenes. Con el tamaño de lote por defecto de llama.cpp, una imagen grande puede tumbar el servidor.

Ollama, LM Studio y Jan cargan los mismos archivos GGUF. La página de Hugging Face genera este comando para Ollama:

ollama run hf.co/bottlecapai/ThinkingCap-gemma-4-26B-A4B-it-GGUF:Q4_K_M

Ten en cuenta dos cosas. Ese comando descarga Q4_K_M, que según BottleCap rindió peor en matemáticas que MXFP4_MOE. Y la ficha de BottleCap no explica cómo activar el razonamiento en Ollama, LM Studio o Jan; sin razonamiento activado, ThinkingCap no tiene nada que ahorrar. Si quieres medir la diferencia, usa llama.cpp.

¿Qué archivo GGUF descargar?

Archivo	Tamaño	Notas
MXFP4_MOE	16.6 GB	Recomendado por BottleCap; es el que evaluaron
Q4_K_M	17.0 GB	Rindió peor en sus benchmarks de matemáticas que MXFP4_MOE
IQ4_XS	13.6 GB	El más pequeño; sin evaluar por BottleCap
Q6_K / Q8_0	23.3 / 26.9 GB	Más precisión, más memoria
mmproj-…-f16	1.19 GB	Proyector de visión, necesario para enviar imágenes

En equipos con poca memoria, IQ4_XS es el que cabe, pero también es el único sin cifras publicadas. Si ya ejecutas Gemma 4 en local, nuestra guía sobre qué variante de Gemma 4 elegir según la RAM de tu Mac cubre la parte de memoria.

Para servidores con GPU, la ficha principal documenta vLLM, con parsers de razonamiento y de llamadas a herramientas:

vllm serve bottlecapai/ThinkingCap-gemma-4-26B-A4B-it --max-model-len 262144 \
  --reasoning-parser gemma4 --enable-auto-tool-choice --tool-call-parser gemma4

Los pesos completos en bf16 ocupan unos 52 GB.

¿Quién está detrás de ThinkingCap?

BottleCap AI. Es el quinto modelo de su serie ThinkingCap, después de dos variantes de Qwen3 27B, Nemotron 3.5 Lightning de NVIDIA y Qwen3.8-Flash-Next, y el primero construido sobre un modelo de Google. Entre los autores que figuran en la cita del modelo está Tomas Mikolov, conocido por word2vec.

BottleCap también vende una versión comercial "PRO" que, según la empresa, recorta el razonamiento un 62 por ciento en promedio. No hay nada público sobre ella, así que tómalo como un argumento de venta. Al momento de publicar esta nota, la página del modelo gratuito en Hugging Face todavía no mostraba cifras de descargas: es muy reciente.

¿Cuándo conviene usar ThinkingCap?

• Conviene: trabajo con contexto largo, matemáticas y preguntas de conocimiento donde Gemma 4 piensa mucho, y cualquier entorno donde los bucles te hacen perder tiempo o GPU.
• Da igual: seguimiento de instrucciones y uso de herramientas en modo agente, donde el ahorro es pequeño (entre 14 y 21 por ciento).
• Pruébalo antes: razonamiento sobre documentos largos (la caída en AA-LCR) y cualquier configuración GGUF en local, donde la cifra principal no se ha medido.

Como es un reemplazo directo con la misma licencia, la forma más barata de salir de dudas es pasar tus propios prompts por los dos modelos con el razonamiento activado y comparar la longitud de reasoning_content.

---

¿Y tú? ¿Activas el modo de razonamiento cuando ejecutas modelos en local, o lo dejas apagado para ganar velocidad?

Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.

Relacionado: LM Studio, Ollama o llama.cpp: qué corre de verdad en tu máquina