Chida82 · sf-ds4-1flash / Reddit · 阅读原文
原始来源：Chida82 · sf-ds4-1flash / Reddit
发现渠道：r/LocalLLaMA 原帖
Chida82 在 128 GB M5 Max 上从 SSD 流式读取 341 GB 的 DeepSeek V4.1 Flash Q2 权重。10 月 11 日的帖子报告：APFS 上不对齐的 F_NOCACHE 读取仍留下部分页缓存，挤走解码权重；拆出首个残页后，8K prompt 预填充后的首 token 从 1.23 秒降到 0.15 秒。另一项改动用共享缓冲区轮询路由结果，减少逐层等待。仓库另列同 GGUF、参数、82GB 专家缓存及基线提交的对照；这些整套收益不应全算在两个局部改动上。
可信度 65 · 重要性 70 · 新颖度 72
技术与主题
系统与效率 · 评测与基准 · SSD Streaming · Mixture of Experts · Apple Metal · Page Cache
Chida82
从本次采集 RSS 正文读到完整原帖；网页单独打开超时，未读取评论。
忠实转述（非原句）：他先发现“无缓存”读取仍把页留在 RAM，随后把读取拆到页边界；再观察到逐层等 command buffer 完成的延迟可以缩短。帖子强调只有一台机器的数字，持续重负载后速度会下降，并希望其他机器提供结果。
编辑评读
这里的“首 token”特别容易误读。帖子说的是完成预填充之后的等待，不能据此推断一个全新 8K 请求从发送到看到回答只需 0.15 秒。若要评估使用体验，应把输入预填充、权重换入与后续稳定解码分开，否则一个改善会遮住另一个瓶颈。
仓库的测量说明值得读：同机器也会受芯片温度与之前访问过的专家页影响，所以相邻两次运行并不自动可比。输出一致性检查则限制了一个重要替代解释——速度来自改变结果。它只核对有限提示上的行为，不担保全部输入，也不说明模型答案正确。对于磁盘换入权重的项目，这种分开记录性能与结果的方式，比只贴一个最高 tok/s 更可迁移。
因此，部署前的比较应固定请求轨迹，分别记录冷启动、追加输入与持续生成。不要只选已经命中缓存的那一次请求；它回答的是最佳路径有多快，而不是这批用户通常要等多久。
需要留意
- 一台机器自报；长时间热状态与冷状态不能混比。