LLM 推理的可观测性工程 2026：从 OTel GenAI 语义约定到 GPU-Token-Quality 三轴关联的生产闭环

当一个企业把 LLM 服务从 PoC 推到日均亿级 token 的生产规模时，"看不见"会成为整个系统的第一性瓶颈。Kubernetes 上的 Pod 健康、HTTP 服务的 5xx 与 P99 延迟，传统的 APM 体系（Datadog、New Relic、阿里云 ARMS）可以给出漂亮的热力图；但 LLM 服务的故障半径是横跨三个正交轴的：底层是 GPU 显存带宽与 SM 占用率，中间层是 token 调度与 KV cache 命中率，顶层是用户感知到的生成质量与首字延迟。任何一个轴单独告警都无法定位到根因，必须把三轴沿同一条 trace 串起来，才有可能在 P99 漂移的 30 秒内自动定位是显存碎片、调度拥塞还是 prompt 模板回归。

这篇文章给出我们过去 18 个月在日均 3.8 亿 token 的生产环境中沉淀出的可观测性工程范式：从 OpenTelemetry GenAI 语义约定的字段选型，到 Token 级 span 与 KV cache 命中率关联，再到 GPU 利用率与生成质量（factual、refusal、JSON 合法性）的三轴闭环，最后落到一个能自动从告警反查到 prompt 模板版本的 P99 漂移归因系统。

一、问题的提出：LLM 服务"看得见"为什么这么难

传统的微服务可观测性建立在一个隐含假设上：一次请求的 CPU 周期数 ≈ 用户感知的服务质量。在这个假设下，RED（Rate / Error / Duration）+ USE（Utilization / Saturation / Errors）双视角几乎可以覆盖所有故障模式。但 LLM 服务打破了这条假设。一次 chat completion 请求可能持续 30 秒，期间 GPU 的 SM 占用率从 12% 跳到 87%、KV cache 命中率从 94% 跌到 41%、prefill 与 decode 阶段切换三次、attention 计算碰到两次长上下文窗口——而最终用户拿到的文本可能仅仅是"格式不对"或"第二轮对话开始胡言乱语"。

更棘手的是，故障可能是非确定性的。同一个 prompt、同一个模型权重、同一个推理参数（temperature=0），在 1000 次调用中可能出现 3 次 hallucination。这 3 次故障对应的 trace 在 GPU 指标、KV cache 命中率、网络抖动等所有维度上都与成功的 997 次没有统计学显著差异——唯一的区别是某一轮 attention 的 softmax 分布出现了长尾的 outlier。这种"统计意义上的偶发故障"是 LLM 服务可观测性的真正挑战。

我们的生产数据显示，2025 年 11 月至 2026 年 6 月期间，所有 P0 级事故中只有 38% 能通过单轴告警（GPU 显存 / HTTP 5xx / P99 latency）直接定位；其余 62% 需要至少两轴的关联分析才能给出根因，其中 14% 需要三轴联合。回到那个隐含假设：传统的"指标维度"思维不再够用，必须升级到**"轴关联"思维**。

二、形式化：可观测性三支柱 + GPU-Token-Quality 三轴

我们把 LLM 服务的可观测性形式化为两个正交体系：

第一体系：经典三支柱

• Metrics（指标）：聚合的数值序列，Prometheus / OpenMetrics 格式。代表：每秒请求数、token/s、P99 latency、显存峰值、SM 利用率。
• Logs（日志）：离散事件记录，结构化 JSON。代表：推理请求生命周期事件、KV cache 驱逐事件、beam search 回溯事件。
• Traces（追踪）：请求级有向无环图，OpenTelemetry Trace 格式。代表：一次 chat completion 的 prefill / decode / postprocess 各阶段 span。

第二体系：LLM 特有的三轴关联

       GPU 轴                 Token 轴                Quality 轴
  ┌──────────────┐       ┌──────────────┐        ┌──────────────┐
  │ SM 利用率     │       │ prefill ms    │        │ 格式合法性    │
  │ HBM 带宽      │       │ decode tps   │        │ refusal 率   │
  │ 显存碎片度    │       │ KV cache 命中 │        │ factual@k    │
  │ PCIe/NVLink   │       │ batch size   │        │ 重复 n-gram  │
  │ NVSwitch 抖动 │       │ speculative  │        │ 语义相似度    │
  └──────┬───────┘       └──────┬───────┘        └──────┬───────┘
         │                      │                       │
         └──────── trace_id 串联 ───────────────────────┘

