pping-langv0.1.0a1
GitHub
LLM serving 的实时剖析器 · Nsight 级深度,常驻 + 自己下结论

不止诊断 vLLM,
Autopilot 自主调优,零干扰

pping-lang 把你本来要开 Nsight Compute 才看得到的 kernel 级深度 (PC sampling / stall reason / SASS / 源码行)做成常驻、低开销、还附结论,而且懂 vLLM 语义。 旗舰能力 Autopilot(设计中)更进一步:不止诊断,还在沙盒里自动把 vLLM 调到最优。

PyPI v0.1.0a1 Python 3.10–3.12 License Apache 2.0 Tests 444 通过
$ pip install pping-lang 复制 看实时演示 ↓
问题

指标能看,但不会下结论

Prometheus + Grafana 那套能把 vLLM 的指标全画出来,但落到「现在到底是什么瓶颈、该动哪个参数」时,要靠人脑补。这里有两个具体的坑:

指标语义模糊

GPU utilization 反映的是 SM duty cycle,不是吞吐量。LLM decode 阶段它常稳定在 70–90%,而 MFU 不足 5% —— 因为 memory-bound。只盯 utilization 数字,识别不出这类瓶颈。

缺乏可操作性

规则触发、阈值告警、根因关联 —— 全要使用方自己实现。看到一堆曲线,离「该把 max_num_seqs 调大还是开 prefix caching」还隔着一整套领域知识。

采集 事实 署名推断 处方

pping-lang 把诊断拆成两层:规则名 = 测出来的客观事实(如「TPOT p99 超 SLA」),根因与优化建议作为署名推断单列。事实和猜测分开摆,你能判断该不该信。

定位

占 Nsight 与 Grafana 之间的空位

Nsight 给你最深的证据,但要抓一段、离线看、还得自己是专家;Grafana 常驻实时,但看不到 kernel、也不下结论。pping-lang 把两边的好处合在一起 —— 常驻 + Nsight 级深度 + 直接给结论,而且懂 vLLM。

维度 Nsight Systems / Compute Grafana + Prometheus pping-lang
运行方式抓一段 → 离线看报告常驻、实时常驻、实时(跑在 vLLM 进程里)
Kernel 级深度 极深 同源 CUPTI · PC sampling / stall / SASS / 源码行
给结论 原始证据,自己读 曲线,自己判 事实 + 署名推断 + 处方
懂 vLLM 语义 只见 CUDA kernel~ 见指标不解释 TTFT / TPOT / KV / batch / prefix / roofline
开销高(详细 profiling 串行化 kernel)低(~5% 预算,常驻)
上手门槛高(要懂 GPU 架构)低(直接给人话)
生产常驻 一次性诊断

Nsight 是实验室显微镜 —— 偶尔抓一段、离线看、给原始证据;pping-lang 是常驻听诊器 —— 一直跑、说人话、还告诉你该调哪个旋钮。要对单个自定义 kernel 做穷尽式微架构调优,Nsight Compute 仍是那把专业手术刀;pping-lang 主打的是常驻、serving 级、结论驱动的那条线。

实时演示

仪表盘 · 一次真实压测的全貌

下面是把 502 个请求(并发 8、内置 mixed-short 数据集)打到 runw 上一台 RTX 5060 Ti 的 vLLM 0.21(Qwen2.5-0.5B)后,仪表盘四个标签页采到的真实数据。点标签切换。

demo.local:8765 captured from live runw
currently serving

Qwen/Qwen2.5-0.5B-Instruct

vLLM0.21.0 GPURTX 5060 Ti BF16 Peak95 TFLOPS Mem BW0.45 TB/s
TTFT p99
19.7ms
p50 18.5 · 远低于 SLA
TPOT p99
5.0ms
p50 4.89 · 稳定
Output 吞吐
1,579tok/s
聚合 · 8 并发
单请求 decode
205tok/s
per-request
GPU 利用率
73%
SM duty cycle
显存带宽
60%
269 / 448 GB/s
显存占用
54%
gpu-mem-util 0.5
KV cache
0.2%
充裕
Running reqs
8
满并发
Waiting reqs
0
无排队
Prefix 命中
78%
mixed-short 复用
抢占率
0/min
无 preemption

Roofline · 算术强度 vs 实测吞吐

