边缘 / 本地推理引擎（2026 年 8 月）

一群在极小硬件上运行超大模型的项目。共享技术：利用 MoE 稀疏性——让小型共享核心常驻内存，
按需从磁盘流式加载被路由的专家权重——而不是对整个模型做量化。

模式

MoE 模型的每个 token 活跃参数量很小，而大部分专家集处于闲置。把这些专家从 SSD/NVMe 流式加载
（配 LRU/LFU 缓存），就能把数万亿参数的模型变成消费级硬件的工作负载。"零量化、零蒸馏"是它们
共同的口号。

项目

• kimi-k3-in-c — FareedKhan-dev/kimi-k3-in-c，Apache 2.0。176KB 的 C99 二进制在 8.24GB 内存上运行 Moonshot Kimi K3（2.78T 参数）。MXFP4 打包的专家从 NVMe 流式加载，16/896 专家激活， O_DIRECT 主干流式传输，专家 LRU 缓存。与 PyTorch 参考实现逐字节一致。
• TurboFieldfare — drumih/turbo-fieldfare，Apache 2.0。Swift+Metal 引擎，在 ~2GB 内存 （Apple Silicon）上跑 Gemma 4 26B-A4B。~1.35GB 共享核心常驻，逐层 16 槽 LFU 专家缓存。
• Ling-3.0-tiny — inclusionAI/Ling-3.0-tiny（蚂蚁 Bailing），MIT。7.9B MoE（1.3B 激活）， KDA:MLA 3:1 混合注意力，128 个专家。M4 Pro MacBook 上 ~90 tok/s，<100ms 首 token。
• Muse Glimmer — meta-models/Muse-Glimmer-30B（Meta），Apache 2.0。30B，从 Muse Spark 1.2 蒸馏而来，~17GB 4-bit 量化，RTX 5090 上经 DFlash 投机解码达到 233 tok/s。
• Needle 2 — cactus-compute/needle（Cactus Compute），Apache 2.0。45M 参数 → 14MB C++ 二进制； 无 MLP 层（Walsh-Hadamard 变换），哈希 n-gram 表。树莓派 5 上 500–800 tok/s。已部署于 Pebble Index 01 智能戒指。
• h3.c — antirez/h3-metal，MIT。C/ObjC + Metal 引擎，在 Apple Silicon 上运行 MiniMax H3 全模态模型；从 safetensors mmap 加载，--ssd-streaming 将 DiT 内存从 36.5 降到 2.0 GiB。

内存管理对比

"MoE 稀疏性"这个共同标签下其实藏着两种不同的策略。值得把它们分开——它们优化的是不同的约束，
失败的方式也不同。

A. 流式 + 缓存（kimi-k3-in-c、TurboFieldfare、h3.c 的 --ssd-streaming）——让共享核心常驻，
按需从 SSD/NVMe 流式加载被路由的专家，并缓存热点专家。无论有多少专家，内存占用都保持平坦；
代价是路由切换后的首个 token 会遇到缓存未命中。

• kimi-k3-in-c — 规模最大（2.78T → 8.24GB RAM）。专家 LRU 缓存，O_DIRECT 主干流式传输， 16/896 专家激活。与 PyTorch 参考实现逐字节一致是它的标志性主张。
• TurboFieldfare — 占用最紧（~2GB）。逐层 16 槽 LFU 缓存，~1.35GB 共享核心常驻。用 LFU （而非 LRU），因为活跃专家集很小且逐层都是热点。
• h3.c — 把通用机制暴露为一个开关（--ssd-streaming），并应用到 DiT（扩散）栈而不只是 LLM——证明了这套技巧与模态无关。

B. 缩小活跃集（Ling-3.0-tiny）——把每个 token 的活跃足迹压得足够小（7.9B 中的 1.3B，
KDA:MLA 3:1 混合注意力），让整个模型装进内存；完全不做磁盘流式。优化的是延迟和确定性的
首 token 时间（<100ms），而不是总参数量。

可复用的洞见： 引擎选择是在规模（A 可流式加载任意多的专家，但要付出缓存未命中代价）和
延迟（B 永不未命中，但受限于内存能装下的量）之间的权衡。缓存策略（LRU vs LFU、逐层 vs 全局）
是区分 A 类各引擎的可调旋钮。留意这两种策略是否会融合——一个"小常驻核心"模型，在更大的硬件上
也能流式加载溢出的专家。