Qwen3.6-27B como Capa de Razonamiento Local: Resultados de 2 Semanas de Prueba Multi-Agente

Un desarrollador reemplazó Claude con Qwen3.6-27B en un orquestador multiagente durante dos semanas, ejecutándose completamente en una sola RTX 3090. El objetivo era directo: probar si un modelo local podía servir como capa de razonamiento — bucle líder/gestor/subagente — en flujos de trabajo de codificación reales. Los resultados ofrecen cifras concretas para quienes consideran reducir costos en la nube.

Configuración y Línea Base

• Hardware: RTX 3090, 24GB VRAM
• Modelo: Qwen3.6-27B en cuantificación Q6_K (~22GB en GPU), contexto efectivo 32k
• Motor de inferencia: Ollama
• Orquestador: Sistema multiagente con planes JSON estructurados, modal de aprobación de planes, y pase de revisión automática tras la finalización del subagente
• Carga de trabajo: 47 flujos de trabajo de codificación de varios pasos en dos repositorios reales

Lo que Funcionó (La Capa de Razonamiento)

Generación de planes. Qwen3.6 generó planes de varios pasos casi tan bien como Claude en estas tareas. Un poco más conservador — menos sugerencias de refactorización no solicitadas — pero coherente y con esquema válido ~95% del tiempo después de ajustes en el prompt. El 5% restante se solucionó con un solo re-prompt.

Extracción de memoria. La extracción de hechos al estilo Mem0 cada 6 turnos funcionó bien. Qwen extrajo los mismos hechos que Claude (por ejemplo, "al usuario no le gustan los comentarios a menos que expliquen un 'por qué'") y los almacenó limpiamente en Qdrant.

Revisión automática de la salida del subagente. Una segunda instancia de Qwen revisando el código de la primera detectó ~60% de los errores que la revisión de Claude detectó en el mismo conjunto. Menos agresivo, aún útil y gratuito.

Donde Falló

Fiabilidad de llamadas a herramientas. La salida JSON de llamadas a herramientas de Qwen3.6 tuvo una tasa de error de formato de ~12% en 47 tareas. Claude tuvo ~0.5% en la misma carga de trabajo. Los errores no eran JSON malformado — eran nombres de campo incorrectos, tipos incorrectos, firmas de herramientas alucinadas. Usar Outlines o modo de salida estricta redujo los errores pero no los eliminó.

Deriva de contexto largo. Pasados ~14k tokens de contexto de sesión acumulada, Qwen comenzó a recordar mal decisiones (por ejemplo, "dijiste que uses Postgres" cuando se dijo lo contrario). El límite práctico efectivo es ~12k tokens, luego resumir y reiniciar agresivamente.

Manejo de fallos en cascada. Cuando un subagente fallaba, el planificador de Claude generalmente lo notaba y replanificaba. Qwen a veces generaba pasos posteriores asumiendo que el subagente había tenido éxito. Tres alucinaciones en cascada en 47 ejecuciones — no catastrófico con compuertas de planificación, pero lo sería sin ellas.

Implicaciones Prácticas

La opinión del desarrollador: "Qwen3.6-27B es una capa de razonamiento viable para sistemas multiagente locales hoy. NO es una capa de ejecución viable." Si estás construyendo agentes solo locales, necesitas:

1. Imposición de salida estructurada en el límite de llamadas a herramientas (Outlines, lm-format-enforcer o modo de gramática de tu motor de inferencia)
2. Compuertas de aprobación de planes para que los errores de formato del 12% nunca lleguen a escrituras de archivos reales
3. Lógica de replanificación en caso de fallo — no se puede confiar en que el modelo maneje fallos en cascada

La brecha de error del 12% en llamadas a herramientas es la métrica a observar. Una vez que Qwen3.6 o el próximo modelo local alcance ~2% en esta métrica, el caso para el razonamiento en la nube en bucles de agentes se debilita considerablemente.