Métricas de API para modelos ajustados

Un modelo ajustado solo merece conservarse si se mantiene lo bastante rápido, lo bastante estable y lo bastante barato bajo el tráfico de API en vivo.

Si tuviera que monitorear solo unas pocas cosas desde el primer día, vigilaría la latencia, el rendimiento, la tasa de error, la tasa de timeout, la tasa de éxito, la tasa de respaldo, el uso de tokens, el costo por solicitud, la profundidad de cola y la tasa de finalización de tareas. ¿Por qué? Porque un modelo puede devolver 200 OK y aún así fallar la tarea, quemar tokens extra o empujar a los usuarios a marcharse.

Aquí está la versión corta:

• Latencia: vigila el TTFT y p95/p99, no solo los promedios.
• Rendimiento: prueba RPS/TPS bajo concurrencia de producción, no una solicitud a la vez.
• Fiabilidad: separa los 4xx, 5xx, 429, 503 y 504 para que los patrones de fallo sean fáciles de detectar.
• Timeouts: las salidas más largas suelen empujar a los modelos ajustados más allá de los plazos de la solicitud.
• Éxito vs. respaldo: una respuesta de API que funciona no es lo mismo que una respuesta utilizable.
• Tokens: monitorea los tokens de entrada, de salida y totales del campo usage de la API.
• Costo: mide el costo por solicitud, el costo por cada 1000 tokens y el costo p95, no solo el gasto mensual.
• Capacidad: la profundidad de cola y la presión de la caché KV suelen mostrar problemas antes que los gráficos de GPU.
• Resultado del usuario: vigila la tasa de finalización de tareas, la revisión humana y el abandono.
• Riesgo de reversión: si el p99 se dispara, los 5xx + timeouts superan el 5% o la tasa de victorias frente al modelo base cae por debajo del 50%-55%, lo trataría como una advertencia seria.

Ajuste fino con métricas de cómputo personalizadas

Comparación rápida

En resumen: no juzgaría un modelo ajustado solo por las puntuaciones offline. Lo compararía con el modelo base en producción, fijaría límites de reversión antes del lanzamiento y mantendría un panel que muestre velocidad, fallos, gasto y resultado en una sola vista.

Por qué las métricas de API importan más después del ajuste fino

El ajuste fino cambia cómo se comporta un modelo en producción. Bajo tráfico en vivo, la latencia, el uso de tokens y los patrones de fallo pueden moverse. En algunos casos, el ajuste fino reduce los tokens de entrada reemplazando prompts largos. En otros, aumenta los costos de salida al hacer las respuestas más largas ^[6]. Por eso las victorias offline no significan mucho por sí solas. Tienes que contrastarlas con las métricas de API en vivo.

La brecha entre las pruebas offline y la producción es real. La investigación muestra que un modelo ajustado puede ganar 12 puntos en un conjunto de prueba específico de la tarea y aun así perder 6 puntos en benchmarks de razonamiento general como GSM8K ^[2]. No es un caso raro. Es un patrón de fallo conocido llamado olvido catastrófico, donde mejorar una habilidad puede debilitar otras.

La lección aquí es bastante simple: un ajuste fino puede ayudar a la tarea que te importa y aun así perjudicar el rendimiento en otros lugares. Y ese tipo de deriva de benchmark no se ve con claridad si solo miras las puntuaciones offline. Se ve cuando las señales de producción se sitúan junto a los resultados de evaluación.

La deriva de calidad no es el único problema. El ajuste fino de dominio también puede debilitar el comportamiento de rechazo del modelo base, lo que hace al modelo más abierto a jailbreaks e inyección de prompts ^[2]. En producción, ese tipo de desliz aparece rápido: la tasa de éxito cae, la tasa de respaldo sube y empiezan a aparecer picos de error de formas que un conjunto de prueba estático no captará. Esos cambios aparecen en las métricas de API que siguen.

1. Latencia de extremo a extremo

La latencia de extremo a extremo es el tiempo total desde que un cliente envía una solicitud hasta que llega la respuesta completa. Eso incluye el tiempo de red, la puesta en cola, la inferencia y la entrega de la respuesta ^[7][9]. Para los endpoints ajustados, esta es una de las primeras señales de producción que vigilar.

Una forma sencilla de pensar en la latencia es esta: total time ≈ TTFT + output_tokens × TPOT ^[9].