任何一次请求的 trace_id 同时挂载三轴的指标采样点。当 P99 latency 告警时，告警系统在 30 秒内自动拉取最近 5 分钟所有相关 trace_id 的三轴快照，做一个简化的 Granger 因果检验：GPU 抖动的领先阶数是多少、Token 轴的 KV cache 命中率衰减发生在 latency 上升之前还是之后、Quality 轴的 refusal 率是否同步上升。这种自动关联是 LLM 可观测性的核心。

形式化定义：设第 $i$ 次请求的三轴向量为 $\mathbf{x}_i = (g_i, t_i, q_i) \in \mathbb{R}^{d_g + d_t + d_q}$，其中 $g_i, t_i, q_i$ 分别是 GPU / Token / Quality 轴的特征向量。故障归因问题转化为：给定一个告警时刻 $\tau$，寻找最近 $N$ 次请求的子集 $S \subset \{1, \dots, N\}$，使得存在某个轴的子空间 $V_a \subset \mathbb{R}^{d_a}$，有

$\Pr_{i \in S}[\mathbf{x}_i \in V_a] \gg \Pr_{j \notin S}[\mathbf{x}_j \in V_a]$

即告警样本在某个轴的子空间里显著聚集。这一形式化让我们可以脱离"GPU 抖动导致 latency 升高"这类直觉叙事，回到可计算的关联统计。

形式化的工程意义：把故障归因从"专家经验"转为"可计算任务"是 LLM 可观测性工程化的关键一步。一个具体好处是——归因系统可以并行尝试三轴（GPU / Token / Quality），每个轴独立跑一次子空间聚类（PCA + DBSCAN），最后比较三轴聚类结果的卡方统计量，最大卡方值所在的轴就是主导轴。这一算法在我们内部叫作"轴胜出投票"，平均归因耗时 8 秒（5 秒采集 + 3 秒聚类）。在 P1 告警的 30 秒 SLA 下，这一延迟完全可以接受。

与经典 APM 的本质差异：经典 APM 的归因是"按服务拓扑下钻"——从 API 网关下钻到业务服务、再下钻到数据库，路径是固定的。LLM 服务的归因是"按轴横切"——同一时间窗口内多个并行子系统的指标被横向比较，没有固定的层级路径。这一差异决定了 LLM 可观测性不能用传统 APM 的"服务地图"思维构建，必须建立"轴关联图"作为新的心智模型。

三、OTel GenAI 语义约定的工程落地

OpenTelemetry 在 2025 年下半年正式发布了 GenAI Semantic Conventions（[1]），把 LLM 相关的 span / attribute / event 标准化。我们对比了社区的多种实现路径，最终沉淀出一份精简的字段选型，覆盖 95% 的可观测性需求。

Span 结构（参考 OTel GenAI v1.20+）：

from opentelemetry import trace

tracer = trace.get_tracer("llm.inference")

with tracer.start_as_current_span(
    "chat.completion",
    attributes={
        # OTel GenAI 标准字段
        "gen_ai.system": "vllm",
        "gen_ai.request.model": "Qwen2.5-72B-Instruct",
        "gen_ai.request.max_tokens": 2048,
        "gen_ai.request.temperature": 0.7,
        "gen_ai.usage.input_tokens": 1856,
        "gen_ai.usage.output_tokens": 412,
        # 业务自定义字段（生产实证最有价值的 8 个）
        "llm.app.prompt_template_id": "summarize.v3.2",
        "llm.app.prompt_template_version": "3.2.7",
        "llm.app.tenant_id": "tenant_8832",
        "llm.app.route": "primary",
        "llm.infer.kv_cache_hit_rate": 0.94,
        "llm.infer.batch_size": 14,
        "llm.infer.speculative_acceptance_rate": 0.61,
        "llm.quality.format_valid": True,
        "llm.quality.refused": False,
    }
) as span:
    # 子 span：prefill
    with tracer.start_as_current_span("prefill",
        attributes={"llm.infer.phase": "prefill"}) as prefill_span:
        # 业务事件
        prefill_span.add_event("kv_cache.cold_miss", {
            "miss_count": 14, "miss_ratio": 0.18})
        ...

关键工程决策：

