这几年我搭过的模型部署架构不算少从最开始一个模型一个 Flask 接口应付 demo到后来在正式环境里支撑日均千万级调用的推理平台中间踩过的坑、推翻重来的设计都能单独写好几篇长文。正好最近团队在推进新一版推理平台建设把从“单模型服务”到“LLM 推理平台”这条演进路线重新梳理了一遍我对这个主题的体会也更深了。这篇文章不聊云里雾里的架构概念就讲清楚一件事你的模型要从“能跑”变成“在正式环境里稳定、高效、可扩展地跑”部署框架到底该怎么选、怎么搭、怎么避坑。无论你是在只有一台 GPU 服务器的小团队还是在需要同时服务几十个模型的平台组这条链路里总有一段是你正在经历的阶段。1. 先搞清楚一个前提部署这件事到底在解决什么问题很多同学一提“模型部署”第一反应是“把模型加载起来写个接口返回结果”。这个理解没有错但它只覆盖了部署的最底层要求。真正到了正式环境部署要回答的问题至少包括以下几类可用性模型服务挂了能不能自动恢复发版期间请求会不会中断吞吐与延迟单位时间能处理多少请求响应耗时是否达标资源效率GPU 显存和算力用满了没有还是只用了百分之二三十扩展性流量翻倍了怎么扩容新增一个模型怎么接入成本跑这些服务的机器、电费、带宽成本是否可控单模型服务和 LLM 推理平台的本质差异就藏在上面这些问题的答案里。一个模型单独部署你只需要关心这个模型的加载和推理效率多个模型、多种流量、多团队共享一套 GPU 资源时你面对的问题就变成了资源调度、请求路由、弹性伸缩和稳定性保障。这也解释了为什么业界的演进路径是“单模型服务 → 推理服务器 → 推理平台”。我刚入行时用 FastAPI 写的模型服务到现在公司内部统一的推理平台走的正是这条路线。下面我把每个阶段的典型特征、适用场景和具体技术选型展开讲。1.1 三层架构演进从 FlastAPI 脚本到平台化先给一个整体的对照后续每一层再深挖阶段典型方案核心关注点适用团队规模单模型服务FastAPI/Flask 自写接口或 TorchServe 单模型部署接口可用、能跑通、延迟可接受几个人的小团队、算法验证、demo推理服务器Triton Inference Server、TorchServe 多模型、TensorFlow Serving批处理、多模型共存、GPU 利用率、动态 batcher中等团队有多个模型要统一接入推理平台网关 推理引擎池 调度/监控/弹性伸缩vLLM/TGI/SGLang 等作为引擎高并发、KV Cache 管理、多租户隔离、成本治理平台团队、大规模业务和多模型场景这个演进不是拍脑袋想出来的是业务需求一步步逼出来的。一开始一个模型只服务一个内部工具QPS 个位数FastAPI 足够后来模型多了要统一给公司其他团队提供推理能力每次发版都要走流程就开始需要推理服务器来统一管理再往后大模型时代来了单单一个 LLM 模型对显存和延迟的要求就把传统推理服务器逼到了极限于是又长出了专用 LLM 推理框架和平台化调度这一层。后面你会看到每一步演进都是对前一层短板的补位没有哪一层是彻底被替代的。哪怕今天我在做平台化内部也依然会有团队用单模型服务跑实验这是合理的。1.2 什么时候该从单模型服务升级到推理服务器我见过不少团队在迁移上犹豫不决也有团队为了跟风过早平台化结果把小问题搞复杂。这里给一个我自己的判断标准满足任意两条基本就该考虑升级需要部署的模型数量超过 3 个且每个模型要独立更新版本单个 GPU 上需要同时服务多个模型但手动分配显存很容易踩线线上请求的 batch 效果明显比如 CV 模型、向量化模型但现网没有自动组 batch 的机制需要按模型/租户统计使用量和计费但手写服务里没有这些逻辑。不能满足这些条件时老老实实做单模型服务就好简单反而可靠。我在踩过过度设计的坑后才明白架构不是越重越好而是匹配当前问题规模就好。下一节就从最基础的“单模型服务”讲起。2. 单模型服务先把一个模型稳定跑起来再谈其他单模型服务是整套体系的基石也是很多同学入门的起点。这个阶段的方案看起来简单但真要在正式环境里稳定运行还是有不少门道。这里我把两种主流路线做一次对比再给出一个可以直接参考的工程化模板。2.1 自写接口FastAPI/Flaskvs 推理服务器自写接口的优势是灵活、代码完全可控适合逻辑特殊要加复杂预处理/后处理、要对接内部 RPC 框架的模型。劣势也很明显并发管理、批处理、显存复用、健康检查、指标暴露这些功能都需要自己从头实现。很多人写接口时只实现了“推理函数 HTTP 封装”结果一上压测就暴露问题——要么并发能力弱要么 GPU 利用率低要么线程池配置不当导致请求排队。推理服务器如 Triton、TorchServe把这些基础能力内置了。比如 Triton 的 Dynamic Batcher 可以把一段时间窗口内的多个请求自动拼接成一个 batch 送进 GPU对 CV 模型、embedding 模型这类短请求效果非常明显。我用 Triton 跑过一个 ResNet 模型同样是单卡 V100自写 FastAPI 接口的吞吐大约 120 QPS切到 Triton 并开启 Dynamic Batcher 后峰值干到了 400 QPS延迟还更稳定了。这里不是说 FastAPI 不行而是说在正式环境里通用推理服务器帮我们把很多容易忽略的细节做掉了。2.2 单模型服务的工程化清单如果你还是决定先用自写接口跑一个模型我建议至少把下面这些工程化事项补上否则上线后迟早要回来返工健康检查接口/health返回模型是否加载完成、显存是否正常供负载均衡和 K8s 探活使用请求超时与排队策略推理时间超出阈值时直接返回错误避免请求堆积拖垮服务优雅退出接收 SIGTERM 后停止接收新请求等存量推理完成再退出指标暴露输出请求数、推理耗时、GPU 利用率、显存占用方便监控模型热加载更新模型权重时不需要重启整个服务至少保留双缓冲机制。这些内容在 demo 阶段都是“多余的”但在正式环境一个都不能少。我接手过一个遗留服务上线三个月从没挂过结果发新版模型时发现没有优雅退出每次发布都断连十几秒监控图上一个明显的“断崖”——这就是工程化清单的价值。2.3 可参考的 FastAPI 单模型服务骨架给一个小型模板你们可以直接参考改造。以 PyTorch 模型为例核心思路是“初始化一次 复用推理”同时用信号量控制并发import signal import threading import time from contextlib import asynccontextmanager import torch from fastapi import FastAPI, HTTPException from pydantic import BaseModel model None model_lock threading.Lock() shutdown_event threading.Event() asynccontextmanager async def lifespan(app: FastAPI): global model # 加载模型 model torch.load(model.pt, map_locationcuda:0) model.eval() yield app FastAPI(lifespanlifespan) class PredictRequest(BaseModel): text: str app.get(/health) def health(): return {status: ok, model_loaded: model is not None} app.post(/predict) def predict(req: PredictRequest): if model is None: raise HTTPException(status_code503, detailmodel not loaded) # 预处理 推理 后处理 inputs preprocess(req.text) with torch.inference_mode(): outputs model(inputs) return {result: postprocess(outputs)}这段代码只是一个起点真正的正式环境里你还要引入asyncio 线程池的合理组合或者直接把推理部分扔给 Triton 做这些都是后话。单模型服务阶段的最大意义是让我养成了“把工程化细节当一等公民”的习惯后面做平台时受益很多。3. 从单模型到多模型网关、复用与流量治理当你管理的模型数量变多比如从 3 个涨到 10 个并且来自不同团队、由不同同学维护你会发现一个尴尬的问题每个模型都自己部署一套服务资源利用率低、版本管理混乱、联调成本高。这个阶段模型网关和统一推理服务器就成了关键。3.1 多模型场景下的典型痛点我举一个自己实际经历过的例子。团队里有 8 个模型分布在 3 台 4 卡 A10 服务器上。最初每个模型单独部署每一份部署都要独占一整块显存比如每个模型 8~10GB但实际上很多模型在一段时间内根本没有流量GPU 就这么白白空转。同时每个模型服务都有自己的一套权限校验和日志格式接入方每对接一个新模型就要重新读一遍文档、调一遍参。这些痛点的本质是“模型生命周期”和“资源生命周期”没有解耦。模型网关和推理服务器就是来解决这个问题的把模型统一注册到一个平台由平台来分配显存、调度流量、管理版本。3.2 模型网关统一接入、路由与灰度网关这一层做的事情包括统一鉴权每个调用方拿一个 API Key网关注入认证和计费信息协议转换内部 RPC 转 HTTP或者 HTTP 转推理服务器的 gRPC 接口流量路由按模型版本切灰度比例比如新版本先放 5% 流量限流降级按租户/接口维度限制 QPS超出直接返回 429可观测性记录每次调用的模型、耗时、token 数、错误码。网关本身的实现不算复杂你可以用现成的 API 网关比如 APISIX、Kong也可以自己写一层薄薄的代理服务。我自己更倾向在网关上做“模型路由”这件事因为它天然是流量的入口能拿到全量的调用数据做灰度、计费、容量规划都方便。早期用 Kong 改过一版后来流量大了内部自研的网关逐步取代了通用 API 网关的位置。如果你在做多模型网关我建议先把“路由策略”想清楚而不是一上来就堆功能。常见的路由维度有按模型名、按版本、按请求内容比如输入长度、按资源池比如把大模型路由到 A100 池把小模型路由到 A10 池。这些策略直接决定了平台的资源效率和调度复杂度。3.3 存储、版本管理与模型仓库有了网关和推理服务器还需要一个存放模型权重的“模型仓库”。这个仓库不只是放文件而是要管版本不可变、元数据、审批流程、发布记录。MVN 之类的配置管理工具我不展开重点说模型数据本身。一个比较实用的做法是模型文件 一份 metadata框架类型、输入输出 schema、精度、显存预估以版本号命名注册到内部存储。发布时从仓库拉取指定版本推理服务器加载后注册到网关。这样模型发版就是“仓库更新 网关切流量”两个动作回滚则是“网关切回旧版本”整个过程可以做到分钟级。在模型仓库的元数据里显存预估这个字段非常关键。后面做容量规划和调度时全靠它来判断一台 GPU 能塞几个模型。关于显存预估怎么算正好也是 LLM 平台章节的重点我马上会讲。4. LLM 推理平台为什么它和传统模型部署不是一回事模型部署演进的第三个阶段是专门处理 LLM 的推理平台。这些年“LLM 推理平台”“大模型推理框架”成了高频词很多人把它当成传统推理服务器的又一个变体但实际上 LLM 对推理基础设施的要求和传统模型是量级级的不同。这一章我会把 LLM 推理的三个核心问题讲透显存管理、批处理策略、解码调度。理解了这三点你就能看懂为什么社区会催生 vLLM、TGI、SGLang 这些专用框架也不容易被各种“性能翻倍”的宣传带节奏。4.1 传统模型和 LLM 在“推理”上的本质差异传统 CV 或 NLP 模型比如 BERT、ResNet的推理过程是“前向传播一次输出结果”整个过程是固定计算显存占用在请求开始时就能确定。LLM 是自回归解码生成一个 token把它拼回输入再生成下一个 token直到遇到结束符或达到最大长度。这意味着计算不是一次性的而是会循环很多次每个 token 的生成都依赖前文全部信息需要把历史 token 的键值缓存下来——这就是 KV Cache输出长度是动态的导致显存占用在请求进行中会不断变化生成过程对延迟极其敏感用户等第一个 token 的时间TTFT和后续每个 token 的间隔TPOT是两种完全不同的优化目标。KV Cache 的大小直接决定了一个 LLM 服务能同时承载多少并发。公式大致是KV Cache 大小 2K 和 V 两份 × 层数 × 注意力头数 × 头维度 × 并发请求数 × 序列长度 × 数据类型字节数拿一个 7B 模型举例假设 32 层、32 个头、头维度 128用 FP162 字节并发 16 路、平均上下文长度 2048光 KV Cache 就要大约2 × 32 × 32 × 128 × 16 × 2048 × 2 ≈ 16.8 GB。这还没算模型权重和输入激活值。你要是在一张 24GB 的 3090 上跑权重 7B FP16 已经占掉 14GB剩下的空间连几路并发都跑不起来。这就是为什么“用传统推理服务器跑大模型”会非常亏传统服务器按请求为单位做静态 batch无法感知 KV Cache 的动态变化也做不到在 token 级别动态调度。也因为这样整个行业从“推理服务器”长出了“LLM 推理框架”这一层。4.2 连续批处理Continuous Batching大模型推理吞吐的关键LLM 生成是逐步进行的传统的静态批处理方式是等 batch 集满然后整批跑完再切换到下一批。问题是batch 里的请求生成速度不同有的已经生成完结束符了有的还在慢慢跑静态 batch 会导致 GPU 算力浪费——已经结束的请求占着位置新的请求只能排队。连续批处理Continuous Batching / In-flight Batching的思路是在 token 级别做调度每生成一个 token 后把已经完成的请求踢出 batch把新的请求加进来。这样 GPU 始终在处理“正在生成中”的请求并发度和吞吐量提升非常明显。vLLM 有公开数据连续批处理在模拟场景下可以把吞吐提升 2~4 倍这个数字在实际测试里并不夸张。这项技术听起来简单但实现极其复杂因为你必须动态管理 KV Cache——每个请求的缓存长度不同分配和回收都是动态的。vLLM 在 2023 年提出 PagedAttention借鉴操作系统分页的思路把 KV Cache 切成固定大小的块按需分配碎片问题也就顺带解决了。这是 LLM 推理框架和传统推理服务器最大的分水岭。4.3 量化、显存估算与硬件选型先算账再搭平台正式环境里搭 LLM 平台第一个要面对的问题是“我要买什么卡能跑多大的模型”这里有一个快速估算公式模型权重显存 参数量 × 每个参数的字节数。FP16 是 2 字节INT8 是 1 字节INT4 约 0.5 字节KV Cache 显存 并发路数 × 平均序列长度 × 每 token 的 KV 占用上面公式总显存需求 ≈ 权重 KV Cache 输入激活值 约 20% 冗余。以 7B FP16 为例权重约 14GB。在 24GB 的 3090/4090 上扣除权重后剩余约 9~10GB按每路并发、2048 上下文、FP16 计算只能支持大约 2~4 路并发非常拥挤。所以 7B 模型生产推理的主流选择是量化到 INT8 或 INT4权重降到 7GB 或 4GB 左右留出更多 KV Cache 空间或者换更大显存的卡比如 A100 80GB、A800、H20直接硬扛更高并发。我见过一个很典型的容量事故平台刚上线时没按 KV Cache 算并发上限默认并发开到了 512结果用户一多显存直接打满服务 OOM 重启反复了好几次才定位到是 KV Cache 没规划好。后来我们在模型仓库的元数据里加上“单路 KV Cache 占用”和“推荐并发上限”调度器按这个值切流量事故再没发生过。4.4 主流 LLM 推理框架对比vLLM、TGI、SGLang、TensorRT-LLM 怎么选这一节是很多人最关心的“选型”问题。我先给结论再展开分析。框架核心卖点适用场景踩坑点vLLMPagedAttention 连续批处理兼容 OpenAI API 协议通用 LLM 在线推理最推荐作为起步部分自定义算子需特定 CUDA 版本长上下文可能 OOMTGIHuggingFace生态好集成 HF 全家桶支持 Server-Sent EventsHF 生态为主的中小团队性能略低于 vLLM复杂 gRPC 调度能力弱SGLangRadixAttention擅长多轮对话、前缀复用高并发多轮对话场景社区相对新部分模型兼容性待验证TensorRT-LLM极致推理性能成熟量化支持对延迟/吞吐要求极高、GPU 型号固定的生产链路编译流程重动态形状支持有限Triton LLM Backend作为上层调度器可混跑 LLM 和传统模型已有 Triton 体系、需要统一纳管配置复杂需要二次开发简单解释一下我的选型逻辑如果你从零起步、GPU 型号不统一、要求快速上线选 vLLM。它性能不差、社区最活跃、API 协议贴近 OpenAI团队上手成本最低。如果你们已经有 Triton 体系希望 LLM 和传统模型统一纳管那就用 Triton 的 LLM Backend 包一层 vLLM/TensorRT-LLM。如果对单卡极致性能有强诉求且型号定型不再变了比如清一色 H20TensorRT-LLM 可以考虑。这里有个很多人忽略的点选用哪个框架不是看宣传性能有多高而是看团队能承接多少复杂度。TensorRT-LLM 性能确实好但每次模型版本更新都要重新编译调优链路长团队没有专职高性能计算工程师不建议轻易上。这个判断标准能帮你们避免很多选型上的坑。5. 落地方案从零搭一个正式环境 LLM 推理平台前面讲了原理和选型下面把落地路径完整走一遍。我会以一个“面向公司内部多个业务方、需要支持 3~5 个开源 LLM 模型、日均请求量百万级”的典型场景为例把平台从设计到上线的关键步骤讲清楚。5.1 平台目标与边界定义搭平台的第一步不是选框架而是定边界。否则就会出现“什么都想做最后什么都做不好”的失控局面。对于上面的场景我建议第一版只做四件事统一模型接入模型仓库注册、版本管理、一键发布统一推理入口网关接入业务方用 API Key 调用任何模型基本弹性GPU 资源池按模型分组服务支持多实例横向扩容可观测与告警请求量、延迟、吞吐、显存、错误率全部可视化。租户级精细计费、自动扩缩容到云上、多集群联邦、GPU 共享调度这些复杂能力放到第二版甚至第三版再做。第一版先把核心链路跑通、把稳定性立住。5.2 组件选型与拓扑设计基于上面的边界我给出的第一版组件清单是网关自研薄网关负责鉴权、路由、限流、日志也可用 APISIX 快速落地推理引擎vLLM 作为主力按模型各部署一个服务实例池模型仓库内部对象存储 MySQL 记录版本元数据调度/流水线Kubernetes 自定义 Controller监听模型版本变更触发拉取与滚动发布监控Prometheus Grafana采集吞吐、延迟、显存、GPU 利用率。拓扑上请求链路是“客户端 → 网关 → vLLM 实例池 → 模型权重”。网关根据请求里的 model 参数找当前版本对应的服务地址转发过去。vLLM 实例池可以有一个或多个副本前面挂 Service 负载均衡。这里我不会画拓扑图用文字描述一下核心逻辑整个系统分控制面和数据面。控制面负责模型注册、版本切换、扩缩容跑在 Kubernetes 上数据面就是网关和推理引擎组成的请求链路。控制面频率低、数据面频率高两边解耦是平台稳定性的基础。5.3 vLLM 启动配置与关键参数vLLM 的使用相对简单核心是启动参数。以一个 7B Chat 模型为例典型的启动命令是python -m vllm.entrypoints.openai.api_server \ --model /models/llama-7b-chat \ --served-model-name chat-7b \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 8 \ --port 8000几个关键参数需要重点解释--gpu-memory-utilization 0.85vLLM 会预先分配 85% 的显存给 KV Cache其余留给权重和激活值。这个值不是越高越好留 15% 以上的余量能避免激活值突刺导致的 OOM。显存紧张时可以从 0.9 开始试--max-model-len 4096决定了 KV Cache 单路的预留长度。设太长会挤占并发设太短会截断用户上下文。需要根据业务实际分布来调最好先统计线上请求的 token 长度分位数--max-num-seqs 8单实例最大并发请求数超过后排队。这个值要和显存容量匹配起步可以从 4~8 开始压测后逐步上调--tensor-parallel-size张量并行数单卡跑不动大模型时用多卡切分。注意 7B 在 24GB 单卡上一般不切。这些参数不是调一次就完的。我自己的习惯是先按模型的参数量和显存估算一个安全值跑一轮压测看显存峰值和延迟分布再反过来调整 KV Cache 分配比例和并发上限。平台上线前参数调优至少要经历两轮。5.4 压测与容量规划上线前必须做的几件事正式环境最怕的不是功能问题而是容量问题。我总结了一套压测 容量规划的 checklist指标定义主要看 TTFT首 token 延迟、TPOT每 token 生成时间、吞吐tokens/s、错误率、显存峰值压测工具可以自己写并发脚本也可以直接用 Locust、wrk但我建议专门为 LLM 写一个模拟“多轮对话 不同长度输入 不同输出长度”的脚本并发阶梯从 1、2、4、8、16、32 逐步加压记录每个并发档位的延迟分位数和显存占用找到拐点长稳测试以预估峰值流量的 60% 持续跑 4~8 小时观察显存是否持续上涨有泄漏、是否出现请求超时堆积容量规划根据“单实例并发上限 × 实例数”和“业务预估峰值”做反推决定买几台机器。有一件我很在意的事压测不能只测一个固定输入长度。LLM 服务里输入 100 token 和输入 4000 token 的显存占用、耗时差别非常大。我见过团队用短输入压测通过了结果上线后长文档请求一进来直接 OOM。所以压测脚本必须覆盖业务里最长输入的场景给长上下文单独留够余量。5.5 灰度发布与回滚机制模型版本更新时不能直接把线上流量切到新版本。稳妥的做法是新版本模型在推理引擎池中启动一个独立实例加载完成后通过健康检查网关路由增加版本维度先把 5% 流量切到新实例观察延迟、错误率、输出稳定性稳定后逐步放量到 10%、30%、100%任何一步指标异常网关切回旧版本新实例下线排查。这个机制听起来简单但需要网关、模型仓库、推理引擎三者的版本信息打通。这也是为什么我一直强调“先统一模型仓库的元数据再谈平台化”版本信息不通灰度就只是一句空话。6. 常见问题与排查技巧实录最后把我在模型部署与 LLM 推理平台实践中遇到的高频问题整理成一张速查表并给出每个问题的排查思路。这些问题在文档里很少直接写清楚基本都是要踩过坑才有体会。现象可能原因排查思路解决方案模型服务启动后 OOM权重显存 KV Cache 超限查看启动日志和显存占用确认--gpu-memory-utilization是否过高调低显存利用率减少--max-model-len量化到 INT8/INT4首 token 延迟很高模型权重过大、请求排队从监控看 TTFT 分位数看实例并发是否打满扩容实例降低单实例并发限制升级到带优化算子的推理框架并发上来后吞吐暴跌请求间相互争抢 KV Cache未开连续批处理观察 GPU 利用率和排队请求数换用 vLLM/TGI 等连续批处理框架调整--max-num-seqs分池隔离不同模型长文档请求一次就 OOM输入长度超过预设max-model-len查看被截断或 OOM 的请求长度分布提高max-model-len对超长输入做截断或摘要增加显存余量新版本模型输出不稳定模型文件未固化、权重复用错误核对模型仓库版本号、哈希值模型文件版本不可变按版本灰度GPU 利用率只有个位数并发太低、batch 太小看请求量和 batch size 指标提高并发打开动态批处理看是否有流量瓶颈在上游网关推理结果和本地测试不一致精度被量化或 dtype 设置不同对比 FP16/INT8 输出、随机种子、解码参数明确生产精度标准量化后做校准验证在实际排查中我还有一个心法凡是 LLM 服务异常先看显存曲线再看请求长度分布最后才是代码逻辑。大多数线上事故的核心都在这两个维度上代码只是触发条件。6.1 显存型 OOM 的完整排查流程显存问题我再单独展开讲一次因为这是大家踩的最多的坑。LLM 推理的显存是“动态的”不像传统模型加载完就稳定。排查流程我总结为四个步骤第一步确认权重显存。查看模型文件大小除以单个副本数确认权重本身占用了多少。比如 7B FP16 模型文件约 14GB这个数字基本固定。第二步查看 vLLM/TGI 的 KV Cache 分配日志。框架启动时会打印显存分布情况比如“GPU memory usage: 14.0GB weights, 8.5GB cache”。从这里能看出框架实际给 KV Cache 留了多少空间。第三步用监控看峰值显存。在压测高峰期看 nvidia-smi 的显存占用这个指标要跟框架日志的预期值做对比如果偏差太大说明模型量化精度或上下文长度分布和预期不符。第四步按“权重 单路 KV Cache × 并发数 激活值”倒推并发上限再对照线上的并发参数调整。这套流程我用了三年稳定可靠也帮团队解决过好几个“疑似代码 bug 实为显存规划错误”的疑难问题。6.2 延迟优化把 TTFT 和 TPOT 分开调LLM 延迟优化的核心是把“首 token 延迟”和“后续 token 速度”分开对待。TTFT 主要由模型大小、请求排队时间、预处理复杂度决定TPOT 主要由解码阶段的批大小、显存带宽、算子效率决定。如果你发现 TTFT 偏高优先检查实例是否被打满排队、输入预处理是否耗时长、模型是不是需要即时编译。如果你发现 TPOT 偏高优先考虑并发 batch 是否过大导致单路减速、是否用了低效的量化、是否该上更先进的算子比如 FlashAttention。我之前优化过一个线上服务TPOT 一直 80ms 上下批处理增大到 8 路后确实吞吐上来了但每路速度明显变慢。后来把并发上限从 8 调回 4开了两个实例问题解决——有时候“单实例减少并发多实例水平扩展”比硬撑单实例并发更划算。6.3 框架选错之后的“后悔成本”最后一条经验是给正在选型的团队的。框架选型这件事一旦定了就很难短期更改因为你要迁移的不只是推理引擎还有模型仓库、监控体系、网关路由逻辑、团队习惯。我有一位朋友在选型时只看了 benchmark 里的峰值吞吐选了当时跑分最高的框架结果团队没人熟悉它的编译流程上线两个月模型更新迭代了三次每次都要折腾一天做转换编译最后不得不换回 vLLM白白浪费了大量时间。所以选型的核心不是“哪个性能最高”而是“哪个框架在你们团队能持续稳定运行”。这也是我在 4.4 节里给出“按团队承接复杂度选型”结论的原因。平台化建设是马拉松不是短跑。写在最后的心得回到文章开头那句话模型部署从单模型服务演进到 LLM 推理平台本质上是一条被业务逼出来的路。每个阶段都有它对应的合理方案单模型服务在实验和 demo 阶段依然是最优解推理服务器在多模型统一纳管时价值明显而 LLM 推理平台解决的是大模型时代全新的并发、显存和资源调度难题。我在实际建设平台的过程中最深的体会是不要被各种新框架、新概念的宣传带着走先把需求和边界定义清楚把显存估算和压测这件事做到极致再用最小可行架构去落地。你现在觉得复杂的 KV Cache、连续批处理、模型网关一旦真正跑通之后回头看其实每一步都有清晰的路标。最后再分享一个小技巧每次做完架构演进把当时踩过的坑整理成一篇团队内部文档下次就不会再犯同样的错误了。