我把自己的 AI 助手 Jarvis 过去真实处理过的 27 个生产任务拿出来，重新交给本地模型执行，想验证一个问题：一台家用 GPU 机器上的大模型，能不能成为个人 AI 助手的主力大脑？

结论并不适合写成一句“本地模型已经赢了”。更准确的说法是：在单张 RTX 3090 和 16K 上下文窗口下，30B 模型不是慢一点、差一点，而是会把工具调用语法泄漏到用户答案里，属于不可用；升级到三张 RTX 3090、256K 上下文和 122B MoE 模型后，本地方案达到了 Claude 基线约 89% 的质量分，同时把单任务成本压到了约千分之一美元。

AI agent 真正进入业务系统后，瓶颈往往不只是模型参数，而是服务器显存、上下文容量、网络稳定性、数据边界和长期运行成本。把模型跑在本地或私有服务器上，不是为了追求“离线情怀”，而是为了让邮件、客户资料、内部文件和自动化工具调用留在可控环境里。

先看结果

最重要的变化不是“分数提高了”，而是失败形态变了。第一轮的本地模型会把类似 <function=send_email> 这样的原始标签写进最终回复；第二轮完全没有出现这类泄漏。对一个接入邮件、日历、文件、消息工具的个人 agent 来说，这个差别决定了它能不能放到真实工作流里。

Jarvis 为什么是一个更难的测试场

Jarvis 不是一个只会聊天的助手，而是一个基于 LangGraph react-agent 的个人自动化系统。它连接了大约 90 个工具，包括邮箱、日历、笔记、文件、Office、WhatsApp、Discord、图片生成，以及用于长任务的子 agent。这个工具面远大于常见 benchmark 里的简化环境。

作者之前也测过 qwen3-coder:30b：在 17 个任务、较小工具面和干净 harness 里，它表现很好。但把同一个模型放进 Jarvis 的真实环境后，可靠性直接塌了。这说明小型 benchmark 上的成功，不能自动外推到大型、私有、工具复杂的生产 agent。

实验不是重跑 Claude，而是重放本地模型

这次实验从 Jarvis 的 Langfuse 追踪记录中抽取了 28 个历史任务，覆盖日历、代码、邮件、文件、通用问答、消息和笔记 7 类，每类 4 个。由于其中一个代码任务有 336,906 个字符，第二轮 256K 上下文也装不下，最终两轮都按 27 个任务统计。

Claude 的答案没有重新生成，而是直接使用当时生产环境里已经记录下来的真实回复。这样做避免了一个常见问题：如果把 Claude 也放进沙盒，用假的工具返回值喂它，反而会惩罚原本已经在真实数据上完成任务的基线。

本地模型则通过同一套 Jarvis agent 代码重新执行，但所有写操作都被拦截，例如发邮件、写日历、发 Discord 或 WhatsApp、写文件。读操作也被沙盒化；如果原始 Langfuse trace 里有对应工具返回值，mock 会回放真实记录，而不是给一段通用占位文本。

这个 default-deny 的安全包装很关键：只允许少量明确放行的工具，其余全部 mock。Jarvis 在两轮之间新增了工具，但默认拒绝策略保证新工具不会悄悄碰到真实账号。

评分和成本如何计算

质量由 LLM judge 独立评分，而不是把两个答案并排比较。评分模型是 claude-opus-4-8，按 1 到 5 分打分，再映射到 0 到 100。这里有一个必须承认的限制：Claude 模型给 Claude 答案评分，可能存在同源偏好。这个偏差在第二轮尤其重要，因为本地模型已经接近 Claude，几分差距可能影响结论。

成本的计算也不是估算。Claude 一侧使用 Langfuse 记录的真实 API 账单；本地模型一侧用作者维护的 HomeLab Monitor 记录 GPU 能耗，并按实际电价折算到每个任务。第二轮还修正了一个容易忽略的问题：跑 benchmark 的桌面机和承载模型的 GPU 服务器不是同一台机器，能耗必须从真正运行模型的三张显卡上采样。

第一轮：单张 3090，16K 上下文，结果是不可用

第一轮使用 qwen3-coder:30b，运行在一张 RTX 3090 上。因为显存还要被家用实验室里的其他任务共享，模型权重占用约 18GB 后，上下文窗口只能压到 16,384 tokens。Jarvis 的系统提示词和工具 schema 本身就几乎填满这个空间。

这一轮的价值不在于证明某个小模型“不行”，而在于说明 agent 环境会放大上下文限制。模型可能在小工具面里表现很好，一旦工具 schema、个人上下文和真实历史数据一起进入提示词，就会出现截断、错选工具、循环调用和格式泄漏。

第二轮：三张 3090，256K 上下文，系统终于可用

