TurboFieldfare 这个开源项目容易让人先记住一个数字：Gemma 4 26B-A4B，在 Apple Silicon Mac 上约 2GB RAM 可跑。真正值得工程团队看的不是这个数字本身，而是它怎样把“模型大小”拆成常驻内存、SSD 读取、KV cache、活跃 expert 和硬件版本。只看参数量或 token/s，很容易把一个模型特定运行时误读成通用端侧突破。
项目的做法很直接：不把完整 14.3GB 文本模型载入内存，而是把共享的 1.35GB core 和 FP16 KV cache 留在内存里，每个 token 只从 SSD 流式读取需要的 experts。运行时、安装器、CLI 和 Mac app 都用 Swift 与 Metal 写成，不是 MLX 或 llama.cpp 的通用包装。README 给出的参考点是，约 2GB weights 加 4K KV cache，8GB M2 MacBook Air 上测得 5.1-6.3 tok/s decode，24GB M5 Pro 上测得 31-35 tok/s。作者也明确说，prompt 长度、生成长度、page cache 状态和硬件都会影响吞吐。
第一个边界：内存少了，存储和版本要求不会消失
TurboFieldfare 的要求并不低：Apple Silicon、macOS 26、Metal 4、Swift 6.2 或更新版本，还要为安装后的文本模型准备约 14.3GB 存储。第一次安装会从固定 Hugging Face revision 流式抓取并重新打包模型，避免在本地同时落下完整源 checkpoint，但网络和磁盘仍然是复现成本的一部分。
这类项目的关键问题不是“能不能装进 2GB”，而是这 2GB 是什么口径：是否包含 KV cache，context 长度多少，权重是不是流式读取，冷启动和热 page cache 是否分开测。读者复现时至少要记录模型 revision、量化格式、KV 长度、冷/热缓存、生成长度和硬件温控状态。没有这些条件，token/s 只是一条孤立数字。
第二个边界：参数放进 flash，不等于能力也放进去
ESP32-S3 上的 28.9M 参数项目给了一个更极端的对照。它运行在约 8 美元的微控制器上，芯片配置是 512KB SRAM、8MB PSRAM 和 16MB flash。项目把大约 25M 参数放在 flash lookup table 里，每个 token 只读少量行，模型整体 4-bit 后约 14.9MB，并报告约 9.5 tok/s 的端到端速度。
但作者也把限制写清楚了：模型训练在 TinyStories 上，只会写短小、简单、基本连贯的故事；它不能回答问题，不能遵循指令，不能写代码，也不知道事实。这个项目的价值在架构演示，而不是可直接替代手机或桌面上的通用助手。对端侧 AI 来说，参数驻留位置解决的是资源问题，任务能力还要由训练目标和可用计算决定。
第三个边界：小模型需要知道什么时候退出
Cactus Hybrid 从另一个角度处理端侧限制。它在 checkpoint 里放入 probes，每个回答返回 0 到 1 的 confidence，应用可以在置信度低时转给更大模型。README 给出的使用方式很像一个策略钩子：
if confidence < 0.85:
answer = ask_a_bigger_model(prompt)
项目称 Gemma 4 E2B Hybrid 在 FP16 下只把 15-35% 查询交给 Gemini 3.1 Flash-Lite，就能在多数 benchmark 上匹配 Flash-Lite。这个结论不能直接搬进生产，原因同样写在项目里：4-bit、3-bit 下 handoff 比例会上升，不同量化实现还需要开发者自己 benchmark。这里的启发不是“本地模型已经足够好”，而是本地模型如果要进入应用，需要把置信度作为结构化字段暴露出来，并在自己的数据集上校准阈值。
第四个边界：很多任务根本不需要 decoder
Liquid AI 在 Hugging Face 发布的 LFM2.5-Encoders 提醒了另一个常被忽略的选择：如果任务是 intent routing、policy linting、PII detection 或分类，长上下文 encoder 可能比本地聊天模型更合适。LFM2.5-Encoder-230M 和 350M 支持 8192-token context，官方报告在长上下文 CPU 推理上约比 ModernBERT-base 快 3.7 倍，目标就是让文档级分类和安全过滤在已有硬件上长时间运行。
这和 TurboFieldfare、ESP32-S3、Cactus Hybrid 不冲突。它们只是把端侧 AI 的任务拆开了：需要生成时看 decoder 的内存和 I/O；需要低风险回答时看 confidence 和 handoff；需要分类或路由时先试 encoder。把这些任务混成一个“端侧大模型”问题，反而会让系统设计变钝。
复现前先填这张表
| 检查项 | 要写清楚什么 | 为什么 |
|---|---|---|
| 常驻内存 | weights、KV cache、context 长度、是否流式读取权重 | 2GB、8GB、14.3GB 说的是不同资源 |
| 存储路径 | 模型安装大小、是否需要完整 checkpoint、冷/热缓存 | SSD 流式读取会改变延迟和复现口径 |
| 任务能力 | instruction、story、classification、routing、PII detection | 参数量不能说明任务能不能做 |
| 质量出口 | confidence、fallback 模型、阈值、失败样本 | 小模型需要可解释的退出条件 |
| benchmark 条件 | prompt 长度、生成长度、硬件、温控、量化实现 | token/s 离开条件就无法比较 |
端侧 AI 的下一步不会只靠“更小的模型”解决。更实际的路线是把模型、运行时、存储、任务和降级策略拆开：能本地跑的留在本地，置信度不够的转给更大模型，分类和路由交给更便宜的 encoder。这样设计出来的系统没有一句口号漂亮，但更容易上线，也更容易解释它为什么慢、为什么错、为什么该退出。