Cambié el modelo local de OpenCode: lo que aceleró y lo que solo parecía un error

Si usas ChatGPT para programar, ya conoces la escena. Pides un filtro, un botón, un endpoint. Vuelve un código que parece bien. A veces lo está. A veces compila y está mal en el detalle que no leíste.

Yo hago lo mismo, solo que el “cerebro” no está en la nube. Está en una placa de video en este escritorio, una RTX 5090. El programa que dirige el modelo se llama OpenCode: lee archivos, edita, corre tests. Un pasante que no se cansa y no manda el repositorio fuera de casa.

El modelo que usaba era el Qwen3.6, 27 mil millones de parámetros. “27B” es el tamaño de la cabeza. Más grande, en teoría, sabe más — y se come más memoria de video. Entonces Qwen sacó el 3.8. Misma franja, misma licencia libre (Apache 2.0), y ahora ve imágenes.

La pregunta que todo el mundo hace, yo incluido: ¿quedó más rápido? ¿Acierta más?

Te cuento lo que medí en este escritorio. Y el día que pensé que el modelo había empeorado después del cambio — y era yo el que había configurado mal.

Antes, qué es cada pieza

Tres nombres que van a aparecer el post entero, sin misterio.

OpenCode es la aplicación. Abre el proyecto, llama herramientas, escribe el git diff. Sin ella, el modelo solo conversa.

Qwen es el modelo. 3.6 era el que tenía. 3.8 es el sucesor. Los dos entran en esta placa. Los dos hablan bastante para mi día a día en .NET, JavaScript y Flutter.

Ollama es el motor que carga el modelo en la GPU y responde en localhost. OpenCode le habla. Si Ollama anuncia un contexto que la placa no entrega, el agente “se pone tonto” y la culpa parece del Qwen.

Local, acá, quiere decir: el código no va a la API de OpenAI ni de Anthropic. La placa trabaja, el disco es mío, el test corre en la carpeta del repo.

Dos relojes, y la gente los mezcla

Está el reloj de la placa. Cuántos pedacitos de texto escribe el modelo por segundo, el famoso tok/s. Lo mido con curl y nvidia-smi. Es el número que el YouTube de hardware ama.

Está el reloj de la tarea. Desde “implementa el filtro” hasta que pasa dotnet test — o vitest, o flutter test. Ese reloj incluye al modelo describiendo la edición en vez de editar, el razonamiento interno comiéndose la respuesta, el programa anunciando 262 mil tokens de memoria y tirando las instrucciones a mitad del archivo. Entonces abro otra sesión y pierdo diez minutos.

En el 3.6 los dos ya peleaban. Puse a OpenCode a hacer tres tareas chicas de código (una función de paridad, un caché LRU, un merge de intervalos). El Qwen3.6 en Q6 — Q6 es una compresión del modelo, un poco más pesada y un poco más fiel — hizo 3/3. Empató a Haiku 4.5, un modelo pago de Anthropic, en acierto. Haiku cerró en unos 24 segundos. El de acá, entre 56 y 103.

Mismo acierto. Pared de dos a cuatro veces.

Traducido: si tu métrica es ganarle a ChatGPT en el cronómetro, local en esta placa sigue perdiendo. Si la métrica es el patch compiló, el test pasó, y el repositorio no viajó a Estados Unidos, el 3.6 ya daba para trabajar. El 3.8 se sienta encima de eso.

Lo que la placa realmente ganó de velocidad

La arquitectura de los dos es la misma. 64 pisos en el edificio, solo 16 con ese “cuaderno de borrador” que crece a medida que avanza la conversación — el KV cache. La cuenta del post del 3.6 no envejeció.

Lo que cambió en el paquete fue un proyector de visión (el modelo pasó a mirar capturas de pantalla) y, a la hora de escribir, más velocidad.

Velocidad de escribir en la 5090 · sin razonamiento interno · contexto corto

Modelo	Memoria de video	Escribe (tok/s)	Lee el pedido (tok/s)
Qwen3.6 27B Q4	16,95 GB	76,0	1372
Qwen3.8 27B Q4	18,25 GB	111,8	1141

Unos 100 a 110 tokens por segundo contra 76. Eso se siente en el tramo en que el modelo está tipeando el archivo.

Casi no se siente en el tramo en que lee el archivo. En esta batería el 3.8 leyó más lento: 1141 contra 1372. Y un agente de código lee mucho más de lo que escribe. Abre el servicio, abre el test, abre el componente, y recién ahí mueve tres líneas.

O sea: comprar el cambio solo porque “escribe más rápido” es mirar el reloj equivocado.

El otro número que medí, ya en el 3.8 comprimido en Q6 y con visión, fue este. Pedido mínimo: “usa la herramienta”. El modelo devolvió un comando de verdad, no un párrafo diciendo “voy a editar el archivo”. 14 segundos, 67 tokens. En el 3.6 eso oscilaba. Cuando narra la herramienta, OpenCode no edita. La tarea no se pone lenta. Simplemente no ocurre.

El folleto de Qwen dice que acierta más en código

Esto no lo corrí. Son los números que la propia Qwen puso en la ficha del 3.8, comparando con el 3.6.

Pensá esos nombres como exámenes estandarizados. SWE-bench es “¿puede arreglar un bug de un repositorio de verdad?”. Terminal Bench es “¿puede arreglárselas en la terminal?”. LiveCodeBench es “¿puede pasar un ejercicio de programación en vivo?”.

Números de Qwen, no de este escritorio

Prueba	Qwen3.6 27B	Qwen3.8 27B
Terminal Bench 2.1	63,4	73,0
SWE-bench Pro	53,5	61,7
DeepSWE 1.1	13,3	42,2
LiveCodeBench v6	83,9	90,3

