土法炼钢兴趣小组的算法知识备份

【大模型基础设施工程】23：LLM 可观测性

2026-04-22 · architecture · ai-infra · #llm #infra #observability #langsmith #langfuse #helicone #openllmetry #opentelemetry #ragas #phoenix #gpu-metrics #llm-eval

文章导航

分类入口
architectureai-infra
标签入口
#llm#infra#observability#langsmith#langfuse#helicone#openllmetry#opentelemetry#ragas#phoenix#gpu-metrics#llm-eval

目录

可观测性（Observability）在传统微服务里已经是老生常谈：Metrics、Logs、Traces 三件套，加一点 Profiling 就能覆盖 90% 的排障场景。但把这套方法论直接搬到大模型系统上，会发现它远远不够：

本篇把 LLM 可观测性拆成四层：基础设施层（GPU / 推理引擎）、调用层（LLM / RAG / Agent trace）、质量层（Eval / 幻觉 / 用户反馈）、业务层（成本 / A/B / 合规），并串联主流工具栈：Langfuse、LangSmith、Helicone、Arize Phoenix、W&B Weave、OpenLLMetry、AgentOps、Pezzo、Lunary，以及 OpenTelemetry GenAI Semantic Conventions（2025 稳定版）。

贯穿全文的一个观点：可观测性不是把监控仪表盘做多花哨，而是”出问题时能 5 分钟定位、3 小时修复，下次不再出现”。围绕这个目标，本文既会讲指标口径和工具选型，也会给出告警阈值、故事复盘、平台化落地路径。

前置阅读：21-推理服务化、22-大模型网关。

一、为什么 LLM 需要一套新的可观测性

1.1 与传统微服务的差异

把一个在线 LLM 产品和一个传统 CRUD 微服务放一起对比：

维度 传统微服务 LLM 服务
计费单位 请求数 / CPU 秒 input / output / cached token，按模型不同价
延迟语义 单一 latency（p50/p99） TTFT（流式首包）+ TPOT（每 token）+ E2E
正确性 状态码 200 即可 200 不代表正确，可能幻觉、跑题、拒答
调用拓扑 固定 RPC 调用链 动态 Agent 循环，轮次、分支、工具不确定
数据敏感 用户 ID / 订单号 完整 Prompt / Completion 可能含 PII、业务秘密
重放 SQL 重跑 需要完整 Prompt + 模型版本 + 温度 + 种子
资源瓶颈 CPU / DB 连接 GPU SM 利用、HBM、KV cache、网络带宽
回归 单测 + 集成测试 数据集 + LLM-as-Judge + 人工标注

这张表说明：LLM 系统需要新的信号、新的存储、新的评估闭环。

1.2 四层观测模型

flowchart TB
  subgraph BIZ[业务层]
    Cost[成本/按用户&feature]
    AB[A/B 实验]
    Compliance[合规/留存/脱敏]
  end
  subgraph QUAL[质量层]
    Eval[在线评估]
    Halluc[幻觉/Groundedness]
    Feedback[用户反馈 👍/👎]
  end
  subgraph CALL[调用层]
    Trace[Trace: LLM/Tool/Retriever]
    Prompt[Prompt 版本]
    TTFT[TTFT/TPOT/E2E]
  end
  subgraph INFRA[基础设施层]
    GPU[GPU DCGM]
    Engine[vLLM/SGLang metrics]
    KV[KV cache / Prefix hit]
  end
  INFRA --> CALL --> QUAL --> BIZ

本文按自下而上顺序展开。

二、核心指标体系

2.1 延迟：TTFT / TPOT / E2E

流式输出是 LLM 的默认交互形态，单一 latency 已不够用：

线上告警的门槛参考（以 13B/32B 模型为例）：

TTFT p95  < 500 ms       (对话式)
TTFT p95  < 2  s         (长文档/Agent)
TPOT p95  < 50 ms        (>= 20 tokens/s)
Queue p99 < 1  s

2.2 吞吐：tokens / req / GPU

2.3 GPU 与引擎内部信号

2.4 Token 成本：input / output / cached

现代 API 的计价是三档：

类型 相对价格 典型应用
Input (uncached) 1x 新 prompt
Cached input 0.1x ~ 0.5x 系统提示、长文档重用（OpenAI / DeepSeek / Anthropic 均支持）
Output 3x ~ 5x 生成 token

因此观测侧要分别记录：

usage = {
    "prompt_tokens": 1234,
    "prompt_tokens_details": {"cached_tokens": 1000},
    "completion_tokens": 456,
    "completion_tokens_details": {"reasoning_tokens": 200},  # o1/R1 系列
}

