AI Model Routing Policy
Política de selección entre FLAN-T5-small y base con ajuste en desarrollo, evaluación reservada, costo del router y fallos locales inyectados. Publica también el resultado negativo.
Problema y utilidad para agentes
Usar un router no lo vuelve automáticamente más eficiente que un solo modelo. Hay que contar el propio router, los intentos fallidos y las pérdidas de calidad por tipo de tarea.
La comparación mantiene las mismas tareas y deja visibles las decisiones, el fallback y los casos sin respuesta. Permite decidir si la complejidad del router se justifica con los resultados medidos.
Arquitectura
- Política ajustada en desarrollo. 16 tareas ajustan una tabla por tipo mediante exactitud menos 0,02 veces el tiempo medio de inferencia. La evaluación reservada tiene 24 tareas; las etiquetas no entran al router.
- Cuatro estrategias. Compara siempre-small, siempre-base, un selector fijo de 120 caracteres y la política ajustada. Ambos modelos están residentes y fijados por revisión.
- Fallback y contabilidad. Sólo una excepción tipada de indisponibilidad dispara el segundo adaptador. Registra sobrecosto, intentos fallidos, tokens, carga, calentamiento y ajuste por separado.
Qué demuestra
- Separación entre ajuste de políticas y evaluación reservada con baselines explícitos.
- Contabilidad del costo de enrutamiento y degradación por tipo de tarea.
- Fallback controlado, fallo explícito ante dos adaptadores caídos y análisis de un resultado negativo.
Resultados publicados
16 tareas de desarrollo y 24 de evaluación, distribuidas entre sentimiento, extracción, aritmética y lógica. FLAN-T5-small y base ejecutados localmente en Intel Xeon W-3223 con dos hilos.
Tiempo de solicitudes incluye router, despacho, intentos fallidos e inferencia. Carga, calentamiento y ajuste están fuera de esa tabla y se publican por separado. Las caídas son excepciones inmediatas inyectadas en adaptadores locales propios.
Comparación sin fallos inyectados
| Estrategia | Correctas | Tiempo total (s) | Router total (ms) | Tokens generados |
|---|---|---|---|---|
| Siempre small | 12/24 | 4.006823 | 0.021426 | 229 |
| Siempre base | 12/24 | 8.376350 | 0.020290 | 214 |
| Por longitud | 12/24 | 4.359402 | 0.035640 | 229 |
| Política ajustada | 12/24 | 4.401570 | 0.044034 | 229 |
Fallback con política ajustada
| Indisponibilidad inyectada | Correctas | Sin respuesta | Tiempo total (s) |
|---|---|---|---|
| Small caído | 12/24 | 0 | 9.149960 |
| Base caído | 12/24 | 0 | 3.981469 |
| Ambos caídos | 0/24 | 24 | 0.000176 |
Las cuatro estrategias lograron 12/24. El router ajustado fue más lento que siempre-small y no mejoró calidad. Todas fallaron las seis tareas de extracción y las seis de aritmética: cero degradación relativa puede esconder una calidad absoluta insuficiente.
La inferencia de desarrollo tomó 3,600025 s y el ajuste de la política 0,124500 ms. El tiempo completo de evaluación fue 41,797864 s, incluyendo preparación, las cuatro estrategias, caídas y grabación de evidencia. Evidencia original.
Reproducir
Replay con Python 3.11 y biblioteca estándar, sin descargas de modelos. La reproducción neural requiere las dependencias fijadas y snapshots públicos de ambos modelos.
Los comandos usan POSIX y omiten el coordinador específico de la máquina del autor. Ejecutá una medición por vez y conservá desarrollo y evaluación en directorios nuevos relacionados mediante --dev.
Revisar la evidencia guardada
git clone https://github.com/lucioduran/ai-model-routing-policy.git
cd ai-model-routing-policy
git checkout 1e891db0bfc7c6ad77a1baae3b93f5a76a558435
python -m routing verify --split dev --output results/dev
python -m routing verify --split eval --dev results/dev --output results/evalRepetir la medición local
python3.11 -m venv .venv
. .venv/bin/activate
python -m pip install -r requirements-local.lock
python -m routing download
OMP_NUM_THREADS=2 MKL_NUM_THREADS=2 python -m routing run --split dev --output build/dev
OMP_NUM_THREADS=2 MKL_NUM_THREADS=2 python -m routing run --split eval --dev build/dev --output build/eval
python -m routing verify --split eval --dev build/dev --output build/evalAlcance y límites
- Cuarenta tareas sintéticas y una ejecución no establecen ahorros de producción. Las familias se superponen entre particiones y no hubo revisión humana independiente.
- El llamador suministra el tipo de tarea: no se mide un clasificador de intenciones. La política penaliza latencia, sin imponer una garantía dura de calidad.
- Los fallos inmediatos no modelan red, timeouts ni costos de reintentos remotos. Ambos modelos residentes tampoco representan un despliegue con presión de memoria.
- API paga: USD 0. CPU medida no equivale a energía ni factura. Los tiempos excluyen carga y calentamiento a nivel de solicitud.
Fuentes y revisión
Los valores de esta ficha provienen del informe enlazado. No son una medición en vivo. El informe conserva la revisión ejecutada; la revisión consultada incluye la publicación posterior de ese informe.
- Revisión consultada:
1e891db0bfc7c6ad77a1baae3b93f5a76a558435 - Revisión registrada por el experimento:
ae4081c9097561b40652b5c2f2680cba37660af2 - Fecha del informe (UTC):
- Release publicada: v0.1.0 ·