Ollama 在 Cloud Mac AI Stack 里是私有推理层，不是本地玩模型

在上一篇里，我们把 L1（GitHub Runner） 说清楚：git push 之后要有可审计的 Fact（定义见 Runner 篇 · Stack 语言）。接下来很多团队会在同一台 Cloud Mac 上装 Claude Code，顺便 brew install ollama——然后发现主力编码仍 100% 走 Claude API，Ollama 进程常年空转，还占着 6–8GB 统一内存。

这不是「Ollama 没用」，而是还没回答更关键的问题：为什么 Inference 必须单独成为一层，而不是归进 Claude Code？本篇不是 Ollama 安装百科，也不重复16GB vs 24GB 内存实测或M4 vs GPU 云成本；只界定 L2 的存在理由、边界，以及和 L3（Diff）的关系（L3 详见 Claude Code 工作站）。

L2 产出物：Inference 是什么

在 Cloud Mac AI Stack 里，我们用产出物而不是工具品牌来分层（完整链条见Runner 篇 · Stack 语言）：

记忆链 · 五种产出物（非调用顺序）

  Context  →  Inference  →  Diff  →  Fact  →  Workflow
  (MCP)      (Ollama 等)    (Claude Code)  (Runner)  (OpenHands)

五层结构图里仍按 L0–L5 画组件；产出物链把 Inference 与 Context/Diff/Fact/Workflow 并列，避免「横切补丁」感

Inference 在这里指：在你控制的 macOS 进程里完成的模型前向——输入 prompt / embedding，输出 completion / 向量，不经过第三方推理 API（或仅把 API 用于 L3 主路径，而 L2 处理必须本地的 token）。Ollama 是当前最常见的 L2 实现，不是唯一选项；Core ML 与 MLX 也可承担部分 Inference，但 Ollama 的模型生态与运维路径更统一，适合作为 L2 的默认叙事。

L2 形态：Inference Service，不是偶尔 `ollama run`

只说 Inference，读者仍可能把它理解成「又一个本地模型工具」。在 Stack 里，我们更强调形态——每层对应一种可长期依赖的系统角色：

ollama run qwen3:8b 与 ollama serve + 健康检查 + cron 调用的差异，就像「SSH 里手动跑测试」与「Runner 监听 push」的差异：

ollama run     →  人坐在终端前的一次性推理（像试跑）
Inference Service  →  11434 常驻、可 pin 模型、可被 Runner / 脚本 / Agent 反复调用

为什么 Inference 须单独成 L2，而不是 Claude Code 的一部分

很多开发者会问：「Claude API 不也是推理吗？」 是——但 Cloud Mac AI Stack 按产出物分层，不是按「有没有神经网络」分层。

Claude Code 的职责是生成 Diff——改哪些文件、怎么改、PR 里呈现什么 patch。Inference 的职责是生成 Token——任意模型前向的文本或向量输出。Diff 只是 Token 的一种用途。

同样属于 Inference、却不该塞进「编码 Agent」主路径的工作，还包括：

• 日志摘要、分类、审核、路由
• Embedding、RAG、rerank
• Agent 记忆整理、知识库清洗
• 夜间批处理、定时日报

因此关系是：

Claude Code  ⊂  Inference 的应用场景之一

而不是：

Inference  ⊂  Claude Code

把 L2 独立出来，不是因为 Ollama 比 Claude「更底层」，而是因为整台 Cloud Mac 上可能同时存在多条推理管线：L3 走 API 产 Diff；L2 在本机产必须私有的 Token；二者并行，互不替代。若把 Inference 折叠进 Claude Code，读者会误以为「装了 Claude 就等于 Stack 推理层齐了」——这正是空转 Ollama 的根源。

Ollama vs Claude Code：为什么不是二选一

搜索里常见「Ollama 还是 Claude Code」——在 Stack 语境下，这个问题本身问错了方向。二者对应不同产出物，不是替代关系。

实践口诀：编码问 Claude Code；「哪些 token 不能出机、要定时跑」问 Ollama。 同机内存排班见 L2-Q03 续篇；本篇只钉死「不是二选一」。

「玩模型」与「私有推理层」差在哪

同样是在终端里跑 ollama run qwen3:8b，两种心态对应两种架构结果：

