LLMs autogestionados: El futuro de la soberanía de la IA y la eficiencia operativa

Mid-weight LLMs autogestionados, ¿el futuro?

Hemos llegado a ese momento que se estaba augurando desde hace tiempo: el fin de la tarifa plana del token. Durante los últimos años, la industria de GenAI ha estado operando a un nivel de pérdidas astronómicas y bajo la falsa ilusión de que el coste de computación era irrelevante. Era rápido, era espectacular, pero financieramente insostenible.

El reciente anuncio de GitHub Copilot confirma lo que muchos veían venir: a partir de junio de 2026, el modelo de tarifa plana muere. El paso a una facturación basada en uso y los multiplicadores de coste de hasta 27x para algunos modelos son un golpe de realidad. El uso de agentic workflows en la nube se ha popularizado, y ha reventado (todavía más) los márgenes de los proveedores.

El futuro apunta a local (y va a exigir más disciplina)

Con este escenario, replantearse la estrategia de consumo parece la única vía razonable.

En mi opinión, el futuro pasa por adoptar una estrategia de soberanía de IA. Una estrategia que apunte a delegar la gran mayoría de las tareas cotidianas a modelos de rango medio (20B-35B), donde nosotros tengamos el control absoluto de la infraestructura y el precio. Esto implica evitar cualquier forma de "vendor lock-in" y apostar por herramientas flexibles que permitan hilar fino en la segregación de tareas entre múltiples modelos (motivos por los que soy fiel defensor de alternativas como OpenCode o pi.dev frente a ecosistemas cerrados como los de Anthropic u OpenAI)

Esto no significa obligatoriamente ejecutar todo en local en el portátil del desarrollador: abarca desde servidores de inferencia en nuestra VPC, hasta servicios como Vertex AI con endpoints privados. Lo que para mí está claro es que los frontier models deberían quedar reservados únicamente para operaciones críticas o de extrema complejidad.

No es solo optimización de costes, la estrategia enlaza directamente con una decisión operativa y de diseño. A medida que los modelos generalistas se estandarizan, el verdadero valor está en especializarlos para tareas concretas con datos y contexto propios. Apostar por modelos locales o autogestionados permite afinarlos para casos de uso específicos, mantener el control y adaptarlos continuamente.

No se trata de utilizar un modelo generalista de coste astronómico para todo, sino de disponer de múltiples modelos (mucho más ligeros) especializados. En ese escenario, la ventaja competitiva ya no viene del modelo en sí, sino de lo bien que resuelve problemas concretos dentro de tu organización.

Si se decide apostar por esta estrategia, hay algunos factores clave a tener en cuenta y que serán los críticos y que más dolores de cabeza nos provocarán: La importancia del contexto (a nivel de calidad y cantidad), el fine-tuning, los controles de calidad, y el cambio de mentalidad en la forma de uso.

El contexto, el fine-tuning, la calidad y la forma de uso

La gestión del contexto

Si ya es crítico en el uso de modelos frontier, para nuestro caso la importancia se eleva al cuadrado. La ventana disponible será más acotada y la capacidad de atención y precisión del modelo, mucho más frágil. La calidad caerá en picado si lo saturamos.

En su artículo sobre Context Engineering, Ezequiel explica con detalle el concepto de "Context Rot", haciendo una analogía con la situación del uso de la memoria RAM en el pasado (no tan lejano). No se trata de meter más información por fuerza bruta, sino de aplicar arquitecturas de Progressive Disclosure y, especialmente, ser muy estrictos con el punto que comenta sobre el Targeted Retrieval. Hay que aportar única y exclusivamente la información necesaria para la tarea, acotada y controlada, para asegurarnos de que el modelo centre su atención en lo estrictamente indispensable.

La ventaja operativa del fine-tuning

Sabiendo que el contexto hay que gestionarlo como si fuera sagrado, la capacidad de especializar modelos (aun siendo “ligeros”, como Qwen 3.6 27b o Gemma 4 31b) nos da una clara ventaja operativa.

Implicará una inversión en el proceso de entrenamiento inicial, pero especializar a los agentes nos ayudará a reducir drásticamente la cantidad de contexto que necesitamos aportar en cada operativa específica. El uso intensivo de skills, reglas y largos ficheros .md de configuración está muy bien si dispones de un contexto amplio y su gestión no es crítica, pero en nuestra situación, queremos minimizar los tokens de entrada para que el modelo afine su precisión. Un modelo entrenado en tu stack o en las necesidades específicas de la tarea que va a ejecutar, ya trae la lección aprendida.

