本地LLM部署：2025完整指南 - Ollama、vLLM、LocalAI、Jan、LM Studio等
掌握本地LLM部署，对比12+工具
本地部署大型语言模型 随着开发人员和组织寻求增强的隐私性、减少延迟和对AI基础设施的更大控制权，变得越来越流行。
目前市场上提供了多种先进的工具，用于在本地运行LLMs，每种工具都有其独特的优势和权衡。
这张漂亮的图片由 AI模型Flux 1 dev 生成。
在基于云的AI服务主导市场之前，人们认为在本地硬件上运行复杂的语言模型是不切实际的。如今，模型量化、高效的推理引擎和易于获取的GPU硬件的进步，使得本地LLM部署不仅可行，而且在许多使用场景中更受青睐。
本地部署的主要优势： 隐私与数据安全，无需按令牌计费的API费用，低延迟响应，完全的自定义控制，离线能力，以及对敏感数据的合规性要求。
TL;DR
| 工具 | 最适合 | API成熟度 | 工具调用 | GUI | 文件格式 | GPU支持 | 开源 |
|---|---|---|---|---|---|---|---|
| Ollama | 开发者，API集成 | ⭐⭐⭐⭐⭐ 稳定 | ❌ 有限 | 3rd party | GGUF | NVIDIA, AMD, Apple | ✅ 是 |
| LocalAI | 多模态AI，灵活性 | ⭐⭐⭐⭐⭐ 稳定 | ✅ 完整 | Web UI | GGUF, PyTorch, GPTQ, AWQ, Safetensors | NVIDIA, AMD, Apple | ✅ 是 |
| Jan | 隐私，简单性 | ⭐⭐⭐ Beta | ❌ 有限 | ✅ 桌面 | GGUF | NVIDIA, AMD, Apple | ✅ 是 |
| LM Studio | 新手，低规格硬件 | ⭐⭐⭐⭐⭐ 稳定 | ⚠️ 实验性 | ✅ 桌面 | GGUF, Safetensors | NVIDIA, AMD (Vulkan), Apple, Intel (Vulkan) | ❌ 否 |
| vLLM | 生产，高吞吐量 | ⭐⭐⭐⭐⭐ 生产 | ✅ 完整 | ❌ 仅API | PyTorch, Safetensors, GPTQ, AWQ | NVIDIA, AMD | ✅ 是 |
| Docker Model Runner | 容器工作流 | ⭐⭐⭐ Alpha/Beta | ⚠️ 有限 | Docker Desktop | GGUF（取决于） | NVIDIA, AMD | 部分 |
| Lemonade | AMD NPU硬件 | ⭐⭐⭐ 开发中 | ✅ 完整（MCP） | ✅ Web/CLI | GGUF, ONNX | AMD Ryzen AI（NPU） | ✅ 是 |
| Msty | 多模型管理 | ⭐⭐⭐⭐ 稳定 | ⚠️ 通过后端 | ✅ 桌面 | 通过后端 | 通过后端 | ❌ 否 |
| Backyard AI | 角色扮演 | ⭐⭐⭐ 稳定 | ❌ 有限 | ✅ 桌面 | GGUF | NVIDIA, AMD, Apple | ❌ 否 |
| Sanctum | 移动隐私 | ⭐⭐⭐ 稳定 | ❌ 有限 | ✅ 移动/桌面 | 优化模型 | 移动GPU | ❌ 否 |
| RecurseChat | 终端用户 | ⭐⭐⭐ 稳定 | ⚠️ 通过后端 | ❌ 终端 | 通过后端 | 通过后端 | ✅ 是 |
| node-llama-cpp | JavaScript/Node.js开发人员 | ⭐⭐⭐⭐ 稳定 | ⚠️ 手动 | ❌ 库 | GGUF | NVIDIA, AMD, Apple | ✅ 是 |
快速推荐：
- 新手： LM Studio 或 Jan
- 开发者： Ollama 或 node-llama-cpp
- 生产环境： vLLM
- 多模态： LocalAI
- AMD Ryzen AI PC： Lemonade
- 隐私优先： Jan 或 Sanctum
- 高级用户： Msty
Ollama
Ollama 已成为本地LLM部署最受欢迎的工具之一，特别是在喜欢其命令行界面和效率的开发人员中。它基于llama.cpp构建，通过智能内存管理和高效的GPU加速（支持NVIDIA（CUDA）、Apple Silicon（Metal）和AMD（ROCm）GPU），实现了出色的每秒令牌吞吐量。
关键功能： 通过命令如 ollama run llama3.2 简单的模型管理，兼容OpenAI的API以作为云服务的替代方案，支持Llama、Mistral、Gemma、Phi、Qwen等的广泛模型库，结构化输出能力，以及通过Modelfiles创建自定义模型。
API成熟度： 非常成熟，拥有稳定的OpenAI兼容端点，包括 /v1/chat/completions、/v1/embeddings 和 /v1/models。支持通过Server-Sent Events的完整流式传输，支持多模态模型的视觉API，但不支持原生函数调用。理解 Ollama如何处理并行请求 对于优化部署非常重要，尤其是在处理多个并发用户时。
文件格式支持： 主要支持GGUF格式，所有量化级别（Q2_K到Q8_0）。通过创建Modelfile可以自动从Hugging Face模型进行转换。为了高效存储管理，您可能需要 将Ollama模型移动到不同的驱动器或文件夹。
工具调用支持： Ollama已正式添加工具调用功能，使模型能够与外部函数和API进行交互。实现采用结构化方法，模型可以决定何时调用工具以及如何使用返回的数据。工具调用通过Ollama的API实现，并与特别训练用于函数调用的模型（如Mistral、Llama 3.1、Llama 3.2和Qwen2.5）一起工作。然而，截至2024年，Ollama的API尚未支持流式工具调用或tool_choice参数，这些功能在OpenAI的API中可用。这意味着您无法强制调用特定工具或在流式模式下接收工具调用响应。尽管有这些限制，Ollama的工具调用功能对于许多使用案例来说是生产就绪的，并且与Spring AI和LangChain等框架集成良好。该功能代表了与之前提示工程方法相比的重大改进。
何时选择： 适合喜欢CLI界面和自动化、需要可靠API集成的应用程序、重视开源透明度以及希望高效利用资源的开发人员。非常适合需要从OpenAI无缝迁移的应用程序。有关命令和配置的全面参考，请参见 Ollama快捷方式。
LocalAI
LocalAI 将自己定位为一个全面的AI堆栈，不仅支持文本生成，还支持包括文本、图像和音频生成在内的多模态AI应用。
关键功能： 包括LocalAI Core（文本、图像、音频、视觉API）、LocalAGI用于自主代理、LocalRecall用于语义搜索、P2P分布式推理能力以及用于结构化输出的约束语法。
API成熟度： 非常成熟，作为完整的OpenAI替代方案，支持所有OpenAI端点以及附加功能。包括完整的流式支持、通过OpenAI兼容工具API的原生函数调用、图像生成和处理、音频转录（Whisper）、文本到语音、可配置的速率限制以及内置的API密钥认证。LocalAI在诸如 使用LLM将HTML内容转换为Markdown 等任务上表现出色，得益于其多功能的API支持。
文件格式支持： 最具灵活性，支持GGUF、GGML、Safetensors、PyTorch、GPTQ和AWQ格式。多个后端包括llama.cpp、vLLM、Transformers、ExLlama和ExLlama2。
工具调用支持： LocalAI提供全面的OpenAI兼容函数调用支持，其扩展的AI堆栈特别启用了自主代理的强大工具调用能力。LocalAI的实现支持完整的OpenAI工具API，包括函数定义、参数模式以及单个和并行函数调用。该平台跨多个后端（llama.cpp、vLLM、Transformers）运行，并与OpenAI的API标准保持兼容，使迁移变得简单。LocalAI支持高级功能，如用于更可靠结构化输出的约束语法，并且有实验性支持Model Context Protocol（MCP）。工具调用实现成熟且生产就绪，尤其适用于Hermes 2 Pro、Functionary和最近的Llama模型等函数调用优化模型。LocalAI的工具调用方法是其最强的功能之一，提供灵活性而不牺牲兼容性。
何时选择： 适合需要多模态AI能力（超出文本）、模型选择最大灵活性、现有应用程序的OpenAI API兼容性以及高级功能（如语义搜索和自主代理）的用户。即使没有专用GPU也能高效运行。
Jan
Jan 采用不同的方法，优先考虑用户隐私和简单性，而不是高级功能，其100%离线设计包括无遥测和无云依赖。
关键功能： 类似ChatGPT的熟悉对话界面，带有标记为“快速”、“平衡”或“高质量”的干净模型库，具有导入/导出功能的对话管理，最小的配置和开箱即用的功能，llama.cpp后端，GGUF格式支持，自动硬件检测，以及用于社区插件的扩展系统。
API成熟度： 处于Beta阶段，提供OpenAI兼容的API，暴露基本端点。通过llama.cpp后端支持流式响应和嵌入，但工具调用支持有限，视觉API处于实验阶段。未设计用于多用户场景或速率限制。
文件格式支持： 与llama.cpp引擎兼容的GGUF模型，支持所有标准GGUF量化级别，具有简单的拖放文件管理。
工具调用支持： Jan在稳定版本中目前具有有限的工具调用能力。作为注重隐私的个人AI助手，Jan优先考虑简单性而不是高级代理功能。虽然底层llama.cpp引擎理论上支持工具调用模式，但Jan的API实现不暴露完整的OpenAI兼容函数调用端点。需要工具调用的用户需要手动进行提示工程方法或等待未来的更新。开发路线图表明计划改进工具支持，但当前的重点仍然是提供可靠的、以离线为主的聊天体验。对于需要强大函数调用的生产应用，请考虑LocalAI、Ollama或vLLM。Jan最适合用于对话AI使用案例，而不是需要工具编排的复杂自主代理工作流程。
何时选择： 完美适合优先考虑隐私和离线操作的用户，希望获得无配置体验，喜欢GUI而不是CLI，并需要本地ChatGPT替代方案用于个人使用的用户。
LM Studio
LM Studio 以其作为本地LLM部署最易用的工具而闻名，特别是对于没有技术背景的用户。
关键功能： 精美的GUI，具有直观的界面，模型浏览器便于从Hugging Face搜索和下载模型，通过视觉指标显示模型速度和质量的性能比较，用于测试的即时聊天界面，用户友好的参数调整滑块，自动硬件检测和优化，针对集成Intel/AMD GPU的Vulkan卸载，智能内存管理，优秀的Apple Silicon优化，本地API服务器带有OpenAI兼容端点，以及模型分割以在GPU和RAM上运行更大的模型。
API成熟度： 非常成熟且稳定，具有OpenAI兼容的API。支持完整流式传输、嵌入API、兼容模型的实验性函数调用以及有限的多模态支持。专注于单用户场景，没有内置的速率限制或认证。
文件格式支持： GGUF（llama.cpp兼容）和Hugging Face Safetensors格式。内置某些模型的转换器，并可以运行分割的GGUF模型。
工具调用支持： LM Studio在最近的版本（v0.2.9+）中实现了实验性工具调用支持，遵循OpenAI函数调用API格式。该功能允许在本地API服务器上通过训练有函数调用的模型（特别是Hermes 2 Pro、Llama 3.1和Functionary）调用外部工具。然而，LM Studio中的工具调用应被视为Beta质量——它在测试和开发中可靠，但在生产中可能会遇到边缘情况。GUI使定义函数模式和交互式测试工具调用变得容易，这对代理工作流程的原型设计非常有价值。模型兼容性差异显著，一些模型的工具调用行为比其他模型更好。LM Studio不支持流式工具调用或高级功能如并行函数调用。对于严肃的代理开发，请使用LM Studio进行本地测试和原型设计，然后部署到vLLM或LocalAI以获得生产可靠性。
何时选择： 适合本地LLM部署的新手，喜欢图形界面而不是命令行工具的用户，需要在低规格硬件（尤其是集成GPU）上获得良好性能的用户，以及想要专业用户体验的任何人。在没有专用GPU的机器上，由于Vulkan卸载能力，LM Studio通常比Ollama表现更好。许多用户通过 为本地Ollama实例的开源聊天UI 提升其LM Studio体验，这些UI也适用于LM Studio的OpenAI兼容API。
vLLM
vLLM 特别设计用于高性能、生产级LLM推理，其创新的PagedAttention技术减少了50%或更多的内存碎片，并将并发请求的吞吐量提高了2-4倍。
关键功能： PagedAttention用于优化内存管理，连续批处理用于高效多请求处理，跨多个GPU的分布式推理与张量并行，逐令牌流式传输支持，高吞吐量优化以服务大量用户，支持流行的架构（Llama、Mistral、Qwen、Phi、Gemma），视觉语言模型（LLaVA、Qwen-VL），OpenAI兼容的API，Kubernetes支持用于容器编排，以及内置的性能跟踪指标。
API成熟度： 生产就绪，具有高度成熟的OpenAI兼容API。完全支持流式传输、嵌入、工具/函数调用（包括并行调用能力）、视觉语言模型支持、生产级速率限制和基于令牌的认证。优化用于高吞吐量和批量请求。
文件格式支持： PyTorch和Safetensors（主要），GPTQ和AWQ量化，原生Hugging Face模型库支持。不原生支持GGUF（需要转换）。
工具调用支持： vLLM提供生产级、功能齐全的工具调用，100%兼容OpenAI的函数调用API。它实现了完整的规范，包括并行函数调用（模型可以同时调用多个工具）、tool_choice参数用于控制工具选择，以及工具调用的流式支持。vLLM的PagedAttention机制在复杂的多步骤工具调用序列中保持高吞吐量，使其非常适合服务于多个用户并发的自主代理系统。该实现与函数调用优化模型（如Llama 3.1、Llama 3.3、Qwen2.5-Instruct、Mistral Large和Hermes 2 Pro）配合使用效果很好。vLLM在API级别处理工具调用，自动验证函数参数的JSON模式，减少错误并提高可靠性。对于需要企业级工具编排的生产部署，vLLM是黄金标准，提供本地LLM托管解决方案中最高的性能和最完整的功能集。
何时选择： 最适合生产级性能和可靠性、高并发请求处理、多GPU部署能力和企业级LLM服务。当 比较NVIDIA GPU规格的AI适用性 时，vLLM的要求倾向于现代GPU（A100、H100、RTX 4090）具有高VRAM容量以获得最佳性能。vLLM在本地工具调用支持方面也表现出色，可以 从LLMs获取结构化输出。
Docker Model Runner
Docker Model Runner 是Docker在本地LLM部署方面的相对较新尝试，利用Docker的容器化优势，具有原生集成、Docker Compose支持用于轻松的多容器部署、简化卷管理用于模型存储和缓存，以及容器原生的服务发现。
关键功能： 预配置的容器，带有即用型模型镜像，精细的CPU和GPU资源分配，减少配置复杂性，以及通过Docker Desktop的GUI管理。
API成熟度： Alpha/Beta阶段，API正在演变。容器原生接口，底层引擎决定特定功能（通常基于GGUF/Ollama）。
文件格式支持： 容器打包模型，格式取决于底层引擎（通常为GGUF）。标准化仍在发展中。
工具调用支持： Docker Model Runner的工具调用能力继承自其底层推理引擎（通常为Ollama）。Docker的一项近期实际评估显示，本地模型工具调用存在重大挑战，包括急切调用（模型不必要的调用工具）、工具选择错误以及处理工具响应的困难。尽管Docker Model Runner通过其OpenAI兼容API支持工具调用，但可靠性因特定模型和配置而异。容器化层不添加工具调用功能，只是提供一个标准化的部署包装器。对于需要强大工具调用的生产代理系统，直接容器化vLLM或LocalAI比使用Model Runner更有效。Docker Model Runner的优势在于部署简化和资源管理，而不是增强的AI能力。工具调用体验仅与底层模型和引擎支持一样好。
何时选择： 适合已经在工作流程中广泛使用Docker的用户，需要无缝的容器编排，重视Docker的生态系统和工具，以及想要简化部署流水线的用户。有关详细分析，请参见 Docker Model Runner与Ollama比较，该比较探讨了在特定使用案例中选择每种解决方案的时机。
Lemonade
Lemonade 代表了一种新的本地LLM托管方法，特别针对AMD硬件进行优化，利用AMD Ryzen AI的NPU（神经处理单元）加速。
关键功能： 在Ryzen AI处理器上使用NPU加速进行高效的推理，结合NPU、iGPU和CPU的混合执行以获得最佳性能，第一类Model Context Protocol（MCP）集成用于工具调用，OpenAI兼容的标准API，轻量级设计具有最小的资源开销，支持具有工具访问能力的自主代理，包括Web UI、CLI和SDK的多种接口，以及针对AMD Ryzen AI（7040/8040系列或更新）的硬件特定优化。
API成熟度： 正在开发但迅速改进，具有OpenAI兼容端点和基于MCP的工具调用支持。语言无关的接口简化了跨编程语言的集成。
文件格式支持： GGUF（主要）和ONNX，具有NPU优化格式。支持常见的量化级别（Q4、Q5、Q8）。
工具调用支持： Lemonade通过其第一类Model Context Protocol（MCP）支持提供前沿的工具调用，这代表了对传统OpenAI风格函数调用的重大进化。MCP是由Anthropic设计的一种开放标准，旨在实现更自然和上下文感知的工具集成，使LLM在整个对话中更好地了解可用工具及其目的。Lemonade的MCP实现使与各种工具（包括网络搜索、文件系统操作、内存系统和自定义集成）的交互成为可能，所有这些都通过AMD NPU加速以提高效率。MCP方法相较于传统函数调用具有优势：更好的工具可发现性、跨多轮对话的改进上下文管理，以及跨不同模型的标准工具定义。虽然MCP仍在发展（已被Claude采用，正在扩展到本地部署），但Lemonade的早期实现使其成为下一代代理系统的领导者。最适合使用AMD Ryzen AI硬件的用户，其中NPU卸载在工具密集型代理工作流程中提供2-3倍的效率提升。
何时选择： 完美适合拥有AMD Ryzen AI硬件的用户，正在构建自主代理的用户，需要高效NPU加速的用户，以及希望获得前沿MCP支持的开发者。在AMD Ryzen AI系统上，相比仅使用CPU的推理，可以实现2-3倍更好的每瓦令牌效率。
Msty
Msty 专注于通过统一界面无缝管理多个LLM提供商和模型，与Ollama、OpenAI、Anthropic等后端一起工作。
关键功能： 与提供商无关的架构，快速模型切换，高级对话管理包括分支和分叉，内置提示库，能够在同一界面中混合本地和云模型，将多个模型的响应进行并排比较，以及跨平台支持（Windows、macOS、Linux）。
API成熟度： 用于连接现有安装的稳定状态。不需要单独的服务器，因为它扩展了Ollama和LocalAI等工具的功能。
文件格式支持： 依赖于连接的后端（通常通过Ollama/LocalAI的GGUF）。
工具调用支持： Msty的工具调用能力继承自其连接的后端。当连接到Ollama时，您会遇到其限制（没有原生工具调用）。当使用LocalAI或OpenAI后端时，您可以获得其完整的工具调用功能。Msty本身不添加工具调用功能，而是作为多个提供商的统一接口。这实际上是一个优势——您可以测试相同的代理工作流程以不同的后端（本地Ollama vs LocalAI vs 云OpenAI）进行比较，以评估性能和可靠性。Msty的对话管理功能对于调试复杂的工具调用序列特别有用，因为您可以在决策点分叉对话并比较不同模型如何处理相同的工具调用。对于构建多模型代理系统的开发人员，Msty提供了一种方便的方法来评估哪个后端在特定使用案例中提供最佳的工具调用性能。
何时选择： 适合管理多个模型的高级用户，需要比较模型输出的用户，具有复杂对话工作流程的用户，以及混合本地/云设置的用户。不是独立的服务器，而是现有LLM部署的高级前端。
Backyard AI
Backyard AI 专注于基于角色的对话和角色扮演场景，具有详细的角色创建、个性定义、多角色切换、长期对话记忆和以隐私为中心的本地处理。
关键功能： 带有详细AI个性配置文件的角色创建，多个角色人设，长期对话的记忆系统，面向非技术用户的友好界面，基于llama.cpp和GGUF模型支持，跨平台可用（Windows、macOS、Linux）。
API成熟度： 用于GUI使用的稳定状态，但API访问有限。主要专注于图形用户体验，而不是程序集成。
文件格式支持： 支持大多数流行聊天模型的GGUF模型。
工具调用支持： Backyard AI不提供工具调用或函数调用功能。它专为基于角色的对话和角色扮演场景设计，其中工具集成不相关。该应用程序专注于保持角色一致性、管理长期记忆和创建沉浸式对话体验，而不是执行函数或与外部系统交互。对于寻求基于角色的AI交互的用户，缺乏工具调用不是限制——它使系统能够完全优化自然对话。如果您需要能够使用工具的AI角色（例如可以检查真实天气或搜索信息的角色扮演助手），您需要使用其他平台，如LocalAI或构建结合角色卡和具备工具调用能力模型的自定义解决方案。
何时选择： 最适合创意写作和角色扮演，基于角色的应用，希望拥有个性化AI人设的用户，以及游戏和娱乐使用案例。不是为通用开发或API集成设计的。
Sanctum
Sanctum AI 强调隐私，提供离线优先的移动和桌面应用程序，具有真正的离线操作（无需互联网）、端到端加密用于对话同步、设备上处理（所有推理在本地进行）以及跨平台加密同步。
主要功能： 支持 iOS 和 Android 的移动应用（在 LLM 领域中较为罕见），对移动设备进行激进的模型优化，可选的加密云同步，家庭共享支持，优化后的较小模型（1B-7B 参数），为移动设备定制的量化处理，以及预打包的模型捆绑包。
API 成熟度： 对于预期的移动使用是稳定的，但 API 访问有限。它被设计为面向终端用户的应用程序，而不是开发者集成。
文件格式支持： 优化后的较小模型格式，支持为移动平台定制的量化处理。
工具调用支持： Sanctum 当前实现不支持工具调用或函数调用功能。作为一个以隐私和离线操作为重点的移动优先应用程序，Sanctum 优先考虑简单性和资源效率，而不是像代理工作流程这样的高级功能。它运行的较小模型（1B-7B 参数）即使基础设施支持，通常也不适合可靠的工具调用。Sanctum 的价值主张是为日常使用提供私密的设备端 AI 聊天——阅读电子邮件、起草消息、回答问题，而不是复杂的自主任务。对于需要工具调用功能的移动用户，移动硬件的架构限制使得这成为不切实际的期望。基于云的解决方案或带有较大模型的桌面应用程序仍然是需要工具集成的代理工作流程的必要选择。
何时选择： 完美适用于移动 LLM 访问、注重隐私的用户、多设备场景以及随时可用的 AI 协助。由于移动硬件的限制，仅限于较小的模型，且不太适合需要较大模型的复杂任务。
RecurseChat
RecurseChat 是一个面向习惯使用命令行的开发者的基于终端的聊天界面，提供带有 Vi/Emacs 键绑定的键盘驱动交互。
主要功能： 本地终端操作，支持多后端（Ollama、OpenAI、Anthropic），代码块语法高亮，会话管理以保存和恢复对话，可脚本化的 CLI 命令用于自动化，使用 Rust 编写以实现快速高效的操作，依赖项少，可通过 SSH 使用，并与 tmux/screen 兼容。
API 成熟度： 稳定，使用现有的后端 API（如 Ollama、OpenAI 等）而不是提供自己的服务器。
文件格式支持： 依赖所使用的后端（通常通过 Ollama 使用 GGUF 格式）。
工具调用支持： RecurseChat 的工具调用支持取决于连接的后端。使用 Ollama 后端时，会继承 Ollama 的限制。使用 OpenAI 或 Anthropic 后端时，可以获得其完整的函数调用能力。RecurseChat 本身不实现工具调用，但提供一个终端界面，使调试和测试代理工作流程变得方便。对 JSON 的语法高亮使得检查函数调用参数和响应变得容易。对于构建命令行代理系统或通过 SSH 在远程环境中测试工具调用的开发者，RecurseChat 提供了一个没有 GUI 负载的轻量级界面。其可脚本化的特性也允许通过 shell 脚本自动化代理测试场景，使其在需要验证不同模型和后端上工具调用行为的 CI/CD 管道中具有价值。
何时选择： 适合偏好终端界面的开发者、通过 SSH 访问远程服务器、需要脚本和自动化功能以及与终端工作流程集成的用户。不是独立服务器，而是高级终端客户端。
node-llama-cpp
node-llama-cpp 将 llama.cpp 带入 Node.js 生态系统，通过原生 Node.js 绑定提供直接的 llama.cpp 集成，并支持完整的 TypeScript 以及完整的类型定义。
主要功能： 逐词流式生成，文本嵌入生成，程序化模型管理以下载和管理模型，内置聊天模板处理，原生绑定在 Node.js 环境中提供接近原生的 llama.cpp 性能，专为构建带有 LLM 的 Node.js/JavaScript 应用程序、带有本地 AI 的 Electron 应用程序、后端服务和带有打包模型的无服务器函数而设计。
API 成熟度： 稳定且成熟，具有全面的 TypeScript 定义和对 JavaScript 开发者良好的文档 API。
文件格式支持： 通过 llama.cpp 支持 GGUF 格式，并支持所有标准量化级别。
工具调用支持： node-llama-cpp 需要通过提示工程和输出解析手动实现工具调用。与具有原生函数调用的基于 API 的解决方案不同，您必须在 JavaScript 代码中处理整个工具调用工作流程：定义工具模式、将它们注入提示中、解析模型响应中的函数调用、执行工具并将结果反馈给模型。虽然这为您提供了完全的控制和灵活性，但与使用 vLLM 或 LocalAI 的内置支持相比，这需要显著更多的工作。node-llama-cpp 最适合希望在 JavaScript 中构建自定义代理逻辑并需要对工具调用过程进行细粒度控制的开发者。TypeScript 支持使定义类型安全的工具接口变得更加容易。考虑使用像 LangChain.js 这样的库来抽象工具调用的样板代码，同时保持本地推理的好处。
何时选择： 适合 JavaScript/TypeScript 开发者、Electron 桌面应用程序、Node.js 后端服务以及快速原型开发。提供程序控制而不是独立服务器。
结论
选择合适的本地 LLM 部署工具取决于您的具体需求：
主要推荐：
- 初学者： 从 LM Studio 开始，因为其出色的用户界面和易用性，或者使用 Jan 以隐私优先的简洁性
- 开发者： 选择 Ollama 用于 API 集成和灵活性，或者 node-llama-cpp 用于 JavaScript/Node.js 项目
- 隐私爱好者： 使用 Jan 或 Sanctum 以获得带有可选移动支持的离线体验
- 多模态需求： 选择 LocalAI 以获得超越文本的全面 AI 能力
- 生产部署： 部署 vLLM 以获得具有企业功能的高性能服务
- 容器工作流程： 考虑 Docker Model Runner 以实现生态系统集成
- AMD Ryzen AI 硬件： Lemonade 利用 NPU/iGPU 实现出色性能
- 高级用户： Msty 用于管理多个模型和提供商
- 创意写作： Backyard AI 用于基于角色的对话
- 终端爱好者： RecurseChat 用于命令行工作流程
- 自主代理： vLLM 或 Lemonade 用于强大的函数调用和 MCP 支持
关键决策因素： API 成熟度（vLLM、Ollama 和 LM Studio 提供最稳定的 API），工具调用（vLLM 和 Lemonade 提供一流的函数调用），文件格式支持（LocalAI 支持最广泛的范围），硬件优化（LM Studio 在集成 GPU 上表现最佳，Lemonade 在 AMD NPU 上表现最佳），以及模型多样性（Ollama 和 LocalAI 提供最广泛的模型选择）。
本地 LLM 生态系统正在迅速成熟，2025 年带来了 API 标准化（所有主要工具的 OpenAI 兼容性）、工具调用（MCP 协议的采用使自主代理成为可能）、格式灵活性（更好的转换工具和量化方法）、硬件支持（NPU 加速、改进的集成 GPU 利用率）和专用应用（移动、终端、基于角色的界面）的重大进展。
无论您是否担心数据隐私、想要减少 API 成本、需要离线功能，还是需要生产级性能，本地 LLM 部署从未如此易于访问或强大。本指南中审查的工具代表了本地 AI 部署的前沿，每个工具都解决了不同用户群体的具体问题。
有用的链接
- 如何将 Ollama 模型移动到不同的磁盘或文件夹
- Ollama 快速参考
- Ollama 如何处理并行请求
- 比较 NVidia GPU 规格对 AI 的适用性
- 本地 Ollama 实例上的开源 LLM 聊天界面
- 从 LLM 获取结构化输出：使用 Ollama、Qwen3 与 Python 或 Go
- 使用 LLM 和 Ollama 将 HTML 内容转换为 Markdown
- Docker Model Runner 与 Ollama：选择哪个？
