从零开始构建本地 AI 技术栈

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI模型价格对比 | AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

大多数本地 AI 环境在两周内就会失败。不是因为硬件选错了或模型不好——而是因为运行时层是为了演示而选择的，而不是为了日常使用。

你安装了某个工具，让模型给出响应，感觉还不错，然后三天后你又回到 ChatGPT，因为本地的东西调用起来太麻烦了。修复这个问题大概只需要一个下午，而关键在于理解：不存在单一的运行时——而是有五个，每一个在技术栈中占据不同的位置。

完整的演进路径是：Ollama（日常使用）→ LM Studio（评估）→ MLX（Apple 原生）→ vLLM（服务部署）→ TensorRT-LLM（生产环境）。为正确的任务选择正确的工具，技术栈就会变得持久耐用。混淆它们，你就会不断从头重建。

以下是每一层的思考方式。

1、无人谈论的基础：llama.cpp

在上述所有运行时之前，还有 llama.cpp。大多数人从未直接调用过它，但它几乎是本地推理世界中所有东西的底层基础。它创建了 GGUF——你会经常遇到的通用量化模型格式。它支持在 CPU、Apple Metal、CUDA 和 Vulkan 上运行。正是因为它，一个 4-bit 量化的 70B 模型可以装进 40GB 内存，而不是 140GB。

你不需要直接操作 llama.cpp。但你应该知道它的存在，因为当你的技术栈出现问题时，理解 Ollama 本质上就是 llama.cpp 的简洁封装，能让你知道该去哪里排查。

GGUF 格式之所以重要，有一个具体原因：量化。一个 Q4_K_M 量化模型用少量的质量损失换取了大幅降低的内存占用和推理成本。对于大多数个人工作负载——写作、编程辅助、文档搜索——质量差异可以忽略不计。对于需要深度推理的任务，你需要 Q8 或全精度。了解这一点，你就能做出有意识的权衡，而不是随便从 Hugging Face 搜索结果顶部抓取文件。

2、Ollama：你每天真正会用的工具

Ollama 是日常使用的正确默认选择。不是因为它最快或最可配置——它不是——而是因为它让本地推理感觉像是电脑的正常组成部分，而不是你从未完成的周末项目。

Ollama 提供的功能：简洁的 CLI，运行在 localhost:11434 的本地服务器，简单的模型注册表（ollama pull llama3.2，搞定），以及与 OpenAI 兼容的 API 接口。最后一点是最重要的。任何知道如何与 OpenAI API 通信的工具，都可以指向你的本地 Ollama 实例。Continue（本地编程辅助的 VS Code 扩展）、Open Web UI、用于终端代码编辑的 Aider——它们都可以无需修改地对接 Ollama。

设置确实很简单。安装 Ollama，拉取模型，你就拥有了一个本地推理服务器。对于配备 64GB 内存的 Mac mini M4 Pro，ollama pull qwen2.5-coder:32b 可以给你一个强大的编程模型。ollama pull nomic-embed-text 可以给你一个用于本地检索的嵌入模型。两者同时运行，无需 GPU。

Ollama 做不好的是批处理。如果你要服务多个用户或运行高吞吐量的智能体循环，Ollama 的单请求处理模式就会成为瓶颈。这没关系——这不是它的设计目标。Ollama 是日常驱动工具。你从编辑器、启动器（Raycast 或 Alfred 都支持 LLM 集成）、终端调用它。目标是在你工作的任何地方，零摩擦地获取模型响应。

如果你想通过本地模型运行 Claude Code 来降低成本，Ollama 就是你指向的本地端点。

3、 LM Studio：评估工作台

LM Studio 是你在将模型纳入技术栈之前，想要深入了解模型时去的地方。它是一个精美的 GUI，用于加载 GGUF 模型，并排测试不同的量化级别，查看模型在你的硬件上的实际表现，然后再将其接入任何东西。

工作流程是：新模型发布（比如 Gemma 4 或新的 Qwen 版本），你将其拉入 LM Studio，运行标准的测试提示集，检查 Q4 与 Q8 的延迟和质量，决定它是否属于你的技术栈。然后你将胜出者移到 Ollama 供日常使用。

LM Studio 也有自己的 OpenAI 兼容服务器模式，所以你可以在评估期间将其作为 Ollama 的直接替代品。但我建议将两者的角色分开。LM Studio 用于评估，Ollama 用于生产环境的日常使用。混用意味着你永远不确定哪个运行时真正在为你的工具提供服务。

