La Era del Routing Dinámico: Por qué las PYMES no deben elegir un modelo, sino un Orquestador
El mercado de modelos LLM ha dejado de ser una carrera por "quién es más inteligente". Quien encabeza la clasificación en MMLU o GPQA hoy es superado mañana. La competencia se ha desplazado a un eje que las PYMES ignoran bajo su propio riesgo: la relación entre calidad entregada y coste marginal por tarea.
Los datos recientes lo confirman: los modelos near-frontier (Gemini 1.5 Pro, Claude 3.5 Sonnet, GPT-4o) ofrecen rendimiento a un paso de los modelos reasoning (o1, DeepSeek-R1) con latencia de modelo fast y costes drásticamente inferiores. No existe un "mejor modelo en absoluto". Existe el modelo que cuesta menos por unidad de inteligencia útil para esa tarea específica.
La paradoja: la mayoría de las empresas sigue hardcodeando un único proveedor. Firma un contrato anual, pega la API key en `config.yaml` y espera que el pricing no cambie. Mientras tanto, el mercado se mueve: Qwen2.5-Coder a ~0.10$/M input, Nemotron 3 Ultra (550B MoE, 55B activos) a 300+ tok/s en endpoint NIM, DeepSeek-V2.5 a ~0.28$/M. Cada semana surge un nuevo "best value" para coding, reasoning, summarization, extracción.
La solución no es cambiar de modelo. Es dejar de elegir uno.
La Arquitectura Líquida: Routing por Tarea, no por Fidelidad
El patrón no requiere kernels propietarios. Expone una interfaz `think(input, policy) -> Result` donde la `RoutingPolicy` decide en tiempo de ejecución a dónde enviar la petición.
La policy es un grafo de restricciones:
- Presupuesto máximo por petición (ej. 0.003€)
- Calidad mínima requerida (benchmark score en task-type específico: SWE-bench para coding, GPQA para reasoning, MMLU para knowledge)
- Latencia máxima tolerada (p95 < 2s para UX conversacional, < 10s para batch)
- Compliance (¿datos solo UE? ¿no retención de datos de entrenamiento?)
El orquestador consulta un registry de precios/benchmarks en vivo — un servidor MCP, un JSON actualizado via CI, o un endpoint dedicado — que expone pricing, benchmarks actualizados, disponibilidad para cada endpoint configurado. El agente pregunta: "Tengo una tarea de code-review sobre 500 líneas de Rust. Presupuesto 0.01€. Calidad mínima: SWE-bench > 65%. ¿Quién sirve?" El registry responde: "Qwen2.5-Coder-32B en OpenRouter a ~0.008€ estimados. Fallback: Gemini 1.5 Pro a ~0.012€."
El modelo se convierte en un detalle de implementación. La policy es el activo estratégico.
Un Insight Aplicable Inmediato: El "Cost-Aware Router" en 50 Líneas
Cualquier equipo puede implementar hoy un router mínimo usando LiteLLM (proxy universal) + un registry JSON actualizado diariamente via GitHub Action.
```python
from litellm import completion
import json, os
PRICING = json.load(open("pricing_snapshot.json")) # actualizado daily via CI
def estimate_tokens(text: str) -> int:
return len(text) // 4 # aproximación gruesa
def route(task_type: str, prompt: str, budget_eur: float, min_quality: float):
candidates = [m for m in PRICING
if m["task_scores"].get(task_type, 0) >= min_quality
and m["cost_per_1k_tokens"] * estimate_tokens(prompt) / 1000 <= budget_eur]
if not candidates:
raise ValueError("Ningún modelo satisface restricciones. Sube presupuesto o baja calidad.")
best = min(candidates, key=lambda m: m["cost_per_1k_tokens"])
return completion(model=best["litellm_name"], messages=[{"role": "user", "content": prompt}])
```
El punto no es el código. Es el cambio mental: deja de preguntar "¿cuál es el mejor modelo?" y empieza a preguntar "¿cuál es la policy óptima para esta tarea, hoy?"
Por Qué las PYMES Pueden Moverse Primero
Las enterprise tienen contratos plurianuales, procurement de 6 meses, compliance rígida. Las PYMES no. Una PYME puede mañana por la mañana:
1. Activar 5 endpoints en OpenRouter / Together / Fireworks / local (vLLM, Ollama)
2. Definir 3-4 policies para sus tareas recurrentes (coding, extracción, reasoning, chat)
3. Medir coste/calidad real por tarea, no por benchmark genérico
4. Iterar la policy, no el proveedor
La ventaja competitiva no es elegir el mejor modelo. Es tener la arquitectura para cambiar de modelo mañana por la mañana sin reescribir una línea de código de aplicación.