1. 论文基本信息

1.1. 标题

ORCA: A Distributed Serving System for Transformer-Based Generative Models

1.2. 作者

Gyeong-In Yu 和 Joo Seong Jeong (首尔国立大学); Geon-Woo Kim (FriendliAI 和 首尔国立大学); Soojeong Kim (FriendliAI); Byung-Gon Chun (FriendliAI 和 首尔国立大学)。 作者团队主要来自韩国首尔国立大学和人工智能公司 FriendliAI。

1.3. 发表期刊/会议

发表于 Proceedings of the 16th USENIX Symposium on Operating Systems Design and Implementation (操作系统设计与实现国际研讨会，简称 OSDI)。 OSDI 是计算机系统领域的顶级会议之一，以其对系统设计、实现和评估的严谨性要求而闻名，在该领域具有极高的声誉和影响力。

1.4. 发表年份

2022 年 (具体日期为 7 月 11-13 日)。

1.5. 摘要

摘要指出，针对 GPT-3 等 Transformer-based 生成模型，系统支持（system support）变得至关重要。这些模型以自回归（autoregressive）方式生成词元（token），需要多次运行模型以处理单个推理请求。然而，现有推理服务系统（inference serving systems）由于其僵硬的调度机制（inflexible scheduling mechanism），在处理此类多迭代（multi-iteration）工作负载时表现不佳。例如，批次（batch）中提前完成的请求无法立即返回，而新到达的请求则需等待当前批次完全处理完毕。

为解决此问题，论文提出了两种技术：

1. 迭代级调度（iteration-level scheduling）：将执行调度粒度从请求（request）级别提升到迭代（iteration）级别，调度器（scheduler）每次仅调用执行引擎（execution engine）运行批次上模型的一次迭代。

2. 选择性批处理（selective batching）：在迭代级调度的基础上，仅对选定操作（selected operations）应用批处理，以兼顾批处理效率和灵活性。

   基于这两项技术，论文实现了一个名为 ORCA 的分布式服务系统，并针对千亿参数规模模型进行了可扩展性（scalability）设计。在 GPT-3 175B 模型上的评估显示，ORCA 在相同延迟水平下，吞吐量（throughput）比 NVIDIA FasterTransformer 提升了 36.9 倍。

1.6. 原文链接

https://www.usenix.org/system/files/osdi22-yu.pdf 该论文是已正式发表在 USENIX OSDI '22 会议论文集中的开放获取（Open access）文章。

2. 整体概括

2.1. 研究背景与动机

随着 GPT-3 等大规模 Transformer-based 生成模型在语言生成任务（language generation tasks）中取得巨大成功并引起广泛关注，如何高效地为这些模型提供推理服务（inference serving）成为一个紧迫且重要的研究问题。这些模型在实际应用中需要满足低延迟（low latency）和高吞吐量（high throughput）的需求。

现有挑战：

1. 自回归生成（Autoregressive Generation）的特性： Transformer-based 生成模型通常以自回归方式逐个词元（token）地生成输出。这意味着一个推理请求需要模型进行多次前向传播（forward pass），每次生成一个词元，并将前一个生成的词元作为输入用于生成下一个。这与 ResNet 或 BERT 等模型的一次性前向传播有本质区别，使得推理工作负载具有多迭代（multi-iteration）的特性。

2. 现有推理系统（inference systems）的局限性： Triton Inference Server 和 TensorFlow Serving 等现有系统主要设计用于处理批次（batch）级别的请求。它们的调度机制通常是请求级调度（request-level scheduling），即一旦一个批次被调度，其中的所有请求必须全部完成才能返回结果，且新请求必须等待当前批次完全结束才能加入。

3. 低效与高延迟：

   • 提前完成的请求（early-finished requests）被阻塞： 在多迭代生成任务中，不同请求所需的生成词元数量可能不同。请求级调度导致即使某些请求已提前完成生成，也必须等待批次中所有其他请求完成才能返回结果给客户端，从而显著增加了这些请求的端到端延迟（end-to-end latency）。
   • 新到达请求的等待（late-joining requests）： 新到达的请求需要等待当前正在处理的整个批次完成，导致排队时间（queueing time）过长。
   • 计算资源浪费： 对于批次中已完成的请求，系统仍可能在后续迭代中为其分配计算资源（例如，占用 GPU 内存），导致计算浪费。

4. 批处理（batching）的挑战： 为了提高 GPU 利用率和吞吐量，批处理至关重要。然而，在迭代级调度下，不同请求可能处于不同的生成阶段（例如，输入词元长度不同，或已生成词元数量不同），这导致它们的输入张量（input tensors）形状不规则，难以直接进行批处理。

   因此，论文的动机在于设计并实现一个能够克服上述挑战，为大规模 Transformer-based 生成模型提供高效、低延迟、高吞吐服务的分布式系统。

2.2. 核心贡献/主要发现

论文的主要贡献如下：

1. 提出了迭代级调度（iteration-level scheduling）： 这是一种新的调度机制，将执行的粒度从请求级别降低到迭代级别。调度器（scheduler）在每次迭代后都能与执行引擎（execution engine）交互，从而：

   • 降低延迟： 允许已完成的请求立即返回结果给客户端。
   • 提高响应性： 允许新到达的请求在当前迭代完成后迅速加入处理，显著减少排队时间。
   • 优化资源利用： 调度器可以灵活选择每个迭代中要处理的请求集合，避免为已完成请求进行不必要的计算。

2. 提出了选择性批处理（selective batching）： 针对迭代级调度带来的不规则输入张量问题，论文提出选择性批处理技术。该技术识别 Transformer 模型中不同操作的特性，仅对一部分操作（如线性变换 Linear、层归一化 LayerNorm）进行批处理，而对 Attention 操作则单独处理每个请求（individual processing）。这样既能利用批处理的优势，又能支持灵活的请求组合，显著提高了批处理的灵活性和效率。

3. 设计并实现了 ORCA 分布式服务系统： ORCA 是一个基于上述两项核心技术构建的分布式系统，并集成了：

   • 细粒度 GPU 内存管理： 通过预留 Attention Key/Value 槽位（slots）和动态管理，有效解决了大规模模型 GPU 内存受限问题。
   • 优化的分布式架构： 结合了层内并行（intra-layer parallelism）和层间并行（inter-layer parallelism），并采用控制/数据平面分离（control/data plane separation）的通信机制，减少了 CPU-GPU 同步开销。
   • 无微批次的流水线并行（pipelined execution）： ORCA 的迭代级调度允许在不将批次拆分为微批次（microbatches）的情况下，实现跨工作器（worker）的高效流水线执行，避免了 FasterTransformer 中存在的批处理效率和流水线效率之间的权衡。

4. 显著的性能提升： 在 GPT-3 175B 模型上的实验表明，ORCA 在相同的延迟水平下，相比 NVIDIA FasterTransformer 实现了 36.9 倍的吞吐量提升，证明了所提方法的有效性和优越性。

3. 预备知识与相关工作

3.1. 基础概念

理解 ORCA 的工作原理，需要对以下基础概念有清晰的认识：

1. Transformer 模型（Transformer Models）：

   • 概念定义： Transformer 模型是一种由 Google 于 2017 年在论文 Attention Is All You Need 中提出的深度学习模型架构，主要用于处理序列数据，尤其在自然语言处理（NLP）领域取得了革命性进展。它完全放弃了传统的循环神经网络（RNN）和卷积神经网络（CNN）结构，转而完全依赖于注意力机制（Attention Mechanism）。
   • 核心组件：
     • 多头自注意力（Multi-Head Self-Attention）：允许模型在处理序列中的某个词元时，同时关注序列中的所有其他词元，并为每个词元分配不同的“注意力权重”，以捕捉长距离依赖关系。
     • 前馈网络（Feed-Forward Networks）：在每个注意力层之后，模型会应用一个位置独立的、全连接的前馈网络。
     • 残差连接（Residual Connections）和层归一化（Layer Normalization）：用于帮助深层网络训练的稳定性和收敛性。
   • 在生成模型中的应用： GPT (Generative Pre-trained Transformer) 系列模型是 Transformer 架构在生成任务中的典型应用。它们通常采用 Transformer 的解码器（Decoder）部分，以自回归（autoregressive）方式逐个词元地生成文本。