缓存命中率 = cached_tokens / prompt_tokens。一个成熟 RAG 系统应该稳定在 50%+。

2.5 质量：不再是 200 就算对

三、Trace 模型与标准

3.1 为什么需要 Trace

一个 Agent 请求的真实调用：

sequenceDiagram
  participant U as User
  participant A as Agent
  participant R as Retriever
  participant E as Embed
  participant L as LLM(Planner)
  participant T as Tool(SQL)
  participant L2 as LLM(Summarizer)
  U->>A: "上季度华东区销售?"
  A->>E: embed(query)
  A->>R: search(vec, k=8)
  A->>L: plan(context)
  L-->>A: call_tool(sql, "...")
  A->>T: run_sql
  T-->>A: rows
  A->>L2: summarize(rows, context)
  L2-->>A: answer + citations
  A-->>U: stream

任何一环变慢或出错，都需要 trace 才能定位。

3.2 OpenTelemetry GenAI Semantic Conventions

OpenTelemetry 在 2024 底到 2025 陆续把 gen_ai.* 语义约定从 experimental 推向 stable。关键字段（节选）：

span.kind                    = CLIENT
span.name                    = "chat gpt-4o-mini"
gen_ai.system                = "openai" | "anthropic" | "deepseek" | ...
gen_ai.operation.name        = "chat" | "text_completion" | "embeddings"
gen_ai.request.model         = "gpt-4o-mini"
gen_ai.response.model        = "gpt-4o-mini-2024-07-18"
gen_ai.request.temperature   = 0.2
gen_ai.request.max_tokens    = 2048
gen_ai.usage.input_tokens    = 1234
gen_ai.usage.output_tokens   = 456
gen_ai.response.finish_reasons = ["stop"]
gen_ai.conversation.id       = "conv_..."

工具调用、Agent 场景的扩展：

gen_ai.tool.name        = "search_sql"
gen_ai.tool.call.id     = "call_abc123"
gen_ai.agent.id / name
gen_ai.server.request.duration (histogram)
gen_ai.client.token.usage (histogram)

原则：默认不把 prompt / completion 塞进 attribute（PII），而用 Events（log-record like）承载；由 OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT 环境变量控制是否采集内容。

3.3 OpenInference（Arize）与 OpenLLMetry（Traceloop）

两套早于 OTel 稳定版诞生的”事实标准”：

2025 年的实际姿势：后端接收 OTel，SDK 任选。Langfuse、Phoenix、SigNoz、Jaeger、Tempo、Dynatrace 都开始原生理解 gen_ai.*。

3.4 Span 层次模板

推荐的 span 分层：

Trace: "user chat #U123"
└─ Span: agent.run                           (AGENT)
   ├─ Span: retriever.search                 (RETRIEVER)
   │  └─ Span: embedding.encode              (EMBEDDING)
   ├─ Span: reranker.rerank                  (RERANKER)
   ├─ Span: llm.plan (gpt-4o-mini)           (LLM)
   ├─ Span: tool.sql_query                   (TOOL)
   ├─ Span: tool.http_fetch                  (TOOL)
   └─ Span: llm.summarize (claude-3-5)       (LLM)

每个 LLM span 都应带：model、params、usage、cost、TTFT、TPOT、finish_reason、messages（可脱敏）。

四、主流工具栈横评

4.1 LangSmith（LangChain 官方）

4.2 Langfuse（开源 self-host 首选）

4.3 Helicone

4.4 Arize Phoenix

4.5 Weights & Biases Weave

4.6 OpenLLMetry / Traceloop

4.7 AgentOps

4.8 Pezzo / Lunary

4.9 选型决策树

flowchart TD
  A[我要观测什么?] --> B{数据能出境?}
  B -- 能 --> C[LangSmith / Helicone / Lunary]
  B -- 不能 --> D[Langfuse / Phoenix self-host]
  A --> E{已有 OTel/APM?}
  E -- 是 --> F[OpenLLMetry 发到现有后端]
  E -- 否 --> D
  A --> G{重点是 Agent?}
  G -- 是 --> H[AgentOps + Langfuse]
  A --> I{重 Prompt 版本?}
  I -- 是 --> J[Pezzo / Langfuse / LangSmith]

五、Prompt / Output 存储与脱敏

5.1 敏感数据问题

Prompt 里可能出现：

直接 full-trace 到 SaaS 就是合规事故。

