如果你曾经考虑过用本地模型替换代码 harness 正在进行的 API 调用，那么结果可能让你失望。你快速运行了一个 llama-bench，认为你将看到 X 个 tokens/秒。但这个基准测试不会告诉你使用这些 harness 的实际感受。开发体验极其不稳定。你可能坐在那里几分钟都看不到任何响应。也许你已经取得了一些进展，但 halfway through it started stalling。'这个 prefill 为什么要占用我所有的时间？'这不是你的错：大多数代码 harness 并不是为本地模型设计的。对于这个问题，使用错误的工具是不可避免的。请加盐：我一直在 tinkering with chad，这是一个专门为 Qwen 3.8 27B 在 Apple silicon 上优化的代码 harness。笔记本物理学 大多数 harness 以三种方式对抗 localhost。大型系统提示和工具架构。假设你的笔记本读取速度为 90 tokens/秒，写入速度约为 10 个。这些代表了代码 harness 中每个循环的 prefill 和生成部分。以这些速度，每 1,000 个 tokens 的提示读取时间相当于约 11 秒的盯着光标等待模型开始写入。在你的 LLM 开始工作之前，它将读取整个系统提示以及任何加载的工具架构。在 pi harness 中，这个组合对于 Qwen 3.8 27B 是 2,008 个 tokens，但对于 Opencode 是 18,046 个。你不会注意到太多差异，当你有一个数据中心 GPU 时，prefill 速率平均达到 10k+ tokens/秒。这从 0.2 秒下降到 1.8 秒。而在你的笔记本上？这是在 22 秒和 226 秒之间的差异，实测结果。难以忍受！更小的上下文窗口。在你的 LLM 完成系统提示后，你在内存中还有一个有限的上下文窗口可以进行工作。它比你想象的要小，你的 harness 刚刚用掉了其中一部分。你有多少上下文取决于你初始时有多少内存与模型权重的尺寸有多大。这里有很多变量，但 32,000 个 tokens 是你在合理的笔记本上使用合理的模型时可能剩下的空间的一个合理猜测。pi harness 还剩下多少 32,000 个 tokens 的预算？94% - 看起来是可控的。Opencode？在已经用掉了 18,046 个 tokens 之后，只有 44% 的上下文留给你实际工作。侧面请求的习惯。在传统的本地客户端/远程服务器模式中，harness 可以向数据中心服务器发出任意数量的侧面请求。你的笔记本既是客户端又是服务器。在最好的情况下，这些侧面请求会导致本地模型排队等待。在最坏的情况下，它们会导致重复的长 prefill。Opencode 在 24 个任务中发出了 33 个请求，crush 51 个，dsh 24 个（会话标题和摘要），几乎每个都与 agent 转折重叠。模型在 opencode 和 crush 上分别忙碌了 125% 和 114% 的墙钟时间：一个 GPU 上有两个请求在进行中。Harness 结果 我让 9 个 harnesses 通过一系列 8 个 Exercism 练习，每个练习都有自己的自动批准模式，使用相同的单句提示。每个任务都利用了相同的 M4 Mac Book Pro（24GB，mac OS 26.6.2），使用 3 bit 量化版本的 Qwen 3.8 27B 模型，通过 llama.cpp（构建 10470）提供。相同的 llama-server 被每个 harness 共享，一个公共代理强制执行相同的 Qwen 推荐采样机制（temperature=1.0，top_k=20，top_p=0.95，min_p=0.05）。每个会话都有相同的 32,768 个统一缓存，跨四个插槽提供。下面报告的每个数字都是 llama-server 自己的记录，通过代理读取，从不使用 harness 的自我报告，除了标记为 * 的两行（chad 在其内部 MLX 引擎上运行，没有服务器可以观察，所以它们来自 chad 自己的 prefill 跟踪，使用相同的定义）。