El TTFT mide con qué rapidez aparece el primer token, lo que importa mucho para las aplicaciones de streaming ^[9][10]. El TPOT es el tiempo promedio entre tokens generados ^[9]. Esta separación te ayuda a ver qué cambió tras un ajuste fino. ¿Se ralentizó la velocidad de respuesta? ¿Empezó el streaming más tarde? ¿Se ralentizó la generación de tokens?

Los modelos ajustados suelen funcionar entre un 10% y un 20% más lentos que los modelos base. Si la latencia salta más de un 50%, eso suele apuntar a pesos LoRA sin fusionar, cuantización ausente o una salida que se ha vuelto demasiado larga ^[7][8]. La comparación útil es contra el modelo base. Eso te dice si el ajuste fino mejoró la calidad de la tarea lo suficiente para justificar el golpe de velocidad.

La latencia de cola es lo que los usuarios notan durante turnos lentos, reintentos y picos de cola. Un TTFT p95 por encima de 3-4 segundos genera una ralentización clara para los usuarios ^[3]. En un chat interactivo, un TTFT p95 por debajo de 500 ms se siente instantáneo. Una vez que pasa de 3-4 segundos, la experiencia cae rápido ^[12]. Así que no fijes los SLA solo sobre la media. Fíjalos sobre la latencia de cola.

La latencia de cola alta suele apuntar a problemas de profundidad de cola o sobrecarga de arranque en frío, no a la velocidad bruta de la GPU ^[10]. Por eso la latencia por percentiles importa más que el tiempo de respuesta promedio por sí solo.

Antes de medir, ejecuta 2-3 solicitudes de calentamiento. La latencia de la primera llamada suele ser entre un 30% y un 50% más alta ^[8].

2. Latencia p50, p90 y p99

La latencia promedio puede hacer que las cosas parezcan mejores de lo que son. Podrías ver un tiempo de respuesta medio de 1,2 segundos y suponer que el endpoint va bien, mientras el p99 es de 9 segundos ^[15]. Eso significa que el 1% de los usuarios siguen esperando casi 10 segundos, aunque el panel diga que todo se ve normal. Los percentiles te ayudan a ver si el ajuste fino ayudó a la mayoría de las solicitudes o solo empujó la ralentización hacia la cola.

Esto es lo que cada percentil te dice sobre tu endpoint ajustado:

Usa estos percentiles para comparar el modelo base y el modelo ajustado bajo la misma mezcla de tráfico.

Tras el ajuste fino, el p50 y el p99 pueden moverse en direcciones distintas. Si tu ajuste fino conduce a salidas más cortas y estructuradas, el p50 puede bajar porque las solicitudes típicas terminan más rápido. Pero el p99 puede subir si el modelo a veces se vuelve más verboso ^[7][15]. Esa separación importa. Si el p99 sube mientras el p50 se mantiene estable, esa es la señal para investigar a fondo, no el tiempo de respuesta promedio.

El p99 es tu número de riesgo de reversión. Fija puertas de regresión en tu canalización de CI/CD en torno a los umbrales de p99 ^[15]. Si una actualización de modelo empuja la latencia de cola más allá de tu límite, la compilación debería fallar antes de llegar a producción.

La latencia te dice qué tan lentas se sienten las solicitudes. A continuación, mira cuántas solicitudes puede manejar el endpoint.

3. Rendimiento y solicitudes por segundo (RPS)

La latencia te dice cómo rinde una solicitud. El rendimiento te dice cuánto trabajo puede manejar el endpoint a lo largo del tiempo.

Los números principales a monitorear son las solicitudes por segundo (RPS), los tokens por segundo (TPS) y los tokens por minuto (TPM) ^[17][18]. Juntos, muestran si tu endpoint ajustado puede seguir el ritmo del tráfico real, especialmente cuando usas una API LLM unificada para gestionar varios proveedores.

Aquí está el detalle: un modelo puede parecer rápido en una prueba puntual y aun así desmoronarse una vez que el tráfico se acumula. Bajo concurrencia, puedes llegar a un colapso de rendimiento, donde añadir más solicitudes en paralelo ya no aumenta la salida, y la latencia empieza a dispararse con fuerza. Ese punto de inflexión —donde el rendimiento deja de escalar— es tu techo de capacidad ^[15].

Uno de los mayores factores detrás del RPS es la longitud de la salida. Si un ajuste fino empieza a dar respuestas más largas, el rendimiento baja y los costos suben, aunque las respuestas sean mejores ^[6][8].

