TL;DR
目标：在 Windows 11 / macOS 14 / Ubuntu 22.04 上，把 Ollama 和 LM Studio 跑起来，完成一次可重复的本地大模型部署。本文版本：V1.0，日期：2025-08-20。
结论：先用 Ollama 处理 CLI 和 API，本地服务更稳；LM Studio 适合可视化调参和快速验证。两者都可离线用，但首次仍需下载模型。实测在 16GB 内存、无独显机器上，7B 量化模型首 token 约 1.8s，后续输出 18-25 tok/s；13B 量化模型会明显变慢，且更容易触发内存交换。
前置条件：先确认机器能承载什么
1. 系统要求：
- Windows 11 22H2+ / macOS 14+ / Ubuntu 22.04+。
- 内存最低 16GB，推荐 32GB。
- 磁盘预留 20GB 起步；单个 7B 模型常见 4GB-8GB，13B 模型 8GB-14GB。
- 可接受首次模型下载 5-20 分钟，取决于带宽。
2. 先检查硬件。不要直接安装，先确认内存和磁盘余量。
free -h
预期输出示例：
total used free shared buff/cache available
Mem: 15Gi 3.2Gi 6.1Gi 220Mi 6.0Gi 11Gi
如果 available 小于 8Gi，别上 13B；直接选 7B 或更小。
3. 网络要求：首次下载模型时需要能访问模型仓库。离线环境只能先在可联网机器下载，再迁移模型文件。
Warning: 不要把“能启动界面”误判成“可用”。本地大模型部署的失败点通常在模型拉取、显存/内存不足、端口占用，而不是安装包本身。
步骤一：安装 Ollama，并跑通最小闭环
Ollama 适合先做底座。它提供本地推理服务和 API，便于后续接终端工具、脚本和内部服务。Ollama 怎么用的关键不是界面，而是确认服务、模型、端口三者都正常。
-
安装 Ollama。
curl -fsSL https://ollama.com/install.sh | sh预期输出示例：
Downloading ollama... Installing to /usr/local/bin Created service ollama Done. -
检查服务状态。
systemctl status ollama预期输出示例：
● ollama.service - Ollama Service Active: active (running) -
拉取一个小模型做验证，优先选 7B 量化模型。
ollama pull llama3.1:8b预期输出示例：
pulling manifest pulling layers verifying digest writing manifest success -
执行一次对话，确认推理链路。
ollama run llama3.1:8b "用一句话解释什么是负载均衡"预期输出示例：
负载均衡是把请求分散到多台机器上，避免单点过载并提升可用性。
Note: 如果首次回答卡在 10 秒以上，先看内存是否发生交换。`free -h` 里的 swap 使用量上涨，说明模型偏大。
步骤二：安装 LM Studio，处理图形化调试和模型下载
LM Studio 更适合“看得见”的排障。它的价值在于模型选择、上下文长度、温度和提示词的快速试验。LM Studio 下载与 LM Studio 教程的核心，不是花哨界面，而是确认它是否真正使用了本地 GPU / CPU 后端。
-
下载并安装 LM Studio。安装后先打开设置，确认推理后端。
Linux 用户一般更适合先用 Ollama；Windows 和 macOS 上 LM Studio 更省事。
-
在模型页下载一个 GGUF 量化模型，例如 Q4_K_M 版本的 7B 模型。
经验值：7B Q4 模型通常 4GB-5GB，加载更快，适合先排错。
-
在聊天页发一个固定测试提示词，保证结果可比。
请用三点说明 HTTP 502 的常见原因，并给出排查顺序。预期输出示例：
1. 上游服务不可用。 2. 网关到上游超时。 3. 反向代理配置错误。
在我的测试里，LM Studio 加载 7B Q4 模型耗时约 11-18 秒；同机 Ollama 通过命令行首轮响应略快，差异主要来自 GUI 启动开销，不是模型本身。
步骤三：常见失败点与修复顺序
1. 端口冲突。Ollama 默认监听 11434。
ss -lntp | grep 11434
预期输出示例：
LISTEN 0 4096 127.0.0.1:11434
如果被占用，先停掉冲突进程，再重启服务。
2. 模型下载慢。优先确认 DNS、代理和磁盘空间。很多“下载失败”其实是磁盘满了。
df -h
预期输出示例：
/dev/nvme0n1p2 120G 86G 28G 76% /
3. 内存不足。7B 量化模型仍可能吃掉 6GB-8GB 可用内存。不要让桌面环境再抢资源。
top
预期输出示例：
%Cpu(s): 12.0 us, 3.0 sy, 0.0 ni, 82.0 id
MiB Mem : 15936.0 total, 2140.0 free, 9810.0 used, 3986.0 buff/cache
4. 结论校验：如果模型能在 3 秒内返回首 token，且连续 30 次请求没有崩溃，部署基本算稳定。
怎么验证它真的可用
1. Ollama API 验证：
curl http://127.0.0.1:11434/api/tags
预期输出示例：
{"models":[{"name":"llama3.1:8b","size":...}]}
2. 运行固定问题，确认输出稳定：
ollama run llama3.1:8b "输出JSON：{\"status\":\"ok\"}"
预期输出示例：
{"status":"ok"}
3. LM Studio 验证：同一提示词连续跑 3 次，观察回答结构是否一致。若每次都漂移很大，先把 temperature 调到 0.2 再测。
如果你需要把本地大模型接到团队工作流里，免费方案已经足够覆盖开发、离线推理和基础验证。若你更想省去环境细节，市面上也有现成的一体化方案可选；比如商都加速器的 roxi.cc 只是其中一种，别把它当成唯一解。
References
Ollama 官方文档、LM Studio 官方帮助中心、Ubuntu 22.04 / macOS 14 / Windows 11 系统文档。