n8n 如何在自托管 LLM 与云 API 之间路由

Self-Hosted LLM vs. Cloud APIs: How to Route Between Them

自托管 LLM 可以让你更好地控制数据存储的位置。如果模型和处理其请求的工作流都运行在你控制的基础设施上，提示词就可以留在你的网络内，而不必经过外部提供商。

对于敏感工作负载而言，自托管可能很有吸引力。但它也需要硬件、维护和运营开销，而基于云的 API 大多会替你承担这些工作。

混合方案提供了一种将请求路由到本地或云端的方式，无需管理两个相互割裂的系统。

最适合自托管的 LLM 开放权重模型

开放权重模型会提供其训练好的模型权重，供你下载并在自己的基础设施上运行。

先考虑你希望模型完成的任务，并通过 OpenRouter 或其他提供商试用开放权重模型。找到能够可靠处理任务的最小模型后，就可以将其部署到自己的基础设施上。较小的模型通常需要更少的算力，响应速度也更快；因此，只有当更大的规模能够切实改善工作流结果时，才有必要升级到更大的模型。

参数量（Params）是 parameters 的简称，用于衡量模型的规模。例如，24B 模型大约有 240 亿个训练参数。模型越大，能力可能越强，但所需的算力和内存也越多。

最低显存（Min VRAM）是运行模型所需 GPU 显存的大致最低容量。如果模型无法装入现有显存，你就需要选择更小的模型、模型的量化版本，或使用更强的硬件来支持它。

以下是一些适合自托管的开放权重模型，以及它们的参数量和建议最低显存。

向下滚动查看更多 →

模型	参数量	最低显存*	最适合的用途
Phi-4-mini	3.8B	~8 GB	适合硬件有限时，作为本地助手和相关任务的轻量级起点
Qwen3 8B	8B	~8 GB（8-bit 配置）	适用于聊天、编程和多语言工作负载的通用选项，无需高端 GPU 硬件
Gemma 3 12B	12B	~12–16 GB（量化后）	通用推理、摘要，以及理解文本和图像等多模态任务
DeepSeek R1-Distill-Qwen-14B	14B	~12–16 GB（量化后）	适合推理密集型任务：当你需要比更小的本地模型更强的能力，但又不想运行大得多的模型时
Mistral Small 3.1	24B	~12–16 GB（4-bit 量化），~44–55 GB（未量化）	更高要求的本地应用，包括函数调用、编程、长篇文档和多模态工作流
Llama 4 Scout	总计 109B，17B 激活	~55–80 GB	高端私有 LLM 部署、大型文档分析和多模态工作负载

运行开放权重模型所需的条件

选择开放权重模型后，请确认你的硬件和推理环境能否支持它运行日常工作流。显存决定 GPU 能够处理的模型上限，而量化则会降低加载模型所需的内存。

标准的自托管 LLM 技术栈

一个自托管 LLM 设置通常包含协同工作的五个层次：

硬件：GPU 提供显存和算力，决定你可以运行哪些模型，以及模型的响应速度。
模型：你为任务选择的 LLM 和开放权重模型。
推理运行时：像 Ollama 或 vLLM 这样的软件会加载模型，并将其提供给其他应用程序使用，通常通过 API 实现。
检索层：如果模型需要私有或特定领域的信息，检索增强生成（RAG）可以让系统搜索外部知识源中的相关信息，并在生成答案前将这些上下文添加到模型的请求中。
应用层：向模型发送请求并使用响应的聊天界面、API 或工作流。

VRAM 和量化

模型权重在加载模型进行推理时需要 VRAM。当权重和运行时要求能够容纳在 GPU 内存中时，GPU 可以执行相关计算，而无需依赖速度更慢的系统内存。如果无法容纳，推理引擎可能会将数据或计算卸载到系统内存或 CPU，这会降低性能。

量化通过使用更少的比特表示模型权重来减少所需的内存。这意味着你可以在同一块 GPU 上运行更大的模型。适度量化可以保留模型输出的大部分质量，但过度压缩可能会影响数值推理等复杂任务。

自托管与云托管解析

你可以在本地运行 LLM，但这并不意味着你应该以这种方式处理每个请求。某些工作负载可能受益于将处理保留在你的基础设施内，而其他工作负载可能需要云服务提供商的规模或能力。

混合设置让你可以根据一些因素，为每种请求类型选择最佳路径。

隐私与合规要求

AI 系统可能会处理敏感数据或受监管数据，而你的组织可能对这些数据的处理或传输地点存在法律、合同或内部限制。例如，GDPR 第 V 章规定了向第三国或国际组织传输个人数据的条件。

