Mejores LLMs para coding agéntico local con 128 GB de VRAM

Con 128 GB de VRAM puedes correr modelos como Qwen3.5-122B-A10B (cuantizado a NVFP4, 75,6 GB) con calidad cercana a Claude Opus 4.6 para tareas agénticas, sin pagar por API. La clave está en combinar vLLM con FP8 KV cache y un contexto de 256K tokens para workflows con Cline y n8n. Esta guía detalla qué modelo elegir según el tipo de tarea y cómo configurarlo correctamente en marzo de 2026.

El problema de seleccionar un LLM local para agentes de coding

La mayoría de comparativas de modelos locales miden generación de código puntual. Pero un agente de coding no hace eso: llama herramientas, mantiene contexto durante decenas de pasos, edita archivos, ejecuta comandos y reacciona a errores. Un modelo puede puntuar bien en HumanEval y fallar sistemáticamente en un loop agéntico con Cline.

Con 128 GB de VRAM, la restricción de memoria deja de ser el cuello de botella principal. El problema se convierte en otro: qué modelo maximiza la fiabilidad en tool calling, sigue instrucciones multi-paso y mantiene coherencia en contextos largos. Si ya usas Claude Code con modelos locales, sabes que la elección del modelo afecta directamente al coste y la calidad de cada sesión. Con 128 GB, el abanico se amplía considerablemente.

¿Qué es coding agéntico y por qué el modelo importa más de lo que parece?

Coding agéntico es la capacidad de un LLM para completar tareas de programación de múltiples pasos de forma autónoma: leer archivos, escribir código, ejecutar tests, interpretar errores y corregirlos sin intervención humana continua. No es generación de código, es orquestación de acciones.

Para este tipo de tarea, los benchmarks relevantes no son HumanEval ni MBPP:

• SWE-Bench Verified: resolución de issues reales de GitHub con tests que pasan
• BFCL-V4: fiabilidad en function calling con herramientas reales
• Terminal-Bench 2.0: razonamiento en entornos de terminal
• Tau2-Bench: planificación multi-paso en tareas agénticas complejas

La diferencia entre un modelo que pasa benchmarks de código y uno que funciona en un agente real es exactamente lo que separa los prototipos de los sistemas de producción.

Los candidatos: qué modelos caben en 128 GB

Qwen3.5-122B-A10B (NVFP4)

El modelo de referencia actual para 128 GB de VRAM. Alibaba lanzó Qwen3.5 el 16 de febrero de 2026 con arquitectura MoE: 122B parámetros totales, 10B activos por paso. La versión NVFP4 cuantizada ocupa 75,6 GB, dejando aproximadamente 52 GB para KV cache y overhead de vLLM.

Sus números en benchmarks agénticos son los mejores del ecosistema open-source a esta fecha: BFCL-V4 de 72,2 (frente a 55,5 de GPT-5 mini), Terminal-Bench 2.0 de 52,5 y Tau2-Bench de 86,7. Solo Claude Opus 4.6 supera consistentemente este último con 91,6. La ventana de contexto nativa es de 262.144 tokens.

La velocidad de inferencia en hardware con 128 GB de memoria unificada ronda los 8-15 tokens por segundo. Para uso interactivo con Cline, es suficiente. Para pipelines batch en n8n con muchas peticiones en paralelo, puede quedarse corto.

Aviso crítico: la versión NVFP4 con vLLM requiere patches específicos para el bloque Qwen3NextGatedDeltaNet. Sin ellos, las 36 capas GDN producen salida cero y el modelo genera texto incoherente. El repositorio de referencia incluye un Docker build multi-etapa con todos los patches aplicados y FlashInfer compilado desde fuente.

DeepSeek V3.2

685B parámetros totales, 37B activos (MoE). Cuantizado a FP4 cabe en 128 GB con margen. Su punto fuerte es la generación de código: 90% en LiveCodeBench y 72,8% en SWE-Bench Verified, rozando el 74,1% de Claude Opus 4.6. Donde pierde frente a Qwen3.5 es en tool calling y planificación multi-paso. Para generación puntual de C++ o Fortran, DeepSeek V3.2 puede dar mejor resultado. Para un agente que necesita llamar herramientas en bucle durante 20 pasos, Qwen3.5 es más fiable.

Qwen3-Coder-Next

80B parámetros totales, solo 3B activos. La arquitectura ultra-sparse hace que quepa cómodamente en 128 GB en Q8_0 (aproximadamente 85 GB), con ventana de contexto de 170K tokens. Para tareas de coding agéntico sobre codebases medianas, su ratio rendimiento/velocidad es difícil de superar: alcanza nivel Sonnet 4.5 con menos de la mitad de los recursos de cómputo activo, a 20-35 tokens por segundo.

