GPU、训练与推理可观测性¶

AI 平台最常见的可观测性误区，是只安装 Prometheus 和一个 GPU Dashboard。真正可用的系统必须把基础设施、调度、训练进度、推理请求和模型质量连接到同一条证据链。

1. 五层可观测模型¶

业务与模型质量：正确率、拒答率、用户反馈、安全评估
请求与服务：TTFT、TPOT、Token/s、队列、错误、缓存命中
工作负载：训练 step、loss、checkpoint、rank、重试
设备与节点：GPU、显存、NVLink、RDMA、CPU、磁盘、网络
控制面：队列准入、调度、扩容、Operator、Kubernetes 事件

只有一层数据时，团队往往只能知道“慢了”，无法回答慢在数据、网络、GPU、调度还是模型本身。

2. 先统一关联键¶

指标、日志和 Trace 至少应携带以下低基数标识：

cluster、namespace、workload；
team、environment；
job_id 或 service；
model_name、model_revision；
gpu_model、resource_flavor；
release 或镜像摘要。

请求 ID、Prompt、用户 ID 等高基数或敏感字段不要直接成为 Prometheus Label。它们更适合进入受控日志、Trace 或专用分析系统。

3. GPU 指标怎么看¶

NVIDIA DCGM Exporter 通过 /metrics 暴露 GPU 指标，可作为 DaemonSet 或由 GPU Operator 管理，并能借助 kubelet PodResources 把设备指标关联到 Pod。参考：DCGM Exporter

类别	关注指标	解释
核心利用	GPU utilization、SM activity	GPU 是否在执行计算
显存	framebuffer used/free	模型、Batch 和 KV Cache 占用
内存带宽	DRAM active	是否受显存带宽限制
Tensor Core	Tensor activity	混合精度矩阵计算是否充分
互联	NVLink/NvSwitch throughput、error	多卡通信负载和异常
PCIe	TX/RX throughput、replay	主机与设备传输瓶颈
健康	XID、ECC、health status	驱动或硬件故障信号
环境	功耗、温度、时钟、降频原因	是否被功耗或散热限制

“GPU utilization 100%”不等于效率最佳。它可能在执行低效 Kernel，也可能因同步等待呈现误导性的平均值，需要结合吞吐和业务目标判断。

4. 训练任务的黄金指标¶

训练至少记录：

global step、epoch、samples/s 或 tokens/s；
loss、学习率、梯度范数；
step time 的平均值和 P95；
DataLoader wait、数据解码时间；
collective communication time；
Checkpoint 保存/恢复时间与大小；
有效训练时间、排队时间、失败恢复时间；
各 Rank 的 straggler 差异。

一个实用分解是：

step_time
  = data_wait
  + forward
  + backward
  + communication
  + optimizer
  + checkpoint_amortized

如果只记录总 step time，网络抖动、数据饥饿和计算回退会混在一起。

5. 实验追踪与基础设施监控要分层¶

训练曲线和 GPU 监控解决的是两类问题，不应强行塞进同一个系统：

工具	最适合回答的问题	不适合替代
TensorBoard	单次或少量本地实验的曲线与计算图	团队级项目、权限和实验治理
SwanLab	Run、超参数、Loss、媒体文件和跨实验对比	GPU、节点、RDMA 和 Kubernetes 监控
MLflow	实验、模型制品与模型注册生命周期	高频基础设施指标
Weights & Biases	托管式实验追踪与团队协作	内网完全自托管场景的默认选择
Prometheus + Grafana	GPU、节点、网络、队列和集群告警	训练数据、超参数和模型制品管理

一个实用的训练基础设施组合是：

ms-swift / PyTorch
  -> SwanLab SDK -> Gateway
                    -> Server / Auth -> PostgreSQL
                    -> House / Vector -> ClickHouse
                    -> 媒体与制品 -> S3 兼容对象存储

Kubernetes / DCGM Exporter / NIC
  -> Prometheus -> Grafana

两条链路用统一的 run_id、job_id、模型版本和 Git Commit 对齐。看到 Loss 抖动时，先在 SwanLab 定位具体 Step，再到 Grafana 查看同一时间窗的 GPU 利用率、显存、功耗、慢 Rank 和网络异常。

一次自托管 PoC 的验证结果¶

2026 年 8 月 21 日使用官方 Helm Chart 0.6.2、SwanLab v3.1.1 在 Kubernetes 1.30 环境完成了基础设施 Smoke：10 个 Deployment、1 个 StatefulSet 和 1 个初始化 Job 均成功启动，11 个常驻 Pod 全部 Ready 且未重启；数据库迁移和对象存储 Bucket 初始化成功，Gateway 激活页与 API 均可访问。

这轮 PoC 为了先验证组件、镜像和入口链路，所有有状态目录都使用临时卷，没有创建 PVC。它能证明页面和基础 API 可用，却不能证明数据耐久性；Pod 被替换后，账号、实验和曲线都可能丢失。生产环境应改用持久 PostgreSQL、ClickHouse 和对象存储，并完成备份恢复演练。

实例激活后，又使用训练镜像内置的 SwanLab SDK 0.8.4 创建了一个 6 Step 合成 Run。SDK 成功上传 39 条记录，包含 train/loss、Learning Rate 和 Tokens/s，外部 Web 入口中的 Run 页面返回 200。第一轮兼容性 Smoke 还发现：该镜像中的 swanlab.login() 不接受新版文档里的 web_host 参数，因此训练镜像升级时要同时固定 SDK 版本，并以真实镜像跑一次登录、建 Run、写指标和结束 Run 的回归测试。