También ayuda vigilar el goodput, no solo el rendimiento bruto. El goodput es la proporción de solicitudes que aún cumplen los SLO de latencia. Si el goodput es bajo, el endpoint puede estar ocupado pero aun así fallando el objetivo. Ese tipo de brecha suele apuntar a un procesamiento por lotes débil o a saturación del servidor ^[17].

Así que cuando pruebes el RPS y el TPS, hazlo con concurrencia de producción, no con ejecuciones de una sola solicitud. Los límites ligados a los topes de tasa, la profundidad de cola y la VRAM suelen permanecer ocultos hasta que el sistema está bajo carga ^[7][9][15]. Si el endpoint puede sostener la capacidad ahí, entonces es momento de comprobar si esas solicitudes están teniendo éxito.

4. Tasa de error por código de estado HTTP

Una vez que la carga está bajo control, lo siguiente que vigilar es la fiabilidad: con qué frecuencia falla el endpoint. La tasa de error te dice si las solicitudes terminan como deberían. En la práctica, esto se divide en dos grupos: fallos del lado del cliente y fallos del lado del servidor.

Un aumento de errores 4xx suele apuntar a desajustes de prompt o de esquema, o a problemas de ventana de contexto introducidos por el ajuste fino. Un aumento de errores 503 o 504 suele apuntar a tensión del servidor o presión de timeout. Cuando los errores 5xx se disparan, trátalo como un riesgo serio de reversión.

También hay un ángulo económico aquí. Las solicitudes fallidas siguen consumiendo tokens. Para monitorear el gasto desperdiciado, suma los cargos de tokens de las solicitudes fallidas, especialmente los errores 4xx que no sean 429 y cualquier error 5xx ^[22]. Y si la lógica de reintento es demasiado agresiva, esos reintentos malos pueden aumentar el costo de inferencia entre 3x y 5x ^[21].

Aquí tienes un mapa simple de los códigos de estado más comunes, de dónde suelen venir y qué hacer a continuación:

No uses la misma lógica de reintento para cada código de error. Reintentar un 400 solo quema más cómputo porque la solicitud sigue rota. El retroceso exponencial pertenece a los errores 429 ^[21]. Si los 503 o 504 siguen apareciendo en tres comprobaciones, activa un interruptor de circuito y desvía el tráfico al modelo base.

A continuación, comprueba si las respuestas lentas están agotando el tiempo antes de terminar.

5. Tasa de timeout

Cuando los errores suben y no hay un salto claro en fallos rotundos, la tasa de timeout es lo siguiente que comprobar. Un timeout sigue siendo una solicitud fallida: el cliente no recibe respuesta antes del plazo. Monitorea la tasa de timeout como la proporción de solicitudes que superan ese plazo, lo que suele aparecer como errores de timeout del lado del servidor.

Los modelos ajustados tienen más probabilidad de alcanzar timeouts porque suelen producir salidas más largas. Si los datos de entrenamiento tendían a ser verbosos, el modelo puede generar más tokens por solicitud de los que generaba el modelo base. Esto es común cuando se usan modelos Qwen de Alibaba u otros LLM de alto rendimiento que priorizan las respuestas detalladas. Más tokens significan más tiempo de generación, y ese tiempo extra es lo que empuja las solicitudes más allá del plazo ^[8].

Si la profundidad de cola se mantiene por encima de cero, el sistema ya está al límite de su capacidad. Cuando eso pasa, las tasas de timeout suelen subir poco después ^[12]. Trata la profundidad de cola como la señal de advertencia temprana en lugar de esperar a que aparezcan los timeouts. Si la profundidad de cola sube al mismo tiempo que los timeouts, estás ante un problema de capacidad, y necesita acción de inmediato. Una vez que la tasa de timeout se estabilice, separa los éxitos verdaderos de las respuestas de respaldo.

6. Tasa de éxito y tasa de respaldo

Incluso cuando los timeouts desaparecen, las solicitudes pueden seguir sin cumplir el trabajo. La tasa de éxito te dice si el modelo completó realmente la tarea, no solo si devolvió un HTTP 200. Eso significa comprobar cosas como el cumplimiento del esquema, las llamadas a herramientas correctas y la precisión factual. Un modelo ajustado puede registrar una alta precisión de tokens y aun así fallar entre el 15% y el 30% de las consultas de producción en vivo debido a regresiones a nivel de tarea ^[23].

