Qué modelos de coding agéntico caben de verdad en 128 GB de VRAM

Este artículo no ordena modelos de mejor a peor. Los benchmarks que existen hoy para coding agéntico (SWE-bench Verified, BFCL-V4, Tau2-Bench) los mide y publica cada proveedor con su propio agente, su propio scaffold de evaluación y su propio presupuesto de tokens, así que una diferencia de dos décimas entre dos evaluaciones distintas no dice nada fiable sobre cuál modelo es mejor. Lo que sí se puede sostener con evidencia es otra cosa: qué cabe de verdad en un presupuesto fijo de 128 GB de VRAM, con qué cuantización, en qué motor de inferencia, y con cuánto contexto real una vez descontado el KV cache. Ese es el orden que sigue este artículo: primero el presupuesto y sus consecuencias, después los candidatos que sobreviven a la aritmética.

Conviene aclarar algo sobre el hardware antes de empezar: "128 GB de VRAM" no describe una sola máquina. Puede ser un Mac Studio con memoria unificada, dos o tres GPUs de consumo (RTX 3090, 4090, 5090) en paralelo, una A100 o H100 de 80 GB combinada con otra tarjeta, o una GPU Blackwell de última generación. Cada una de esas topologías impone un motor de inferencia y un formato de cuantización distintos, y esa restricción de hardware, no el score de un benchmark, es la que decide qué modelo puedes ejecutar de verdad.

El presupuesto manda: por qué los parámetros activos no dicen nada de tu VRAM

La mayoría de los modelos de esta lista son Mixture-of-Experts (MoE): en cada paso de inferencia solo se activa un subconjunto de los expertos del modelo, y ese subconjunto es el que determina cuánto cómputo (FLOPs) hace falta para generar un token. Ahí es donde los parámetros activos importan: menos parámetros activos significa inferencia más rápida y más barata en cómputo por token.

Lo que los parámetros activos no determinan es cuánta VRAM necesitas. Un modelo MoE tiene que mantener en memoria todos sus expertos, activos o no en un paso concreto, porque el router puede enviar cualquier token a cualquier experto. La VRAM que ocupan los pesos depende del número total de parámetros y de la cuantización elegida, no de cuántos parámetros se activen por token. Confundir ambas cosas lleva a un error práctico concreto: un modelo con pocos parámetros activos pero muchos parámetros totales no deja automáticamente más margen de VRAM que otro con más parámetros activos pero menos parámetros totales. Lo que decide el margen es el total de parámetros multiplicado por los bytes por parámetro de la cuantización, punto.

A eso hay que sumarle el KV cache, que sí crece con el contexto que mantienes abierto y con el número de peticiones concurrentes, y que compite por la misma VRAM que los pesos. El presupuesto real con el que trabajas no es "128 GB menos los pesos del modelo": es 128 GB menos los pesos, menos el overhead del motor de inferencia (vLLM, por ejemplo, reserva memoria para CUDA graphs y buffers internos), y lo que queda es lo que tienes disponible para KV cache, es decir, para contexto real y para sesiones concurrentes.

Lo que no entra en 128 GB: por qué DeepSeek V3.2 queda descartado antes de empezar

DeepSeek V3.2 no cabe en 128 GB, ni cuantizado a 4 bits. Es un modelo MoE con 685 000 millones de parámetros totales y 37 000 millones activos por token, bajo licencia MIT. Que solo 37 000 millones estén activos no ayuda aquí, por la razón de la sección anterior: un MoE necesita todos sus expertos cargados en memoria, activos o no. Con 685 000 millones de parámetros totales, incluso a 4 bits (0,5 bytes por parámetro) los pesos solos ocupan alrededor de 342 GB, antes de sumar una sola unidad de KV cache. Estimaciones de despliegue en producción, con overhead de motor incluido, sitúan el requisito real más cerca de 350-400 GB.