5.2 脱敏策略

  1. 客户端脱敏：SDK 在发送前用正则 / NER 替换 PII 为 <PHONE>、<ID_CARD>；原文仅本地保留。
  2. 网关脱敏：在 LLM 网关 统一处理，观测后端只看到脱敏后的流。
  3. 字段级加密：prompt / completion 用 KMS 加密存储，查询时按角色解密。
  4. 采样：只存 1% 原文 + 100% 结构化（usage、latency、tags）。
  5. TTL：按法规设置（见 §12）。

Langfuse 的 mask 钩子示例：

from langfuse import Langfuse

def mask(data):
    import re
    if isinstance(data, str):
        data = re.sub(r"1[3-9]\d{9}", "<PHONE>", data)
        data = re.sub(r"\d{17}[\dxX]", "<ID>", data)
    return data

langfuse = Langfuse(mask=mask)

六、评估闭环

6.1 在线 vs 离线

flowchart LR
  Prod[线上流量] -->|采样 1%| Sampler
  Sampler --> OnlineEval[在线 LLM-as-Judge]
  OnlineEval --> Dash[仪表盘 / 告警]
  Prod -->|badcase| Queue[标注队列]
  Queue --> Dataset[回归数据集]
  Dataset --> CI[离线 Eval / CI]
  CI --> Promote[Prompt/模型发布闸门]

6.2 在线评估：LLM-as-Judge

对采样请求跑一个”裁判模型”，常见维度：

Langfuse 自带 Evaluator，也可以自己写：

judge_prompt = """
你是严格的评审。请根据 [Context] 判断 [Answer] 是否完全由 [Context] 支持。
只输出 0.0-1.0 分数和一行理由。
[Context]
{context}
[Answer]
{answer}
"""

注意：裁判模型必须比生产模型更强或至少同级，否则存在 judge 偏见；并且要定期和人工标注对齐。

常见坑：

6.3 离线评估框架

promptfoo 片段：

providers:
  - openai:gpt-4o-mini
  - deepseek:deepseek-chat
  - anthropic:claude-3-5-sonnet
prompts:
  - file://prompts/summarize_v1.txt
  - file://prompts/summarize_v2.txt
