模型部署框架全景：从单模型服务到LLM推理平台

正式环境模型部署框架全景：从单模型服务到 LLM 推理平台

一个老朋友前几天找我聊天，说他们团队把模型好不容易训完了，结果架在正式环境里各种卡：并发一高就超时，显存动不动就 OOM，加机器也没用，最后发现是几个服务互相抢资源。他问我要不要上个推理平台，我说你先别急着上平台，先把“模型部署框架”这件事从头到尾理一遍，从单模型服务到 LLM 推理平台中间隔着好几层东西，每一层都有它的适用场景和技术代价。

这篇文章就是基于这类实战问题整理的。无论你是在做推荐模型、CV 模型还是大语言模型，只要涉及正式环境部署，大概率都会走过同一条路：先写个脚本启动 model.predict()，然后封装成 HTTP 服务，接着发现并发扛不住，于是开始拆服务、加网关，最后发现大模型的推理有自己特殊的问题——流式输出、上下文缓存、动态批处理、显存调度，这才真正触及 LLM 推理平台。

我会按演进顺序把这条链路上的关键问题讲透。适合正处在“模型训练完不知道怎么上线”阶段的算法工程师，也适合准备搭建推理平台的后端和平台团队参考。

1. 先分清场景：单模型服务、推理增强与推理平台怎么选

很多人把“模型部署框架”当成一个大而全的东西，一上来就搜 vLLM、TensorRT-LLM、Ray Serve，好像只有上了这些才叫正式部署。实际上在业务初期，一个普通的 FastAPI 单模型服务往往才是最优解。我见过不少项目死在过度设计上：模型还在调优阶段就搭了一堆微服务加消息队列，结果每次改模型都要改三条链路。

1.1 三种方案的能力边界

我把常见部署形态分成三档，每一档解决不同层次的问题。

第一档是“单模型服务”，说白了就是把模型封装成一个可调用的 HTTP 接口。适合模型数量少、调用方单一、QPS 要求不高的场景。比如一个内部审核小助手、一个跑批任务的分类模型，用一个 FastAPI 或者 Flask 进程包起来就够了。这类方案的特点是链路短，出问题好查，但扩展性差：模型和业务逻辑耦合在一起，并发全靠多开进程硬扛。

第二档是“推理增强服务”，典型代表是 Triton Inference Server、TorchServe 这类专门为推理设计的服务框架。它们解决的核心问题有两个：一是模型管理，一个进程里可以同时加载多个模型；二是推理调度，支持动态批处理、并发模型执行，能把 GPU 利用率提上来。适合模型开始变多、单模型并发已经撑不住的阶段。

第三档是“LLM 推理平台”，不只是部署一个模型，而是把大模型推理变成一套平台能力。典型组件包括：推理引擎（vLLM、TensorRT-LLM、SGLang）、模型网关（路由、鉴权、灰度、限流）、观测系统（TTFT、TPS、显存监控）、知识库与工具调用支撑。到了这一档，你解决的不再是“模型能不能跑”，而是“一组模型如何稳定、高效、可控地对外提供服务”。

三档之间不是替代关系，而是演进关系。我见过一些团队在模型还没稳定的时候直接上第三档，后来发现排障复杂度翻了好几倍。

1.2 我见过的选型失误

举一个真实例子。某团队做一个文档解析模型，高峰期 QPS 不到 10，结果用了 Triton 再加 Kubernetes 自动伸缩，折腾了两周才部署上去，排查问题时日志散在六七个 Pod 里。另一个团队做 LLM 应用，一开始只用 Flask 起服务，调用方多了以后出现三个问题：没有流式返回导致首字延迟高，没有请求排队导致高峰 502，多副本之间没有网关导致模型权重更新不一致。这两个例子说明一件事：选型错误不在于“选了高级的”或“选了低级的”，而是方案与阶段不匹配。

我的建议是：先明确当前阶段最痛的三个问题。是接口稳定性？并发能力？还是模型太多管不过来？然后从第一档起步，按需演进。下文把每一档的关键落地细节展开讲，这样你对照自己的处境就知道该看哪一节。

