中文 EN

系统设计 Lab

实时 model serving 是一道 throughput 对 tail latency 的权衡题：batching 和 GPU 买来容量，但每一分收益都要从你的 p99 预算里掏。

调节请求速率、单请求的 model latency、batch window、host 多少 replica 和多少 model，以及你的 p99 目标。开关 dynamic batching 和 GPU acceleration。架构会从单个 model endpoint，演进到 dynamic batching、GPU 加持的 autoscaling replica、带 canary rollout 的 model registry，最终到高 throughput 下的多 model packing。

阅读完整教程

分步讲解

一步一步把它想清楚

每一步都会设定下方的 workload —— 看着 diagram、meter 和各项 decision 随之变化。

常规演进场景

从左到右点击，就是预设的演示路径。每张卡片都会改变 workload 输入。

Workload

这些是输入，不是预设好的架构阶段。

推荐形态

当前架构路径
Model serving 平台架构图 实时 model serving 平台的白板式架构图：客户端、负责路由和切流的 inference gateway、做 batching 的 model-server replica、model registry 和 GPU pool，以及一条异步的 metrics 与 shadow-traffic 路径。 Clients Gateway Model servers Registry + GPU Async Client predict 调用 Inference gateway 路由 + 版本 Traffic split canary + A/B Dynamic batcher 合并请求 Server replicas autoscaled Model registry 版本 + artifact GPU pool accelerator Metrics + latency p99 监控 Shadow traffic offline eval
Clients
Client 发送实时 feature vector，并在很紧的截止时间内等一个预测结果
Gateway
Inference gateway 把每个请求路由到对的 model 和版本，并强制 timeout
Traffic split 把一部分流量切到新版本，做 canary 和 A/B 对比
Model servers
Dynamic batcher 在一个 window 内把并发请求攒成一个 padded batch
Server replicas gateway 在其间做负载均衡的并行 model-server 实例
Registry + GPU
Model registry 存放带版本的 model artifact，以及名字到已部署版本的映射
GPU pool replica 调度上去做高 throughput inference 的 GPU 池
Async
Metrics + latency 在 hot path 之外采集每个 model 的 latency 和 accuracy 指标
Shadow traffic 把线上请求镜像给候选 model 做评估，但不对外返回它们的输出

瓶颈

Serving 容量

p99 latency 预算

Accelerator 效率

Replica 机群压力

多 model packing

为什么会变

    决策权衡

    Dynamic batching

    硬件 + autoscaling

    Model registry

    A/B + canary

    多 model packing

    p99 vs throughput

    有出处支撑的规则

    这些是模型背后那些经得起时间考验的 system design 论断。而 slider 的具体阈值，则被刻意标注为教学用的假设。

    已验证的规则

    Dynamic batching 用 latency 换 accelerator throughput

    Triton 在一个可配置的延迟内把单个 inference 请求合并成一个 batch，让 GPU 每次 kernel launch 处理很多请求，以增加排队延迟为代价换来更高 throughput。

    NVIDIA Triton Inference Server
    已验证的规则

    serving 系统应该给 model 做版本管理，并在一个稳定的名字背后对外服务

    TF Serving 从 registry/model store 加载带版本的 model artifact，能同时服务一个 model 的多个版本，于是流量可以在版本间迁移而不必重新部署 server。

    TensorFlow Serving
    已验证的规则

    KServe 为 inference 提供 canary rollout 和 autoscaling

    KServe 暴露一个 model-serving 控制面，带 traffic splitting 做 canary rollout，以及请求驱动的 autoscaling（可缩到 0 也可从 0 拉起），让 replica 跟随负载。

    KServe
    已验证的规则

    决定交互式 serving SLA 的是 tail latency，不是均值

    在 fan-out 和高 throughput 的系统里，第 99 百分位的响应时间主导了用户可感知的延迟，所以容量和 batching 要按 p99 来定规模，而不是平均延迟。

    The Tail at Scale (Dean & Barroso)

    教学用假设

    • 单 replica 容量是教学近似：CPU 维持一个小的固定 ops/s，一个 GPU replica 清理掉数倍的工作量，而 batching 只有在流量并发到足以填满一个 batch 时才会成倍提升 throughput。batch 增益随 window 和 model latency 一起上升，因为更重的 model 每次 batch 调用能 amortize 掉更多 kernel-launch 和内存传输开销。
    • p99 被建模为 model 计算时间 + batch window + 一个随 utilization 逼近饱和而增长的排队惩罚；惩罚再除以一个关于 replica 数的平方根人力配置因子，用 M/M/c 而非 M/M/1 来近似，于是把同样的负载摊到更多 replica 上真的能压低 tail。真实的 tail 还取决于 GC、padding 和 cold start。
    • host 很多 model 被处理为：一旦 distinct model 超出单个 replica 能无抖动 hot-load 的数量，就需要更多 replica 或 model packing。