2. 自回归生成（Autoregressive Generation）：

   • 概念定义： 在序列生成任务中，自回归是指模型在生成当前词元时，会将其前面已经生成的所有词元作为输入。这个过程是顺序的、迭代的，每个新生成的词元都会加入到输入序列中，以预测下一个词元。
   • 工作流程： 对于一个 GPT 模型，生成一个包含 $N$ 个词元的输出序列，需要模型进行 $N$ 次前向传播。每次前向传播生成一个词元。
   • 示例： 要生成句子“我 爱 中国”，如果输入是“我”，模型生成“爱”；然后将“我 爱”作为输入，模型生成“中国”。

3. 推理服务（Inference Serving）：

   • 概念定义： 指将训练好的机器学习（ML）模型部署到生产环境，使其能够接收客户端请求并实时或准实时地提供预测结果的服务。
   • 关键指标： 通常关注低延迟（low latency，即从接收请求到返回结果所需的时间）和高吞吐量（high throughput，即单位时间内处理的请求数量）。
   • 挑战： 资源管理（resource management）、调度（scheduling）、并行化（parallelization）、批处理（batching）等。

4. 批处理（Batching）：

   • 概念定义： 将多个独立的客户端请求的数据合并成一个更大的批次（batch），然后一次性输入到模型中进行处理。
   • 目的： GPU 等加速器在处理大规模并行计算时效率更高。批处理可以提高 GPU 的利用率，减少每次前向传播的开销，从而提高整体吞吐量。
   • 局限性： 批处理通常要求批次中所有数据的输入张量形状相同，这在多迭代生成任务中是一个挑战。

5. GPU 内存管理（GPU Memory Management）：

   • 概念定义： 在 GPU 上高效分配、使用和回收内存资源，以存储模型参数、中间激活值（intermediate activations）和关键状态（如 Attention Key/Value）。
   • 对于 Transformer 模型： Attention 机制会产生 Key 和 Value 状态，这些状态需要跨迭代（across iterations）保存，并且其大小会随着生成序列长度的增加而线性增长，对 GPU 内存造成巨大压力。

6. 分布式执行（Distributed Execution）：

   • 概念定义： 将一个计算任务（如大型模型推理）分解为多个子任务，并在多个计算设备（GPUs）或多台机器（machines）上并行执行。
   • 并行策略：
     • 模型并行（Model Parallelism）：将模型本身分割并部署到不同的设备上。
       • 层内并行（Intra-layer Parallelism）：将单层内的计算（如大型矩阵乘法）分割到多个设备。
       • 层间并行（Inter-layer Parallelism）/流水线并行（Pipeline Parallelism）：将模型的不同层分配给不同的设备，形成一个处理数据的流水线。
     • 数据并行（Data Parallelism）：将输入数据分割到不同的设备上，每个设备复制完整的模型进行处理。

3.2. 前人工作

论文在 2 Background 和 7 Related Work and Discussion 部分提及了多项相关工作，主要可以分为以下几类：

1. Transformer-based 生成模型：

   • GPT ([12, 47])：OpenAI 的系列模型，是 Transformer 解码器架构的代表，采用自回归生成。
   • fairseq ([43])：Facebook AI 开源的序列建模工具包，提出了增量解码（incremental decoding）技术，通过缓存 Attention Key/Value 状态避免重复计算。
   • FasterTransformer ([4]) 和 Megatron-LM ([3])：也采用了增量解码。
   • Attention 机制 ([60])：Transformer 的核心，计算 Q, K, V 之间的权重平均。
   • 其他变体 ($[15, 47-49]$)：例如 T5, PaLM 等。

2. ML 推理服务系统（ML Inference Serving Systems）：

   • Triton Inference Server ([7])：NVIDIA 的通用推理服务系统，支持多种模型和框架，主要负责请求批处理和调度。
   • TensorFlow Serving ([42])：Google 的 TensorFlow 生态中的推理服务系统。
   • Clipper ([16])：一个低延迟在线预测服务系统。
   • 这些系统通常位于底层执行引擎之上，负责 endpoints、调度和响应，并提供批处理、模型选择等功能。它们普遍采用请求级调度。

3. 专门用于 Transformer 模型的执行引擎（Specialized Execution Engines）：

   • FasterTransformer ([4])：NVIDIA 针对 Transformer 模型推理优化的执行引擎，支持分布式执行。
   • LightSeq ([61])、TurboTransformers ([22]) 和 EET ([36])：其他高性能 Transformer 推理库。
   • 这些系统通常作为 Triton 等服务系统的后端，负责实际的张量操作，但它们的调度仍由上层服务系统控制，遵循请求级调度。

4. 分布式训练系统：

   • Megatron-LM ([3]) 和 DeepSpeed ([1])：虽然主要用于训练，但也支持大型模型的分布式执行。它们对大规模模型的模型并行（model parallelism）有重要贡献，但通常未针对推理服务进行优化。
   • MeshTensorFlow ([55])：用于超算上的深度学习。
   • 这些系统提出的层内并行（intra-layer parallelism）和层间并行（inter-layer parallelism）策略被 ORCA 借鉴。

5. 细粒度批处理研究：

   • BatchMaker ([23])：针对循环神经网络（RNNs）的细粒度批处理系统。它在 RNN cell 级别进行调度和批处理，允许新请求加入或完成请求离开。

Attention 机制的计算公式补充： Transformer 模型的核心是自注意力机制。对于一个给定的查询（Query）向量 $Q$，一组键（Key）向量 $K$ 和值（Value）向量 $V$，自注意力（Self-Attention）的计算公式如下：

