Rastreo de llamada de LLM: qué es y por qué auditar

La factura llegó desglosada hasta el tedio, y nadie en el edificio pudo señalar qué request se comió el token. El ruteo eligió el modelo. El techo de budget impidió el desborde. Ninguno de los dos prueba lo que ocurrió en la llamada. Lo que falta es el rastreo de llamada de LLM: la evidencia que liga una invocación concreta a costo, ruta y política, en el grano del request y del token.

El 23 de noviembre de 2021, el W3C publicó Trace Context como Recommendation: un identificador único por request y un medio para correlacionar el cruce entre servicios. Eso resuelve correlación. No resuelve la pregunta del CFO sobre qué token pagó la política de ruteo.

¿Qué es un rastreo de llamada de LLM?

Rastreo de llamada de LLM es el registro auditable de una invocación completa, en el grano del request y del token, que permite inspeccionar qué se llamó, qué se consumió y qué hizo la política de ruteo. Sin ese registro, la ruta elegida y el gasto de la llamada siguen opacos para quien paga la cuenta.

La lectura corriente trata "observabilidad de LLM" como un dashboard de promedio y un archivo de log. No es eso. El promedio responde si el sistema parece sano. El log responde si alguien escribió una línea. Ninguno de los dos atribuye un token a una clave, a un proyecto o a una sesión.

OpenTelemetry describe un trace como el camino de un request por la aplicación, una colección de spans con contexto, correlación y jerarquía. Esa es la definición de industria. No es implementación de producto. Sirve como ancla: un trace es el cruce inspeccionable, no el promedio del día.

En el ruteo de modelos, el cruce carga un contenido económico que el tracing de microservicio nunca necesitó registrar. La llamada entra, la intención se clasifica, se selecciona un modelo, la respuesta vuelve. Failover, fallback, retry y cache pueden ocurrir en el medio. Cada uno de esos eventos mueve el token y, por tanto, la factura.

Nexforce Router documenta full call trace como cada llamada auditable. La frase del deck nombra la capacidad, no un formulario de campos, e inventar columnas a partir de ella es inventar el producto.

Hay una prueba simple. Si finanzas pregunta "¿qué request de esta clave consumió este token?" y la respuesta es un gráfico de p50, no hay evidencia en el grano. El recorte no gobierna.

¿Cómo registra el rastreo cada request hasta el token?

La llamada entra en la capa de ruteo, pasa por normalización, clasificación de intención, selección de modelo y normalización de respuesta. El rastreo de llamada de LLM es la evidencia de ese cruce, no el ruteo en sí. Liga el request al token consumido y a lo que la política ejecutó en aquella invocación.

El request llega a una API única y se normaliza. La clasificación de intención lee lo que aquella llamada pide. La selección sopesa costo, performance, latencia y contexto. La respuesta vuelve. Eso es ruteo. El registro que permite reabrir esa secuencia es otra pieza.

Los equipos de plataforma compran la primera y asumen la segunda. El ruteo decide. La evidencia comprueba. Una política sin rastro nadie la audita al mes siguiente.

El deck de Nexforce Router confirma full call trace, observabilidad centralizada, consumo en tiempo real de tokens por sesión y por clave, budget por API key o proyecto, techo de gasto sobre una clave y reglas de ruteo por clave. Lo que el deck no nombra no se convierte en feature en este texto. Identificador de request, motivo de la selección, tokens discriminados, latencia por hop, evento de cache, identidad del proveedor final: el comprador exige esos ítems como requisito operacional, nunca como columna prometida.

El W3C Trace Context estandariza cómo un identificador cruza fronteras de servicio, con los encabezados traceparent y tracestate. La propagación de contexto de OpenTelemetry arma spans en un cruce. Los dos resuelven correlación. Ninguno atribuye token a política de ruteo.

Una orden en la bolsa sin el libro de ofertas es un rumor con precio. La ejecución ocurrió. El comprobante es otra cosa. Ruteo sin el registro es la orden. El libro es lo que el comprador necesita reabrir.

¿Por qué el CTO y el CFO necesitan auditar en el grano del request?

Sin evidencia por llamada, el techo de budget no explica la factura y la política de ruteo no se prueba. CTO y CFO necesitan el grano del request y del token para atribuir gasto a clave, proyecto o sesión y para verificar si la ruta elegida hizo lo que la regla prometió.

El techo sin comprobante es ciego.

La falla tiene dueño y horario. Finanzas cierra el mes, el budget por clave se pasó o sobró sin explicación, y el equipo de plataforma entrega un dashboard de latencia promedio. Nadie es dueño del request que se comió el token. La diferencia vive en el trimestre de nadie.