一个被低估的功能：LM Studio 实时显示 token 生成速度、内存使用情况和上下文窗口利用率。当你试图弄清楚 70B 模型在 Q4_K_M 下在你的硬件上交互使用是否足够快时，这很重要。你关心的指标是首个 token 的每秒 token 数（首个 token 时间）和持续生成速度。对于交互使用，你希望首个 token 在 2 秒以内，持续生成速度在每秒 15 个 token 以上。再慢的话，模型就会开始感觉像是一种负担。

4、MLX：Apple Silicon 原生路径

如果你使用的是 Apple Silicon，即使不直接使用 MLX，也值得了解它。这是 Apple 的机器学习框架，针对 M 系列芯片的统一内存架构进行了优化。与 llama.cpp/Ollama 的关键区别在于，MLX 原生在 Metal GPU 上运行，无需 llama.cpp 使用的转换层。

在实践中，这意味着在 Apple 硬件上，某些模型尺寸的推理速度更快。MLX 社区一直在快速移植流行模型——你可以找到 Llama 4、Qwen、Gemma 4 和 Mistral 模型的 MLX 格式版本。mlx-lm Python 包是主要的入口点。

权衡之处在于生态系统的成熟度。Ollama 有更广泛的工具兼容性。MLX 需要更多的手动设置，没有即插即用的集成方案。我的建议：当你确定了某个特定模型和工作负载的性能差异确实重要时——通常是长上下文工作或大模型在推动机器内存极限时——才使用 MLX。对于其他一切，Ollama 的简洁性胜出。

配备 128GB 或 256GB 统一内存的 Mac Studio M4 Max 是 MLX 开始展现其他硬件难以复制优势的地方。一个 70B 模型以全精度运行需要 140GB。在 128GB 的 Mac Studio 上，你可以以 Q6 或 Q8 量化运行 70B 模型，获得接近全精度的质量。这是一台严肃的本地推理机器，MLX 是其原生性能路径。

5、vLLM：当本地推理成为基础设施

vLLM 是完全不同类别的工具。它不是用于个人使用的——它是用于服务部署的。如果你在构建内部产品、运行团队共享的推理端点，或操作需要真正吞吐量的智能体循环，vLLM 就是对话的起点。

关键特性是连续批处理。vLLM 不像 Ollama 那样一次处理一个请求，而是动态批处理传入的请求，大幅提高 GPU 利用率和吞吐量。在配备 32GB GDDR7 的 RTX 5090 上，Ollama 和 vLLM 在并发请求方面的差异是显著的——vLLM 可以在同一模型下处理每秒 10-20 倍以上的请求。

vLLM 也有与 OpenAI 兼容的 API，所以指向 Ollama 的相同工具也可以指向 vLLM。迁移路径是：用 Ollama 原型验证，验证模型和工作流，当你需要服务多人或运行高容量批处理作业时，用 vLLM 部署。

设置更加复杂。你需要 CUDA、合适的 Python 环境，以及在多 GPU 上运行时需要了解如何配置张量并行。但回报是真实的：如果你在本地运行长时间的智能体循环，vLLM 的吞吐量意味着你可以运行更多循环、更长时间，而不会让推理成为瓶颈。而且由于你支付的是电费而不是按 token 的 API 费用，长时间运行的智能体的经济学完全改变了。这与 open-claw 现象的洞察相同——人们设置好本地推理，然后真正运行他们在按 token 付费时心理上回避的长时间智能体循环。

6、TensorRT-LLM 及以上：生产级别

TensorRT-LLM、SG-Lang 和 Nvidia NeMo 是严肃的部署级别。这些不是个人计算工具——它们是当你已经投入 CUDA 基础设施并需要从中挤出每一分性能时使用的。

TensorRT-LLM 将模型编译为针对特定 Nvidia GPU 架构优化的推理引擎。编译步骤需要时间（大模型有时需要数小时），但生成的引擎在同一硬件上比 vLLM 快得多。延迟、结构化生成和大规模服务经济学是 TensorRT-LLM 证明其复杂性的地方。

Nvidia DGX Spark 是这一级别对个人有意义的硬件背景。桌面上的一颗 Grace Blackwell 芯片，配备 128GB 一致性统一内存——与数据中心 GPU 相同的架构类别，打包为个人设备。如果你在 DGX Spark 上运行 TensorRT-LLM，你就拥有了一台严肃的本地推理机器，可以处理原本需要云 GPU 实例的工作负载。