$$\mathrm{Attention}(Q, K, V) = \mathrm{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$

• 概念定义： Attention 机制通过计算 Query 与所有 Key 之间的相似度（点积），并进行缩放和 softmax 归一化，得到每个 Value 对应的权重。然后，将这些权重与 Value 向量进行加权求和，得到最终的注意力输出。$d_k$ 是 Key 向量的维度，用于缩放点积，防止梯度过小。
• 符号解释：
  • $Q$：查询矩阵（Query matrix），形状为 $[num_queries, d_k]$。
  • $K$：键矩阵（Key matrix），形状为 $[num_keys, d_k]$。
  • $V$：值矩阵（Value matrix），形状为 $[num_values, d_v]$。通常 num_keys 和 num_values 相同。
  • $Q K^T$：查询矩阵和键矩阵的转置的点积，衡量 Query 与每个 Key 的相似度，形状为 [num_queries, num_keys]。
  • $\sqrt{d_k}$：缩放因子，$d_k$ 是 Key 向量的维度。
  • $\mathrm{softmax}(\cdot)$：softmax 函数，将相似度分数转换为概率分布，使所有权重之和为 1。
  • $V$：值矩阵。
  • $\mathrm{Attention}(Q, K, V)$：注意力机制的输出，形状为 $[num_queries, d_v]$。

3.3. 技术演进

Transformer 模型在序列建模中的崛起，以及其在大规模生成任务中的表现，推动了对高效推理系统的需求。

• 早期 ML 推理服务系统：如 Triton 和 TensorFlow Serving，提供了通用的模型部署和批处理功能。它们主要为传统的、单次前向传播的模型（如分类、回归任务）设计，采用请求级调度。
• Transformer 专有执行引擎：为了优化 Transformer 模型的计算效率，FasterTransformer 等系统应运而生。它们专注于底层 CUDA 核优化，并支持模型并行，但仍然依赖上层服务系统的请求级调度。
• RNN 细粒度批处理：BatchMaker 尝试在 RNN cell 级别进行细粒度批处理，但在 Transformer 模型中，由于 Attention Key/Value 状态随位置变化，这种方法效果不佳。
• ORCA 的创新：ORCA 的出现标志着推理服务系统向更细粒度的调度（迭代级）和更灵活的批处理（选择性批处理）方向演进，以更好地适应 Transformer-based 生成模型的多迭代自回归特性。它在系统层面解决了现有批处理和调度机制与生成模型特性不匹配的问题，旨在实现更低的延迟和更高的吞吐量。

3.4. 差异化分析

ORCA 与现有方法的核心区别和创新点在于：

1. 调度粒度（Scheduling Granularity）：

   • 现有系统 (Triton, FasterTransformer 等)： 采用请求级调度（request-level scheduling）。这意味着批次中的所有请求必须作为一个整体被处理，直到所有请求都完成才能返回结果，且新请求必须等待整个批次完成。
   • ORCA： 采用迭代级调度（iteration-level scheduling）。调度器在每次迭代后都能与执行引擎交互，允许已完成的请求立即返回，并允许新请求在下一次迭代时加入批次，显著提高了系统的响应性和效率。

2. 批处理灵活性（Batching Flexibility）：

   • 现有系统： 为了批处理效率，通常要求批次内所有请求的输入张量形状严格一致，这在自回归生成任务中难以实现（例如，不同请求已生成词元数量不同）。这导致它们在处理异构请求时效率低下或无法有效批处理。
   • ORCA： 提出了选择性批处理（selective batching）。它认识到 Transformer 模型中不同操作的特性，对大部分与模型参数无关的线性操作进行“词元级（token-wise）”批处理，而对 Attention 操作则按请求单独处理。这种方式允许将具有不同输入长度或不同生成进度的请求灵活地组合在一个批次中，从而维持高 GPU 利用率。

3. 流水线并行（Pipeline Parallelism）实现：

   • FasterTransformer： 为了在请求级调度下实现流水线，它需要将批次拆分为微批次（microbatches）。这可能导致批处理效率和流水线效率之间的权衡（trade-off）：微批次太小会降低批处理增益，微批次太大则可能在流水线中引入气泡（bubbles）。
   • ORCA： 凭借迭代级调度，可以直接在请求级别实现高效的流水线并行，而无需将批次拆分为微批次。这消除了上述权衡，能够同时实现高批处理效率和高流水线效率。

4. GPU 内存管理：

   • FasterTransformer： 为每个请求预分配固定大小的 Attention Key/Value 内存，这可能导致内存浪费或 OOM（Out-Of-Memory）错误，尤其是在序列长度较长时。
   • ORCA： 采用更细粒度的内存管理，为每个请求动态预留 Attention Key/Value 槽位，避免了不必要的内存浪费，提高了大规模模型服务的鲁棒性。

5. 控制/数据平面分离（Control/Data Plane Separation）：

   • 现有分布式系统： CPU-GPU 之间通过 NCCL 等机制同步控制消息和数据，在每次迭代都会产生非必要开销。

   • ORCA： 将控制消息（control messages）和数据传输（tensor data transfer）的通信通道分离。控制消息通过 gRPC 等独立通道传输，而张量数据则通过 NCCL，显著减少了 CPU-GPU 同步开销，尤其是在跨层间并行的场景下。

     总结来说，ORCA 通过重新思考调度和批处理的粒度，并结合优化的分布式架构和内存管理，专门为 Transformer-based 生成模型的自回归、多迭代特性量身定制，解决了现有系统在处理此类工作负载时的根本性瓶颈。

4. 方法论

4.1. 方法原理

ORCA 的核心原理在于认识到 Transformer-based 生成模型推理的“多迭代”和“自回归”特性与现有推理系统的“请求级调度”和“严格批处理”机制之间的不匹配。针对此，ORCA 提出了两个核心技术：迭代级调度（iteration-level scheduling）和选择性批处理（selective batching）。

1. 迭代级调度（Iteration-level Scheduling）：

   • 核心思想： 将模型执行的调度粒度从处理整个请求的完成（request completion）变为处理模型单次迭代的完成（single iteration completion）。
   • 直觉： Transformer 生成模型每次只输出一个词元（token），然后将这个词元反馈作为下一次迭代的输入。这意味着模型是逐次迭代地工作的。如果调度器能够在每次迭代结束后获得控制权，那么它就可以在每次迭代后检查请求的状态，并根据需要灵活地调整批次。
   • 优势：
     • 即时返回： 已完成生成的所有词元的请求可以立即从批次中移除并返回给客户端，不再需要等待批次中其他请求的完成。这显著降低了尾延迟（tail latency）。
     • 动态批次组合： 调度器可以在每次迭代后重新评估请求池（request pool），将新到达的请求或符合条件的请求加入到下一个迭代的批次中。这使得批次可以更动态地组成，提高了 GPU 利用率，并降低了新请求的排队时间。
     • 资源节约： 避免了对已完成请求进行不必要的计算。

2. 选择性批处理（Selective Batching）：

   • 核心思想： 解决迭代级调度下批次中请求输入形状不规则（irregularly shaped inputs）的问题，同时尽可能保留批处理带来的效率优势。
   • 直觉： Transformer 模型并非所有操作都严格依赖于批次维度。例如，矩阵乘法、层归一化等操作，在一定程度上可以处理展平（flattened）的输入，即使这些输入来自不同长度的序列。而 Attention 操作则需要区分不同请求的词元，因为它只在同一请求的词元内部计算注意力。
   • 优势：

     • 支持异构请求批处理： 允许将处于不同生成阶段（例如，不同输入词元数量或已生成词元数量）的请求组合在一个批次中。

     • 保持 GPU 效率： 对于大部分计算量较大的非 Attention 操作，仍然可以通过“词元级”批处理获得 GPU 并行计算的优势。

     • 对 Attention 操作影响小： Attention 操作本身不涉及模型参数（model parameters），因此即使对其单独处理，也不会损失参数复用带来的效率提升。

       这两个技术相辅相成：迭代级调度提供了调度灵活性，而选择性批处理解决了这种灵活性带来的批处理难题，共同实现了 ORCA 在低延迟和高吞吐量方面的性能优势。

4.2. 核心方法详解 (逐层深入)

4.2.1. 挑战与解决方案概览 (Challenges and Proposed Solutions Overview)

论文在 3 Challenges and Proposed Solutions 中详细阐述了现有系统的两大挑战以及 ORCA 提出的对应解决方案。

挑战 C1：提前完成和迟加入的请求（Early-finished and late-joining requests）

• 问题描述： 现有系统（如 Triton + FasterTransformer）采用请求级调度（request granularity）。这意味着：

  • 批次固定： 一旦一个批次被调度，其中的请求集合就固定了，直到批次中所有请求都处理完成。
  • 早期完成请求的阻塞： 如果批次中某个请求比其他请求更快地完成生成（例如，生成了 $<EOS>$ token），它也必须等待批次中所有其他请求完成后才能返回结果给客户端，导致不必要的延迟。
  • 新请求的等待： 在批次处理期间到达的新请求必须等待当前批次完全完成，才能被纳入下一个批次处理，导致高排队延迟。

• 额外计算： 即使请求已完成，现有系统仍可能为批次中的“不活跃（inactive）”请求执行计算，造成资源浪费。

  以下是原文 Figure 3 的示意图，展示了请求级调度导致的问题：

  该图像是论文中Orca系统的示意图，展示了请求池、调度器和执行引擎的交互流程，其中请求池中的令牌以 $x_{ij}$ 表示，灰色块表示客户端输入令牌，白色块表示Orca生成的令牌。

Figure 3: An illustration for a case where the requests have the same input length but some requests finish earlier than others. Shaded tokens represent input tokens. "" denotes inputs and outputs of extra computation imposed by the scheduling.

解决方案 S1：迭代级调度（Iteration-level scheduling）

• 核心思想： 调度器（scheduler）和执行引擎（execution engine）在**迭代级别（granularity of iteration）**进行交互，而非请求级别。
• 工作流程： 调度器重复以下步骤：
  1. 选择接下来要运行的请求集合。
  2. 调用引擎执行模型的一次迭代（a single iteration）处理这些选定的请求。
  3. 接收引擎返回的执行结果（即输出词元）。
• 优势：

  • 即时返回： 调度器在每次迭代后都能接收结果并检查请求状态，一旦请求完成，即可立即返回给客户端。

  • 动态加入： 新到达的请求可以在当前迭代完成后，有机会被调度器选择加入下一个迭代的批次中，显著减少排队延迟。

  • 灵活控制： 调度器可以完全控制每次迭代中处理哪些请求以及处理多少请求。

    以下是原文 Figure 4 的系统架构图，展示了 ORCA 的迭代级调度流程：

    该图像是论文中的示意图，展示了ORCA执行引擎如何通过选择性批处理在批次请求上运行Transformer层，图中包含QKV线性变换、拆分、注意力计算及合并等模块，使用了$x_{ij}$等符号描述输入，强调了注意力键值管理。

Figure 4: System overview of OrCA. Interactions between components represented as dotted lines indicate that the interaction takes place at every iteration of the execution engine. x _ { i j } is the $\mathbf { j }$ -th token of the i-th request. Shaded tokens represent input tokens received from the clients, while unshaded tokens are generated by OrCA. For example, request x _ { 1 } initially arrived with two input tokens ( x _ { 1 1 } , x _ { 1 2 } ) and have run two iterations so far, where the first and second iterations generated x _ { 1 3 } and x _ { 1 4 } , respectively. On the other hand, request x _ { 3 } only contains input tokens ( x _ { 3 1 } , x _ { 3 2 } ) because it has not run any iterations yet.

• ORCA 系统架构描述：
  1. 客户端请求通过 endpoint (如 HTTPS 或 gRPC) 到达系统。
  2. endpoint 将新到达的请求放入请求池（request pool）。请求池管理系统中所有请求的生命周期。
  3. **调度器（scheduler）**监控请求池，负责：
     • 从请求池中选择一组请求。
     • 调度执行引擎（execution engine）对这组请求运行模型的一次迭代。
     • 从引擎接收执行结果（即输出词元）。
     • 通过将输出词元追加到相应请求来更新请求池。
  4. **执行引擎（execution engine）**是一个抽象层，负责执行实际的张量操作，并可跨多个 GPU 和机器进行并行化。
  5. 在 Figure 4 的示例中：
     • 调度器 $(1)$ 与请求池交互，决定运行哪些请求。
     • 调度器 $(2)$ 调用引擎运行四个选定请求 $\left( x _ { 1 } , x _ { 2 } , x _ { 3 } , x _ { 4 } \right)$。对于首次调度的请求（如 x _ { 3 } 和 x _ { 4 }），调度器提供其输入词元。
     • 引擎 $(3)$ 对这四个请求运行模型的一次迭代。
     • 引擎 $(4)$ 返回生成的输出词元 ( x _ { 1 5 } , x _ { 2 3 } , x _ { 3 3 } , x _ { 4 4 } )，每个请求一个。
  6. 一旦请求处理完成，请求池会移除该请求并通知 endpoint 发送响应。
  • 关键区别： 与 Figure 2 (现有系统) 不同，ORCA 的调度器可以在每次迭代后改变批次中的请求，实现高度灵活性。

挑战 C2：批处理任意请求集合（Batching an arbitrary set of requests）

• 问题描述： 为了实现高效率，执行引擎应该能够以批处理方式处理任何选定的请求集合。但迭代级调度使得请求集合中的请求可能处于不同阶段，导致它们的输入张量形状不规则，难以直接批处理。
• 无法批处理的三种情况：
  1. 初始化阶段（initiation phase）且输入词元数量不同： 例如，Figure 4 中的 x _ { 3 } 和 x _ { 4 } 分别有 2 和 3 个输入词元。它们的输入张量长度（$L$ 维度）不相等，无法合并。
  2. 增量阶段（increment phase）且处理的词元索引不同： 例如，Figure 4 中的 x _ { 1 } 和 x _ { 2 } 正在处理不同索引的词元。根据 Figure 1c，这将导致它们的 Attention Key/Value 状态张量形状不同。
  3. 请求处于不同阶段： 例如，一个请求在初始化阶段，另一个在增量阶段。初始化阶段通常并行处理所有输入词元，而增量阶段每次处理一个词元，两者输入模式不同。

解决方案 S2：选择性批处理（Selective batching）

• 核心思想： 不对所有张量操作都进行批处理，而是有选择性地仅对部分操作应用批处理。

• 原因分析： 导致无法批处理的主要问题在于不规则形状的输入（或状态）张量。然而，并非所有操作都与这些不规则形状不兼容。

• 具体策略：

  • 非 Attention 操作： 大多数非 Attention 操作（如 Linear、LayerNorm、Add、GeLU）可以处理扁平化（flattened）的不规则张量。例如，Figure 4 中 x _ { 3 } ([2, H]) 和 x _ { 4 } ([3, H]) 的输入可以合并为一个 [5, H] 的二维张量，用于这些操作。它们不需要区分来自不同请求的张量元素。
  • Attention 操作： Attention 操作需要知道请求的边界，以确保只在同一请求的词元内部计算注意力。因此，对于 Attention 操作，ORCA 会拆分批次（splits the batch），并单独处理每个请求（process each request individually）。

• Attention 键值管理器（Attention K/V manager）： ORCA 维护一个管理器来存储增量阶段请求（如 x _ { 1 } 和 x _ { 2 }）的 Attention Key/Value 状态，以便在后续迭代中重用。

  以下是原文 Figure 5 的示意图，展示了 ORCA 执行引擎中的选择性批处理机制：

  该图像是一个示意图，展示了图6中的层内和层间并行示例。图中用垂直虚线表示层间的划分，水平虚线表示层内的划分，箭头指示数据流向和处理顺序。

Figure 5: An illustration of ORCA execution engine running a Transformer layer on a batch of requests with selective batching. We only depict the QKV Linear, Attention, and Attention Out Linear operations for simplicity.

• Figure 5 描述：
  1. 对于 $(x_1, x_2, x_3, x_4)$ 组成的批次，总共有 7 个输入词元。
  2. 输入张量形状被统一为 [7, H] ( $H$ 是隐藏维度 hidden size )，并首先应用于非 Attention 操作（例如 QKV Linear 的一部分）。
  3. 在 Attention 操作之前，插入一个 Split 操作，将批次拆分为独立的请求。
  4. Attention 操作对每个请求单独进行处理。对于增量阶段的请求（x _ { 1 } 和 x _ { 2 }），Attention 会从 Attention K/V manager 中获取之前迭代的 Key/Value 状态。
  5. Attention 操作的输出通过 Merge 操作重新合并回 [7, H] 形状的张量。
  6. 合并后的张量再次送入后续的非 Attention 操作（例如 Attention Out Linear）。

4.2.2. 分布式架构 (Distributed Architecture)

ORCA 的分布式架构旨在支持数百亿参数规模的大型模型，这些模型无法单次放入一个 GPU。它结合了 Transformer 模型中已知的两种并行策略：层内并行（intra-layer parallelism）和层间并行（inter-layer parallelism）。

1. 并行策略：

   • 层内并行（Intra-layer Parallelism）：将矩阵乘法（Linear 和 Attention 操作）及其相关参数分割到多个 GPU 上。例如，一个大的矩阵乘法 AB 可以被分解为 $A_1B_1 + A_2B_2$ 并在多个 GPU 上并行计算。

   • 层间并行（Inter-layer Parallelism）：将 Transformer 模型的不同层分配给不同的 GPU。例如，模型的前几层在一个 GPU 上计算，后几层在另一个 GPU 上计算。ORCA 将相同数量的 Transformer 层分配给每个 GPU。

     以下是原文 Figure 6 的示意图，展示了层内和层间并行的示例：

     该图像是 ORCA 执行引擎分布式架构示意图，展示了 Scheduler、Engine Master 及两个 Worker 的控制平面与数据平面间的交互关系，以及各 Worker 内部多 GPU 之间的通信。

Figure 6: An example of intra- and inter- layer parallelism. A vertical dotted line indicates partitioning between layers and a horizontal line indicates partitioning within a layer.

• Figure 6 描述： 一个 4 层 GPT 模型被分割为 2 个层间分区（inter-layer partitions），每个分区内的层又被细分为 3 个层内分区（intra-layer partitions）。最终，每个分区分配给一个 GPU，总共使用 6 个 GPU。

2. ORCA 引擎架构与执行流程：

   • ORCA 引擎的每个工作器（worker process）负责模型的一个层间分区，并可部署在不同的机器上。每个工作器管理一个或多个 CPU 线程，每个线程专门控制一个 GPU，具体数量取决于层内并行的程度。

     以下是原文 Figure 7 的示意图，展示了 ORCA 引擎的分布式架构：

     该图像是三幅柱状图，展示了不同批处理大小下ORCA与FasterTransformer在不同规模GPT模型（13B、101B、175B）和不同GPU数量配置上的执行时间对比，体现了ORCA在延迟上的优势。

Figure 7: An illustration of the distributed architecture of ORCA's execution engine using the parallelization configuration shown in Figure 6. For example, the first inter-layer partition (Layer1 and Layer2) in Figure 6 is assigned to Worker1, while the second partition is assigned to Worker2.

• Figure 7 描述：
  • 调度（Scheduling）： 一旦引擎被调度执行一个批次的模型迭代，引擎主控（engine master）将调度批次的信息转发给第一个工作器（Worker1）。
  • 信息内容： 包括当前迭代的词元（tokens）和一个控制消息（control message）。控制消息包含批次中请求的 ID、当前词元索引（用于增量阶段的请求）以及输入词元数量（用于初始化阶段的请求）。
  • GPU 核启动： Worker1 的控制器将信息传递给其 GPU 控制线程，每个线程解析信息并向其关联的 GPU 发出相应的 GPU 核（GPU kernels）。例如，Attention 操作的核会使用请求 ID 和当前词元索引从 Attention K/V manager 获取之前 Key/Value 的 GPU 内存地址。
  • 控制消息转发： Worker1 的控制器同时将控制消息转发给下一个工作器（Worker2）的控制器，而无需等待 Worker1 GPU 上核的完成。
  • 结果返回： 最后一个工作器（如 Worker2）的控制器会等待其 GPU 核的完成，然后获取每个请求的输出词元，并将其发送回引擎主控。

3. 控制/数据平面分离（Control/Data Plane Separation）：
   • 问题： 现有分布式推理系统（如 FasterTransformer）在 CPU 和 GPU 之间进行同步，并且控制消息通过 GPU-to-GPU 通信通道（如 NCCL）交换。这在每次迭代都会引入显著的性能开销。
   • ORCA 方案： ORCA 将控制消息（control messages，包含 tokens）和张量数据传输（tensor data transfer）的通信通道分离。
     • 控制消息： 通过独立的非 GPU 通道（如 gRPC）在引擎主控和工作器控制器之间传输。
     • 张量数据： 仅在 GPU 之间交换中间张量数据时使用 NCCL（图中的虚线箭头），因为这是 GPU 产生和消费的数据。
   • 优势： 避免了 CPU 和 GPU 之间不必要的同步，从而提高了效率。

4.2.3. 调度算法 (Scheduling Algorithm)

ORCA 调度器在每次迭代中决定选择哪些请求进行处理。由于选择性批处理的存在，调度器在请求组合上具有高度灵活性。

1. 调度策略：

   • 迭代级先进先出（iteration-level first-come-first-served (FCFS)）：ORCA 调度器采用一个简单算法，不改变客户端请求的处理顺序。即，先到达的请求先被处理。如果请求 x _ { i } 比 x _ { j } 先到达，则 x _ { i } 应该已经运行了相同或更多次的迭代。需要注意的是，尽管如此，迟到达但所需迭代次数较少的请求仍可能比早到达但所需迭代次数较多的请求更早完成并返回。

2. 额外考虑因素： 调度器还需要考虑以下因素：

   • 批次大小的边际效益递减和 max batch size： 增加批次大小可以提高吞吐量，但边际效益会递减，且可能增加延迟。ORCA 引入了 max_batch_size 这一参数，由系统操作员调整，以在吞吐量和延迟之间找到平衡。
   • GPU 内存约束：Attention K/V 状态的内存管理：

     • Attention K/V manager 用于存储 Key/Value 状态，这些状态在请求完成前不能被回收。

     • 调度器必须感知预分配的内存区域（n_slots）的剩余大小，以避免在存储新词元的 Key/Value 时发生死锁（deadlock）。n_slots 是 Attention K/V manager 可用内存大小的参数，由操作员配置。

     • ORCA 在请求首次被调度（即处于初始化阶段）时，会预留其 max_tokens（请求最大生成词元数）对应的 GPU 内存槽位，确保在整个生成过程中内存充足。

       以下是原文 Algorithm 1 的调度算法伪代码：

Algorithm 1 Iteration-level scheduling algorithm for ORCA.

Params: n_workers: number of workers, max_bs:   
max batch size, n_slots: number of K/V slot   
1 n_scheduled ← 0   
2 n_rsrv ← 0   
3 while true do   
4   batch, n_rsrv ← Select(request_pool, n_rsrv)   
5   schedule engine to run one iteration of   
    the model for the batch   
6   foreach req in batch do   
7     req.state ← RUNNING   
8     n_scheduled ← n_scheduled + 1   
9     if n_scheduled = n_workers then   
10      wait for return of a scheduled batch   
11      foreach req in the returned batch do   
12        req.state ← INCREMENT   
13        if finished(req) then   
14          n_rsrv ← n_rsrv - req.max_tokens   
15          n_scheduled ← n_scheduled - 1   
16   
17 def Select(pool, n_rsrv):   
18   batch ← EMPTY   
19   pool ← { req ∈ pool | req.state ≠ RUNNING }   
20   SortByArrivalTime(pool)   
21   foreach req in pool do   
22     if batch.size() = max_bs then break   
23     if req.state = INITIATION then   
24       new_n_rsrv ← n_rsrv + req.max_tokens   
25       if new_n_rsrv > n_slots then break   
26       n_rsrv ← new_n_rsrv   
27     batch ← batch ∪ {req}   
28   return batch, n_rsrv

• 符号解释：

  • n_workers：工作器（worker）的数量。
  • max_bs：最大批次大小（max batch size）。
  • n_slots：Attention K/V manager 中可用的 K/V 槽位总数。一个槽位是存储单个词元的 Attention Key 和 Value 所需的内存量。
  • n_scheduled：当前已调度且尚未返回的批次数量。
  • n_rsrv：当前已预留的 K/V 槽位总数。
  • request_pool：系统中所有待处理和正在处理的请求池。
  • batch：当前迭代选中的请求集合。
  • req.state：请求的状态，可以是 INITIATION (初始化阶段，首次调度)、INCREMENT (增量阶段，已生成部分词元) 或 RUNNING (正在运行)。
  • req.max_tokens：请求预期生成的最大词元数量。
  • SortByArrivalTime(pool)：根据请求到达时间对请求池中的请求进行排序。
  • finished(req)：判断请求是否已完成（例如，已生成 $<EOS>$ 词元或达到 max_tokens）。

• 算法流程详解：

  • 主循环 (while true loop)：
    • 第 4 行： 调用 Select 函数从请求池中选择一个批次 batch，并更新预留槽位数 n_rsrv。
    • 第 5 行： 调度引擎对该批次执行模型的一次迭代。
    • 第 6-8 行： 遍历批次中的每个请求，将其状态设为 RUNNING，并增加 n_scheduled 计数。
    • 第 9-10 行： 如果 n_scheduled 达到 n_workers（表示所有工作器都已忙碌），则等待一个已调度批次完成并返回。
    • 第 11-15 行： 遍历返回的批次中的每个请求：
      • 将其状态设为 INCREMENT (表示已完成一次迭代，进入增量阶段)。
      • 如果请求已完成（finished(req)），则释放其预留的 K/V 槽位（n_rsrv -= req.max_tokens），并减少 n_scheduled 计数。
  • Select 函数 ($def Select(pool, n_rsrv)$):
    • 第 18 行： 初始化空批次。
    • 第 19 行： 过滤掉请求池中当前处于 RUNNING 状态的请求，只考虑待处理的请求。
    • 第 20 行： 根据到达时间对请求池进行排序（实现 FCFS）。
    • 第 21-27 行： 遍历排序后的请求：
      • 第 22 行： 如果批次已达到 max_bs，则停止选择。
      • 第 23-26 行（内存预留逻辑）： 如果请求处于 INITIATION 阶段（即首次调度），则计算预留其 max_tokens 所需的 K/V 槽位后，新的 n_rsrv 值。如果这个新值超过了总可用槽位 n_slots，则无法调度该请求，并停止选择（break）。否则，更新 n_rsrv。
      • 第 27 行： 将请求添加到批次中。
    • 第 28 行： 返回选定的批次和更新后的 n_rsrv。

3. 流水线并行（Pipeline Parallelism）：

   • ORCA 的调度器通过控制 n_scheduled 来实现工作器之间的流水线。调度器不会等待一个已调度批次的返回，直到 n_scheduled 达到 n_workers (算法 1 的 9-10 行)。

   • 这意味着调度器会确保有 n_workers 个批次在引擎中并发运行，从而使每个工作器都持续忙碌，实现了流水线执行。

   • 与 FasterTransformer 的对比： FasterTransformer 需要将批次拆分为微批次（microbatches）来在请求级调度下实现流水线。这导致批处理效率（较大的微批次）和流水线效率（较小的微批次以减少气泡）之间的权衡。而 ORCA 由于迭代级调度，可以直接在请求级别实现流水线，无需微批次，因此没有这种权衡。

     以下是原文 Figure 8 的示意图，对比了 ORCA 和 FasterTransformer 的流水线并行使用：

     该图像是包含三个子图的图表，展示了不同规模Transformer模型（101B、175B、341B）在多GPU环境下，使用不同服务系统（ft和orca）时的延迟与吞吐量关系。

Figure 8: Comparison of the use of pipeline parallelism in ORCA and FasterTransformer where X _ { i } is the i-th iteration of request $X$ .

• Figure 8a: ORCA execution pipeline 描述：

  • 展示了 3 个 ORCA worker 的执行流水线，max batch size 为 2。
  • 调度器连续注入批次 AB、CD、EF。
  • 当 Worker1 处理批次 AB 时，Worker2 可以处理批次 CD，Worker3 可以处理批次 EF。
  • 当 AB 完成在 Worker1 上的处理并流转到 Worker2 时，Worker1 就可以开始处理新的批次 A2B2。
  • 这种方式保持了所有 worker 持续忙碌，实现了高效的流水线。

• Figure 8b: FasterTransformer execution pipeline 描述：

  • FasterTransformer 必须等待整个批次 AB 完成才能注入下一个批次 CD。
  • 为了实现流水线，它将批次 AB 拆分为微批次 $A$ 和 $B$。
  • 即使如此，由于请求级调度的限制，Triton 无法在当前批次 AB 完成前注入新的请求。
  • 这导致了流水线中存在气泡，且微批次会降低批处理带来的性能增益。

4.2.4. 实现细节 (Implementation Details)

ORCA 的实现基于 13K 行 $C++$ 代码和 CUDA 生态系统。

• 通信：
  • 控制平面： 使用 gRPC ([2]) 进行 ORCA 引擎控制平面的通信（如调度器与工作器控制器之间）。
  • 数据平面： 使用 NCCL ([5]) 进行层内（intra-layer）和层间（inter-layer）的数据传输（即 GPU-to-GPU 张量数据交换）。
• 模型支持： 专注于 Transformer-based 生成模型，提供常见的 Transformer 层作为构建块，包括原始编码器-解码器 Transformer ([60])、GPT ([47]) 及其变体 ([49])。
• 融合核（Fused Kernels）： ORCA 实现了 LayerNorm、Attention 和 GeLU 等操作的融合 CUDA 核，这与 FasterTransformer ([4]) 等系统类似，旨在减少核启动开销和提高 GPU 利用率。
  • Attention 融合： 将 Attention 查询与键的点积计算、Softmax 和注意力值加权平均等步骤融合到一个 CUDA 核中。
  • 选择性批处理的融合： 进一步将拆分的 Attention 操作核通过简单地连接所有请求的线程块（thread blocks）进行融合。尽管这会导致核内的线程块具有不同的特性和生命周期，但实验发现这种融合有利于提高 GPU 利用率和减少核启动开销。

5. 实验设置

5.1. 数据集

论文中没有使用特定的文本数据集进行训练或直接推理，而是通过**合成（synthesize）客户端请求轨迹（trace）**来评估 ORCA 的端到端性能。这种方法旨在模拟真实世界的负载情况。

• 请求轨迹生成方式：

  • 输入词元数量： 每个请求的输入词元数量从 $U(32, 512)$ (32 到 512 之间，包含边界) 的均匀分布（uniform distribution）中随机采样。
  • 最大生成词元数量（max_gen_tokens）： 从 $U(1, 128)$ (1 到 128 之间，包含边界) 的均匀分布中随机采样。这意味着最少需要 1 次迭代，最多需要 128 次迭代来完成请求。
  • 总词元数量： 输入词元数量加上 max_gen_tokens 等于请求的 max_tokens 属性。
  • 生成终止： 假设所有请求会一直生成，直到达到 max_gen_tokens。即模型不会发出 $<EOS>$ (end-of-sequence) 词元。作者解释这是因为他们没有实际模型检查点和输入文本，无法准确预测 $<EOS>$ 生成时机。
  • 到达时间： 请求的到达时间基于**泊松过程（Poisson process）**生成，通过改变泊松参数（即到达速率 arrival rate）来模拟不同的系统负载。

• 为何选择合成轨迹：

  • 公开可用的生成语言模型请求轨迹稀缺。
  • 合成轨迹允许灵活控制负载特性（如输入长度分布、生成长度分布、到达速率），从而系统地评估系统在不同条件下的行为。

5.2. 评估指标

论文使用了以下评估指标来衡量 ORCA 和基线系统的性能：

1. 延迟（Latency）

   • 概念定义： 延迟是指从客户端发送请求到接收到完整响应所需的时间。在生成模型中，这个时间通常包括请求的排队时间、模型处理时间以及网络传输时间。为了更好地比较，论文报告了中位归一化延迟（median normalized latency）。
   • 数学公式： 如果原始延迟为 $L_{raw}$，请求生成的词元数量为 $N_{gen}$，则归一化延迟 $L_{normalized}$ 为： $$L_{normalized} = \frac{L_{raw}}{N_{gen}}$$
   • 符号解释：
     • $L_{normalized}$：归一化延迟，通常以毫秒/词元（ms/token）为单位。
     • $L_{raw}$：原始端到端延迟，以毫秒（ms）为单位。
     • $N_{gen}$：请求生成的词元数量。
   • 设计目标： 归一化延迟消除了不同请求生成长度差异带来的影响，使得延迟指标能够更公平地反映模型和系统每生成一个词元的效率。

2. 吞吐量（Throughput）

   • 概念定义： 吞吐量是指系统在单位时间内成功处理的请求数量。它是衡量系统处理能力和效率的关键指标。
   • 数学公式： 如果系统在时间 $T_{total}$ 内处理了 $N_{requests}$ 个请求，则吞吐量 TP 为： $$TP = \frac{N_{requests}}{T_{total}}$$
   • 符号解释：
     • TP：吞吐量，通常以请求数/秒（req/s）为单位。
     • $N_{requests}$：在测量时间内处理的总请求数量。
     • $T_{total}$：总测量时间，以秒（$s$）为单位。
   • 设计目标： 吞吐量越高，表示系统在单位时间内能服务更多的用户或处理更多的数据。

5.3. 对比基线

论文主要将 ORCA 与 NVIDIA FasterTransformer ([4]) 进行比较。

• NVIDIA FasterTransformer：

  • 选择原因： 这是一个知名的、针对 Transformer 模型优化的推理引擎，支持通过分布式执行来处理大规模模型。它代表了当前用于 Transformer 模型推理的先进系统之一。
  • 特点： 它专注于底层 CUDA 核的优化，并支持模型并行。然而，它作为一个执行引擎，其调度职责通常委托给上层服务系统（如 Triton Inference Server），因此遵循请求级调度。为了在分布式环境下实现流水线，它将批次拆分为微批次（microbatches）。
  • 限制：
    • FasterTransformer 会为每个请求预分配固定量的 Attention Key/Value 内存，可能导致内存浪费或在批次大小较大或序列长度较长时发生 Out-Of-Memory (OOM) 错误。
    • 在处理异构请求（不同输入长度、不同生成进度）时，其请求级调度机制表现不佳。
    • 微批次策略在批处理效率和流水线效率之间存在权衡。

• 未选择其他基线的原因： 论文提到，虽然 Megatron-LM ([3]) 和 DeepSpeed ([1]) 等系统也支持分布式执行，但它们主要设计和优化用于训练工作负载，因此在推理性能方面通常不如专门为推理优化的系统。

5.4. 环境配置

• 硬件： Azure ND96asr A100 v4 VMs。每台 VM 配备 8 块 NVIDIA 40-GB A100 GPU，通过 NVLink 连接。最多使用 4 台 VM。每台 VM 还有 8 个 Mellanox 200Gbps HDR Infiniband 适配器，提供 $1.6 Tb/s$ 的 VM 间互连带宽。
• 模型： GPT ([12]) 模型，作为 Transformer-based 生成模型的代表。

  • 配置（Table 1）： 以下是原文 Table 1 的结果：

    # Params	# Layers	Hidden size	# Inter- partitions	# Intra- partitions
    13B	40	5120	1	1
    101B	80	10240	1	8
    175B	96	12288	2	8
    341B	120	15360	4	8

    • 模型规模： 13B (130 亿参数) 到 341B (3410 亿参数)。
    • 最大序列长度： 所有模型都设置为 2048。
    • 精度： 使用 fp16 格式的模型参数和中间激活值。
    • 并行策略： 除了 13B 模型可以完全放入单个 GPU 外，其他模型都应用了层间并行和层内并行。例如，175B 模型分布在 16 个 GPU 上，包含 2 个层间分区和 8 个层内分区。
• 软件： ORCA 使用 13K 行 $C++$ 代码实现。通信库包括 gRPC (控制平面) 和 NCCL (数据平面)。

5.5. 实验场景（Scenarios）

论文设计了两种不同的实验场景来评估 ORCA 的性能：

1. 引擎微基准测试（Engine Microbenchmark）：

   • 目的： 评估 ORCA 执行引擎的纯粹性能，不受迭代级调度的影响。
   • 设置：
     • 不运行 ORCA 调度器。
     • 给定一个批次的请求，测试脚本重复将相同的批次注入 ORCA 引擎，直到批次中所有请求完成，模拟传统请求级调度的行为。
     • 所有请求具有相同的输入词元数量（32 或 128）和生成词元数量（32）。这意味着批次中的所有请求同时开始和结束。
   • 报告指标： 处理整个批次所需的时间（非单个请求）。
   • 对比： 与 FasterTransformer 进行比较。

2. 端到端性能评估（End-to-end Performance Evaluation）：

   • 目的： 评估 ORCA 整个软件栈（包括 ORCA 调度器）在模拟工作负载下的真实端到端性能。
   • 设置：
     • 使用 5.1 节描述的合成客户端请求轨迹。
     • 客户端请求按照轨迹到达 ORCA 调度器。
     • FasterTransformer 使用一个自定义调度器，该调度器模拟现有服务系统（如 Triton）的常见批处理行为：从请求队列中动态选取最多 max batch size 个请求创建批次。
     • 对于 FasterTransformer，还测试了不同 microbatch size 的配置，因为这是其流水线行为的额外参数。
   • 报告指标： 中位归一化延迟和吞吐量。
   • 对比： ORCA 的不同 max batch size 配置与 FasterTransformer 的不同 max batch size 和 microbatch size 配置进行比较。

6. 实验结果与分析

6.1. 核心结果分析

6.1.1. 引擎微基准测试 (Engine Microbenchmark)

该部分评估了 ORCA 引擎在理想条件下（批次内请求同质，同步开始和结束）的性能，并与 FasterTransformer 进行了比较。

以下是原文 Figure 9 的结果：

该图像是包含三个子图的图表，展示了不同规模Transformer模型（101B、175B、341B）在多GPU环境下，使用不同服务系统（ft和orca）时的延迟与吞吐量关系。

Label "ft(n)" represents results from FasterTransformer processing requests with $n$ input tokens. Configurations that incurs out of memory error are represented as missing entries (e.g., ft(32) for the 101B model with a batch size of 16).

• Figure 9a (13B 模型，单 VM，1 GPU)：

  • ORCA 引擎和 FasterTransformer 的性能相似，甚至 ORCA 略差。
  • 原因分析： ORCA 在 Attention 操作上不进行批处理，而 FasterTransformer 对所有操作都进行批处理。尽管如此，性能差异相对较小。这是因为 Attention 操作本身不关联模型参数，因此对其单独处理并不会损失参数复用带来的效率。
  • OOM 问题： FasterTransformer 在 13B 模型上，当批次大小为 8 或更大时，会发生内存不足（OOM）错误。这是因为 FasterTransformer 为每个请求预分配固定量的 Attention Key/Value 内存，而 ORCA 通过 max_tokens 属性动态分配，避免了冗余内存。

• Figure 9b (101B 模型，单 VM，8 GPU)：

  • 结果与 13B 模型类似，两者性能相当。
  • 原因分析： 这表明 ORCA 引擎在 CUDA 核实现和层内分区（intra-layer partitions）之间的通信效率上与 FasterTransformer 相当。
  • OOM 问题： FasterTransformer 在 101B 模型上，当批次大小为 16 或更大时，会发生 OOM 错误，再次印证了其内存分配策略的局限性。

• Figure 9c (175B 模型，跨 VM，2 个层间分区，8 个 GPU / VM)：

  • ORCA 引擎的性能显著优于 FasterTransformer，最高可达 47% 的提升。

  • 原因分析： 在这个实验中，为了公平比较，两者都禁用了层间分区的流水线执行。ORCA 的优势归因于其**控制/数据平面分离（control-data plane separation）**设计。通过将控制消息（gRPC）和张量数据（NCCL）的通信通道分离，ORCA 减少了 CPU-GPU 同步开销，这在跨工作器通信（尤其是在分布式设置下）时尤为重要。

  • 341B 模型的结果与 175B 模型类似。

    结论： 即使在理想的同质批次条件下，ORCA 引擎也能与 FasterTransformer 保持可比甚至更优的性能，尤其是在大规模分布式模型上。其内存管理和控制/数据平面分离的优势开始显现。

6.1.2. 端到端性能 (End-to-end Performance)

该部分评估了 ORCA 在模拟真实世界工作负载（请求异构，动态到达）下的端到端性能，并与 FasterTransformer 进行了比较。

以下是原文 Figure 10 的结果：

该图像是图表，展示了使用175B模型在不同批次大小和生成长度条件下，ORCA与FasterTransformer系统的中位端到端延迟与吞吐量性能对比，图中用标签区分了不同配置和系统的表现。

ua u with a max batch size of max_bs and a microbatch size of mbs.

• Figure 10a (101B 模型)：

  • 低负载下： ORCA 和 FasterTransformer 的性能相似。这主要是因为低负载下请求数量不足以组成大批次，性能主要受引擎自身效率影响（类似于微基准测试结果）。
  • 高负载下： 随着负载增加，ORCA 表现出更高的吞吐量和相对更低的延迟增长。这得益于 ORCA 调度器能够让迟到达的请求“搭便车（hitch a ride）”当前的批次，有效处理异构请求。
  • FasterTransformer 的局限性： 在高负载下，FasterTransformer 的吞吐量峰值仅为 $0.49 req/s$，且延迟显著增加。它无法有效处理：1) 不同时间到达的请求；2) 需要不同迭代次数完成的请求；3) 具有不同输入词元数量的请求。