2. 单模型服务：把“能跑”变成“能上线”

单模型服务听起来简单，写个 API 谁都会，但正式环境和测试环境的差别就在那些“细节”上：进程崩了会不会自动拉起？显存碎片多了怎么办？请求超时了是重试还是直接报错？这些不处理干净，模型就算推理得再准也没法上线。

2.1 FastAPI 封装不是图省事，是边界清晰

我在实际项目中用 FastAPI 封装单模型，不只是因为有类型校验和自动文档，更重要的是它的异步能力让我们能把“模型推理”和“网络IO”分离开。大多数模型推理库是同步阻塞的，而 FastAPI 可以通过run_in_executor把推理放到线程池里，让 API 进程仍能处理健康检查、指标上报等轻量请求。

不过这里有个常见的坑：直接在一个 uvicorn 进程里跑多个模型，或者一个进程里既加载模型又做批量预处理，会让单进程的内存和显存占用变得不可控。我习惯的做法是一个进程只管一个模型，通过环境变量指定模型路径。比如下面这种调度入口：

# serve.py 的核心简化逻辑 from fastapi import FastAPI from pydantic import BaseModel import os, torch from model_loader import create_model app = FastAPI() MODEL_NAME = os.getenv("MODEL_NAME", "default_model") model = create_model(MODEL_NAME) model.to("cuda:0") model.eval() class PredictRequest(BaseModel): instances: list max_length: int = 128 @app.post("/predict") async def predict(req: PredictRequest): # 用线程池执行同步推理，避免阻塞事件循环 outputs = await run_in_executor(model.infer, req.instances, req.max_length) return {"outputs": outputs} @app.get("/health") def health(): return {"status": "alive", "model": MODEL_NAME}

这里的关键不是代码本身，而是你已经给服务定义了清晰的边界：哪个模型、哪些参数、怎么健康检查、在哪里切线程。后续加网关、加监控，都是在这个边界上做文章。

2.2 模型加载方式：冷加载、预加载与显存预算

正式环境里最忌讳“来一个请求加载一次模型”。模型加载时间短则几十秒，长则几分钟，如果服务启动后再懒加载，第一个请求必然超时。所有正式服务都应该在进程启动时预加载模型，也就是常说的 warm start。这个点看似基础，但很值得检查一遍你的部署脚本有没有把它保证好。

显存预算方面，单模型服务同样要提前规划。举个例子，一个 7B 参数模型用 FP16 存储，光权重就要大约 14GB 显存。如果你同时启动两个副本，每个副本都完整加载一遍模型，那么一张 24GB 的卡根本放不下。这时候要么量化，要么做张量并行，要么一个模型只起一个副本。但我见过很多人不去算这笔账，结果服务一扩容直接 OOM。

有个实操技巧：模型加载前先用torch.cuda.empty_cache()清理缓存，加载后立即做一次假推理（dummy input），让 CUDA context 和算子缓存稳定下来。这一步能减少后续推理时频繁的显存申请和释放，实测对提升服务稳定性有明显帮助。

2.3 Triton 这类专用推理服务的入场时机

FastAPI 方案在模型数量超过五个、或者单模型并发超过几十 QPS 之后，就有点吃力了。最典型的问题是不支持动态批处理：十个请求同时到达，每个都要单独过一遍 GPU，批大小永远是 1，吞吐上不去。

这时候 Triton Inference Server 是合适的下一步。动态批处理是它的核心价值，系统会把同一时刻到达的多个请求拼成一个 batch，一次性喂给 GPU，吞吐提升非常明显。举个例子，我实测过一个 3B 模型，用 FastAPI 时吞吐大概 30 req/s，换到 Triton 开了动态批处理之后，在延迟略微上升的前提下吞吐能到 120 req/s 左右。

Triton 的另一个优势是模型并发内存管理。它允许你在同一个 GPU 上同时加载多个模型，并按显存预留比例控制每个模型的并发实例数。配置大致长这样：

