尧图网站建设 
真机实测通过本文实验已在 RK3588 板端实测完成2026-09方法学与原始记录见仓库 docs 与《实验脚本》目录一句话导读复现 13.1×跨进程恢复实测怎么做——把 S1 全量落盘、杀进程、S2 恢复的每一步命令与每一行日志摆出来并拆清同一个实验为什么 prefill、TTFT、wall 三个口径报出三个数字。仓库基准报告写了“8K 跨进程恢复13.1×”。今天不背书把复现步骤与每一行日志摆出来并且把两个口径拆清楚为什么同一个实验prefill 口径 ≈23.6×、而请求总耗时wall口径只有 ≈7.1×因为口径不同数字本来就不同——这是 Day 28 性能方法论的一课预演。1. 知识点三个口径三个数字跨进程恢复实验能报出至少三个加速比别混着说prefill 口径只比“prefill 这段”——全量 46.37s vs 恢复后 1.96s →23.6×。这是引擎真正省下的“算”首 tokenTTFT口径从请求到达算到第一个 token 吐出。恢复路径要先把 ~0.47 GB 快照从 eMMC 读进内存TTFT 比纯 prefill 大wall整请求口径两端都含 decode。decode 在恢复与全量两条路径上一样贵都要在完整上下文上逐词生成所以 wall 加速比一定小于 prefill 加速比。基准报告的 13.1× 用的是TTFT 口径202s → 15.4s8K 档——注意它两端都含“调度首词”且恢复端含 1.87 GB 读盘。引用时永远带上口径这就是“报告口径先行”的第一课。2. 对应代码复现的完整命令序列板端实测模板环境RK3588 / Qwen3-VL-2B /build-rk3588/vllm_kestrel。# —— S1启动全量 turn1落盘 —— ./vllm_kestrel --serve --port 18099 --model /mnt/emmc/Modl/Qwen3-VL-2B-Instruct \ --load-format vqf --auto-load --disk-kv /mnt/emmc/day12_kv \ s1.log 21 # 发长 prompt12-1 的 P1→ s1.log 应出现 # [PREFILL-TIMING] n2044 total46373.1ms | GEMM... ATTN... # [KV-DISK] saved 2056-token KV - /mnt/emmc/day12_kv/kv_a0db3b0aa6b59cb8.kv # [KV-DISK] index: 1 checkpoint(s) in /mnt/emmc/day12_kv kill %1 # ← 杀掉 S1模拟服务重启 # —— S2重启发“历史追问” —— ./vllm_kestrel --serve --port 18099 --model /mnt/emmc/Modl/Qwen3-VL-2B-Instruct \ --load-format vqf --auto-load --disk-kv /mnt/emmc/day12_kv \ s2.log 21 # 发 P2P1 上轮回答 追问→ s2.log 应出现 # [KV-DISK] index: 1 checkpoint(s) in /mnt/emmc/day12_kv ← 启动即建索引 # [KV-DISK] loaded 2034-token KV prefix from kv_a0db...cb8.kv ← 命中 # [PREFILL-TIMING] n31 total1962.2ms ← 只算增量板端实测结果汇总2026-09进程串行口径S1全量S2恢复加速比prefill 时间46.37 sn20441.96 sn31≈23.6×请求总耗时wall含 decode 与读盘51.34 s7.27 s≈7.1×把 13.1× 与上表对齐报告的 13.1× 是 8K 档 TTFT 口径201.7s→15.4s。8K 全量 prefill 占 TTFT 的绝对大头恢复端 TTFT 几乎全被“1.87 GB 读盘 34 token 增量 decode 首词”吃掉——所以它介于 prefill 口径与 wall 口径之间、更接近“真首 token 体验”。用你自己的板子复现时先声明口径再报数字。复现要点都是从翻车里学来的纪律同参启动S2 的 wmode/线程/--disk-kv目录必须与 S1 一致几何写进快照头不一致会拒载目录要干净S1 前先清空 kv 目录否则旧快照可能被 LCP 命中数字就不是“这一个会话”的串行无并发任何后台负载都会污染计时Day 7 的抖动纪律先 warm第一轮请求会触发权重 mmap 触页Day 11-3 的 RSS 实验929 MB正式对照前先发一次短请求热身。3. 改动后果把--disk-kv拿掉重启后就回到原始社会对照实验把 S1/S2 里的--disk-kv去掉其余全同板端实测S2 启动后目录无索引日志无index: N checkpoint(s)P2 请求的 LCP 只能对上进程内的上一轮——而进程是新的last_ids为空 →keep0→ 全量重算实测[PREFILL-TIMING] n2065 total48205.2ms请求总耗时 52.55s与恢复路径同请求的 n31 / 1.96 s 形成对照。配置同一 P2 请求文本prefill请求总耗时[KV-DISK]带--disk-kv恢复n31 /1.96 s7.27 sloaded 2034-token KV prefix不带--disk-kv对照n2065 /48.21 s52.55 s0 行全量重算prefill 口径≈24.6×、wall 口径 ≈7.2×且两条路径输出逐字节一致都是Bob lives in Tokyo.。这组对照把 12-1 的结论钉死跨进程恢复的收益 100% 来自--disk-kv与“进程内前缀复用”无关进程内复用只对同进程连发有效重启即失效。4. 学员调试任务A 档板端动手按第 2 节模板完整复现一轮S1 全量 → kill → S2 恢复抄出四条日志saved / index / loaded / PREFILL-TIMING填出你自己的三个口径加速比并标注用的是哪个口径。有条件的再跑一次 4K 档看加速比随上下文比例怎么变。B 档纯读源码把 12-1/12-2 的锚点串起来回答① 恢复路径的 TTFT 由哪几段组成提示读盘、增量 prefill、decode 首词、调度② 为什么“目录不干净”会污染 LCP 命中③DISKKV_MAX_TOKENS8192对 8K 会话意味着什么提示快照按 8192 钳制超长会话怎么处理预期输出你能脱离文档用四行日志向别人演示“进程杀了会话没断”并说清自己报的是 prefill / TTFT / wall 哪个口径。收尾本篇源码点名vllm_server.csave 620、index 560、命中 1308–1317、LRU 648、vllm_safetensors.csave/load、RK3588_性能基准报告.md§3.2。开源仓库Kestrel-LLM (Gitee)源码可得双许可学习 / 学术研究免费下篇预告单请求已经很快可 decode 逐词生成仍是“等一个、算一个”。Day 13 上推测解码--spec让模型“赌”几个候选词一起验证——但 2B 本地 decode 才 ~120ms/词verify 的账怎么算才划算关键词跨进程恢复、实测复现、性能口径、磁盘 KV上一篇Day 12·2 磁盘KV快照格式0.47GB从哪来下一篇待更新...... Day 12·3 实测13.1倍加速：跨进程恢复完整复盘
真机实测通过本文实验已在 RK3588 板端实测完成2026-09方法学与原始记录见仓库 docs 与《实验脚本》目录一句话导读复现 13.1×跨进程恢复实测怎么做——把 S1 全量落盘、杀进程、S2 恢复的每一步命令与每一行日志摆出来并拆清同一个实验为什么 prefill、TTFT、wall 三个口径报出三个数字。仓库基准报告写了“8K 跨进程恢复13.1×”。今天不背书把复现步骤与每一行日志摆出来并且把两个口径拆清楚为什么同一个实验prefill 口径 ≈23.6×、而请求总耗时wall口径只有 ≈7.1×因为口径不同数字本来就不同——这是 Day 28 性能方法论的一课预演。1. 知识点三个口径三个数字跨进程恢复实验能报出至少三个加速比别混着说prefill 口径只比“prefill 这段”——全量 46.37s vs 恢复后 1.96s →23.6×。这是引擎真正省下的“算”首 tokenTTFT口径从请求到达算到第一个 token 吐出。恢复路径要先把 ~0.47 GB 快照从 eMMC 读进内存TTFT 比纯 prefill 大wall整请求口径两端都含 decode。decode 在恢复与全量两条路径上一样贵都要在完整上下文上逐词生成所以 wall 加速比一定小于 prefill 加速比。基准报告的 13.1× 用的是TTFT 口径202s → 15.4s8K 档——注意它两端都含“调度首词”且恢复端含 1.87 GB 读盘。引用时永远带上口径这就是“报告口径先行”的第一课。2. 对应代码复现的完整命令序列板端实测模板环境RK3588 / Qwen3-VL-2B /build-rk3588/vllm_kestrel。# —— S1启动全量 turn1落盘 —— ./vllm_kestrel --serve --port 18099 --model /mnt/emmc/Modl/Qwen3-VL-2B-Instruct \ --load-format vqf --auto-load --disk-kv /mnt/emmc/day12_kv \ s1.log 21 # 发长 prompt12-1 的 P1→ s1.log 应出现 # [PREFILL-TIMING] n2044 total46373.1ms | GEMM... ATTN... # [KV-DISK] saved 2056-token KV - /mnt/emmc/day12_kv/kv_a0db3b0aa6b59cb8.kv # [KV-DISK] index: 1 checkpoint(s) in /mnt/emmc/day12_kv kill %1 # ← 杀掉 S1模拟服务重启 # —— S2重启发“历史追问” —— ./vllm_kestrel --serve --port 18099 --model /mnt/emmc/Modl/Qwen3-VL-2B-Instruct \ --load-format vqf --auto-load --disk-kv /mnt/emmc/day12_kv \ s2.log 21 # 发 P2P1 上轮回答 追问→ s2.log 应出现 # [KV-DISK] index: 1 checkpoint(s) in /mnt/emmc/day12_kv ← 启动即建索引 # [KV-DISK] loaded 2034-token KV prefix from kv_a0db...cb8.kv ← 命中 # [PREFILL-TIMING] n31 total1962.2ms ← 只算增量板端实测结果汇总2026-09进程串行口径S1全量S2恢复加速比prefill 时间46.37 sn20441.96 sn31≈23.6×请求总耗时wall含 decode 与读盘51.34 s7.27 s≈7.1×把 13.1× 与上表对齐报告的 13.1× 是 8K 档 TTFT 口径201.7s→15.4s。8K 全量 prefill 占 TTFT 的绝对大头恢复端 TTFT 几乎全被“1.87 GB 读盘 34 token 增量 decode 首词”吃掉——所以它介于 prefill 口径与 wall 口径之间、更接近“真首 token 体验”。用你自己的板子复现时先声明口径再报数字。复现要点都是从翻车里学来的纪律同参启动S2 的 wmode/线程/--disk-kv目录必须与 S1 一致几何写进快照头不一致会拒载目录要干净S1 前先清空 kv 目录否则旧快照可能被 LCP 命中数字就不是“这一个会话”的串行无并发任何后台负载都会污染计时Day 7 的抖动纪律先 warm第一轮请求会触发权重 mmap 触页Day 11-3 的 RSS 实验929 MB正式对照前先发一次短请求热身。3. 改动后果把--disk-kv拿掉重启后就回到原始社会对照实验把 S1/S2 里的--disk-kv去掉其余全同板端实测S2 启动后目录无索引日志无index: N checkpoint(s)P2 请求的 LCP 只能对上进程内的上一轮——而进程是新的last_ids为空 →keep0→ 全量重算实测[PREFILL-TIMING] n2065 total48205.2ms请求总耗时 52.55s与恢复路径同请求的 n31 / 1.96 s 形成对照。配置同一 P2 请求文本prefill请求总耗时[KV-DISK]带--disk-kv恢复n31 /1.96 s7.27 sloaded 2034-token KV prefix不带--disk-kv对照n2065 /48.21 s52.55 s0 行全量重算prefill 口径≈24.6×、wall 口径 ≈7.2×且两条路径输出逐字节一致都是Bob lives in Tokyo.。这组对照把 12-1 的结论钉死跨进程恢复的收益 100% 来自--disk-kv与“进程内前缀复用”无关进程内复用只对同进程连发有效重启即失效。4. 学员调试任务A 档板端动手按第 2 节模板完整复现一轮S1 全量 → kill → S2 恢复抄出四条日志saved / index / loaded / PREFILL-TIMING填出你自己的三个口径加速比并标注用的是哪个口径。有条件的再跑一次 4K 档看加速比随上下文比例怎么变。B 档纯读源码把 12-1/12-2 的锚点串起来回答① 恢复路径的 TTFT 由哪几段组成提示读盘、增量 prefill、decode 首词、调度② 为什么“目录不干净”会污染 LCP 命中③DISKKV_MAX_TOKENS8192对 8K 会话意味着什么提示快照按 8192 钳制超长会话怎么处理预期输出你能脱离文档用四行日志向别人演示“进程杀了会话没断”并说清自己报的是 prefill / TTFT / wall 哪个口径。收尾本篇源码点名vllm_server.csave 620、index 560、命中 1308–1317、LRU 648、vllm_safetensors.csave/load、RK3588_性能基准报告.md§3.2。开源仓库Kestrel-LLM (Gitee)源码可得双许可学习 / 学术研究免费下篇预告单请求已经很快可 decode 逐词生成仍是“等一个、算一个”。Day 13 上推测解码--spec让模型“赌”几个候选词一起验证——但 2B 本地 decode 才 ~120ms/词verify 的账怎么算才划算关键词跨进程恢复、实测复现、性能口径、磁盘 KV上一篇Day 12·2 磁盘KV快照格式0.47GB从哪来下一篇待更新......