CangLu Knowledge Base

本机本地模型接入与选型 — 主报告

17分钟阅读

本机本地模型接入与选型 — 主报告

主题索引 · 工具调研 · AI 总索引

数据时效：2026-07-14。硬件与已装模型为本机实测快照；Ollama/Claude Code 集成以官方文档为准。本文是 选购决策主报告 的本地层续篇，不推翻原双层云侧结论。

一、需求解构与第一性原理

表面诉求：「本机加一个本地模型，再分析一遍怎么选。」

核心本质：不是「再买一个模型」，而是问——

在已有云侧供应链上，本地算力能否以接近零边际成本，补上云侧永远补不好的洞（隐私、离线、撞墙、批量吞吐）？

1.1 本地层真正能消灭的焦虑

云侧痛点本地能否治本说明
Token / 额度账单✅ 近似治本边际成本≈电费；批量改写、反复试错不再心疼
敏感代码进第三方✅ 治本权重与上下文不出本机
断网 / 出差弱网✅ 治本离线可用（模型已在本地磁盘）
套餐 5h 速率墙 / RPM✅ 部分治本撞墙时段切本地不停工
支付 / 封号✅ 无关本地无此问题
智能不够 / 长链 agent 翻车❌ 不能本地开源与云端顶级仍有稳定差距
交互速度体感⚠️ 视模型35B-A3B MoE 在 M1 Max 上可用，但通常慢于云端 API

1.2 不该用本地硬扛的事

  • 整库级长链 agentic 重构、超长工具链、需要极强指令遵循的生产改动
  • 「一次做对」的付费上线前关键路径（应用 L2 Claude 交叉验证）
  • 需要最新联网知识且本地未挂搜索工具时的调研

1.3 与原双层策略的关系

原结论（选购决策）：

国产套餐打底 + API 溢出 + 海外小额攻坚

本地层是 L0 增量，不是替换：

L0 本地（免费无限池）  →  隐私 / 离线 / 批量 / 撞墙兜底
L1 国产云（MiniMax + DeepSeek） → 日常主力智能
L2 Claude 小额 → 硬核攻坚与交叉验证

第一性：焦虑形态再拆一层——云侧用「套餐确定性 vs API 弹性」对冲；本地再用「零边际成本吞吐」对冲云侧所有计费与合规焦虑。三层各管一类失败模式。

二、本机硬件与已装基线（实测）

设备全景亦见 个人开发环境现状。本节只保留与本地推理直接相关的本机命令确认事实。

2.1 硬件（本机确认）

项实测值
机型MacBook Pro（MacBookPro18,2）
芯片Apple M1 Max
统一内存64 GB
CPU10 核（8P + 2E）
系统盘可用约 2.8 TB 空闲（总约 3.6 TB）
供电实测时接电源、电量 100%
同网其他节点PC：13600KF + RTX 4060 8GB + 48GB RAM；N100：16GB（见开发环境文档）

推理角色分工（确认）：

设备适合本地模型不适合
Mac M1 Max 64GB30B 级 Q4、35B-A3B MoE、长上下文有余量70B 全精度 / 超大 MoE 全载
PC 4060 8GB7B~14B Q4；小补全30B+ 全 GPU 载入
N100 16GB3B~7B 极慢 或 仅做 API 转发任何交互式编码 agent

2.2 运行时（本机确认）

运行时状态路径/版本
Ollama已安装；当前无运行中的实例/usr/local/bin/ollama，client 0.31.2（≥0.14 即可接 Claude Code）
LM Studio已安装（App）/Applications/LM Studio.app；模型目录 ~/.lmstudio/models ≈ 78GB
MLX Python 包未在默认环境检测到后续若要极致速度可再装 mlx-lm（非必须）

2.3 已下载模型（本机确认）

Ollama（~/.ollama/models ≈ 22GB）：

Tag备注
qwen3.6:35b-a3b已有 manifest；可直接作为 Claude Code 试验模型

LM Studio（~/.lmstudio/models）：

