在线判别模型推理服务架构体系从一次限流报错到完整技术图景本文源自一次线上问题排查引出的体系化梳理从一条请求被限流降级的报错日志出发层层下钻到 GPU 资源分配、模型部署形态、推理引擎选型最终串起在线推理服务Online Inference / Model Serving的完整技术架构。文章采用自顶向下与自底向上两条路线展开并对涉及的每个名词给出说明。一、引子一条报错日志告诉我们什么一个模型服务对外提供推理接口某天调用方开始收到这样的错误Request is Degraded ... strategy: cluster-qps, code: 429, msg: the current limit has been reached拆解这条日志能读出四层信息发生了什么请求被限流组件拒绝reject返回 HTTP 429Too Many Requests。谁做的服务端的限流中间件按集群 QPS策略整个服务集群每秒请求数上限计数超额后触发。后果是什么被拒请求走了降级路径服务降级Service Degrade——快速失败返回错误而不是排队等待或拖垮服务端。在哪儿改限流阈值配置在服务治理平台上按服务 → 接口维度管理调大阈值或调整策略即可恢复。这个入口的启示是线上问题的表象报错背后是一整套分层的服务治理体系。要真正理解一个模型服务需要同时看两幅地图——治理地图流量如何进来、被管控和推理地图模型如何部署、被执行。下文分别展开。二、自顶向下一次推理请求的完整旅程从调用方发起请求到 GPU 算出结果返回请求依次穿过以下六层。每层只关心自己的职责上层不感知下层细节这是整个架构解耦的关键。调用方 │ ①服务发现按服务名查询可用实例列表 ▼ ┌─────────────────────────────────────────────┐ │ ② RPC 服务层一个服务即一组对等进程实例 │ │ 服务注册发现 / 负载均衡 / 限流 / 熔断降级 / 鉴权 │ │ 实例 一个独立部署的进程容器有 IP、端口 │ ├─────────────────────────────────────────────┤ │ ③ 推理服务框架层进程内如 Triton / TF Serving │ │ 模型加载 / 版本管理 / 按模型名路由 / 动态批处理 │ ├─────────────────────────────────────────────┤ │ ④ 推理引擎层加载与执行 │ │ 被模型服务器委托文件解析、显存分配、 │ │ 权重上传、前向计算 │ │ ONNX Runtime / TensorRT / libtorch / vLLM │ ├─────────────────────────────────────────────┤ │ ⑤ 模型文件层纯数据无执行能力 │ │ ONNX / .pt / SavedModel / TensorRT engine │ ├─────────────────────────────────────────────┤ │ ⑥ 硬件层GPU显存/ CPU │ └─────────────────────────────────────────────┘① 服务发现层调用方不直连 IP而是拿着服务名一个全局唯一标识如反向 DNS 风格的域名型 key向注册中心查询当前存活实例列表再由客户端负载均衡策略挑一个发送。实例上下线自动同步调用方零改动——这是加机器就能扩容的基础。② RPC 服务层治理能力的所在地一个服务对外是一张接口清单Thrift/gRPC 风格的 IDL 定义对内是一组对等实例。这一层承载所有流量治理能力限流Rate Limiting按接口维度设定 QPS 上限超限拒绝保护服务端不被打垮。策略有单机限流和集群限流全服务共享计数之分。熔断降级Circuit Breaking / Degradation下游故障或自身过载时快速失败、返回兜底结果避免故障级联。负载均衡把请求摊到各实例配合健康检查自动摘除故障节点。一个容易忽略的事实限流配在服务接口维度而模型部署在更细的粒度上见第四节所以A 业务模型流量暴涨触发限流会连带拒绝 B 业务的请求这类问题是这种架构的固有权衡。③ 推理服务框架层每个实例进程内跑着一个模型服务器Model Server如 Triton Inference Server 或 TensorFlow Serving。它是指挥者而非执行者决定和管理什么模型、什么时候、以什么配置存在于服务中具体搬运由推理引擎完成见 ④ 层。它负责模型加载与生命周期发起并管理模型的加载/卸载/版本切换实际由推理引擎执行文件解析与显存分配支持多模型共存、版本热更新。按模型名路由一个服务内可以挂几十个模型请求带模型名框架分发到对应模型。动态批处理Dynamic Batching把短时间内的多个独立请求凑成一个 batch 一次前向提升 GPU 利用率。④ 推理引擎层模型文件只是结构描述和权重数据本身不会计算模型服务器也不亲自执行。这一层解决的核心问题是——把一个静态的模型文件变成 GPU/CPU 上高效执行的计算过程解析网络图、加载权重到显存、把算子调度到硬件、管理显存分配与执行依赖。与上层的配合方式是委托执行模型服务器决定加载哪个模型、何时加载、用什么配置并发起加载/推理指令引擎接到指令后完成全部实际工作——读文件、分配显存、上传权重、执行前向再把输出 tensor 交还。这也是后端概念的由来模型服务器支持把哪几种引擎插进来执行。它负责图优化算子融合、消除无效计算、重排执行顺序减少 kernel 启动与访存开销。量化压缩FP32 降到 FP16/INT8牺牲少量精度换取显存减半、吞吐成倍提升。硬件适配编译针对特定 GPU 卡型生成优化执行计划TensorRT 的核心能力代价是产物绑定卡型。执行调度内存池化、异步执行、多流并发减少 GPU 空转。各引擎的差异主要在侧重ONNX Runtime 通用跨硬件TensorRT 极致优化但绑定 NVIDIA 卡型vLLM 专为生成式解码做了 KV Cache 分页与请求级动态组批详见第六、七节。⑤ 模型文件层纯静态数据见第六节描述网络结构和权重不含执行逻辑。⑥ 硬件层GPU 的**显存VRAM**是推理服务最稀缺的资源模型权重常驻显存生成式模型还有动态增长的 KV Cache见第七节。资源管理视角详见第八节。三、自底向上从一张 GPU 卡到一项在线业务反向走一遍看每一层为什么存在。硬件GPU。一张卡有固定显存和算力上面能同时塞多个模型只要显存放得下。物理资源本身没有服务概念。模型文件。训练框架产出的权重结构描述是死的。要让它活起来需要有人解析、分配显存、调度算子执行——于是有了推理引擎。推理引擎ONNX Runtime、TensorRT 等。能加载模型并执行前向计算但只是个库/进程级组件没有 API 服务能力、没有批调度、没有多模型管理、没有版本热更新。生产环境需要把这些工程能力补齐——于是有了模型服务器。模型服务器Triton、TF Serving。补齐了服务化和多模型管理但通常对外说的是自己的 HTTP/gRPC 协议。企业内部已有成熟的 RPC 体系和治理能力服务发现、限流、监控希望模型服务也纳入同一套体系统一管理——于是外面再包一层 RPC 服务进程。RPC 服务层。对调用方暴露统一的接口协议和治理能力一个服务名下可以管理所有推理实例。当服务规模变大——几十种业务模型、上百实例、多个机房——需要一层逻辑划分来管理资源配额、发布节奏和容灾——于是引入了服务分组Group分组是服务内部的逻辑单元通常按业务模型划分不是把多个服务归类而是把一个服务切分。每个分组拥有独立的资源配额哪些机房、多少卡、独立的发布/回滚/事件状态、独立的容灾与弹性伸缩评估。分组之下才是实例实例是具体执行体落在某个机房、某个资源队列上。最终形成三级包含关系服务对外门面→ 分组资源发布治理单元→ 实例执行体。调用方。只认服务名 接口 模型名完全不感知内部分组怎么切、实例怎么漂移。中间某次发布把模型从 A 组迁到 B 组调用方零改动——这正是分层解耦的回报。四、关键架构决策模型路由的三级坐标把请求定位到一个具体模型需要三个坐标分别回答三个问题坐标回答的问题所在层服务名Service请求发给哪个进程组RPC 层模型名Model请求算什么请求体参数框架分发分组Group模型跑在哪批实例、归谁管平台侧配置服务名解决发给谁服务发现、连接、治理模型名解决算什么框架按名字分发到加载好的模型分组解决跑在哪、怎么管实例与模型的绑定关系、资源份额、发布节奏。分组与模型非严格一对一——一个分组可管理一个业务模型的多个版本一个实例也可同时加载同组多个模型以摊薄资源。五、推理引擎与后端体系Triton 的多面手本质Triton 声称后端可挂 ONNX、TensorRT、PyTorch、scikit-learn——这句话需要拆开理解因为四个名词根本不在同一类别上5.1 四类角色的本质区别名词本质类别职责PyTorch训练框架训练模型产出.pt权重自带运行时可推理scikit-learn传统 ML 库训练线性回归/树模型等产出 pickle 文件ONNX模型交换格式标准化模型描述算子权重的 protobuf本身不负责加载执行TensorRT推理优化引擎深度编译优化算子融合、FP16/INT8 量化、按卡型调优产出绑定特定 GPU 的引擎文件5.2 后端Backend的真正含义后端 Triton 支持把哪几种执行引擎插进来。onnxruntime后端内部封装的是 ONNX Runtime 引擎tensorrt后端封装 TensorRTpytorch后端封装 libtorch。Triton 自己不解析任何模型文件——加载与执行全部委托给引擎自己只做服务化编排。因此完整分层是Triton服务层API、批调度、多模型管理 └→ 推理引擎执行层ONNX Runtime / TensorRT / libtorch └→ 模型文件描述层ONNX / .pt / engine一个类比ONNX 如同标准化的菜谱文件格式统一的用料与步骤写法ONNX Runtime 是照谱做菜的厨师TensorRT 则是按自家厨房特定卡型改编出最优做法的主厨Triton 是统筹接单、排桌、上菜流程的餐厅经理。5.3 典型生产流水线PyTorch 训练 → 导出 ONNX与训练框架解耦→ TensorRT 编译优化绑定卡型 → Triton 加载执行 → RPC 层对外服务各环节可按需省略轻量场景直接挂 ONNX 跑 ONNX Runtime 即可追求极致吞吐才引入 TensorRT。Triton 同一服务内可混挂不同后端的模型——这正是多面手的价值不同团队产出的模型格式五花八门统一交给一个模型服务器实例群承载。六、判别式 vs 生成式模型类型决定推理架构这是整个选型体系的第一判据。模型类型一变瓶颈就变优化方向随之全变。6.1 两类模型的本质差异维度判别式模型Discriminative生成式模型Generative数学目标直接学 P(y|x)输入到输出的映射学数据分布 P(x,y) 或 P(x_t1|x_1…t)典型代表线性回归、逻辑回归、SVM、BERT 分类、embedding 模型GPT/LLaMA/Qwen 等自回归 LLM、朴素贝叶斯、HMM推理形态一次前向传播出结果无状态残留逐 token 循环解码KV Cache 常驻显存瓶颈算力 批调度KV Cache 显存管理 长尾调度显存画像权重固定多模型权重叠加KV Cache 随并发数与上下文长度动态膨胀输出形态完整 tensor 一次返回流式吐 token一个常见的概念分层统计学语境下生成式指建模数据分布朴素贝叶斯、GPT 都算部署语境下生成式特指自回归逐 token 解码——后者是前者的子集延伸正是自回归把生成变成了循环计算才催生了专门的推理引擎。6.2 推理引擎的两条路线Triton 路线判别式优化核心是动态批处理——攒请求凑批一次前向。挂 ONNX/TensorRT/PyTorch 等多后端服务分类、打标、评分、embedding、相似度等单次前向任务。vLLM 路线生成式 LLM专为自回归解码设计三大核心技术——PagedAttention把 KV Cache 像操作系统内存分页一样切块管理消除碎片显存利用率大幅提升。Continuous Batching新请求随时插入正在生成的批次无需等整批完成吞吐提升数倍到数十倍。OpenAI 兼容接口原生 chat/completions天然匹配流式生成业务。两者不互斥Triton 可将 vLLM 作为 backend 挂入。选型口诀模型只判断用 Triton模型要写东西用 vLLM。七、资源管理视角GPU 卡数到底由什么决定从资源台账看一个模型服务涉及四个概念各自决定一件事单实例规格决定卡数每个实例声明CPU 核数 / 内存 / GPU 型号 × 卡数。配置列中16核/64G/A30-24G*1即单实例挂 1 张 A30。GPU 数量由规格决定与队列无关——同一队列完全可混跑 GPU 实例和纯 CPU 实例后者配置无 GPU 段。资源额度决定上限跟组织项目组走。申请新实例时从项目组剩余额度里扣。额度不足时需先扩额度再申请。资源队列决定调度位置实例被调度到哪个机房、哪个资源池。队列本身不携带卡数信息只决定资源从哪个池里扣。分组配额决定份额总卡数按分组切份额各组配额之和服务总卡数这是比实例列表更上层的资源台账。核心公式总 GPU 数 Σ(每个实例规格中声明的卡数)与队列无换算关系。同理卡数跟着单实例规格走额度跟着项目组走调度位置跟着队列走份额跟着分组走。另一个易错点实例总数 ≠ GPU 实例数。一个服务常混布大量纯 CPU 实例做预处理、轻量模型、参数服务统计 GPU 必须按配置过滤。八、名词速查表名词类别一句话说明在线推理 / Model Serving领域将训练好的模型部署为常驻服务对外提供实时推理接口服务ServiceRPC 层一组对等进程实例 一张接口清单对外一个全局服务名实例Instance部署层一个独立部署的进程/容器有 IP、端口、资源规格服务发现Service Discovery治理客户端按服务名从注册中心查询存活实例实例增删自动同步负载均衡Load Balancing治理把请求摊到各实例配合健康检查自动摘除故障节点限流Rate Limiting治理按 QPS 等指标限制流量超限拒绝HTTP 429分单机/集群策略熔断降级Degrade治理过载或故障时快速失败返回兜底结果防止故障级联服务分组Group部署层服务内部的逻辑单元独立资源配额、发布节奏、容灾评估模型服务器Model Server推理层Triton / TF Serving模型加载、版本管理、按名路由、动态批处理推理引擎Inference Engine执行层ONNX Runtime / TensorRT / libtorch / vLLM实际加载并执行模型后端BackendTriton 概念Triton 可插拔的执行引擎种类onnxruntime后端内部即封装 ONNX RuntimeONNX模型格式Open Neural Network Exchange读作欧尼克斯标准化模型描述只定义结构不负责执行TensorRT推理引擎NVIDIA 优化编译器算子融合、FP16/INT8 量化、按卡型调优产物绑定特定卡型PyTorch / scikit-learn训练框架前者训练深度学习模型后者训练传统 ML线性回归、树模型判别式模型模型类别学 P(y|x)一次前向出结果分类、打标、回归、embedding生成式模型模型类别学数据分布部署语境特指自回归 LLM逐 token 解码自回归解码Autoregressive推理过程每步用已生成内容预测下一 token循环至终止符KV Cache推理过程解码中间状态注意力 Key/Value 缓存常驻显存且随上下文增长PagedAttentionvLLM 技术KV Cache 分页管理消除显存碎片Continuous BatchingvLLM 技术请求级动态组批新请求随时插入运行中的批次动态批处理Dynamic BatchingTriton 技术攒独立请求凑 batch 一次前向提升 GPU 利用率显存VRAM硬件GPU 板载内存推理最稀缺资源权重常驻 KV Cache 动态占用服务降级 vs 限流治理限流是门口保安按量拒绝降级是应急预案被拒后走快速失败路径九、总结一张全景图【治理地图】 【推理地图】 调用方 硬件GPU 显存 / CPU │ 服务发现 ▲ ▼ │ 加载执行 RPC 服务层 ── 限流 / 熔断 / 负载均衡 推理引擎ONNX Runtime / TensorRT / vLLM │ 一个服务名一组实例 ▲ Triton 的后端 │ │ 封装 ├─ 服务分组资源配额/发布/治理单元 模型服务器Triton / TF Serving │ └─ 实例规格决定卡数队列决定调度 │ 模型加载 / 按名路由 / 批调度 ▼ ▲ 请求进入实例进程 ──────────────────────→ 模型文件ONNX / .pt / SavedModel 纯格式无执行能力三条主线贯穿全文分层解耦主线服务名→模型名→分组三个坐标各答一问调用方对内部变化无感知。模型类型主线判别式一次前向Triton 路线vs 生成式自回归解码vLLM 路线模型类型决定瓶颈瓶颈决定引擎优化方向。资源管理主线卡数跟规格、额度跟项目组、调度跟队列、份额跟分组——四件事四个归属总 GPU 数等于各实例卡数之和。 
长河君 · 2026/10/1 7:51:28 · 阅读 1.2k 在线推理服务架构体系
在线判别模型推理服务架构体系从一次限流报错到完整技术图景本文源自一次线上问题排查引出的体系化梳理从一条请求被限流降级的报错日志出发层层下钻到 GPU 资源分配、模型部署形态、推理引擎选型最终串起在线推理服务Online Inference / Model Serving的完整技术架构。文章采用自顶向下与自底向上两条路线展开并对涉及的每个名词给出说明。一、引子一条报错日志告诉我们什么一个模型服务对外提供推理接口某天调用方开始收到这样的错误Request is Degraded ... strategy: cluster-qps, code: 429, msg: the current limit has been reached拆解这条日志能读出四层信息发生了什么请求被限流组件拒绝reject返回 HTTP 429Too Many Requests。谁做的服务端的限流中间件按集群 QPS策略整个服务集群每秒请求数上限计数超额后触发。后果是什么被拒请求走了降级路径服务降级Service Degrade——快速失败返回错误而不是排队等待或拖垮服务端。在哪儿改限流阈值配置在服务治理平台上按服务 → 接口维度管理调大阈值或调整策略即可恢复。这个入口的启示是线上问题的表象报错背后是一整套分层的服务治理体系。要真正理解一个模型服务需要同时看两幅地图——治理地图流量如何进来、被管控和推理地图模型如何部署、被执行。下文分别展开。二、自顶向下一次推理请求的完整旅程从调用方发起请求到 GPU 算出结果返回请求依次穿过以下六层。每层只关心自己的职责上层不感知下层细节这是整个架构解耦的关键。调用方 │ ①服务发现按服务名查询可用实例列表 ▼ ┌─────────────────────────────────────────────┐ │ ② RPC 服务层一个服务即一组对等进程实例 │ │ 服务注册发现 / 负载均衡 / 限流 / 熔断降级 / 鉴权 │ │ 实例 一个独立部署的进程容器有 IP、端口 │ ├─────────────────────────────────────────────┤ │ ③ 推理服务框架层进程内如 Triton / TF Serving │ │ 模型加载 / 版本管理 / 按模型名路由 / 动态批处理 │ ├─────────────────────────────────────────────┤ │ ④ 推理引擎层加载与执行 │ │ 被模型服务器委托文件解析、显存分配、 │ │ 权重上传、前向计算 │ │ ONNX Runtime / TensorRT / libtorch / vLLM │ ├─────────────────────────────────────────────┤ │ ⑤ 模型文件层纯数据无执行能力 │ │ ONNX / .pt / SavedModel / TensorRT engine │ ├─────────────────────────────────────────────┤ │ ⑥ 硬件层GPU显存/ CPU │ └─────────────────────────────────────────────┘① 服务发现层调用方不直连 IP而是拿着服务名一个全局唯一标识如反向 DNS 风格的域名型 key向注册中心查询当前存活实例列表再由客户端负载均衡策略挑一个发送。实例上下线自动同步调用方零改动——这是加机器就能扩容的基础。② RPC 服务层治理能力的所在地一个服务对外是一张接口清单Thrift/gRPC 风格的 IDL 定义对内是一组对等实例。这一层承载所有流量治理能力限流Rate Limiting按接口维度设定 QPS 上限超限拒绝保护服务端不被打垮。策略有单机限流和集群限流全服务共享计数之分。熔断降级Circuit Breaking / Degradation下游故障或自身过载时快速失败、返回兜底结果避免故障级联。负载均衡把请求摊到各实例配合健康检查自动摘除故障节点。一个容易忽略的事实限流配在服务接口维度而模型部署在更细的粒度上见第四节所以A 业务模型流量暴涨触发限流会连带拒绝 B 业务的请求这类问题是这种架构的固有权衡。③ 推理服务框架层每个实例进程内跑着一个模型服务器Model Server如 Triton Inference Server 或 TensorFlow Serving。它是指挥者而非执行者决定和管理什么模型、什么时候、以什么配置存在于服务中具体搬运由推理引擎完成见 ④ 层。它负责模型加载与生命周期发起并管理模型的加载/卸载/版本切换实际由推理引擎执行文件解析与显存分配支持多模型共存、版本热更新。按模型名路由一个服务内可以挂几十个模型请求带模型名框架分发到对应模型。动态批处理Dynamic Batching把短时间内的多个独立请求凑成一个 batch 一次前向提升 GPU 利用率。④ 推理引擎层模型文件只是结构描述和权重数据本身不会计算模型服务器也不亲自执行。这一层解决的核心问题是——把一个静态的模型文件变成 GPU/CPU 上高效执行的计算过程解析网络图、加载权重到显存、把算子调度到硬件、管理显存分配与执行依赖。与上层的配合方式是委托执行模型服务器决定加载哪个模型、何时加载、用什么配置并发起加载/推理指令引擎接到指令后完成全部实际工作——读文件、分配显存、上传权重、执行前向再把输出 tensor 交还。这也是后端概念的由来模型服务器支持把哪几种引擎插进来执行。它负责图优化算子融合、消除无效计算、重排执行顺序减少 kernel 启动与访存开销。量化压缩FP32 降到 FP16/INT8牺牲少量精度换取显存减半、吞吐成倍提升。硬件适配编译针对特定 GPU 卡型生成优化执行计划TensorRT 的核心能力代价是产物绑定卡型。执行调度内存池化、异步执行、多流并发减少 GPU 空转。各引擎的差异主要在侧重ONNX Runtime 通用跨硬件TensorRT 极致优化但绑定 NVIDIA 卡型vLLM 专为生成式解码做了 KV Cache 分页与请求级动态组批详见第六、七节。⑤ 模型文件层纯静态数据见第六节描述网络结构和权重不含执行逻辑。⑥ 硬件层GPU 的**显存VRAM**是推理服务最稀缺的资源模型权重常驻显存生成式模型还有动态增长的 KV Cache见第七节。资源管理视角详见第八节。三、自底向上从一张 GPU 卡到一项在线业务反向走一遍看每一层为什么存在。硬件GPU。一张卡有固定显存和算力上面能同时塞多个模型只要显存放得下。物理资源本身没有服务概念。模型文件。训练框架产出的权重结构描述是死的。要让它活起来需要有人解析、分配显存、调度算子执行——于是有了推理引擎。推理引擎ONNX Runtime、TensorRT 等。能加载模型并执行前向计算但只是个库/进程级组件没有 API 服务能力、没有批调度、没有多模型管理、没有版本热更新。生产环境需要把这些工程能力补齐——于是有了模型服务器。模型服务器Triton、TF Serving。补齐了服务化和多模型管理但通常对外说的是自己的 HTTP/gRPC 协议。企业内部已有成熟的 RPC 体系和治理能力服务发现、限流、监控希望模型服务也纳入同一套体系统一管理——于是外面再包一层 RPC 服务进程。RPC 服务层。对调用方暴露统一的接口协议和治理能力一个服务名下可以管理所有推理实例。当服务规模变大——几十种业务模型、上百实例、多个机房——需要一层逻辑划分来管理资源配额、发布节奏和容灾——于是引入了服务分组Group分组是服务内部的逻辑单元通常按业务模型划分不是把多个服务归类而是把一个服务切分。每个分组拥有独立的资源配额哪些机房、多少卡、独立的发布/回滚/事件状态、独立的容灾与弹性伸缩评估。分组之下才是实例实例是具体执行体落在某个机房、某个资源队列上。最终形成三级包含关系服务对外门面→ 分组资源发布治理单元→ 实例执行体。调用方。只认服务名 接口 模型名完全不感知内部分组怎么切、实例怎么漂移。中间某次发布把模型从 A 组迁到 B 组调用方零改动——这正是分层解耦的回报。四、关键架构决策模型路由的三级坐标把请求定位到一个具体模型需要三个坐标分别回答三个问题坐标回答的问题所在层服务名Service请求发给哪个进程组RPC 层模型名Model请求算什么请求体参数框架分发分组Group模型跑在哪批实例、归谁管平台侧配置服务名解决发给谁服务发现、连接、治理模型名解决算什么框架按名字分发到加载好的模型分组解决跑在哪、怎么管实例与模型的绑定关系、资源份额、发布节奏。分组与模型非严格一对一——一个分组可管理一个业务模型的多个版本一个实例也可同时加载同组多个模型以摊薄资源。五、推理引擎与后端体系Triton 的多面手本质Triton 声称后端可挂 ONNX、TensorRT、PyTorch、scikit-learn——这句话需要拆开理解因为四个名词根本不在同一类别上5.1 四类角色的本质区别名词本质类别职责PyTorch训练框架训练模型产出.pt权重自带运行时可推理scikit-learn传统 ML 库训练线性回归/树模型等产出 pickle 文件ONNX模型交换格式标准化模型描述算子权重的 protobuf本身不负责加载执行TensorRT推理优化引擎深度编译优化算子融合、FP16/INT8 量化、按卡型调优产出绑定特定 GPU 的引擎文件5.2 后端Backend的真正含义后端 Triton 支持把哪几种执行引擎插进来。onnxruntime后端内部封装的是 ONNX Runtime 引擎tensorrt后端封装 TensorRTpytorch后端封装 libtorch。Triton 自己不解析任何模型文件——加载与执行全部委托给引擎自己只做服务化编排。因此完整分层是Triton服务层API、批调度、多模型管理 └→ 推理引擎执行层ONNX Runtime / TensorRT / libtorch └→ 模型文件描述层ONNX / .pt / engine一个类比ONNX 如同标准化的菜谱文件格式统一的用料与步骤写法ONNX Runtime 是照谱做菜的厨师TensorRT 则是按自家厨房特定卡型改编出最优做法的主厨Triton 是统筹接单、排桌、上菜流程的餐厅经理。5.3 典型生产流水线PyTorch 训练 → 导出 ONNX与训练框架解耦→ TensorRT 编译优化绑定卡型 → Triton 加载执行 → RPC 层对外服务各环节可按需省略轻量场景直接挂 ONNX 跑 ONNX Runtime 即可追求极致吞吐才引入 TensorRT。Triton 同一服务内可混挂不同后端的模型——这正是多面手的价值不同团队产出的模型格式五花八门统一交给一个模型服务器实例群承载。六、判别式 vs 生成式模型类型决定推理架构这是整个选型体系的第一判据。模型类型一变瓶颈就变优化方向随之全变。6.1 两类模型的本质差异维度判别式模型Discriminative生成式模型Generative数学目标直接学 P(y|x)输入到输出的映射学数据分布 P(x,y) 或 P(x_t1|x_1…t)典型代表线性回归、逻辑回归、SVM、BERT 分类、embedding 模型GPT/LLaMA/Qwen 等自回归 LLM、朴素贝叶斯、HMM推理形态一次前向传播出结果无状态残留逐 token 循环解码KV Cache 常驻显存瓶颈算力 批调度KV Cache 显存管理 长尾调度显存画像权重固定多模型权重叠加KV Cache 随并发数与上下文长度动态膨胀输出形态完整 tensor 一次返回流式吐 token一个常见的概念分层统计学语境下生成式指建模数据分布朴素贝叶斯、GPT 都算部署语境下生成式特指自回归逐 token 解码——后者是前者的子集延伸正是自回归把生成变成了循环计算才催生了专门的推理引擎。6.2 推理引擎的两条路线Triton 路线判别式优化核心是动态批处理——攒请求凑批一次前向。挂 ONNX/TensorRT/PyTorch 等多后端服务分类、打标、评分、embedding、相似度等单次前向任务。vLLM 路线生成式 LLM专为自回归解码设计三大核心技术——PagedAttention把 KV Cache 像操作系统内存分页一样切块管理消除碎片显存利用率大幅提升。Continuous Batching新请求随时插入正在生成的批次无需等整批完成吞吐提升数倍到数十倍。OpenAI 兼容接口原生 chat/completions天然匹配流式生成业务。两者不互斥Triton 可将 vLLM 作为 backend 挂入。选型口诀模型只判断用 Triton模型要写东西用 vLLM。七、资源管理视角GPU 卡数到底由什么决定从资源台账看一个模型服务涉及四个概念各自决定一件事单实例规格决定卡数每个实例声明CPU 核数 / 内存 / GPU 型号 × 卡数。配置列中16核/64G/A30-24G*1即单实例挂 1 张 A30。GPU 数量由规格决定与队列无关——同一队列完全可混跑 GPU 实例和纯 CPU 实例后者配置无 GPU 段。资源额度决定上限跟组织项目组走。申请新实例时从项目组剩余额度里扣。额度不足时需先扩额度再申请。资源队列决定调度位置实例被调度到哪个机房、哪个资源池。队列本身不携带卡数信息只决定资源从哪个池里扣。分组配额决定份额总卡数按分组切份额各组配额之和服务总卡数这是比实例列表更上层的资源台账。核心公式总 GPU 数 Σ(每个实例规格中声明的卡数)与队列无换算关系。同理卡数跟着单实例规格走额度跟着项目组走调度位置跟着队列走份额跟着分组走。另一个易错点实例总数 ≠ GPU 实例数。一个服务常混布大量纯 CPU 实例做预处理、轻量模型、参数服务统计 GPU 必须按配置过滤。八、名词速查表名词类别一句话说明在线推理 / Model Serving领域将训练好的模型部署为常驻服务对外提供实时推理接口服务ServiceRPC 层一组对等进程实例 一张接口清单对外一个全局服务名实例Instance部署层一个独立部署的进程/容器有 IP、端口、资源规格服务发现Service Discovery治理客户端按服务名从注册中心查询存活实例实例增删自动同步负载均衡Load Balancing治理把请求摊到各实例配合健康检查自动摘除故障节点限流Rate Limiting治理按 QPS 等指标限制流量超限拒绝HTTP 429分单机/集群策略熔断降级Degrade治理过载或故障时快速失败返回兜底结果防止故障级联服务分组Group部署层服务内部的逻辑单元独立资源配额、发布节奏、容灾评估模型服务器Model Server推理层Triton / TF Serving模型加载、版本管理、按名路由、动态批处理推理引擎Inference Engine执行层ONNX Runtime / TensorRT / libtorch / vLLM实际加载并执行模型后端BackendTriton 概念Triton 可插拔的执行引擎种类onnxruntime后端内部即封装 ONNX RuntimeONNX模型格式Open Neural Network Exchange读作欧尼克斯标准化模型描述只定义结构不负责执行TensorRT推理引擎NVIDIA 优化编译器算子融合、FP16/INT8 量化、按卡型调优产物绑定特定卡型PyTorch / scikit-learn训练框架前者训练深度学习模型后者训练传统 ML线性回归、树模型判别式模型模型类别学 P(y|x)一次前向出结果分类、打标、回归、embedding生成式模型模型类别学数据分布部署语境特指自回归 LLM逐 token 解码自回归解码Autoregressive推理过程每步用已生成内容预测下一 token循环至终止符KV Cache推理过程解码中间状态注意力 Key/Value 缓存常驻显存且随上下文增长PagedAttentionvLLM 技术KV Cache 分页管理消除显存碎片Continuous BatchingvLLM 技术请求级动态组批新请求随时插入运行中的批次动态批处理Dynamic BatchingTriton 技术攒独立请求凑 batch 一次前向提升 GPU 利用率显存VRAM硬件GPU 板载内存推理最稀缺资源权重常驻 KV Cache 动态占用服务降级 vs 限流治理限流是门口保安按量拒绝降级是应急预案被拒后走快速失败路径九、总结一张全景图【治理地图】 【推理地图】 调用方 硬件GPU 显存 / CPU │ 服务发现 ▲ ▼ │ 加载执行 RPC 服务层 ── 限流 / 熔断 / 负载均衡 推理引擎ONNX Runtime / TensorRT / vLLM │ 一个服务名一组实例 ▲ Triton 的后端 │ │ 封装 ├─ 服务分组资源配额/发布/治理单元 模型服务器Triton / TF Serving │ └─ 实例规格决定卡数队列决定调度 │ 模型加载 / 按名路由 / 批调度 ▼ ▲ 请求进入实例进程 ──────────────────────→ 模型文件ONNX / .pt / SavedModel 纯格式无执行能力三条主线贯穿全文分层解耦主线服务名→模型名→分组三个坐标各答一问调用方对内部变化无感知。模型类型主线判别式一次前向Triton 路线vs 生成式自回归解码vLLM 路线模型类型决定瓶颈瓶颈决定引擎优化方向。资源管理主线卡数跟规格、额度跟项目组、调度跟队列、份额跟分组——四件事四个归属总 GPU 数等于各实例卡数之和。