在本地运行模型可以更容易地满足数据驻留合规要求，因为你可以控制处理发生的位置。但自托管并不会让系统自动合规，因为你还需要针对访问、日志记录和存储采取安全措施。某些云托管模型（尤其是提供企业级 SLA 的模型）可能具备更严格的访问控制和其他防护措施。

Self-Hosted LLM vs. Cloud APIs: How to Route Between Them — *帮助决定使用哪种 LLM（本地还是云端）的示意图*

成本与盈亏平衡量

云 API 通常按使用量收费，令牌越多，账单越高。使用自托管时，你需要为硬件和运营人员付费，并将这些成本分摊到系统处理的所有请求上。

盈亏平衡点是指运行自有设置的总成本低于使用云 API 成本的时刻。如果你的使用量较低或不可预测，使用云服务可能更经济。但如果你要处理大量且稳定的请求，自托管可能是更适合你组织的选择。

💡

如果你使用 LLM 进行批处理，这里还有一个实用建议。你可以租用像 runpod 这样的 GPU 驱动 VPS，并仅在需要处理数据时运行它。这样，你既能确保相对的数据隐私，又能降低成本，因为 VPS 只会在必要时运行。

延迟与前沿能力

如果你拥有合适的硬件，本地 LLM 模型可以提供可预测的延迟。它还可以避免与外部提供商之间的网络往返。但本地推理并不总是更快。在受限硬件上运行的大型模型，可能会比经过优化的云服务慢得多。

云服务商可以提供高度优化的基础设施，并访问前沿模型，也就是目前可用的、最适合处理复杂推理任务的模型。如果任务需要额外的能力，那么前沿模型增加的延迟可能值得将任务发送给云模型。

以下是自托管 LLM 与云 API 之间的主要区别。

	自托管 LLM	云 API
隐私	能够更好地控制系统处理和处理数据的位置	外部服务商会根据其服务条款和数据处理条款处理数据
成本	较高的固定基础设施和运营成本	按使用量或 token 计费
延迟	只要本地容量充足，就可以保持可预测	取决于网络、服务商容量和速率限制
前沿能力	仅限于你能够部署和运行的模型	更容易访问最新的领先模型
维护	由内部团队管理	主要由服务商负责

在 n8n 中于本地 LLM 与云端 LLM 之间进行路由

确定哪些请求在本地运行、哪些请求应发送到云端后，你仍然需要一种可靠的方法来为每个请求应用规则。你可以将这些逻辑硬编码到各个应用中，但随着你添加新的模型和规则，这种方式会越来越难以检查和更新。

这正是 n8n 的用武之地。n8n 是一个源代码可用的自动化平台，工程团队可以在其中创建 AI 代理和代理式工作流。你还可以在同一个工作流中连接本地模型和云端模型，并使用路由逻辑，根据工作负载类型、复杂度或数据敏感性，决定每个请求所采用的路径。

基本的混合工作流如下所示。

决定哪些信息会影响路由： 尽可能使用你已有的信息，例如敏感性标记、任务类型、请求量或复杂度评分。
连接本地路径： 添加 Ollama Chat Model 节点，并使用实例的 Base URL 创建一个 Ollama credential。如果工作流需要能够使用工具的代理，可以将聊天模型连接到 AI Agent 节点，由该模型决定采取何种操作。
添加云端路径： 添加你想使用的云服务商的聊天模型节点，例如 OpenAI Chat Model 或 Anthropic Chat Model 节点。这样，工作流就拥有了第二条路径，用于需要使用云端处理的任务。
选择请求的路由方式： 当一个 AI 代理或链应根据你定义的规则使用不同的语言模型时，使用 Model Selector node。它会按顺序检查这些规则，并将第一个匹配的模型提供给同一个代理或链。当你需要将更大的工作流拆分为两个独立分支时，使用 If node；当你需要多个具有不同后续步骤的分支时，使用 Switch node。
定义规则： 根据任务类型、复杂度或数据敏感性对请求进行路由。在将请求发送给云模型之前，先执行数据敏感性检查。如果代理需要检查敏感内容才能确定适当的路由，请先在本地运行检查。
测试两条路径：通过工作流运行具有代表性的本地和云端请求，并检查执行情况，以确认每条规则都经过预期的模型。加入一个敏感测试用例，以验证受限数据绝不会到达云端分支。

使用 n8n 灵活配置你的 LLM

混合式设置让你可以随着模型、工作流需求和成本的增长，灵活调整自托管 LLM 策略。你无需将所有工作负载都固定在单一环境中，而是可以根据不同请求随时间调整分配，并保留周围的

使用 n8n 灵活配置你的 LLM

立即从云端路由开始，并随着需求变化添加本地模型

免费试用 n8n Cloud