El entrenamiento de este tipo de modelos es hoy completamente asumible gracias a técnicas de adaptación paramétrica eficiente como LoRA. De hecho, plataformas como Vertex AI de Google Cloud han estandarizado el fine-tuning gestionado, ofreciendo estos procesos bajo modelos de facturación basados en el uso. En paralelo, frameworks como NVIDIA NeMo permiten implementar estas técnicas con un mayor control sobre la infraestructura, mientras que librerías optimizadas como Unsloth facilitan su ejecución eficiente incluso en entornos con recursos limitados.

El control de calidad y las herramientas deterministas

Otro concepto que ya es clave en cualquier escenario, pero que con el uso de modelos no-frontier aumenta su criticidad.

Tal y como argumenta Jason Gorman en su serie “The AI-Ready Software Developer”, la escalabilidad del desarrollo asistido por IA depende de integrar los modelos en workflows deterministas y con retroalimentación estricta. En este enfoque se generan propuestas, pero su validez se verifica siempre mediante mecanismos como tests automatizados, integración continua o análisis estático. Esto pasa por aplicar prácticas como derivar tests a partir de especificaciones ejecutables (por ejemplo, en Gherkin) o reutilizar de forma sistemática los resultados de herramientas como linters o suites de tests. El modelo propone, el sistema de ingeniería valida, restringe, corrige y fuerza la iteración.

El cambio de mentalidad

Todo esto desemboca en un cambio de paradigma frente a los flujos agénticos habituales con LLMs en la nube. Operar con modelos locales requiere un trabajo a mucho más bajo nivel y una mayor intervención humana debido a los límites inherentes de los modelos. Lejos de ser un inconveniente, este roce constante, en mi opinión, es positivo porque evita la peligrosa invitación a “despegarse” del código que tan fácilmente provocan modelos como Opus 4.6. Se acabó el lanzar un prompt del tipo “revísame el repo entero y plantea este cambio a súper alto nivel que implica un montón de modificaciones”. Obligarnos a trocear el problema y guiar al modelo nos devuelve el control sobre el software.

Cacharreando en local

Llevo unas semanas experimentando con una configuración de modelos locales para mi trabajo diario. Tras múltiples pruebas y una experimentación que todavía continúa, he llegado a una estrategia funcional que mitiga parte de las carencias habituales de los modelos pequeños en entornos de ejecución limitados.

Mi entorno de pruebas es un MacBook Pro M4 con 48 GB de RAM. Aunque es una máquina potente, ejecutar modelos que rondan los 30B de parámetros exige optimizar cada giga de VRAM disponible, especialmente cuando la KV cache empieza a dispararse al gestionar ventanas de contexto amplias.

La orquestación: llama.cpp y llama-swap

Para servir los modelos me apoyo en llama.cpp y, sobre todo, en llama-swap. ¿Por qué no Ollama? Bueno, utilizar llama.cpp requiere un pelín más de configuración, pero ganas en optimización y eficiencia.

El swap es la pieza clave: permite intercambiar el modelo que se está sirviendo bajo demanda. En lugar de intentar cargar tres modelos en paralelo y saturar la memoria, llama-swap gestiona la carga y descarga en VRAM de forma transparente para mi instancia de OpenCode. Os dejo por aquí el repositorio por si queréis echar un vistazo, es relativamente simple y posiblemente con mucho margen de mejora.

El flujo de 3 capas: Plan → Review → Build

Decidí añadir un paso intermedio frente al flujo habitual de “Plan” y “Build”:

• Plan (DeepSeek R1 Distill 32b): Un modelo muy imaginativo y con una capacidad de razonamiento profundo. Es el encargado de trazar la estrategia técnica inicial.

• Review (Gemma 4 31b): DeepSeek puede ser “demasiado” creativo y, a veces, desestructurado en su output. Aquí entra Gemma, un modelo mucho más pragmático, rápido y estricto. Su función es pulir el plan, eliminar redundancias y asegurar que la propuesta sea ejecutable y técnicamente sólida.

