周日晚上十点四十，我那台 M1 的 MacBook 风扇突然响起来，屏幕上 LM Studio 正卡在 43%，下的是 DeepSeek-R1-Distill-Qwen-7B 的 Q4_K_M。这已经是这个月第三次下同一个模型了——前两次不是软件的问题，是我自己手快把缓存目录清掉了。
事情得从头说。我这个站是个人项目，模型调用这块一个月的账单是两位数，不算多，但足够让我开始琢磨能不能干脆全挪到本地。Windows 那台机器我不敢想，显卡喂不饱；手头这台 M1、16G 内存的机器就成了解放的对象。折腾了几天，LM Studio 和 Ollama 我都装上了，Jan 也试了，vLLM 只看了文档没上手。装完我才发现，这几个工具之间真正要比的不是功能列表清单，是四件很具体的事：装机的门槛、模型从哪来、接口能不能接进现有的工具链、还有钱到底花在哪。
本地跑模型这件事，软件授权本身几乎不要钱，真正贵的是你的机器和你的时间。一开始我把它当成「免费的 API」，装完才发现模型是免费了，内存、磁盘、等待时间，还有一堆说不清来源的环境问题，全都变成了成本。所以这篇我不做功能盘点，我写我自己撞到的那几件事，以及每个结论对应的官方出处。
一、口径先钉死：版本、日期、测什么
版本号全部取自各家的官方发布页，核对日期是 2026-11-10。对比的四个对象是：LM Studio 0.4.28（2026-10-31 发布）、Ollama v0.40.16（2026-11-09 发布）、Jan v0.8.8（2026-10-28 发布），以及 vLLM v0.33.0rc3（2026-11-02 发的预发布版，我按预发布看待）。授权这一栏我也顺手查了：Ollama 是 MIT，Jan 仓库里的 LICENSE 写的是 Apache-2.0，vLLM 是 Apache-2.0，都属于可以放心改、可以放心商用那一类。
有一条得先说清楚，否则后面全是鸡同鸭讲：vLLM 和前面三个根本不在同一个赛道上。LM Studio、Ollama、Jan 面向的是「一台机器上跑一个模型」的个人场景，vLLM 面向的是在服务器上把显卡榨干。我把它列进来，是因为不少人拿它当参照物说「LM Studio 太慢」，但它慢的原因只是它压根没打算干这个活。我后面单独开一段说它。
测的东西我说得窄一点：DeepSeek-R1-Distill-Qwen-7B 和通义千问的 Qwen3 蒸馏版，在我自己这台 M1 16G 上跑「加载 → 起服务 → 调一次 → 换模型」这一圈。我不测推理速度排行榜，官方 README 给的显存和速度口径我会单独标出来，那是仓库自己写的数，不是我实测出来的。模型的权重从哪下、量化版怎么挑，我在这篇Hugging Face 使用指南里已经写过一遍，这里不重复。
二、维度一：装机的门槛，Intel Mac 是硬伤
LM Studio 的官方系统要求写得比大多数同类清楚：macOS 只支持 Apple Silicon，M1 到 M4，系统要 macOS 14.0 以上，内存建议 16G 起，8G 也能跑小模型但官方态度是「克制」。Windows 版要 x64 且支持 AVX2，同样建议 16G 内存加 4G 独立显存。Linux 是 AppImage，官方说 Ubuntu 20.04 以上可以跑，22 以上没有充分测试。
这里有一条让我当场翻车：Intel Mac 当前不支持。我有个同事还在用 2019 年的 Intel 机器，他装 LM Studio 装不上，回来问我是不是下错包。不是他下错了，是官方就不支持这件事本身。Jan 这边也有类似的一条：v0.8.8 的已知问题里明确写着本地模型在 Intel Mac 上不支持，这个限制从 v0.8.5 就在了。两家都把这条写进正式文档，而不是等用户在 issue 里问，这一点我要给分。
我自己是 M1，所以这条对我不成立。但我还是要把它写出来，因为 2026 年了还有不少人拿「MacBook」三个字就默认能跑本地大模型。Ollama 在这一维度反而没有厂商级的系统要求表，它把能跑什么机器这件事交给了 llama.cpp 的编译覆盖面，反过来说兼容性更宽，代价是遇到冷门硬件你得自己去翻 issue。
另一条更隐蔽的坑，是我装 0.4.25 的时候遇到的：LM Studio 的 Splash 引擎要求 M3 以上，而且系统要 macOS 26.4 以上。我在 M1 上装完发现这个选项直接不亮，查了 release notes 才知道是硬件门槛，不是 bug。版本号变了不代表硬件门槛没变，这种事官方只在 changelog 里写一行，你不翻就会当成软件坏了。
三、维度二：模型从哪来，怎么管
LM Studio 这块是它最厚的地方，也是它和 Ollama 最大的分野：它不是一个程序，是三个互相独立的工具——桌面 App、无头的 llmster 守护进程、以及 lms 命令行。三者装在同一套目录里，但可以单独用。
llmster 和 lms 这两个是 0.4.0 引入的，2026-01-28 发布，对应 Build 18。那一版一次性塞了三件事：无头守护进程、并行推理（Continuous Batching，n_parallel 默认 4），以及一个带本地 MCP 支持的有状态 REST 接口 POST /v1/chat，UI 也重做了一遍。对我来说最有用的是第一条，我不需要每次都开一个图形界面占着屏幕，后台跑一个守护进程就够了。本地 MCP 那部分我在另一篇MCP 实测里展开过，这里只说它确实挂在这个接口上。
lms 能做的事列一下，因为这条线是 GUI 和脚本之间的分界线：lms get 拿模型、lms load 加载、lms ls 看本地有哪些、lms server start 起服务、lms chat 直接聊、lms log stream 看日志。这几个命令拼起来基本就是一个可脚本化的模型工作台。我现在的做法是 lms load 加载好，再用 lms server start 把 1234 端口占住，编辑器和其他工具都指过去。哪个模型在占内存、什么时候该卸掉，lms ls 一眼能看出来。
Ollama 这边的模型管理简单得多，一条命令拉、一条命令跑，端口默认 11434。但 0.40.16 这一版有两条更新我得单独拎出来，因为它们直接改了我原来写的脚本。
第一条：Qwen3.8 Flash Next 在 Apple silicon 上少用约 27 GiB 内存。这不是小改动，我原来在 16G 机器上跑这个系列是要退让的，现在余量大了不少。第二条：/v1/models 在没有任何模型时返回空数组，而不是 null。这一条我踩过——我上一版脚本写的是 if (!data)，拿到的其实是 {data: []}，判断没走空数组分支，请求最后打到一个不存在的模型上，报错信息还特别难懂，排查了小半天。官方把返回结构改成数组，是为了让客户端少写一层防御，但它确实改变了老代码的判断路径。
同一版里还有两条跟 Anthropic 客户端相关的：/v1/responses 尊重 truncation 参数，以及 ollama launch claude 现在总是路由到你选定的那个模型，不再自己猜。后一条听起来是小修，但对我这种同一个项目里挂着好几个模型做对比的人是实打实的省事。
Jan 0.8.8 我用得最少，但这一版有一处安全更新，同时把 llama.cpp 引擎从 0.5.0 提到 0.7.0（对应 upstream b11669），新增了 Trusted Hosts，server-side tool execution 改成了逐端点 opt-in，CORS 开关更新之后默认是开的。
这里有个我必须承认是自己没准备好的坑：server-side tool execution 从「默认开着」变成「要一个一个端点手动打开」，我升级之后有一条调用直接 403，还以为是自己脚本写错了。我回头去看 changelog 才明白是默认行为改了。以后升级本地推理工具，我得先扫一遍 breaking change 再动手，不能直接起服务了事。
四、维度三：接口能不能接上，这一条淘汰掉一半选项
本地推理最后一定要落到一个能编程调用的接口上，不然装它干什么。我关心三件事：端口、兼容性、要不要认证。
LM Studio 的服务器默认在 http://localhost:1234，同时兼容 OpenAI 和 Anthropic 两套端点格式。这个「两套都兼容」是它最被低估的地方：我现有的一套脚本按 Anthropic 的 messages 格式写的，另一套是 OpenAI 的 chat completions，换到 LM Studio 上两个都不用改，改个 base URL 就行。对照 Ollama：它的默认端口是 11434，也支持 Anthropic 格式，但 base URL 要写成 http://localhost:11434，客户端自己会追加 /v1/messages。路径上多一个约定，脚本里就得写对，不然 404。我第一次接的时候就是漏了这段路径，查了半天才反应过来。
安全这块我要专门纠一个我自己被误导过的说法。我之前一直以为「本地服务默认就带 API key」，结果不是。LM Studio 默认不要求任何认证，你要开 token 得手动去 Developers Page 的 Server Settings 里打开，这个功能要求 0.4.0 以上，然后配 Authorization: Bearer。Ollama 这边本地请求也不需要 key，它默认只绑 127.0.0.1，不对外网暴露。Jan 0.8.8 新增的 Trusted Hosts 属于同一类问题的解法。
对一个只在自己电脑上跑模型的个人用户来说，「默认不带认证」不是漏洞，因为它默认就不出网卡。但只要你把这个端口映射出去，或者在同一个局域网里给别的设备用，就必须自己把认证打开。我把 Ollama 的 OLLAMA_NO_CLOUD=1 设成了环境变量，理由很简单：我要确认请求永远不出本机，别让任何一次「顺便用云端模型」的便利，把数据带出去。这个开关在官方文档里写着，本地推理它不影响，但一旦有云端相关的功能介入，它就是最后一道闸。
五、维度四：钱到底花在哪，Free 档不是全免费
LM Studio 的定价页我逐档抄过。Free 档 $0，包含 Bionic Agent、llama.cpp 加 MLX 的本地 LLM、离线语音转写、LM Link 最多 5 台设备，以及有限的网页搜索。Bionic+ 是 $20 一个月，给的是美国托管的开源模型，页面上列了 Kimi K3、GLM 5.3、DeepSeek V4 Flash 这些，附带零数据保留和批量 token 折扣。Pro 是 $100 一个月，用量是 Bionic+ 的 5 倍。Teams 档按席位算，Bionic+ $22 一席一月，Pro for Teams $110 一席一月。
这里有个非常容易被宣传材料说混的地方：Free 档的「本地 LLM」和 Bionic+ 的「托管开源模型」是两件不同的事。前者是在你自己电脑上跑，机器是你的，不限调用量但受限于你的硬件；后者是官方在云上跑，按 token 计费，有网络往返。你要的是「不花钱、把模型放本机」，那 Free 档就够了；你要的是「不自己买显卡也能用上更大的模型」，那 $20 起步的档位才是你该看的那一栏。看到「LM Studio 免费」就以为托管模型也免费，是这行最常见的误读。
Ollama 和 Jan 的本体都是免费开源，Ollama 是 MIT，Jan 是 Apache-2.0（仓库 LICENSE 前面多了一段 Menlo Research 的产品声明，GitHub 的自动检测因此认不出来）。它们的成本全在你自己那台机器上。真要花钱的只有一件事：vLLM。vLLM 自己不收你钱，它要的是一张撑得住的服务器显卡，那笔账单是直接付给云厂商或者机房提供商的，跟这个软件本身没关系。
顺带说一个跟本地推理配套的东西。我把本地模型接进自己那套调用链之后，才体会到网关这层有多省心——之前我写过一篇LiteLLM 网关核对，讲的正是把「换模型」从改代码变成改配置这件事，本地推理接进去之后这条路更顺，因为它连网络往返都没有。
六、vLLM 为什么不该跟它们放一张表里
vLLM v0.33.0rc3 是 2026-11-02 发的预发布版。它跟上面三个的差距不是「慢一点」，是量级不同：这个版本只支持 CUDA 13.0，直接放弃了 12.9，底层是 PyTorch 2.14、torchvision 0.29、Triton 3.8。目标机器是数据中心显卡，不是你的笔记本。
它的更新日志里有几条对做服务端的人是大事：新增了 /v1/decisions 端点；移除了 Medusa 和 MLP speculator 两种推测解码；移除了 legacy Ray compiled-graph executor；还有一条行为变化，生成暂停的时候，请求会返回 HTTP 503。
最后这条我标出来，是因为它会打到人。我如果自己搭一个 vLLM 服务，某个请求把生成队列卡住，后面的请求会拿到 503 而不是排队等。看到 503 就去查网络、查防火墙，是完全找错方向的那种排查。这一版还把两个推测解码路径删了，意味着以前靠 Medusa 提吞吐的那套配置得重写。
所以我把 vLLM 放在这张表里的位置是参照物，不是竞品。个人本地跑模型的话，vLLM 解决的问题你压根不会遇到。
七、那到底该选哪个
按我自己这半个月的实际用下来，给三个明确的结论。
要图形界面、要顺手点开就聊天、要模型列表看着清楚，选 LM Studio。它的模型管理、下载流程和内置界面是目前几个里最完整的，而且 lms 命令行把「界面」和「可脚本化」这两件事分开了，你不必二选一。
要的是一条命令能拉起来、能塞进 shell 脚本、能塞进 CI，选 Ollama。11434 这个端口和几乎什么都不用配的默认行为，在脚本里省下的时间是实打实的。我自己最后留在 Ollama 上，原因就一条：我不想每次开模型都面对一个 GUI。这个选择很主观，但我把过程写出来，你按自己的习惯对号入座就行。
要的是给团队做一层统一的本地推理网关、或者要在服务端跑，跳出这个对比，去看 vLLM 或者专门的网关方案。
还有一条不在功能表里但我要单独提醒：不管选哪个，升级之前先看 changelog 的 breaking change。Jan 那个 403 就是这么来的。
八、我没验证到的，和一个截至日期
有几件事我没测，不想含糊过去。第一，LM Studio 在 16G 内存的 Intel Mac 上的表现——官方文档说不支持 Intel Mac，所以我这台 M1 上测不出任何东西，这条我只能引用官方口径。第二，vLLM 我一行都没跑过，上面关于它的所有内容都来自官方 release notes 和文档，包括 CUDA 13.0 这条硬要求。第三，官方 README 里那些显存和速度数字，比如 7B 的 Q4_K_M 约需 6GB 显存、32B 约 22GB，是仓库自己写的口径，我没有逐条在本机复现，因为不同后端之间的差距可以到两倍以上。
所有版本号和价格的截至日期是 2026-11-10。LM Studio 0.4.28 是 2026-10-31 发布的当前稳定版，它的 Bionic 组件在 2026-11-05 到了 1.2.0，内置 llama.cpp 2.67.0 和 oMLX 0.1.0（0.4.26 那一版还是 llama.cpp 2.50.0，upstream b11337）。Ollama v0.40.16 是 2026-11-09 的，Jan v0.8.8 是 2026-10-28 的。这几个都是会动的数字，下个月再看到这篇，请以官方发布页为准。
最后一句：非要让我留一个最省事的建议，那就是先在命令行里把 Ollama 跑通，再决定要不要装 LM Studio。反过来做的话，你会先花一晚上研究 GUI。上一篇我写过Weights & Biases 和纯手调提示词的同跑对比，也是同一个思路——先有能复现的基线，再谈工具值不值。
—— 标个版本号