专注打磨，推动本地模型

# 专注打磨本地模型 来源：https://lucumr.pocoo.org/2026/5/8/local-models/ 写于2026年5月8日 我真的很、真的很想让本地模型好用起来。 我希望它们在非常实际的意义上好用：我可以打开我的编码代理，选一个本地模型，得到足够有竞争力的体验，这样我就不会五分钟后立刻切回托管的API。我想要这个的原因有很多，但最直白地讲，是因为我们在这件事上还处于非常早期的阶段，而把所有实验都锁在普通开发者之外的想法让我非常不安。 令人沮丧的是，现在这件事仍然比它应该的要难得多，但原因与任务复杂度或模型质量关系不大。 我们在本地推理方面有大量的活动，这很棒。我们有好的项目、快的内核，人们在做很好的量化工作。很多非常聪明的人正在让这一切变得更好，然而，对于试图在编码代理中实现这一切的人来说，体验却远比它理应达到的更差。 把API密钥粘贴到Pi（https://pi.dev/）然后使用托管模型是一个非常无趣的操作。你选择提供商，粘贴密钥，然后就不用再操心如何获取token了。在本地做同样的事情，即使你有一台高配Mac且内存很大，也完全是另一种体验。你选择一个推理引擎，然后选一个模型，然后选量化方式，然后选模板，然后选上下文大小，然后你不得不把一堆JSON配置扔到栈的不同部分，接着你发现其中某个选择悄悄让模型变差了，或者某个东西完全无法工作。 这就是我关心的差距。 ## 能跑不等于完成 很多本地模型的工作优化目标是让模型能跑起来。这是必要的，但这和让它们给人完工的感觉不是一回事。我给你一个非常基本的例子来说明这个差距：工具参数流式输出。 不知为何，你在本地运行的大部分东西都不支持工具参数流式输出。我很难解释原因，但其后果实际上出奇地重要。如果你不熟悉这些API的工作方式，最简单的理解是它们会在token可用时立即发出。对于文本来说这很简单，但对于工具调用来说，通常并不这样处理，尽管补全API是支持的。结果就是，你只有在模型完成整个工具调用的流式输出后，才能看到对文件所做的编辑。 这很糟糕，原因有很多： - **连接断了是一种奇怪的连接：**本地模型很慢，所以如果你5分钟内没有收到任何token，你就无法判断是连接断了还是只是没有东西过来。这意味着你需要把非活动超时时间增加到毫无意义的程度。 - **你不会看到将要发生什么：**如果你比较亲力亲为，看不到系统在后台慢慢构思的bash命令意味着可能浪费token，也意味着你无法及时中断它，直到为时已晚。 - **这根本不是最先进的。**我们可以做得更好，而且我们应该力求拥有最好的体验。工具参数流式输出和其他地方的token流式输出同样重要。 让模型吐出token不需要很长时间，但要让端到端的体验变得出色，确实需要投入更多精力。 ## 碎片化 本地栈碎片化严重，涉及许多引擎和层。有llama.cpp、Ollama、LM Studio、MLX、Transformers、vLLM，以及许多其他取决于硬件和口味的组件。这些都是了不起的项目！问题不在于它们存在，也不在于数量众多（尽管坦白说，这让我想起了老式Python打包的糟糕感觉），问题在于，对于给定的模型，你获得的实际行为取决于一连串小的决策，而大多数用户根本没有精力去处理。 聊天模板渲染是否完全正确？推理token是否按预期方式处理？工具调用格式是否正确翻译？上下文窗口是否真实？KV缓存是否能真正用于编码代理？我从Hugging Face上选的量化模型是否正确？你是否因为模型与你的硬件不匹配而无意中损失了大量性能？流式使用是否在所有通道上正常工作？模型是否需要将其之前的推理内容保留在助手消息中？编码代理是否为其正确设置？ 除了你的编码代理之外，你还需要安装许多不同的东西。 所有这些事情都很重要。非常重要。 结果是，人们尝试一个本地模型，得到的结果既不是对模型的公平评估，也不是精致的产品体验，这导致人们要么否定本地模型，要么精力分散到太多独立的努力中，而不是集中精力把一件事从头到尾做好。 这是一种建立信心的糟糕方式。 ## 缺乏临界质量 与我们“慢下来”的总体原则一致，我想再次强调这个行业的飞速发展。 每周都有新模型和新“vibeslopped”的东西。注意力立刻转移到让下一个东西跑起来，而不是让一个东西在一个框架里跑得非常好。我理解这种兴奋和多巴胺冲击，但这同时也意味着太少的人气积累在任何一个模型、硬件、推理引擎、框架组合上，去发现当整个栈都围绕它构建时，它能变得多好。 托管模型提供商不会给你一堆权重然后让你自己解决其余问题，对于本地模型我们也需要采用这种思路。我希望有人选择一个模型，将其与一个服务路径配对，直接嵌入到编码代理中。一开始只针对一种硬件配置，然后扩展到更多。坚定地选一个赢家。如果工具调用失败，那就是一个产品bug，无论它发生在栈的哪个位置，都要修复。如果模型的推理流格式错误，那就是一个产品bug。如果延迟比应该的要差得多，那就是一个产品bug。我们需要开始将这种心态应用到本地模型上。 而且不是针对每个模型！这就是重点。让我们选一个赢家，然后把它打磨到极致。学会让那个配置变好需要什么，然后将这些经验用到下一个配置上。 ## 押注DS4 这就是我对ds4.c（https://github.com/antirez/ds4）感到兴奋的原因。这是Salvatore Sanfilippo特意为DeepSeek V4 Flash设计的一个窄范围推理引擎，仅限128GB以上内存的Mac运行。它不是一个通用的GGUF运行器，也不是一个框架。它是一个模型特定的原生引擎，包含Metal路径、模型特定加载、提示渲染、KV处理、服务器API胶合代码和测试。 DeepSeek V4 Flash是这类实验的好候选，因为它具有一些对于本地使用来说不寻常的属性组合。它足够大，感觉上与许多较小的密集模型有显著不同，但又足够稀疏，使得活跃参数数量使其可以运行。它有一个非常大的上下文窗口。由于ds4.c只针对Mac和Metal，它可以将KV缓存移到SSD中，这极大地帮助了编码代理预期的工作负载。 要运行`ds4.c`，你不需要MLX、Ollama或任何其他东西。它是一个完整的包。 ## 嵌入Pi 这促使我构建了pi-ds4（https://github.com/mitsuhiko/pi-ds4），这是一个Pi扩展，将整个东西直接嵌入到Pi中。利用ds4本身，并在编码代理中大量自用，零配置。目标是回答这个问题：如果Pi将本地模型视为一等提供商，而不是一堆手动配置，那么本地模型体验能变得多好？ 该扩展注册`ds4/deepseek-v4-flash`，按需编译并启动`ds4-server`，如果需要则下载并构建运行时，根据机器选择量化方式，在Pi使用期间保持租约，暴露日志，并通过看门狗在无客户端连接时关闭服务器。它现在甚至不给你旋钮，因为我想弄清楚如何自动设置旋钮。 这并不是要掩盖本地推理的复杂性。而是要将复杂性集中在一个可以改进的地方，因为我们需要沿着整个栈改进很多东西才能让它工作得更好。 我认为我们可以在缓存方面做得更好，如果大家齐心协力，可能还能获得一些性能提升。 ## 聚焦与学习 我想做的实验不是“本地模型能跑吗？”因为我们已经知道它能跑。我想知道的是，对于首先拥有高配Mac的人，我们能否尽可能接近托管提供商的易用性，并具备良好的工具调用性能：如何让缓存良好工作，如何改进在这些模型中暴露工具的方式，然后逐步扩展到更多的硬件配置和后续模型。 我也希望每个人都能用到这个。工程师需要锤子，而一把锁在另一个国家数据中心的订阅后面的锤子是不合格的。我知道一台能运行这个的Mac的价格本身也是天文数字，但我认为价格更有可能降下来。更糟的是，苹果目前由于内存短缺甚至不卖内存那么大的Mac Studio。所以是的，ds4.c最初将面向一小部分人。 但尽管如此，重要的是有一批人开始集中精力在一件事上，摆弄它，改进它，不被锁住，公开透明，最重要的是不受超大规模云服务商所提供内容的限制。 但如果你有合适的硬件并且关心本地代理，我很希望你在pi中尝试一下： ``` pi install https://github.com/mitsuhiko/pi-ds4 ``` 我希望这能成为一个有用的强制函数，真正打磨一个编码代理体验。但真正焦点应该是ds4.c本身（https://github.com/antirez/ds4）。 这篇条目标记为ai（https://lucumr.pocoo.org/tags/ai/）和thoughts（https://lucumr.pocoo.org/tags/thoughts/） 复制为（https://lucumr.pocoo.org/2026/5/8/local-models.md）/查看（https://lucumr.pocoo.org/2026/5/8/local-models.md）markdown