Tras haberlo rodado y comprobar que es funcional, muestro cómo he configurado Qwen3.8-27B para utilizarlo localmente en OpenCode. Por su calidad, vuelve a colocarse, según mi experiencia, como el modelo más interesante para programación en equipos modestos -y no tan modestos- porque para superarlo de forma clara hay que empezar a mirar modelos generosamente mayores con requisitos de hardware muy elevados.
Anteriormente, en GPU local con OpenCode: Qwen3.6-27B y Ollama, vimos cómo configurar OpenCode para utilizar Qwen3.6-27B mediante Ollama. Como era de esperar, Qwen3.8-27B mejora el resultado y, afortunadamente, el modo de configurarlo es prácticamente el mismo.
Todas las pruebas de este artículo se han realizado en Linux sobre una GPU con 16 GB de VRAM. En otras gráficas cambiarán algunos valores: principalmente la cuantización que podemos permitirnos, el contexto máximo antes de empezar a descargar capas o estructuras a la CPU y, por supuesto, la velocidad resultante de esas decisiones.
El objetivo inicial será forzar todo el modelo dentro de la VRAM con el mayor contexto posible. Después probaremos configuraciones algo más exigentes, aceptando un poco de offloading a CPU a cambio de conservar más información del modelo o disponer de más contexto.
Ollama viene especialmente bien para este tipo de experimentos porque cambiar entre variantes es trivial. También es una ventaja durante el uso cotidiano: no todas las tareas de programación necesitan la misma combinación de calidad, velocidad y contexto.
Estamos trabajando con modelos locales relativamente pequeños frente a los modelos punteros disponibles en remoto. Si queremos buenos resultados conviene intervenir paso a paso, compactar el contexto cuando corresponda y vigilar lo que hace el agente. La habilidad importante no es utilizar siempre el modelo más grande, sino saber qué configuración necesita cada tarea. En local, un modelo excesivamente pesado nos penaliza en velocidad; en remoto, los modelos grandes penalizan el coste. Y en ambos casos un modelo insuficiente para la tarea acaba provocando errores y tiempo perdido, especialmente si esos errores pasan inadvertidos.
Qwen3.8-27B y el primer GGUF: 3,69 bpw
Qwen3.8-27B soporta de forma nativa un contexto de 262.144 tokens (256 k). Eso no significa que podamos utilizar todo ese contexto en una GPU de 16 GB: el contexto también consume memoria y, en un agente de programación, precisamente ahí estará buena parte del ajuste fino que tendremos que hacer. El modelo oficial puede consultarse en Qwen/Qwen3.8-27B.
Para empezar elegí el GGUF soyaakinohara/qwen3.8-27b-abliterated-3.69bpw-12GB-MTP.gguf. Su archivo ocupa 12.599.187.808 bytes, aproximadamente 12,6 GB decimales o 11,73 GiB, y declara también 256 k tokens de contexto máximo.
Importante: este primer GGUF no contiene exactamente los pesos oficiales sin modificar de Qwen3.8-27B. Es una cuantización mixta de una variante AEON-7 abliterated, libre de censura. Lo utilizo porque su tamaño es extraordinariamente conveniente para 16 GB de VRAM, pero más adelante probaré también cuantizaciones construidas a partir del Qwen3.8-27B oficial.
Primero lo descargamos y comprobamos que Ollama puede ejecutarlo:
ollama run hf.co/soyaakinohara/qwen3.8-27b-abliterated-3.69bpw-12GB-MTP.ggufSi responde correctamente, ya podemos empezar con las pruebas de contexto.
Preparar los Modelfile
En Linux guardo mis Modelfile en un directorio propio. No es una ruta obligatoria de Ollama; simplemente resulta cómoda para mantener ordenadas las variantes:
mkdir -p ~/.ollama/modelfilesPodemos partir del Modelfile que devuelve Ollama:
ollama show --modelfile hf.co/soyaakinohara/qwen3.8-27b-abliterated-3.69bpw-12GB-MTP.gguf > ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-64k.modelfileDespués lo editamos:
nano ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-64k.modelfileEdito el contenido con estos cambios; el TEMPLATE lo conservaremos intacto:
FROM hf.co/soyaakinohara/qwen3.8-27b-abliterated-3.69bpw-12GB-MTP.gguf:latest
PARAMETER num_ctx 65536
PARAMETER num_batch 256El parámetro importante y documentado aquí es num_ctx. num_batch 256 formó parte de mis pruebas iniciales porque ya había experimentado con él en Qwen3.6 para reducir presión de memoria. Sin embargo, actualmente no aparece entre los parámetros documentados públicamente para los Modelfile de Ollama. Por esa razón, al final de las pruebas decidí retirarlo de mis configuraciones definitivas.
Esto importa para interpretar las cifras: los resultados de rendimiento y reparto CPU/GPU que aparecen a continuación corresponden a la tanda experimental que todavía incluía num_batch 256. No voy a mezclar esas mediciones con una segunda tanda que no quedó registrada en mis notas.
64K: el primer objetivo
Con la configuración hecha, creamos la variante para un contexto de 64K:
ollama create qwen3.8-27b-3.69bpw:27b-64k -f ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-64k.modelfileLa ejecutamos y, desde otra terminal, comprobamos la carga:
ollama run qwen3.8-27b-3.69bpw:27b-64k
ollama psEl resultado fue:
NAME ID SIZE PROCESSOR CONTEXT
qwen3.8-27b-3.69bpw:27b-64k db4dd46627e2 13 GB 100% GPU 65536Con 64K conseguimos el objetivo: 100 % GPU. En una prueba inicial simple obtuve además unos 42,52 tokens/s de generación.
Estirar el contexto: 80K, 96K y 128K
Como 64K cabían completamente en VRAM, fui subiendo el contexto para localizar el punto en el que comenzaba el offloading. Ollama recomienda actualmente un mínimo de 64K para tareas de contexto grande, como agentes y herramientas de programación. Aumentar el contexto incrementará el consumo de memoria. La comprobación práctica se hace con ollama ps, observando la columna PROCESSOR.
Para 80K copié la variante anterior y cambié únicamente el contexto:
cp ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-64k.modelfile ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-80k.modelfile
nano ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-80k.modelfilePARAMETER num_ctx 81920ollama create qwen3.8-27b-3.69bpw:27b-80k -f ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-80k.modelfileResultado:
ollama psNAME ID SIZE PROCESSOR CONTEXT
qwen3.8-27b-3.69bpw:27b-80k 9bec4a852827 14 GB 100% GPU 81920Seguíamos en 100 % GPU. Repetí además esta comprobación accediendo a Ollama desde otro equipo de la red y el reparto se mantuvo.
Para 96K utilicé:
cp ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-64k.modelfile ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-96k.modelfile
nano ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-96k.modelfilePARAMETER num_ctx 98304ollama create qwen3.8-27b-3.69bpw:27b-96k -f ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-96k.modelfiley obtuve:
ollama psNAME ID SIZE PROCESSOR CONTEXT
qwen3.8-27b-3.69bpw:27b-96k 97e28cc51b92 16 GB 8%/92% CPU/GPU 98304Aquí ya aparece offloading: un 8 % de la carga pasa a CPU.
Con 128K:
cp ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-64k.modelfile ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-128k.modelfile
nano ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-128k.modelfilePARAMETER num_ctx 131072ollama create qwen3.8-27b-3.69bpw:27b-128k -f ~/.ollama/modelfiles/qwen3.8-27b-3.69bpw-128k.modelfileel resultado fue:
ollama psNAME ID SIZE PROCESSOR CONTEXT
qwen3.8-27b-3.69bpw:27b-128k 0422b670bb63 18 GB 17%/83% CPU/GPU 131072La frontera queda bastante clara en este equipo:
| Contexto configurado | SIZE mostrado por Ollama | PROCESSOR |
|---|---|---|
| 64K (65.536) | 13 GB | 100 % GPU |
| 80K (81.920) | 14 GB | 100 % GPU |
| 96K (98.304) | 16 GB | 8 % CPU / 92 % GPU |
| 128K (131.072) | 18 GB | 17 % CPU / 83 % GPU |
Por tanto, 80K fue el máximo contexto que probé manteniendo el 100 % de la carga en GPU en esta tanda. No hay ninguna obligación de utilizar únicamente 32K, 64K o 128K: si 80K es el punto dulce de nuestro hardware, 80K es una configuración perfectamente válida.
La variante de 80K fue la que incorporé inicialmente en OpenCode.
¿64K u 80K?
No porque 80K entren en VRAM tienen que ser la elección para todo. Con 64K queda más margen de memoria y la respuesta es muy rápida. Con 80K disponemos de unos 16 000 tokens adicionales para una conversación que empieza a acumular archivos, instrucciones, llamadas a herramientas y cambios de código.
Mi planteamiento es mantener varias variantes y cambiar entre ellas según la tarea. Ésa es una de las ventajas de Ollama: no necesitamos buscar una única configuración perfecta para absolutamente todo.
Tres cuantizaciones del Qwen3.8-27B oficial
El GGUF de 3,69 bpw es muy rápido y pequeño, pero parte de una variante modificada. Para comprobar qué ocurre conservando algo más de precisión, probé las tres cuantizaciones de enginetown/Qwen3.8-27B-Calibrated, derivadas del Qwen3.8-27B oficial y construidas a partir de la versión Q8_0 de Unsloth.
No son simples cuantizaciones uniformes. Su autor ajustó diferentes grupos de tensores según su sensibilidad y publicó tres compromisos:
| Modelo | BPW real | Tamaño del GGUF |
|---|---|---|
| Bedrock | 4,37 | 13,91 GiB |
| Tightrope | 4,13 | 13,14 GiB |
| Gambit | 3,94 | 12,54 GiB |
Para evitar ambigüedades, en los comandos utilizo siempre el nombre explícito del archivo GGUF y no el repositorio sin etiqueta.
Bedrock 4,37 bpw
Esta es la variante más conservadora de este lote de tres.
ollama pull hf.co/enginetown/Qwen3.8-27B-Calibrated:Qwen3.8-27B-Bedrock-v4.ggufPara la tanda comparativa de 64K utilicé este Modelfile:
ollama show --modelfile hf.co/enginetown/Qwen3.8-27B-Calibrated:Qwen3.8-27B-Bedrock-v4.gguf \
> ~/.ollama/modelfiles/qwen3.8-27b-bedrock-4.37bpw-64k.modelfilenano ~/.ollama/modelfiles/qwen3.8-27b-bedrock-4.37bpw-64k.modelfileLos valores de TEMPLATE y otros PARAMETER distintos a los aquí especificados, no los cambio:
FROM hf.co/enginetown/Qwen3.8-27B-Calibrated:Qwen3.8-27B-Bedrock-v4.gguf
PARAMETER num_ctx 65536
PARAMETER num_batch 256ollama create qwen3.8-bedrock:27b-4.37bpw-64k -f ~/.ollama/modelfiles/qwen3.8-27b-bedrock-4.37bpw-64k.modelfileResultado:
NAME ID SIZE PROCESSOR CONTEXT
qwen3.8-bedrock:27b-4.37bpw-64k 592bf1edeebf 17 GB 15%/85% CPU/GPU 65536La generación rondó los 17,4 tokens/s. Conservamos más precisión, pero en 16 GB de VRAM pagamos ya un 15 % de offloading.
Tightrope 4,13 bpw
Es la cuantización intermedia y ofrece un compromiso real entre velocidad y calidad.
ollama pull hf.co/enginetown/Qwen3.8-27B-Calibrated:Qwen3.8-27B-Tightrope.ggufcp ~/.ollama/modelfiles/qwen3.8-27b-bedrock-4.37bpw-64k.modelfile ~/.ollama/modelfiles/qwen3.8-27b-tightrope-4.13bpw-64k.modelfile
nano ~/.ollama/modelfiles/qwen3.8-27b-tightrope-4.13bpw-64k.modelfileFROM hf.co/enginetown/Qwen3.8-27B-Calibrated:Qwen3.8-27B-Tightrope.gguf
PARAMETER num_ctx 65536
PARAMETER num_batch 256ollama create qwen3.8-tightrope:27b-4.13bpw-64k -f ~/.ollama/modelfiles/qwen3.8-27b-tightrope-4.13bpw-64k.modelfileResultado:
NAME ID SIZE PROCESSOR CONTEXT
qwen3.8-tightrope:27b-4.13bpw-64k 92d325676d81 16 GB 10%/90% CPU/GPU 65536La generación quedó aproximadamente en 23,5 tokens/s.
Gambit 3,94 bpw
Es la menor de las tres, aunque conserva una cuantización menos agresiva que el modelo abliterado inicial de 3,69 bpw.
ollama pull hf.co/enginetown/Qwen3.8-27B-Calibrated:Qwen3.8-27B-Gambit.ggufcp ~/.ollama/modelfiles/qwen3.8-27b-bedrock-4.37bpw-64k.modelfile ~/.ollama/modelfiles/qwen3.8-27b-gambit-3.94bpw-64k.modelfile
nano ~/.ollama/modelfiles/qwen3.8-27b-gambit-3.94bpw-64k.modelfileFROM hf.co/enginetown/Qwen3.8-27B-Calibrated:Qwen3.8-27B-Gambit.gguf
PARAMETER num_ctx 65536
PARAMETER num_batch 256ollama create qwen3.8-gambit:27b-3.94bpw-64k -f ~/.ollama/modelfiles/qwen3.8-27b-gambit-3.94bpw-64k.modelfileResultado:
NAME ID SIZE PROCESSOR CONTEXT
qwen3.8-gambit:27b-3.94bpw-64k 69598d9ab955 16 GB 6%/94% CPU/GPU 65536La generación alcanzó unos 30,35 tokens/s. Para una GPU de 16 GB empieza a resultar un compromiso muy atractivo: sólo un 6 % de offloading y una cuantización menos agresiva que la de 3,69 bpw.
Primera comparación de velocidad
La primera tanda de medidas quedó así. Insisto: son cifras orientativas de mi equipo y de la configuración experimental con num_batch 256; no deben interpretarse como un benchmark universal de los modelos.
| Modelo | BPW | Contexto | Prompt eval | Generación |
|---|---|---|---|---|
| Bedrock | 4,37 | 64K | 73,90 tok/s | 17,40 tok/s |
| Tightrope | 4,13 | 64K | 361,73 tok/s | 23,50 tok/s |
| Gambit | 3,94 | 64K | 126,37 tok/s | 30,35 tok/s |
| Qwen3.8 abliterado | 3,69 | 64K | 157,82 tok/s | 42,52 tok/s |
Las cifras de prompt eval con entradas pequeñas pueden bailar mucho por el estado de cachés, calentamiento y otros detalles de la ejecución. Por eso repetí la comparación con una entrada bastante mayor.
Prueba con un prompt de 26.017 tokens
Con el mismo prompt de 26.017 tokens en las cuatro variantes obtuve:
| Modelo | Prompt tokens | Prompt eval | Generación | Tiempo total |
|---|---|---|---|---|
| Bedrock 4,37 | 26.017 | 928,03 tok/s | 10,40 tok/s | 71,90 s |
| Tightrope 4,13 | 26.017 | 1.103,71 tok/s | 15,71 tok/s | 56,81 s |
| Gambit 3,94 | 26.017 | 1.218,15 tok/s | 27,99 tok/s | 43,44 s |
| 3,69 bpw | 26.017 | 1.175,22 tok/s | 34,56 tok/s | 39,73 s |
Aquí la tendencia resulta bastante más útil. El modelo de 3,69 bpw termina antes y es el más rápido generando. Gambit queda relativamente cerca y conserva más bits por peso. Tightrope todavía puede ser interesante si priorizamos la conservación del modelo sobre la velocidad. Bedrock, en cambio, empieza a pagar demasiado cara su mayor precisión en una gráfica de sólo 16 GB.
Eso no significa que Bedrock sea peor. Significa que este hardware no es su terreno ideal. En una gráfica con más VRAM los resultados y, sobre todo, la relación entre calidad y velocidad pueden cambiar por completo.
Retirar num_batch 256
Después de esas pruebas decidí retirar PARAMETER num_batch 256 de todos los Modelfile y recrear las variantes. El motivo es sencillo: num_ctx sí figura actualmente en la referencia oficial de parámetros de los Modelfile de Ollama, mientras que num_batch no aparece en esa lista pública.
Por tanto, una configuración final mínima de 64K queda así:
FROM hf.co/soyaakinohara/qwen3.8-27b-abliterated-3.69bpw-12GB-MTP.gguf
PARAMETER num_ctx 65536y la de 80K:
FROM hf.co/soyaakinohara/qwen3.8-27b-abliterated-3.69bpw-12GB-MTP.gguf
PARAMETER num_ctx 81920En mis notas no quedaron registradas las cifras completas de la segunda tanda ya sin num_batch, así que prefiero no adjudicarle los números anteriores. Si se pretende comparar versiones de Ollama o hardware distinto, lo correcto es volver a ejecutar la misma prueba y anotar de nuevo los resultados de ollama ps, velocidad de evaluación, velocidad de generación y tiempo total.
Mi elección práctica en 16 GB
Con los datos obtenidos me quedo con dos perfiles claros:
- Máxima velocidad y mucho contexto: la variante de 3,69 bpw, especialmente 64K u 80K cuando permanece íntegramente en GPU.
- Más conservación de los pesos oficiales: Gambit 3,94 bpw a 64K, aceptando una pequeña cantidad de offloading a cambio de una cuantización menos agresiva.
No elegiría Bedrock como variante habitual para una GPU de 16 GB salvo cuando es especialmente delicado el código y se puede asumir la lentitud de la respuesta. Tightrope no me ofrece aquí un equilibrio tan interesante como Gambit, aunque en determinadas tareas su mayor conservación me da más confianza. En una GPU con más VRAM repetiría todo el proceso desde cero.
Ésta es una idea que conviene retener: no existe un GGUF mejor en términos absolutos. Existe un compromiso más adecuado para un modelo, una tarea y un hardware determinados.
Configurar Qwen3.8-27B en OpenCode
OpenCode puede utilizar Ollama mediante su API compatible con OpenAI. Si ambos programas están en el mismo equipo, la URL habitual es:
http://localhost:11434/v1Aplico la configuración global del usuario de OpenCode donde lo venía utilizando hasta ahora: ~/.opencode/opencode.json si bien el estándar actual y recomendable sería ~/.config/opencode/opencode.json. También se admite JSONC. En Windows, puedes utilizar %USERPROFILE%\.config\opencode\opencode.json(c). Usa .json de modo general y .jsonc si quieres poder agregar comentarios. Las instalaciones antiguas pueden conservar archivos en otras ubicaciones, así que si ya tenemos una configuración funcional no hay motivo para moverla a ciegas.
Un ejemplo con las variantes principales sería:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (local)",
"options": {
"baseURL": "http://localhost:11434/v1"
},
"models": {
"qwen3.8-bedrock:27b-4.37bpw-64k": {
"name": "Qwen 3.8 27B 4.37bpw Bedrock 64k",
"limit": {
"context": 65536,
"output": 8192
}
},
"qwen3.8-tightrope:27b-4.13bpw-64k": {
"name": "Qwen 3.8 27B 4.13bpw Tightrope 64k",
"limit": {
"context": 65536,
"output": 8192
}
},
"qwen3.8-gambit:27b-3.94bpw-64k": {
"name": "Qwen 3.8 27B 3.94bpw Gambit 64k",
"limit": {
"context": 65536,
"output": 8192
}
},
"qwen3.8-27b-3.69bpw:27b-64k": {
"name": "Qwen 3.8 27B 3.69bpw 64k",
"limit": {
"context": 65536,
"output": 8192
}
},
"qwen3.8-27b-3.69bpw:27b-80k": {
"name": "Qwen 3.8 27B 3.69bpw 80k",
"limit": {
"context": 81920,
"output": 8192
}
}
}
}
},
"model": "ollama/qwen3.8-27b-3.69bpw:27b-80k"
}En OpenCode, limit.context y limit.output sirven para que el agente conozca los límites que le estamos declarando para ese modelo. Los 8.192 tokens de salida del ejemplo son una decisión práctica para este uso local, no el máximo teórico de Qwen3.8-27B. Si necesitamos respuestas finales mucho más largas podemos aumentarlo, teniendo siempre presente el presupuesto total de contexto que Ollama está sirviendo.
Después de editar la configuración, podemos ejecutar /models en OpenCode y seleccionar la variante correspondiente. Antes de confiarle un proyecto real conviene verificar algo muy simple: que el modelo utilice correctamente las herramientas. Por ejemplo, pedirle que liste los archivos del directorio sin modificar nada.
OpenCode y Ollama desde otro equipo de la red
Si OpenCode y Ollama no están en la misma máquina, localhost ya no sirve. En ese caso hay que exponer Ollama en la red local con la configuración adecuada y sustituir la URL por la IP del equipo que ejecuta Ollama, por ejemplo:
http://192.168.1.50:11434/v1Como ya vimos en el artículo anterior, aquí entran también en juego el cortafuegos y la interfaz en la que Ollama esté escuchando. No conviene exponer el servicio fuera de la red de confianza sin pensar antes en autenticación y seguridad.
Equivalentes en Windows
Aunque todas mis mediciones se hicieron en Linux, casi todo el procedimiento es igual en Windows. Los comandos propios de Ollama —pull, run, create, show y ps— no cambian. Lo que cambia principalmente es la gestión de rutas y el editor utilizado para los Modelfile.
Desde PowerShell podemos crear un directorio equivalente:
New-Item -ItemType Directory -Force "$HOME\.ollama\modelfiles"Guardar el Modelfile obtenido de Ollama:
ollama show --modelfile hf.co/soyaakinohara/qwen3.8-27b-abliterated-3.69bpw-12GB-MTP.gguf > "$HOME\.ollama\modelfiles\qwen3.8-27b-3.69bpw-64k.modelfile"Editar con el Bloc de notas:
notepad "$HOME\.ollama\modelfiles\qwen3.8-27b-3.69bpw-64k.modelfile"Y crear la variante:
ollama create qwen3.8-27b-3.69bpw:27b-64k -f "$HOME\.ollama\modelfiles\qwen3.8-27b-3.69bpw-64k.modelfile"Para la configuración global de OpenCode en Windows, la documentación actual utiliza el equivalente bajo el perfil del usuario:
%USERPROFILE%\.config\opencode\opencode.jsonSi se utiliza WSL, lo más sencillo es tratarlo como un entorno Linux y seguir las rutas Linux dentro de la distribución. OpenCode recomienda además WSL como alternativa cuando aparecen problemas de rendimiento o acceso a archivos en Windows.
Qué conviene medir en nuestro propio equipo
Copiar mis números sería perder la parte más útil del experimento. Lo que merece la pena copiar es el método:
- Elegir el mayor modelo que tenga sentido para la tarea.
- Escoger una cuantización que deje margen suficiente para el contexto.
- Fijar un contexto mínimo realmente útil para un agente de programación.
- Comprobar con
ollama psqué porcentaje permanece en GPU. - Medir con prompts suficientemente grandes y representativos.
- Separar la velocidad de evaluación del prompt de la velocidad de generación.
- Probar llamadas a herramientas y trabajo real sobre código, no sólo preguntas aisladas.
- Mantener varias configuraciones y usar cada una cuando corresponda.
Ollama, de hecho, recomienda evitar el offloading a CPU cuando buscamos el mejor rendimiento. Pero eso no convierte cualquier cantidad de offloading en algo prohibido: a veces aceptar un pequeño porcentaje permite conservar más calidad o contexto y el resultado global compensa. La decisión depende de la tarea.
Atención: límite de contexto y compactado
Aunque OpenCode dispone de compactación automática, antes de pasar deliberadamente de 80K a 64K prefiero compactar manualmente, evitando depender de que la sesión llegue justo al umbral. Esto también es válido cuando pasamos de usar un modelo grande de OpenAI o Anthropic con contexto enorme a uno local con un contexto mucho más modesto.
Otra posibilidad es utilizar modelos con el mismo límite de contexto, de modo que esta situación simplemente no llegue a producirse. Precisamente por eso mantengo también una variante del modelo de 3,69 bpw con 64K de contexto, aunque mi GPU pueda utilizarlo perfectamente con 80K. Usando la de 64K desaparece el riesgo cuando cambiamos entre ella y cualquiera de las otras variantes Qwen configuradas también a 64K.
Qwen3.8-27B, como era de esperar, vuelve a demostrar hasta dónde puede llegar una GPU doméstica cuando ajustamos bien cuantización y contexto. La variante de 3,69 bpw me permitió alcanzar 80K de contexto manteniendo toda la carga en una GPU de 16 GB de VRAM en la tanda registrada, mientras Gambit 3,94 bpw ofreció un compromiso especialmente interesante entre conservación de los pesos oficiales y velocidad; en mi experiencia, Bedrock es la opción más fiable y Tightrope ofrece casi la misma confianza sin la sensación de lentitud tan acusada. En la práctica, uso las cuatro.
Lo más valioso no es decidir que uno de esos modelos será «el ganador». En un agente como OpenCode, el contexto crece, las tareas cambian y el coste de cada error también cambia. Tener varias variantes preparadas y saber cuándo pasar de una a otra es mucho más útil que obsesionarse con un único número de tokens por segundo. Ctrl+X M (/models) es tu amigo, como Ctrl+X U (/undo) también es un aliado para retroceder a tiempo o ahorrar contexto y Ctrl+X C (/compact) colabora muy bien.
Un modelo local excesivamente grande puede hacernos perder tiempo esperando. Uno demasiado cuantizado o insuficiente puede hacernos perder todavía más tiempo corrigiendo errores. La clave es encontrar el óptimo para cada momento y saber estructurar las tareas y el proyecto en general para fraccionar adecuadamente cada paso del trabajo.