OpenTelemetry GenAI Conventions: A Common Vocabulary for AI Observability

Conçu pour la vitesse : latence d'environ 10 ms, même en cas de charge
Une méthode incroyablement rapide pour créer, suivre et déployer vos modèles !
- Gère plus de 350 RPS sur un seul processeur virtuel, aucun réglage n'est nécessaire
- Prêt pour la production avec un support complet pour les entreprises
OpenTelemetry is giving GenAI systems a shared telemetry vocabulary, but it is not a finished universal schema. In June 2026, the project moved its GenAI, provider-specific, and MCP semantic conventions into a dedicated repository so they could iterate and version independently. That repository currently marks the GenAI conventions as Development, and as of August 21, 2026 it has no official release. The opportunity is still substantial: common names for model operations, token usage, agent steps, MCP calls, content events, and evaluation results can reduce translation work across instrumentation and observability backends. The engineering posture should be adoption with version awareness—not an assumption that gen_ai.* has already frozen.
Two teams can emit valid OpenTelemetry and still disagree about what an LLM call means. Transport interoperability and semantic interoperability are different problems. OTLP can move telemetry between systems; semantic conventions make the fields inside that telemetry more consistently interpretable. For GenAI, the second problem is still being actively standardized.
1. Why GenAI Needs More Than Generic APM
Generic APM remains useful for throughput, latency, errors, dependencies, and service health. GenAI adds semantics that those signals do not describe by themselves.
Probabilistic behavior. The same logical request can produce different outputs, so debugging often needs the requested and served model, generation settings, response identifiers, and—where policy permits—relevant input or output context. Full content is useful evidence, but it is not always appropriate or necessary to retain.
Token economics. Request counts still matter for load and rate limiting, but they are insufficient for spend and model-efficiency analysis. A small number of long-context calls can cost more than a large number of short ones. Current GenAI metrics include token usage and operation duration, along with time-to-first-chunk and time-per-output-chunk measures.
Agent structure. A model call is only one operation inside many agents. Planning, tool execution, retrieval, workflows, and MCP calls may determine the outcome. Observability therefore needs a vocabulary for the execution that surrounds inference, not only the provider API boundary.
Content sensitivity. Prompts and outputs frequently contain user or business data. OpenTelemetry can describe how to record that content, but whether to capture, retain, export, redact, or restrict it remains a data-governance decision.
2. What the Conventions Cover Now
The most useful way to read the current work is by signal and operation rather than by assuming one maturity ladder. The dedicated GenAI repository marks the overall conventions as Development.
Model and inference spans. Current conventions define GenAI client operations including inference, embeddings, retrievals, response fetching, memory operations, and tool execution. Common attributes include gen_ai.provider.name, gen_ai.operation.name, requested and response model identifiers, and input/output token usage. Span timing supplies operation duration; dedicated metrics standardize token usage and latency-related measurements.
Agent and framework spans. The agent conventions define operations such as create_agent, invoke_agent, invoke_workflow, plan, and execute_tool. These spans can make an instrumented execution path reconstructible. They do not expose a model's private reasoning, and they do not appear automatically unless the relevant framework or instrumentation emits them.
MCP conventions. MCP has its own Development conventions for client and server spans, W3C Trace Context propagation, transport correlation, tool-aware attributes, and metrics such as mcp.client.operation.duration and mcp.server.operation.duration. The value is continuity across the MCP boundary—not a promise that every MCP implementation already emits the conventions.
Metrics and provider-specific conventions. The repository defines client, server, workflow, agent, and tool metrics and adds provider-specific conventions for systems including OpenAI, Anthropic, Azure AI Inference, and AWS Bedrock.

3. Content Capture Is an Opt-In Policy Decision
The current event gen_ai.client.inference.operation.details can carry chat history, parameters, inputs, and outputs independently from the main trace. Its requirement level is explicitly Opt-In, and the OpenTelemetry documentation warns that event support is not yet available in every language.
That is a better default than treating prompts and completions as ordinary diagnostic text. OpenTelemetry defines the telemetry shape; it does not decide your retention period, regional storage, access policy, legal basis, or redaction requirements. Those remain operator and backend responsibilities.
For a production deployment, write the policy before turning content on: which environments may capture full content, what is filtered or truncated, where exported telemetry is allowed to go, how long it is retained, and who can retrieve it.
TrueFoundry AI Gateway offre une latence d'environ 3 à 4 ms, gère plus de 350 RPS sur 1 processeur virtuel, évolue horizontalement facilement et est prête pour la production, tandis que LiteLM souffre d'une latence élevée, peine à dépasser un RPS modéré, ne dispose pas d'une mise à l'échelle intégrée et convient parfaitement aux charges de travail légères ou aux prototypes.

















.webp)



.png)

.png)