• Figure 10b (175B 模型) 和 Figure 10c (341B 模型)：

  • 对于使用多于一个层间分区的大模型，ORCA 在所有负载水平下都显著优于 FasterTransformer，无论是在延迟还是吞吐量方面。

  • ORCA 实现了数量级（an order of magnitude）更高的吞吐量。

  • 具体数据： 在 175B 模型上，为了匹配 190ms 的中位归一化延迟（约是 Figure 9c 中 $orca(128)$ 执行时间的两倍），FasterTransformer 的吞吐量为 $0.185 req/s$，而 ORCA 的吞吐量为 $6.81 req/s$，实现了 36.9 倍的加速。

    结论： ORCA 的迭代级调度和选择性批处理在处理真实世界中异构且动态到达的生成模型工作负载时，展现出压倒性的优势，特别是在大规模模型和高负载条件下。

6.1.3. 不同批次大小配置 (Varying batch size configurations)

• ORCA： Figure 10 显示，增加 ORCA 的 max batch size 会导致吞吐量增加，而延迟基本不受影响。这是因为迭代级调度解决了提前完成和迟加入请求的问题，使得批次可以更有效地被利用。然而，作者也指出，在任意硬件、模型和工作负载下，增加批次大小不一定会对延迟产生负面影响，需要仔细权衡。
• FasterTransformer： 增加 FasterTransformer 的 max batch size 不一定会提高吞吐量。实验发现，对于 FasterTransformer， (max_bs, mbs) = (1, 1) 或 $(8, 8)$ 是最佳选择。
  • 原因： FasterTransformer 的微批次（microbatch）流水线可能会降低效率，因为它每次只处理 mbs 数量的请求。因此，当 mbs 等于 max_bs 时（即不拆分微批次），性能反而更好。
  • 此外，增加 max_bs 也会增加批次中出现输入长度或生成长度差异较大的请求的可能性。在这种情况下，FasterTransformer 无法有效处理：1) 对于批次的第一次迭代，它会按照最短的输入长度处理所有请求；2) 提前完成的请求不能立即返回。