Tabla comparativa: cuándo usar cada modelo

Modelo	VRAM cuantizado	BFCL-V4	SWE-Bench	Velocidad	Mejor para
Qwen3.5-122B NVFP4	75,6 GB	72,2	N/D	8-15 tok/s	Agentes con tool calling, contexto largo
DeepSeek V3.2 (FP4)	~90 GB	N/D	72,8%	10-18 tok/s	Generación C++/Fortran puntual
Qwen3-Coder-Next Q8	~85 GB	N/D	44,3%	20-35 tok/s	Velocidad, Python/TS, codebases medianas

Setup: vLLM con FP8 KV cache para 256K tokens

La configuración por defecto de vLLM desperdicia memoria en KV cache. Para 128 GB con contextos largos, el parámetro clave es --kv-cache-dtype fp8, que reduce el consumo del cache a la mitad con impacto mínimo en calidad. Estimación práctica: con FP8 KV cache, 256K tokens de contexto consumen aproximadamente 44,8 GB en un modelo de 70B. Con Qwen3.5 NVFP4 ocupando 75,6 GB, tienes margen para contextos largos en una sola sesión.

vllm serve Qwen/Qwen3.5-122B-A10B-NVFP4 \
  --quantization nvfp4 \
  --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.95 \
  --max-model-len 262144 \
  --enable-chunked-prefill \
  --dtype bfloat16

Si el proceso termina con OOM durante el warmup, reduce primero --gpu-memory-utilization a 0.88. Si sigue fallando, baja --max-model-len a 131072. El contexto de 256K es el techo teórico; en la práctica, codebases de 50K-100K tokens son el caso de uso habitual.

Para el patch NVFP4 específico de Qwen3.5, usa el Docker build oficial que compila FlashInfer para SM121 y aplica los patches sobre vLLM nightly. No intentes aplicar los patches manualmente sobre una instalación estándar: las dependencias de versión son demasiado específicas.

Integración con Cline y n8n

Una vez que vLLM sirve el modelo, configurar Cline es directo. Apunta al endpoint local con la API compatible con OpenAI que expone vLLM:

{
  "apiProvider": "openai",
  "openAiBaseUrl": "http://localhost:8000/v1",
  "openAiApiKey": "local-key",
  "openAiModelId": "Qwen/Qwen3.5-122B-A10B-NVFP4",
  "contextWindow": 131072,
  "maxTokens": 8192
}

El parámetro contextWindow es crítico: si lo dejas en el valor por defecto de Cline, truncará el contexto del codebase antes de enviarlo al modelo y perderás la mayor ventaja de estos modelos grandes.

Para n8n, el nodo "OpenAI" acepta una base URL personalizada, sin adapter adicional. Para pipelines donde el agente procesa archivos en batch, vLLM ofrece mayor throughput que Ollama, especialmente con sesiones concurrentes. El patrón de boss agent con ciclo de crítica funciona bien aquí: el modelo local actúa como agente ejecutor y reservas las llamadas a Claude para validación final.

C++ y Fortran: el caso especial

Los benchmarks de coding agéntico están dominados por Python y TypeScript. Para C++ y especialmente Fortran, la situación es diferente. DeepSeek V3.2 lidera en LiveCodeBench (90% pass rate) con problemas que incluyen C++ competitivo. Para Fortran, ningún modelo open-source tiene entrenamiento específico documentado.

El patrón que mejor funciona con lenguajes no predominantes en los datos de entrenamiento: usa el modelo local para entender el código existente y proponer cambios, con verificación humana más activa. El contexto de 256K es especialmente útil aquí: puedes incluir toda la base de código Fortran relevante antes de pedir modificaciones, algo que no era posible con hardware de 24-48 GB.

En Producción

Correr un LLM de 122B parámetros en local tiene implicaciones que los benchmarks no capturan.

Consumo eléctrico: Una GPU de gama alta en carga plena consume entre 350 W y 700 W. Para un agente procesando tareas de coding de forma continua, estima entre 2,5 y 5 kWh diarios. A precios eléctricos europeos (aproximadamente 0,20 €/kWh), son entre 15 y 30 € al mes. No es trivial si el hardware ya está amortizado, pero sí si lo alquilas en cloud.

Time to first token: Con Qwen3.5-122B NVFP4 en vLLM, el TTFT en prompts largos puede superar los 10 segundos. Para workflows interactivos con Cline, se siente lento. Para pipelines batch en n8n que procesan archivos en segundo plano, no importa.

