Mac Studio实测：122B模型如何做家庭财务分析师

在本地跑大模型不稀奇，但用一台 Mac Studio 让 122B 参数量的模型担任家庭财务分析师，还要保证它不说谎——这件事的难度和启发都远超“跑个分”。博主 koustubh 在 gharasathi 系列的最新一篇中，记录了他从 3B 小模型升级到 Qwen3.5-122B-A10B 的完整实践。结论先行：更大的模型让解释更漂亮，但算术安全必须靠代码兜底。

硬件与模型：为什么是 Mac Studio 加 MoE

整套系统的硬件是一台 M3 Ultra、96GB 统一内存的 Mac Studio。模型选用 Qwen3.5-122B-A10B 的 4-bit GGUF 量化版本（UD-IQ4_NL），实际占用约 62GB 内存，剩下 30 多 GB 还能同时跑 Immich、Nextcloud 和一个 Kubernetes 集群。这种“一台机器全包”的部署方式，正是统一内存架构的价值所在。

选择这个模型的核心理由是混合专家（MoE）结构：总参数 122B，但每个 token 只激活约 10B。所有专家都必须驻留内存，统一内存恰好擅长这件事；而每个 token 的计算成本接近 10B 稠密模型。结果就是“大模型的质量，可接受的速度”——一次带工具调用的仪表盘追问大约 25 秒，隔夜批量分析则完全够用。

服务端没有用 Ollama，而是直接用 llama.cpp 的 llama-server，理由是需要精确控制上下文长度、并行槽位、聊天模板和思考开关。Nix 固定构建版本，launchd 负责进程守护。上下文开到 128k token，2 个并行槽位，对外暴露 OpenAI 兼容接口。

一个值得注意的细节是思考模式的管理。Qwen3.5 默认会“思考”，但服务端默认关闭，由每个调用方按需开启：隔夜分析师开启思考，聊天和路由不开启。原因是思考在困难提示上没有自然停止点，作者见过单次调用烧掉 35k token 的情况，因此所有思考请求都必须设上限。

混合专家模型（MoE） 是一种在 Transformer 内部将前馈网络拆分为多个“专家”子网络的架构。每个 token 经过路由门控后只被分配给少数几个专家计算，因此总参数量可以很大，但单次推理的浮点运算量远低于同等总参数的稠密模型。以 Qwen3.5-122B-A10B 为例，122B 是全部专家参数之和，A10B 表示每个 token 平均激活约 10B 参数。MoE 的代价是所有专家权重都必须常驻显存或内存，无法像稠密模型那样只加载部分层，因此对内存容量要求更高；作为交换，它能在相同硬件上提供接近大模型的质量和接近小模型的速度。这也是统一内存 Mac 特别适合运行 MoE 模型的原因。

两种用法：聊天助手与隔夜分析师

第一个用法是名为 anna 的聊天代理，基于 LangGraph 构建，挂了十来个财务工具：支出分析、洞察、目标、按揭 what-if 计算器、账单与对账单，以及一个只读的 Cypher 查询。它的提示词规则非常直接：回答前必须调用工具，绝不在脑子里做算术，计算一律走 calculate 工具。仪表盘上用户点击固定问题后可以继续追问，追问会携带对话上下文，所以“贷款是固定的，这会影响结论吗”能得到针对该发现的具体回答。

第二个用法才是大模型真正发挥价值的地方：隔夜分析师。整条流水线分为几个阶段。首先是事实包（fact pack），由代码按主题构建，涵盖按揭与对冲账户、育儿、水电、杂货、餐饮、保险等，每个包包含月度总额、商户、周期性扣款、余额，以及从账单和对账单中读取的事实。关键原则是：包里的每个数字都是计算出来的，不是估计的。

接着模型先概括家庭的 3 到 6 个主题，然后每个主题写最多 3 条发现。写作之前，模型可以从固定列表中请求补充数据，比如某商户的交易记录或某类别的逐月数据。写完之后的环节是整套系统的核心。

事实核查：让模型不敢编数字