6.1.4. 同质请求轨迹 (Trace of homogeneous requests)

为了进一步验证，论文还评估了在同质请求轨迹（所有请求具有相同的输入词元数量和 max_gen_tokens 属性）下的性能。在这种情况下，提前完成请求的问题不会发生。

以下是原文 Figure 11 的结果：

该图像是论文中的示意图，展示了现有系统中生成式语言模型的整体服务工作流程，包括请求队列、调度器和执行引擎之间的交互。

Figure 11: Median end-to-end latency and throughput, using the 175B model with traces composed of homogeneous requests. We do not normalize the latency since all requests have the same characteristic.

• 结果： 在同质请求轨迹下，FasterTransformer 的性能会因为 max_bs 的增加而显著改善，因为此时批次内所有请求的行为一致，其请求级调度的缺点被最小化。
• 对比： 尽管如此，ORCA (max_bs=8) 仍然优于 FasterTransformer (max_bs=8)，唯一的例外是当 max batch size 为 1 时，ORCA 退化为不进行批处理的简单流水线，此时性能较低。这再次强调了 ORCA 在批处理和流水线效率上的设计优势。

6.2. 数据呈现 (表格)

由于 Table 1 已在 5.4. 环境配置 中呈现，这里不再重复。

6.3. 消融实验/参数分析