tests:
  - vars: {doc: file://data/d1.md}
    assert:
      - type: llm-rubric
        value: 必须包含结论与证据链
      - type: cost
        threshold: 0.01
      - type: latency
        threshold: 3000

6.4 数据集治理

七、幻觉与事实核查

7.1 Groundedness 分数

核心公式：

groundedness = (answer 中被 context 支持的 claims) / (answer 中总 claims)

实现：让 judge LLM 把 answer 拆成原子 claims，再逐条判 entail / contradict / neutral。

7.2 引用对齐

7.3 多样性与拒答

7.4 幻觉的三种典型形态

工程上建议把”幻觉”细分，不同形态处置不同：

  1. 事实型幻觉：捏造人物、日期、数字。→ Groundedness + 外部知识核查。
  2. 引用型幻觉：引了存在的文档但原文不支持结论。→ claim 级 entailment 检查。
  3. 指令幻觉：不按用户要求的格式 / 约束输出。→ 结构化输出（JSON Schema、function call）+ 校验重试。

不同形态的观测指标、告警阈值和修复手段都不一样，把它们混在一个”hallucination rate”里会误导方向。

八、A/B 实验

8.1 分流维度

通常在 LLM 网关 或观测 SDK 里按 user_id hash 稳定分桶。

8.2 在线指标

Langfuse / LangSmith 都支持 experiment_id + variant 打标，然后在面板里对比。

8.3 显著性

LLM A/B 样本量往往不如传统互联网大，要警惕：

九、成本观测

9.1 多维度计费

每条 trace 至少打上：

user_id, tenant_id, feature, model, region, experiment_variant

在 Langfuse 里直接 group by；或把 usage 导出到 ClickHouse / BigQuery 自己切。

9.2 缓存命中分析

仪表盘必看：

三者独立，都能省钱；目标：总 input cost 下降 30–60%。

9.3 异常花费告警

alert: CostSpike
expr:  sum(rate(llm_cost_usd[5m])) by (feature)
       > 3 * avg_over_time(sum(rate(llm_cost_usd[5m])) by (feature)[1h:5m])
for: 10m

并加速率限（见 22-llm-gateway）——观测发现、网关止损，是标配组合。

十、GPU 与推理引擎观测

10.1 DCGM Exporter

NVIDIA 官方 Prometheus exporter，部署一个 DaemonSet 即可采全节点 GPU 指标：

apiVersion: apps/v1
kind: DaemonSet
metadata: { name: dcgm-exporter, namespace: monitoring }
spec:
  template:
    spec:
      containers:
      - name: dcgm-exporter
        image: nvcr.io/nvidia/k8s/dcgm-exporter:3.3.5-3.4.1-ubuntu22.04
        ports: [{ containerPort: 9400, name: metrics }]
        securityContext: { capabilities: { add: ["SYS_ADMIN"] } }

关键指标：

DCGM_FI_PROF_SM_ACTIVE              # SM 实际活跃比例（真利用率）
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE     # Tensor Core 利用
DCGM_FI_DEV_FB_USED / FB_FREE       # HBM
DCGM_FI_DEV_POWER_USAGE             # 功耗
DCGM_FI_PROF_NVLINK_TX/RX_BYTES     # NVLink 流量
DCGM_FI_DEV_ECC_DBE_VOL_TOTAL       # 双比特 ECC（故障预警)

10.2 vLLM / SGLang 指标

vLLM 在 /metrics 暴露 Prometheus：

vllm:num_requests_running
vllm:num_requests_waiting
vllm:gpu_cache_usage_perc
vllm:time_to_first_token_seconds (histogram)
vllm:time_per_output_token_seconds (histogram)
vllm:e2e_request_latency_seconds
vllm:prompt_tokens_total
vllm:generation_tokens_total
vllm:prefix_cache_hit_rate

SGLang 类似，另提供 RadixAttention 命中：

sglang:cache_hit_rate
sglang:running_requests
sglang:token_usage
sglang:schedule_overhead

10.3 Grafana 面板模板

一个推理集群的”四行一屏”：

  1. 流量行：RPS / tokens-in / tokens-out / 队列深度；
  2. 延迟行：TTFT p50/p95/p99、TPOT p50/p95、E2E；
  3. 资源行：SM active、HBM used、KV cache %、prefix hit %；
  4. 成本行：$/1k tokens、按 model/tenant 分桶。

社区模板：DCGM 官方 dashboard + vLLM 官方 dashboard（GitHub vllm-project/vllm 的 examples/production_monitoring）。

10.4 深度性能剖析：Nsight

指标发现异常后，需要剖析：

组合拳：Prometheus 告警 → nsys 抓一段 → ncu 钻到 kernel。

十一、Agent 观测

11.1 特有信号

11.2 死循环检测

def loop_detector(history, window=4):
    sig = [(a.tool, hash(str(a.args))) for a in history[-window*2:]]
    half = len(sig)//2
    return sig[:half] == sig[half:]  # 后半和前半完全相同 -> 疑似环

检测到立刻打断并记 agent.loop_detected=true。

11.3 Replay

Trace 必须包含：每一步的 input / output / tool args / tool result / model / params / seed。AgentOps、LangSmith、Langfuse 都有 replay：点一个失败 session，加载到 playground 里按原样重跑或改一步重跑，定位问题比 printf 高效十倍。

11.4 多 Agent 拓扑

CrewAI、AutoGen、LangGraph 这类多 Agent 框架下，观测要能展示：

LangGraph 的 state machine 天然适合 trace 成一棵树，Langfuse 的 session 视图能覆盖；复杂场景下 AgentOps + 自定义 dashboard 更清晰。

十二、日志合规

12.1 法规一览

12.2 工程落地要点

  1. 日志分级：结构化指标永久留、完整 prompt / completion 按法规 TTL（中国公众服务建议 ≥ 6 个月，企业内部按行业判断）。
  2. 数据分区：按区域部署观测后端（中国数据留中国）。
  3. 审计日志：谁在什么时候访问了哪个 trace，自身要审计。
  4. “可遗忘”：提供按 user_id 级联删除能力——Langfuse、LangSmith 都有相应 API。
  5. 安全审核记录：拒答、命中黑名单的请求单独入审计库，便于备案自检。

十三、代码实战

13.1 Langfuse self-host + OpenAI SDK

# 1. 起 self-host（生产建议 k8s helm）
git clone https://github.com/langfuse/langfuse && cd langfuse
docker compose up -d

# 2. 登录 http://localhost:3000 拿 PK / SK
export LANGFUSE_PUBLIC_KEY=pk-...
export LANGFUSE_SECRET_KEY=sk-...
export LANGFUSE_HOST=http://localhost:3000

最小侵入集成（drop-in）：

from langfuse.openai import openai  # 只改这一行
from langfuse.decorators import observe

@observe()
def answer(q: str, user_id: str):
    docs = retrieve(q)
    resp = openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "你是客服，请基于 context 回答。"},
            {"role": "user", "content": f"context:\n{docs}\n\n问:{q}"},
        ],
        metadata={"user_id": user_id, "feature": "cs_chat", "variant": "v2"},
    )
    return resp.choices[0].message.content

