长上下文压测与 PD 配比：从单请求日志到容量实验

范围与问题起点

北京时间 2026-09-18：希望测试 128K/256K/512K 输入、1K输出、约99%前缀命中下的 PD 配比；随后实际提供了较短输出的性能结果。测试目标和已经完成的结果必须分开。

已取得的实测证据

原始文件「粘贴的文本 (1)(1).txt」（2026-09-18，414行）可直接核对1K和32K；128K来自用户当天19:52的结果反馈，本次未取得对应原始日志。

共同设置：EvalScope random、parallel=1、number=3、prefix-length=0、输出256、ignore_eos=true、stream=true、warmup_num=0。实际请求URL为 http://127.0.0.1:8300/v1/chat/completions；配置打印中的port=8877不能替代明确的目标URL，旧检索摘要“服务端口8877”不采纳。

表内解码速率约为1000/TPOT毫秒；客户端输出吞吐还计入首token前的等待，因此不能混用。近似关系：端到端时延 ≈ TTFT + (输出token数−1)×TPOT。128K教学复算为36.47 + 255×0.0279 ≈ 43.58秒，与反馈一致。

结论限定于本次小样本：输入增长时TTFT上升显著，decode每token耗时相对稳定。TTFT含排队、Prefill、传输及调度，不能把全部36.47秒直接认定为纯Prefill算子耗时。三个请求的p99不能代表稳定尾延迟。

prefix-length=0代表没有人为指定共享前缀，不证明服务端缓存功能关闭。32K日志报告cached prompt throughput为0，仅说明这一报告口径下未记录命中；需结合服务端计数确认。random不是自然语言质量评测，不能据此判断长上下文理解能力。

PD 配比怎么从测量得到

先验证请求实际走过 P→KV传输→D，而不是直连混部端点。保存两端日志、模型revision、量化元数据、并行组、KV connector和路由配置。

在固定输入/输出分布下，测每个P实例和D实例的可持续请求服务率 μP、μD。教学容量模型：λ上限约为min(nP×μP,nD×μD,传输瓶颈容量)，故平衡时nP/nD约为μD/μP。该式假设相同服务单位且阶段容量可近似独立；动态batch、EP同步和缓存会改变结果，最终必须端到端复测。

实验矩阵分三层：

1. 正确性：短prompt、长prompt、重复前缀与不同后缀均校验无串扰。
2. 冷缓存：不同输入长度，先固定输出和并发，再逐步增加并发/到达率。
3. 热缓存：先预热共享前缀，再用不同后缀发请求，测实际命中率；报告预热成本和热态结果。

“99%前缀+1K后缀”不能在所有长度上同时成立：128K输入加1K新内容约99.2%共享；256K和512K对应更高比例。应明确是固定新后缀长度，还是固定命中比例，并考虑缓存块粒度。

每档保存完成QPS、错误率、TTFT/TPOT分位数、P/D队列、KV传输时间、实际缓存命中、设备内存峰值。发送QPS、完成QPS和并发是三个量。提高并发后的收益与尾延迟共同决定可用容量。

性能和长上下文质量分开验收

GSM8K等题目可以测试任务质量，却不是长上下文PD配比的天然性能负载。性能测试使用可控长度并保留真实业务回放；200K/300K质量问题需另做位置变化的检索、多跳推理和真实任务评估。模型声明支持某长度，不等于所有位置和任务都有相同质量。

当前没有取得256K/512K→1K完整矩阵，也没有可证明最佳P:D比例的结果。用户周报说PD性能较差、瓶颈待定位，不能写成部署性能已验收。

可复用资料

EvalScope 官方压力测试说明（核查2026-09-20）；具体CLI参数按本机版本的help和解析后配置固定。

DP2、TP8 与 MoE EP：两节点部署为何不一定是两份独立模型；GLM-5.3-Flash 精度异常复盘：从 GPQA 反馈到分层定位。