Objetivos de aprendizaje
- Diseñar grupos de modelos por tarea, coste y sensibilidad.
- Usar fallbacks sin ocultar errores importantes.
- Registrar cuándo una tarea salió de local a cloud.
En cristiano: routing híbrido. Es una capa que decide qué modelo usar: local para tareas normales, vLLM para concurrencia, y cloud para tareas complejas o revisión final.
model_list:
- model_name: local-fast
litellm_params:
model: ollama/qwen2.5:7b
api_base: http://localhost:11434
- model_name: local-gpu
litellm_params:
model: openai/Qwen/Qwen2.5-14B-Instruct
api_base: http://localhost:8000/v1
api_key: none
- model_name: frontier-review
litellm_params:
model: openai/gpt-4.1-mini
api_key: os.environ/OPENAI_API_KEY Idea clave. La política importa más que el YAML: qué datos pueden salir, quién aprueba, cuánto puede gastar y qué logs se guardan.
Política práctica
- Local-fast: borradores, clasificación, resumen de documentos no sensibles.
- Local-gpu: tareas largas, RAG interno y agentes con más contexto.
- Frontier-review: revisión final, razonamiento difícil o fallo repetido local.
routing_rules:
sensitive_data: local_only
max_local_retries: 2
allow_cloud_fallback:
- public_code_review
- generic_planning
- final_quality_check
require_human_approval:
- customer_data
- legal_docs
- financial_docs Cuidado. Un fallback automático puede convertirse en fuga de datos. Si local falla sobre datos sensibles, la acción correcta puede ser parar, no mandar el prompt a otro proveedor.
Comprueba que funciona. Crea una traza por petición: modelo elegido, motivo, coste estimado, si hubo fallback y si había datos sensibles. Sin esa traza, no hay control real.
Guardar y reabrir el proyecto.
Híbrido no significa “todo conectado”. Significa tener una política explícita para decidir cuándo local basta y cuándo merece la pena escalar.
Siguiente misión recomendada
Si has guardado la evidencia de esta lección, continúa con «Observabilidad». Si no, repite la comprobación antes de avanzar.