<![CDATA[二测 vLLM 服务器 Agent 长链性能及稳定性测试-为家庭终端做准备]]>二测 vLLM 服务器 Agent 长链性能及稳定性测试

测评时间： 2026-09-18（完整测试周期约 7 小时）（其中局域网多次断网测试）
被测配置： vLLM 0.27.1（RADIANCE 0.9.3）· Qwen3.8-27B INT4 · AMD Radeon AI PRO R9700
运行参数： --gpu-memory-utilization 0.95 / --max-num-seqs 4 / --max-num-batched-tokens 8192 / fp8 KV / 前缀缓存 / MTP 投机解码 / R4D 后端

一、测评总览

本次对优化后的服务器做了完整的 Agent 长链性能测评，累计约 1764 次真实推理调用，0 错误、0 抢占、0 崩溃、0 OOM。核心结论：

维度 结论
稳定性 ★★★★★ 满分——1764 次调用零失败，30 分钟浸泡无宕机
解码速度 MTP 投机解码提速 2.05 倍（40 vs 19.5 tok/s），是最大性能杠杆
长链瓶颈 每步延迟被上下文处理（TTFT）主导，24K 上下文时 TTFT 达 19.7 秒
并发能力 单卡在 1–2 并发即饱和，4 并发只 +24% 吞吐却慢 6.4 倍

最终调优方案： max-context=60000 → 40000 / max-num-seqs=4 → 2 / gpu-memory-utilization 0.97→ 0.95

二、测试环境

2.1 部署完成的工作

本次测评前完成了完整环境搭建，包括：

组件 状态 说明
Docker Compose ✅ 2.40.3 新增安装，并配置国内镜像加速（解决 Docker Hub 被墙）
Prometheus :9090 ✅ 抓取 vllm/amdgpu/node 三个 target
Grafana :3000 ✅ 含 R9700 GPU 面板
node-exporter :9100 ✅ VM 主机指标
gpu-exporter :9103 ✅ R9700 GPU 指标（last_ok=1）

部署过程中修复了 3 个监控栈 bug：① debugfs 挂载点不存在；② gpu-exporter 继承 radiance entrypoint 导致被当 vllm serve 跑；③ 容器内 amd-smi 子命令不兼容（改用 rocm-smi）。

2.2 服务器关键参数（预检确认）

参数 值
KV 缓存容量 148,111 token（fp8 + HND 布局）
max-model-len 131072 （硬性指标不要动）
max-num-seqs 4（减少并发）
gpu-memory-utilization 0.95 （0.97→0.95）防止OOM
max-num-batched-tokens 8192 （不鸟他）
投机解码 MTP，num_speculative_tokens=4 （真正的红利）

三、测试结果

3.1 冒烟测试（30 步）✅

指标 值
成功率 30/30（100%）
TTFT p50 1858 ms
TPOT p50 13.9 ms
聚合吞吐 47.5 tok/s

3.2 MTP 投机解码开关对照 ✅（关键发现）

指标 MTP 开（日常） MTP 关（纯引擎） 差异
decode 吞吐 40.0 tok/s 19.5 tok/s MTP 提速 2.05 倍
TTFT 97 ms 86 ms 基本不变
ITL（chunk 级） 61 ms 52 ms MTP 每 chunk 含多 token

结论：投机解码让解码速度翻倍，且不增加 TTFT。这是本机最有价值的优化项，强烈建议日常保持开启。

3.3 Phase 1 —— 单链基线（500 步 × 3 回合）✅

指标 值 说明
成功率 500/500（0 错误、0 重试） ✅
墙钟时长 11098 s（3.1 小时） 长于预估
最大上下文 24,410 token 触发裁剪
TTFT p50 19,722 ms（19.7 秒） ⚠️ 随上下文显著增长
TPOT p50 14.1 ms ✅ 解码稳定
聚合吞吐 16.9 tok/s 受 TTFT 拖累 （重点调它，40000）

关键发现：长链延迟由"上下文处理"主导。 TTFT 随上下文增长：冒烟 12K 上下文时 1.8s → Phase 1 的 24K 上下文时 19.7s。即使开启前缀缓存，每步仍需对完整上下文做注意力计算。而 TPOT 始终稳定在 ~14ms，说明解码不是瓶颈，长上下文的 prefill/注意力才是。

3.4 Phase 2 —— 并发梯度（1/2/4 × 150 步）✅

并发 墙钟 成功率 TTFT p50 TPOT p50 聚合吞吐
1 34 min 150/150 9.78 s 13.8 ms 28.7 tok/s
2（够了） 61 min 300/300 9.90 s 38.0 ms 32.7 tok/s
4 105 min 600/600 10.0 s 88.0 ms 35.6 tok/s

关键发现：单卡在 1–2 并发即饱和。

  • TPOT 随并发急剧退化：1→2 并发 2.75 倍、1→4 并发 6.4 倍；
  • 聚合吞吐几乎不涨：28.7 → 32.7 → 35.6 tok/s（4 并发仅 +24%）；
  • 这是典型的单 GPU "边际收益递减"——并发增加的是排队，不是吞吐。

3.5 Phase 3 —— 稳定性浸泡（2 Agent × 30 分钟）✅

指标 值
调用数 168（2 条链）
错误 / 重试 / 宕机 0 / 0 / 0
TTFT p50 9.9 s
TPOT p50 39.3 ms
聚合吞吐 35.2 tok/s

30 分钟浸泡期间服务器零宕机、零错误，温度正常回落。2 个 chain_aborted 事件是 30 分钟预算正常到期（非故障）。

3.6 全周期累计（服务器侧 /metrics 实测）

指标 累计值
成功请求 1740（1089 stop + 651 length）
失败 / 中止 / 重复 0 / 0 / 0
抢占（preemptions） 0
累计 prompt tokens 25,118,970
累计生成 tokens 660,041

