运行记录 mem=0.57，KV Token 池 1,579,520
三台分别为 PP Rank 0 / 1 / 2，KV 指标一致、health 正常；HTTPS Web UI、Prometheus、Grafana 在线。当前进程累计请求量远不足以构成并发、Arrival、8K 或稳定性验收。
02 · 能力实测 · 业务负责人重点看
历史能力基线：能用，但要管好长文本和排队
本页性能数字来自 2026-08-15/16 的 mem=0.50 验收配置。2026-08-17 当前服务已扩大 KV 池，但完整矩阵尚未重跑，不能把旧数字写成新配置性能。
mem=0.50、MRR=8、Graph=4 的完整矩阵
35.105 tok/s、120/120、160/160、4K/8K 和约 83 分钟混合观察全部属于该配置。数字仍有效，但只用于历史容量基线。
本页解决什么回答“用户等多久、能同时来多少请求、最长能输入多少”
项目实测官方数据
296+历史验收通过请求
100%纳入通过统计的用例
83 分钟历史混合负载观察
另有 FAIL12K 重复与 16K 边界
01 · 历史用户体验
mem=0.50 基线下，一次请求大概要等多久？
以下是历史样本的 p95 体验边界，不代表当前大 KV 配置。
95% 请求在约 3 秒内开始看到回答；完整生成约 23 秒以内。
256 输入 / 128 输出，稳态约 0.10 req/s首字等待明显变长，完整完成约 31 秒；适合能容忍短队列的后台任务。
256 输入 / 128 输出，约 0.20 req/s客户端已经出现明显排队，完整等待接近 48 秒，不建议作为交互默认。
目标 0.30 req/s，实际已被反压“95%”来自每档 40 个合成请求，适合做容量方向判断；正式 SLA 仍需更大样本和真实业务回放。
02 · 吞吐能力
同时处理更多请求，总产出会上升，但单个用户会等更久
怎么理解 token/s？
它是整个服务每秒产出的文本单位，不等于每个用户都能得到这个速度。并发 8 时总体产出最高，但第一个字的尾部等待也从约 5 秒上升到约 25 秒。
因此：默认交互优先控制在约 4 个活跃请求，8 个更适合短时突发。03 · 历史完整并发矩阵
输入变长以后，并发 8 的尾部等待非常明显
全部为历史验收配置：context 12,288、mem 0.50、MRR 8、Decode Graph 4。
| 业务形状 | 并发 | 成功 | 总输出 | 首字 p50 / p95 | 完整耗时 p50 / p95 |
|---|---|---|---|---|---|
| 短 Agent：256→128 | C4 | 20 / 20 | 27.483 tok/s | 4.175 / 4.919 秒 | 18.530 / 19.088 秒 |
| 短 Agent：256→128 | C8 | 40 / 40 | 35.105 tok/s | 6.162 / 25.027 秒 | 21.349 / 42.504 秒 |
| 中等任务：1K→256 | C4 | 20 / 20 | 22.107 tok/s | 16.073 / 18.713 秒 | 46.252 / 46.566 秒 |
| 中等任务：1K→256 | C8 | 40 / 40 | 27.293 tok/s | 24.177 / 68.940 秒 | 54.997 / 109.833 秒 |
C8 是吞吐档，不是最佳交互档。
短请求 C8 比 C4 多产出约 27.7%，但 TTFT p95 从 4.919 秒升到 25.027 秒。1K 输入时，C8 的完整耗时 p95 已接近 110 秒。
04 · 历史调优过程
不是把内存开得越大越快
2026-08-15/16 的验收方案主动降低 context 和内存比例，获得更高吞吐和更低尾延迟。
32K / mem 0.70 / MRR1
9.795 tok/s短 Agent C4 TTFT p95 46.573 秒；spark-8 可用内存仅 13.32 GiB，并有少量 Swap-in。
→
32K / mem 0.70 / MRR4
21.499 tok/s吞吐提高，但 spark-8 可用内存仅 8.19 GiB，并出现 Swap-in/out，不接受为最终配置。
→
12K / mem 0.50 / MRR8
27.483 tok/s同一短 Agent C4 形状；TTFT p95 4.919 秒，三机保留约 48–50 GiB 可用内存。
三轮同时改变了 context、内存比例、最大运行请求和 Graph，数据说明整体收敛结果，不能把增益归因于单一参数。
05 · 长文本上限
模型会读 100 万 token，不代表这套设备能安全处理 100 万
软件标称窗口是模型设计能力；现场上限还受到内存、并发、输出长度和运行时缓存共同约束。
4K稳定通过首字约 29 秒
8K历史通过 / 当前 cap历史首字约 44 秒
12K仅单次可用重复请求触发压力
16K+不安全出现明显内存压力
12,288 是服务器保护窗口，不是可以输入 12K 的承诺。
当前入口继续沿用 8K 保守 cap；8K 的长文本与 NIAH 证据来自历史配置，当前大 KV 配置仍需重新验证。
06 · 四个瓶颈
为什么不是“算力够就一定快”
内存容量
每台 128 GB 由模型、操作系统、缓存和计算过程共同使用。长文本首先把内存余量吃掉。
长文本预读
模型回答前要先“读完”输入。4K 首字约 29 秒、8K 约 44 秒，长文档不适合即时交互。
三段流水线
每个 token 必须经过三台机器。加机器解决了容量，但也增加了跨机通信和串行阶段。
请求排队
超过推荐到达率后，成功率仍可能是 100%，但用户等待已经显著变差；只看“是否成功”会误判容量。
07 · 网络与稳定性
200G 网络不是宣传数字，现场已经测到线速附近
网络解决跨机传输，不等于模型 Token 速度；但没有稳定 RoCE，三机实例无法可靠工作。
双 rail 并发 ib_write_bw
双 rail 并发 ib_write_bw
双 rail 并发 ib_write_bw
12 / 12 预期 rail 双向可达512 MiB × 20 NCCL All-reduce 正确约 235–236 ms 每轮三 rank 平均约 6.4 ppm 已恢复自适应重传
功能和 NET/IB 数据面通过，但恢复性重传意味着尚未达到最严格的“所有扩展计数零增量”网络签署标准。
08 · 官方量化质量
NVFP4 节省容量，官方评测能力基本保持
以下为 NVIDIA 模型卡数据，不是本项目重新跑出的准确率。
箭头左侧为模型卡基线，右侧为 NVFP4。基准接近不代表所有企业任务都无损，仍应使用真实业务集评测。
09 · 正确理解数据
本次测试能证明什么，不能证明什么
历史配置可以证明
- 三机能够稳定加载并真实生成
- mem=0.50 下 8K 长文本与检索通过
- 该配置的 256→128 容量曲线可用
- 历史基础 Function-call 曾通过
不能外推到当前配置
- 当前大 KV 配置具有相同速度和容量
- 当前 Tool-call 已完成回归
- 0.30 req/s 可以长期稳定交互
- 一次 83 分钟混合测试等于长期满载认证
10 · 历史实测摘要
mem=0.50 核心数据表
| 场景 | 成功 | 首字 p95 | 完整耗时 p95 | 判断 |
|---|---|---|---|---|
| 短交互，0.10 req/s | 40 / 40 | 2.91 秒 | 22.55 秒 | 推荐稳态 |
| 短交互，0.20 req/s | 40 / 40 | 8.38 秒 | 31.41 秒 | 允许短队列 |
| 短交互，目标 0.30 req/s | 40 / 40 | 16.43 秒 | 47.59 秒（含客户端排队） | 不作默认 |
| 4K 长输入 | 5 / 5 | 29.18 秒 | 34.09 秒 | 通过 |
| 8K 长输入 | 5 / 5 | 44.37 秒 | 49.31 秒 | 历史通过 / 当前 cap |
| 12K 重复长输入 | 第 2 次停止 | — | — | 不通过 |
本表全部来自 mem=0.50 历史配置。0.30 req/s 的 47.59 秒是从计划到达开始、包含客户端排队的 arrival-to-E2E p95；请求实际发出后的 E2E p95 为 39.002 秒。所有数字均不是当前大 KV 配置或厂商 SLA。