Esto no es un matiz de cuantización: es aritmética de tamaño. Ninguna cuantización razonable de 4 bits reduce 342 GB a 128 GB. DeepSeek V3.2 sigue siendo un modelo notable en generación de código puntual, con 70% en SWE-bench Verified según su propia ficha de modelo, pero para un presupuesto de 128 GB de VRAM no es un candidato: pertenece a otra categoría de hardware, la de clústeres multi-GPU, no la de una estación de trabajo local.

La cuenta modelo por modelo: qué cabe, con qué cuantización y con cuánto contexto real

Los cinco modelos que siguen sí caben en 128 GB con alguna combinación razonable de cuantización. Para cada uno: qué reporta su proveedor (con su propio scaffold de evaluación, no comparable directamente con los demás), qué cuantización libera memoria real, y qué motor de inferencia la soporta hoy.

Qwen3.5-122B-A10B

Alibaba lanzó Qwen3.5 en febrero de 2026: arquitectura MoE con 122 000 millones de parámetros totales y 10 000 millones activos por paso, licencia Apache 2.0 y contexto nativo de 262 144 tokens, extensible a 1 010 000 con YaRN. Alibaba reporta, con su propio harness de evaluación, 72,0% en SWE-bench Verified, 72,2 en BFCL-V4 y 79,5 en Tau2-Bench.

Esa cifra de 72,0% corresponde al modelo de referencia en precisión completa, no a ningún checkpoint cuantizado. La versión NVFP4 que circula (probada sobre B200, con SGLang como motor documentado en su model card) no tiene un SWE-bench Verified propio, medido y publicado: nadie ha vuelto a correr el benchmark sobre ese checkpoint concreto. Es razonable esperar un score parecido, pero no es lo mismo que saberlo. Si tu hardware no es Blackwell (SM100 o SM120), la alternativa es AWQ o GGUF a 4 bits, con la misma salvedad: tampoco tienen un score propio medido.

Devstral 2 (123B)

Mistral lanzó Devstral 2 en diciembre de 2025: un transformer dense (no MoE) de 123 000 millones de parámetros, con 256K de contexto. Mistral reporta, con su propio harness, 72,2% en SWE-bench Verified. Esa cifra queda a dos décimas de la que reporta Alibaba para Qwen3.5, pero dos evaluaciones con distinto agente, distinto scaffold y distinto presupuesto de tokens no son el mismo experimento: no se puede leer esa diferencia como un empate ni como una ventaja de ninguno de los dos modelos. Son dos números que miden cosas parecidas, medidas de formas distintas.

Al ser dense, no depende de kernels específicos de una generación de GPU: corre en AWQ o GPTQ sobre cualquier tarjeta con soporte CUDA razonable. Pero aquí la aritmética de VRAM tiene una trampa: la versión FP8 (~123 GB de pesos) deja apenas ~5 GB para KV cache y overhead del motor, muy por debajo de lo que necesita para sostener su ventana de 256K de contexto. Con un presupuesto de 128 GB, la ruta con margen real es INT4 (~62 GB de pesos), no FP8, aunque INT4 tampoco tiene un score de SWE-bench propio: el 72,2% es del checkpoint sin cuantizar.

El repositorio AWQ oficial de Mistral para Devstral 2 no existe: el que circula es comunitario, cyankiwi/Devstral-2-123B-Instruct-2512-AWQ-4bit, derivado del checkpoint FP8 oficial de Mistral. Su propia ficha de modelo admite que la conversión "sacrifica algo de calidad" frente al original; no aporta, ni podría aportar sin evaluarlo de nuevo, un SWE-bench Verified propio.

El matiz de licencia importa antes de adoptarlo: es "MIT modificada", y esa modificación bloquea su uso —incluido el uso interno— a cualquier empresa (o su matriz) con más de 20 millones de dólares de facturación consolidada mensual, y la restricción se extiende a derivados y checkpoints cuantizados como el AWQ comunitario. Para un desarrollador independiente o una empresa pequeña no cambia nada; una corporación grande necesita licencia comercial de Mistral antes de desplegarlo, aunque sea solo para uso interno del equipo de ingeniería.