La tasa de respaldo te dice con qué frecuencia hubo que enviar el tráfico a otra parte después de que el endpoint ajustado fallara, agotara el tiempo o fuera bloqueado por filtros de seguridad ^[4][5]. Por eso debería monitorearse justo al lado de la tasa de éxito. No solo estás midiendo finalizaciones. Estás midiendo la salida que puedes usar.

Usa estas dos métricas juntas como señal principal de la calidad de finalización. Si alguna de las dos resbala, ese es el momento de comprobar si el ajuste fino aún se sostiene frente al modelo base. Si la tasa de victorias frente al modelo base cae por debajo del 50%-55%, ese es un umbral de reversión común ^[2][4].

Si el éxito se mantiene alto pero el costo empieza a subir, comprueba el uso de tokens a continuación.

El éxito alto no significa mucho si cada solicitud cuesta demasiado servir.

7. Uso de tokens por solicitud

Después de la fiabilidad, el uso de tokens te dice si el modelo es lo bastante ligero para funcionar a escala. También muestra si el ajuste fino está haciendo su trabajo al reemplazar la sobrecarga del prompt con comportamiento aprendido. Un menor uso de tokens suele significar menor costo y respuestas más rápidas.

Monitorea los tokens de entrada, de salida y totales como números separados. Eso facilita detectar el crecimiento lento antes de que se convierta en un problema de costo. Los tokens de entrada altos suelen apuntar a hinchazón del prompt o desbordamiento del contexto. Los tokens de salida altos suelen significar respuestas prolijas, reglas de parada débiles o falta de tope de salida. Y los tokens de salida cuestan más que los de entrada, así que la verbosidad es el mayor riesgo de costo ^[15].

Extrae los recuentos de tokens del objeto usage de la API en cada respuesta, no de una estimación de tokenizador local ^[15][25]. Las estimaciones locales pueden desviarse de los recuentos facturados. Si ves un pico de tokens de 3x, asume hinchazón del prompt o desbordamiento del contexto hasta que encuentres la causa ^[3]. También ayuda fijar un tope de tokens de salida en CI/CD para captar las regresiones de verbosidad antes de que se desplieguen ^[15].

Los recuentos de tokens se traducen directamente en gasto, por lo que la siguiente métrica es el costo por solicitud.

8. Costo por solicitud y costo por cada 1000 tokens

Los tokens se convierten en dólares. Pero una factura mensual por sí sola no te dice por qué subió el gasto. Para ver qué lo impulsa, monitorea el costo por solicitud y el costo por cada 1000 tokens. Eso te da la siguiente capa de análisis de producción.

El costo por solicitud muestra lo que cuesta una sola acción de usuario. Calcúlalo a partir de los cargos facturados de tokens de entrada, de salida y en caché de esa solicitud ^[26][28]. Luego monitorea la tarifa facturada por cada 1000 tokens por su cuenta. Cuando vigilas ambos números juntos, puedes saber si el gasto sube porque tienes más tráfico o porque los prompts y las respuestas se están alargando. Ese patrón suele llamarse aumento gradual de tokens ^[15][26].

La inferencia ajustada puede costar entre 2x y 5x más por token, pero aun así puede reducir el costo por solicitud cuando recorta la longitud del prompt ^[29][30]. ¿Por qué? Un modelo ajustado incorpora las definiciones de rol, las barreras de protección y los ejemplos few-shot en sus pesos. Así, cada prompt se acorta en cada llamada. En un benchmark, un modelo ajustado necesitó solo 42 tokens de finalización donde el modelo base necesitó 85: una reducción del 50,6% en el costo de inferencia por solicitud ^[19]. En palabras sencillas, el precio unitario más alto puede perder frente al menor recuento de tokens. Esa es la ganancia que quieres medir en el tráfico de API en vivo.

Etiqueta cada llamada a la API con feature_name y user_tier para poder conectar el gasto con el uso del producto ^[27][28]. Eso hace los datos mucho más útiles cuando los costos empiezan a desviarse.

Unas pocas comprobaciones importan más:

• Vigila de cerca los tokens de salida. Con los precios de los modelos insignia, pueden costar 5x más que los tokens de entrada, así que recortar una respuesta prolija ahorra más que recortar el mismo número de tokens de prompt ^[15].
• Fija un techo en la media de tokens de salida en tu canalización de CI/CD. Esto ayuda a captar las regresiones de verbosidad antes de que lleguen a producción ^[15].
• Revisa el costo por función y nivel de usuario, no solo en agregado. De lo contrario, el uso costoso puede esconderse dentro de un total de aspecto saludable.

Después del costo, mira si el gasto coincide con la demanda real o solo con capacidad ociosa.

A continuación, compara estos costos con la utilización de la infraestructura y la longitud de la cola.

9. Utilización de la infraestructura y longitud de la cola

Si la latencia y los timeouts subieron, mira la capa de servicio a continuación: colas, memoria y presión de caché. La profundidad de cola importa más aquí. La utilización de la GPU tiende a ir por detrás de la demanda, así que es una señal rezagada. Por eso el autoescalado debería basarse en la profundidad de cola por réplica, no en el porcentaje de cómputo ^[10][32].

El uso de la caché KV es otra métrica que los equipos suelen pasar por alto. La caché KV almacena el contexto de tokens en la memoria de la GPU, y cuando esa memoria se aprieta, el motor puede empezar a poner en cola nuevas solicitudes aunque el cómputo de la GPU aún parezca disponible ^[31][32]. Una buena regla general: trata un uso de caché KV del 40%-50% como advertencia temprana, y del 90%+ como saturación ^[31][32].

Los modelos ajustados añaden un giro más. Los adaptadores LoRA necesitan memoria además de los pesos del modelo base, y cargarlos en la primera solicitud tras un escalado crea retraso de arranque en frío. En la mayoría de los casos, eso añade unos cientos de milisegundos al TTFT ^[10]. Precargar los adaptadores al inicio evita la mayor parte de ese golpe. También ayuda vigilar la CPU por su cuenta, ya que la tokenización y el preprocesamiento pueden añadir una latencia fácil de pasar por alto ^[10].

Si estas señales de capacidad aún se ven saludables, pasa a la calidad de la salida.

10. Satisfacción del usuario y tasa de finalización de tareas

Después de la latencia, el costo y la fiabilidad, la última comprobación es simple: ¿termina el modelo el trabajo? Un endpoint ajustado puede ser rápido, barato y estable, y aun así fallar el objetivo.

La tasa de finalización de tareas (TCR) es la proporción de solicitudes resueltas sin ayuda humana. La tasa de revisión humana es la proporción de salidas que aún necesitan correcciones manuales. Esa diferencia importa. Un modelo puede devolver un HTTP 200 y aun así entregar algo que una persona tiene que limpiar antes de que alguien pueda usarlo. Así que la TCR monitorea el resultado de negocio, no solo si la API respondió.

En trabajo de salida estructurada, 500 ejemplos de alta calidad pueden llevar el cumplimiento de formato del 68%-74% al 97%-99% ^[33]. Ese tipo de salto reduce con qué frecuencia el personal necesita intervenir. Una vez que el formato es correcto, compara el modelo ajustado directamente contra el modelo base.

La velocidad todavía importa aquí. Una latencia p99 por encima de 5 segundos impulsa aproximadamente un 45% de abandono ^[33]. Así que si el ajuste fino ralentiza la experiencia, los usuarios te lo mostrarán rápido: marchándose.

Para una comprobación directa de calidad, usa pruebas de arena por pares. Ejecuta 200-500 muestras de producción a través de los modelos base y ajustado, luego puntúa las salidas lado a lado con un LLM como juez. Después de eso, fija el modelo juez y la rúbrica para que las pruebas futuras se mantengan consistentes. Si la tasa de victorias frente al modelo base cae por debajo del 50%-55%, ese es un umbral de reversión común ^[2][4].

También ayuda vigilar estas señales juntas:

• TCR
• Tasa de victorias en arena
• Una suite de benchmark congelada

Si el modelo cae más de 5 puntos en los benchmarks generales, trátalo como un fallo grave, incluso cuando las puntuaciones específicas de la tarea suban ^[2].

Usa estas comprobaciones de calidad junto a las métricas de API de las secciones anteriores al decidir si el ajuste fino está listo para producción.

Tabla de comparación de latencia y rendimiento

Ninguna métrica única cuenta toda la historia de un endpoint ajustado. La latencia promedio, por ejemplo, puede suavizar las oscilaciones de solicitud a solicitud, especialmente cuando entran en juego la puesta en cola y el procesamiento por lotes del lado del proveedor ^[9].