每点 = 一次迭代 · 实测自 iter-level token 计数与模型参数量推算(analytical)
自动结论Memory-bound(decode 阶段的典型状态)
算力利用
1.7% · 1.6/95 TFLOPS
带宽利用
60% · 269/448 GB/s
优化路径
  • 增大 batch 直至 KV cache 占用接近 80%
  • 启用 speculative decoding
  • 权重量化(AWQ / GPTQ)
  • 升级带宽更高的 GPU

延迟时序 · TTFT / TPOT

压测窗口内分桶(4s/桶)的 p50 / p99 走势
本机 --enforce-eager 运行,vLLM 未导出 perf_stats,故 MFU / padding ratio 显示为空,Roofline 自动切换 analytical 模式(绝对值约 ±20% 误差)。其余 KPI 不受影响。

诊断结论 · 事实 + 署名推断

规则引擎默认每 1s 评估一次。下例展示规则被触发时的输出形态(本次压测系统健康,无告警)。
GPU 利用率偏低warning
GPU 平均利用率 3% 持续低于 50% 已 30s
署名推断 → 检查 batch 是否退化为 1,或开启连续 batching
batch 退化warning
并发请求数 1.0 ≤ 1.0 已 30s
署名推断 → 增加客户端并发,或检查上游路由是否串行化
这正是你会打开 Nsight Compute 看的东西 —— 但常驻、在仪表盘里、还附结论。 Kernel 级采集需完整接入(pping-vllm serve,经 CUPTI 注入做 PC Sampling)。下方为 runw RTX 5060 Ti(Blackwell)实采、单窗 826 万样本的真实热点。

GPU Kernel 时间占比 · Top 热点 + 算子分类

按 GPU 时间降序 · 每个 kernel 展开后给「最深热点」双轨(源码行 / SASS 偏移)
Kernel分类GPU 时间最深热点
cutlass wmma_bf16 16x16_128x1GEMM57.0%◆ SASS 0x11f0 · memory_dependency 77%
cutlass wmma_bf16 16x16_128x2GEMM33.5%◆ SASS 偏移级(闭源 cutlass)
flash_fwd_splitkv(FlashAttention)Attention1.7%◆ SASS 偏移级(闭源 flash)
flashinfer RadixTopK(采样)Sampling0.8%◆ SASS 偏移级(闭源 flashinfer)
at::native elementwiseElementwise0.7%◆ SASS 偏移级

启动来源 · 即便闭源 GEMM 也能归因

CUPTI 钩 cuLaunchKernel 回溯 host 调用栈 —— 92% 的 GPU 时间(全是 GEMM)来自一条 nn.Linear 链,71,408 次启动
cutlass GEMM92% GPU 时间
↑ 来自
cublasLtMatmul
↑ 来自
at::native::addmm
↑ 来自
at::native::linear · nn.Linear

Deep Evidence · 为什么慢

本窗 826 万样本的 stall reason 分解(PerfWorks 下钻)
memory_dependency
71%
exec_dependency
9%
memory_throttle
9%
其它
11%
kernel 名即诊断:cutlass wmma_bf16 16x16 → tile 16×16 / bf16 / wmma tensorop / SM80。小 tile = 小矩阵、低并发 → 呼应 Roofline 的「增大 batch」结论。memory_dependency 71% = 在等显存 → 实锤 memory-bound。
价值边界(诚实披露):「翻到 .py 源码行」只在 Triton / 自编译 kernel 路径有效。本类负载 ~92% 时间在闭源 cutlass GEMM 里 → 那里只能到 SASS 偏移级 + stall reason + kernel 名解码。runw 实采印证:top kernels 全 mappable=false。这是物理事实,不是 bug。
生效中 13 条策展规则 · 阈值集中在一份 SLA 配置,仪表盘里改完即热加载,不重启 vLLM。
workloadcustom SLA TTFT p992000 ms SLA TPOT p9950 ms
内置 OpenAI 协议静态压测器 · 场景 showcase-demo · 并发 8 · 时长 35s · 数据集 builtin:mixed-short · output 128 tok
请求总数
502
成功 / 错误
502 / 0
Output 吞吐
1,579 tok/s
Output tokens
56.2 K
SLO 达标 ttft:p99 19.7ms < 500ms
SLO 达标 tpot:p99 5.0ms < 50ms

客户端实测延迟分布

client-side 测量 · n = 502
指标p50p90p95p99meanminmax
TTFT ms18.519.119.419.717.113.522.1
TPOT ms4.894.954.975.024.904.685.12
E2E ms636.8644.6648.1654.6560.647.8659.9
旗舰方向设计中 · 即将到来

