在 H100 显卡上部署大语言模型服务器并连接十六个客户端时，nvidia-smi 监控显示 GPU 繁忙度仅为 35%，吞吐量为每秒 58 个 token，首 token 延迟接近两秒。这意味着显卡在三分之二时间内处于空闲，用户却在排队等待，而常规工具无法解释剩余时间的去向。
百分比的误导与细粒度统计
NVIDIA 定义的“GPU 繁忙”指采样周期内至少有一个内核（kernel）运行的时间占比。35% 的繁忙度仅表明 65% 的时间无内核运行，并未揭示显存资源占用情况。为此，团队开发了开源分析工具 Tensward 及其内置统计库 census。该库通过 NVIDIA CUPTI 接口和环境变量 CUDA_INJECTION64_PATH 注入推理服务器，无需重新编译即可记录内核启动、运行时长、内存复制操作、耗时及传输字节数，从而计算每个请求的 GPU 成本。
每个请求 643 MB 的数据搬运
在使用 llama.cpp 运行 Qwen3.8-27B 混合架构模型时，统计数据显示每个请求会从 GPU 向主机内存复制 643 MB 数据，远高于普通 8B 模型的 49 MB。原因在于 llama-server 默认在主机内存保留提示词缓存并创建对话检查点，以便后续加载避免重算。这种权衡导致每次请求均产生数百兆字节的复制开销。
由于复制操作在单线程上运行，保存一个对话状态时其余客户端均需等待。采样显示，该线程 80% 的时间处于内存复制状态。通过设置 --cache-ram 0 --ctx-checkpoints 0 关闭此功能后，吞吐量从每秒 58 个 token 提升至 110 个，GPU 繁忙度从 35% 升至 88%。在独立机器上的复测证实了约 87%-94% 的性能增益。需注意，此举会丢弃提示词复用能力，在部分场景下可能导致性能下降，应视为诊断手段而非通用优化方案。
版本迭代与指标陷阱
升级至 11 月 15 日发布的 llama.cpp 新版本后，默认设置下处理相同负载的速度提升 67% 至 75%。统计库显示，每个请求复制字节数仍约为 643 MB，但内核运行时间占比从 30% 提升至 45%，表明复制效率而非数据量得到了优化。这与上游合并的三个关于状态复制和存储的 PR 相符。
此外，百分比指标存在其他误导案例：在 L4 显卡上运行 MoE 模型时，nvidia-smi 显示繁忙度为 55%，但统计库和 DCGM 显示内核实际运行时间仅为 25%，其余时间为 CPU 到 GPU 的权重复制；而在 H100 上使用 vLLM 时，nvidia-smi 显示繁忙度高达 95%-97%，DCGM SM 占用率却仅为 8%-12%，表明显卡虽在运行但算力利用率极低。
工具现状与局限
该统计库目前仍为研究工具。在 L4 显卡上，llama.cpp 的记录开销约为吞吐量的 4%，vLLM 中低于 1% 至 4%。早期版本在旧版 llama.cpp 和混合模型测试中存在崩溃风险，但在新版本 H100 测试中未复现。该库已兼容 llama.cpp、vLLM 0.30.0、Ollama 0.40.15 和 SGLang 0.5.21，无需修改引擎代码。相比需要单独追踪会话的 NVIDIA nsys profiler，该库能在服务器正常运行时实时计数。统计库计划纳入 Tensward 0.5，具体发布日期待定。