return_stats模式详解DFlash内置TTFT/TPOT/接受长度统计怎么用【免费下载链接】dflashDFlash: Block Diffusion for Flash Speculative Decoding项目地址: https://gitcode.com/GitHub_Trending/df/dflashDFlash 是一个基于块扩散Block Diffusion的轻量级投机解码加速框架用于让大模型推理更快。它内置了return_stats统计模式开启后无需额外打点即可拿到TTFT首 token 延迟、TPOT单 token 解码耗时和接受长度acceptance length三大核心性能指标是评估 DFlash 加速效果最便捷的内置工具。为什么需要 return_stats做投机解码性能评估时大家最关心的三个问题其实是指标含义为什么重要TTFTTime To First Token首个 token 的延迟决定用户等多久才看到第一个字⚡TPOTTime Per Output Token平均每个 token 的耗时决定打字机速度即吞吐 tok/s 的核心接受长度每个块平均有多少个草稿 token 被目标模型接受投机解码效率的直接度量越高加速越明显传统做法是自己在代码里插表计时、逐块记录容易引入额外开销或统计口径不一致。DFlash 在核心生成函数 dflash_generate 里原生支持return_stats: bool False参数见 model.py一次调用就能拿到全部口径统一的统计结果。一键开启return_stats 的两种返回值调用时只需把return_stats从False改为True# 默认模式只返回 token id 张量 output_ids dflash_generate(model, target..., return_statsFalse) # 统计模式返回包含完整性能指标的对象 stats dflash_generate(model, target..., return_statsTrue)return_statsFalse时直接返回output_ids张量model.pyreturn_statsTrue时返回一个结构化对象包含7 个字段model.py字段类型说明output_idsTensor完整输出含输入 prompt 部分num_input_tokensint输入 prompt 的 token 数num_output_tokensint实际生成的 token 数time_to_first_tokenfloatTTFTprefill 到首个 token 的耗时秒time_per_output_tokenfloatTPOT解码阶段平均每 token 耗时秒acceptance_lengthslist[int]每个块的接受长度逐个块的明细列表 小贴士生成出的纯文本部分 output_ids[0, num_input_tokens:]用 tokenizer 解码即可。三大指标的计算口径细节这是return_stats最值回票价的部分——每个指标的计时口径都经过精心设计避免常见统计陷阱1️⃣ TTFT包含 CUDA 同步的真实首字延迟计时点在 prefill 前后各插一次_cuda_time()model.py。注意它内部会先执行torch.cuda.synchronize()再取时间戳model.py所以测到的是GPU 真正干完活的墙钟时间而不是 CPU 提交异步任务的假时间。2️⃣ TPOT自动剔除首个草稿块的冷启动投机解码的第一个块比较特殊草稿模型还没建好 KV 缓存属于 draft 的 prefill耗时会虚高。DFlash 在这里做了一个巧妙的修正——只有等第一个草稿块完成后才把decode_start重新校准为真正的解码起点model.py。最终 TPOT 纯解码耗时 ÷ 输出 token 数不会因为冷启动而失真。3️⃣ 接受长度逐块记录明细到每个块每个块验证后代码会比较草稿 token 与目标模型后验采样结果用cumprod一次性算出连续匹配长度并记入acceptance_lengths列表model.py。列表中每个值 ≥ 1至少保底接受 1 个 token最大值不超过block_size。这个列表不只是个数字它是分析加速效果的显微镜——既能算平均值还能画分布直方图看稳定性。实战benchmark 里的现成用法 如果你不想自己写调用代码dflash/benchmark.py 已经把return_stats封装成了命令行工具。以 Transformers 后端为例benchmark.py 内部自动开启return_statsTruepython -m dflash.benchmark --backend transformers \ --model Qwen/Qwen3-8B --draft-model z-lab/Qwen3-8B-DFlash-b16 \ --dataset gsm8k --max-samples 128它会同时跑block_size1基线和block_size16DFlash两组然后调用 _print_decode_summary 输出对比报告Baseline throughput: 12.40 tok/s DFlash throughput: 38.75 tok/s Decoding speedup: 3.12 Average Acceptance length: 6.83 Acceptance length histogram: [1.2%, 2.5%, 6.0%, 13.5%, 22.1%, 28.4%, 26.3%]逐行解读Decoding speedup解码阶段相对基线无投机的加速倍数由基线与 DFlash 的平均 TPOT 之比算出Average Acceptance length所有样本所有块的平均接受长度6.83 表示平均每个块 16 个草稿位置里约 6.8 个被接受Acceptance length histogram接受长度的分布占比从 1 到 block_size例如上面表示 26.3% 的块拿到了满分 16 连中。服务端后端vLLM / SGLang的统计如果用 vLLM 或 SGLang 起服务benchmark 走 HTTP 接口统计来自服务端返回的元信息benchmark.pySGLang 的meta_info中会带spec_accept_length和spec_verify_ct验证轮数报告里以Accept length和Spec verify ct两行输出。MLX 后端的流式响应中也内置了每块的accepted字段model_mlx.py。新手避坑指南如何看懂你的统计数据 ✅1. 接受长度接近 1说明草稿质量差如果直方图集中在左侧1~2说明草稿模型与目标模型匹配度低加速会很有限。可以检查draft 模型是否来自官方配套的 DFlash 系列每个目标模型有专属草稿模型temperature是否过高随机采样越剧烈草稿命中率越低。2. TTFT 升高是正常的DFlash 需要目标模型额外输出hidden_states供草稿模型使用model.pyprefill 开销略高于原生推理。只要 TPOT 的降幅覆盖这部分开销整体吞吐依然是赚的——这也是 benchmark 单独对比解码加速倍数而非总时延的原因。3. 想要更细的逐块分析acceptance_lengths是逐块列表你可以直接用它算方差、P50/P99 分位数或者按输出位置切片看上下文越长接受率是否衰减。多卡跑分布式 benchmark 时各 rank 的统计会自动 gather 到主进程汇总benchmark.py。总结需求怎么做代码里拿 TTFT/TPOT/接受长度dflash_generate(..., return_statsTrue)读 7 字段对象命令行一键出加速报告python -m dflash.benchmark --backend transformers ...分析草稿命中质量看acceptance_lengths的均值与直方图分布服务端统计vLLM/SGLang 响应元信息中的spec_accept_lengthreturn_stats用一行参数的成本换来了口径统一、CUDA 同步可靠、自动剔除冷启动干扰的完整性能画像。无论是写加速效果报告还是调优block_size与temperature它都是 DFlash 性能分析的第一站。【免费下载链接】dflashDFlash: Block Diffusion for Flash Speculative Decoding项目地址: https://gitcode.com/GitHub_Trending/df/dflash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 return_stats模式详解：DFlash内置TTFT/TPOT/接受长度统计怎么用
return_stats模式详解DFlash内置TTFT/TPOT/接受长度统计怎么用【免费下载链接】dflashDFlash: Block Diffusion for Flash Speculative Decoding项目地址: https://gitcode.com/GitHub_Trending/df/dflashDFlash 是一个基于块扩散Block Diffusion的轻量级投机解码加速框架用于让大模型推理更快。它内置了return_stats统计模式开启后无需额外打点即可拿到TTFT首 token 延迟、TPOT单 token 解码耗时和接受长度acceptance length三大核心性能指标是评估 DFlash 加速效果最便捷的内置工具。为什么需要 return_stats做投机解码性能评估时大家最关心的三个问题其实是指标含义为什么重要TTFTTime To First Token首个 token 的延迟决定用户等多久才看到第一个字⚡TPOTTime Per Output Token平均每个 token 的耗时决定打字机速度即吞吐 tok/s 的核心接受长度每个块平均有多少个草稿 token 被目标模型接受投机解码效率的直接度量越高加速越明显传统做法是自己在代码里插表计时、逐块记录容易引入额外开销或统计口径不一致。DFlash 在核心生成函数 dflash_generate 里原生支持return_stats: bool False参数见 model.py一次调用就能拿到全部口径统一的统计结果。一键开启return_stats 的两种返回值调用时只需把return_stats从False改为True# 默认模式只返回 token id 张量 output_ids dflash_generate(model, target..., return_statsFalse) # 统计模式返回包含完整性能指标的对象 stats dflash_generate(model, target..., return_statsTrue)return_statsFalse时直接返回output_ids张量model.pyreturn_statsTrue时返回一个结构化对象包含7 个字段model.py字段类型说明output_idsTensor完整输出含输入 prompt 部分num_input_tokensint输入 prompt 的 token 数num_output_tokensint实际生成的 token 数time_to_first_tokenfloatTTFTprefill 到首个 token 的耗时秒time_per_output_tokenfloatTPOT解码阶段平均每 token 耗时秒acceptance_lengthslist[int]每个块的接受长度逐个块的明细列表 小贴士生成出的纯文本部分 output_ids[0, num_input_tokens:]用 tokenizer 解码即可。三大指标的计算口径细节这是return_stats最值回票价的部分——每个指标的计时口径都经过精心设计避免常见统计陷阱1️⃣ TTFT包含 CUDA 同步的真实首字延迟计时点在 prefill 前后各插一次_cuda_time()model.py。注意它内部会先执行torch.cuda.synchronize()再取时间戳model.py所以测到的是GPU 真正干完活的墙钟时间而不是 CPU 提交异步任务的假时间。2️⃣ TPOT自动剔除首个草稿块的冷启动投机解码的第一个块比较特殊草稿模型还没建好 KV 缓存属于 draft 的 prefill耗时会虚高。DFlash 在这里做了一个巧妙的修正——只有等第一个草稿块完成后才把decode_start重新校准为真正的解码起点model.py。最终 TPOT 纯解码耗时 ÷ 输出 token 数不会因为冷启动而失真。3️⃣ 接受长度逐块记录明细到每个块每个块验证后代码会比较草稿 token 与目标模型后验采样结果用cumprod一次性算出连续匹配长度并记入acceptance_lengths列表model.py。列表中每个值 ≥ 1至少保底接受 1 个 token最大值不超过block_size。这个列表不只是个数字它是分析加速效果的显微镜——既能算平均值还能画分布直方图看稳定性。实战benchmark 里的现成用法 如果你不想自己写调用代码dflash/benchmark.py 已经把return_stats封装成了命令行工具。以 Transformers 后端为例benchmark.py 内部自动开启return_statsTruepython -m dflash.benchmark --backend transformers \ --model Qwen/Qwen3-8B --draft-model z-lab/Qwen3-8B-DFlash-b16 \ --dataset gsm8k --max-samples 128它会同时跑block_size1基线和block_size16DFlash两组然后调用 _print_decode_summary 输出对比报告Baseline throughput: 12.40 tok/s DFlash throughput: 38.75 tok/s Decoding speedup: 3.12 Average Acceptance length: 6.83 Acceptance length histogram: [1.2%, 2.5%, 6.0%, 13.5%, 22.1%, 28.4%, 26.3%]逐行解读Decoding speedup解码阶段相对基线无投机的加速倍数由基线与 DFlash 的平均 TPOT 之比算出Average Acceptance length所有样本所有块的平均接受长度6.83 表示平均每个块 16 个草稿位置里约 6.8 个被接受Acceptance length histogram接受长度的分布占比从 1 到 block_size例如上面表示 26.3% 的块拿到了满分 16 连中。服务端后端vLLM / SGLang的统计如果用 vLLM 或 SGLang 起服务benchmark 走 HTTP 接口统计来自服务端返回的元信息benchmark.pySGLang 的meta_info中会带spec_accept_length和spec_verify_ct验证轮数报告里以Accept length和Spec verify ct两行输出。MLX 后端的流式响应中也内置了每块的accepted字段model_mlx.py。新手避坑指南如何看懂你的统计数据 ✅1. 接受长度接近 1说明草稿质量差如果直方图集中在左侧1~2说明草稿模型与目标模型匹配度低加速会很有限。可以检查draft 模型是否来自官方配套的 DFlash 系列每个目标模型有专属草稿模型temperature是否过高随机采样越剧烈草稿命中率越低。2. TTFT 升高是正常的DFlash 需要目标模型额外输出hidden_states供草稿模型使用model.pyprefill 开销略高于原生推理。只要 TPOT 的降幅覆盖这部分开销整体吞吐依然是赚的——这也是 benchmark 单独对比解码加速倍数而非总时延的原因。3. 想要更细的逐块分析acceptance_lengths是逐块列表你可以直接用它算方差、P50/P99 分位数或者按输出位置切片看上下文越长接受率是否衰减。多卡跑分布式 benchmark 时各 rank 的统计会自动 gather 到主进程汇总benchmark.py。总结需求怎么做代码里拿 TTFT/TPOT/接受长度dflash_generate(..., return_statsTrue)读 7 字段对象命令行一键出加速报告python -m dflash.benchmark --backend transformers ...分析草稿命中质量看acceptance_lengths的均值与直方图分布服务端统计vLLM/SGLang 响应元信息中的spec_accept_lengthreturn_stats用一行参数的成本换来了口径统一、CUDA 同步可靠、自动剔除冷启动干扰的完整性能画像。无论是写加速效果报告还是调优block_size与temperature它都是 DFlash 性能分析的第一站。【免费下载链接】dflashDFlash: Block Diffusion for Flash Speculative Decoding项目地址: https://gitcode.com/GitHub_Trending/df/dflash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考