Selección de modelos y gobernanza de costes: de «usar siempre el más potente» a clasificar por tarea

Por qué «usar siempre el modelo más potente» es una trampa de costes

La capacidad de los modelos está estratificada: los modelos insignia destacan en razonamiento de cadena larga, código complejo e instrucciones con múltiples restricciones; los modelos ligeros suelen bastar para clasificación, extracción, conversión de formato y preguntas y respuestas cortas. Y la diferencia de precio unitario entre ambos puede llegar a diez veces o más.

La página de precios actual de Anthropic y la de [API pricing](https://developers.openai.com/api/docs/pricing) de OpenAI dividen sus modelos en varios niveles; tomando como ejemplo la [pricing](https://claude.com/pricing) publicada por Anthropic, los tres niveles Opus, Sonnet y Haiku están orientados a tareas de distinta intensidad, con diferencias de precio unitario evidentes. Encomendar también al modelo insignia los cientos de miles de clasificaciones simples diarias es el desperdicio más fácil de pasar por alto.

Llevar la clasificación por tareas al código

1. Enumera las llamadas a LLM del sistema por «tipo de tarea» (clasificación / extracción / resumen / generación / razonamiento / código).
2. Elige un nivel predeterminado para cada tipo de tarea y escríbelo en la configuración, no en nombres de modelo dispersos por el código.
3. Prepara de 50 a 200 muestras de evaluación fijas por tipo de tarea, incluyendo casos difíciles típicos.
4. Ejecuta primero la línea base con el nivel predeterminado y luego prueba a degradar, comparando la precisión y la tasa de cumplimiento de formato.
5. Mantén la degradación solo si la pérdida de calidad está por debajo del umbral; de lo contrario, vuelve al nivel anterior.

Enrutamiento escalonado: primero lo barato, luego lo caro

Un patrón práctico es «primero lo barato, luego lo caro»: procesar primero con el modelo ligero y escalar al modelo insignia cuando aparezcan estas señales:

• La salida no se puede analizar (JSON malformado, campos faltantes).
• El propio modelo declara incertidumbre o la confianza está por debajo del umbral.
• Se activa una validación de calidad del lado del negocio (por ejemplo, el SQL generado no se puede ejecutar).
• Los indicadores de complejidad de la solicitud superan el umbral (longitud de entrada, número de documentos citados).

Así, la mayor parte del tráfico se queda en el nivel barato y solo las partes realmente difíciles se pagan al nivel insignia. Conviene incluir el número de escalados en la monitorización: una tasa de escalado persistentemente alta indica que toca reevaluar la selección de modelos.

Qué confirmar antes de cambiar entre proveedores

Distintos proveedores no coinciden en el estilo de salida, el formato de llamada a herramientas ni las políticas de rechazo para una misma tarea. Antes de mover un tipo de tarea del proveedor A al proveedor B, hay que confirmar al menos:

• Salida estructurada: si el grado de soporte de JSON mode / schema estricto es equivalente.
• Formato de llamada a herramientas: estructura de parámetros, llamadas en paralelo, forma de devolver errores.
• Longitud de contexto y comportamiento de truncado: si una entrada demasiado larga da error o se trunca en silencio.
• Diferencias en políticas de contenido: el mismo texto es rechazado por un modelo y aceptado por otro.

Clasificar dentro de una misma pasarela

Admesh mantiene externamente el protocolo compatible con OpenAI y expone los modelos como namespace/model (por ejemplo, anthropic/…, openai/…, deepseek/…). Esto significa que la clasificación por tareas solo requiere mantener en la configuración una tabla de correspondencia «tipo de tarea → modelo», y en el código siempre se cambia únicamente el parámetro model.

Como el enrutamiento solo ocurre dentro del pool de canales de un mismo public_model, no sustituirá silenciosamente tu anthropic/xxx por el modelo de otro proveedor: la clasificación la eliges tú explícitamente, no la decide la pasarela por ti.

Ver la interfaz de listado de modelos →