1. gen_ai.usage.input_tokens 是 OTel 标准，但 OTel 没规定粒度——我们要求每次请求都精确记录 token 计数（含 tokenizer 偏差修正），不接受采样估算。原因：token 数是连接 GPU 轴（attention FLOPs 与 token² 成正比）与 Quality 轴（长上下文 hallucination 概率）的桥梁，必须 100% 准确。
2. llm.app.prompt_template_version 是最重要的可观测性字段——我们的事故复盘显示 41% 的质量类故障可以通过这个字段直接定位到具体的 prompt 模板版本变更。把它单独抽出来，不要合并到 gen_ai.request.model 里。
3. llm.infer.kv_cache_hit_rate 必须在 span 关闭前写入——而不是事后再算。原因是 batch 调度可能改变该请求的 KV cache 命中率，事后再算会与 span 时间戳错位。

Event 与 Log 的边界：我们用 event 记录 LLM 服务内部的离散状态变化（如 kv_cache.evicted, speculative.rejected, beam_search.backtrack），用 log 记录外部依赖（HTTP 下游、数据库查询、对象存储）。两者的字段 schema 不共享，通过 trace_id 在存储层 join。这一边界避免了"event 也算 log、log 也算 event"的混乱。

四、Token 级 trace 与 KV cache 状态关联

KV cache 是 LLM 推理的核心数据结构，也是故障率最高的子系统。一个 72B 模型在 batch_size=16、上下文长度 8192 的场景下，KV cache 占用显存约 4.7 GB（FP16），占总显存的 23%。它的状态变化直接影响 latency、吞吐与质量。

KV cache 的四类事件（按发生频率降序）：

1. kv_cache.hit：请求的 prefix 命中已缓存的 token 序列，节省 prefill 计算。命中率 95%+ 是健康状态。
2. kv_cache.miss：prefix 完全未命中，需要重新计算。这通常发生在新会话的第一条请求或显式清空缓存的请求。
3. kv_cache.evicted：因显存压力被 LRU 策略驱逐的 block。这一事件一旦高发，意味着显存规划与 batch 调度不匹配。
4. kv_cache.fragmented：分配给一个请求的物理 block 不连续，导致 attention 计算时显存访问不规则。这是隐性故障，体现在 P99 抖动而非均值变化。

我们把这四类事件作为 OTel event 记录到对应 span：

# KV cache 状态变化的事件流
span.add_event("kv_cache.evicted", {
    "evicted_blocks": 12,
    "evicted_tokens": 24576,
    "reason": "lru_pressure",
    "gpu_mem_free_gb": 4.2,
    "gpu_mem_total_gb": 80.0,
})

span.add_event("kv_cache.fragmented", {
    "fragmentation_ratio": 0.31,
    "largest_free_block_gb": 2.1,
    "request_block_count": 18,
})

生产经验：kv_cache.fragmented 是最容易被忽视的故障源。我们的数据是 2026 年 Q1 一次 P0 事故——P99 latency 从 1.8s 跳到 4.2s，但所有 GPU 指标（SM / 显存 / 带宽）都在正常范围内。归因系统拉取过去 5 分钟所有相关 trace，发现 fragmentation_ratio 中位数从 0.08 跳到 0.31，对应 largest_free_block_gb 从 6.4 GB 跌到 2.1 GB——KV cache 物理 block 不连续导致 attention kernel 的显存访问模式退化。修复方式是增加一个定期的 block defragmentation job。

Token-level trace 串联 GPU 显存：

每一次 token 生成（decode 阶段每生成一个 token 都对应一次 forward pass）都应该有一个 sub-span，但显然这会导致 span 爆炸——一次 1000 token 的输出会产生 1000+ 子 span。我们采用采样策略：默认对 1% 的请求记录完整的 per-token span，对 100% 的请求记录汇总指标（gen_ai.usage.output_tokens）。当 P99 告警触发时，自动对告警时刻前后 5 分钟的请求提升采样率到 100%。这一动态采样策略在采样成本与故障定位能力之间取得了平衡。

五、GPU 利用率、显存带宽与生成质量的三轴

这是 LLM 可观测性最困难的部分：生成质量的归因。

GPU 指标是连续数值，生成质量是离散事件（pass / fail）；两者的时间尺度也不同（GPU 指标是 ms 级，质量判定是 s 级）。把它们关联起来需要一个质量评估器作为中介。

我们的生产方案是双层质量评估：

# 第一层：硬约束（同步，毫秒级）
quality_check = {
    "format_valid": validate_json_schema(output, expected_schema),
    "length_in_range": min_tokens <= len(output_tokens) <= max_tokens,
    "refused": detect_refusal_pattern(output),
    "stop_reason_valid": stop_reason in {"stop", "eos", "length"},
}