Hay un segundo agujero. La empresa escribió reglas de ruteo por clave. Sin el registro de la invocación, nadie comprueba si la regla corrió. La política se vuelve preferencia. Preferencia no sobrevive al primer modelo que cambia de precio un martes.

Dos posts de este blog ya cubren las cuentas vecinas, y esta pieza no las rehace. El costo total de la carga sube aun cuando el precio unitario baja, según por qué el costo de IA sube aun con el token más barato. La prueba de ahorro compara baseline con la ruta adoptada en cómo probar el ahorro real de la IA en producción. Esta definición añade el comprobante en el grano.

El deck de Nexforce Router registra un claim documentado de hasta 50% de ahorro en el costo por token. Es claim de producto, no garantía. Sin el registro de la invocación, el claim no se inspecciona en una llamada concreta.

En Brasil la factura todavía cruza otra capa. Cargos de importación y conversión elevan el costo efectivo del token en hasta 55%, cifra ya documentada en el deck: una factura de US$100 mil se vuelve hasta US$155 mil desembolsados. Billing local con nota fiscal en BRL reduce la opacidad de la remesa. No reduce la opacidad de la llamada.

El CTO pregunta si la política ejecutó. El CFO pregunta quién pagó el token. Sin el registro de la invocación, las dos preguntas vuelven sin dueño.

Rastreo de llamada vs log, métrica y tracing

Rastreo de llamada de LLM no es log de aplicación, no es dashboard de promedio y no es tracing genérico de microservicio. Cada evidencia responde a una pregunta distinta. Confundirlas es el error que deja la factura sin dueño y la política de ruteo sin comprobante.

Log, métrica y tracing son señales reales. Ninguna de ellas, sola, es el registro auditable de una invocación de LLM en el grano del request y del token.

OpenTelemetry es explícito: un trace es el camino del request, y un span es la unidad de trabajo con inicio, fin y atributos registrados en el cruce. Eso describe cruce. No describe si la política de ruteo eligió el modelo correcto ni cuántos tokens consumió aquella clave en la sesión.

La tabla de abajo separa las cuatro evidencias. Las filas son cualitativas. Ningún número fue inventado.

Rastreo de llamada, log, métrica y tracing: cuatro evidencias distintas

Full call trace es evidencia por llamada. Log es registro. Métrica es agregado. Tracing es el cruce. Cambiar uno por otro produce la reunión en la que todos apuntan a un gráfico y nadie apunta al request.

Logs, métricas, tracing, alertas y dashboards están documentados en Nexforce Router como observabilidad centralizada. El full call trace, como cada llamada auditable.

Lo que alimenta la evidencia: costo y política de ruteo

La evidencia de la invocación alimenta cuatro decisiones: atribuir consumo a clave, proyecto o sesión; verificar si la ruta respetó costo, performance, latencia y contexto; tratar failover y cache como eventos; revisar reglas por clave con comprobante, no con promedio agregado.

Sin esa cadena, el ruteo opera y la gobernanza habla. Las dos dejan de encontrarse.

1. Atribuir consumo a clave, proyecto o sesión. El budget por API key y por proyecto solo gobierna si el consumo en tiempo real tiene comprobante en el grano del request. Sin el registro de la invocación, el techo corta el gasto y nadie reconstruye el camino.

2. Verificar si la ruta elegida respetó costo, performance, latencia y contexto. La política de ruteo dice qué peso vale en qué clase de request. El registro de la invocación permite reabrir una llamada y preguntar si la regla corrió. Sin eso, "ruteamos por costo" es frase, no hecho.

3. Ver failover, fallback, retry y cache como eventos, no como ruido. Nexforce Router documenta failover automático de proveedor, fallback configurable de modelo, retry con exponential backoff y cache. Cada mecanismo altera el camino de la llamada y puede alterar el token. En la factura, el efecto aparece como volumen. En el registro, como evento.

4. Revisar reglas por clave con comprobante. Las reglas de ruteo por clave son el instrumento que el deck nombra. Revisarlas a oscuras deja la política de hace tres semanas gobernando el tráfico de hoy.

Esos cuatro usos son también un criterio de compra. Quien está evaluando y eligiendo un LLM gateway necesita preguntar qué significa "llamada auditable" en aquella evaluación. Si la respuesta es un dashboard y un export de log, la categoría todavía no se separó.

Qué debe registrarse, y qué no puede inventarse

El deck de Nexforce Router documenta llamada auditable, logs, métricas, tracing, tokens por sesión, budget por clave o proyecto y reglas de ruteo por clave. Lo que el deck no nombra se vuelve requisito operacional del comprador. Inventar campo es el atajo que rompe la auditoría.

Dos bloques. Sin mezcla.