每条发现里的每个金额和百分比，都必须能在事实包中找到出处，或者能通过一步算术从包中推导出来。不满足条件的发现会获得一轮修复机会，再不合格就被直接拒绝。原文贴出了昨晚的日志：一条关于育儿缺席津贴的发现被拒绝，原因是“156.0 这个节省金额不在数据中”；另一条关于 CCS 补贴比例的发现被分析师在事实核查后主动撤回。两条都是听起来很合理、但实际上是模型自己算出来的数字。

事实核查之后还有第二道判断：另一轮调用会问建议是否真的从事实中推出。再往后是跨主题综合、根据历史反馈（“没用过”“已处理”）排序、合并重复项、限制每晚新增发现的数量。

作者特别强调，每条发现都存储证据：交易 ID，或者从 PDF 中引用的原文行。事实核查器就是对照这些证据工作的。这一点在后续处理账单和对账单时会更加关键。

大模型仍然会犯的错：自信但缺上下文

事实核查能拦住编造的数字，却拦不住脱离上下文的建议。作者举了一个亲身经历：分析师告诉他按揭利率比“此前可协商的利率”高出不到一个百分点，建议打电话给银行。每个数字都通过了核查，但建议毫无用处。

原因有三层。贷款是固定利率的，重定价意味着 break costs；贷款价值比（LVR）意味着换银行要重新支付房贷保险（LMI），足以抵消多年小幅利率节省带来的收益；而所谓“可协商利率”来自更早的一条发现，根本不在数据里。

修复方案有两个。一是在事实包里加入领域规则：固定利率的违约成本、LVR 超过 80% 时的 LMI、绝不引用数据中不存在的利率，以及真正的杠杆点——对冲账户余额、固定期结束时的留存利率、以及 LVR 降到 80% 以下后的再融资。二是加入“家庭事实”，有些信息只有住户自己知道，比如 LVR，这些会以简短的“家庭说明”形式同时提供给分析师和 anna。

修复之后，当作者问再融资是否现实时，anna 会说不现实，解释 LMI 和违约成本，并指向对冲账户。而对冲账户正是数据中真正有金矿的地方：在对冲余额最高的几个月，每日利息下降了约五分之一。

给尝试者的四条经验

作者的总结值得逐条看。第一，更大的模型让解释更好，但不会让算术变安全，无论模型多大，计数逻辑都应该留在代码里。第二，强制引用，每条发现都存证据。第三，把你会告诉人类顾问的约束条件喂给模型，大多数糟糕建议来自缺失的上下文，而不是推理能力不足。第四，统一内存是这一切的使能条件：62GB 的 4-bit 122B MoE 模型，还能给其他服务留出充足空间。

系列下一篇将转向账单和对账单——作者刻意没有在那里使用 LLM，结果却发现它们藏着最有价值的发现。这个反转本身也值得关注：在财务分析这类场景里，确定性的代码路径往往比生成式模型更可靠。

背景补充

GGUF 量化是 llama.cpp 生态使用的模型文件格式，支持多种量化方案。文中选用的 UD-IQ4_NL 属于 4-bit 非对称量化，“UD”指 Unsloth Dynamic 量化策略，会对不同层或张量采用不同的位宽，把敏感部分保留得更高精度，从而在约 4-bit 的平均位宽下尽量减小质量损失。4-bit 量化的直接收益是内存占用：122B 参数按 4-bit 存储约需 60GB 量级，而非 FP16 下的 240GB 以上，这使得单台 96GB 统一内存的机器可以容纳整个模型。量化也会带来轻微的质量下降，但在事实核查和代码兜底的配合下，作者认为完全可以接受。

LVR（贷款价值比）与 LMI（房贷保险） 是理解文中再融资建议为何失效的关键。LVR 指贷款余额占房产估值的比例，LVR 超过 80% 时，贷款机构通常要求借款人购买 LMI，以在违约时保护 lender。LMI 的保费可能高达贷款额的百分之一到数个百分点，且通常一次性支付或计入贷款。当借款人从一家银行转贷到另一家时，如果新贷款的 LVR 仍高于 80%，往往需要重新支付 LMI，这笔成本可能抵消多年小幅降息带来的节省。此外，固定利率贷款在固定期内提前还款或转贷通常会产生 break costs，即银行补偿其资金成本损失的费用。这两项约束正是文中模型给出“打电话给银行谈利率”这种看似合理实则不可行建议的根源。