Una arquitectura híbrida de IA puede repartir la programación entre un modelo remoto que organiza la tarea y un modelo local que edita los archivos. Para un homelab, la pregunta práctica es cuánto cuesta obtener un resultado correcto, incluyendo la espera, los reintentos y la revisión humana.
Reducir las peticiones de pago es un objetivo medible. No implica automáticamente reducir el coste total: ejecutar un modelo local también requiere hardware, electricidad y mantenimiento.
Actualizado el 30 de septiembre de 2026.
Dos funciones, dos modelos
La separación tiene un precedente documentado. En el modo architect de Aider, un modelo propone la solución y un editor convierte esa propuesta en cambios concretos en archivos. El editor puede configurarse por separado. La documentación también advierte de que usar dos peticiones puede aumentar tiempo y coste.
Nuestra propuesta para un homelab es aplicar esa separación a tareas pequeñas: pedir al planificador un objetivo, los archivos que deben cambiar y los criterios de aceptación; entregar ese encargo al editor; y comprobar después el resultado. Elegir un editor local no demuestra por sí mismo que el flujo sea más barato o mejor.
Una tarea inicial podría ser añadir un filtro a una lista existente. Es más fácil comparar sus resultados que valorar una aplicación completa generada desde cero: el comportamiento esperado puede describirse antes de ejecutar los modelos.
Cómo medir si compensa
Para evaluar el flujo proponemos repetir varias tareas representativas con los mismos criterios de aceptación. Registra tanto las ejecuciones satisfactorias como los intentos fallidos y el tiempo que dedica una persona a revisar.
| Medida | Qué registrar |
|---|---|
| Gasto remoto | Consumo real de todas las peticiones, incluidas correcciones |
| Tiempo total | Planificación, edición, comprobación y reintentos |
| Calidad | Criterios cumplidos y errores detectados al usar el resultado |
| Trabajo humano | Minutos de revisión y reparación |
| Coste local | Electricidad y parte del equipo atribuible al uso |
La API de Ollama devuelve métricas de tokens de entrada y salida, carga y duración de generación. Permiten registrar el uso local; no equivalen a una medición de consumo eléctrico.
Para comprobar dónde se ejecuta el modelo, la documentación de Ollama explica cómo consultar con ollama ps si está cargado en CPU, GPU o ambas. Esto ayuda a interpretar diferencias de velocidad entre equipos.
Local no significa que todo permanezca en casa
En un flujo híbrido, el planificador remoto recibe aquello que le envías. Si le entregas archivos privados para planificar o revisar, esos archivos salen del equipo aunque la edición ocurra localmente.
Ollama distingue en sus preguntas frecuentes la ejecución local de los modelos alojados en su nube y documenta una opción para desactivar las funciones cloud. Esa configuración afecta a Ollama; no cambia los envíos que otra herramienta haga al planificador remoto.
Antes de probar, define qué contexto necesita cada modelo. Una descripción de la tarea, una interfaz pública o un fragmento reducido pueden ser suficientes. Comprueba el flujo real en lugar de deducirlo por el nombre del producto.
La prueba útil para tu homelab
Nuestra lectura editorial es que esta arquitectura merece una prueba acotada cuando ya dispones de hardware y puedes verificar el resultado. Lo decisivo es el coste por tarea aceptada, junto con la espera y el esfuerzo de revisión.
Si el editor necesita numerosas correcciones, el planificador vuelve a consumir API y la persona dedica más tiempo al resultado. Si resuelve tareas concretas con pocas iteraciones, la combinación puede resultar útil. Tus registros y tus criterios de aceptación deben decidir si funciona para ti.