上一篇28-2《分析工具引擎日志时间戳与 prefill/decode 拆解》 下一篇29-1《AGPL 双许可为什么不是 source-available》真机实测通过本文实验已在 RK3588 板端实测完成2026-09方法学与原始记录见仓库 docs 与《实验脚本》目录一句话导读推理引擎复现核心三表冷启动、长上下文拆解与历史 KV 恢复——按报告口径重跑并逐项标注配置/计时差异如实记录优化档 13.1×disk-kv未在本板复现落点是把“复现要交代哪些差异”变成方法论本身。关键词手搓推理引擎、大模型推理、复现核心三表、冷启动、prefill、KV 恢复、基准28-1/28-2 立了口径、教会读表。这篇动手复现报告的核心数据冷启动、长上下文拆解、历史 KV 恢复。目的不是证明报告没错而是学会复现时要交代哪些差异——实测与报告存在配置口径差异默认档 vs 优化档与计时口径差异health-ready vs spawn-ready如实记录本身就是方法论。1. 知识点复现的四个对账点复现 ≠ 跑一遍看数字像不像。每次复现前先对四个账版本/编译报告为 2026-09-05 板端 gcc 11.4 aarch64 发布源码本次同日同源GitHupSRC 同步树build-rk3588。配置报告标注优化档全开sparse-attn k32 spec-k4 prefix/disk-kv本次 serve 为默认配置未显式开 sparse/spec。口径报告冷启动 spawn→HTTP ready本次测得 spawn→/health 200。TTFT/加载计时同字段[M-T] model load took。驱动报告测试驱动未随仓库分发附录已声明本次用自建 python 脚本请求格式对齐/v1/chat/completions。对不齐的项写进结论旁边而不是悄悄忽略。2. 对应代码/工具复现三表要用到的入口表需要入口冷启动spawn → /health 200 [M-T]servemanual-load 模式下 health 即服务就绪prefill/decode 拆解长 prompt 一次[PREFILL-TIMING]/[PREFILL-KERNELS]28-2KV 恢复同会话 turn1 → turn2 追加内存前缀缓存同进程或 disk-kv跨进程--disk-kv3. 改动后果三次复现与两处诚实差异实测口径RK3588 OPi5 / aarch64 / 2026-09-07 / 默认配置未开 sparse/spec 优化档。模型 Qwen3-VL-2B 明文 VQF。① 冷启动spawn→/health 200 × 3[cold0] spawn-health OK 5 ms # 首测含旧进程释放抖动 [cold1] spawn-health OK 102 ms [cold2] spawn-health OK 102 ms [M-T] model load took 341 ms (startup time) # vqf mmap 加载诚实差异 #1报告口径spawn→HTTP ready 中位 2.01s2026-09-05 版完整启动计时本次 health-ready ≈100ms 量级。差异来源是计时口径health 服务线程极早就绪 vs 完整 ready 判定与当时版本初始化路径——两者结论一致相对 llama.cpp 5.0s 的首字节优势不变但绝对值不可直接混用。复现的产出不是2.0s 达成而是量级确认 口径标注。② 长上下文拆解2243 prompt tokens默认档[PREFILL-TIMING] n2243 total75460.4ms | GEMM43703.0ms(57.9%) ATTN29456.8ms(39.0%) OTHER2300.5ms( 3.0%) # 客户端墙钟 wall89.9s含 decode诚实差异 #2报告 2K 档2049 tokens优化档prefill 44.6–45.2s ≈ 45.4 tok/s本次默认档 2243 tokens prefill 75.5s ≈29.7 tok/s。差异主要来自配置档sparse-attn 未开时 2.2K 全量注意力吃掉 ATTN 39%。复现到的是默认档基线不是优化档数字——这正是 28-1 说的数字离开配置不可比报告里每个数字都必须挂它的配置档。③ 历史 KV 恢复同进程前缀复用——turn2 追加短问[turn1] wall89.9s # 2243 tokens 全量 prefill decode28-2 那次 [turn2] wall10.4s # 同前缀 2243 tokens 命中 追加句增量 prefill decode → 8.6×# serve 日志在 turn1 与 turn2 之间内存前缀缓存命中无 [KV-DISK]非跨进程 [PREFILL] 2243/2243 tokens done # turn1 全量 # turn2 无全量 PREFILL 进度 → 增量路径报告同场景优化档给出 TTFT 口径12.8×4K/ 14.6×8K、增量 prefill 恒定 ~2.0s本次默认档墙钟口径 8.6×。量级与趋势一致前缀越长收益越大差异再次落在配置档 口径TTFT vs 墙钟。报告 §3.2 的13.1× 跨进程 disk-kv 恢复需要 8K 会话prefill ~200s 1.87GB 快照写读 重启本次未复现——按报告附录口径引用作为 A 档进阶任务留给学员诚实边界。推演改动后果三张表复现下来最有价值的发现不是数字而是默认档 ≠ 报告档这一课本身——它解释了为什么社区里复现不出别人的性能九成是配置差异而非引擎差异。复现报告的正确姿势先按 §0 复现环境表逐项对齐再跑跑完把对不齐的项写进结论。4. 学员调试任务A 档动手复刻三次实测冷启动 / 长上下文拆解 / turn2 前缀复用记录你自己的三组数字进阶可选项尝试复现 13.1× disk-kv--disk-kv 8K 会话提示需磁盘 ≥2GB 空间与较长时间若环境不允许写明未复现即算完成——诚实优先差异标注把你自己三组数字与报告对比列出每条差异的口径/配置原因。B 档思考回答① “复现失败与复现出不同数字分别可能是什么原因哪种更可能是 bug、哪种更可能是口径提示先查配置档、再查版本、最后才怀疑算法② 若你要给别人的论文做复现评审拿到报告后第一步看哪一节提示复现环境表 口径注释③ 为什么报告把测试驱动不随仓库分发、而是可按表结构自建”提示驱动本身不是引擎的一部分聚焦可复现的引擎行为预期输出你自己的三表复现记录 一张复现 vs 报告差异清单每条标注原因配置/口径/未复现能口头说清复现的价值在于暴露口径而不在于数字一致。收尾本篇文档点名RK3588_性能基准报告.md§0 复现环境、§1 冷启动、§2 长上下文、§3 KV 恢复开源仓库Kestrel-LLM (Gitee)AGPL-3.0-or-later 或商业许可二选一下篇预告性能与可信都有实证了进入交付环节。Day 29 讲发布与工程化AGPL-3.0-or-later / 商业双许可与 source-available 的区别、换板怎么验证、以及内存安全的最后一关 ASan。