对于大多数阅读本文的人来说，TensorRT-LLM 是一个愿景。知道它存在，了解它在技术栈中的位置，当你的工作负载需要应对这种操作复杂性时再重新考虑它。

7、模型层：你实际运行的内容

运行时技术栈是持久的东西。模型是可替换的东西。但你仍然需要一个思维模型来了解哪些模型适合哪些位置。

从角色角度而非模型名称来思考。你需要：一个快速的小模型用于廉价的交互调用（Gemma 4 2B 或 Qwen 2.5 1.5B），一个强大的通用模型用于困难的本地工作（Llama 4 Scout 或 Qwen 2.5 72B），一个专门的编程模型（Qwen 2.5 Coder 32B 或 DeepSeek Coder 变体），一个用于检索的嵌入模型（nomic-embed-text 或 Qwen 嵌入模型），以及用于本地转录的 Whisper。

Llama 4 Scout 和 Maverick 模型值得了解，因为它们是混合专家（mixture-of-experts）架构——问题不在于模型有多大，而在于每个 token 激活了多少。这显著改变了内存和计算的数学模型。GPT-OSS-20B 和 GPT-OSS-120B 是 OpenAI 的宽松许可（Apache 2.0）推理模型——你在自己控制的基础设施上运行的权重，而不是通过 API 调用的模型。

8、记忆层：让它产生复利效应

没有记忆的运行时是一个无状态工具。有用，但不会产生复利。

记忆层位于模型之外。你的笔记、文档、会议记录、代码决策和项目状态需要存储在模型可以查询的持久化位置。严肃工作的正确默认选择是带 pgvector 的 Postgres——关系数据、元数据、权限和向量搜索在一个地方。对于个人使用，带 sqlite-vec 的 SQLite 是轻量级版本：单个文件，易于备份，易于理解。

最重要的架构原则：在数据库中将原始数据和嵌入分开。当更好的嵌入模型出现时（它一定会出现），你可以在不丢失源文档的情况下重建向量索引。大多数检索失败不是模型失败——它们是管道失败，通常是由于没有考虑文档结构的分块策略。PDF 需要与 markdown 不同的处理方式。会议记录需要说话人标签和时间戳。代码需要符号感知索引。

Open Brain 是一个专门为此构建的开源记忆系统——SQL 驱动的数据库加嵌入管理加 MCP 服务器，这样 Claude 或任何其他模型都可以通过标准工具接口查询你的记忆。MCP 服务器是将本地记忆连接到任何模型客户端的正确方向，但要像对待任何其他工具接口一样对待它：它需要权限、日志和边界。写作智能体不需要 shell 访问权限。会议摘要器不需要删除文件的权限。

9、接口原则：多个界面，一套技术栈

最后一个失败模式是接口。一个拥有出色运行时但没有舒适使用界面的系统，是一个你最终会停止使用的系统。

原则是：多个界面，底层一套技术栈。你的编辑器（Continue 指向 Ollama）、你的笔记应用、你的浏览器、你的启动器（带 LLM 集成的 Raycast 或 Alfred）、你的终端（用于代码编辑的 Aider）和你的录音器（用于转录的 Whisper）——这些都不应该有独立的记忆层。它们都应该调用相同的本地运行时和相同的记忆层。

这是大多数 AI 产品不会给你的部分，因为它们的商业模式依赖于拥有输入通道之下的记忆。你在 ChatGPT、Claude、Notion 中积累记忆——然后你无法迁移它，因为向量嵌入存在于它们的基础设施中，而不是你的。本地推理加上你自己的记忆层解决了这个问题。知识库可以跨工具、跨模型、跨时间产生复利。

10、路由决策

个人 AI 技术栈本质上是一个路由系统。一些工作留在本地，因为它们是私密的、重复的或上下文密集的。一些工作去云端，因为它们是罕见的、困难的或需要前沿能力的。

力量来自于你有意识地做出路由决策，而不是默认使用云服务提供商想要的。前沿模型是你为难题聘请的专家——不是你的文件系统，不是你的记忆层，不是你的工作流引擎。

正确构建运行时技术栈，你买的不是一个模型设备。你构建的是一个新模型可以插入、新运行时可以替换、新智能体可以调用的基础设施——当它们离开时，不会带走你的知识库。

你桌上的机器有一份工作。在它到来之前，先给它安排好。

原文链接: How to Build a Local AI Stack from Scratch: Ollama to vLLM, Step by Step

汇智网翻译整理，转载请标明出处