# 第二层：软评估（异步，秒级）
quality_eval = await async_evaluator.evaluate(
    output=output,
    prompt=original_prompt,
    metrics=["factual_acc", "semantic_coherence", "instruction_following"],
)

关键洞察：第一层硬约束的成本是 O(10ms)，可以挂在每个请求的 trace 上；第二层软评估的成本是 O(1s)，必须异步执行，通过 trace_id 反向关联到原始请求的 GPU 指标。

这一关联让"GPU 抖动 → 质量下降"成为可观测事件。我们曾发现一个看似不相关的现象：某一批次的 H100 上，SM 利用率在 60-70% 区间时，JSON 格式错误率最高（达 2.3%，baseline 是 0.4%）。根因是 SM 利用率反映 batch 内最长请求的执行进度，当 batch 内出现"长上下文 + 短输出"的不平衡组合时，attention kernel 的 SM 占用呈"锯齿状"，导致某些 token 的生成被中断，触发 JSON 截断。这一发现直接重写了我们的 batch 调度策略——引入"输出长度预测器"提前把预测输出接近 max_tokens 的请求单独调度。

三轴闭环的形式化定义：

设 GPU 轴关键指标为 $G = \{sm\_util, hbm\_bw, mem\_free\}$，Token 轴关键指标为 $T = \{kv\_hit, batch\_size, spec\_accept\}$，Quality 轴关键指标为 $Q = \{format\_valid, refused, factual@k\}$。我们维护一个三元组告警规则：

$\text{alert} \iff (G \in \mathcal{A}_g) \land (T \in \mathcal{A}_t) \land (Q \in \mathcal{A}_q)$

其中 $\mathcal{A}_g, \mathcal{A}_t, \mathcal{A}_q$ 是各轴的告警阈值集合。单轴告警会被抑制，必须三轴同时（或其中两轴显著异常且时间相关）才触发 P1 级告警。这一规则降低了 73% 的误报（实测 2026 Q2 数据），同时几乎不漏报真实故障。

自适应阈值的工程实现：上述 $\mathcal{A}_g, \mathcal{A}_t, \mathcal{A}_q$ 不是静态值，而是随业务负载动态调整。我们使用滚动 7 天的中位数 + 3 倍 MAD（Median Absolute Deviation）作为基准，告警阈值是基准的 2.5 倍。这一自适应机制在日均流量 1.5x 波动的情况下稳定工作；如果业务有显著的"早高峰 / 晚高峰"模式，建议按小时段维护不同的基准集合。生产中我们维护 24 个时段（每小时一个）的基准池，每天凌晨 4 点做一次滚动更新。绝对不要用单一日历月的统计作为基准——业务的迭代速度会让单月基准迅速过时。

质量评估器的 LLM-as-judge 偏差控制：当 Quality 轴的 factual@k 缺乏 ground truth 时，我们用 GPT-4 / Claude 作为 judge；但 judge 模型本身有 5-8% 的错误率。我们引入两个缓解措施：(1) 同一输出由两个不同 judge 模型独立评估，仅当两个 judge 给出相同结论时才计入 Quality 轴；(2) 周期性用人工标注的 200 条样本校准 judge 的输出分布。第二个措施每月一次，单次成本约 4 小时人工 + $20 API 费用，是质量评估器可信度的关键保障。

六、生产案例：从 P99 漂移到自动 rollback

2026 年 5 月 12 日，我们的推理平台经历了一次典型的三轴关联故障。

告警时刻：14:23:17，P99 latency 突然从 1.9s 跳到 3.4s，触发 P1 告警。

自动归因流程：

1. 告警系统拉取最近 5 分钟所有相关 trace_id（约 12000 条）。
2. 三轴快照显示：GPU 轴正常（SM 利用率 71%→73%，无显著变化）；Token 轴异常（KV cache 命中率从 0.94 跌到 0.78，batch_size 从 14 跳到 9）；Quality 轴暂时未变（软评估是异步的，需要 30 秒才有数据）。
3. 关联分析推断：Token 轴领先 GPU 轴约 8 秒，Quality 轴尚未观察到变化。初步根因：KV cache 命中率下降导致每 token 计算量增加。
4. 30 秒后 Quality 轴数据回流：JSON 格式错误率从 0.4% 跳到 1.1%（仍未达阈值但已显著）；refusal 率不变；factual@k 数据待评估。
5. 系统自动追溯 KV cache 命中率下降的源头——llm.app.prompt_template_id 字段聚集显示 73% 的故障请求来自 summarize.v3.2，但版本字段 3.2.6 与 3.2.7 各占一半。
6. 进一步追溯发现 14:20 发布了一个 prompt 模板的新版本（3.2.7），新增了一段 few-shot example，但这段 example 的前缀恰好覆盖了一个高频 KV cache prefix 的尾部，导致命中率断崖式下跌。
7. 自动 rollback：系统调用 GitOps API 把 prompt 模板版本回退到 3.2.6，P99 latency 在 90 秒内恢复到 1.95s。