Autopilot —— 诊断驱动的自主调优

一条命令起 pping-lang → 点「自动调优」→ Agent 在沙盒里迭代「诊断 → 改一个旋钮 → 压测 → Δ → 留下 / 回滚」→ 给出实测验证过的最优配置 + 全程推理。把 LLM 变成一个会看证据、自己动手、用压测打分的 LLM-serving 性能工程师。

1
observe读当前诊断 + 配置 + 历史
2
hypothesize挂在诊断上选一个旋钮
3
act沙盒带新 flag 重启
4
measure跑同一套压测打分
5
decide更好留下 / 破 SLA 回滚
为什么只有 pping-lang 能做
👁 眼睛深度诊断 ✋ 手压测 + serve 控制 📊 记分牌基线 / Δ

三件套在同一进程。别人的 AI infra agent = 把 nvidia-smi 喂给 GPT 盲调;Autopilot = 诊断驱动(只动对症旋钮)→ 3–5 轮收敛,而非盲搜几十轮。每步改动必须 bench 验证才留下,LLM 无权声明压测没证实的收益。

目标:吞吐优先 · TTFT p99 ≤ 1000ms · 预算 6 轮
设计预览 · 示意数字(区别于上方真机数据)
R0基线
max_num_seqs=32 · chunked_prefill=off · gpu_util=0.70
1,240tok/s
baseline
R1
诊断MFU/MBU 双低 · running=8≪32 · waiting=0
假设batch 没拼起来 → enable-chunked-prefill
1,980tok/s+60%
✓ kept
R2
诊断running 仍 ≪ max · KV 用量 31%
假设显存富余 → max_num_seqs 32→128
3,520tok/s+78%
✓ kept
R3
假设gpu_util 0.70→0.90 扩 KV 池
实测TTFT p99 940ms(逼近 SLA)
3,910tok/s+11%
✓ kept
R4
假设max_num_seqs 128→256
实测TTFT p99 1,180ms ✗ 破 SLA
3,840tok/s−2%
↩ reverted
R5
Agent 判:已近最优(再扩并发破 SLA、屋顶已贴)→ 停
■ done
吞吐 1,240 → 3,910 tok/s(×3.15),仍满足 TTFT SLA
$ vllm serve <model> --enable-chunked-prefill --max-num-seqs 128 --gpu-memory-utilization 0.90
「×3」只在「现实但没调过」的默认基线上成立 —— 那正是大量真实部署的现状(默认 max_num_seqs、chunked-prefill 关着、gpu-util 保守)。已调过的基线则是诚实的边际收益(+5~15%),Agent 会如实报「已近最优」。
自主级别 L0–L4 · 从「看见」到「自己写算子」
两条正交轴:能力级(配置 → 代码)与放行度(沙盒自动 / 生产人工)。自动到 L3 封顶,生产永远人工 promote
L0
观测
只诊断、给结论,不动手 —— 今天的 pping-lang
已上线
L1
调参
改 vllm serve 旋钮(introspect 全量参数面)· bench + SLA 验证
M0
L2
配组件
开/换投机解码 · attention 后端 · KV offload · 编译配置 · + 等价检查
M1
L3
写算子
自己写自定义 scheduler / 融合 kernel,经插件点插入(不改源码)· + 强正确性闸
M2/3
L4
改源码
patch vLLM 本体(fork 债、升级即碎)—— 自动封顶在 L3,L4 只提补丁、人审
advisory
工作原理

双路径架构 · 热路径只做 O(1) 入队

设计前提:插件的任何异常都不得影响 vLLM 推理路径。所以热路径不做 I/O、不序列化、不等锁;实时面板直读内存 ring buffer,持久化是顺序追加 JSONL。

                ┌─── live 内存层(O(1) 写 / O(1) 读)
                │       ↑                ↑
record() ──push─┤   /api/kpis        /api/metrics/recent  ≤60s
NVML 100ms ─────┤   /api/snapshot    /api/roofline        ≤60s
                │   /api/latency_trends                   ≤900s

                │   Sink._latest:  name → (value, ts_ns)
                │   Sink._recent:  name → 2000-deep ring

                └─── bg flush ─── JSONL append-log ─── archival 扫描
                                   metrics / diagnoses