一句话：玩模型关心「能不能跑」；L2 关心「跑什么、何时跑、谁依赖它的输出」。 若团队没有任何工作负载必须落在私有 Inference 上，L2 可以整层跳过——不必为了「完整 Stack」硬装 Ollama。

L2 与 L1 / L3 如何分工

三层最容易混在一起的边界如下：

L2 不生产 Diff，也不生产 Fact。 它不会让 PR 自动变绿，也不会替代 xcodebuild。典型接法是：Claude Code 改完代码 → Runner 验证 → 某 step 或 sidecar 脚本调用 Ollama 做日志摘要、漏洞模式匹配、私有 embedding 写入向量库——这些输出进入 Context（L4）或人工 review，而不是直接等同「构建通过」。

五层图里的 L2：层级 ≠ 调用顺序

全系列共用的五层结构见 Runner 篇 · 五层结构图。图中 Ollama 位于 Claude Code 下方，表示职责上 Inference 托住「私有算力」这一块地基，不是说开机必须先 ollama serve 才能开 Claude Code。

摘录 · 详见 Runner 篇完整图

  Claude Code  L3 · Diff
       ↑ 并行，非依赖
  Ollama       L2 · Inference Service（可选）
       ↑
  GitHub Runner L1 · Fact
       ↑
  Cloud Mac    L0 · 基础设施

理解 L2 时请记住：Claude API 与 Ollama 可以同时存在——前者服务编码主路径产 Diff，后者服务本机 Inference。这与「本地模型取代 Claude」的叙事不同，也是 Cloud Mac AI Stack 与「单机 All-in-One 聊天」产品的分界。

除合规外：L2 的持续计算价值

L2 常被写成「金融 / 医疗 / 大企业才需要」——合规确实是强信号，但 Cloud Mac 上大量用户是独立开发者、AI 创业者、小团队，未必有合规工单，却同样需要 L2。

核心差异在工作形态：

Claude Code（L3）· 按需
  你打开它 → 开始推理
  你关闭它 → 主路径推理结束

Ollama（L2）· 可 24/7
  进程常驻 → cron / sidecar 随时调用
  不依赖你是否坐在终端前

这类任务不是 Agent 对话，不是 CI，也不是日常 Coding，却是真实的长期推理服务，例如：

• 每小时整理 Runner / 应用日志
• 每晚重建 embedding、清洗知识库
• 自动生成日报、异常归类、路由草稿
• 在 Claude Code 离线时仍更新 Context（L4）侧数据

笔记本合盖就停，很难把这些当成「基础设施」；与 L1 错峰后，白天 Fact、夜间 Inference，对小团队往往比「再买一张 GPU 云」更现实——前提是 L2 已按 Service 来运营，而不是偶尔开终端试模型。

本地 Mac 能跑，Cloud Mac 能运营

有人会问：「我家 Mac mini 也能 brew install ollama，为什么非要 Cloud Mac？」 他说得对——本地 Mac = 可以跑；本篇讲的差异在能不能当基础设施运营。

选型与 L0 边界见 Cloud Mac vs 本地 Mac AI 工作站；本篇不重复租机参数，只钉死：Stack 叙事里，L2 要落在「能运营」的节点上。

L2 该接哪些工作负载

值得把 Ollama 当成 L2 基础设施（而不只是试玩）的信号，通常长这样：

• 合规 / 气隙边界——代码与日志可上 Cloud Mac，但推理请求不能进公有 API；L2 跑脱敏后的子任务（分类、摘要、PII 检测）。
• Embedding / rerank——CodeGraph 或 RAG 管线需要稳定、可 pin 版本的本地向量模型，避免 API embedding 计费与数据路径不可控。
• 高频、小模型、可批处理——例如每晚对 CI 日志做归类；7B–14B 量化模型在 Apple Silicon 上性能够用，且成本可预测（对照固定节点 vs 按小时 GPU）。
• 与 L3 错峰——白天 Claude Code + Runner 占满内存；夜间 ollama run 批处理，不把 24GB 机器当成「全天同时满负载」。
• 多 Agent 里的「快路径」——复杂改动仍走 Claude；分类、路由、草稿生成走本地 8B，降低 API token（OpenHuman 等桌面 Agent 也常采用类似拆分，见OpenHuman 手记）。