Qwen3-Coder-Next (80B-A3B)

También de Alibaba, publicado el 3 de febrero de 2026: 80 000 millones de parámetros totales con 3 000 millones activos, contexto de 256K y licencia Apache 2.0. Alibaba reporta 70,6% en SWE-bench Verified —no el 44,3% que circula en algunas comparativas, que corresponde a SWE-bench Pro, un benchmark distinto y más exigente, no a Verified— y 36,2% en Terminal-Bench 2.0.

Aquí está el punto que conviene aclarar sobre VRAM: Qwen3-Coder-Next deja más margen de los 128 GB que Qwen3.5 porque tiene menos parámetros totales (80 000 millones frente a 122 000 millones) y admite cuantizaciones agresivas sin depender de hardware específico, no porque tenga menos parámetros activos. Los 3 000 millones activos (frente a los 10 000 millones de Qwen3.5) hacen que sea más rápido y más barato en cómputo por token; eso es una ventaja real, pero es una ventaja de velocidad, no de memoria.

gpt-oss-120b

OpenAI lo publicó en agosto de 2025: 117 000 millones de parámetros totales, 5 100 millones activos, licencia Apache 2.0, con cuantización MXFP4 nativa —entrenado y publicado ya en ese formato, sin conversión posterior de terceros— que permite servirlo en una sola GPU de 80 GB. OpenAI reporta SWE-bench Verified de 62,4% con esfuerzo de razonamiento alto; con esfuerzo medio cae a 52,6% y con esfuerzo bajo a 47,9%, así que la cifra que se cite depende de la configuración usada, no solo del modelo.

Es, de los cinco, el que menos fricción de despliegue tiene: soporte de fábrica en Ollama, LM Studio y vLLM desde el día de lanzamiento, sin patches ni builds custom, porque MXFP4 es parte del checkpoint oficial, no una conversión de terceros sin medir.

GLM-4.5-Air

De Z.ai, con 106 000 millones de parámetros totales y 12 000 millones activos, bajo licencia MIT. Su SWE-bench Verified oficial, reportado en el technical report de GLM-4.5, es 57,6% —bastante por detrás de los otros cuatro en esa cifra concreta, medida además con un scaffold distinto (OpenHands v0.34.0)—. Cuantizado a Q4_K_M cabe en unos 73 GB, dejando el resto de los 128 GB para un contexto de 131K con KV cache generoso, o para correr otro modelo en paralelo en la misma máquina.

Resumen: memoria, cuantización y motor por modelo

Lee la columna de SWE-bench Verified con cuidado: no es un ranking. Cada fila la mide un proveedor distinto, con un agente distinto. Sirve para saber qué reporta cada uno, no para declarar un ganador entre ellos.

Formato, motor y hardware: la matriz que decide si tu checkpoint arranca

"Cualquier GPU" no es una frase que sobreviva al contacto con estos cuatro formatos. Cada uno exige un motor de inferencia concreto y, en algunos casos, una generación de hardware concreta:

• NVFP4 → SGLang (documentado) / vLLM (soporte inmaduro) → GPUs Blackwell. Es el formato de 4 bits de NVIDIA y solo corre de forma nativa en SM100 (centro de datos: B100, B200, GB200) y SM120 (consumo: RTX 50 Pro, RTX 5090). En cualquier GPU anterior no hay tensor cores de FP4. Incluso en Blackwell de consumo el soporte tiene aristas: un issue abierto de vLLM documenta que en RTX 5090 (SM120) un checkpoint NVFP4 cae al kernel Marlin, más lento, con un mensaje de log que sugiere de forma incorrecta que la GPU no soporta FP4 de forma nativa. El equipo de vLLM está cerrando esa brecha, pero a mediados de 2026 no está resuelta del todo.
• AWQ/GPTQ → vLLM → cualquier GPU con CUDA razonable. El kernel de dequantización es software, no depende de una generación concreta de tensor cores: corre en Ampere (RTX 3090, A100), Ada (RTX 4090), Hopper (H100) o Blackwell por igual. Es la ruta por defecto si tu hardware no es Blackwell y necesitas AWQ/GPTQ.
• GGUF → llama.cpp → CPU, Metal (memoria unificada de Apple) o CUDA. Es la ruta real para un Mac Studio: memoria unificada, sin GPU discreta ni CUDA, así que ni NVFP4 ni AWQ/vLLM aplican ahí. Es también la ruta más flexible para hardware heterogéneo o antiguo.
• MXFP4 → vLLM / transformers → específico de la familia gpt-oss. Es el formato nativo de gpt-oss-120b y gpt-oss-20b; no es un formato general que puedas aplicar a cualquier otro modelo de esta lista.

La consecuencia práctica: la pregunta no es "¿qué modelo es mejor?", es "¿qué combinación de formato y motor soporta mi hardware concreto?". Un Mac Studio de 128 GB y un rig con dos RTX 5090 tienen el mismo presupuesto de memoria y rutas de despliegue completamente distintas.

Los benchmarks, atribuidos: qué mide cada cifra y por qué no son comparables entre proveedores

Un agente de coding no genera una función y termina: llama herramientas, mantiene contexto durante decenas de pasos, edita archivos, ejecuta comandos y reacciona a los errores que produce. Los benchmarks que predicen ese comportamiento no son HumanEval ni MBPP:

• SWE-bench Verified: resolución de issues reales de GitHub sobre un conjunto de 500 instancias filtradas por humanos.
• Terminal-Bench 2.0: razonamiento y ejecución en un entorno de terminal real, no en un sandbox de generación pura.
• BFCL-V4 y Tau2-Bench: fiabilidad en function calling y planificación multi-paso con herramientas reales.

El problema no es qué miden, sino cómo se miden. Cada proveedor evalúa su modelo con su propio agente, su propio scaffold (OpenHands, un harness interno, mini-swe-agent) y su propio presupuesto de tokens por intento. El caso de Qwen3.5 (72,0%) y Devstral 2 (72,2%) en SWE-bench Verified es el ejemplo central de este artículo: 0,2 puntos entre dos evaluaciones heterogéneas no describen un empate ni una diferencia real, describen ruido de metodología. Y hay una segunda capa del mismo problema: esos scores describen el modelo de referencia tal como lo publicó su proveedor, no el checkpoint cuantizado que de verdad vas a ejecutar en tu hardware. Antes de repetir cualquier cifra de esta lista como si fuera un hecho sobre el artefacto que corre en tu máquina, conviene recordar cuál de las dos cosas estás citando.

Puesta en marcha: vLLM con FP8 KV cache, ajustada a tu ruta de hardware

El resto del setup se mantiene razonablemente estable con independencia del modelo y la cuantización elegidos, siempre que el motor sea vLLM (AWQ, MXFP4) y no SGLang o llama.cpp. El flag --kv-cache-dtype fp8 duplica aproximadamente la capacidad efectiva del KV cache, lo que permite más contexto o más sesiones concurrentes con la misma VRAM. El beneficio no es solo de throughput y memoria: también hay impacto en la latencia por petición. Con una sola petición en curso, FP8 reduce casi a la mitad la pendiente de ITL en Llama-3.1-8B (54% de la pendiente de BF16), y bajo carga da un 14,8% menos de ITL mediana en Llama-3.1-8B y un 4,8% en gpt-oss-20b. Las excepciones son acotadas: por debajo de unos 7000 tokens de contexto, BF16 puede ser ligeramente más rápido, y con head_dim=256 en cargas dominadas por prefill el TTFT puede llegar a ser ~1,6 veces mayor, lo que compensa la ganancia en decode. Sin calibración, además, las escalas se fijan por defecto a 1.0, lo que puede degradar la calidad en generación larga: para un uso serio, calibra con llm-compressor sobre un dataset representativo de tu propio código antes de fijar el setup en producción.