name: "my_model" platform: "pytorch" max_batch_size: 32 input [ { name: "input_ids", data_type: TYPE_INT64, dims: [-1] } ] output [ { name: "logits", data_type: TYPE_FP32, dims: [-1, 1024] } ] instance_group [ { count: 2, kind: KIND_GPU } ] dynamic_batching { max_queue_delay_microseconds: 200 }

这个配置里最有用的是max_queue_delay_microseconds，它表示请求在队列里最多等 200 微秒就强制执行。这个参数决定了“为了拼 batch 愿意等多久”，需要根据业务容忍的延迟来回调。我的经验是从 100 开始，逐步加到 500，找到吞吐和延迟的平衡点。但我也要提醒一句：Triton 的上手成本不低，它的配置体系、模型仓库结构和 Python backend 脚本都需要学习，建议在确认 FastAPI 确实成为瓶颈之后再引入。

3. 从单服务走向网关：流量治理与版本演进

单模型服务一旦多起来，你就会遇到一个新的问题：调用方根本不知道应该找哪个服务？不同版本的模型什么时候切换？某个模型卡住了会不会拖垮整个调用链？这些问题不是模型层能解决的，需要引入网关。对 LLM 场景来说，网关的地位尤其重要，因为大模型的输出不是一次性的，而是持续一段时间的流，网关不能只做简单转发。

3.1 网关层到底在治什么

很多团队把网关理解为“负载均衡”，实际上对模型服务来说，网关至少要承担四个职责：路由、限流、熔断、灰度。

路由解决的是“找谁”的问题。一个调用方可能同时使用多个模型（比如一个 Embedding 模型加一个生成模型），网关根据请求里的模型名或业务标签，把流量路由到对应服务或推理引擎。路由表里有每个模型的版本、副本数、健康状态，支持动态更新。这样上游业务就不用感知具体服务实例的变化。

限流解决的是“扛不住”的问题。模型服务的并发能力是有上限的，尤其是 LLM，GPU 显存直接限制了同时处理的请求数。网关需要在令牌桶维度上做细粒度限流，比如“每个模型每秒最多 20 个请求”“每个用户最多同时占用 2 个生成会话”。这里不能只看 QPS，大模型场景下必须考虑并发会话数和总 token 吞吐。

熔断解决的是“别传染”的问题。一个模型服务如果连续报错或超时，网关应该自动把它摘掉，或者返回降级结果，避免调用方无限等待。我在实践中用的策略是：连续 5 个 5xx 错误就把实例标记为不健康，同时保持一个半开状态让少量流量试探恢复。

灰度解决的是“改了别炸”的问题。新模型上线前，先放 5% 流量对比效果，确认无异常再全量切。这个在单模型服务时代很难做，因为每个服务实例是固定的，没有入口做流量切分。有了网关，按权重或按用户维度分流就只是配置项的事。

3.2 发布与回滚：模型权重也要走版本管理

代码上线有 Git 分支、有流水线，模型上线在很多团队里却还停留在“把新权重文件放到服务器上重启”的阶段。这在正式环境是不可接受的。模型权重本身也有版本、有上线时间、有回滚需求，尤其在大模型场景，一次糟糕的权重更新可能让线上问答质量断崖式下跌。

我推荐的做法是把模型权重视为制品（artifact），每次发布都对应一个不可变的版本号。目录结构类似：

/models/v1.0.1/ config.json model.safetensors tokenizer.json /models/v1.0.2/ ...

网关路由表里记录当前线上版本的指针。发布时先复制一份新版本目录，在预发布环境验证完，再通过网关把流量切过去；出问题就一键切回旧版本。这个流程里最重要的原则是：永远不要覆盖正在被服务的模型目录。我吃过一次亏，直接在线上目录里覆盖权重，结果旧请求还在读文件，服务直接崩了。之后我要求所有正式环境模型权重目录只增不改,留过期版本定期清理。

如果你用 Kubernetes 部署，可以通过imageTag或挂载卷版本控制来达成同样的效果，核心思路一致：让模型版本与代码版本一样可追踪、可切换。

4. LLM 推理平台的关键能力拆解