El salto que declara está en “usar herramienta y tocar un proyecto”, no en pregunta de ciencia. Si cambias esperando que el modelo gabarite un quiz, la tabla no promete eso. Si cambias porque el 3.6 ya era el 27B local de código, es exactamente el caso en el que apunta la ganancia.

En mi escritorio el 3.6 en Q6 ya había empatado a Haiku en las tres tareas chicas. La versión más apretada, Q4, hizo 1/3 en el mismo test. La compresión movió más ese acierto que un cambio de familia iba a mover en una función de paridad. Por eso me quedo en Q6 para dirigir herramientas, y dejo el Q4 para charla. No volví atrás.

Culpé al modelo. Era configuración.

Después del cambio el 3.8 “alucinaba” y se cortaba a mitad de la frase. Culpa clásica: el modelo nuevo es peor. Fui a leer el log del servidor que Ollama levanta debajo.

Tres defectos. Ninguno era el peso.

Primero: la caja dice 262 mil tokens de contexto. Contexto es la memoria de corto plazo de la conversación — el archivo que leyó, el test que corrió, las instrucciones. 262 mil es lo que el modelo acepta. En esta placa, con el Q6, 262 mil empuja un pedazo del modelo a la RAM común, fuera de la GPU. La lectura del pedido cae 29%. Y hay un detalle feo: el servidor intenta “deslizar” la memoria cuando se llena, el híbrido no deja, y el programa guarda solo 4 tokens. Las instrucciones se van. El modelo pasa a responder una pregunta que nadie hizo. Parece alucinación. Es amnesia configurada.

El techo que cabe entero en la GPU, como está Ollama hoy, es unos 139 mil. Clavé OpenCode en 131 mil. 262 mil es el número de la caja. No es el número de esta 5090.

Segundo: el límite de respuesta demasiado corto. El 3.8 piensa en voz alta antes de responder. Si dejás solo 512 tokens de techo, el pensamiento se come todo y la respuesta corta en el primer ítem. Con 2048, salen los cinco. Medido en esta placa, mismo pedido, solo cambió el techo.

Tercero: OpenCode pasando por un intermediario. Tenía un programa en el medio, LiteLLM. El flujo de texto venía en un formato que el OpenCode viejo rechazaba. El camino que funciona acá es OpenCode hablando directo con Ollama, en el puerto 11434. El intermediario queda para wiki, clave de proyecto y modelo en la nube.

Cuando el agente “se puso tonto” después del cambio, la mayoría de las veces no se puso. Yo había dejado que el motor mintiera la memoria.

Cómo se ve esto en .NET, JavaScript y Flutter

La forma de pedir es la misma en los tres. Abro OpenCode en la carpeta del proyecto. El modelo es el de acá. Puede editar y puede correr comando. No pido “escribe el sistema”. Pido la tarea con el contrato a la vista: qué entra, qué sale, qué tiene que romper el test.

En .NET, una carpeta de feature entra en esos 131 mil tokens junto con el test. Las reglas de la casa — Result, ProblemDetails, sin exception para flujo — están en el repositorio, y el agente local las lee. La ganancia que siento contra el 3.6 no es el dotnet build más rápido. Es el modelo llamando a leer-archivo y editar-archivo, en vez de pegar un fragmento en el chat. Cuando narra, pierdo el turno entero. Es como un pasante que describe la corrección en Slack y no abre Visual Studio.

En JavaScript tengo número de test: las tres tareas chicas de OpenCode en el 3.6 Q6 pasaron. En el día a día es Next, un componente, un test. El 3.8 con visión ayuda cuando la pantalla está mal. El print entra en la conversación, el archivo del componente también. Antes describía el layout en prosa (“el botón quedó a la izquierda, con un gap raro”) e inventaba un flex que no estaba en el píxel.

Flutter es la misma lógica de pantalla. Print del emulador más el widget. Las reglas de la casa siguen siendo spec, no milagro del modelo. El 3.8 no me ahorró escribir el caso raro. Ya lo medí: escribir lo que pasa en el caso extraño sube el acierto de 46% a 90%. La tabla linda en markdown, contra el mismo texto corrido, casi no paga.

El tiempo que gané, en los tres, es menos retrabajo. Sesión que no muere en el pensamiento interno. Herramienta que dispara. Memoria que no tira las instrucciones a mitad del archivo.

Escribir a 100 tokens por segundo es el extra que aparece cuando ya está tocando el archivo correcto.

Qué haría en tu lugar

Si ya usás OpenCode con el 3.6 27B Q6 en una placa de 24 GB o más, yo cambiaría. Cuesta unos 1,3 GB de más en la placa y un Ollama reciente (0.32.12 para arriba). La escritura sube. El folleto de Qwen promete la ganancia donde lo usás — tocar proyecto, no gabaritar quiz. Clavá el contexto en lo que entrega tu placa. Acá, 131 mil. Y apuntá OpenCode directo a Ollama, sin intermediario.

Si tu comparación es Haiku en la nube, prepará el reloj. El de acá sigue más lento por tarea chica y sigue ganando en dato que no viaja. Son cuentas distintas. Uso las dos. El 3.8 local quedó lo bastante bien para el turno en el que el repositorio no puede salir de acá.

Si la placa tiene 16 GB, el 3.8 no resuelve lo que el 3.6 ya no resolvía. Sigue el recado del post de la memoria de video.

No corrí SWE-bench en este escritorio. Lo que este post prueba es la velocidad de escribir, el comando de herramienta de verdad, el techo real de 131 mil tokens y lo que se rompe cuando creés los 262 mil de la caja. El resto es lo que publicó Qwen.

Número de fabricante es punto de partida. No es cierre. Corrélo en tu placa y mirá si el test pasa — o no.