热路径开销项实测说明
push_metric() 单次< 5 μs纯入队,无 I/O
record() 单次≈ 100 μs含 collector 解析
Sink bg flush 线程 CPU< 1%独立 daemon 线程
常驻内存≈ 6 MBring buffer 有界
能力

四张能力,一个插件装好

实时 KPI + Roofline

12 项 KPI(TTFT/TPOT/吞吐/KV/队列/MFU/利用率/显存/Prefix/Padding/抢占),Roofline 散点带自动结论卡,TTFT/TPOT/E2E 多统计量时序。每项 hover 看公式与解读。

Kernel 级 PC Sampling(Nsight 级)

Nsight Compute 级的证据,常驻采集:每个 GPU kernel 的时间占比 + 算子分类 + 主导 stall。Triton kernel 直定位到 .py 源码行;闭源库给 SASS 热点 + kernel 名解码;闭源 GEMM 也能归因到调它的 nn.Linear

事实规则诊断引擎

13 条策展规则,「事实 + 署名推断 + 处方」三段式。阈值集中在一份 SLA 配置,仪表盘热加载,不重启 vLLM;可增删自定义规则,与策展规则同一引擎评估。

内置压测器

仪表盘直接发起 OpenAI 协议静态压测,配置 endpoint / 并发 / 时长 / prompt 来源,输出 client-side TTFT/TPOT/E2E 分布与 SLO 校验。三个内置数据集:短问答 / 长文档 / 代码。

快速上手

三种接入,pip 装完即用

不改任何 vLLM 参数,自动加载。需要 Kernel 级证据时,把 vllm serve 换成 pping-vllm serve 即可。

01 · 零依赖试玩

离线 demo

无需 GPU / vLLM,注入合成指标,约 7s 后终端打印诊断。
$ pip install pping-lang
$ python -m examples.embedded.demo
dashboard → localhost:8765
02 · 接入 vLLM

基础接入

KPI / Roofline / NVML / 诊断,自动加载,不改参数。
$ pip install pping-lang
$ vllm serve <model>
启动日志输出 [pping-lang] dashboard → …
03 · 完整证据

+ Kernel 采集

额外开 PC Sampling 的「为什么慢」。薄包装,透传所有参数。
$ pip install pping-lang
$ pping-vllm serve <model>
现编 libppingcupti.so,编不出则自动降级为基础接入
兼容性

跑在哪、采到什么

vLLM 版本支持

vLLM状态SchedulerIterationperf_stats
0.20+推荐
0.13.x支持
< 0.13不支持

perf_stats 是 MFU / 显存带宽利用 / 实测 Roofline 的数据源,仅 0.20+ 提供。缺失时 Roofline 切 analytical,其余功能不变。

已识别 GPU(BF16 峰值 / 带宽)

代际设备
BlackwellB200 · B100
HopperH200 · H100 SXM/PCIe/NVL · A100
Ada 数据中心L40S · L40 · L4
Ada 桌面/移动RTX 4090 … 4060 · 5060 Ti
旧代A30 · A10G · A10 · V100 · T4 · RTX 3090

未识别的 GPU 不影响指标采集,仅跳过依赖峰值的派生量。Linux 原生支持;Windows 经 WSL2 + Ubuntu。

路线图

旗舰是 Autopilot,底座是诊断

旗舰能力

Autopilot 自主调优 · 分期

下一个里程碑
M0
demo MVP

沙盒 + 5 旋钮 + LLM loop

吞吐-under-SLA 目标 + Autopilot UI,runw 上从朴素基线跑出 ×2~3。不碰源码、不碰生产。前置:基线记分牌。

M1 / M2
多目标 / 源码级建议

更多旋钮 + advisory

多旋钮 / 多目标 / 去噪 / promote-to-prod;M2 用 PC sampling 给 kernel / 源码级建议(仅建议,不自动改)。

M3+
数据飞轮

多卡调优 + 学策略

TP/PP/EP 通信维度;每次调优攒「诊断→动作→压测Δ」轨迹 → 学策略,趋近「看一眼直接给最优配置」。

部署形态
当前
v0.1
Embedded

单机本地,pip 装即用

dashboard + 规则引擎 + bench。目标场景:单机本地开发、单卡 / 单 Pod 部署。

v0.2
Sidecar / Centralized

独立 server 进程

Docker 镜像、Helm chart、K8s 多副本指标聚合。面向生产侧部署。

v0.3
Stateless

OTel-native

基于已有 Prometheus / Tempo 后端的诊断,复用现有可观测栈。