当服务从“几个模型 API”演进到“面向大语言模型的推理平台”，除了网关和部署基础设施，还得专门处理 LLM 自身带来的新问题。这些问题如果不用专门的推理引擎和平台机制解决，单靠普通服务框架根本扛不住。下面四个点是我认为正式环境里绕不开的。

4.1 流式输出：别再用“等全部生成完再返回”

很多第一次做大模型应用的人会犯同样的错：调用模型接口后，一直等到完整回答生成完再返回给前端。遇到长回答，用户可能要等十几秒甚至更久，体验非常差。LLM 推理平台必须具备流式输出能力，也就是模型每生成一个 token 就立刻推给客户端，首字延迟可以从几秒降到几百毫秒。

从实现角度看，流式输出通常走 SSE（Server-Sent Events）或 WebSocket。vLLM、Triton 等引擎都支持流式接口，返回的是一个生成器的 token 序列。网关层需要把它透传给下游，同时处理好中断场景：客户端断开连接时，要能主动取消上游推理任务，否则 GPU 会被一个已经没人看的请求占着，浪费算力。

我这里有一个很实用的经验：在网关层做“按需取消”的钩子。客户端断开时网关立即调用引擎的 abort 接口终止生成。没有这一步，长上下文的生成任务可能占据显存几十秒，并发的几个断连请求就能把 GPU 打满。

4.2 KV Cache 与显存预算：动手算一算

大模型推理和普通模型最大的区别在于 KV Cache。它存储了每一个已生成 token 的 Key 和 Value 张量，用于后续 token 的 attention 计算。在正式部署 LLM 时，KV Cache 占用的显存往往比模型权重还大，不对它做预算和调度，OOM 是必然的。

工程上，KV Cache 的大小可以用一个简化公式估算：单条请求的 KV Cache 显存约等于2 × transformer层数 × KV头数 × 头维度 × 序列长度 × 参数字节数。以一个 7B 模型、24 层、32 个 KV 头、头维度 128、FP16 为例，单个请求生成 2048 个 token 的 KV Cache 大约是 2 × 24 × 32 × 128 × 2048 × 2 字节，约等于 805MB。加上权重本身的 14GB，一个请求就要占掉接近 15GB 显存。一张 24GB 卡理论上只能同时处理几个这样的请求。

这就是为什么推理平台必须精细管理 KV Cache。vLLM 的 PagedAttention 就是借鉴操作系统分页的思路，把 KV Cache 切成小块按需分配，能显著提高显存利用率。你在配置引擎时，要给定max-model-len、gpu-memory-utilization等参数。我认为比较稳的初始配置是gpu-memory-utilization=0.85，留出 15% 余量给 CUDA context 和临时算子。随着上下文越来越长，KV Cache 占用还会继续上涨，线上要设置并发上限并对超长请求做截断。

4.3 Continuous Batching：让 GPU 真正忙起来

传统动态批处理的逻辑是“攒一批请求，统一跑完，再处理下一批”。这在 LLM 场景里效率不高，因为每个请求的生成长度完全不同，短请求生成完后 GPU 还在等长请求跑完，白白浪费算力。推理平台现在普遍采用 Continuous Batching（连续批处理），基本思路是请求级调度：某个请求生成完了，从当前 batch 里挪走，立刻补一个新请求进去，让 GPU 始终在处理有效的 token 生成。

这个机制像游乐园的过山车：传统批处理是一车人全下车后再载下一车，连续批处理是每个座位空出来就立刻有人坐上去，运力自然高。换来的是调度复杂度和显存管理的难度上升，而这正是 LLM 推理引擎的核心技术壁垒。如果你是自研派，要做好心理准备：Continuous Batching 涉及的显存分配、请求级状态管理、抢占与恢复，都是非常深的水。多数情况下，直接用 vLLM、SGLang 这类成熟引擎比自研靠谱得多。

4.4 量化选型：不是越低越好

