Introducción
En previsión al aumento de costes del uso de las grandes IA y pretendiendo salvaguardar también datos sensibles, el experimentar usando OpenCode con una GPU local, en un equipo de la LAN, ha empezado a dar resultados viables.
Voy a ir pasando a limpio aquí las partes relevantes de mis notas de trabajo para facilitar a quien desee experimentar con ello. Está sujeto a errores y a actualizaciones. Las notas por ahora están incompletas, lo que no las hace menos útiles si sabes un poco lo que llevas entre manos.
El servidor de inferencia
Esto requiere un artículo completo o más. Resumámoslo en ciertos detalles que extenderé en otro momento. Las características fundamentales del que he utilizado son:
Hardware
GPU
Utilizo una NVIDIA GeForce RTX 4070 Ti Super, elegida por lo más relevante: tiene 16 GB de VRAM. Elige la mayor cantidad de VRAM posible como criterio principal una vez te hayas decantado por usar AMD o NVIDIA.
RAM
Uso 32 GB DDR5 en 2 módulos de 16 GB para usar así el doble canal, es un rendimiento equilibrado usar el doble que de VRAM, permite un trabajo fluído. DDR4 sería válido también, simplemente supone anclarse en tecnologías que van quedando atrás.
Almacenamiento
Este puede ser un cuello de botella según para qué uses el equipo pues cambiar de modelo requiere de un tiempo de carga que va limitado muchas veces por la unidad de almacenamiento. Los SSD NVMe son lo más recomendable.
El tamaño de la unidad depende de si vas a usar el servidor de inferencia para más cosas y si vas a experimentar mucho con él o vas muy directo a producción. Para programación y texto, con 512 GB irás bien, si requieres ya múltiples trabajos en imagen y vídeo no bajes de 1 TB.
Los modelos son grandes consumidores de espacio de almacenamiento, no pierdas el rastro de los que ya no utilices.
Software
Para la inferencia, estoy utilizando Ollama por su flexibilidad y la facilidad de uso. Utilizar llama.cpp también es una fantástica elección.
El modelo
La elección del modelo es uno de los puntos críticos. La cantidad de VRAM es la base que condiciona la decisión pues de ella dependerá que se ejecute todo en la GPU o partes vayan teniendo que trasladarse a la RAM con la consecuente lentitud, es el concepto de offloading. No es lo mismo esperar medio minuto a una acción simple o respuesta que esperar una hora y media. Aquí empieza el juego de equilibrismo que requirió de muchas horas de experimentación para entender lo que conviene en la práctica, que en mi opinión, dista de algunas recomendaciones simplificadas que he visto/leído por ahí.
No podemos tomar la decisión en base a un único criterio, lo que aprietas por un lado se afloja por el otro.
Modelo base
Demasiado pequeño y será rápido y tonto, demasiado grande y será desesperadamente lento. Unos comentarios orientativos, me basé en los modelos Qwen pues tienen muy buena fama en programación y las pruebas que hice lo confirman. Eso no quita que pueda haber otros interesantes para actividades concretas o que encajen con precisión en las características de tu equipo por la VRAM disponible o gustos personales.
Qwen 2.5 Coder 7B. Lo lamento, un modelo de 7 B de parámetros no alcanza para programar. quizás pequeños scripts, cositas muy supervisadas o experimentos para tomar soltura sean viables.
Qwen 3 14B: Probablemente mejor que su antecesor Qwen 2.5 Coder 7B, lo considero lo mínimo utilizable como punto de partida.
DeepSeek Coder v2 16B: Apenas lo he probado.
GPT OSS 20B: Si consigues una versión que funcione bien, debería ser viable.
Qwen 3.6 27B: Esto empieza a ser serio, me da confianza para trabajar seriamente con él y con mucho apuro y afinando al máximo he logrado que funcione, es mi elección actual. Es un modelo denso (monolítico) al contrario que el siguiente que es un MoE (mezcla de expertos).
Qwen 3.6 35B A3B: Fantástico, un MoE que solo utiliza expertos de 3 B en cada momento. Lamentablemente, demasiado grande para mi VRAM, la velocidad colapsa estrepitosamente. Es posible que la calidad real final no mejore la del modelo de 27 B.
Qwen 3 Coder Next (80B): Deberás comprobar tu edad para ver si terminas el proyecto antes de jubilarte o gastar en GPU tanto (o más) que en un coche.
A mismo volumen de parámetros, es preferible siempre la versión más moderna del mismo origen, por ejemplo, Qwen 3 14B sobre Qwen 2.5 Coder 14B o Qwen 3.6 27B sobre Qwen 3.5 27B.
Tu opinión sobre otros modelos puede ser un enorme aporte, no dejes de comentar sobre los que has probado para bien y para mal.
La cuantización
Es el siguiente punto crítico que se combina con la elección del modelo.
Una recomendación que he visto repetidamente y con la que no estoy nada de acuerdo es utilizar versiones cuantizadas en 3 bits tipo Q3_XXS. Claro, reduces mucho el uso de VRAM y quizás te puedes permitir un modelo mayor que de otro modo, ¿pero a qué precio? Una vez te pones a aplicarlo en un uso real, observas que con cierta frecuencia aparecen caracteres cambiados que dan al traste con el código generado y las correcciones requeridas lastran largamente el flujo de trabajo. Eso sin contar con las veces que el error no sea detectado y pase a ser un bonito bug.
Quizás si solo pretendes hacer HTML o documentar, sea viable, para programar, desaconsejo los modelos cuantizados en 3 bits están fuera de los límites de lo tolerable.
Los 4 bits siempre han sido un estándar para cuantizar cuando de generación de texto se trata, Q4_K_M es lo que suele entregar Ollama en al mayoría de modelos de forma genérica, en ese criterio coincidimos.
Pero… hay veces que necesitamos una chispita más. Un IQ4_NL, es una finura que con la cuantización imatrix y la no linealidad, para programación es preferible respecto a una Q4_K_S y muy similar a una Q4_K_M. Ten presente que eo comentario de sus desarrolladores recomendando Q4_K_S es con texto y no con programación en mente. Siendo viable para el servidor de inferencia (en el momento de escribir este artículo aún había ciertas incompatibilidades solucionables con trabajo) pueden hacer una rebaja que cuando estás desbordando el límite de la VRAM causa una diferencia muy notable.
El tamaño de contexto
Dependiendo del tamaño del proyecto y de la complejidad de las acciones requeridas, la necesidad es variada.
Un par de truquitos para el contexto
Sin que tenga relación con la cuantización del modelo, utilizar la caché K/V (Clave/Valor) del contexto en 8 bits en lugar de en los 16 bits originales reduce aproximadamente a la mitad la memoria consumida sin pérdida de calidad perceptible. Reducirla a 4 bits parece reducirla a un tercio aprox. si bien ahí ya hay más posibilidades de pequeñas diferencias en la precisión de uso del contexto.
Dependiendo del uso es un buen aliado, puedes pasarla a8bits con esta configuración en el override del servicio de Ollama u otro lugar según sea tu sistema operativo o instalación.
Para editar el archivo de override /etc/systemd/system/ollama.service.d/override.conf, que se mantendrá aun cuando actualices Ollama utiliza un comando:
sudo systemctl edit ollamaAhí puedes agregar, dentro de la sección [Service] lo siguiente:
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"Aplica cambios y comprueba que no aparecen errores en el log con:
sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -n 40 --no-pagerOtro truquito interesante: No necesitas ligarte a un tamaño de ventana de contexto determinado, puedes configurar diferentes variantes del mismo modelo y usar la que te resulte más conveniente en cada momento, siempre teniendo presente que no cambies a un modelo mejor que no pueda manejar el contexto real que estás utilizando sin compactar y reducir antes ese contexto.