@observe()
def retrieve(q):
    # 这里会自动成为 answer 的子 span
    return vectorstore.search(q, k=5)

附带用户反馈回写：

from langfuse import Langfuse
lf = Langfuse()
lf.score(trace_id=trace_id, name="thumb", value=1, comment="有帮助")

13.2 OpenTelemetry instrument vLLM

vLLM 0.6+ 自带 OTel 支持（--otlp-traces-endpoint）；也可以用 OpenLLMetry 在客户端侧一把梭。

服务端：

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen3-32B-Instruct \
  --enable-prefix-caching \
  --otlp-traces-endpoint http://otel-collector:4317 \
  --collect-detailed-traces model,worker

客户端（OpenLLMetry 自动 instrument）：

from traceloop.sdk import Traceloop
from openai import OpenAI

Traceloop.init(
    app_name="my-llm-app",
    api_endpoint="http://otel-collector:4318",  # OTLP HTTP
    disable_batch=False,
)

client = OpenAI(base_url="http://vllm:8000/v1", api_key="none")
resp = client.chat.completions.create(
    model="qwen3-32b",
    messages=[{"role":"user","content":"写一段 quicksort"}],
    stream=True,
)
for chunk in resp:
    ...

OTel Collector 把 gen_ai.* trace 同时吐到：

Collector 片段：

receivers:
  otlp: { protocols: { grpc: {}, http: {} } }
processors:
  batch: {}
  filter/pii:
    traces:
      span:
        - 'attributes["gen_ai.prompt.0.content"] != nil'
  transform/mask:
    trace_statements:
      - context: span
        statements:
          - replace_pattern(attributes["gen_ai.prompt.0.content"],
              "1[3-9][0-9]{9}", "<PHONE>")
exporters:
  otlphttp/langfuse:
    endpoint: http://langfuse:3000/api/public/otel
    headers: { Authorization: "Basic ${LANGFUSE_AUTH}" }
  otlp/tempo:
    endpoint: tempo:4317
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [transform/mask, batch]
      exporters: [otlphttp/langfuse, otlp/tempo]

13.3 Prometheus 抓 vLLM + DCGM

scrape_configs:
  - job_name: vllm
    static_configs: [{ targets: ["vllm-0:8000","vllm-1:8000"] }]
    metrics_path: /metrics
  - job_name: dcgm
    kubernetes_sd_configs: [{ role: pod }]
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        regex: dcgm-exporter
        action: keep

告警示例：

groups:
- name: llm
  rules:
  - alert: HighTTFT
    expr: histogram_quantile(0.95,
           sum by (le,model) (rate(vllm:time_to_first_token_seconds_bucket[5m]))) > 2
    for: 10m
    annotations: { summary: "TTFT p95 > 2s on {{$labels.model}}" }
  - alert: KVCacheNearFull
    expr: vllm:gpu_cache_usage_perc > 0.9
    for: 5m
  - alert: GPUECCErrors
    expr: increase(DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[1h]) > 0
    annotations: { summary: "GPU {{$labels.gpu}} 出现双比特 ECC，立即隔离" }

13.4 LLM-as-Judge 在线采样

import random
from langfuse import Langfuse
lf = Langfuse()

def online_judge(trace_id, question, context, answer, judge_model="gpt-4o"):
    if random.random() > 0.01:  # 1% 采样
        return
    score = call_judge(judge_model, question, context, answer)  # 返回 0-1
    lf.score(trace_id=trace_id, name="groundedness", value=score)
    if score < 0.4:
        lf.event(trace_id=trace_id, name="low_groundedness", level="WARNING")

十四、一个典型排障故事