四、核心结论与发现

4.1 稳定性：满分

1764 次调用零失败、零抢占、零 OOM，30 分钟浸泡无宕机。优化后的配置（0.95/4/8192）在长时间、多阶段负载下表现稳定。

4.2 性能画像（实测）

场景 TTFT TPOT 解码速度
短问答（热） ~97 ms 14 ms ~40 tok/s
长链 12K 上下文 ~10 s 14 ms ~26 tok/s
长链 24K 上下文 ~19.7 s 14 ms ~24 tok/s
2 并发 ~10 s 38 ms ~26 tok/s
4 并发 ~10 s 88 ms ~11 tok/s

4.3 三大发现

  1. MTP 投机解码提速 2 倍（19.5 → 40 tok/s），是本机最重要的性能优化，日常必须开启。
  2. 长链瓶颈在 TTFT 而非解码：24K 上下文时每步 19.7 秒，其中解码仅 ~5 秒，其余是上下文注意力处理。TPOT 全程稳定 14ms，证明 R9700 的解码能力充足。
  3. 单卡最优工作点是 1–2 并发：4 并发只换回 24% 吞吐却付出 6.4 倍延迟代价，对你的单用户场景毫无必要。

五、我的使用场景

5.1 日常使用参数（已就位）

项 建议 状态
MTP 投机解码 保持开启（2 倍解码加速） ✅ 已开启
max_tokens（调不了，不折腾了） 512（避免"只思考不回答"） ✅ 本次测试用 512
并发 保持 1–2，不要刻意并发 ✅ max-num-seqs=4 已够
重启自愈 unless-stopped ✅ 已开启

5.2 偶发 Agent 长任务的优化建议

由于长链瓶颈是 TTFT（上下文处理），建议：

  1. 控制上下文窗口：Agent 链的 --max-context 建议 12000–16000（而非 60000）。24K 上下文每步 19.7s，而 12K 上下文仅 10s——窗口砍半，每步提速近 1 倍。
  2. 及时裁剪冗余上下文：让 Agent 框架主动丢弃不相关的历史消息，保持窗口紧凑。
  3. 接受"慢而稳"：500 步长链约 3 小时是这台硬件的真实能力，属正常。若需更快，只能换更强 GPU 或多卡张量并行（这是没调参数前）。

5.3 监控使用 （实测有问题，后期QW给修好了）

  • Grafana 看板：浏览器打开 http://192.168.67.202:3000（admin/admin，改密码）；
  • GPU 实时状态：看板里 R9700 GPU (AMD/ROCm) 面板的 VRAM/温度/功耗曲线；
  • 引擎指标：vLLM 官方面板（TTFT/TPOT 直方图、KV 使用率、抢占数）。

六、需要进一步优化

优化后的 vLLM 服务器（R9700 单卡 + Qwen3.8-27B INT4）经完整 Agent 长链测评：

  1. 稳定可靠：1764 次调用零失败，满足日常学习办公 + 偶发 Agent 长任务的生产需求；
  2. 性能明确：短问答 40 tok/s、长链每步 10–20 秒（随上下文）、单卡最优 1–2 并发；
  3. 关键优化已落地：MTP 投机解码（2 倍加速）、fp8 KV（148K token 容量）、前缀缓存、开机自愈；
  4. 唯一短板：长上下文下的 TTFT 是主要瓶颈，需通过控制 Agent 窗口大小来缓解（硬件层面无法在当前单卡上解决）。

综合评级：稳定性与可用性优秀，性能符合 27B 模型单卡 INT4 的预期水平，可放心投入日常使用。

本报告基于 2026-09-18 对服务器的完整实测数据，覆盖冒烟、MTP 对照、500 步长链基线、1/2/4 并发梯度、30 分钟浸泡共约 1764 次真实推理调用。

396df61a-59b2-457b-9c07-1306817b0d3d-image.jpeg

d2b1938d-8f2a-4f86-b0c5-15d6f6ad91d8-image.jpeg

]]>https://lcz.me/topic/1801RSS for NodeSun, 25 Oct 2026 02:00:05 GMTFri, 18 Sep 2026 11:44:41 GMT60<![CDATA[Reply to 二测 vLLM 服务器 Agent 长链性能及稳定性测试-为家庭终端做准备 on Fri, 18 Sep 2026 16:03:22 GMT]]>数据量够，三点可以再压：

  1. 24K 上下文 TTFT 19.7s 是 prefill 决定的，vLLM 侧只有前缀缓存命中率和 chunked prefill 两个杠杆。如果 agent 每步都在同一长前缀上滚，命中后 TTFT 应掉到百毫秒级；没掉就先查每步 prompt 是否都变了（工具输出插在中间会让整段前缀失效）。
  2. MTP 2.05 倍很亮，但要连接受长度一起看：num_speculative_tokens=4 在高并发下验证 FLOPs 翻倍，4 并发只 +24% 吞吐，很可能就是这里被吃掉。扫 k=2/3/4，画「接受长度 x 有效吞吐」再定。
  3. 单卡 1–2 并发饱和是 R9700 带宽（640GB/s）决定的，27B INT4 权重约 15GB，dense 上限粗算约 40 t/s。注意你 MTP 关掉只有 19.5，不到这个上限的一半，说明引擎本身还没吃满带宽（ROCm kernel、fp8 KV/HND 布局都可能是原因），这块单独查可能比调并发更值钱。对 24K 长链，结论应该偏「限并发保 TTFT」，而不是追聚合吞吐。

max-num-seqs 4 收到 2、gpu-mem 0.95 是对的方向。

]]>https://lcz.me/post/19199https://lcz.me/post/19199Fri, 18 Sep 2026 16:03:22 GMT