05 · 基准测试与复现测量口径与数据可信度仓库https://gitee.com/kill-life/glm5.3-flash-cybersec-sm80-vllm-deploy.git本篇说明性能数字是如何测得、如何复现的先给出基准测试工具与各自的适用场景再区分两个容易混淆的吞吐口径随后列出六条测量准则及其对应的失败案例最后给出双来源交叉校验方法、原始记录解读方式以及约一小时的复现流程与容差判定标准。概览精简修订版严谨、句式紧凑保留全部技术信息同配置单晚读数波动区间182–249 tok/s核心影响因素为温度参数。六项测量规范温度归零、≥256 token稳态窗口、满窗口预热、机器独占、长上下文三连测、样本级截断与空正文扫描均存在带具体数值的实测反例。并发日志包含两类吞吐指标agg_decode_tok_per_s为稳态解码窗口聚合速率agg_total_tok_per_s为包含prefill的端到端速率。128k × 8路日志中端到端指标显示6293 tok/s但稳态窗口实际仅解码177个token混淆两类口径将得出完全相反结论。复现协议已纳入双源交叉校验第三独立数据源①客户端流式口径输出token总数/ITL总和、②墙钟反推口径总量减去TTFT、③引擎上报metrics.speculative_decoding。客户端口径6.40引擎口径6.425差值≤0.4%判定一致超出则优先核查测量口径。全部结论可溯源原始数据bench/results/下4份JSONL文件含200余条带标签、上下文信息的原始记录。README表格由bench/render_tables.py自动生成--check模式检测到表格与原始记录不一致时直接报错文档内容由程序自动校验非人工维护。完整复现耗时约1小时分为环境检查、页缓存预热、服务启动、生产准入校验、基准测试套件运行五步与docs/REPRODUCING.md容差判定表一一对应偏差超限的排查方法与佐证材料已准备就绪。1. 基准测试工具与适用场景基准测试的第一条原则是所有测量脚本都在容器内运行整套测试工具已挂载到/work。理由同一份压测脚本在容器内外运行仅网络路径的差异就足以造成 3% 的读数偏差而 3% 正是多个判定标准的门槛。工具适用场景关键口径bench.pysingle 与 concur单流速率、并发曲线、长上下文检索测试needle test输出顶满上限、强制--ask每个请求可指定effort与temperaturebattery.shA/B 对照的固定五档修改参数后必须使用一轮约 3 分钟内置两轮满窗口预热档位为 single 2k 与 32k、concur 8 与 32、128k 首 tokenrun_suite.sh完整测试套件六个阶段约 15 分钟包含真实的 1M 上下文档位prod_gate.py生产准入检查四项关键一项28 至 32K prompt 加至少 100 输出 token 的深度解码20K 的检查点位于触发阈值之下无法证明任何问题topology_probe.py通信微基准测试第 03 篇的 39 微秒与 30.6 GB/s 由此测得render_tables.py由 JSONL 生成 README 表格--check模式用于校验表格与原始记录是否一致prod_gate 的四项检查并非随意设定而是沿用同家族模型在另一代硬件上的崩溃分析结论判断服务是否真正可用需要同时验证以下四点越过 24K 触发阈值的深度解码三路 20K 并发 prefill 的瞬时显存压力重复深度解码KV 池被使用后的状态复现/health接口返回 200每项判据旁边都写有依据脚本自身即包含必要的背景说明。2. 易混淆的两个吞吐口径TTFT 与 Throughput并发记录中首先需要区分两个吞吐字段。agg_decode_tok_per_s表示稳态解码窗口内的聚合速率窗口从最早的首 token 开始到最后一个 token 结束窗口内的 token 数等于总输出减去请求数每路的首 token 计入 TTFTtime to first token不重复计入。agg_total_tok_per_s则是端到端吞吐即prompt 加 output除以墙钟时间在长上下文场景中它主要反映 prefill 吞吐。两个口径的差异不是文字游戏下面的数值可以直接说明Prefill 阶段等待时间很长128k、8 路时 p50 达 102.2 秒Decode 阶段持续产出 token只有这一段计入稳态窗口的产出口径对照窗口内实际 decode 的 token 只有 177 个而端到端读数高达 6,293相差约 35 倍差异全部来自口径选择公式层面bench.py 的并发打分骨架可用四行伪代码表示变量名取自源码本意windowwall_clock 减去 各路最小的 TTFT ——从最早开始的那一路算起 unitsum(输出 token)减去 请求数 ——每路首 token 计入 TTFT不重复计入 decodeunit 除以 window ——稳态解码口径 total(prompt 加 output 总和)除以 墙钟 ——端到端口径长上下文时由 prefill 主导还有一组值得记录的读数并发从 1 提高到 2 时聚合速率不升反降从 112.4 降到 91.8 tok/s从 2 提高到 4 才回升到 165.5 tok/s。原因与 MoE 的门控机制有关两条序列若路由到不同的专家W4A16 的 Marlin 内核每步需要读取接近两倍的专家权重单步耗时从 17.5 毫秒量级上升到 43 毫秒量级。这不是缺陷而是 MoE 架构决定的成本。3. 六条测量准则与对应的失败案例以下六条测量准则均对应真实实测失败案例而非形式化检查清单各准则的实测现象、成因与纠正措施如下#准则实测现象原因与纠正措施一temperature 强制设为 0服务端默认采样温度为 0.3同一配置 32k 档读数在 182–249 tok/s 间波动MTP 接受长度逐轮不同清空采样参数、退回权重默认值 1.0 时波动进一步扩大显式传入--temperature 0确保每次测量均携带该参数二输出顶满 256 token 稳态窗口默认检索型请求仅十几个 token 即结束SSE 分块导致 63 被误读为 106另有 3 条记录已废弃仅作历史数据留存通过--ask强制长输出或显式设置输出上限为 256三预热且覆盖完整窗口首个请求触发 JIT 编译首档速率从 11 tok/s 降至 52深度提升后预热 32 个输出 token 仍无法抹平差异三次复测结果为 207–217保留battery.sh内置的两轮满窗口预热机制不得删减四测量期间独占机器邻实例加载权重时单 worker 占用 12 核以上8 进程可占满 112 核本机步时从 19.6 ms 升至 78 ms差异约 4 倍先用nvidia-smi自查资源与同机其他使用者约定错峰运行五长上下文结论需连测三次1M 首 token 因单次 417 秒的离群读数被误判为“慢三成四”三次复测确认长期值为 312 秒三次复测为必要步骤非可选项六逐样本检查截断与空正文不唯均值论330 格采样中 6 格触发 4400 token 输出上限其中 1 格正文完全为空预算被思考链耗尽该格事实命中为 0将单档均值从 0.983 拉低至 0.917导出错误结论上限提至 7000 重测后该档均值回到 1.000原结论不成立输出预算为「思考正文」共享思考型模型易耗尽预算跑完先检查finish_reasonlength与空正文计数bench/sampling_sweep.py已内置该告警六条准则说明前五条来自性能测量实践唯有准则六由本套件自身的结论纠错反推得出——单个空正文样本即可导致整档参数误判。其普适性结论为均值不能替代逐样本检查尤其当失败样本为极值时空正文命中率恒为 0恰好是分布的下界。准则四补充说明8 个加载进程占满 112 核只是问题的一部分。并发加载会同时破坏「双实例对照」的两个前提对照组与实验组均处于不稳定状态测得的差异无法归因。仓库通过实验驱动器的文件锁机制应对加载权重时持有独占锁测量时持有共享锁保证同一时刻仅一个实例执行对应操作。该机制虽看似繁琐但已在实际使用中两次避免数据污染。4. 三来源交叉校验机制本套件已将三来源交叉校验写入复现协议读数接近时须通过独立来源交叉验证不依赖单一脚本来源A客户端流式测量累计输出token数除以流内间隔之和天然排除首token等待时间直接近似流式观感速率。来源B墙钟反推输出token数除以总时长-首token时间为客户端流式的独立第二来源实测与来源A偏差小于1%。来源C引擎自报指标响应体中metrics.speculative_decoding由SPEC_DECODE_METRICSsummary开启与前两者相互独立包含接受长度、草稿命中率、每步分布三类指标。三者不一致时按固定顺序排查先确认口径是否对应同一窗口稳态窗口/端到端再检查首token是否按每路一次扣除最后排查物理层问题。引擎与客户端间0.4%的残差来自记账口径保底校正项为固定系统偏差非故障。5. 结果记录解读bench/results/下4份基线JSONL文件各司其职MTP深度6定版口径、调优全量记录、部署形态二TP4×PP1的1M与并发prefill历史记录、三卡配置时期基线。单条原始记录示例{label:decode_2048_r1,effort:low,prompt_tokens:1862,output_tokens:256,ttft_s:0.382,steps:41,step_ms:25.57,accept_len:6.24,decode_s:1.02,output_tok_per_s:250.27,needle_code:831EAF2F}核心字段含义字段含义accept_len 6.24单解码步平均净增约5.24 token接受长度6.24减1step_ms 25.57MTP深度6下单步耗时与理论值25.66 ms基本吻合steps 41该请求引擎总步数accept_len输出token数÷步数256÷416.24output_tok_per_s 250.272k高可预测文本档单流速率普通散文结果单独统计needle_code随机ORACLE校验码用于确认长上下文响应来源answer_head输出前数十字符切片用于人工校验输出有效性几组代表性读数1M首token三次复测311.8~312.6 秒128k八路并发端到端两次复测6292、6293 tok/s该口径由prefill主导普通散文场景85~91 tok/s32路并发稳态窗口聚合速率683.1 tok/s所有超出容差的记录均附专门解释越界场景配套后续处理指引。5.1 分位读数说明p50与p90并发记录除聚合速率外还包含单路输出速率分布、首token p50/p90分位数两组数据分布数据反映并发提升后单路速率的衰减程度分位数反映prefill排队时间的中位与高位差异。两个核心读数逻辑排队公平性p90/p50比值越接近1各请求等待时间越均衡比值严重失衡时尾部请求承受数倍等待表现为偶发卡顿而非平均速率下降排查方向不同。对照阅读原则聚合值受长尾拉伸分布值反映单请求真实表现二者缺一易遗漏问题。记录旁注「看公平性并发拉高后单流掉多少」是将该读法写入元数据的实践。6. 一小时复现流程与容差判定完整复现共五步含服务启动总耗时约60分钟可将预热与测试准备并行以压缩时长./setup.sh--check# 0分钟只读环境检查./warm_cache.sh# 3分钟页缓存已热则立即返回./serve.sh./wait_ready.sh# 合计约6分钟含一次启动makegate# 四项准入检查全部通过后方可继续cdbench./battery.sh repro# 运行一轮复现基准测试并写入结果测得数据需与docs/REPRODUCING.md容差判定表比对摘录示例如下指标基准值容差越界优先排查项单流2k250.3、256.1±5%temperature设置、预热是否充分32路并发窗口聚合683.1±10%32路是否跑满、同机是否有其他实例加载权重1M首token312 秒±10%必须连续测三次单次读数无效差异报告需满足标准流程提交环境指纹原文、复现命令原文、原始记录、差异最大档位的引擎日志、机器独占性说明五项齐全才予受理。仅报速率值、无口径/环境/原始数据的报告无法处理。6.1 复现失败需提交的五项材料docs/REPRODUCING.md规定复现失败需提交五项材料从问题定位角度各有不可替代的作用共同支撑完整归因环境指纹原文对比环境差异复现命令原文还原操作过程原始记录测量一手数据异常档位日志还原故障前后引擎状态独占性证明排除同机任务干扰五项齐全后差异方可准确归因优先级按排列顺序递减缺少环境指纹则差异无法归因缺少复现命令则复现无法开展缺少原始记录则读数无依据缺少日志则故障过程无法还原缺少独占性证明则计时结果可能受干扰。将该图与容差表配合使用可显著提升问题报告质量。7. 数据记录规范标签四级命名按「实验-配置-档位-轮次」命名标签自解释字符串支持多年后检索仍可还原完整实验过程。双轮记录原则同一配置至少两轮同日数据推翻已有结论必须有第三个独立数据点支撑。保留历史异常历史疑点数据连同原因一并留存如预热假象期的低接受长度记录数据会过时但缺失记录会引发新问题。表格程序生成README表格仅可由原始数据通过公式生成手工修改生成区会触发lint报错以程序校验替代人工维护每次检查自动执行。最终结论以数据为核心复现基准测试完成后将结果首行附于评审中所有测量准则与记录规范的价值即会体现——结论直接由数据支撑无需额外解释。