发帖
雷达卡
核心摘要：我在自家RTX 3090设备上，通过复现27项真实生产任务，实测本地部署模型能否替代Claude，作为个人AI智能体「贾维斯（Jarvis）」的核心大脑，全面对比两者的输出质量、使用成本与运行稳定性。
第一轮测试：单张RTX 3090、16K上下文窗口，300亿参数模型得分仅22.8分（满分100），远低于Claude的89.4分；四分之一的输出存在工具调用格式错乱问题，并非单纯效果变差，而是直接出现功能故障。
第二轮硬件升级测试：三张RTX 3090、256K超大上下文窗口，1220亿参数模型得分提升至80分，彻底消除所有工具调用格式错误（27项任务零出错）；单任务运行成本仅0.000969美元，相比Claude的0.763美元，成本降低约787倍。
目前我的AI智能体已全面切换为本地模型运行，同时取消了Claude高级版订阅，仅保留基础版。客观局限说明：本次升级同时改动了模型参数量、上下文窗口、硬件设备三个变量，未设置单一变量对照组，因此实测结果是整套系统升级的综合效果，无法单独归因于模型本身。
一、测试背景：我的个人AI智能体 Jarvis
Jarvis 是我搭建的个人AI响应式智能体，基于LangGraph框架开发，内置近90项工具能力，覆盖邮件、日历、笔记、本地文件、Office套件、即时通讯软件（WhatsApp、Discord）、图像生成，还可自主创建子智能体处理复杂长周期任务。
自搭建完成以来，我始终以Claude作为Jarvis的核心推理模型，稳定性与可靠性一直值得信赖。一个月前，我尝试用本地部署模型替换Claude，首次测试效果极差，我完整记录了所有问题；随后我升级硬件设备重新测试，得到了截然不同的结果。本文将对比两轮完整实测数据，核心还原本地模型从「不可用」到「可商用」的真实差距。
过往基准测试的局限性
我此前发布的《RTX 3090 本地大模型智能体实测》一文，基于两套智能体框架、17项任务（12项代码任务、5项通用智能体任务）测评了5款本地模型，最终 qwen3-coder:30b 综合排名第一，基准测试表现优异。
但标准化基准测试与真实生产环境完全不同：基准测试仅有17项固定任务、环境干净可控；而真实的Jarvis智能体，搭载90项工具、专属个性化系统提示词，且积累了数年杂乱真实用户指令，所有运行日志均通过自研托管追踪工具Langfuse完整记录。按理说，基准测试的优异表现理应能复现到真实场景，但实际结果完全相反。
二、实测方案：任务复现（非重复运行）
本次测试从Jarvis近90天的Langfuse真实运行日志中，筛选出28条原始任务指令，按7大场景分层抽样（日历、代码、邮件、文件、通用任务、消息通讯、笔记），每类场景4条任务，覆盖全场景真实使用需求。
对照组：固定不变的Claude历史基线
本次测试未重新运行Claude模型，直接复用其历史生产环境的真实输出结果作为固定基线。若在沙箱环境重新运行Claude，只能提供虚假模拟工具数据，无法还原真实业务场景，会导致测评结果失真。本次基线数据为Claude在真实数据、真实场景下的原始输出，两轮本地模型测试均沿用该固定基线，保证对比公平。
实验组：沙箱环境复现本地模型运行
本地模型在独立沙箱复现环境中运行，完整复用Jarvis原生LangGraph智能体代码。为避免真实设备、账号数据被修改，所有写入类工具（发邮件、编辑日历、发布社交消息、写入文件）均被拦截屏蔽；
读取类工具（邮件/日历读取等调用外部系统的操作）同样被拦截，但不会使用通用虚假占位数据，而是调取历史日志中真实的原始返回数据。本地模型与Claude基于完全一致的收件箱、日历真实数据推理，彻底杜绝数据层面的不公平差异。
环境采用「默认拦截」机制：未在白名单内的所有工具均自动模拟屏蔽。该机制至关重要——两轮测试间隔内Jarvis新增了部分工具，默认拦截机制自动屏蔽新工具，避免新工具在真实账号中静默执行操作，规避测试风险。
评分规则：独立大模型打分（规避顺序偏差）
本次采用大模型裁判独立打分（非两两对比），彻底规避对比顺序带来的主观偏差。使用 Claude Opus 4.8 作为裁判模型，采用1-5分评分体系，最终换算为0-100分标准分值，两轮测试所有输出均使用完全一致的评分规则。
测评核心局限性（如实披露）
本次裁判模型为Claude系列，同时对Claude与本地模型输出打分，存在天然自偏好偏差（行业公认现象：大模型更倾向于给同系列模型高分）。该偏差无法彻底消除，大概率会抬高Claude的评分，尤其第二轮本地模型分数逼近Claude时，该偏差对结果解读的影响极大，属于本次测评不可忽视的核心局限，绝非可忽略的次要问题。
成本测算：无估算、全实测
Claude成本可直接通过Langfuse记录的真实API账单精准统计；本地模型无按任务计费机制，我通过自研开源监控系统 HomeLab Monitor 全程记录测试数据，精准统计每轮任务的GPU耗电量，结合家庭阶梯电价换算真实成本，两组数据均为实测值，无任何预估。
三、三轮校准：反复排错，确保数据可信
本次最终公布的所有数据，均经过多轮bug修复与重测，确保结果有效：
第一轮打分bug：裁判模型输出为结构化内容块而非纯文本，评分解析器对54次打分中的40次解析失败，系统未报错，而是静默填充中立默认分。本轮数据（Claude 71.6分、Qwen 43.5分）完全无效，属于噪声数据。
第二轮数据bug：修复解析问题后，分差进一步拉大（Claude 89.2分、Qwen 15/45分两极分化）。排查发现核心问题：28项任务中有16项为日历、邮件、笔记、消息场景，模拟工具返回通用占位文本，而非真实历史数据。本地模型基于虚假数据推理，Claude基于真实数据输出，测评对比完全失去意义。后续修复逻辑，所有模拟工具均调取历史真实返回数据。
第三轮限流bug：修复数据问题重测后，Claude API频繁触发限流，大量打分被静默填充中立分。新增退避重试机制，完成最终有效重测。
补充校验：第二轮测试中有8项任务得分恰好为70分（系统故障默认分值），我逐一核对裁判推理日志，确认所有70分均为真实3/5分人工评判结果，无系统故障兜底数据，确保最终分数真实有效。
四、第一轮实测：单RTX 3090 + 30B模型（完全不可用）
首轮测试搭载 qwen3-coder:30b 模型，单张RTX 3090需兼顾家庭实验室其他任务，显存资源受限：模型权重占用约18GB显存，上下文窗口被迫压缩至16384令牌。仅Jarvis的工具规则定义与系统提示词，就几乎占满全部上下文空间。
核心分数结果
Claude 平均分：89.4/100
Qwen3-Coder 30B 平均分：22.8/100
30B模型在七大场景中无任何一项优于Claude。相对依赖逻辑推理、少工具调用的日历、通用任务场景表现最好，但得分也仅为Claude的三分之一，整体全面落后。
核心故障问题（非单纯效果差）
1. 工具调用格式错乱：27项任务中有7项（25.9%）输出错乱，模型未执行标准LangGraph工具调用，直接将 <function=send_email></function> 这类原始函数代码暴露在用户可见的最终回答中，严重影响使用体验。
2. 工具匹配率极低：27项任务中有18项需要调用工具，模型工具匹配召回率仅14.8%，多数场景要么调用错误工具，要么完全不调用任何工具，无法复刻历史正确的任务执行逻辑。
3. 任务循环卡死：2项复杂任务出现严重调度故障：邮件任务（24次工具调用）、消息任务（27次工具调用）出现无效循环调用，反复调用已完成的工具，无法汇总结果、终止任务，并非资源不足导致的卡顿。
特殊现象：模拟环境下的模型诚实度差异
有一项邮件发送任务，两套模型均在沙箱内触发邮件调用（已拦截，无真实发送）。Claude 直接告知用户「邮件已发送」，属于主动虚假陈述；30B本地模型如实反馈「发送未成功」。
看似本地模型更诚实，但不能片面定论：30B模型四分之一输出存在代码泄露、还会任务循环，两套模型只是在不同维度出错，不存在绝对的优劣与道德差异。
关键结论：基准测试不代表生产可用
同款30B模型，在此前小范围、可控基准测试中任务成功率100%，但落地到真实Jarvis生产环境后彻底失效。核心原因并非模型性能下降，而是真实生产场景复杂度远超基准测试。在小场景表现完美的模型，无法直接无缝适配大规模、高复杂度的真实AI智能体业务。
首轮测试结束后，我的初步结论为：Jarvis 必须继续依赖Claude，本地模型无法替代。
五、第二轮实测：三RTX 3090 + 122B模型（基本可用）
硬件升级为三张RTX 3090，总显存72GB，彻底打破资源限制：部署Qwen3.5 122B混合专家模型（Q3_K_M量化），权重占用约53GB，全程显存运行、无CPU显存溢出。最核心提升为上下文窗口扩容至256000令牌，相比首轮提升16倍。
测试条件完全对齐：27项同源任务、固定Claude基线、同一裁判模型、同一评分标准、同一沙箱环境。
整体得分结果
122B本地模型平均分：80.0/100
相比首轮22.8分大幅提升，达到Claude得分（89.4分）的89.4%；27项任务中，14项任务得分持平或超越Claude。
分场景得分对比
| 任务场景 | Claude | 30B模型 | 122B模型 |
|---|---|---|---|
| 日历 | 90 | 30 | 78 |
| 代码 | 87 | 25 | 73 |
| 邮件 | 92 | 15 | 87 |
| 文件 | 88 | 15 | 64 |
| 通用任务 | 85 | 30 | 90 |
| 消息通讯 | 87 | 22 | 74 |
| 笔记 | 97 | 22 | 92 |
场景亮点：通用任务场景，122B模型得分（90）反超Claude（85）；笔记、邮件场景得分与Claude基本持平；唯一短板为文件处理场景（64分），该场景高度依赖多步骤工具串联调用，是当前本地模型的核心弱项。
可靠性质变：彻底消除格式故障
1. 工具调用格式错误率：从25.9%（7/27）降至0，彻底解决函数代码泄露到用户输出的致命问题；
2. 工具匹配召回率：从14.8%提升至38.0%（提升2.6倍）；当前模型可稳定输出规范工具调用，但仍存在工具选择与历史最优方案不一致的情况，是目前唯一明显短板。
极限场景：上下文仍有上限
原28项任务中有1项超大代码任务（字符总量33.6万），首轮16K上下文直接无法运行；第二轮256K超大上下文仍无法承载，模型报错：「请求令牌数281190，超出最大上下文256000」。
这说明：业务真实复杂任务的体量，始终在突破模型上下文上限，更大的上下文窗口只能缓解问题，无法彻底解决。这也是两轮测试最终有效任务为27项、而非28项的原因。
六、实测核心局限（客观无美化）
1. 多变量未隔离：第二轮升级同时改动硬件、模型参数量、上下文窗口三大变量，未做单一变量对照实验。目前只能确定整套系统大幅升级，无法精准区分性能提升来自更大的参数体量，还是不再截断的完整工具规则与个性化上下文。
个人推测：上下文完整度的贡献远大于参数量。首轮核心故障（格式错乱、工具选错、任务循环），均是上下文截断、工具规则不完整导致；第二轮格式错误彻底清零，也印证了「完整读取工具定义」是关键，而非模型本身智商提升。该结论为合理推测，尚未实验验证。
2. 裁判偏差依然存在：Claude裁判的自偏好偏差，在模型分数高度接近的第二轮测试中，对结果解读的影响更大。
3. 成本测算曾出现致命误判：分布式部署极易导致能耗统计偏差。首轮单设备部署，能耗统计精准；第二轮模型运行在GPU服务器、测试程序运行在桌面设备，初始统计错误将GPU能耗归为桌面设备闲置能耗，得出0能耗的虚假结果。最终通过1Hz高频采样、精准时间对齐、时钟偏移校正，才得到真实能耗数据。
重要经验：过于完美、符合预期的实验数据，更需要重点核查。
七、真实运行成本对比
27项任务全程三卡总耗电量：0.1573千瓦时，结合家庭电价核算单任务成本：
| 模型 | 单任务成本 | 成本对比（相对Claude） |
|---|---|---|
| Claude | 0.763106 美元 | 基准 |
| 30B本地模型 | 0.00014792 美元 | 便宜 5159 倍 |
| 122B本地模型 | 0.000969 美元 | 便宜 787 倍 |
1. 本地模型相比云端API，成本直接降低三个数量级；
2. 性能升级并非零成本：122B模型单任务能耗成本，比30B模型高出6.6倍；
3. 成本说明：本次数据包含显卡常驻闲置功耗（三张显卡持续加载模型，待机功耗约107W，保障低延迟）；若按需启停模型，边际成本更低，但任务延迟会显著升高。
八、最终落地决策与真实体验
目前我的Jarvis智能体已全面切换为122B本地模型稳定运行一周。我已取消Claude高级版订阅，仅保留基础版。
核心决策逻辑并非「本地模型更强」，而是本地模型性价比足够高。Claude综合质量仍小幅领先（89.4 vs 80），首次执行准确率更优，复杂关键任务仍值得使用。
两轮测试的本质差距：首轮30B模型是功能性损坏、完全无法落地，存在致命输出故障；次轮122B模型实现可控取舍——牺牲少量可预见的任务准确率，换取99.9%的成本降幅与100%的数据本地化（数据不出本地设备）。
剩余短板清晰可控：文件处理场景、38%的工具召回率，说明模型擅长「基于已有内容推理」，短板是「自主选择多步骤工具执行方案」。因此我目前的策略为：简单单步骤任务走本地模型，复杂多步骤任务手动路由至Claude，无需全程订阅高阶API服务。
九、核心实战结论
本次实测最关键的发现：让本地模型可用的核心变量，不是更聪明的模型权重，而是足够大的上下文窗口。充足的上下文可以让模型完整读取全部工具规则、个性化提示词与历史对话，从根源解决格式错乱、工具选错、任务循环等致命问题。
优化优先级建议：先拉满上下文窗口、保障环境完整适配，再升级更高参数量模型。
最后留给所有自建智能体用户的思考：你愿意为多少百分点的质量差距，放弃数据本地化、承担百倍的API成本？你的业务质量阈值底线是多少？
推荐学习书籍 《CDA一级教材》适合CDA一级考生备考，也适合业务及数据分析岗位的从业者提升自我。完整电子版已上线CDA网校，累计已有10万+在读~ !
[victory]
京公网安备 11010802022788号