Por eso ayuda medir la latencia y el rendimiento por separado primero, y luego compararlos lado a lado antes de fijar los SLO.

Desglosa los resultados por tipo de endpoint, versión del modelo, región y hora del día. El tráfico de hora punta suele sacar a la superficie problemas de latencia que las pruebas fuera de pico no captarán.

Esos cortes hacen mucho más fácil ver dónde empieza a tener problemas un endpoint ajustado bajo el tráfico en vivo.

Métricas de fiabilidad que señalan riesgo de reversión

La señal más clara de que puede necesitarse una reversión es la tasa de victorias frente al modelo base. Ejecuta canarios por pares y enrutamiento en sombra para poder comparar el modelo ajustado contra el modelo base lado a lado. Si la tasa de victorias cae por debajo del 50%, el ajuste fino ya no está aportando valor en producción. Tu capa de enrutamiento también debería revertir automáticamente cuando la cohorte canaria mantenga una caída de 2 puntos en cualquier puntuación de calidad por rúbrica durante 30-60 minutos ^[2][4]. Una vez que esas comparaciones se vuelven negativas, el siguiente movimiento es simple: encontrar los grupos de prompts que se están rompiendo.

Algunas otras señales deberían actuar como disparadores de reversión: tasa de 5xx + timeout, tasa de rechazo, tasa de salida inválida, picos de 429 y comportamiento de respaldo. Estos son los números que importan cuando decides si el ajuste fino debe seguir en vivo. Monitorea los picos de 429 por su cuenta. A menudo apuntan a un mayor costo de cómputo o colas más profundas ^[24][5].

También ayuda separar la tasa de rechazo de la tasa de salida inválida en lugar de agruparlas. Los rechazos por encima del 2% suelen apuntar a una regresión de seguridad o a filtros del proveedor que chocan con tus prompts personalizados ^[5][35]. La tasa de salida inválida suele apuntar a deriva de esquema o a un seguimiento de instrucciones más débil ^[2][24].

Desglosa cada métrica por tipo de prompt, ruta de flujo de trabajo y versión del modelo. Un modelo puede verse bien en solicitudes generales y aun así tener problemas en rutas de salida estructurada o prompts específicos de dominio. Esa separación hace mucho más fácil juzgar si el modelo es seguro para mantenerlo funcionando y si el perfil de costo aún se sostiene.

Métricas de costo, tokens y recursos en términos de dólares

Después de la latencia, el rendimiento y la fiabilidad, el siguiente paso es simple: ¿vale el endpoint el dinero? Un tráfico estable no ayuda mucho si cada solicitud cuesta demasiado. Una vez que la fiabilidad está bajo control, necesitas convertir el uso de tokens en dólares.

Para GPT-4o, el precio de la inferencia ajustada viene con un recargo de 1,5x sobre las tarifas base. Eso equivale a $3,75 por cada 1M de tokens de entrada y $15 por cada 1M de tokens de salida ^[36]. Ese costo extra solo tiene sentido si el ajuste fino reduce el costo de obtener un resultado exitoso. Una forma común de recortar el gasto es a través de descuentos agregados para API de IA y el cascadeo de modelos: envía las consultas simples a un modelo más pequeño y de menor costo, y guarda el modelo más grande para las tareas más difíciles ^[37].

También ayuda pronosticar el gasto en los casos de carga ligera, esperada y alta. Luego añade los reintentos, el uso de respaldo y las ejecuciones de evaluación ^[26]. Ese paso importa más de lo que muchos equipos esperan, porque el 40% de los equipos supera su presupuesto de API de IA en el primer trimestre de uso ^[37]. Además, monitorea el costo p95 por solicitud, no solo el promedio. De lo contrario, los prompts de contexto largo o los reintentos repetidos pueden sesgar tu pronóstico de formas que la media no mostrará ^[24]. El gasto bruto solo se vuelve útil cuando lo conectas con resultados exitosos.

Esa conexión es el costo por resultado exitoso. En la práctica, eso podría significar el costo por ticket de soporte resuelto o el costo por respuesta aceptada. Si un modelo ajustado eleva la proporción de resultados exitosos, tu costo por resolución puede bajar aunque el precio por solicitud suba ^[26][37].