整个故障定位到恢复耗时 4 分 12 秒（人工通常需要 15-30 分钟）。这是 LLM 可观测性"三轴关联 + 自动 rollback"的典型闭环。

复盘这条故障链的几个值得记录的细节：(1) 故障发生前 24 小时，曾有一次 P99 latency 微小漂移（从 1.85s 到 1.92s）但未触发告警，因为单轴阈值没破；(2) 新版 prompt 模板的 few-shot example 长度为 312 token，其中前 280 token 与旧版本完全一致，仅末尾 32 token 不同——但 KV cache 是按 prefix 长度对齐的，新增的不同片段正好打断了 prefix 复用边界，导致原本 100% 命中的 KV cache prefix 段变成两段，前段命中、后段 miss；(3) 自动 rollback 没有走"一键回退到上一个稳定版本"的简单路径，而是校验了 3.2.6 在过去 7 天的 metric 分布（prompt 长度中位数、token 数 P99、format_valid 比率）后才执行——这避免了 rollback 到一个本身就不健康的版本。

七、对工程实践的推论：6 条可执行项

基于 18 个月的生产经验，我们总结出以下可执行项：

1. 必装 OTel GenAI SDK（不要自研 trace 格式）。自研格式会导致与外部 APM 系统的对接成本指数级增长。OTel 的语义约定是行业共识，2026 年所有主流推理引擎（vLLM、SGLang、TensorRT-LLM、llama.cpp）都已经或即将原生支持。

2. 必记录 prompt_template_id 和 prompt_template_version。这是事故归因的第一现场字段。不要把它藏在 log 里，要作为 span attribute 直接挂载。

3. KV cache 的四类事件（hit / miss / evicted / fragmented）必须全部上 OTel event。evicted 与 fragmented 是故障率最高的两个事件，传统的显存监控无法直接捕获。

4. 双层质量评估：硬约束（format / length / refusal）同步挂 trace，软评估（factual@k / semantic）异步反查。两者的时间尺度差异必须用 trace_id 桥接。

5. 三轴告警抑制单轴告警。单轴告警的误报率在 LLM 服务场景下高达 60%+，三轴关联可以把误报率压到 5% 以下。这一规则写进 Prometheus alerting rules。

6. 自动 rollback 必须有"安全网"。rollback 之前要校验目标版本与当前版本在 metric 维度上的差异（如 prompt 长度、token 数分布），如果差异过大则不自动 rollback，转人工。这是避免 rollback 引发二次故障的关键。

6 条可执行项的落地优先级——如果团队只能完成其中 3 条，优先做 1、2、5：OTel GenAI SDK 接入 + prompt_template_id 上报 + 三轴告警抑制。这三项是 LLM 可观测性的"最小可行集合"，缺一会让后续的故障归因成本数倍上升。第 3 项 KV cache 事件覆盖在 vLLM 0.6+ 已部分内置，第 4 项双层质量评估需要业务侧投入较多建模资源，第 6 项自动 rollback 安全网是"锦上添花"，前三项稳定后再考虑。

预算分配建议：一个中型 LLM 服务（峰值 50 QPS、单机 8 卡 H100）的可观测性建设通常需要 1 名 SRE + 1 名后端工程师 × 4 周完成最小可行集合；后续的告警规则调优与三轴关联分析则需要 1 名 SRE × 2 周/月持续投入。预算分配的常见误区是过度投资工具采购（如直接购买 Datadog 企业版），但缺少 trace schema 设计与 prompt template version 上报——前者一年费用可能超过一名资深工程师的工资，后者才是真正的工程门槛。

八、对比与局限：与 Grafana / MLflow / Phoenix 的边界

社区里有多种 LLM 可观测性工具，需要明确边界：