论文中没有明确标注为“消融实验”的部分，但以下几点可以看作是对 ORCA 各组件或参数的分析：

1. Attention 操作选择性批处理的影响：

   • 在 6.1.1 引擎微基准测试中，论文指出 ORCA 引擎在 Attention 操作上不进行批处理，而 FasterTransformer 会。但性能差异相对较小。
   • 分析： 这表明 Attention 操作不批量处理对整体效率的影响有限，因为它不涉及模型参数，不会损失参数复用。这间接验证了选择性批处理的有效性，即在不牺牲太多效率的前提下，获得了批处理异构请求的灵活性。

2. GPU 内存管理（n_slots 参数）：

   • 论文在 4.2.3 调度算法中讨论了 GPU 内存约束和 n_slots 参数。
   • 分析： FasterTransformer 的固定内存预分配导致 OOM 错误（Figure 9a 和 9b 中的缺失条目），而 ORCA 通过动态预留 K/V 槽位，避免了内存浪费和 OOM。这表明 ORCA 的内存管理策略是其鲁棒性的关键组件，使得它能够处理更长的序列和更大的批次。
   • n_slots 可以由系统操作员根据模型和硬件配置轻松调整，以最大化内存利用率。

3. max batch size 参数的影响：

   • 在 6.1.3 不同批次大小配置中进行了详细讨论。
   • ORCA： 增加 max batch size 提高了吞吐量而不显著增加延迟。这验证了迭代级调度在解耦吞吐量和延迟方面的有效性。
   • FasterTransformer： 增加 max batch size 不一定能提高吞吐量，并且需要与 microbatch size 配合调整。这凸显了 FasterTransformer 在处理异构批次和流水线方面的局限性。

