舍弃外部网关，改用 Triton BLS 编排模型，延迟能降多少？

在多模型级联（如 ASR + NLP + TTS，或者目标检测 + 裁剪 + 属性分类）的业务场景中，如何编排模型一直是个经典架构问题。

常见的做法有两种：

外部网关分桶/编排：在 Triton 外部写一个 Go/Python 的 API 网关，串行或并行地调用 Triton 的各个独立模型。
Triton BLS (Business Logic Scripting)：在 Triton 内部编写 Python 脚本，直接在服务内部调度其他模型。

从实际生产经验来看，改用 Triton BLS 替换外部网关，非推理延迟（Overhead）通常能降低 50% 到 90% 以上。对于大流量、大张量（Tensor）传输的场景，延迟的绝对值节省甚至能从数十毫秒缩短到微秒级。

为了说清楚这其中的延迟差距到底在哪里，我们需要把每一次请求的生命周期拆开来看。

一、外部网关编排的“延迟隐藏杀手”

为什么引入外部网关会带来明显的延迟？主要原因不在于业务代码运行得慢，而在于数据在不同进程、不同机器之间的“无谓旅行”。

1. 网络栈与协议开销（Network Hop）

在外部网关方案中，一次典型的二级模型串联（Model A -> Model B）请求，数据流向是这样的：
Client -> Gateway -> Triton (Model A) -> Gateway -> Triton (Model B) -> Gateway -> Client

这里产生了 4 次网络传输（Network Hops）。即便网关和 Triton 部署在同一台机器甚至同一个 Pod 内，走 Localhost Loopback，依然绕不开 Linux 内核的网络协议栈（TCP/IP、Socket 缓冲区分配、上下文切换）。单次 gRPC 往返在内网即便只占 1~~2ms，4 次下来就是 4~~8ms 的底噪。

2. 疯狂的序列化与反序列化（Serialization Overhead）

这是最容易被忽视的性能瓶颈。

Triton 接收的是结构化的 Tensor。
外部网关（Go/Python）拿到 Model A 的输出后，必须先将 Protobuf/JSON 字节流反序列化成内存中的数组/张量。
准备调用 Model B 时，又要把这些张量序列化成 gRPC/HTTP 请求体。

如果模型输出的是高维向量（如 Embedding 搜索）或图像数据（如 1080P 图像张量），序列化和反序列化会极度消耗 CPU 资源，单次耗时可达数毫秒甚至数十毫秒。

3. 显存与系统内存的反复拷贝（H2D / D2H）

当 GPU 完成 Model A 的推理后，结果在显存（Device Memory）中。

外部网关要拿回这个结果，Triton 必须把数据从 显存拷贝到系统内存（D2H），然后通过网络发给网关。
网关调 Model B 时，Triton 收到数据，又必须把数据从 系统内存拷贝到显存（H2D）。

PCIe 总线的带宽虽然高，但在高并发下，频繁的 D2H 和 H2D 拷贝不仅会撑爆 PCIe 带宽，还会引入显著的物理延迟。

二、 Triton BLS 是如何“消灭”这些延迟的？

Triton BLS（业务逻辑脚本）允许你用 Python 编写编排逻辑，但这个 Python 脚本不是运行在普通的外部进程中，而是作为 Triton 的一个特殊的“模型”运行。

[ 外部请求 ] 
     │
     ▼
┌────────────────── Triton Inference Server ──────────────────┐
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │                     Triton BLS                        │  │
│  │                                                       │  │
│  │  Model_A_Output = BLS.execute(Model_A, Input)         │  │
│  │  # 共享内存 / CUDA IPC 传递，零拷贝                         │  │
│  │  Model_B_Input  = PostProcess(Model_A_Output)         │  │
│  │  Model_B_Output = BLS.execute(Model_B, Model_B_Input) │  │
│  └───────────────────────────────────────────────────────┘  │
│          ▲                               ▲                  │
│          │ (C API / IPC)                 │ (C API / IPC)    │
│          ▼                               ▼                  │
│     ┌─────────┐                     ┌─────────┐             │
│     │ Model A │                     │ Model B │             │
│     └─────────┘                     └─────────┘             │
└─────────────────────────────────────────────────────────────┘

它之所以快，核心在于以下三点技术实现：

1. 进程内/本地 IPC 通信（C API Level）

BLS 调度其他模型时，不走网络协议栈。