# gpt-oss-120b: MXFP4 nativo, sin patches, corre en 80 GB dejando margen en 128 GB
vllm serve openai/gpt-oss-120b \
  --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 131072

# Devstral 2 vía AWQ (cuantización comunitaria de cyankiwi; el repo oficial
# de Mistral, mistralai/Devstral-2-123B-Instruct-2512, es FP8), para hardware
# que no sea Blackwell
vllm serve cyankiwi/Devstral-2-123B-Instruct-2512-AWQ-4bit \
  --quantization awq \
  --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 131072

Si el proceso termina en OOM durante el warmup, baja primero --gpu-memory-utilization a 0.85 antes de tocar el contexto. En los modelos con capas Gated DeltaNet (Qwen3.5, Qwen3-Coder-Next), buena parte de las capas usan atención lineal con memoria aproximadamente constante en vez de la atención cuadrática habitual, así que el KV cache real crece más despacio de lo que cabría esperar de un modelo de este tamaño; no asumas la misma huella que en un transformer dense equivalente como Devstral 2.

Integración con Cline y errores comunes al desplegar

Una vez que vLLM sirve el modelo, conectar Cline es directo: apunta al endpoint compatible con OpenAI que expone en http://localhost:8000/v1. Lo que no es evidente es que hay que declarar explícitamente la ventana de contexto real, porque Cline no la infiere del servidor:

{
  "apiProvider": "openai",
  "openAiBaseUrl": "http://localhost:8000/v1",
  "openAiApiKey": "local-key",
  "openAiModelId": "openai/gpt-oss-120b",
  "contextWindow": 131072,
  "maxTokens": 8192
}

Si dejas contextWindow en el valor por defecto de Cline, la herramienta truncará el contexto del codebase antes de enviarlo al modelo, sin avisar, y se pierde la ventaja de haber elegido un modelo con contexto largo: ajusta ese número al --max-model-len real con el que arrancaste vLLM, no al máximo teórico del modelo. Para n8n, el nodo "OpenAI" acepta la misma base URL sin adaptador adicional.

Licencias: qué te bloquea según el tamaño de tu empresa

De los seis modelos de este artículo, cinco son Apache 2.0 o MIT sin condiciones de uso comercial: Qwen3.5, Qwen3-Coder-Next, gpt-oss-120b, GLM-4.5-Air y DeepSeek V3.2 (aunque este último quede descartado por VRAM, no por licencia). Úsalos, redistribúyelos y modifícalos sin pedir permiso. Devstral 2 es la excepción, con la cláusula de facturación de más de 20 millones de dólares mensuales detallada más arriba: si trabajas por cuenta propia o en una empresa pequeña no te afecta; si trabajas en una corporación grande, necesitas licencia comercial de Mistral antes de desplegarlo, incluido el uso interno.

Y frente a todos ellos, la comparación honesta sigue siendo con un modelo cerrado: Claude Opus 4.6 reporta 80,84% en SWE-bench Verified y 91,9% en Tau2-Bench Retail, entre 8 y 10 puntos por delante de lo que reporta cualquier candidato local de esta lista en la misma métrica, aunque con la misma reserva de fondo: es otro proveedor, con otro scaffold. Ese margen es lo que se cede al ir en local. Si tu prioridad real es resolver el issue más difícil del día y no simplemente ejecutar el modelo en tu propio hardware, un patrón híbrido con fallback a un modelo de API en los pasos críticos sigue siendo más razonable que forzar a un modelo local a cerrar, solo, una diferencia que hoy sigue siendo real.