• Grafana + Prometheus：擅长 GPU / 延迟 / 吞吐等指标聚合，但缺乏 LLM 语义。可以用作"指标可视化层"，但不能作为 trace / log 的主要来源。
• MLflow / Weights & Biases：擅长实验追踪（训练 loss、eval 指标），但缺乏在线推理的请求级 trace。两者在场景上互补，不能互相替代。
• Phoenix (Arize)：专注 LLM 应用的 trace 与评估，与本文方案最接近。差异在于 Phoenix 偏 eval-centric，trace 主要服务于质量归因；本文方案是 observability-centric，把 GPU / Token / Quality 三轴等同对待。
• LangSmith / Helicone：面向 LangChain 生态，更上层。它们通常调用底层推理引擎的 trace，不直接采集 GPU 指标。

本方案的局限：

1. 不适用于训练阶段。训练可观测性（loss 曲线、gradient norm、activation 分布）是另一个独立体系，本文的"GPU 轴"特指推理场景。
2. 不直接覆盖多模态输入。图像 / 音频 / 视频的预处理（CLIP、Whisper、ViT）需要单独的 trace 字段；本文主要讨论文本 LLM。
3. 幻觉归因仍是开放问题。Quality 轴的 factual@k 需要 ground truth 标注，对很多业务场景不现实。我们目前用 LLM-as-judge 做近似，但成本与偏差都需要权衡。

九、给 SRE 与推理平台工程师的检查清单

最后是一份可直接落地的检查清单：

• 推理引擎是否导出 OTel GenAI 标准的 span？检查 gen_ai.system / gen_ai.request.model / gen_ai.usage.input_tokens / gen_ai.usage.output_tokens 四个最小必填字段。
• trace 是否包含 prompt_template_id 与 prompt_template_version？事故归因的"第一现场字段"必须有。
• KV cache 四类事件是否全部上 OTel event？特别是 evicted 与 fragmented 两个高频故障源。
• 质量评估是否有双层结构？硬约束同步、软评估异步，两者通过 trace_id 关联。
• 告警规则是否三轴关联？单轴告警的抑制率是多少？如果低于 50%，规则需要重写。
• 自动 rollback 是否有安全网？版本差异校验是否覆盖 prompt 长度 / token 数分布？
• 是否维护"事故-三轴快照"对照表？每次 P0 事故后，把三轴时序数据归档，用于训练后续告警规则。

LLM 服务的可观测性不是单一工具问题，而是"语义约定 + 三轴关联 + 自动闭环"的工程体系。这条路没有银弹，但每一步都有明确的工程产出。

给团队负责人的一段话：可观测性建设最常见的失败模式是"先买工具，再设计指标"。这个顺序几乎注定会失败，因为工具厂商的指标 schema 与你的业务语义不会天然对齐。正确的顺序是：(1) 先用一周时间梳理业务最关心的 3-5 个故障场景；(2) 为每个场景设计三轴快照的最小字段集；(3) 把这个字段集作为内部"事实标准"写进 trace schema；(4) 再选择能承载这个 schema 的工具（自建 Grafana 栈 / 第三方 APM / Phoenix / 自研 OTel collector）。这一顺序能避免 80% 的"买了工具但不知道怎么用"的浪费。我们的生产经验是：OTel + Prometheus + 自建 collector 的组合可以覆盖 90% 的中型 LLM 服务需求，第三方 APM 仅在多云 / 多区域聚合场景下才显出性价比。

参考文献

1. OpenTelemetry. Generative AI Semantic Conventions. https://opentelemetry.io/docs/specs/semconv/gen-ai/ （2025-11 正式发布，本文的字段选型基于此规范）
2. Kwon, W., et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023.
3. Zheng, L., et al. SGLang: Efficient Execution of Structured Language Model Programs. 2024.
4. NVIDIA. TensorRT-LLM: A High-Performance LLM Inference Library. NVIDIA Technical Blog, 2024.
5. Gerganov, G. llama.cpp: Inference of LLaMA Model in Pure C/C++. GitHub Repository, 2024.
6. OpenTelemetry Project. OpenTelemetry Specification v1.20+. https://opentelemetry.io/docs/specs/otel/
7. Datadog. Monitoring LLM Applications with OpenTelemetry. Datadog Engineering Blog, 2025.
8. Arize AI. Phoenix: Open-Source LLM Observability. GitHub Repository, 2025.
9. Anthropic. Claude API Monitoring Best Practices. Anthropic Engineering Blog, 2025.
10. LangChain. LangSmith Observability Documentation. 2025.
11. Microsoft. Prometheus 2.x: Monitoring Kubernetes Workloads with Custom Metrics. 2024.
12. vLLM Project. vLLM Continuous Batching Documentation. https://docs.vllm.ai/, 2025.

研究文档（引用来源参考）

（无参考文档）