自托管大语言模型网络：一个网关替代每个模型单独的服务器

添加开放权重模型并不意味着每个应用都需要新的主机名和对等连接。类似LiteLLM的网关只需维护一个端点，而后端则可在其背后进行更换。

1044 词

自托管开放权重模型通常起步很简单：一个模型、一个主机名、一条顺畅的访问路径。但当出现第二个和第三个模型时问题就来了。每个新的权重文件往往都需要额外的网络配置、对等连接设置以及应用配置——尽管产品仅要求增加一个模型标识。在后端之前放置网关，虽然能让模型在背后频繁更替，但仍能保持单一的访问端点。这其中的教训是架构层面的，而非针对特定产品：不必再向每个客户详细讲解每台GPU设备的拓扑结构。

一切始于一个模型

最初是一个在本地运行的开放权重Qwen类检查点，通过主机名对外提供访问：

llm.my-app.com

应用程序会使用模型名称及其余请求数据来调用该端点。流量传输正常，控制面板显示也一切良好。后来，一个性能更快的Gemma实例因为对延迟敏感的请求路径而需要自己的监听器：

flash.llm.my-app.com

那招也有效。DeepSeek级别的图像模型及评估用检查点吸引了更多主机加入：

images.llm.my-app.com

deepseek-v4.llm.my-app.com

生产环境中的Qwen保持不变，而开发阶段则使用实验端点。每一步单独来看都是合理的，但整体上却形成了一张只有设计者才能记住的基址网络。

虽然可行，但总觉得有些不对劲

这些步骤其实都不难——问题恰恰就在于此。每个模型都重复着相同的流程：部署权重、提供服务接口、配置网络设置、让私有模型主机能够访问应用，然后再为应用设定新的基础网址。但这些都不是“模型”本身的特性，只是些通用的基础设施操作。团队成员无法被要求“使用我们的大语言模型服务并选择某个模型”；他们需要明确知道具体的主机地址，而且每当出现新的端点时，沟通就不得不重新开始。要引入外部承包商，也只能提供一份包含所有主机名的私有术语表，而非一个统一的目录。

DeepSeek实验让这一点变得显而易见

在不影响生产环境中的Qwen的情况下评估独立的DeepSeek类部署，意味着又多了一个接入开发环境的接口。从技术层面看并没有出现问题。但那个困扰人的问题依然存在：为何添加模型就必须同时添加网络功能？实际发生变化的只是模型的权重，应用程序的基础设施本不必随之同步改变。如果每次实验都要调整DNS和对等连接设置，那么实验进度就会受到网络变更流程的制约。

那大型提供商是如何提供模型的呢？

主流提供商并不会为每个模型创建独立的公共基础URL。调用方也不需要处理诸如以下这类不同的主机地址：

gpt-4.api.openai.com
gpt-5.api.openai.com
some-other-model.api.openai.com

他们只保留一个 API，在请求中选择模型。如果服务提供商能在单一接口后支持数十种模型，自托管的模型集群也能实现类似功能。客户端契约保持稳定，而其背后的模型集群则可以不断更替。

核心思路：在模型前添加代理

应用程序应始终与一个稳定的基础接口通信：

llm.my-app.com

并在请求体中选择模型：

{
  model: "qwen-3.8",
  ...
}

{
  model: "gemma-3",
  ...
}

{
  model: "deepseek-v4",
  ...
}

后端可以在不同的机器、区域或运行时之间切换，而客户端契约保持不变。这其实就是云服务提供商早已提供的抽象层——只不过是针对由你掌控的开放模型集群设计的。

自行构建代理与采用网关

一个简单的转发器——即模型调用、路由处理和响应返回功能——在尚无需作为共享服务时看起来很简单。但一旦需要实现共享服务，就会出现虚拟密钥、使用量统计、访问控制、模型配置、速率限制、日志记录以及管理界面等功能。这已不再是简单的代理工具，而是一个LLM网关。从零开始重新构建这些控制功能意味着要处理多年积累的各种边缘情况（如密钥轮换、各团队的预算限制、审计日志等）。LiteLLM直接针对这一控制层进行设计，从而让团队无需再处理这些问题。

为何选择LiteLLM

应用程序只需维护一个端点：

llm.my-app.com

LiteLLM则能将请求路由到多种不同的后端：

My Application
                        │
                        ▼
                 llm.my-app.com
                        │
                        ▼
                   LiteLLM
                  /   |    \
                 /    |     \
              Qwen  Gemma  DeepSeek

要添加新的实验性模型，只需部署模型权重、在网关上注册它们，应用程序的URL无需更改。这样一来，主机名就不会泄露到产品代码中。开发者选择模型的方式就像调节温度一样——在请求中直接指定，而无需为每次实验都编辑环境文件。

部署过程十分简单

LiteLLM以Docker镜像的形式提供，通常需要PostgreSQL来存储密钥和支出等关键状态数据：

LiteLLM container
        │
        ├── PostgreSQL
        │
        └── Open-weight model servers

模型服务器仅负责推理任务，而网关则负责管理其上的控制平面。GPU节点不再需要被每个微服务直接访问，架构设计将重点放在网关层，而非应用与模型主机之间的N乘M型网格结构。

真正发生变化的部分

在引入网关之前，添加新模型意味着要重复整个网络配置流程：

New model
   ↓
New deployment
   ↓
New networking
   ↓
New hostname
   ↓
Application changes

引入网关后，这一流程简化为在稳定的入口处进行注册即可：

New model
   ↓
Deploy it
   ↓
Register it with the gateway
   ↓
Use the existing endpoint

重要的经验教训是：应用程序无需知道大语言模型运行在何处——只需知道应请求哪个模型即可。LiteLLM就是实现这一限制的一种实用方法。最初的痛点并不在于网关产品，而在于第二个模型。一旦这种模式显现出来，后续的每个模型要么会加剧主机名之间的复杂关系，要么会强化单一的模型目录结构。请选择后者。

值得保留的运营注意事项

将模型注册视为需要经过变更管理的操作：明确谁有权限添加后端、密钥如何与团队对应，以及实验的有效期如何设置。
将后端的健康检查与公共接口分开，这样模型暂时不可用时也不至于显得完全中断服务。
在入门文档中明确记载唯一的基准网址，除非有严格的隔离要求，否则不要向应用程序团队提供额外的主机名。

这些习惯保持了该网关最初设计时所追求的抽象层次。

全部文章发送简报