95% 请求在约 3 秒内开始看到回答；完整生成约 23 秒以内。
256 输入 / 128 输出，稳态约 0.10 req/sPerformance · 三机现场实测
能用，但要管理好长文本和排队
短请求的首字等待约 2–3 秒；完整回答通常十几到二十几秒。输入越长、同时使用的人越多，等待会明显上升。
296+正式请求
100%已计入用例成功
83 分钟混合负载观察
0OOM / 重启 / 硬件错误
用户体验
一次请求大概要等多久？
以下是 95% 请求能够达到的体验边界，而不是只展示最好的一次。
首字等待明显变长，完整完成约 31 秒；适合能容忍短队列的后台任务。
256 输入 / 128 输出，约 0.20 req/s客户端已经出现明显排队，完整等待接近 48 秒，不建议作为交互默认。
目标 0.30 req/s，实际已被反压“95%”来自每档 40 个合成请求，适合做容量方向判断；正式 SLA 仍需更大样本和真实业务回放。
吞吐能力
同时处理更多请求，总产出会上升，但单个用户会等更久
怎么理解 token/s？
它是整个服务每秒产出的文本单位，不等于每个用户都能得到这个速度。并发 8 时总体产出最高，但第一个字的尾部等待也从约 5 秒上升到约 25 秒。
因此：默认交互优先控制在约 4 个活跃请求，8 个更适合短时突发。完整并发矩阵
输入变长以后，并发 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 秒。
调优过程
不是把内存开得越大越快
最终方案主动把 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，数据说明整体收敛结果，不能把增益归因于单一参数。
长文本上限
模型会读 100 万 token，不代表这套设备能安全处理 100 万
软件标称窗口是模型设计能力；现场上限还受到内存、并发、输出长度和运行时缓存共同约束。
4K稳定通过首字约 29 秒
8K生产上限首字约 44 秒
12K仅单次可用重复请求触发压力
16K+不安全出现明显内存压力
12,288 是服务器保护窗口，不是可以输入 12K 的承诺。
系统提示词、工具定义、聊天历史、用户内容和模型输出都要共享这一个“行李箱”。入口系统应在 8K 左右开始压缩历史，并为输出和工具调用留空间。
四个瓶颈
为什么不是“算力够就一定快”
内存容量
每台 128 GB 由模型、操作系统、缓存和计算过程共同使用。长文本首先把内存余量吃掉。
长文本预读
模型回答前要先“读完”输入。4K 首字约 29 秒、8K 约 44 秒，长文档不适合即时交互。
三段流水线
每个 token 必须经过三台机器。加机器解决了容量，但也增加了跨机通信和串行阶段。
请求排队
超过推荐到达率后，成功率仍可能是 100%，但用户等待已经显著变差；只看“是否成功”会误判容量。
网络与稳定性
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 数据面通过，但恢复性重传意味着尚未达到最严格的“所有扩展计数零增量”网络签署标准。
量化质量
NVFP4 节省容量，官方评测能力基本保持
以下为 NVIDIA 模型卡数据，不是本项目重新跑出的准确率。
箭头左侧为模型卡基线，右侧为 NVFP4。基准接近不代表所有企业任务都无损，仍应使用真实业务集评测。
正确理解数据
本次测试能证明什么，不能证明什么
可以证明
- 三机能够稳定加载并真实生成
- 8K 内长文本与检索测试通过
- 典型 256→128 请求的容量曲线可用
- 聊天、流式输出和工具调用兼容
不能外推
- 所有真实业务都有相同速度
- 0.30 req/s 可以长期稳定交互
- 12K、16K 或 100 万上下文可生产使用
- 一次 83 分钟混合测试等于长期满载认证
实测摘要
核心数据表
| 场景 | 成功 | 首字 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 秒 | 生产上限 |
| 12K 重复长输入 | 第 2 次停止 | — | — | 不通过 |
tok/s、首字时间和完成时间均为本项目现场实测，不是 NVIDIA 或 DeepSeek 对所有环境的官方承诺。