正式部署 LLM，几乎绕不开量化。一个 7B 模型用 FP16 至少要 14GB，INT4 量化后可以压到 4GB 左右，部署成本和并发能力立刻上一个台阶。但量化是有代价的,精度损失、算子兼容性、推理速度都可能受影响。我在平台部署中常见的组合是 W4A16（权重 INT4、激活 FP16），这是目前效果与速度平衡比较好的一种方案，主流引擎比如 vLLM、TensorRT-LLM 都支持得很好。

不同量化方案的使用场景我整理过一张对照表：

有一条经验值得强调：量化后一定要在测试集上跑一遍指标对比，不要只看压测吞吐。我曾经把一个摘要模型的权重从 FP16 切到 INT4，推理速度上去了，但 ROUGE-L 分数掉了 3 个多点，线上用户明显反馈摘要变差。后来换用 AWQ 并把敏感层保留高精度，损失控制在可接受范围内。量化参数不是越激进越好，而是要在显存与质量之间做取舍。

5. 部署侧如何支撑 RAG 与知识库增强

大模型部署越来越难离开 RAG（检索增强生成），大量的企业应用都需要把私有知识库接进 LLM 的生成链路。LLM 推理平台在 RAG 链路里不直接负责检索，但平台的设计会深刻影响整体效果和稳定性。我最近接触了不少基于知识库的 LLM 应用，包括热词里提到的“LLM wiki 知识库”“GraphRAG”这类增强检索方向，这里就把部署侧要注意的几点单独理一理。

5.1 推理平台在 RAG 链路里的职责

一个典型的 RAG 流程是：用户输入 query → 生成向量 → 在向量库检索 → 拿到相关片段 → 拼接 prompt → 交给 LLM 生成回答。推理平台主要负责最后一段“交给 LLM”，但它要做的事比你想的多：Embedding 模型的并发接入、检索结果的结构化注入、长上下文的组装。

部署上最常见的问题是：Embedding 服务和生成模型服务没有统一规划。Embedding 模型一般不大，可能只有几百 MB，但它同样需要 GPU，而且它在 RAG 高并发检索时反而是瓶颈。我建议在平台里把“嵌入模型服务”和“生成模型服务”作为两种推理实例类型分开管理，分别设定并发上限。比如 Embedding 接检索请求走 QPS 限流，生成模型按并发会话限流。二者不要挤在同一张卡上，否则一次生成高峰会拖垮检索延迟。

检索提示词注入方面，部署平台要准备好处理超长 prompt。企业知识库检索回来的片段经常超过模型上下文限制，平台侧要有两个兜底策略：一是做文本压缩或截断，二是支持上下文窗口扩展。目前主流引擎都支持 32K、128K 甚至更长的上下文，但显存开销也随之上升，部署时一定要按上文提到的 KV Cache 公式重新估算峰值占用。

5.2 GraphRAG 等增强检索的部署注意点

如果做更复杂的知识库增强，比如 GraphRAG 或基于本体（ontology）的知识引擎，部署侧的压力会明显增加。GraphRAG 会在传统向量检索之外，额外依赖图结构的信息：实体关系、社区摘要、多跳路径等。这意味着部署链路里除了向量数据库，很可能还要有图数据库或专门的图查询服务，检索阶段的延迟构成会更复杂。

我实际部署过类似系统后有一个深刻感触：检索环节的稳定性比想象中更重要。图查询出现慢查询时，LLM 生成会被迫等待，用户体感就是“模型卡住了”。因此平台侧给检索调用设置的超时时间必须合理，比如一般检索超过 3 秒直接返回降级结果（只给向量检索的片段），不要死等图查询。同时在 LLM 提示词层，需要让模型知道“当前可能只有部分上下文”，避免生成过程闭嘴不答或强行编造。

从纯部署角度看，我的建议是：知识库增强先跑通“向量检索 + 拼接 + LLM 生成”的最小链路，稳定了再逐步叠加图检索、本体路由等复杂逻辑。因为每多加一个环节，就多一层延迟和故障点，而推理平台的稳定性始终应该排在功能丰富度前面。

6. 监控、压测与模型选型参考

正式环境部署框架的最后一块拼图是“你凭什么认为它在线上是健康的”。没有可观测性，前面所有架构设计都是盲人摸象。尤其大模型服务，状态是流式的、显存是动态的、队列是持续排队的，一个普通 QPS 监控根本不够。

