Módulo 7: Observability Latency And Evals In Production
7. El límite exacto: por qué la latencia y la calidad reales no se pueden medir aquí
Descripción
Las lecciones 3, 4 y 6 de este módulo corrieron, todas, código real: un logger estructurado, un cálculo de tasa de escalamiento, un arnés de smoke test. Esta lección documenta, con la misma honestidad exacta que el Módulo 3, lección 6 ya aplicó a apply, y el Módulo 4, lección 7 ya aplicó al bloqueo del guardrail gestionado, el límite que ninguna de esas tres lecciones puede cruzar: la latencia real de extract-shipment-manifest-fields, y la calidad semántica que el M7.5/M7.6 deliberadamente no mide, solo pueden confirmarse invocando el modelo real — algo que este laboratorio $0, declarado desde el Módulo 1, nunca hace.
Conexión con el módulo
Esta lección retoma, para latencia y calidad, exactamente el mismo patrón que el Módulo 1, lección 7 estableció para list-foundation-models, el Módulo 3, lección 6 aplicó a apply, y el Módulo 4, lección 7 aplicó al bloqueo del guardrail: documentar el schema real de lo que se mediría, con precisión y con fuente oficial verificada hoy, sin presentar nunca un número inventado como si fuera medido.
Paso 1 — Las métricas reales que Bedrock publicaría, si una invocación ocurriera
Amazon Bedrock, para cualquier invocación real a través de bedrock-runtime, publica un conjunto fijo de métricas en CloudWatch, bajo el namespace AWS/Bedrock — verificado hoy contra la documentación oficial:
| Métrica | Unidad | Definición exacta |
|---|---|---|
InvocationLatency | Milisegundos | "The time from when a request is sent to when the last token is received." |
TimeToFirstToken | Milisegundos | "Time from when a request is sent to when the first token is received" — solo para las operaciones de streaming (ConverseStream, InvokeModelWithResponseStream) |
InputTokenCount / OutputTokenCount | Conteo | Número de tokens en la entrada / salida de la invocación |
Invocations | Conteo | Número de invocaciones exitosas a Converse/ConverseStream/InvokeModel/InvokeModelWithResponseStream |
InvocationThrottles | Conteo | Invocaciones que el sistema limitó por cuota |
— AWS Docs — Monitor bedrock-runtime inference using CloudWatch metrics
Estas seis filas no son una lista inventada para esta lección — son, literalmente, las filas de la tabla oficial de AWS, transcritas sin cambios. Y aquí está el punto central de esta lección, dicho de la forma más simple posible: cada una de estas métricas solo tiene un valor si una invocación real produjo ese valor. InvocationLatency no es un número que AWS publique de antemano, como un precio en una lista — es el resultado de cronometrar una llamada específica, que en este laboratorio nunca ocurre.
Paso 2 — Por qué la latencia de un modelo no es un número fijo, ni siquiera en teoría
Vale la pena entender, con precisión técnica real, por qué la latencia no podría ser un número único ni siquiera si esta guía sí invocara el modelo. La misma documentación de AWS que definió InvocationLatency explica la mecánica exacta:
"An inference request passes through two compute-bound stages on the model host: Prefill. The model processes the entire input prompt in a single forward pass and produces the first output token. The duration of this stage scales primarily with input length and is the main driver of
TimeToFirstToken. Decode. The model generates each subsequent output token sequentially, one token per forward pass. The total time of this stage scales with the number of output tokens."— AWS Docs — Diagnose
InvocationLatencyincreases using output tokens per second (OTPS)
Y la relación exacta entre las tres métricas, también citada textual de esa misma fuente:
InvocationLatency (ms) = TimeToFirstToken (ms) + (OutputTokenCount / OTPS) * 1000Esto significa que InvocationLatency depende de dos variables que cambian con cada manifiesto: cuánto texto tiene el manifiesto de entrada (que determina la etapa de prefill, y por lo tanto TimeToFirstToken), y cuántos tokens produce la respuesta (que determina la etapa de decode). Un manifiesto de texto libre de tres líneas y uno de tres párrafos, con el mismo modelo, en el mismo momento, producirían valores de InvocationLatency distintos — no por inconsistencia del servicio, sino porque la física del cálculo (más texto de entrada, más texto de salida) así lo determina. No existe, ni podría existir, un único "número de latencia" para Nova Lite — solo una distribución de valores, sobre tráfico real, con la forma exacta que la fórmula de arriba describe.
POR QUE NO HAY UN NUMERO FIJO DE LATENCIA, NI EN TEORIA
Manifiesto corto, respuesta corta Manifiesto largo, respuesta larga
│ │
▼ ▼
Prefill rapido -> TimeToFirstToken bajo Prefill lento -> TimeToFirstToken alto
│ │
▼ ▼
Decode rapido (pocos tokens) Decode lento (muchos tokens)
│ │
▼ ▼
InvocationLatency BAJO InvocationLatency ALTO
Mismo modelo. Misma cuenta. Mismo minuto. Valores DISTINTOS -- por diseño.Paso 3 — El hallazgo honesto: ni siquiera la iniciativa de latencia de AWS cubre el modelo elegido
Antes de concluir que "no hay ningún número publicado", vale la pena confirmar que sí se buscó uno con precisión. AWS sí publica una iniciativa específica para reducir latencia — verificado hoy contra el anuncio oficial:
"Amazon Bedrock now offers latency-optimized inference for foundation models [...] currently supports Anthropic's Claude 3.5 Haiku model, as well as Meta's Llama 3.1 405B and 70B models."
— AWS — Introducing latency-optimized inference for foundation models in Amazon Bedrock
Nova Lite —el modelo que GENAI-COST-PROFILE.md (Módulo 2, lección 8) eligió para Andes Cargo— no está en esa lista. Este no es un detalle menor: significa que ni siquiera la pieza más directa de marketing de AWS sobre latencia de Bedrock —la que sí incluiría, si existiera, una comparación de milisegundos— cubre el modelo específico de esta guía. Lo único que la documentación pública de la familia Nova ofrece es una afirmación cualitativa, sin número:
"Nova Micro delivers the lowest latency responses in the Amazon Nova family of models."
Nótese, además, que esta cita es sobre Nova Micro, no Nova Lite — el modelo que Andes Cargo eligió es, según la propia documentación de AWS, el segundo más rápido de su familia, no el más rápido, sin que exista un número que cuantifique esa diferencia. Esta guía busca con la misma disciplina de investigación de cada lección anterior —WebFetch contra documentación oficial, hoy, no memoria de entrenamiento— y el hallazgo honesto es que no existe un rango de milisegundos publicado por AWS para Nova Lite, ni en su ficha de modelo, ni en el blog de lanzamiento, ni en la iniciativa de latencia optimizada.
Paso 4 — Ejemplo representativo: el formato que un InvocationLatency real tendría
Con el schema real del Paso 1 confirmado, y sin ningún número inventado, así se vería una consulta real a esta métrica, si extract-shipment-manifest-fields invocara Nova Lite de verdad:
awslocal cloudwatch get-metric-statistics \
--namespace AWS/Bedrock \
--metric-name InvocationLatency \
--dimensions Name=ModelId,Value=amazon.nova-lite-v1:0 \
--start-time 2026-08-14T14:00:00Z \
--end-time 2026-08-14T15:00:00Z \
--period 3600 \
--statistics Average p50 p99Qué esperar (representativo — la estructura del comando y de la respuesta está verificada contra el schema real de la API; ningún valor numérico de Datapoints corrió aquí, ni podría, sin una invocación real; y aunque corriera, Bedrock —"Included in Plans: Ultimate"— tampoco está disponible en el plan Hobby de este laboratorio, la misma limitación que el Módulo 1, lección 7 y el Módulo 3, lección 6 ya confirmaron):
{
"Label": "InvocationLatency",
"Datapoints": [
{
"Timestamp": "2026-08-14T14:00:00+00:00",
"Average": "VARIABLE -- depende de la longitud de cada manifiesto de ese periodo",
"p50": "VARIABLE",
"p99": "VARIABLE",
"Unit": "Milliseconds"
}
]
}Fíjate en el campo "Average" de este ejemplo: no dice un número, dice "VARIABLE", seguido de la razón exacta. Esta es una decisión deliberada de esta lección, no una limitación de formato — cualquier número específico ahí ("842", "1250", cualquier cifra) habría sido, con precisión, exactamente el tipo de invención que esta guía se niega a hacer desde el Módulo 1: un número que suena preciso, sin ninguna medición real detrás.
Paso 5 — Calidad semántica: el mismo límite, la misma razón de fondo
La lección 5 de este módulo ya trazó la línea entre forma y significado; esta lección confirma que la razón por la cual la calidad semántica no se puede medir aquí es la misma razón exacta por la que la latencia no se puede medir: ambas dependen de una invocación real. Sin una respuesta real de Nova Lite ante un manifiesto de texto libre real, no hay nada contra lo cual comparar expectedFields —el campo que evals/fixtures/sample_manifests.json (Módulo 7, lección 6) ya declara, pero que el arnés de esa lección nunca lee—. La conexión con la lección anterior es directa:
evals/fixtures/sample_manifests.json (Modulo 7, leccion 6)
expectedFields -- lo que SERIA correcto (documentado,
para lectura humana)
representativeModelResponse -- lo que el arnes SI compara (forma,
ejecutado, esta leccion lo confirma)
Comparar ambos campo a campo = evaluacion semantica = requiere
una respuesta REAL de Bedrock, que esta guia nunca invocaLa tabla de honestidad completa de este módulo, ahora cerrada
| Pieza | Schema/estructura verificado | Número/dato real |
|---|---|---|
InvocationLatency/TimeToFirstToken (definición, unidades, fórmula OTPS) | Sí — citado textual de AWS Docs, hoy | No — ninguna invocación real ocurrió |
| Rango de latencia específico de Nova Lite | No existe publicado por AWS, confirmado por búsqueda directa | No |
expectedFields vs. representativeModelResponse (Módulo 7, lección 6) | Sí — el arnés compara forma, con código real | No — ninguna comparación semántica ocurre en esta guía |
Errores comunes
Buscar, en algún blog de terceros o comparativa no oficial, un número de latencia para Nova Lite y presentarlo como si fuera de esta lección (de completar, por cuenta propia, lo que esta lección deja sin número). Qué pasa: alguien, insatisfecho con "VARIABLE" como respuesta, busca en un sitio de benchmarking de terceros un número en milisegundos y lo cita como si fuera parte de esta guía. Cómo detectarlo: si tu nota de esta lección incluye una cifra de latencia con una fuente que no es docs.aws.amazon.com ni aws.amazon.com. Cómo corregirlo: cualquier número de un sitio de terceros mide condiciones que esta guía no puede verificar —qué proveedor, qué configuración de red, qué tamaño de prompt exacto usaron—; citarlo aquí, sin esa verificación, rompería la misma disciplina de fuentes que cada Recursos de esta guía ya exige. La honestidad correcta, si de verdad necesitas un número, es correr tu propia medición contra tu propia cuenta de Bedrock — el mismo consejo que el Módulo 3, lección 6 ya dio para apply.
Concluir que, porque no hay un número publicado, la latencia de Nova Lite es "mala" o "lenta" (de interpretar la ausencia de datos como una señal negativa). Qué pasa: alguien interpreta "AWS no publica un número específico para Nova Lite" como evidencia de que el modelo es lento. Cómo detectarlo: si tu conclusión de esta lección es "Nova Lite debe ser lento porque no está en la lista de latencia optimizada". Cómo corregirlo: la ausencia de un número publicado no es evidencia de nada sobre el desempeño real — significa, exclusivamente, que AWS no incluyó ese modelo específico en esa iniciativa de marketing particular, por razones que esta lección no puede conocer. GENAI-COST-PROFILE.md (Módulo 2, lección 8) ya fue explícito en que la elección de Nova Lite es "a judgment call, not a measurement" — la misma honestidad aplica aquí: ni bueno ni malo, simplemente no medido.
Presentar el diagrama del Paso 2 (prefill/decode) como si fuera evidencia de que se corrió una invocación real (de confundir explicar la mecánica con haberla medido). Qué pasa: alguien, entusiasmado con la precisión técnica de la fórmula InvocationLatency = TimeToFirstToken + (OutputTokenCount / OTPS) * 1000, la presenta como si viniera de datos propios. Cómo detectarlo: si tu descripción de esta lección dice "medimos que la latencia depende de..." en vez de "la documentación de AWS explica que...". Cómo corregirlo: la fórmula y la explicación de dos etapas son, con precisión, citas textuales de la documentación oficial de AWS —la misma disciplina de "schema verificado, contenido no verificado" que el Módulo 4, lección 7 ya aplicó a ApplyGuardrail—; explican por qué la latencia varía, sin que esta guía haya medido, en ningún momento, cuánto varía en la práctica.
Ejercicios
Ejercicio 1 — Usando la fórmula del Paso 2, calcula qué pasaría con InvocationLatency si TimeToFirstToken se mantiene fijo en 400ms, pero OutputTokenCount sube de 150 a 300 tokens (el doble), con un OTPS constante de 55 tokens/segundo (el valor de ejemplo que la documentación oficial de AWS usa). ¿Cuánto cambia InvocationLatency?
Ver solución
Con la fórmula InvocationLatency = TimeToFirstToken + (OutputTokenCount / OTPS) * 1000: con 150 tokens de salida, InvocationLatency = 400 + (150 / 55) * 1000 ≈ 400 + 2.727 = 3.127ms. Con 300 tokens de salida, InvocationLatency = 400 + (300 / 55) * 1000 ≈ 400 + 5.455 = 5.855ms. Duplicar la cantidad de tokens de salida no duplica exactamente InvocationLatency total (porque TimeToFirstToken se mantiene fijo, sin duplicarse), pero sí duplica, casi exactamente, la porción de decode — de 2.727ms a 5.455ms. Este ejercicio confirma en números concretos exactamente lo que el Paso 2 explicó en prosa: la duración de la respuesta —que depende de cuántos campos extrae y qué tan verboso es el modelo— es un factor directo en la latencia total, no un detalle menor.
Ejercicio 2 — Explica por qué esta lección elige citar la fórmula de OTPS de AWS en vez de simplemente decir "la latencia depende del tamaño del texto", sin la fórmula. ¿Qué gana esta lección al incluir la ecuación exacta?
Ver solución
Incluir la ecuación exacta convierte una afirmación cualitativa ("depende del tamaño") en una relación cuantitativa verificable — la misma disciplina de precisión que distingue a esta guía de una explicación superficial en cualquier otro punto. Con la fórmula, un lector puede, como el Ejercicio 1 acaba de demostrar, calcular por sí mismo cómo cambiaría la latencia ante un escenario hipotético específico, sin depender de la palabra de esta lección. Sin la fórmula, "depende del tamaño" es una afirmación que suena razonable pero que nadie puede verificar ni usar para razonar sobre un caso concreto — exactamente la diferencia entre citar el schema real de una API (como el Módulo 4, lección 7 ya hizo con ApplyGuardrail) y simplemente describir, de memoria, cómo "probablemente" funciona algo.
Ejercicio 3 — Predice qué pasaría con la fila de "Rango de latencia específico de Nova Lite" en la tabla de honestidad de esta lección si, dentro de seis meses, AWS agregara Nova Lite a su lista de modelos con latencia optimizada. ¿Bastaría con eso para que esta guía pudiera citar un número real?
Ver solución
No bastaría por completo, aunque sí cambiaría la situación de forma importante. Que AWS agregue Nova Lite a la lista de latencia optimizada confirmaría que la iniciativa existe para ese modelo —y probablemente vendría acompañada de alguna comparación cualitativa o cuantitativa en el anuncio correspondiente, como ya ocurrió para Claude 3.5 Haiku y Llama 3.1—. Pero un rango de milisegundos citado de un anuncio de marketing sigue siendo distinto de una medición propia, corrida contra la carga de trabajo específica de Andes Cargo, con sus propios tamaños de manifiesto reales. Esta guía citaría ese número nuevo, si existiera, con la misma etiqueta "representativo" que usa hoy para cualquier cifra no medida por ella misma —la actualización correcta sería agregar la cita, no eliminar la etiqueta—, hasta el día en que una invocación real, contra la cuenta de Andes Cargo, produjera un valor propio de InvocationLatency.
Resumen y siguiente paso
Esta lección documentó, con precisión y sin inventar ningún número, el límite final de este módulo: InvocationLatency/TimeToFirstToken son métricas reales, bien definidas, citadas textual de la documentación oficial de AWS, con una fórmula exacta (OTPS) que explica por qué la latencia nunca sería un número único ni siquiera con Bedrock corriendo de verdad. Confirmaste, con una búsqueda directa contra fuentes oficiales, que ni siquiera la iniciativa de latencia optimizada de AWS cubre a Nova Lite, el modelo elegido para Andes Cargo — un hallazgo honesto, no una limitación inventada. Y retomaste la línea de la lección 5: la calidad semántica no se puede medir aquí, por la misma razón exacta que la latencia no se puede medir — ambas dependen de una invocación real que esta guía nunca hace.
Antes de avanzar deberías poder: nombrar las métricas reales de latencia de Bedrock y su unidad; escribir de memoria la fórmula que relaciona InvocationLatency, TimeToFirstToken y OTPS; y explicar por qué ni siquiera un modelo con marketing de "latencia optimizada" garantizaría un número fijo para cualquier carga de trabajo específica.
La lección 8, el proyecto de cierre de este módulo, integra los tres SLI —el arnés de la lección 4 (literal), el de la lección 6 (calculable), y el límite exacto de esta lección (representativo)— en un solo panel documentado, con el mismo ledger de honestidad que cada proyecto de esta guía ya modeló.
Recursos
- AWS Docs — Monitor
bedrock-runtimeinference using CloudWatch metrics — fuente exacta deInvocationLatency/TimeToFirstToken, citada en los Pasos 1 y 4 de esta lección. - AWS Docs — Diagnose
InvocationLatencyincreases using output tokens per second (OTPS) — fuente de la fórmula prefill/decode del Paso 2. - AWS — Introducing latency-optimized inference for foundation models in Amazon Bedrock — fuente del hallazgo del Paso 3: Nova Lite no está en la lista de modelos soportados.
- AWS News Blog — Introducing Amazon Nova — fuente de la afirmación cualitativa sobre Nova Micro, citada en el Paso 3.
- Este mismo curso, Módulo 3, lección 6 y Módulo 4, lección 7 — el mismo patrón exacto de "intento honesto" que esta lección reaplica a latencia y calidad.
- Este mismo curso, Módulo 2, lección 8 —
GENAI-COST-PROFILE.md, la fuente de la elección de Nova Lite como "a judgment call, not a measurement", citada en esta lección.