Magnitude：给编码智能体接上本地模型的开源推理服务器

面向想把编码智能体（coding agent）切到本地大模型上的开发者：出于成本、隐私或离线需求，不想再按 token 付费，但被"我的机器到底能跑什么模型"劝退过。前置知识：知道智能体客户端（Claude Code、OpenCode、Cline 这类）与模型推理后端的分工。

读完本文你能判断：Magnitude 解决的矛盾和 Ollama 直接差在哪；它的硬件画像（profiling）与模型推荐怎么工作；两条上手路径（让智能体自己装 vs 手动 setup）；以及哪些场景它不适用。

一句话判断

Magnitude 的定位是**“先懂你的硬件，再谈模型"的本地推理服务器**：它剖析你的芯片、内存、带宽，从模型目录里挑出这台机器真正跑得动的模型，估算 tok/s，下载后按机器调好投机解码（speculative decoding）与并发，再写进你所用智能体的配置里。与"让智能体自己装 Ollama"的本质区别在于：智能体装 Ollama 时在猜——不知道哪个量化版本合适、跑多快；Magnitude 把"猜"换成了"查表”：为这台机器算好的推荐目录 + 生成 harness（智能体经其接模型的运维框架）配置的 onboarding 流程 + 面向智能体负载的推理调度（按需加载、空闲或内存吃紧时卸载）。

核心能力：从硬件到配置的闭环

README 列出的能力可以归成一条链：

硬件画像 → 模型推荐（含预估 tok/s）→ 下载
   → 端到端调优（投机解码/并发）→ 接入 harness → 按需加载/卸载

这条链上有三个设计点决定它和裸用推理引擎的差别：

• 按需加载（load on demand）：模型在智能体请求时加载，空闲或内存吃紧时卸载。本地跑大模型最常见的死法是内存被多个常驻模型占满，这个策略是冲着它去的。
• 智能体优先的接入面：官方列出已适配的 harness——Pi、OpenCode、Hermes、OpenClaw、Codex、Claude Code、Oh My Pi、Cline，也带内置 harness。接入动作发生在 setup 阶段：由你的智能体（或交互式 CLI）把所选模型的端点写进 harness 配置。
• 离线与私有：模型、提示词、文件全部留在本机，下载完成后可完全断网运行。支持从 Hugging Face 下载目录外的兼容 GGUF 模型，不被官方目录锁死。

价值主张对应的是三类真实痛点：token 成本与限流、代码隐私外流、断网环境。如果你一条都不占，本地模型的推理质量目前仍普遍弱于顶级云端模型，强行切换不划算。

一次请求如何流过这套系统

把上面的闭环落到一次实际操作里会更直观。假设你在用 OpenCode，想切到本地模型：

1. 跑 magnitude setup，或把启动提示词丢给智能体。CLI 先做硬件画像，输出这台机器的芯片、内存与带宽，并据此给出推荐模型和预估 tok/s。
2. 你从推荐列表里选一个（例如一个 Qwen 系的中型量化版），CLI 下载模型文件，落在本机缓存里。
3. setup 阶段把该模型的端点写进 OpenCode 的 harness 配置，让它指向本机推理服务。
4. 你照常写代码。发起请求时，Magnitude 按需把模型加载进内存处理；请求结束空闲，或内存被其他常驻进程吃紧，就把它卸下。

第 4 步正是它和"装好 Ollama 后什么都不管"的分水岭：模型加载/卸载由 Magnitude 按请求驱动，而不是常驻占内存。

上手：两条路径

路径 A：让智能体自己装（README 首推）。把这段提示词发给你的智能体：

Set up local models for me with the Magnitude CLI. Install it with
`npm i -g @magnitudedev/cli` (or my package manager), then run
`magnitude docs onboarding` and follow the instructions.

智能体会剖析硬件、给出本机推荐模型、下载你选中的那个，然后把自己切换过去。

路径 B：手动安装：

npm i -g @magnitudedev/cli
magnitude setup

交互式 setup 完成同样的流程：硬件画像 → 从推荐列表选模型 → 下载 → 连接 harness。

平台边界：macOS 与 Linux 原生支持，Windows 走 WSL。硬件没有固定最低门槛——这正是它的卖点，画像结果决定推荐；内存越大可跑的模型越大。

与 Ollama 的差异边界

README FAQ 对这个问题给了官方回答，转述并补一点解读：差异不在"能不能跑本地模型"（都能），而在谁替你做决策。裸用 Ollama 时，量化版本、上下文长度、并发参数的选择落在用户或智能体的常识上；Magnitude 把这些决策编码进了推荐目录（按机器计算的推荐 + 预估吞吐）和默认调优里。代价是引入了一层新的服务依赖——你对推理栈的掌控少了一层直接性，换来的是少踩配置坑。

适用边界

• 适合：有隐私/离线/成本硬约束的智能体用户；机器规格明确但不知道模型选型的开发者。
• 不适合：追求最前沿推理质量的场景（本地模型仍有差距）；纯 API 调用、无智能体 harness 的用法（虽然技术上可用内置 harness，但价值主张主要围绕智能体工作负载设计）。
• 观察项：项目 stars 4k、Apache 2.0、TypeScript 实现，处于快速迭代期；生产环境依赖前先看 issue 区的活跃信号。

本文不覆盖：推理引擎底层实现、具体模型推荐列表（随版本变化，以 magnitude setup 现场输出为准）、与 LM Studio 的对比（仓库未提供可比证据）。

仓库信息

• 仓库：https://github.com/magnitudedev/magnitude （4k stars，Apache 2.0，TypeScript）
• 文档：https://docs.magnitude.dev
• 主页：https://magnitude.dev