6.1 必须长期盯住的六个指标

模型服务监控不能只看 CPU 和内存。以下六个指标，凡是部署过 LLM 的团队都应该纳入标配：

这些指标的采集方式，我在实践中用的是 Prometheus 加自定义 exporter。vLLM 等引擎本身暴露了/metrics接口，可以直接接入。网关层也要记录路由决策、限流拒绝次数，区分“用户太多”和“服务故障”两种情况。

6.2 正式上线前的压测怎么做

很多团队上线 LLM 服务时只测一下请求能返回就完事，上线后被真实并发打垮。压测不是简单的“开几个线程发请求”，而是要做场景化压测。比如：模拟 20 个用户同时提问、每个用户平均 1200 token 的上下文长度、期望 TTFT 小于 1 秒、TPS 不低于 30。根据这些目标去调并发数，看服务的拐点在哪里。

重点提醒一个容易忽略的指标：显存峰值。压测一定要收集 KV Cache 的总峰值占用，与预设上限对比。如果峰值已经到 95% 以上，线上迟早会 OOM。合理的做法是压测时把并发逐步拉高，找到稳定运行的上限，然后在这个上限基础上留 30% 的余量作为线上并发限制。

另外一个经验是：压测数据要结合真实业务分布。纯短文本压测得出的 TPS 很好看，但真实用户可能一半的请求都带着很长的上下文。建议把线上日志中的 prompt 长度分布提取出来，回放做压测，这样数据才可信。

6.3 公开榜单分数和部署选型的关系

热词里提到的 Open LLM Leaderboard 等公开榜单，很多人会拿来做模型选型依据。我的观点是：榜单分数只能说明模型“潜在能力”，不能说明部署到你这套框架里的“实际表现”。榜单评测用的是固定提示词和固定解码参数，线上业务是各种各样的 prompt、动态参数、工具调用、知识库注入，实际效果可能差很远。

我的习惯是：先根据榜单筛选三到五个候选模型，然后全部接入自己的部署框架，用真实业务数据跑一轮评测：生成质量、延迟、吞吐、显存占用四项一起对比。这一步往往能淘汰掉一半“榜单很漂亮但部署不划算”的模型。记住，选型的最终裁判是你的业务指标和 GPU 账单，而不是别人的榜单排名。

7. 常见问题与排查技巧实录

最后整理一份我在正式环境部署模型框架时高频踩过的坑，以速查表形式给出，方便你遇到同类问题时快速对照。

这里特别说一个我印象很深的案例。有一次线上模型频繁报 “provider rejected the request schema or tool payload” 这类错误，第一反应是模型服务的问题，查了半天发现是网关层在透传工具定义时把additionalProperties字段过滤掉了，导致模型请求里的 tool schema 不完整。这类问题有个排查思路：先在网关层记录原始请求和转发请求的差异，如果发现“入口正常、出口异常”，问题多半出在网关的序列化或字段过滤逻辑上。

另外一个小技巧是：模型框架的日志里一定要包含“请求 ID”，贯穿网关、推理引擎、响应三个环节。没有关联 ID，分布式排查等于大海捞针。我们团队花了一个下午给所有环节加上请求 ID 透传，排障效率提升了十倍不止。

回到开头那个朋友的问题。我最后给我的建议是：如果你的团队目前只有几个模型在跑，先把单模型服务做到位——预加载、健康检查、显存预算、基础监控，这四点比追求“上一个推理平台”重要得多。当你真正面临并发增长、模型数量增多、或者要部署 LLM 需要流式输出和 KV Cache 调度时，再沿着“单模型服务 → 网关 → 推理平台”的路径平滑演进，每一步都有清晰的技术目标。模型部署框架不是越复杂越好，而是每一层能力都要刚好覆盖你当前的痛点。我自己在正式环境部署新模型时，现在第一件事永远是先跑通压测曲线、算清显存预算，再谈框架选型，这个习惯帮我避掉了无数次线上事故。