第二轮换成三张 RTX 3090，总显存 72GB。这个预算可以把一个 122B 参数的 MoE 模型以 Q3_K_M 量化方式放进显存，权重大约 53GB，并把上下文窗口拉到 256,000 tokens。

在相同 27 个任务、相同 Claude 冻结基线、相同 judge 和相同 harness 下，本地模型平均得分 80.0 / 100，达到 Claude 的 89.4%。其中 14 个任务的分数达到或超过 Claude。

分项看，通用类任务本地模型反而超过 Claude；笔记和邮件也已经非常接近。差距最大的仍是文件类任务，因为这类任务更依赖多步工具链，而不是只对已经给到的内容做推理。

真正的拐点是工具可靠性

第二轮最值得注意的是 malformed tool-call 泄漏率从 7/27 降到 0/27。工具重合召回也从 14.8% 提升到 38.0%，约 2.6 倍。但 38% 仍然不高，说明模型已经能稳定生成格式正确的工具调用，却还不总能选择和历史成功路径相同的工具。

这也解释了为什么作者最终把本地模型接入 Jarvis，但仍保留 Claude Pro。Claude 在这个 benchmark 上仍是更强模型；本地模型则从“坏掉的替代品”变成了“有明确边界的低成本主力”。

成本：便宜到足以改变路由策略

第二轮 27 个任务一共消耗 0.1573 kWh。按作者家庭电价折算，122B 本地模型单任务成本约 0.000969 美元，而 Claude 是 0.763106 美元，约便宜 787 倍。30B 第一轮更便宜，约 5159 倍，但质量不可用。

需要注意，这个本地成本包含 idle draw。三张显卡常驻加载模型时大约有 107W 的空载功耗，因为作者为了低延迟让模型一直留在显存里。如果按需启动模型，边际电费会不同，但响应延迟会变高。

实际使用下该怎么看

如果放到Hostease的服务器使用场景里，它讨论的不是“买不买一张显卡”这么简单，而是企业要不要把 AI 助手从纯 API 调用，逐步迁移到可控的私有化算力上。对于需要处理客户邮件、工单、合同、知识库和内部文件的团队，数据在哪里流转，比单次回答便宜几分钱更重要。

这类部署对基础设施有几个直接要求：显存要能容纳目标模型和足够长的上下文；服务器要能长时间稳定运行；磁盘和网络要能支撑日志、向量库、文件检索和监控；权限边界要清楚，写邮件、改日历、发消息这类工具必须默认拦截或审计。

落地建议

先用历史任务做 replay 测试，再决定模型和服务器规格，不要只看公开榜单。

把上下文窗口当作服务器选型指标之一；工具 schema 和企业知识库装不下，agent 可靠性会明显下降。

把写操作纳入默认拦截和审计，包括发送邮件、修改日历、写文件、发消息和更新 CRM。

用监控记录 GPU 功耗、任务耗时、失败率和人工接管率，避免只看模型回答是否“像样”。

这次实验不能证明什么

最大的限制是变量没有拆开。第二轮同时换了更大的模型、更大的上下文窗口和更多 GPU，没有做“30B 模型在新机器上跑 256K 上下文”的控制实验。因此这只能证明系统升级后效果显著变好，不能单独证明是参数规模还是上下文窗口贡献更大。

作者的判断是：上下文可能比参数更关键。因为第一轮最典型的问题，诸如工具 schema 泄漏、工具选择错误和循环调用，都很像工具定义被截断后的症状。第二轮泄漏率归零，也更像“schema 终于完整进入上下文”带来的结果。但这仍然只是合理假设，不是被控制实验验证过的结论。

对自建 AI 助手的启发

不要只看模型在小 benchmark 上的 agent 成功率，要用自己的真实工具面和真实历史任务重放。

先确认工具 schema、系统提示词和个人上下文能完整放进窗口；上下文不够时，模型会表现得像不会用工具。

沙盒必须 default-deny，尤其是接入邮箱、日历、消息和文件系统之后。

评分要记录失败哨兵、解析错误和 rate limit，否则一个中性 fallback 分数可能把整组结果污染掉。

本地模型适合作为高频、低风险、数据敏感任务的主力；多步工具链、强正确性任务仍应路由给更强模型。

结论

这次复盘最有价值的结论不是“本地大模型替代了 Claude”，而是“本地大模型开始具备可运营的边界”。在单张 3090 和 16K 上下文下，它连基本工具调用格式都守不住；在三张 3090、122B 模型和 256K 上下文下，它已经能承担 Jarvis 的日常主力工作。

最后的取舍变得很具体：为了大约 99.9% 的成本下降和数据不出本地，你愿意接受多少质量分的损失？如果任务是通用问答、笔记整理、邮件草拟，本地模型已经很接近；如果任务需要复杂文件操作和多步工具链，Claude 仍然值得保留。