模型目录/文件约体积备注
HauhauCS/Qwen3.6-35B-A3B-Uncensored-... Q4_K_M≈20GB + mmproj去审查变体
huihui-ai/Huihui-Qwen3.6-35B-A3B-Claude-4.7-Opus-abliterated-...≈20GB + mmproj名称含 Claude 对齐/abliterated，非官方
hotdogs/qwen27b-abliterated-Fable-MTP≈16GB27B 密度型
huihui-ai/Huihui-DeepSeek-V4-Flash-abliterated-...≈3.5GB轻量草稿
paperscarecrow/Gemma-4-31B-it-abliterated≈17GB通用备选

[基于上下文推断] 用户已明显偏好 Qwen3.6 系 MoE（35B-A3B） 与部分 abliterated 权重；编码专用建议仍补一条官方 qwen3-coder:30b，与现有通用模型形成「通用 + 编码」双轨。

2.4 组网潜力（未实施，仅架构可行）

三台设备已 Tailscale 组网。理论上：

  • Mac 跑 Ollama，PC/手机通过 http://<mac-tailscale-ip>:11434 共用同一本地模型
  • 需防火墙与 Token 鉴权（Ollama 默认无强鉴权，内网暴露需谨慎）

本文默认 先本机 loopback，不做跨设备服务化。

三、三层供应链架构

3.1 任务分流表

场景推荐层原因
敏感业务代码、密钥附近重构L0 本地上下文不出机
离线 / 高铁 / 弱网L0 本地唯一可用
大批量机械改写、格式化、翻译注释L0 本地零 token 焦虑
MiniMax 5h 窗口撞墙时段L0 本地 或 DeepSeek 溢出不停工
日常多文件编码、中文场景L1 MiniMax 套餐智能与速度平衡，月费封顶
独立小产品嵌入 AIL1 DeepSeek API按量、可程序化
整库重构、疑难 bug、架构攻坚L2 Claude Sonnet 5长链 agent 仍领先
关键结论交叉验证L2 或 L1↔L2 互证抗幻觉

3.2 架构图

flowchart TD
    User["开发者发起任务"] --> Router{{"分流规则"}}
    Router -->|"隐私/离线/批量/撞墙"| L0["L0 本地 Ollama<br/>Mac M1 Max 64GB"]
    Router -->|"日常主力"| L1a["L1a MiniMax M3 套餐"]
    Router -->|"溢出/嵌产品"| L1b["L1b DeepSeek V4 API"]
    Router -->|"硬核攻坚"| L2["L2 Claude Sonnet 5 小额"]

    L0 --> CC["Claude Code 外壳"]
    L1a --> CC
    L1b --> CC
    L2 --> CC

    CC --> Out["代码变更 / 文档 / 验证"]

3.3 与原推荐组合对照

角色原双层方案+本地后
日常高频MiniMax 编码套餐不变（仍是智能主力）
溢出 / 嵌产品DeepSeek API不变
攻坚Claude Sonnet 5 小额不变，用量可因 L0 分流略降
新增—L0 本地 Ollama（已有硬件）

落地优先级（修正版）：

  1. 🥇 先把已有 Ollama 拉起来，用现成 qwen3.6:35b-a3b 接 Claude Code 验证工具链（零采购）
  2. 🥈 补拉官方编码模型 qwen3-coder:30b（≈19GB，磁盘充足）
  3. 🥉 保持 L1 MiniMax + DeepSeek、L2 Claude 小额；本地只吃「适合本地」的流量
  4. （可选）LM Studio 继续做人评 / 聊天；agent 编码优先 Ollama（Anthropic API 兼容更直接）

四、接入方案：Claude Code ↔ Ollama

[已在官方文档确认] Ollama 自 v0.14.0（2026-01-16） 起原生实现 Anthropic Messages API，可直接被 Claude Code 使用。参考：Ollama Claude 集成、公告。

4.1 前置

# 1) 确认版本 ≥ 0.14（本机已是 0.31.2）
ollama --version
 
# 2) 启动服务（当前实测：无 running instance，需先起）
ollama serve
# 或打开 Ollama.app
 
# 3) 确认已有模型 / 补拉编码模型
ollama list
ollama pull qwen3-coder:30b   # 官方推荐编码，≈19GB，可选但强烈建议