反过来说，若你只做 iOS 交付、编码全靠 Claude API、也没有任何需要定时跑的本地推理，L2 的优先级应低于 L1 Runner——先让 push 有 Fact，再考虑私有 Inference。

系列阅读顺序：Runner → Ollama → Claude Code

若你按 Stack 系列追读，建议顺序与产出物一致：

1. L1 · Fact — GitHub Runner 执行引擎：push 之后代码是否真的构建、测试、交付。
2. L2 · Inference Service — 本篇：哪些 Token 必须留在 Cloud Mac 上，并以服务形态被调用。
3. L3 · Diff — Claude Code 工作站：仓库该怎么改（多数走 API）。

底座与选型：Cloud Mac vs 本地 Mac AI 工作站。Context（L4）与 CodeGraph 等会在后续篇目接上 Inference 输出。

典型误判：装了 Ollama，Stack 仍只有 API

1. 在 Cloud Mac 上 brew install ollama，拉了两个模型，团队庆祝「AI 栈齐了」。
2. 日常开发仍 100% Claude Code + Anthropic API；Ollama 一周未被任何脚本或 Agent 调用。
3. 内存常年被闲置模型占用；Claude Code 与 Runner 争抢剩余统一内存，Swap 升高（内存事实见16GB vs 24GB 文）。
4. 负责人问：「我们为什么还要有 Cloud Mac？」——因为L0 只有机器，没有定义 L2 工作负载。

修正方式不是再装一个 GUI，而是指定 1–2 个必须走 L2 的 pipeline（例如：仅 CI 失败日志摘要走 Ollama；仅 embedding 走 nomic-embed-text），并 pin 模型版本、监控 11434 健康检查。并行排班见 L2-Q03 · 内存排班。

谁可以跳过 L2

与已发实测文的关系（本篇不重复）

仓库里已有几篇「Ollama 相关」长文，分工如下，避免读者以为重复选题：

• L2-Q02 · 16GB vs 24GB——内存与 Swap 实测；回答「买哪档机器」，不回答「Ollama 在 Stack 哪一层」。
• L2-Q04 · M4 vs GPU 云——账单与规模边界；本篇不比价。
• L2-Q05 · Core ML——Apple 原生推理路径；可与 Ollama 并存，但是不同运行时。
• L3 · Claude Code 工作站——编码体验；本篇补 L2，说明 API 编码与本地 Inference 如何并存。

落地顺序：Fact 之后再叠 Inference

与Runner 篇 · 接入顺序一致，我们更推荐：

1. L0——Cloud Mac 常驻 macOS。
2. L1——Runner，让 push → 绿/红 可重复。
3. L2——Ollama 只接已定义的私有 Inference 管线（本篇）。
4. L3–L5——Claude Code、MCP、OpenHands，在 Fact +（可选）Inference 稳定之后扩展。

先堆 L2 再补 L1，会出现：本地模型摘要跑得欢，xcodebuild 仍在 Linux 上失败——Inference 不能替代 Fact。

L2 专题连载

本篇是 L2 基石（定位与边界）。同专题后续：

五层职责总图仍锚定在 Cloud Mac AI Stack 五层结构图。

常见问题

Claude API 也是推理，为什么还要单独一层 Inference？
Claude Code 产 Diff；L2 产 Token（摘要、embedding、批处理等）。关系是 Claude Code ⊂ Inference 应用，不是反过来。

Ollama 和 Claude Code 是二选一吗？
不是。编码走 L3 API；必须本机或定时跑的推理走 L2，见上文 对比表。

必须先装 Ollama 才能用 Claude Code 吗？
不必。L2 可选，与 L3 并行。

没有合规需求还需要 L2 吗？
若需要 24/7 持续推理（日志、embedding、日报），独立开发者与小团队同样值得立 L2；仅偶尔试模型可跳过。

本地 Mac mini 能跑 Ollama，为什么还要 Cloud Mac？
本地能跑；Cloud Mac 能运营 Inference Service——24/7、与 Runner/Agent 同栈、可排班可观测。见 本地 vs Cloud Mac。

Ollama 和 GitHub Runner 谁先谁后？
建议先 L1 再 L2。图上的上下关系是职责层级，不是启动顺序。

本篇和 16GB vs 24GB 文有什么不同？
本篇讲 Stack 定位；内存实测见 16GB vs 24GB 文，成本见 M4 vs GPU 云文。