4. 控制/数据平面分离的影响：

   • 在 6.1.1 引擎微基准测试中，175B 模型的结果 (Figure 9c) 显示 ORCA 引擎优于 FasterTransformer，作者将其归因于控制/数据平面分离。

   • 分析： 这表明 ORCA 的分布式通信优化是其在大规模模型上实现更高性能的关键因素，减少了 CPU-GPU 同步开销。

     这些分析虽然不是严格意义上的“消融实验”，但通过对比 ORCA 自身的参数变化和与基线系统在不同条件下的行为，有效地展示了 ORCA 核心设计（迭代级调度、选择性批处理、内存管理、通信优化）的有效性和优势。

7. 总结与思考

7.1. 结论总结

论文提出 ORCA (Open-access Retargetable Cloud-native AI Inference) 作为一个针对 Transformer-based 生成模型的分布式服务系统，旨在解决现有推理系统在处理此类多迭代、自回归工作负载时面临的高延迟和低吞吐量问题。ORCA 的核心创新在于迭代级调度（iteration-level scheduling）和选择性批处理（selective batching）。

迭代级调度使得调度器能在每次模型迭代后与执行引擎交互，从而允许已完成请求的即时返回，并动态地将新到达请求加入批次。选择性批处理则通过识别 Transformer 模型中不同操作的特性，对非 Attention 操作进行“词元级”批处理，而对 Attention 操作单独处理，解决了迭代级调度下批次中请求输入形状不规则的难题。