随后使用相同链路完成了真实 Qwen3.5-4B + BF16 LoRA：120 Step 的 Train Loss、Learning Rate、Gradient Norm、Token Accuracy 和四次 Validation 都能查看，最佳 Checkpoint 由 Validation Loss 选在 Step 60；110 条隔离盲测的自定义故障码准确率由 Base 的 0% 提升到 Adapter 的 77.3%。这才形成“指标链路 + Checkpoint + Base/Adapter 效果”的完整证据。

真实 Run 也暴露了版本兼容细节：ms-swift 4.4.1 会把 30/120、3m 53s 等展示字段作为字符串上报，SwanLab SDK 0.8.4 拒绝 String Scalar，但数值型指标、训练和盲测不受影响。这个问题应进入镜像升级回归用例。可复用的部署边界与脱敏曲线见 SwanLab 自托管：从 Kubernetes 部署到真实 SFT 指标，机器可读结果见 meaningful-sft。

6. 分布式训练如何找慢 Rank¶

应同时观察：

每个 Rank 的 step duration；
NCCL collective 的耗时分布；
GPU/NIC/NUMA 亲和性；
网卡吞吐、丢包、ECN/PFC 和重传；
CPU 调度、Page Fault 与存储读取；
是否某个节点降频、发生 XID 或链路降级。

最慢 Rank 决定同步训练的整体速度。不要只看集群平均值，平均值会隐藏单节点异常。

7. LLM 推理的核心指标¶

指标	含义	使用方式
TTFT	从请求到首 Token	反映排队、Prefill 和冷启动
TPOT	后续每 Token 时间	反映 Decode 性能
ITL	Token 间延迟	评估流式输出稳定性
E2E latency	完整请求延迟	用户体验与输出长度相关
input/output tokens/s	吞吐	需要区分输入和输出
queue time/depth	排队时间和深度	扩缩容与过载控制依据
KV Cache utilization	缓存占用	判断并发上限和驱逐风险
prefix cache hit	前缀命中	评估路由和缓存收益
request success/cancel	成功、错误、取消	长连接和客户端行为

所有延迟都应按模型、输入长度、输出长度、优先级和流式/非流式请求分桶，否则 P95 缺乏可比性。

8. 从基础设施 SLI 到业务 SLO¶

建议至少定义三类 SLO：

平台 SLO¶

Job 提交 API 可用性；
调度控制面错误率；
有配额且有容量时的准入延迟；
推理平台发布成功率。

工作负载 SLO¶

训练任务成功率与恢复时间；
Checkpoint 成功率；
在线推理可用性、TTFT 和错误率；
模型版本发布和回滚时间。

模型 SLO¶

离线评估门槛；
在线质量、拒答率或安全策略命中；
数据漂移和模型漂移；
用户反馈与业务转化。

基础设施 SLO 达标而模型输出错误，仍然是一次失败发布。

9. 日志设计¶

训练日志应结构化包含：时间、Job、Rank、step、组件和错误类别。推理日志应区分网关、调度器、模型服务器和下游工具调用。

禁止默认记录：

完整 Prompt 与响应；
访问 Token、Cookie、API Key；
数据集中的个人信息；
未脱敏的模型输入附件；
Secret、环境变量或完整 Pod Spec。

为排障临时提高日志级别时，应设置自动过期，并限制访问权限。

10. Trace 应覆盖哪些边界¶

一次推理请求可以跨越：

API Gateway
  → 身份/限流
  → 模型路由
  → 排队
  → Prefill Worker
  → KV Cache 传输
  → Decode Worker
  → 工具或检索服务
  → 流式响应

Trace 的价值是解释端到端延迟，不是替代指标。OpenTelemetry 提供 Trace、Metric、Log 和 Resource 的语义约定，可用统一资源属性关联信号。参考：OpenTelemetry Semantic Conventions

11. 告警应该可行动¶

较好的告警示例：

GPU 节点出现新的 XID 且对应 Pod 错误率上升；
TTFT P99 超过 SLO，同时队列深度持续增加；
有配额队列等待超过阈值，但集群扩容没有动作；
Checkpoint 连续失败，剩余可恢复窗口低于 RPO；
单个 Rank 比中位数慢 30% 以上；
GPU 功耗低、显存高、吞吐下降，疑似数据或通信瓶颈。

“CPU 高”或“Pod 重启”本身通常不够行动化，需要包含影响对象、可能原因和 Runbook 链接。

12. 控制指标基数和成本¶

不把 request ID、用户 ID、文件名作为 Metric Label；
模型版本只保留当前和少量历史版本；
对高频 GPU Profiling 指标控制采样间隔；
长期趋势降采样，原始高分辨率数据短期保留；
Trace 使用按错误、延迟或租户的尾部采样；
为日志、指标和 Trace 本身设置容量预算。

可观测系统把生产集群拖慢，是平台常见的二次故障。

13. 推荐 Dashboard¶

平台总览：GPU 容量、队列、成本、SLO、告警；
节点详情：GPU、NVLink、NIC、CPU、存储、XID；
训练任务：step、loss、吞吐、Rank、通信、Checkpoint；
推理服务：TTFT、TPOT、队列、KV Cache、错误、版本；
租户视图：配额、GPU-hours、成功率、等待时间和成本；
发布视图：新旧版本的质量、性能和错误对比。