在 GPU 资源日益成为 AI 基础设施瓶颈的今天，如何准确评估 GPU 的实际算力利用率成了一个关键问题。传统工具如 nvidia-smi 和 nvtop 只会显示 GPU 是否在运行内核，而不管运行的是计算密集型任务还是内存等待 —— 它们在所有场景下都可能显示 100%，这给了开发者一个严重误导的信号。Systalyze 开源的 Utilyze 正是为了解决这一痛点而生，它通过直接读取 GPU 硬件性能计数器来报告真实的算力有效利用率，并将这个利用率与当前工作负载、模型和硬件组合下的可达成上限进行对比，为性能优化提供可操作的方向指引。
从利用率到有效利用率：为什么现有工具都失真
理解 Utilyze 的价值首先需要理解现有工具的测量盲区。nvidia-smi 和 nvtop 判断 GPU 是否繁忙的方式非常粗糙：只要 GPU 上有任何内核在执行，就将其标记为 100% 利用。这相当于把整个 GPU 芯片当成一个简单的开关 —— 要么在工作，要么不在。对于现代 AI 负载而言，这种二元判断几乎没有参考价值：一个内存密集型的解码任务会让 GPU 看起来满负荷运转，但实际的算力利用率可能只有 6%。
DCGM（Data Center GPU Manager）提供了更丰富的指标，其中最常用的是 SM Active（活跃 SM 比例），它衡量的是有多少比例的流多处理器（Streaming Multiprocessor，SM）至少有一个 warp 调度在其上。这一指标比 nvidia-smi 进了一步，因为它至少考虑了 GPU 内部的计算单元活动。然而，SM Active 同样无法区分一个 warp 是在做算术运算还是在等待数据从内存返回。一个 warp resident 在 SM 上并不等于 SM 正在进行有效的计算 —— 它可能在搬运数据、执行分支判断，或者纯粹在空闲等待。当工作负载是内存密集型时，SM Active 可能显示 99% 的利用率，而实际的算术吞吐量可能依然只有峰值能力的个位数百分比。
Utilyze 的核心创新在于它直接测量每个计算引擎（如 Tensor Core、FP32/FP64/INT32 流水线）和每个内存子系统（如 HBM 带宽、L2 缓存、L1 缓存）的实际吞吐量，然后除以硬件的理论峰值，得到两个关键指标：Compute SOL %（算力有效利用率）和 Memory SOL %（内存带宽有效利用率）。这两个数字直接回答了一个问题：GPU 距离其物理极限还有多远？
SOL 指标的技术原理与采集方式
SOL（Speed-of-Light）模型源自 roofline 性能分析框架，其核心思想是：任何 GPU 上的 AI 操作都受到两个物理极限的约束 —— 计算吞吐量和内存带宽。每一个内核都会首先撞上这两个限制中的一个，而这个限制决定了它的理论最高性能。SOL % 就是实际达成的吞吐量占这个理论极限的百分比。
Utilyze 通过 NVIDIA 的 Nsight Perf SDK 来轮询 GPU 性能计数器。它并不像 Nsight Compute（ncu）那样通过重放内核来获取详细指标 —— 那种方式的代价是让工作负载慢 10 到 100 倍，完全不适合生产环境。Utilyze 采取的方式是在多个时间窗口上滚动采样并聚合结果，因此开销可以忽略不计，能够在生产环境中持续运行而不会干扰实际工作负载。
具体实现上，Utilyze 在 Linux 环境下需要 sudo 权限或 CAP_SYS_ADMIN 能力来访问 GPU 性能计数器。它支持 NVIDIA Ampere 或更新的 GPU（A100、H100、H200、B200、RTX 3000+），需要 CUDA Toolkit 11.0+。安装完成后，只需运行 sudo utlz 即可监控所有 GPU，运行 sudo utlz --devices 0,2 可以指定特定 GPU。Utilyze 还会发现运行的推理服务器（如 vLLM）来检测每个 GPU 上加载的模型，从而计算该模型在当前硬件上的 Attainable SOL %（可达成算力利用率）—— 这是一个比 100% 更现实的性能上限。
Attainable SOL：从测量到优化决策的关键桥梁
理解了 SOL % 之后，一个更重要的问题是：100% 真的是目标吗？答案是否定的。硬件的理论峰值 —— 比如 H100 的 2000 TFLOPS 算力和 3.4 TB/s 内存带宽 —— 是一个物理极限，没有任何真实 AI 工作负载能够达到。内核启动有开销，数据在内存层次结构之间移动需要时间，线程同步消耗周期，在多 GPU 环境中 GPU 之间的通信也要占用时间。对于 MoE（混合专家）模型，专家路由带来的不规则内存访问模式更是会显著降低有效吞吐量。这些都不是优化不佳的表现，而是真实部署的结构性属性。
Utilyze 引入的 Attainable SOL % 正是为了解决这个问题。它是根据当前硬件、软件栈、AI 工作负载和模型架构计算出的一个现实天花板。例如，如果你运行的是一个 120B 参数的推理配置，当前 Compute SOL % 是 30%，而该模型在该硬件上的 Attainable SOL % 是 35%，说明你已经接近极限；但如果 Attainable SOL % 是 65%，则你有 35 个百分点的可优化空间，此时应该做的是优化而非采购更多硬件。Utilyze 会自动发现推理服务器并计算这个天花板，当前支持 vLLM 后端，未来计划支持 SGLang 等更多推理框架。
实际场景中的优化落点
在 Systalyze 公布的基准测试中，Utilyze 展示了在多种真实 AI 场景中的诊断价值。
对于 Prefill 密集的 LLM 推理场景（Llama-3.1-8B，2xH200，ISL=8192，OSL=64，并发 20），Utilyze 显示 Compute SOL % 约为 45%，Memory SOL % 更低，说明这是一个计算密集型工作负载。Utilyze 估算的 Attainable SOL % 为 89%，这意味着当前有 44 个百分点的优化空间可以挖掘。在应用 Systalyze 的优化技术后，Compute SOL % 提升到接近 Attainable SOL % 的水平，token 吞吐量从 52,298 tokens/s 提升到 73,903 tokens/s，提升幅度达 40%。与此同时，nvtop 在整个过程中始终显示 100%，完全无法反映这一优化空间。
对于 Decode 密集的 LLM 推理场景，情况则截然不同。Decode 阶段每个批次都需要将整个模型权重和 KV cache 从 HBM 搬运到计算单元，使得这类工作负载天然是内存带宽受限的。Utilyze 清晰显示 Memory SOL % 显著高于 Compute SOL %，确认了这一点。当并发从 2 提升到 32 时，两个指标都有提升：更大的批次使得每次读取模型权重可以摊销更多计算，KV cache 增大也使得内存读取总量增加，Compute SOL % 从极低值上升到 46%，接近 Attainable SOL %。
对于 LoRA 微调场景，默认框架设置下的 Compute SOL % 只有 1% 到 7%，而 nvidia-smi 显示 80% 到 100%。这一反差的原因是 LoRA 微调中，前向和反向传播主要是在读取冻结的基础模型权重，这些操作内存带宽利用率高但算术强度低 —— 每个字节的移动产生的算术工作量很少，使得工作负载停留在内存受限区域。LoRA 适配器本身的矩阵乘法规模太小（rank 通常为 8 到 64），无法充分利用 Tensor Core。在应用优化后，Compute SOL % 提升到 40% 到 55%，实现了 6 到 8 倍的实际算力吞吐量提升，直接反映在训练步时间的缩短上。
对于更复杂的 MoE（混合专家）模型全参数微调场景（gpt-oss-20b，4xH200），Utinyze 显示 Compute SOL % 为 3% 到 15%，而 nvidia-smi 同样显示 100%。MoE 模型的特殊性在于每个 token 只激活 20B 参数中的 3.6B，Tensor Core 期望的是大规模均匀矩阵乘法，但 MoE 给出的是每个活跃专家的小规模不均匀块，加上路由和 token shuffling 的开销，GPU 难以被完全利用。优化后利用率提升到 30% 到 60%，工作负载从完全的内存带宽受限转变为计算受限。值得注意的是，MoE 的低 SOL % 部分是其架构固有特性 —— 它用 GPU 利用率换取更小的每 token 激活参数量和更低的训练 FLOPs，不能简单视为优化失败。
落地建议与工程参数
将 Utilyze 集成到日常开发流程中，可以遵循以下工程实践。首先，在首次评估阶段使用 sudo utlz 启动监控，观察 Compute SOL % 和 Memory SOL % 的相对大小 —— 哪个更高就说明当前工作负载受哪个瓶颈制约，这直接决定了优化方向是优化计算路径还是优化内存访问模式。其次，关注当前 SOL % 与 Attainable SOL % 之间的差距，如果差距大于 15 到 20 个百分点，优化工作应该优先于扩容采购。第三，在进行优化（如调整批次大小、启用 CUDA Graph、融合内核、调整并行策略）后，用 Utilyze 验证 SOL % 是否提升，确保每一步优化都有量化反馈。第四，对于需要持续监控的生产环境，可以将 Utilyze 作为长期运行的守护进程，配合 Prometheus 等指标采集系统记录 SOL % 趋势。
对于团队而言，值得在 GPU 监控体系中引入 Utilyze 作为 nvidia-smi 的补充。nvidia-smi 仍然适合用于基础的 GPU 状态监控（如显存使用、温度、电源），但当需要判断 GPU 是否被有效利用来做有意义的计算时，SOL % 指标是不可替代的。理解并应用这两个指标的差异，是从 “GPU 看起来很忙” 到 “GPU 正在高效工作” 这一认知转变的关键一步。
资料来源：Utilyze 官方 GitHub 仓库与 Systalyze 官方博客。