在模型精度调试调优过程中，开发者常会面临如下难题：模型精度测评效率偏低，测评任务一旦中断需从头执行，难以通过新增代码埋点开展性能诊断，很难精准定位执行缓慢的根本原因。

针对上述挑战，昇腾MindStudio服务化调优工具 msServiceProfiler 无需修改一行vLLM Ascend源码，也无需重启正在运行的测评任务，仅需5分钟即可搭建覆盖vLLM Ascend 全链路的在线监测体系。借助工具完成性能优化后，同等规模测试样本的整体测评耗时大幅缩减，测评性能提升3.7倍。

长时测评任务的三大性能监测现状

大模型精度测评与普通线上推理服务有着本质区别，传统的性能监测手段在这个场景下几乎完全失效：

**无法重启加埋点：**测评任务连续运行数天，任何重启都会导致前功尽弃，硬编码埋点的方式根本不可行。

**黑盒运行无感知：**只能看到任务在运行，却不知道 vLLM Ascend内部的调度状态、缓存利用率、推理耗时等关键信息。

**性能波动难追溯：**几天的运行过程中可能出现间歇性的性能下降，但没有历史数据可以回溯分析。

我们需要的是一种“无感接入、在线监测、动态扩展”的指标采集方案，能够在不影响长时任务运行的前提下，透视vLLM Ascend内部的每一个细节。

**msServiceProfiler：**长时任务的性能透视镜

msServiceProfiler是专为大模型推理场景设计的轻量级Python 指标采集库，基于动态字节码注入技术，完美解决了长时任务的性能监测难题。下面就结合GLM大模型精度的调试调优，看看msServiceProfiler是如何帮助我们定位和解决性能问题的。

第一步：零侵入集成，不中断测评任务

我们拉起vLLM Ascend推理服务进行测评，测评任务已经连续运行了12小时。如果按照传统方式，我们只能终止任务、修改代码加埋点、重新运行，这意味着之前 12 小时的工作全部白费。

而使用 msServiceProfiler ，我们只需要两步：

• 在服务配置中添加一行依赖：

  ms_service_metric

• 在vLLM Ascend启动脚本中添加一行初始化代码：

from ms_service_metric import initialize_vllm_metric
initialize_vllm_metric()

**无需重启正在运行的测评任务，**我们只需要重新发布服务，新的请求就会自动带上指标采集能力，而正在处理的请求不会受到任何影响。

第二步：开箱即用的指标，快速发现异常

集成完成后，我们立即打开了预置的Grafana监测大盘，一眼就发现了问题所在：

vLLM Ascend核心指标监测大盘

首字时延 (TTFT) 的p99 avg是3.48min

单token时延 (TPOT) 波动极大，p99 avg峰值达到2.49s

Prefix Ca****che命中率仅为12%，远低于预期的80%以上

这些指标清晰地指向了同一个方向：vLLM Ascend的缓存机制没有正常工作，导致大量重复计算。但具体是什么原因导致的缓存失效，我们还需要更详细的指标。

第三步：动态添加指标，精准定位根因

这时候msServiceProfiler的运行时配置热加载能力发挥了关键作用。我们不需要重启测评服务，只需要编写一个简单的YAML配置文件，添加重计算相关的指标：

- symbol: vllm.core.scheduler.Scheduler._schedule
  need_locals: true
  metrics:
    - name: vllm_recompute_count
      type: counter
      expr: "recompute_count if 'recompute_count' in locals() else 0"
      description: "重计算触发次数"
    - name: vllm_recompute_tokens
      type: counter
      expr: "sum([seq.get_num_uncomputed_tokens() for seq in running])"
      description: "重计算token总数"

然后执行一条命令：

ms-service-metric restart

新增的指标立即生效，我们很快就看到了性能数据：

重计算指标监测

每轮调度平均触发15次重计算

重计算token占总处理token的65%

原来，我们为了加快测评速度，将并发数设置得过高，导致vLLM Ascend的调度器频繁进行请求抢占，而被抢占的请求无法复用之前的缓存，必须从头开始重计算。这就是为什么Prefix Cache命中率极低，整体性能变差的根本原因。

第四步：针对性优化，性能提升3.7倍

找到了问题根源，优化就变得非常简单。我们在保证精度不受影响的前提下，将并发数从原来的32降低到8。调整后，我们立即通过监测大盘看到了变化：

Prefix Cache平均命中率提升至76.9%

重计算次数抢占率的平均值下降至0.00271

TTFT的P99 avg值降至14.6s，TPOT P99 avg稳定在 147ms以内

优化前后性能对比，同等规模测试样本下多项关键指标实现显著提升：TTFT性能提升14.3倍，TPOT性能提升16.9倍，端到端测评性能提升3.7倍，大幅加速模型精度测评迭代效率。

为什么msServiceProfiler

能搞定长时任务监测？

msServiceProfiler之所以能够完美适配大模型长时运行任务的监测需求，核心在于它的三大技术特性：

**动态字节码注入技术：**在运行时将采集逻辑植入目标函数，无需修改源码，不影响任务的连续性

**共享内存+信号机制：**实现真正的运行时动态开关和配置热加载，随时添加或删除指标，无需重启服务

**vLLM Ascend深度原生集成：**开箱即用提供100+核心指标，覆盖调度、执行、缓存、资源等全链路，无需自己阅读源码加埋点

此外，它还完美兼容vLLM Ascend的多进程部署架构，通过Prometheus多进程模式和共享内存前缀隔离，确保在多Worker场景下指标采集的准确性和一致性。

5分钟上手，开启你的长时任务性能监测

如果你也在进行大模型精度测评、批量推理等长时运行任务，不妨试试msServiceProfiler ，只需5分钟就能搭建起完整的监测体系：

安装参考文档：

https://gitcode.com/Ascend/msserviceprofiler/blob/master/docs/zh/msserviceprofiler_install_guide.md

集成vLLM Ascend

在你的vLLM Ascend启动脚本中添加一行代码：

python
运行
from ms_service_metric import initialize_vllm_metric
initialize_vllm_metric()

启动服务并开启采集

bash
运行
# 启动你的vLLM服务
python -m vllm.entrypoints.api_server --model your-model
# 开启指标采集
ms-service-metric on

查看监测

打开Prometheus和Grafana，导入预置的仪表盘模板，即可看到所有核心指标。如需添加自定义指标，只需修改YAML 配置文件并执行ms-service-metric restart即可。

总结

大模型的精度和性能优化是一个长期的过程，而高效的性能监测是这个过程中不可或缺的工具。传统的硬编码埋点方式不仅效率低下，而且无法应对长时运行任务的监测需求。

msServiceProfiler通过创新的动态字节码注入技术，为我们提供了一种全新的指标采集方式：零代码侵入、运行时动态控制、轻量高效。它让我们能够在不影响业务的前提下，透视大模型推理服务的每一个细节，快速定位和解决性能问题。

目前msServiceProfiler已经在GitCode开源，地址：

https://gitcode.com/Ascend/msserviceprofiler/tree/master/ms_service_metric

扫描二维码，一键直达msServiceProfiler开源社区