Estabilidad de vLLM nightly: Fija la versión del contenedor Docker en producción. Los patches para NVFP4 de Qwen3.5 son específicos de versión y una actualización automática puede romper el setup silenciosamente.

Temperatura de generación: Para coding agéntico, usa temperature entre 0 y 0,2. Valores más altos aumentan la creatividad pero también la probabilidad de que el modelo desvíe el formato de tool calling. Si el modelo empieza a fallar en loops agénticos largos, temperature es el primer parámetro que revisar.

Si tu objetivo es reducir el coste de API mientras mantienes calidad, el patrón híbrido funciona mejor que sustituir completamente la API. Puedes implementar LLM fallback para hacer resiliente el sistema: modelo local como primario, Claude como fallback en pasos críticos.

Errores comunes y depuración

Error: el modelo genera texto aleatorio o repeticiones desde el primer token.
Causa: patches NVFP4 no aplicados; las capas GDN producen salida cero.
Solución: usa el Docker build con patches incluidos. No instales vLLM de pip directamente.

Error: OOM durante la inicialización de vLLM.
Causa: --gpu-memory-utilization demasiado alto o --max-model-len excesivo.
Solución: baja a 0.88 y 131072 respectivamente, luego sube gradualmente probando estabilidad.

Error: Cline trunca el contexto del codebase de forma inesperada.
Causa: contextWindow en el valor por defecto de Cline (generalmente 4K o 8K).
Solución: configura explícitamente "contextWindow": 131072 en la configuración del provider.

Error: tool calling inconsistente en loops agénticos largos.
Causa: temperatura alta o system prompt que sobreescribe el formato de herramientas.
Solución: fija temperature: 0 para coding agéntico y revisa que el system prompt no entre en conflicto con las instrucciones de herramientas del modelo.

Preguntas frecuentes

¿Puedo usar Ollama en lugar de vLLM para estos modelos?

Para modelos hasta 70B cuantizados, Ollama funciona bien. Para Qwen3.5-122B NVFP4, necesitas vLLM porque los patches NVFP4 no están disponibles en Ollama. Además, vLLM ofrece mayor throughput en sesiones concurrentes, lo que importa si tienes varios agentes corriendo a la vez.

¿Qwen3.5-122B supera a Claude Opus 4.6 para coding agéntico local?

No de forma general. Claude Opus 4.6 sigue siendo superior en Tau2-Bench (91,6 vs 86,7) y en planificación multi-paso compleja. Qwen3.5 se acerca en tool calling puntual (BFCL-V4: 72,2) pero la brecha en contextos muy complejos sigue siendo medible. Para casos donde la privacidad o el coste justifican el hardware local, Qwen3.5-122B es la mejor opción open-source disponible hoy.

¿Con 64 GB de VRAM tiene sentido intentar esto?

Con 64 GB tienes acceso a Qwen3-Coder-Next en Q4_K_M (aproximadamente 46 GB), que ofrece nivel Sonnet 4.5 para coding. No es la misma clase que Qwen3.5-122B, pero para Python, TypeScript y codebases medianas es una opción práctica. El salto cualitativo real para coding agéntico ocurre en el rango de 96-128 GB de VRAM.

Conclusión

Los modelos locales para coding agéntico han cruzado un umbral en 2026. Con 128 GB de VRAM y Qwen3.5-122B cuantizado a NVFP4, tienes un modelo open-source que se acerca a Claude en tool calling y supera a GPT-5 mini en benchmarks agénticos, corriendo completamente en local. La elección entre candidatos no es obvia: si tu prioridad es generación de código C++ o Fortran puntual, DeepSeek V3.2 puede ser más fiable. Si necesitas un agente que mantenga coherencia durante decenas de pasos con herramientas, Qwen3.5-122B es el candidato actual. Si el throughput importa más que la capacidad máxima, Qwen3-Coder-Next en Q8 da el mejor ratio de rendimiento por watt.

El setup con vLLM y FP8 KV cache no es trivial, pero una vez configurado el workflow con Cline y n8n funciona sobre la misma API compatible con OpenAI que ya conoces. La inversión en configuración se recupera si el agente trabaja de forma intensiva.

¿Tienes hardware local con 128 GB o más y has probado alguno de estos modelos en producción? Cuéntame cómo te ha ido en los comentarios o en Twitter @sergiomarquezp_. El próximo artículo entra en el benchmark SWE-CI de Alibaba y qué revela sobre las limitaciones reales de los agentes de coding en mantenimiento de código a largo plazo.