Modelos locales vs en la nube: Qwen-3.6-27B, Gemma-4-31B, Claude Haiku, Codex-Spark en generación de código complejo

Un usuario de Reddit comparó Qwen-3.6-27B ejecutado localmente (GGUF q4_k_m) contra equivalentes de API: Qwen-3.6-27B a través de OpenRouter, Gemma-4-31B a través de OpenRouter, Claude Haiku 4.5 y GPT-Codex-Spark. La prueba consistió en implementar un bucle de auto-investigación a partir de un documento de diseño, una tarea deliberadamente difícil para evaluar la limpieza del fallo, no la tasa de éxito.

Configuración de hardware

• CPU: Ryzen 7 7800X3D
• RAM: 64 GB DDR5-6400
• GPU: RTX 5080 (16 GB VRAM)
• Modelo local: Qwen-3.6-27B q4_k_m (GGUF) — cabe en 16 GB VRAM mediante cuantización

Resultados

• Gemma-4-31B (API): Falló completamente. Escribió un esqueleto con módulos simulados, sin pruebas, sin archivos de configuración (__init__.py, requirements.txt, pyproject.toml). Costo: $0.112, 803k tokens de contexto consumidos, 21k generados.
• Codex-Spark (API): Produjo una hermosa estructura de carpetas y código, pero las importaciones fueron alucinadas. Sin pruebas unitarias. Usó el 1% de los límites de Spark de $100/mes.
• Claude Haiku 4.5 (API): Implementación detallada pero falló en corrección. (Más detalles truncados en la fuente.)
• Qwen-3.6-27B (local q4_k_m): No se puntuó explícitamente, pero el usuario señala que la inferencia cuantizada degrada la calidad en comparación con la versión API de precisión completa.

Contexto

El usuario argumenta que las evaluaciones típicas de modelos locales usan tareas triviales (por ejemplo, Snake en HTML) donde tanto los modelos locales como los fronterizos tienen éxito, haciendo que los modelos locales parezcan mejores de lo que son. Esta prueba utilizó un proyecto de trabajo real con un documento de diseño; solo Codex-Spark produjo código completamente escrito (pero con errores). El punto: los modelos locales aún no están listos para la generación de código complejo sin correcciones sustanciales.