从单模型服务到LLM推理平台：模型部署框架全貌拆解-北京尧图网络

做模型部署做久了你会发现一个尴尬的事实在开发环境里跑通一个模型和生产环境稳定服务一个模型完全是两回事而稳定服务一个模型和把几十个大大小小的模型统一接入、统一调度、统一监控又是另一个数量级的问题。我先后经历了两家公司的AI基建从零搭建从早期单模型服务走到今天的LLM推理平台踩过不少坑也沉淀出一套自认为还算完整的方法论。这篇文章把整个模型部署框架的全貌拆开讲清楚从最朴素的单模型服务开始一路聊到成熟LLM推理平台该有的样子。这篇文章适合谁如果你正打算把训练的模型真正上线或者发现手里的模型越来越多、部署环境越来越乱想在动手之前把整体框架想明白那这篇文章能帮你看清全貌。我不会只堆概念会结合真实的部署参数、踩坑案例和选型逻辑来讲尽量让你看完之后直接能在自己的环境里照着做。1. 单模型服务为什么注定走向平台化1.1 从一次很顺利的模型上线说起多年以前我接过一个文本分类模型的部署任务。模型不大几百MB用的PyTorch训练当时我的部署流程非常标准买一台带GPU的服务器装好CUDA和Python环境把模型权重文件copy上去写一个FastAPI接口加载模型做推理最后用systemd托管这个进程。流程很顺API一跑通测试请求返回正常我就觉得部署这件事已经搞定了。这套方案的直观优势是简单。一个进程、一个端口、一份依赖环境出了问题只要盯这一个进程的日志就行。但它隐藏了一个致命假设你只有这一个模型。一旦模型数量从1变成3再变成10问题就全冒出来了。我印象最深的是第二家公司团队接了三个不同领域的需求一个BERT的文本分类模型一个Sentence-BERT的Embedding模型还有一个早期的GPT风格生成模型。三个模型按老办法各自部署结果就是三张GPU卡每张卡上跑着互不相关的独立进程Python环境各装各的端口也是各记各的文档维护靠聊天记录。到第四、第五个模型进来的时候连环境依赖冲突都快把机器搞炸了装A模型需要的numpy版本会把B模型的环境打碎。1.2 单体部署的四个隐性成本为什么单体部署在模型数量一多之后就撑不住我复盘下来隐性成本主要集中在四个方面。第一是环境隔离成本。每个模型框架对CUDA、Python、依赖库的版本要求都不同如果全部堆在同一台机器上环境冲突是迟早的事。即使踩过坑之后我们开始用virtualenv和Docker但容器一多怎么编排、怎么管理镜像版本又成了新问题。第二是资源利用率太低。每个模型单独部署显存是按模型峰值预留的根本做不到模型间共享。比如文本分类模型平时推理只占4GB显存却要预留6GB的卡Embedding模型更轻2GB都够但为了保险还是给了整张卡。最后统计下来GPU利用率长期不到30%成本却是一点没少花。第三是上线和发布的流程完全没法自动化。每部署一个新模型就得手动写一遍服务代码、手动起进程、手动加监控发布一次模型要拜神。遇到多个模型要同时升级操作窗口长、出错概率高回滚也极其痛苦。第四是模型能力无法统一暴露。业务方调模型今天需要一个文本分类接口明天需要一个向量检索接口后天又要一个生成接口接口风格五花八门。业务系统每接一个新模型就要重新开发一次对接逻辑纯粹的内耗。我当时就意识到单模型部署只是能跑模型多起来之后真正需要的是一套框架用统一的方式解决环境隔离、资源池化、发布编排和对外接入这个框架就是我们今天说的模型部署平台的雏形。1.3 用小作坊和中央厨房理解平台化打个比方单模型部署就像小作坊。小作坊的厨师算法工程师一个人干所有事买菜准备数据、切菜写推理逻辑、炒菜起服务、端盘对外提供接口。菜谱多了之后小厨房就转不过来了灶台不够用、人手也分不开而且每个人炒出来的菜味道还不一样。平台化就是建中央厨房。所有模型被统一收编有标准化的锅灶推理引擎、标准化的供应链镜像分发、标准化的菜品标准对外协议算法工程师只需要把自己的模型食材交进来出品质量由平台保障。多一个模型不是多一个独立厨房而是中央厨房里多一道菜。这个类比解释了一个关键点平台化的本质不是把代码复杂化而是把部署模型这件事变成一条流水线。你不需要把所有模型的环境揉在一起而是通过容器、网关注入、调度器这些抽象层让每个模型依然有自己独立的环境但对外又呈现为统一的服务入口。2. 正式环境部署的框架选型从vLLM到TensorRT-LLM的取舍2.1 先搞清楚选型评什么延迟、吞吐、显存和生态聊框架选型之前得先明确选型标准。我在带团队做技术评估时从不直接问哪个框架最强而是先定好四个维度任何框架丢进来都按这四个维度打分。吞吐量Throughput单位时间能处理多少请求对离线批处理任务来说是最硬核的指标。测吞吐不能看框架自吹的数字得拿自己的业务负载去压特别是要带上不同的输入序列长度分布。延迟LatencyLLM场景和传统模型不一样传统模型看整体响应时间LLM要拆开看TTFT首Token时间和TPOT每个Token的输出时间。这两个指标直接影响用户体验后面我会专门展开。显存效率同样一张A100能不能同时塞下更多并发请求取决于框架对KV Cache的管理做得好不好。这是LLM部署区别于传统模型部署最大的地方也是几个框架拉开差距的核心战场。生态与可维护性社区活跃度、与监控报警系统的适配、升级是否激进、出现问题能不能找到人问。框架再好小众、没人维护放在正式环境就是定时炸弹。2.2 主流推理引擎横向对比我给团队做完评估后把五个框架列进了对比表直接给结论框架吞吐优势延迟特点显存策略最适合的场景vLLM极高PagedAttention降低显存碎片连续批处理下P95稳定分页管理KV Cache省显存大多数在线/批量LLM推理TensorRT-LLM极致TensorRT图优化加多级融合首Token延迟最低显存规划成熟但需预编译对延迟极度敏感的在线场景Text Generation InferenceTGI高HF生态深度集成稳定可靠有显存碎片但成熟与HF模型仓库配合最省心SGLang高RadixAttention共享前缀前缀命中场景极快前缀缓存复用RAG、多轮对话等共享上下文场景Ollama中本地友好模型按需加载开发调试、小规模私有部署生产慎用注意这个表不是谁最强的排名而是谁最匹配你的场景。做选型的时候我反复跟团队强调框架的领先优势只在你踩中的负载特征下才有意义。比如你业务是RAG知识库问答用户问的问题和系统提示词前面一大段是一样的SGLang的RadixAttention能把公共前缀一次性缓存起来吞吐直接翻倍这时候vLLM反而不是最优解。还有一点容易被忽视框架对模型的支持度。TensorRT-LLM虽然性能炸裂但每上一个新模型基本都要重新编译优化一遍只支持它优化过的模型架构。vLLM对主流开源模型的兼容性好得多新模型发布几天内就能用上。平台化阶段这种支持面广的框架用来做默认引擎更稳妥。2.3 选框架不能只跑benchmark要压测自己的负载看过太多人拿框架官方benchmark做选型上来就比吞吐数字最后却上了生产环境出问题。官方benchmark通常是最优配置下的极限值真实世界里的输入长度分布、并发到达模式、显存限制完全不同。我自己踩过这个坑。当时团队入手了一批新卡我兴冲冲选了官方吞吐第一的框架结果上线第一天P95延迟直接爆表。排查下来才发现我的业务请求绝大部分是短输入、长输出而官方benchmark是长输入KV Cache压力和调度策略完全不同。后来我在选型流程里加了硬性要求必须拿生产环境的真实流量回放做至少48小时的压测同时把自己最关心的指标——TTFT、TPOT、单位显存的并发数——拉出来对比才会拍板。3. 单模型服务的标准架构网关、推理实例与观测闭环3.1 网关层从反代到LLM请求的督查岗当部署框架定了、推理引擎跑起来了下一步就是做架构。单模型服务的架构不用复杂但我坚持三段式网关层、推理实例层、观测层。这个三段式做好之后往平台化走的时候可以直接复用不会白做。网关是很多部署方案里被严重低估的一层。很多人觉得网关就是Nginx反向代理把请求转发给后端就行。但在LLM推理场景里网关要承担四个关键职责身份鉴权、模型路由、流量限流、协议转换。鉴权很好理解请求方必须有有效凭证才能调用模型服务。但在正式环境里我建议你做两层鉴权第一层是网关对所有请求做API Key校验只认签名不认来源IP第二层是模型级权限不同业务线只能调用自己申请的那几个模型。我在实际项目中见过不止一次某个部门误调用了别人的高成本大模型一下子把当月推理账单烧光。路由是网关的核心能力。请求里带上模型名或者路由标签网关决定把请求转给哪个推理实例。这里需要特别设计的是按模型版本路由新版本模型上线后把流量按1%、5%、10%逐步放量一旦指标异常立刻切回这套操作在单体服务里我都是手工改Nginx配置实现又慢又容易出错后来全部收进网关控制面做掉了。协议转换则是为了让业务方免受底层框架变化的影响。我们用OpenAI兼容协议做统一标准内部所有推理框架都统一输出为该协议格式。模型从vLLM换到TensorRT-LLM业务方一行代码不用改。3.2 一个实用的LLM网关设计思路Token不是字符是三元组说到网关我想专门讲一个从LLM领域借来的思考方式对我们做网关设计帮助极大。就是业内常说的Token三元组——把一次LLM请求中的信息拆成三个角色Key是我是谁、Query是我在找什么、Value是我能提供什么。在LLM模型内部注意力机制就是通过这三者的作用来完成信息聚合的。我在设计网关时发现这个思路同样适用Key代表请求方的身份凭证决定你有没有资格进网关这道门。我对每个业务线签发独立Key可以通过Key精确统计到每条业务线调了哪个模型、消耗了多少Token成本分摊表格直接就能导出来。Query代表这次请求想要达成什么目标。在网关层面我把Query当作路由决策的依据通过解析请求参数中的模型名、任务类型、上下文长度要求把请求精确分流到对应的模型实例上。Value代表模型实例能提供的实际能力。我用它做调度决策的参考当前哪个实例的显存余量最充足、哪个实例的前缀缓存命中率最高、哪个实例最能满足这个Query的SLA要求。Value匹配不上的请求直接拒绝或降级而不是抱着侥幸心理发给后端然后超时。别小看这个把Token拆成三元组的抽象方式它把网关从转发的管道升级成了懂业务的调度中枢。我们后来做平台化网关这一层的设计几乎没有推翻重来就是得益于这层抽象做得够干净。3.3 推理实例层冷启动、KV Cache和连续批处理网关确定请求往哪转发推理实例层则要回答怎么让模型高效处理请求。先看显存。LLM推理的显存占用分两部分模型权重以及KV Cache。KV Cache是推理过程中必须缓存的历史序列信息大小极为可观。我给大家一个快速估算公式每个Token的KV Cache约等于2×层数×隐藏维度×精度字节数。以7B模型为例32层、隐藏维度4096、FP16精度算下来每个Token大约占用0.5MB。如果一个并发请求的上下文长度2000Token光KV Cache就要吃掉近1GB显存。多请求并发的时候这一块远远超过模型权重本身的占用。所以框架的显存管理策略直接决定你能开多大的并发。接着看批处理。传统深度学习推理是静态批处理一批请求必须同时进同时出遇到慢请求会拖累整批。LLM推理引擎普遍采用连续批处理Continuous Batching本质就是把包桌上菜改成流水线翻台每个请求打完自己的Token就离席新请求立刻补位不用等整批结束。我在线上对比过同样的负载下连续批处理能把吞吐提升一倍以上。这也是为什么早期一批朴素部署方式在LLM面前迅速淘汰的原因。最后看冷启动。加载一个7B模型从磁盘读到显存初始化顺利的话要30到60秒。如果平台不做任何处理直接后果就是扩容时用户白白等一分钟。我处理的办法是保持最小热实例常驻并把冷实例的启动流程做成快速镜像减少模型权重加载时间。7B以上模型还会考虑把权重放在高速NVMe缓存上而不是每次从远端对象存储去拉这能让启动时间缩短一个量级。3.4 观测层TTFT和TPOT才是LLM服务的命根子太多传统监控体系到了LLM服务这里直接失灵。传统模型的监控盯QPS、CPU、内存、P99响应时间就够了LLM服务光盯这些远远不够。一个关键原因是LLM服务输出的是流式Token用户感受到的快慢是由两个更细粒度指标决定的第一个是TTFT首Token返回时间。用户在输入框敲完问题到看到第一个字蹦出来这个等待决定了第一印象。TTFT过高用户会觉得模型卡住了。它的主要瓶颈在prefill阶段计算和请求排队等待。我在压测里会把TTFT的P95控制在1秒以内超过这个值业务方必投诉。第二个是TPOT每个Token的生成时间。这个指标决定了后续内容吐得流畅不流畅主要瓶颈在decode阶段和KV Cache带宽。正常情况下一张A100上跑7B模型TPOT在20毫秒到50毫秒级别换算成生成速度就是每秒20到50个Token。如果你发现TPOT持续偏高优先怀疑是不是并发开太满、Cache命中率下降。我还坚持把这两个指标跟传统指标一起放到监控大盘上并按模型、按网关节点、按业务线多维拆解。给团队成员定的红线是任何模型上线TTFT和TPOT必须有警报规则否则不允许发布。这套可观测体系做扎实后面平台化之后的容量规划、异常排查才有数据基础。4. 从单服务到推理平台的迁移路径拆分、抽象、标准化4.1 第一步把服务拆成控制面和数据面单模型服务的架构再清晰也只是单体。真正迈向LLM推理平台第一步不是引一堆花里胡哨的中间件而是做架构拆分——把一层厚重的服务拆成控制面和数据面。控制面负责应该怎么做模型版本管理、部署配置、路由规则、权限控制、流量调度这些决策逻辑全部上移集中到一个控制组件。数据面负责实际执行具体的模型推理进程、KV Cache、请求转发逻辑全部下沉为可独立运行的实例。我在项目里做过一个很形象的调整之前发布新模型要登录服务器手工替换文件、重启进程发布过程完全是人肉操作。拆成两平面之后控制面提供一个发布API调用它就会触发模型镜像拉取、实例滚动替换、存活检查、流量切换整个过程不需要任何人登录服务器。数据面的实例变成完全无状态的执行单元——随时可以被替换、被伸缩、被丢弃重建。这一步做完其实你就已经拥有一个平台雏形了。4.2 第二步统一模型接入协议这才是最值得先做的标准很多人做平台化第一反应是上Kubernetes先把基础设施容器化编排起来。我的经验恰恰相反基础设施可以后上但对外接口协议必须先统一。如果每个模型还是对外暴露不同的接口协议就算底层容器化做得再好业务方接入新模型的成本还是居高不下。我们最终采用OpenAI兼容接口作为全公司模型服务的统一协议标准。无论底层跑的是vLLM、TensorRT-LLM还是专门优化过的Embedding服务对外全是一个风格/v1/models 列举模型/v1/completions 和 /v1/chat/completions 做文本生成/v1/embeddings 做向量化。所有框架适配工作收敛到平台侧由平台负责把内部引擎的响应转换成统一格式。这个决策带来的好处几个月后就兑现了。公司引入新的代码大模型时业务方完全是零改造接入因为他们调用的协议和之前那个文本模型一模一样只是模型名参数换了一个。接口标准化是平台化里投资回报率最高的一件事。4.3 第三步资源池化与调度策略从朴素开始平台化的第三步是资源池化。这一步容易过度设计我的建议是从朴素方案开始先严控复杂度再逐步迭代。朴素阶段的调度只处理三件事。第一静态绑定。把模型通过配置文件绑定到具体机器调度器只负责在绑定的机器上启停实例不做跨机迁移。这个阶段先解决统一管理问题。第二按模型规格申请显存。平台根据模型权重大小、预估KV Cache占用、目标并发数计算出实例所需的显存规格然后在有足够空闲显存的机器上分配。算不准不要紧可以先给保守值上线后用TTFT和显存监控数据不断修正。第三冷热分层部署。给每个模型定义热实例数常驻承担在线流量和冷实例策略低峰期回收、高峰按需扩容。这一步做好云上GPU账单能省不少因为不需要每个模型都全时段占着资源。我踩过的跟资源调度相关的坑是早期过度自信直接上复杂的自动伸缩和抢占式调度结果告警风暴和实例反复漂移把团队折腾得够呛。后来收敛成上面的三点朴素策略反而运行得极其稳定。自动化是逐步加码的不是一步到位的。5. 平台化之后的新问题知识库、RAG与评测体系5.1 知识库不是扔给模型部署上要单独规划平台搭好之后业务方就会开始提各种进阶需求其中高频的就是知识库问答也就是大家常说的基于LLM的Wiki知识库、RAG检索增强生成。但很多团队踩了同一个坑把知识库问答简单理解成把文档丢给LLM让它回答然后直接在推理平台后面挂一个知识库数据库就完事了。真实的RAG链路部署要复杂得多推理平台只是其中一环。一条完整请求链路是用户提问问题路由到检索服务检索服务把问题向量化调用Embedding模型、在向量库里做相似度检索、取回TopK文档片段然后把用户问题和文档片段一起拼进Prompt再交给LLM推理平台生成最终答案。这里的部署框架至少涉及三个独立组件Embedding模型部署、向量库服务、检索服务网关。Embedding模型本身也要走完整的部署流程同样需要监控和扩缩容。如果检索环节的延迟高整个问答的TTFT就不可接受所以检索超时、重试、降级策略要在网关层一并设计进去。如果不满足于普通向量RAG还想做GraphRAG那类能回答关系型问题的知识库复杂度再上一个台阶需要提前构建图索引部署的组件更多。我的建议是先把朴素RAG链路跑通、体验调顺、指标监控补齐再考虑GraphRAG不要一上来就搞最重的方案。5.2 榜单只适合海选业务评测才是终面部署框架和模型选型阶段很容易被Open LLM Leaderboard之类的公开榜单带着走。我自己也不例外早期选模型时第一件事就是查榜单看到排名高的模型立刻想上线。但被现实毒打几次之后我总结出一个原则榜单只适合海选真正决定是否上线的必须是你自己业务场景里的评测集。榜单分数存在明显的局限性。第一公开榜单的测试集是固定的多是学术基准和你业务里真实分布差距很大。我的业务是客服语义理解榜单里全是代码生成、数学推理题目模型在这上面分数高跟我的场景关系不大。第二榜单不体现部署性能。一个模型评测分数高但量化后精度掉得厉害或者推理框架支持差、显存占用高在线上的体验反而可能不如一个分数低一点的模型。第三榜单不体现成本结构。某些高排名模型体积巨大部署成本是模型的好几倍对小团队来说根本不划算。所以我在团队里定了流程先用公开榜单和模型卡做海选淘汰圈出2-3个候选然后针对自己的业务场景构造评测集包括服务日志回放构建的真实请求和人工标注的期望结果跑完评测看准确率、相关性等业务指标最后做部署性能综合评估拉出TTFT、TPOT、吞吐和单请求成本让业务方和财务一起看账。只有这套流程走完模型才允许进入平台正式上线。5.3 一个容易让新人懵掉的故障请求被拒的链路排查聊到平台化之后的故障排查我想分享一个自己调过的典型案例也特别适合映射到那句常见的报错信息llm request failed: provider rejected the request schema or tool payload. 这种报错看似是推理框架返回的但真实原因往往不在推理端而是网关层的请求校验出了问题。那一次业务方接入一个支持Function Calling工具调用的场景请求里带着结构化的工具定义。平台返回的报错说请求Schema不合法。第一反应是OpenAI兼容层解析有问题我带着团队查网关日志发现根本没有到达模型推理实例网关在协议转换阶段就把请求拦了。再往里挖发现是工具Tool定义里的JSON Schema版本与平台内部的校验器不兼容导致部分字段被判定为非法。这个故障本质上不是模型能力问题而是网关协议适配的校验规则太严格。修复方案分两步短期在网关侧放宽对tool payload的多余校验只保留必要字段检查长期则是把Tool定义规范化统一传参格式并在API文档里给出工具调用的标准示例。这件事给我一个教训平台化越是往后做网关层积累的协议适配逻辑越复杂越要给它配一个完备的请求校验器同时做好报错信息的分类和可读性不然排查链路会极长。最后再分享一点个人感受。从单模型服务走到推理平台技术组件可以一个个加但最困难也最关键的变化其实是思维方式从我要把这一个模型跑好变成我要让所有模型都跑得有序。如果你正好处在这个转变的起步阶段我最想劝你的是别急着上最重的架构先定接口规范、先做可观测基线、先把三个模型的平台化跑顺后续扩容都是水到渠成的事。

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

相关推荐

MySQL表查看方法全解析：从基础到高级技巧

TFLite内存规划器详解：复用张量按生命周期压峰值内存

不买转接盒：Android车机静态工程评测与接收端实现

更多资讯

SVM算法在风力发电故障检测中的应用与实践

软件测试实战：常见控件与功能点测试要点解析

SVM在风力发电设备故障检测中的应用与实践

CNN本质是局部-层次-共享的特征编码协议

RabbitMQ在大数据实时监控中的架构设计与性能优化

IT6332A三路可编程直流电源串口控制与SCPI脚本实战

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？