工程判断与适用边界

好项目的价值一半在”做了什么”,一半在”为什么这么选、否掉了什么”。这一章把散落各处的判断汇总,再诚实地划出边界。

1. 工程判断记

判断 选择 否掉了 为什么
I/O pread + fadvise mmap 流式要可控预取/驱逐;mmap 交给 OS 换页正是要打败的基线(第 3 章)
格式 GGUF 自造格式 站在生态上:量化模型现成、ggml 原生、可对拍(第 3 章)
语言 C++ Go ggml 是 C/C++,紧密算子跨 FFI 不划算;顺带 dogfood blade+vcpkg 实战(第 2 章)
内核 ggml 走 vcpkg 自己写内核 护城河在算法不在引擎
正则 PCRE2 RE2 RE2 新版拖庞大的 abseil(macOS 链接坑)且无前瞻;PCRE2 自包含 + 支持前瞻(第 7 章)
权重归一 norm_topk=false true 对拍发现 OLMoE 不归一 top-k(第 6 章)
研究方法 trace + 重放 先物理执行 命中率结论不需要物理搬运专家(第 4、9 章)
跨架构 granite(821MB) Mixtral(26GB) 小下载、真异构,不必把它跑进引擎(第 9 章)
图排序 concat 读 + cpy cpy-then-view 读写区不相交,天然避开 ggml 图排序陷阱(第 8 章)

两个特别值得记的时刻:norm_topk 是”对拍是最好的调试器”的活教材;pin/lru 曲线否掉了我自己”最优在中间”的假设——数据否掉直觉时,信数据,并如实标注 in-sample 的乐观性。

2. 一条隐形的功臣:CI

顺带 dogfood blade-build 时,CI 反复证明了自己:Linux gcc 的 -Werror 抓到了好几个 macOS clang 放过的跨平台坑(INFINITY<cmath>memcpy<cstring>、range-loop 绑字符串字面量临时量)。一个诚实的多平台 CI,比任何本地自测都靠谱。

3. 老实说:它还不能做什么

保持诚实,这也是项目一贯的态度:

  • 只有贪心 argmax,没有采样、chat 模板、batch/并发。
  • 流式路径仍慢于常驻(已提速 2×,但异步预取、减少每 token 图趟数都还没做)——本阶段目标是”真的在受限内存里跑起来且 token-exact”,不是速度。
  • 完整引擎构建走 blade(面向 Unix),在 macOS/Linux 验证;Windows 目前只把可移植 I/O 层用真 MSVC(CI job)验证,完整 Windows 构建、以及 ggml 的 Metal/CUDA/Vulkan 后端尚未打通。
  • 引擎只支持 OLMoE 架构(可作为接更多 MoE 的模板);但缓存研究已跨架构(OLMoE + granite)。
  • pin 的”跨输入迁移”没做:命中率用的是 in-sample usage 直方图,偏乐观;从校准跑建 prior、用到新输入的更严谨实验是后续。

4. 收获

这个项目是一条围绕单个假设展开的证据链——”用历史使用学出该缓存哪些专家,会明显赢过朴素缓存”——从合成信号一路验证到真实、跨领域、跨架构。收获是双份的:一个能自证的研究结论,和一次把推理引擎从 GGUF 解析、MoE 前向、KV cache 到物理流式亲手过一遍的经历。

如果你也想学推理引擎,这个仓库是按学习顺序长出来的——顺着 32 个 PR 读,每一步都有”为什么”,每一步都锚过正确性。这,大概就是它最值得留下的东西。

← 回到首页


This site uses Just the Docs, a documentation theme for Jekyll.