4.2 一键方式（推荐）

ollama launch claude
# 或指定模型
ollama launch claude --model qwen3-coder:30b
# 已有通用 MoE 可先试
ollama launch claude --model qwen3.6:35b-a3b

4.3 手动环境变量方式

export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
 
claude --model qwen3-coder:30b

也可写入 ~/.claude/settings.json 的 env 字段做 profile 切换（与现有 MiniMax 代理 profile 并存时，建议用目录/脚本切换，避免全局串台）。

4.4 与现有 MiniMax 代理共存

当前环境记忆：日常通过 https://api.minimaxi.com/anthropic + MiniMax-M3 跑 Claude Code。

ProfileBASE_URL模型用途
cloud-minimaxhttps://api.minimaxi.com/anthropicMiniMax-M3L1 日常
local-ollamahttp://localhost:11434qwen3-coder:30b / qwen3.6:35b-a3bL0 本地
cloud-claude自有 VPS 反代或第三方Sonnet 5L2 攻坚

实践建议：用 shell 函数 / direnv / 独立 iTerm profile 切换，不要在同一 shell 会话里混用未清理的环境变量。

4.5 上下文长度

官方建议编码场景 ≥32K，仓库级优先 64K+。Ollama 可通过环境变量或 Modelfile 提高 num_ctx；注意：上下文越长，统一内存中 KV cache 越大，64GB 虽宽裕，不建议无脑开到模型标称上限。

4.6 能力边界（预期管理）

能力本地预期
对话 / 补全 / 单文件编辑✅ 通常良好
工具调用（读文件、改文件、跑命令）⚠️ 依赖模型是否支持 tools；qwen3-coder 官方标 tools
子 agent / 长链多步⚠️ 失败率高于云端顶级
视觉⚠️ 需带 mmproj 的多模态权重；编码主路径通常不依赖
速度⚠️ 显著慢于云 API 属正常；MoE（A3B）优于同体积 dense

五、本地模型选型建议

5.1 编码主路径（Ollama）

优先级模型体积理由
P0 先用现成qwen3.6:35b-a3b已在 Ollama ≈22GB零下载验证整条链路
P0 建议补拉qwen3-coder:30b≈19GBOllama 库：agentic coding、tools、256K、30B/3.3B active
P1 轻量备胎gpt-oss:20b 或 DeepSeek 小杯视标签官方 Claude 集成文亦推荐；更快、更省电
P2 实验LM Studio 中已有 35B-A3B abliterated已有人评风格；agent 生产路径慎用非官方去审查权重

5.2 为何 35B-A3B / 30B-A3B 特别适合 M1 Max 64GB

  • 权重体积 Q4 约 19~22GB，64GB 统一内存可轻松留下系统 + IDE + 长上下文余量
  • Active 参数约 3B 级 → 解码速度接近小模型，质量接近中大模型（MoE 红利）
  • PC 4060 8GB 扛不住 这档全载；再次印证主力在 Mac

5.3 不建议作为编码主力的

类型原因
仅聊天调优的 uncensored/abliterated工具调用与指令遵循不稳定风险更高
70B+ dense Q3/Q4能塞进 64GB 但交互 tok/s 与热噪声差，agent 体验差
纯云端蒸馏小模型冒充「本地 Claude」预期管理失败

5.4 LM Studio vs Ollama 分工

OllamaLM Studio
Claude Code 接入✅ 原生 Anthropic 兼容需另配 OpenAI 兼容或桥
服务化 / CLI✅ 强GUI 强
已有大模型库存1 个主力 tag多套 GGUF（78GB）
建议agent 编码主入口试模型、人评、视觉预览

六、成本与对原双层方案的修正

6.1 本地层增量成本

项金额
硬件¥0（M1 Max 64GB / 已有 PC）
已下载模型磁盘已占用 Ollama≈22G + LM≈78G；再拉 coder≈19G 仍充足
软件Ollama / LM Studio 免费
电费接电推理，个人用量下可忽略（量级远低于云 token 账单）
时间选型与试错（隐性）

6.2 云侧月费（维持原估算）

