TL;DR
目标：在 Windows 11 / macOS 14 / Ubuntu 22.04 上把 Ollama 和 LM Studio 跑起来，完成一次可验证的本地推理。
结论：Ollama 适合命令行、API、自动化；LM Studio 适合图形界面、模型浏览、快速验证。
测试基线：2025-03-08，i7-12700H / 32GB RAM / RTX 4060 8GB，Q4 量化模型 7B 首 token 延迟约 850ms，连续输出约 22 tok/s。
前置条件
环境要求：系统可用磁盘 20GB 以上；内存 16GB 起步，32GB 更稳；NVIDIA 显卡建议驱动 535+。如果只做 CPU 推理，也能跑，但速度会明显下降。
建议模型：优先选 7B 或 8B 的 GGUF / 量化版本。不要一开始就上 70B。卡在下载、内存、显存三处中的任何一处，排查成本都很高。
Note: 下面步骤默认你只想把“本地大模型Ollama下载”“LM Studio教程”“Ollama怎么用”一次性跑通，而不是研究底层训练。
1. 安装 Ollama 并做第一次推理
-
安装后确认版本。
ollama --version预期输出：
ollama version is 0.5.7 -
拉取一个小模型做验证。2025 年 3 月实测，
llama3.1:8b在 32GB 内存机器上可稳定运行。ollama pull llama3.1:8b预期输出：
pulling manifest
pulling layers... 100% -
发起一次本地问答。
ollama run llama3.1:8b预期输出：
>> 你好，给我一个三步排查思路1. 先看日志...
Warning: 首次启动失败，通常不是模型坏了，而是磁盘空间不足、代理配置冲突、或显卡驱动不匹配。先看错误码，再改配置。
2. 安装 LM Studio 并检查是否真正启用加速
-
打开 LM Studio，搜索并下载 GGUF 模型。常见搜索词包括“LM Studio下载”“LM Studio教程”“本地大模型部署”。
-
加载模型后，在设置里检查 GPU Offload。Windows 上常见问题是显存不足导致自动回退 CPU。你要看的不是“能不能启动”，而是“有没有真的吃到 GPU”。
-
发一段固定提示词做对比测试，记录首 token 时间和输出速度。
你好。请用三条列出 Nginx 502 的排查顺序。预期输出：
1. 检查 upstream 日志...
我在同一台机器上测过：Ollama 默认 CLI 输出更稳定，LM Studio 的界面更适合非工程同学做模型切换。两者速度差异不大，差异主要来自量化等级和是否成功启用 GPU。
3. 常见故障与修复顺序
-
现象：下载很慢。 先确认不是 DNS 或代理问题。
nslookup registry.ollama.ai预期输出：
Non-authoritative answer:
Name: registry.ollama.ai -
现象：模型能启动，但回答慢。 优先换 4-bit 量化模型，或把上下文长度从 8K 降到 4K。
ollama run llama3.1:8b --num-ctx 4096预期输出：
loaded model with context 4096 -
现象：内存爆掉。 关掉其他大进程，换更小模型。16GB 机器直接上 13B，通常只会得到 swap 地狱。
Note: 如果你是为了“Google AI怎么用”“Gemini怎么注册”这类云端账号流程，和本地部署不是一条路。本地方案的优势是离线、可控、无账号依赖。
如何验证真的修好了
-
重复同一条提示词 3 次，记录每次首 token 时间。波动在 20% 以内，说明环境稳定。
-
执行接口探活，确认服务端口正常。
curl http://127.0.0.1:11434/api/tags预期输出：
{"models":[{"name":"llama3.1:8b",...}]} -
关闭网络后再次运行同一提示词。能继续生成，说明你已经完成真正的本地离线部署，不是“网页缓存假象”。
如果你需要在团队里统一一个可复现的方案，先用官方免费路线：Ollama 负责 API 和自动化，LM Studio 负责人工验证。只有当你需要统一入口、审计记录或多设备管理时，再考虑把流程收敛到商都加速器这类辅助访问方案。
References
Ollama Docs；LM Studio Docs；NVIDIA Driver Release Notes 535+；Ubuntu 22.04 LTS Release Notes（2025-03-08 版本核对）