Para los despliegues autoalojados, la utilización de la GPU es el principal impulsor del costo. El gasto fijo de GPU solo se rentabiliza una vez que el uso supera cierto umbral. En otras palabras, la alta utilización importa cuando mejora la eficiencia de costos. También deberías vigilar la longitud de la cola junto a la utilización. Si la profundidad de cola sigue subiendo, eso suele ser señal de saturación, costo añadido y más presión de escalado ^[11][15].

Usa estas métricas juntas para distinguir entre una carga saludable y el desperdicio costoso.

Señales de calidad que puedes observar a través de la API

Una vez que la latencia, el rendimiento y el costo están en buena forma, el siguiente paso es simple: comprueba si el modelo está ayudando de verdad a los usuarios a hacer las cosas. La velocidad importa, claro. Pero una respuesta rápida que no resuelve el problema sigue siendo un fallo.

Enfócate primero en la tasa de finalización de tareas, la tasa de escalado y la tasa de traspaso humano. Estas son tus principales señales de resultado. Te dicen si el modelo ajustado manejó la solicitud por su cuenta o si alguien tuvo que intervenir. Y eso importa más que las puntuaciones de benchmark porque estas métricas provienen de registros reales de solicitud y sesión.

También puedes monitorear las valoraciones de pulgar arriba/abajo y la tasa de abandono como señales de apoyo a nivel de sesión ligadas al tráfico de API. Aunque la retroalimentación sea escasa, aún puede mostrar puntos de dolor repetidos. El abandono es especialmente útil porque muestra dónde el modelo empieza a desviarse, pierde el contexto o deja de ser útil a mitad de una conversación.

También ayuda muestrear el tráfico en vivo con un LLM como juez para estimar los problemas de alucinación y seguridad. Una muestra del 5% suele bastar para captar anomalías sin elevar demasiado el gasto de evaluación ^[39]. Vigila también la frecuencia de activación de barreras de protección. Si más del 20% de las solicitudes se bloquean, eso puede apuntar a un salto en salidas inseguras o a un desajuste entre lo que los usuarios quieren y lo que el sistema espera ^{[38] [1] [2]}. Un aumento brusco de la tasa de rechazo suele significar que los filtros se han vuelto demasiado sensibles o que una plantilla de prompt se rompió en algún punto de la pila ^{[39] [2]}.

Cada fallo en vivo debería volver al conjunto de prueba offline como un caso permanente. Así es como impides que el mismo problema vuelva a colarse más tarde.

Usa la tabla de abajo para separar las señales de calidad principales de las de apoyo.

Usa estas señales junto a la latencia y el costo en el panel de observabilidad.

Paneles de observabilidad para endpoints ajustados

Monitorear métricas individuales ayuda. Pero la recompensa llega cuando ves todo en un solo lugar.

Una configuración sólida de observabilidad para endpoints ajustados se apoya en cuatro pilares: métricas para señales agregadas como la latencia y las tasas de error, trazas para el recorrido completo de una solicitud, registros para constancias estructuradas de lo que pasó y evaluaciones para comprobaciones de calidad asíncronas ^[40][42].

Esto importa aún más con los modelos ajustados. Una solicitud puede tener éxito a nivel de sistema y aun así fallar a nivel de significado, incluso cuando se usa una interfaz de chat de IA. Así que el panel necesita mostrar los fallos semánticos, no solo el éxito de transporte. El APM de la vieja escuela puede mostrar que una respuesta fue saludable. No puede decirte si la respuesta estaba equivocada. Un 200 OK aún puede esconder un mal resultado.

Construye el panel en torno a cinco vistas: latencia, fiabilidad, costo, calidad y capacidad. Usa OpenTelemetry con las convenciones semánticas de GenAI, y muestrea las trazas por cola para conservar todas las solicitudes lentas y fallidas mientras muestreas una pequeña porción del tráfico normal ^[40][41]. Esa configuración también se rentabiliza durante los incidentes: el rastreo puede reducir el tiempo medio de recuperación en 3x ^[42].

Usa esas señales para crear un panel con cinco paneles centrales: latencia, fiabilidad, costo, calidad y capacidad.

Una buena forma de pensarlo: la latencia te dice qué tan rápido se movió el sistema, la fiabilidad muestra si se mantuvo en pie, el costo muestra lo que cuesta cada respuesta, la calidad muestra si la respuesta fue buena y la capacidad te dice cuándo el sistema empieza a calentarse.

Tabla de diseño del panel

