Ollama devuelve una respuesta vacía: el razonamiento (think) se come el contexto

El síntoma

La petición no da error. Tarda bastante más de lo normal y vuelve con el contenido vacío: en la API compatible con OpenAI, choices[0].message.content llega como cadena vacía; en tu programa, eso suele acabar en un «la respuesta no es JSON válido» o en una celda en blanco. Si repites, vuelve a pasar.

La pista está en el uso de tokens. En nuestro caso, la respuesta decía completion_tokens 3.661 y total 4.096: exactamente el tamaño del contexto. El modelo no se colgó; se quedó sin sitio antes de llegar a escribir la respuesta.

Por qué pasa

Modelos como qwen3.5 razonan por defecto: generan una cadena de pensamiento antes de la respuesta final. Esos tokens cuentan dentro de la ventana de contexto igual que tu prompt. Con el contexto que Ollama eligió en nuestro equipo (4.096 tokens; el registro lo dice con la línea «vram-based default context»), un prompt de unos 435 tokens dejaba unos 3.600 para pensar y contestar, y el razonamiento se los comió todos.

Cuánto razona un modelo es difícil de prever. Con otro programa y otro modelo mucho más grande (Strata con Qwen3.8-Flash-Next), medimos hasta 54.512 tokens de razonamiento oculto en una sola respuesta. No es un fallo raro: es lo que hacen estos modelos si no les pones freno.

• Experimento E-05: contexto por defecto y VRAM con Ollama 0.40.14

Arreglo 1: desactivar el razonamiento

Si la tarea es extraer datos, clasificar o rellenar un JSON, normalmente no necesitas que piense. Cada forma de llamar a Ollama tiene su interruptor. En Windows PowerShell, usa Invoke-RestMethod en lugar de curl, que ahí es otro comando y se lleva mal con las comillas del JSON.

Ojo con --hidethinking: según el anuncio oficial de Ollama, solo oculta el razonamiento en la salida, no lo desactiva. El modelo sigue pensando y gastando contexto.

• Ollama: documentación de thinking
• Ollama: anuncio de thinking (opciones de consola)
• Ollama: compatibilidad con OpenAI (reasoning_effort)

Arreglo 2: dejarle pensar, pero con sitio

Si quieres el razonamiento (problemas de varios pasos, revisar un texto con trampas), sube el contexto para que quepan el prompt, la reflexión y la respuesta. Con 32.768 tokens, los modelos pequeños que probamos funcionaron y la velocidad de generación bajó poco (86, 55 y 80 tokens por segundo con qwen3.5:4b, qwen3.5:9b y gemma4:12b). No medimos cuánto razona qwen3.5:9b con ese margen, así que pon también un tope de tiempo en tu programa.

La API compatible con OpenAI no deja cambiar el contexto en la petición; la documentación de Ollama indica crear un modelo propio con un Modelfile.

• IA para leer PDF largos sin que se corte: contexto, RAG o palabras clave
• IA local en Windows: RAM, VRAM y contexto

Cómo comprobar que está arreglado

Repite la misma petición y mira tres cosas: el tiempo (de unos 60 s a unos pocos segundos, en nuestro caso 3,6 s), que completion_tokens sea pequeño y muy por debajo del contexto, y que el contenido no esté vacío y sea JSON válido si lo pediste. En la API nativa, con razonamiento activo, la reflexión aparece en un campo aparte (thinking) y la respuesta en content: si content está vacío y thinking lleno, es este problema.

Y protege tu programa para que no trague en silencio: si el contenido llega vacío, que falle con un mensaje claro en vez de guardar una fila en blanco.

Lo que medimos, con todos los números

Equipo: Windows 11 Pro, NVIDIA RTX 5060 Ti de 16 GB, Ollama 0.40.14. Tarea: extraer las acciones de un acta en JSON, llamando a qwen3.5:9b por la API compatible con OpenAI (/v1) con response_format de tipo json_object.

• Sin desactivar el razonamiento: dos intentos, unos 60 s cada uno, texto vacío; completion_tokens 3.661 de un total de 4.096.
• Con reasoning_effort "none": 3,6 s y JSON válido. Nuestra receta lo añade sola cuando la dirección es local.
• Pero el arreglo no mejora la calidad: qwen3.5:9b dejó responsable y fecha vacíos en lugar de «PENDIENTE» y el validador mandó el acta a revisión con 4 avisos (5 en la segunda acta). gemma4:12b, con el mismo encargo, tardó 11,2 s y pasó sin avisos.
• En el resto de pruebas locales del laboratorio (rendimiento, RAG, OCR, batería de calidad) llamamos a la API nativa con «think»: false desde el principio.

Otras respuestas vacías que no son el razonamiento

• El prompt ya no cabe: un agente como OpenCode envió 22.919 tokens antes del encargo frente a 4.096 de contexto (7.440 con la configuración global vacía). El modelo no llega a ver lo que le pides.
• El modelo no admite think: la documentación indica consultarlo en /api/show; si no lo admite, el interruptor no cambia nada.
• gpt-oss usa niveles (low, medium y high) en lugar de sí o no, según la documentación de Ollama.
• El modelo no carga: si es más grande que tu VRAM puede terminar en error 500. Nos pasó con qwen3.6:35b en 16 GB.

• Experimento: OpenCode con un modelo local de Ollama

Preguntas frecuentes

¿Cómo pongo «no think» en Ollama? En la consola, --think=false al arrancar o /set nothink dentro de la sesión; en la API nativa, "think": false; en la compatible con OpenAI, "reasoning_effort": "none", que es lo que usamos.

¿Cómo desactivo el thinking de Qwen en Ollama? Igual que en cualquier modelo con razonamiento: con qwen3.5:9b, "reasoning_effort": "none" por /v1 lo resolvió en nuestra prueba.

¿Pierdo calidad al desactivarlo? Depende de la tarea. Para extraer datos con un buen encargo, gemma4:12b sin razonamiento sacó 24/24 criterios en nuestra batería de actas con salida JSON. No medimos la misma tarea con razonamiento activo y contexto amplio.

¿Basta con ocultarlo? No: --hidethinking solo oculta la reflexión; el modelo sigue gastando contexto y tiempo.