如何在一个极其昂贵的 GPU 集群上，把算力压榨到极致，同时还要保证业务的稳定性。
在这条赛道上，NVIDIA Triton Inference Server 是绕不开的工业级标准。我将它收拢为多模型高并发部署的 四大核心战役，带你用底层物理视角彻底打透。
第一战：Triton 的核心逻辑与 GPU 压榨术
Triton 的本质是一个“极其贪婪且高效的包工头”。它的核心架构分为四层：Frontend (接收请求) -> Queue (排队与调度) -> Dynamic Batcher (动态组装) -> Backend (调用 TensorRT/ONNX Runtime 真正干活)。
怎么共享 GPU 资源？ 很多新手以为多放几个模型到显存里就算共享了。Triton 的真正杀招是 Model Instance Group (模型实例组)。 假设你有一张 A100，你可以通过 config.pbtxt 显式声明：给我把模型 A 复制 3 份（分配 3 个 CUDA Stream），模型 B 复制 1 份，同时常驻显存。Triton 就能让这 4 个实例在同一块 GPU 上并发执行，完美填满 GPU 的计算单元（SM）。
OOM 与热更新的终极解法
-
OOM (显存溢出) 处理： 多模型部署最怕一个大请求进来把显存干爆，导致所有模型宕机。解法是：限制每个实例的最大 Batch Size；或者采用 模型按需加载（EXPLICIT 模式），平时把冷门模型卸载到主机的系统内存里，有请求时再毫秒级 Load 进显存。
-
无缝热更新： 传统部署更新模型要重启服务，请求会断。Triton 支持热重载，当检测到模型仓库（Model Repository）里的版本号升级时，Triton 会先在显存里加载新版本，把新请求切过去，等老版本处理完手头最后一个请求后，再优雅地释放老版本的显存。做到真正的业务 0 抖动。
第二战：GPU 物理隔离的两大门派 —— MIG vs. MPS
当多个模型在同一块卡上跑时，它们会疯狂争抢 CUDA Context 和计算单元。怎么管？业界有两条路线：
| 特性 | MPS (Multi-Process Service) | MIG (Multi-Instance GPU) |
| 隔离级别 | 软件逻辑层 (共享同一个 CUDA Context) | 硬件物理层 (切分真实的 L2 Cache 和显存通道) |
| 资源浪费 | 极小 (空闲算力可以被其他人借走) | 较大 (划分好的物理隔断，别人空着你也借不到) |
| 故障影响 | 灾难性 (一个模型 OOM 或内核崩溃，整卡全死) | 极其安全 (一个模型崩溃，完全不影响其他实例) |
| 适用场景 | 内部可信任务、小并发、追求极限吞吐量 | 云计算售卖、生产环境核心链路、强 SLA 隔离 |
实战抉择： 如果是同一个业务流里的多个模型组合，用 MPS；如果是不同业务部门的模型共享一张卡，必须用 Ampere 架构及以上的 MIG 技术砌起“物理隔离墙”。
NVIDIA MPS vs MIG 资源隔离演示
第三战：流水线编排与零拷贝
为什么要用 DAG / Ensemble？ 在真实的业务中，推理绝不是“调一个模型”这么简单。典型的 CV 链路：图片解码 -> 预处理 (Resize/Normalize) -> YOLO 检测 -> 剪裁 -> ResNet 分类 -> NMS 后处理。 如果用 Python 写 API 串联，每一步都要经历：显存输出 -> 拷贝回 CPU 内存 -> Python 处理 -> 拷贝进显存。这中间的 PCIe 搬运耗时可能比模型推理本身还长。
-
Triton Ensemble 优势： 你在配置里画一个 DAG（有向无环图），把前后处理也写成模型（利用 DALI 或 Python Backend）。Triton 会在 GPU 显存内部直接把上一个模型的输出指针递给下一个模型。数据全程不离开显存（Zero-Copy），效率有着数量级的跨越。
Triton Ensemble vs. Python API
第四战：Batching 的进化史 —— 吞吐量的生命线
这是大模型时代最重要的性能考点。我们把 Batching（批处理）分成两代来理解：
传统动态批处理 (Dynamic Batching，适用于 CV/推荐模型)
-
原理： 就像公交车发车。第一个请求到了，等 5 毫秒（max_queue_delay_microseconds），如果在此期间又来了 7 个请求，Triton 就会把这 8 个请求打包成一个 Batch=8 的大矩阵，一次性扔给 GPU 算。
-
调优： 延迟和吞吐量的走钢丝。超时时间设长了，吞吐上去了但延迟爆表；设短了，每次只凑齐 2 个请求，GPU 根本吃不饱。
连续批处理 (Continuous Batching，vLLM 核心原理，适用于 LLM) 大语言模型生成文本是一个 Token 一个 Token 蹦出来的。有的请求只要 5 个字，有的要 1000 个字。如果用传统的动态批处理，全车人都要等那个需要 1000 个字的人下车，公交车才能接下一拨人，这会导致 GPU 算力出现海量的闲置（气泡）。
Continuous Batching 的革命性在于：它把批处理的粒度从“请求级”降到了“Token 级”（Iteration-level）。 结合 PagedAttention（把显存像操作系统内存页一样切碎分配），只要池子里有一个请求生成完毕遇到了 <EOS> 符，它就会立刻把位置和显存让出来，排队的新请求瞬间补位进入 GPU 进行计算。
为了让你直观感受到这两种机制对 GPU 算力压榨程度的巨大差别，我为你构建了一个交互式模拟器。你可以亲自对比一下它们在处理长短不一的 LLM 请求时的行为：
总结排障思路：当吞吐量下降 / 延迟飙升怎么办？
如果你在面试中被问到如何排查线上高并发性能问题，给出以下标准三板斧：
分段诊断（看 Prometheus 监控）： 是 Queue 耗时高，还是 Compute 耗时高？
如果 Queue Time 极高，说明请求全堵在前端，此时应立刻增加 Model Instance 的数量。
如果 Compute Time 极高，说明算力到瓶颈了。
底层探伤（上 Nsight Systems）： 抓一段 GPU 的真实 Timeline。看 CUDA Kernel 之间是不是塞满了气泡？看是不是 Memory Bound（被显存带宽卡死）？如果是，考虑引入 FP16 / INT8 量化（牺牲一点尾部精度换取算力翻倍）。
熔断与降级（SLA 保障）： 如果请求量瞬间达到设计的 3 倍，什么优化都救不回来。网关必须立刻根据配置的令牌桶（Token Bucket）进行限流熔断，同时配合 K8s 的 HPA（基于 GPU 真实利用率 DCGM exporter，而非传统的 CPU/内存利用率）触发紧急自动扩容。