Esta tabla vincula cada widget del panel con el tipo de gráfico que funciona mejor y los filtros que lo hacen útil durante los incidentes y las revisiones de costo.

Para que esos filtros funcionen desde el primer día, etiqueta las trazas durante la instrumentación con el ID del modelo, la versión del prompt y el entorno. Las convenciones semánticas de GenAI de OpenTelemetry incluyen atributos como gen_ai.request.model y gen_ai.usage.input_tokens ^[40].

Elige el gráfico que hace fácil detectar el patrón de fallo de un vistazo.

La atribución de costo muestra qué versión del modelo está impulsando el gasto. El explorador de trazas importa más para los flujos de trabajo RAG y de agentes porque muestra la latencia y los errores a través de la recuperación, las llamadas a herramientas y la inferencia ^[43][40].

Después de definir cada widget, fija las reglas de retención y muestreo. Almacena todas las solicitudes de alta latencia, con error y de baja puntuación de calidad en el explorador de trazas. Luego muestrea las solicitudes exitosas de rutina a un 5%-20% para mantener bajo control los costos de almacenamiento ^[40].

Conclusión

La evaluación del ajuste fino tiene que demostrar mejora, no solo cambio. Por eso el cuadro de mando final necesita mirar las métricas de velocidad, fiabilidad, costo y resultado juntas.

Si ajustas una métrica de forma aislada, los problemas de producción pueden colarse rápido. Un modelo podría volverse más rápido pero menos estable. O podría reducir el tiempo de revisión mientras aumenta los errores. El punto es monitorear el panorama completo, no una sola porción.

Empieza con el modelo base. Sin esa referencia, no puedes demostrar que el ajuste fino hizo algo mejor. Ejecuta un canario del 5%-10% y compara esos resultados contra el modelo base mediante enrutamiento en sombra. Fija alertas cuando la latencia supere 2x el valor base o cuando la tasa de error pase del 5% durante 5 minutos. Una vez que esas barreras estén fijadas, conecta los números con el ahorro operativo.

Cada métrica debería mapear a un resultado de negocio. La tasa de revisión humana es un indicador directo del ahorro operativo. Si ese número no se mueve, el ajuste fino no está creando valor de producción.

Los paneles y las alertas no son opcionales. Construye la observabilidad antes del lanzamiento para que las regresiones aparezcan antes de que los usuarios las noten.

Preguntas frecuentes

¿Qué métricas de API debería monitorear primero?

Empieza con las métricas de infraestructura y fiabilidad para comprobar que el sistema es estable. Enfócate en el TTFT en el percentil 95, la latencia de extremo a extremo, las tasas de error graves, la tasa de rechazo y el costo por solicitud.

Una vez que tengas esas referencias, vigila la calidad de la salida con puntuaciones de LLM como juez y la deriva de capacidad. Eso te ayuda a detectar si el modelo ha empezado a resbalar en habilidades centrales.

¿Cómo comparo un modelo ajustado con el modelo base?

Ejecuta ambos modelos en el mismo conjunto de prueba reservado —datos nunca usados en el entrenamiento— para poder medir la brecha de forma limpia. Empieza con una referencia de prompting fuerte en el modelo base primero. Eso te da un punto de comparación justo en lugar de amañar la baraja.

Compara los modelos en calidad, latencia y costo.

Para la calidad, usa métricas que se ajusten al trabajo, como:

• F1 para tareas de clasificación o extracción
• Coincidencia exacta para tareas con una sola respuesta correcta
• Tasa de análisis de JSON para salidas estructuradas

Para la latencia, mide el tiempo de respuesta de extremo a extremo, no solo el tiempo de ejecución bruto del modelo. Eso significa cronometrar la ruta completa de la solicitud desde el envío del prompt hasta la salida final.

Para el costo, usa el precio por cada 1M de tokens de cada modelo y calcula lo que pagarías según el uso real de tokens de entrada y salida en el conjunto de prueba.

¿Cuándo debería revertir un modelo ajustado?

Revierte cuando el monitoreo de producción muestre que la calidad ha caído de forma clara. Eso puede apuntar a deriva del modelo o a un fallo con entradas en vivo.

También deberías revertir si el modelo resbala en tu conjunto de rechazo, abre nuevas debilidades de inyección de prompts o rinde peor que la versión actual durante las pruebas canarias en producción.

Mantén un ojo atento en la latencia p95 y en los problemas de calidad reportados por los usuarios para poder detectar los problemas temprano.