• Build (Qwen 3.6 27b): Para la escritura de código pura, Qwen 3.6 27b es ahora mismo el sweet spot de los “mid-weight LMs”. Su gran ventaja es el “preserve_thinking”: mantiene el contexto de su cadena de razonamiento entre iteraciones. Esto le permite entender por qué está tomando ciertas decisiones de implementación sin perderse en flujos de trabajo agénticos complejos, algo donde Gemma 4 suele sufrir más.

El modelo de uso y el rol de cada agente se configura a nivel de herramienta de desarrollo. En mi caso, utilizo mi suite de configuración para desarrollo con agentes con OpenCode. Nótese que el modelo de skills & commands está pensado más para el trabajo con modelos cloud y todavía no lo he optimizado para uso local, pero sí que aporto una configuración base para uso local en el ejemplo opencode.local.example.json.

El peaje de la velocidad: Q5 vs Q4

No todo es idílico. El principal punto de dolor en local es el throughput o tasa de generación de tokens. Inicialmente aposté por una cuantización Q5_K_M para los tres modelos, buscando la máxima fidelidad. Sin embargo, las iteraciones de planificación y revisión podían alargarse varios minutos.

Actualmente estoy transicionando a Q4_K_M. Si bien sacrificas algo de precisión teórica, la ganancia en velocidad es notable. Aquí es donde los controles de calidad deterministas que comentamos antes deben entrar en juego: si la implementación se desvía del objetivo por culpa de la cuantización, el sistema debe forzar la iteración.

Cabe destacar que este es el principal trade-off del enfoque puramente local. Si en lugar de esto optamos por levantar un endpoint privado en cloud para el equipo, podemos abandonar llama.cpp en favor de motores de inferencia como vLLM servidos en GPUs. Esto nos permite ejecutar los modelos en FP8 o INT4 nativo, compartiendo la KV Cache entre el equipo y multiplicando el throughput sin los cuellos de botella de un portátil.

OpenCode como centro de todo

Nada de esto tendría sentido sin una herramienta vendor-agnostic. Utilizo OpenCode porque no me ata a un proveedor ni a una suscripción. Me permite combinar diferentes orígenes de modelos y orquestar estos flujos complejos con total libertad. Además, es open-source y auditable, con todas las ventajas que ello conlleva.

Si creemos que el futuro es local o mixto, OpenCode es, en mi opinión, uno de los actores principales para recuperar la soberanía sobre nuestras herramientas. De hecho, estoy trabajando en configuraciones que van más allá del puro desarrollo, como este asistente de soporte para Engineering Managers integrado con Jira y GitHub (una adaptación nativa para OpenCode, con funcionalidades personalizadas, basada en el repositorio original de Julio César Pérez para Claude: claude-em).

Repositorios de referencia

• Local models setup: https://github.com/apenlor/llm-local-setup

• OpenCode Expert Mode (dev): https://github.com/apenlor/opencode-expert-mode

• OpenCode EM OS (Engineer Manager): https://github.com/apenlor/opencode-em-os

Conclusión: más ingeniería

Todo parece apuntar a que el futuro del desarrollo asistido pasa por apoyarnos en lo local, o nube privada. Sin embargo, esta transición exige un cambio de paradigma: toca desprendernos de las malas costumbres que se han incrustado en nuestra forma de trabajar demasiado rápido durante estos últimos años.

Lejos de ser un paso atrás, sinceramente creo que será un cambio netamente positivo. Recuperamos la soberanía, el control absoluto y la privacidad de nuestro código. Reducimos la fatiga cognitiva de los equipos: el efecto de burn-out (también llamado “AI fatigue”) disminuye cuando se reduce la cantidad de PRs masivas generadas por un modelo frontier, o cuando tu foco de atención no está saltando continuamente de un punto a otro y te centras en un problema. Además, reduce el riesgo de desapego y descontrol sobre el código.

Incluso a nivel macro, el planeta y nuestra infraestructura agradecerán un cambio de modelo de uso así.

Personalmente, estoy bastante emocionado con los retos que trae esta nueva etapa. Optimizar LLMs, diseñar validaciones eficientes y orquestar flujos en local me resulta infinitamente más estimulante, a nivel técnico, que la estrategia de matar moscas a cañonazos y quemar tokens/computación como si no hubiera un mañana.

Espero acertar y que no envejezca demasiado mal este artículo 🙂