角色选择月成本（估）
L1 日常MiniMax 编码套餐（Max 档示例）≈119 元（档位待官网核实）
L1 溢出 / 产品DeepSeek V4 API几十元级
L2 攻坚Claude Sonnet 5 小额≈70~140 元（可因 L0 分流下调）
L0 本地Ollama≈0
合计仍约 200~300 元/月，有机会压到更低

6.3 何时本地能「省出」一档云订阅？

仅当满足：大部分 agent 时长可接受本地时延 + 质量，且敏感/离线占比高。对当前「Web/全栈 + 独立小产品 + 要稳」画像——

不建议为了省钱砍掉 MiniMax 或 Claude 小额；建议 保留 L1/L2，用 L0 吃掉浪费型 token（重复试错、翻译、格式化、隐私片段）。

6.4 决策树（+本地）

flowchart TD
    Start["新任务"] --> Q1{{"含敏感代码或必须离线？"}}
    Q1 -->|"是"| L0["走 L0 本地"]
    Q1 -->|"否"| Q2{{"是否机械批量 / 低风险？"}}
    Q2 -->|"是"| L0b["优先 L0，失败再升 L1"]
    Q2 -->|"否"| Q3{{"是否长链硬核攻坚？"}}
    Q3 -->|"是"| L2["L2 Claude 小额"]
    Q3 -->|"否"| L1["L1 MiniMax / DeepSeek"]
    L0 --> Fail{{"本地多次失败？"}}
    L0b --> Fail
    Fail -->|"是"| Escalate["升级 L1 或 L2"]
    Fail -->|"否"| Done["完成"]
    L1 --> Done
    L2 --> Done
    Escalate --> Done

七、风险、限制与未覆盖盲区

7.1 风险

风险等级对策
本地模型工具调用不完整导致乱改文件高先只读任务试跑；Claude Code 权限模式收紧；关键路径升 L1/L2
abliterated 权重行为漂移中高生产编码优先官方 qwen3-coder / 官方 Qwen 权重
Ollama 默认无鉴权被局域网误用中仅 bind 127.0.0.1；Tailscale 暴露前加反代鉴权
环境变量串台打到错误后端中profile 脚本；启动时打印 ANTHROPIC_BASE_URL
长上下文内存压力 / 交换中控制 num_ctx；接电源；关吃内存的 App
热节流导致 tok/s 掉崖低~中桌面支架、避免捂膝、长任务分片
把「本地能跑」误判为「本地能替代 Claude」高（认知）用分流表，不用信仰

7.2 诚实声明

  • 未在本会话完成：真实 ollama launch claude 端到端改仓库压测、tok/s 数值、风扇曲线、tools 成功率统计。
  • SWE-bench 本地分：未对用户磁盘上的具体 GGUF 跑基准；云端 M3 / Claude 数字仍以选购决策文档为准。
  • Qwen3.6 vs Qwen3.5 命名：社区与 HF 存在 3.5/3.6 标签混用；以本机文件名与 Ollama tag 为准，不把未核验榜单分写进结论。
  • 阿里 / 第三方 abliterated 模型无官方 SLA。

7.3 下一步（可执行）

  1. ollama serve 后执行：
    ollama launch claude --model qwen3.6:35b-a3b
    用一个只读仓库问答验证工具调用。
  2. 磁盘允许则：ollama pull qwen3-coder:30b，重复只读 → 小范围写文件试验。
  3. 写两个 shell alias：cc-local / cc-minimax，固化 BASE_URL 切换。
  4. 跑一周后统计：本地承接了百分之多少请求、Claude 小额是否下降 → 再决定是否降 MiniMax 档位。

八、结论（给决策用的一句话）

在本机已有 M1 Max 64GB + Ollama/LM Studio + Qwen3.6-35B-A3B 的前提下，应把本地建成 L0「零边际成本池」，与原 L1 国产云、L2 Claude 小额组成三层供应链；先接通 Claude Code↔Ollama 并补 qwen3-coder:30b，用分流吃掉隐私/离线/批量/撞墙流量，而不是幻想本地取代云端智能。

关联主题

关系图谱