此外，ORCA 还结合了优化的分布式架构（层内/层间并行、控制/数据平面分离）和细粒度的 GPU 内存管理。实验结果表明，在 GPT-3 175B 模型上，ORCA 在相同延迟下比 NVIDIA FasterTransformer 实现了 36.9 倍的吞吐量提升，证明了其方法的显著有效性。

7.2. 局限性与未来工作

论文作者指出了以下局限性：

1. 模型范围： ORCA 的设计主要针对 Transformer-based 生成模型。尽管作者认为其他基于 Transformer 架构并使用自回归生成过程的模型（如图像、视频、语音生成模型）也能从中受益，但当前的实验仅在语言模型上进行，且没有展示在其他模态上的具体效果。

2. 通用接口设计： 论文中为了实现迭代级调度和选择性批处理，ORCA 选择了紧密集成调度器和引擎的设计。作者承认，这在一定程度上放弃了现有通用服务系统（如 Triton）中调度层和执行层分离的优点。他们将设计一个在支持这两项技术的同时仍能保持抽象分离的通用接口作为未来的研究方向。

3. 合成请求轨迹： 虽然论文使用了合成的客户端请求轨迹来评估端到端性能，但真实世界的生成语言模型请求轨迹可能具有更复杂的模式和特性，这可能对系统性能产生影响。

   未来可能的研究方向：

• 更通用的接口设计： 探索如何在不牺牲模块化和抽象分离的前提下，将迭代级调度和选择性批处理集成到更通用的推理服务系统中。
• 更广泛的模型验证： 在更多不同模态的 Transformer-based 生成模型上验证 ORCA 的性能和适用性。
• 高级调度策略： 除了 FCFS，可以探索更复杂的调度策略，例如结合优先级、服务质量（QoS）保证或更精细的负载均衡。
• 动态参数调整： 进一步研究 max_bs 和 n_slots 等参数的动态自适应调整策略，以更好地适应变化的负载和模型特性。

7.3. 个人启发与批判

7.3.1. 个人启发

1. 细粒度视角的重要性： ORCA 最大的启发在于，在面对新的、复杂的模型（如 Transformer 生成模型）时，不能简单地沿用旧的系统设计范式。将调度粒度从“请求”下沉到“迭代”，这一看似简单的转变，实则深刻地契合了生成模型的自回归特性，从而打开了优化的大门。这提示我们在系统设计中，对底层应用特性的深入理解是创新的关键。
2. 解耦与重构的艺术： 迭代级调度和选择性批处理是两个独立但又相互支撑的技术。迭代级调度解耦了请求的生命周期，而选择性批处理则应对了解耦带来的批处理挑战。这种先解耦问题，再针对解耦后的子问题提供创新解决方案的思路，在复杂系统设计中非常值得借鉴。
3. 系统级优化的巨大潜力： 论文展示了，即使底层 CUDA 核的优化已经做得很好（ORCA 引擎与 FasterTransformer 在微基准测试中性能相近），上层系统调度和架构的优化仍能带来数量级的性能提升。这意味着在 AI 时代，系统研究在赋能大规模模型应用方面具有不可替代的价值。
4. 对 Attention 机制的深刻理解： 选择性批处理的成功依赖于对 Attention 操作特性的精准把握——它不依赖模型参数，且需要区分请求内部的词元。这说明了在设计高效系统时，不仅要理解模型整体，更要深入到每个核心操作的计算特性。
5. 控制与数据平面分离： 这一设计在分布式系统中非常常见，但 ORCA 再次证明了其在 AI 推理场景下的有效性，通过减少不必要的 CPU-GPU 同步，显著提升了大规模模型的分布式性能。

7.3.2. 批判与潜在改进

1. 通用性与集成挑战： ORCA 紧密集成调度器和引擎的设计虽然实现了极致性能，但也牺牲了与现有通用推理服务系统（如 Triton）的兼容性。对于希望在现有基础设施上部署 ORCA 技术的用户而言，这可能是一个障碍。未来的工作可以探索如何以插件化（plug-in）或更标准化的接口形式，将 ORCA 的核心思想集成到这些通用平台中，以扩大其影响力。
2. Attention K/V 内存管理的进一步优化： 尽管 ORCA 改进了 FasterTransformer 的内存分配方式，但仍是基于 max_tokens 进行预留。对于生成长度具有高度不确定性的请求，预留 max_tokens 仍然可能导致一定的内存浪费。可以考虑更动态、更细粒度的内存池管理，例如使用基于引用的计数（reference counting）或垃圾回收机制，甚至结合预测（prediction）技术来估计实际所需的 Key/Value 内存。
3. 负载均衡和容错： 论文主要关注单体 ORCA 系统的性能优化，对多 ORCA 实例之间的负载均衡、故障恢复（fault tolerance）和高可用性（high availability）等生产级特性提及较少。在一个真实的大规模服务集群中，这些都是不可或缺的挑战。
4. 公平性与服务质量（QoS）： FCFS 调度策略在某些场景下可能不是最优的，例如，高优先级但计算量小的请求可能被大量低优先级但计算量大的请求阻塞。未来的研究可以探索更复杂的 QoS-aware 调度策略，以满足不同类型请求的服务需求。
5. 硬件异构性： 论文主要在 A100 GPU 上进行实验。在其他类型的 GPU 或加速器（如 TPU、CPU）上，ORCA 的性能和优化点可能会有所不同。例如，不同硬件的内存带宽、计算能力和通信原语可能需要不同的优化策略。