真实场景串起来看——“周一早上客服机器人变慢”：

  1. Grafana 红灯：TTFT p95 从 0.6 s 冲到 3.5 s，同时 error_rate 平稳，所以不是模型返回错，而是”慢”。
  2. 拆分维度：按 model 看，只有 qwen3-32b 变差；按 tenant 看，tenant-A 占突增 80%；按 region 看集中在单机房。
  3. 引擎指标：vllm:num_requests_waiting 堆积、gpu_cache_usage_perc 96%、prefix_cache_hit_rate 从 55% 掉到 8%、DCGM_FI_PROF_SM_ACTIVE 仍然很高——不是 GPU 闲着，而是在”徒劳”地重复 prefill。
  4. 结论雏形：tenant-A 换了新 system prompt，prefix 变了导致缓存全失效，带来 prefill 风暴，KV cache 被挤爆，后续请求排队。
  5. Langfuse 验证：按 tenant=A 过滤 trace，diff 两个版本 system prompt，果然周末上线了新版；通过 LLM 网关 的 prompt 模板统一化，并把变动的部分挪到尾部，恢复 prefix 复用。
  6. 复盘：给 Prompt 变更加上”prefix cache hit 回归门槛”——离线 eval 跑 1000 条典型对话，命中率低于基线 10% 不允许发布；同时告警里加上 prefix_cache_hit_rate 指标，下次 5 分钟内就能发现。

每一步都依赖不同层的可观测性：业务层告警→基础设施层指标→调用层 trace→Prompt 版本系统。没有任一层都排不出来——这就是”四层观测模型”的价值。

十五、国内外厂商生态速览

不同云厂、模型厂对”自带观测”做了不同程度的封装，选型时需要了解边界。

15.1 国际

15.2 中国

结论：厂商 Dashboard 看”账单和健康”够用，真要排障还是得在应用侧独立上一套 trace。

十六、与训练侧观测的对比

本系列前半在训练篇（06-并行、07-Megatron-DeepSpeed、10-Checkpoint 与容错）里提到过训练观测，和在线观测是两套体系：

关注点 训练侧 在线推理 / 应用侧
迭代周期 一个 job 几天~几周 每秒数百请求
关键指标 loss、gradient norm、MFU、TFLOPS、GPU 健康 TTFT/TPOT、QPS、cost、quality
工具 W&B、TensorBoard、MLflow、SwanLab Langfuse、LangSmith、Phoenix、APM
失败模式 发散、NaN、节点坏、通信卡顿 幻觉、越权、成本爆炸、延迟尖刺
数据产物 Checkpoint、log Trace、Prompt 版本、Eval score

两侧共用的基础设施是 GPU 遥测（DCGM）、分布式 tracing（OTel）、告警总线（Alertmanager）。成熟团队会搭一套统一的”AI Observability Platform”，训练 + 推理共用后端，只在前端看板区分语义。

十七、前沿方向

17.1 自动根因分析（AIOps for AI）

17.2 Trace + Weights 联合剖析

17.3 LLM-Native 评估

17.4 边缘 / On-device 观测

手机 / 端侧模型（Apple Intelligence、小米 MiLM、vivo BlueLM、Phi-3-mini）兴起后，观测要：

17.5 跨模态

图像、语音、视频生成的观测目前远不如纯文本成熟：

十八、落地清单

按规模从小到大分三档推进，避免一次上全套。

18.1 MVP（1 人周）

18.2 生产级（1 人月）

18.3 平台化（跨团队）

参考资料

  1. OpenTelemetry Semantic Conventions for GenAI：https://opentelemetry.io/docs/specs/semconv/gen-ai/
  2. OpenInference Spec（Arize）：https://github.com/Arize-ai/openinference
  3. OpenLLMetry / Traceloop SDK：https://github.com/traceloop/openllmetry
  4. Langfuse：https://langfuse.com/docs
  5. LangSmith：https://docs.smith.langchain.com/
  6. Helicone：https://docs.helicone.ai/
  7. Arize Phoenix：https://docs.arize.com/phoenix
  8. Weights & Biases Weave：https://wandb.me/weave
  9. AgentOps：https://docs.agentops.ai/
  10. Pezzo：https://docs.pezzo.ai/
  11. Lunary：https://lunary.ai/docs
  12. NVIDIA DCGM Exporter：https://github.com/NVIDIA/dcgm-exporter
  13. vLLM Production Monitoring 示例：https://github.com/vllm-project/vllm/tree/main/examples/online_serving
  14. SGLang Metrics：https://docs.sglang.ai/
  15. RAGAS：https://docs.ragas.io/
  16. DeepEval：https://docs.confident-ai.com/
  17. Giskard：https://docs.giskard.ai/
  18. promptfoo：https://www.promptfoo.dev/docs/
  19. 国家网信办《生成式人工智能服务管理暂行办法》：http://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm
  20. GDPR 条款全文：https://gdpr-info.eu/

上一篇：22-大模型网关 下一篇：24-成本、合规与安全

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

By .