如果 BLS 调用的模型运行在同一个 Triton 实例中，它可以通过 Triton 内部的 C API 直接发起调用。
如果由于 Python GIL 锁限制，BLS 运行在独立的 Python Backend 进程中，Triton 也会利用高度优化的**本地 IPC（进程间通信）**进行数据交互，延迟通常在微秒（μs）级别。

2. 系统共享内存（System Shared Memory）

对于 CPU 上的张量传递，Triton BLS 默认支持共享内存。Model A 推理完后，将数据写入共享内存段，BLS 脚本直接读取该内存地址进行后处理，然后直接把该地址传给 Model B。数据根本没有发生物理拷贝，只是指针的传递。

3. CUDA 共享内存（CUDA Shared Memory / IPC）—— 终极杀手锏

如果你的流水线全在 GPU 上运行，BLS 的优势会达到恐怖的量级。
Triton 支持 CUDA Shared Memory。Model A（比如 TensorRT 引擎）的输出 Tensor 留在 GPU 显存中，BLS 可以直接获取该显存的句柄（CUDA Memory Handle），并将其直接传给 Model B（另一个 TensorRT 引擎）。

在这个过程中：

没有 D2H 拷贝（数据没回 CPU 内存）。
没有 H2D 拷贝（数据没重新上显存）。
没有网络传输，没有序列化。

整个流水线的非推理延迟直接被压缩到了近乎为零。

三、延迟对比：量化数据参考

以下是基于典型生产环境（Nvidia T4/A10G, Intel Xeon CPU, gRPC 通信）下，两种方案在不同数据载荷下的**非推理延迟（Overhead）**对比估计：

场景与数据大小	外部网关编排延迟 (gRPC)	Triton BLS 延迟 (System Shm)	Triton BLS + CUDA Shm 延迟	性能提升幅度
极小载荷 (如 NLP Token ID, 1KB)	~3 - 5 ms	~0.2 - 0.5 ms	N/A (CPU主导)	~10倍
中等载荷 (如特征向量, 512KB)	~8 - 15 ms	~0.5 - 1.0 ms	~0.1 ms	~15 - 80倍
大载荷 (如 1080P 图像/视频帧, 6MB)	~30 - 80 ms	~2.0 - 5.0 ms	< 0.2 ms (显存不落CPU)	~150倍+

场景分析：

轻量级 NLP 场景：如果只是传递几个 Token ID，网关和 BLS 的绝对延迟差距在 3~5ms 左右。如果你的模型本身推理需要 100ms，这 5ms 或许不显眼；但如果模型本身只需要 5ms（如快速分类），BLS 能让吞吐直接翻倍。
重度 CV / 多模态场景：一旦涉及到图像裁剪、缩放、特征图传递，网关方案传输大张量会遭遇严重的 CPU 瓶颈和 PCIe 带宽瓶颈。此时使用 BLS + CUDA Shared Memory，可以将原本数十毫秒的传输和拷贝延迟彻底消灭，降至微秒级。

四、架构选择：我应该立即重构吗？

虽然 BLS 在延迟上有压倒性优势，但架构设计是折中的艺术。在决定是否切换前，可以参考以下考量：

适合继续使用外部网关的情况：

业务逻辑极其复杂且经常变动：外部网关通常使用 Go/Java 开发，拥有更完善的微服务生态（限流、熔断、动态路由、AB 测试、复杂的 Auth 认证）。如果编排逻辑频繁迭代，改网关代码比改 Triton BLS 镜像更安全。
跨节点分布式编排：如果 Model A 运行在 A100 机器上，Model B 必须运行在另一台 CPU 机器上，BLS 无法发挥共享内存优势，此时网关是必需的。

必须坚决切换到 Triton BLS / Ensemble 的情况：

大张量传递：只要你的流水线中间结果包含高维向量、图像、语音波形，别犹豫，BLS 是唯一能拯救延迟的方案。
对 P99 延迟有严苛要求：外部网关受 Go/Python 垃圾回收（GC）以及网络抖动影响，P99 耗时通常有长尾效应。BLS 在进程内调度，P99 极其稳定。
纯粹的模型级联：如果步骤 A 和步骤 B 之间只有简单的“维度变换”或“过滤”，使用 BLS（或更轻量的 Ensemble）可以实现零侵入部署，让算法工程师在单模型仓库里搞定所有事。

总结：
如果你的系统正在遭受“明明模型推理很快，但端到端延迟很高”的折磨，Triton BLS（特别是开启 CUDA 共享内存后）通常能为你白嫖回至少 5ms - 50ms 的硬核延迟红利。