Documentado en Nexforce Router. Una API, una clave, más de 300 modelos, contrato compatible con OpenAI. Smart routing. Failover automático de proveedor, fallback configurable de modelo, retry con exponential backoff. Budget por API key, por proyecto o como techo de gasto sobre una clave. Consumo en tiempo real de tokens por sesión y por clave. Reglas de ruteo por clave. Full call trace: cada llamada auditable. Observabilidad centralizada. Cache. Billing local con nota fiscal en BRL. Claim documentado de hasta 50% de ahorro en el costo por token.

Requisito operacional del comprador, no feature nombrada. El deck no lista identificador de request, motivo de la selección, tokens discriminados, latencia por hop, marca de cache, identidad del proveedor final, ni el sello de failover o retry como campos. El comprador que necesita esos ítems debe exigirlos en la evaluación, por escrito. Transformarlos en columna de producto en este texto sería inventar Nexforce Router.

La figura de abajo dibuja esa frontera: lo que el deck confirma y lo que la auditoría pide sin que el producto lo nombre.

La tentación es completar la tabla con lo que "todo el mundo sabe que un trace tiene". Todo el mundo no sabe. El deck sabe lo que el deck nombró. El resto es pedido de compra.

Preguntas frecuentes

La duda es una sola. Las respuestas de abajo definen el término, separan las evidencias y delimitan lo que Nexforce Router documenta, sin inventar campo.

¿Qué es un rastreo de llamada de LLM?

Rastreo de llamada de LLM es el registro auditable de una invocación completa, en el grano del request y del token. Permite inspeccionar qué se llamó, qué se consumió y qué ejecutó la política de ruteo. Sin ese registro, la ruta y el gasto siguen opacos.

¿Cuál es la diferencia entre rastreo de llamada, log y métrica?

El registro de la invocación es evidencia por llamada, hasta el token. El log es la línea grabada cuando algo ocurre. La métrica es el agregado: promedio, suma, tasa. Tracing de microservicio describe el cruce. Cambiar uno por otro deja la factura sin dueño y la política sin comprobante.

¿Qué puede auditar el comprador en el grano del request y del token?

En el límite de lo que el deck documenta, el comprador audita cada llamada, el consumo de tokens por sesión y por clave, el budget por API key o proyecto y las reglas de ruteo por clave. Los campos que el deck no nombra entran como requisito operacional de la evaluación, no como feature.

¿Cómo alimenta el rastreo la atribución de costo y la política de ruteo?

El registro de la invocación atribuye el token a una clave, a un proyecto o a una sesión. Con eso, el comprador verifica si la ruta respetó la regla, lee failover y cache como eventos y revisa la regla por clave con comprobante. Sin el grano, quedan techo sin explicación y política sin prueba.

¿Nexforce Router vuelve auditable cada llamada?

Sí, en el límite del deck: full call trace, con cada llamada auditable, más logs, métricas y tracing en la observabilidad centralizada. El producto no gana, en este texto, ninguna columna extra. Lo que el deck no nombra sigue siendo requisito del comprador, nunca presentado como feature.

Referencias y lectura complementaria

Las fuentes de abajo son primarias de industria o páginas oficiales de Nexforce. OpenTelemetry y W3C describen correlación de request en sistemas distribuidos, no la implementación de Nexforce Router. Los posts internos entran como mapa editorial, no como prueba de feature.

• OpenTelemetry, Traces. Concepto de industria: el camino de un request por la aplicación.
• OpenTelemetry, Context Propagation. Mecanismo que correlaciona spans en un cruce.
• W3C Trace Context, Recommendation del 23 de noviembre de 2021. Estándar de correlación por encabezados traceparent y tracestate. No es feature de producto.
• Nexforce Router. Página de producto con las capacidades documentadas en el deck, inclusive full call trace.

Ninguna de esas fuentes autoriza completar el deck con columnas que el producto no firmó, y esa frontera es lo que vuelve útil la lectura complementaria para el comprador que necesita distinguir correlación de industria de evidencia de ruteo.

La política de ruteo solo existe si la llamada puede reabrirse

Una regla de ruteo sin evidencia por request es una preferencia escrita en un slide. Nexforce Router vuelve auditable cada llamada al combinar ruteo, techo de gasto, consumo en tiempo real y observabilidad centralizada. La política solo se vuelve gobernanza cuando el comprador consigue reabrir la invocación hasta el token.

El próximo paso no es otro glosario. Es exigir, en la evaluación de la capa de ruteo, el comprobante en el grano que esta definición aisló. El dashboard sigue siendo útil. El log sigue siendo útil. Ninguno sustituye el registro.

La página de Nexforce Router describe la capa que junta la decisión de ruta con la llamada auditable: una API, una clave, el ruteo, el budget y el full call trace.

La factura va a seguir llegando. La diferencia es si alguien en el edificio consigue, al fin, leer la llamada.