generated-computers/locals 是一个本地运行工具，其仓库描述写着「在 Mac 上一次运行多个 AI 智能体，速度约快 3 倍」。2026 年 11 月 5 日的提交 653394a 修复了提示词分块被写入缓存缓冲区副本的问题。
原因在于 MLX 的缓冲区所有权机制。mx.eval 会从最后一个命令缓冲区的信号中返回，但命令缓冲区读取的数组稍后才会在 MLX 的完成处理程序中由另一个线程解锁。在这期间如果分块写入缓存缓冲区，就会被写入地址已经改变了的整个缓冲区副本；而在 GPU 丢弃该分块之后，_rewind 拒绝从该位置重新读取。修复很短：locals/hybrid_batch.py 中的 _read_chunk 在每次尝试之前调用一次 mx.synchronize，等待缓冲区被清空。
引擎文档（docs/engine/README.md）称，等待时间约为 30 微秒，提示词读取速度保持不变。原本在 GitHub 托管方上因 MLX 缓冲区复制而被跳过的、用于模拟 macOS 看门狗引发的 GPU 掉线的测试，在这次提交中去掉了跳过限制，重新开始运行。模拟掉线的代码也会在破坏缓冲区之前先同步，并新增了一个在 eval 结束后立即写入分块的测试。
所有数字都来自项目文档中登载的值。在运行 16 个进程的 M2 Pro 上，读取 13 个分块共 60 次时，有 7~15 次落到副本上；不使用标记时，60 次中有 3~4 次。等待之后，600 次中为 0 次；Qwen3.5-4B 以 256 token 为单位读取 4,096 token，速度为每秒 576 token，等待前后相同。CHANGELOG 中此修复仍处于 0.2.3 尚未发布的状态，紧邻的上一版本 0.2.2 发布于 2026 年 11 月 4 日。许可证与 star 数未给出。范围很窄，仅限于 Mac 的 MLX 路径上出现的缓冲区所有权竞态，而「速度得以保持」的依据只有开发者自己的测量。同一问题是否会在其他 GPU 环境出现，仅凭这份材料难以判断。