Fiddler: CPU-GPU Orchestration for Fast Inference of Mixture-of-Experts Models

作者/机构: Keisuke Kamahori1∗, Tian Tang1,2∗, Yile Gu1, Kan Zhu1, Baris Kasikci1
1University of Washington, 2Tsinghua University

A1 主要贡献

核心问题
在资源受限的环境（如个人电脑或边缘设备）中运行大型语言模型（LLM）变得日益重要，这有助于提升隐私、实现模型定制化，并普及先进的LLM技术。混合专家（Mixture-of-Experts, MoE）架构的LLM因其通过门控机制仅激活部分参数，计算需求相对较低，非常适合此类环境。然而，MoE模型的挑战在于其巨大的模型尺寸（如Mixtral-8x7B、Grok-1等），需要大量GPU内存来存储所有参数，导致在有限的GPU内存下进行本地推理十分困难。此外，由于推理时仅使用部分参数，大量GPU内存被闲置，造成资源浪费和成本效益低下。

现有方法的不足
现有的解决方案主要有两类，但都存在缺陷：
1. 权重卸载（Offloading）方法：这类系统将模型权重卸载到CPU内存，在需要时按需传输到GPU。虽然解决了内存容量问题，但由于CPU和GPU之间的PCIe连接带宽较低，频繁的数据传输会引入显著的运行时开销，导致延迟过高。
2. 基于CPU的推理框架：这类框架（如llama.cpp）将部分模型层放在GPU上执行，其余在CPU上执行，减少了参数传输开销。然而，它们未能考虑CPU和GPU在处理不同批量大小输入时的特性差异（即批处理效应），也未针对MoE模型的特性进行优化，导致在长序列预填充（long prefill）或束搜索（beam search）等关键应用场景中性能不佳。

本文的解决方案与创新点（Fiddler）
为解决上述挑战，本文提出了Fiddler，一个资源高效的MoE模型推理系统，旨在通过智能地协同利用CPU和GPU的异构计算架构，在GPU资源有限的情况下高效运行MoE模型。

核心思想与工作原理：
Fiddler的核心思想是根据CPU和GPU不同的批处理效应来动态制定最优的执行策略。
- CPU与GPU的延迟特性：当专家层在CPU上执行时，其延迟几乎与输入大小成线性增长。相比之下，GPU的执行延迟几乎不受输入大小影响，保持相对恒定，但如果权重需要从CPU传输，则会产生固定的传输开销。
- 动态执行策略：基于上述特性，Fiddler在运行时判断：
- 对于输入规模较小的专家层，在CPU上执行更高效，因为可以避免权重传输的高昂开销。
- 对于输入规模较大（如长序列预填充）的专家层，在CPU上计算会变得非常耗时，此时将权重传输到GPU并在GPU上执行则更为高效。

• Fiddler通过一个延迟模型，根据每个专家接收的输入token数量，动态地为每个专家选择在CPU还是GPU上执行，从而在各种工作负载下（包括单批次推理、长序列预填充和束搜索）实现高效推理。

其他优化：
1. 专家放置优化：为了最大化专家权重在GPU内存中的命中率，Fiddler通过离线分析专家使用的频率，将最常用的专家优先放置在GPU上。
2. 定制化CPU计算核：Fiddler为CPU上的专家处理设计了一个专门的计算核，利用了原生PyTorch不支持的AVX512_BF16指令集，以提升CPU计算效率。

主要贡献总结：
- 设计了Fiddler，一个面向资源受限异构架构的MoE模型推理系统，该系统能利用CPU和GPU找到最优的执行策略。
- 通过评估证明，与各类最先进的系统相比，Fiddler在单批次推理、长序列预填充处理和束搜索推理等多种场景下均取得了更优的性能，成功整合了不同类型现有系统的优点。

A3 背景知识

2.1 混合专家模型（MIXTURE-OF-EXPERTS）

MoE架构简介。基于MoE架构的LLM在各种应用中展现出良好的性能【索引31, Samyam Rajbhandari 等人, Deepspeed-moe: Advancing mixture-of-experts inference and training to power next-generation ai scale, 2022, International Conference on Machine Learning; 索引11, Nan Du 等人, Glam: Efficient scaling of language models with mixture-of-experts, 2022, International Conference on Machine Learning; 索引14, William Fedus 等人, Switch transformers: Scaling to trillion parameter models with simple and efficient sparsity, 2022, The Journal of Machine Learning Research; 索引19, Albert Q Jiang 等人, Mixtral of experts, 2024; 索引42, Fuzhao Xue 等人, Openmoe: An early effort on open mixture-of-experts language models, 2024a; 索引7, Damai Dai 等人, Deepseekmoe: Towards ultimate expert specialization in mixture-of-experts language models, 2024】。与传统的密集型Transformer模型【索引39, Ashish Vaswani 等人, Attention is all you need, 2017, Advances in neural information processing systems】不同，MoE模型通过一个专家系统和一个门控机制为前馈层（feed-forward layer）引入了稀疏性。每个MoE层包含多个与前馈层形状相同的专家层，并由一个门控网络（gating network）决定为每个输入激活哪些专家。尽管一个MoE层可能包含数千个专家【索引14, William Fedus 等人, Switch transformers: Scaling to trillion parameter models with simple and efficient sparsity, 2022, The Journal of Machine Learning Research】，但在训练或推理过程中，门控网络只会激活其中少数几个。

2.2 在异构架构下部署大模型

异构架构部署的挑战。由于MoE模型尺寸巨大，在资源受限的环境中高效部署它们充满挑战。一些现有系统利用CPU资源来解决在资源有限环境中运行大模型的难题，但在高效运行MoE模型方面表现不佳。

Offloading方法的局限性。Offloading（卸载）是在此类环境中运行大模型的一种方法。它们将一部分模型权重存储在CPU内存而非GPU内存中，以利用其更大的容量【索引33, Ying Sheng 等人, High-throughput generative inference of large language models with a single gpu, 2023】。在计算推理时，所需的权重按需从CPU内存传输到GPU内存。对于MoE模型，一些先前的工作尝试通过缓存或预取机制来卸载专家权重【索引13, Artyom Eliseev 和 Denis Mazur, Fast inference of mixture-of-experts language models with offloading, 2023; 索引43, Leyang Xue 等人, Moe-infinity: Activation-aware expert offloading for efficient moe serving, 2024b】。这些方法解决了内存容量的限制，并且适用于以吞吐量为导向的场景。然而，由于PCIe连接的带宽低于内存访问带宽，它们在CPU和GPU之间频繁传输专家权重时会产生显著的延迟开销。因此，对于延迟对用户体验至关重要的应用场景，它们的性能表现并不理想。Fiddler通过利用CPU的计算资源克服了这一挑战。

CPU-based框架的局限性。另一类工作提出了基于CPU的推理框架，这些框架支持通过部分使用GPU来运行LLM【索引17, The ggml authors, llama.cpp, 2023】。根据GPU内存的可用性，这类系统将模型的一部分层在GPU上执行，其余部分在CPU上执行。尽管它们可以减少传输模型参数的开销，但这类方法在一些重要的用例中执行速度不佳，例如长序列预填充（long prefill）或束搜索（beam search），而这些对于提升生成质量至关重要【索引10, Qingxiu Dong 等人, A survey on in-context learning, 2022; 索引40, Patrick von Platen, How to generate text: using different decoding methods for language generation with transformers, 2023】。这是因为它们没有考虑到GPU和CPU不同的批处理效应【索引6, Lequn Chen, Dissecting batching effects in gpt inference, 2023】以及MoE模型的特性。

模型压缩技术的权衡及Fiddler的正交性。尽管模型压缩技术，如量化【索引15, Elias Frantar 和 Dan Alistarh, Qmoe: Practical sub-1-bit compression of trillion-parameter models, 2023; 索引46, Yilong Zhao 等人, Atom: Low-bit quantization for efficient and accurate llm serving, 2023】或稀疏化【索引3, Keivan Alizadeh 等人, Llm in a flash: Efficient large language model inference with limited memory, 2023; 索引38, Jiaming Tang 等人, Quest: Query-aware sparsity for efficient long-context llm inference, 2024; 索引49, Kan Zhu 等人, Tactic: Adaptive sparse attention with clustering and distribution fitting for long-context llms, 2025】，可以减小模型大小并提高推理效率，但它们会降低模型的输出质量，尤其是在试图将大模型适配到内存容量有限的GPU上时【索引13, Artyom Eliseev 和 Denis Mazur, Fast inference of mixture-of-experts language models with offloading, 2023】。最近，【索引36, Yixin Song 等人, Powerinfer: Fast large language model serving with a consumer-grade gpu, 2023】提出利用LLM的稀疏性来加速带CPU卸载的推理。然而，这种方法要求模型使用ReLU（Rectified Linear Units）作为非线性激活函数。将非ReLU模型（这在最先进的LLM中很常见）转换为ReLU模型需要额外的训练，并会导致模型质量下降【索引24, Iman Mirzadeh 等人, Relu strikes back: Exploiting activation sparsity in large language models, 2023; 索引37, SparseLLM, Relullama-70b】。例如，Mixtral-8x7B使用的是SiLU（Sigmoid Linear Units）函数【索引12, Stefan Elfwing 等人, Sigmoid-weighted linear units for neural network function approximation in reinforcement learning, 2018】，只有一小部分值接近于零。因此，很难利用其稀疏性（更详细的讨论见附录B）。Fiddler能够在不修改模型结构或精度的情况下实现更好的性能。我们注意到，Fiddler与压缩技术是正交的，这些优化可以叠加在Fiddler之上。

A2 方法细节

本节阐述Fiddler的设计。Fiddler专为GPU内存容量不足以存储所有MoE模型参数的场景而设计。因此，部分专家的权重被存储在CPU内存而非GPU内存中。Fiddler根据输入的专家选择以及CPU和GPU不同的批处理行为，为此类情况找到最优的执行策略。

3.1 概览

Fiddler的初始化与执行流程。图2展示了Fiddler的概览。在初始化阶段，Fiddler将非专家层（non-expert layers）的参数以及一部分选定专家层的参数分配到GPU内存中，分配数量以GPU内存容量为限。Fiddler根据专家的流行度（popularity）来选择哪些专家放置在GPU内存中，具体方法在§3.4中解释。Fiddler总是将非专家层的权重分配在GPU内存上，因为无论专家如何选择，每个token都会用到它们。非专家层的参数量通常不大（例如，对于Mixtral-8x7B模型，小于20亿参数），本文假设它们能完全放入GPU内存。因容量限制而无法放入GPU内存的专家层参数则存储在CPU内存中。

执行阶段的动态决策。在执行阶段，Fiddler会仔细评估并选择最有效的执行策略。这个决策依据每个专家层接收的输入数量以及CPU和GPU不同的处理延迟。模型的门控层（gating layer）决定了每个专家获得的输入数量，而处理延迟可以通过设备属性来预测。

CPU与GPU的批处理效应差异。Fiddler考虑了CPU和GPU不同的批处理效应。在处理专家层时，输入数量对CPU和GPU的执行延迟影响不同。具体来说，GPU处理表现出在不同输入大小下相对稳定的延迟，这归因于其并行处理能力。这些能力使得执行延迟受限于从内存加载参数所需的时间。相比之下，与CPU处理相关的延迟往往随着输入大小几乎线性扩展。这种线性增长是由于CPU的计算能力弱于GPU，使得延迟受限于计算部分，而非内存移动部分。我们在附录A中给出了更详细的分析。

3.2 执行策略

三种专家层执行场景。在非专家层为每个输入token选定专家后，专家层的处理存在三种场景，如图3所示。

场景a：权重在GPU，GPU执行。如果相应的权重存在于GPU内存中，专家层可以在GPU上执行，无需在CPU和GPU之间进行任何数据传输（图3a）。

场景b：权重在CPU，GPU执行（权重传输）。然而，由于所有模型参数无法完全装入GPU内存，有时专家权重并不在GPU内存中。在这种情况下，存在两种不同的策略来执行专家层。第一种方法是将模型权重从CPU内存复制到GPU内存，然后使用GPU执行专家计算（图3b）。当某些专家权重在GPU内存中缺失时（①），它们会从CPU内存复制到GPU内存（②），然后GPU执行该专家层（③）。现有的卸载系统（offloading systems）使用这种方法。

场景c：权重在CPU，CPU执行（激活值传输）。另一种方法是将激活值（activations）从GPU内存复制到CPU内存，并在CPU上执行专家层（图3c）。在这种方法中，当某些专家权重在GPU内存中缺失时（①），会转而将激活值从GPU内存复制到CPU内存（②），而不是复制权重。然后，专家层的计算在CPU上进行（③），计算完成后，输出的激活值再被复制回GPU（④）。llama.cpp使用了类似的方法。

策略b和c的权衡分析。后面两种策略（上述b和c）存在不同的权衡。一方面，GPU拥有更强的计算能力，适合专家处理。因此，在计算延迟方面，(b)优于(c)。此外，如前所述，由于CPU和GPU的批处理效应不同，(c)的计算延迟会随着输入规模的增长而变长。

通信开销与适用场景。另一方面，考虑到CPU-GPU通信，方法(b)需要传输模型权重，而(c)仅需传输激活值。对于较小的输入规模，激活值的大小（对于Mixtral-8x7B，为输入大小 × 4096）远小于权重大小（对于Mixtral-8x7B，每个专家有3个大小为4096 × 14336的矩阵，使用16位精度时占用超过300MB），因此(c)在减少通信开销方面具有优势。

综合权衡。总的来说，当一个专家的输入规模较小时，(c)更有优势；而当输入规模超过某个阈值时，即使通信开销较大，(b)也更好。在处理长序列预填充（long prefill）时，输入规模可能达到数千。在这种情况下，方法(c)的计算延迟变得比方法(b)的权重传输延迟更难以接受，使得(c)成为一个不切实际的选择。因此，当采用(c)时，激活值的传输延迟可以忽略不计。我们在附录A中给出了更详细的定量分析。

3.3 算法

Fiddler的服务流程。基于上述分析，Fiddler以下述方式服务MoE模型。

初始化。在开始推理过程之前，Fiddler将模型权重分配到CPU和GPU内存中。首先，非专家层的权重被放置在GPU内存中，因为无论专家如何选择，每个token都会使用它们。非专家层的规模通常不大（对于Mixtral-8x7B模型，小于20亿参数），Fiddler假设它们能够装入GPU内存。接下来，Fiddler将一部分专家层放入GPU内存。为此，它会选择内存容量允许的尽可能多的专家，以最大化命中率（hit rate），即专家权重在GPU内存中的概率。对于专家选择，我们应用了§3.4中讨论的优化。我们还会测量在不同输入大小下，在CPU或GPU上复制权重和执行专家的延迟，以便在运行时做出决策。

执行。在运行时，Fiddler确定在GPU和CPU上执行专家层的最优配置。在为每层执行门控函数后，Fiddler知道每个正在处理的token应该使用哪个专家。这使得Fiddler能够获知每个专家的输入大小。需要注意的是，即使对于单个请求，在预填充（prefill）阶段或使用束搜索（beam search）时，也可以同时处理多个输入。

算法1：专家执行策略。基于输入大小信息，Fiddler确定在CPU和GPU之间分配工作负载的最有效执行策略。为此，Fiddler采用算法1。函数is_at_gpu(i, j)检查第i层中专家j的权重是否在初始化时被放置在GPU内存中。此外，cpu_lat(s)和gpu_lat(s)分别提供在输入大小为s的情况下，在CPU和GPU上执行一个专家的预期延迟。函数transfer_lat()估算将一个专家的权重从CPU内存传输到GPU内存所需的延迟。

算法1 专家执行策略

1: 输入:
2: ne: 每层专家数量
3: i: 待处理的层（我们考虑第i层）
4: inp_size: 数组，记录每个专家的输入大小
5: for j = 1 to ne do
6:     s ← inp_size[j]
7:     if s == 0 then
8:         continue
9:     end if
10:    if is_at_gpu(i, j) then
11:        // 在GPU上运行第j个专家
12:    else if cpu_lat(s) > gpu_lat(s) + trans_lat() then
13:        // 在GPU上运行第j个专家
14:    else
15:        // 在CPU上运行第j个专家
16:    end if
17: end for

延迟模型。当在GPU上执行专家并伴随权重传输时，延迟主要由将专家权重从CPU传输到GPU内存的时间决定，这与批大小无关。相比之下，在CPU上执行专家层的行为不同：随着输入token数量的增加，延迟也会增加。然而，将激活值从GPU复制到CPU所需的时间可以忽略不计，占总延迟的不到1%（详见附录A）。为了优化预填充阶段的处理，我们采用一个模型，其中GPU执行时间被视为常数，而CPU执行时间则被假定为随输入token数量线性增加。具体来说，对于输入token数量s，gpu_lat(s)返回一个常数值，而cpu_lat(s)返回一个与s成比例的值乘以另一个常数。这些常数在初始化阶段确定。

3.4 优化

基于专家流行度的放置优化。当输入所需的专家权重已存在于GPU内存中时（即图3a的方法），可以实现最佳的执行性能。为了最大化这种情况的发生频率，我们基于离线分析将频繁使用的专家放置在GPU上。为此，我们按照流行度顺序选择内存容量允许的尽可能多的专家，以最大化命中率，即专家权重在GPU内存中的概率。我们使用校准数据（calibration data）来分析专家选择的配置文件，从而确定热门专家。我们假设这种方法是足够的，因为已知专家选择是基于token的特性，并且专家的流行度在不同的输入域中几乎是普适的【索引19, Albert Q Jiang 等人, Mixtral of experts, 2024; 索引42, Fuzhao Xue 等人, Openmoe: An early effort on open mixture-of-experts language models, 2024a】。附录C更详细地讨论了专家选择。

CPU计算核优化。此外，我们为CPU上的专家处理设计了一个专门的计算核，使用了AVX512_BF16指令集，该指令集在原生的PyTorch实现中不受支持【索引29, Adam Paszke 等人, Pytorch: An imperative style, high-performance deep learning library, 2019, Advances in neural information processing systems】。

A4 实验环境与实验结果

我们评估了Fiddler在资源受限设置下（并发查询少、延迟对用户体验至关重要）进行MoE模型推理的性能。

4.1 实验环境

• 模型与数据：

  • 模型：使用16位精度的Mixtral-8x7B模型【索引19, Albert Q Jiang 等人, Mixtral of experts, 2024】进行评估。该模型架构具有代表性，且所有基线系统都支持，确保了公平比较。
  • 数据集：使用ShareGPT【索引32, ShareGPT, Sharegpt】作为评估和校准数据，这是一个包含人与聊天机器人对话的数据集，用于模拟真实的专家选择行为。实验中随机选取对话子集。附录D中对不同数据集进行了敏感性研究。

• 软件配置：

  • 实现：Fiddler基于PyTorch【索引29, Adam Paszke 等人, Pytorch: An imperative style, high-performance deep learning library, 2019, Advances in neural information processing systems】实现。
  • 基线系统：
    • DeepSpeed-MII v0.2.3【索引23, Microsoft, Deepspeed-mii】：启用ZeRO-Infinity优化【索引30, Samyam Rajbhandari 等人, Zero-infinity: Breaking the gpu memory wall for extreme scale deep learning, 2021】以卸载模型参数，并设置pin_memory以提高性能。
    • Mixtral-Offloading【索引13, Artyom Eliseev 和 Denis Mazur, Fast inference of mixture-of-experts language models with offloading, 2023】：我们对其进行了扩展以支持16位精度的原始模型。offload_per_layer参数在环境1和2中分别设置为7和5以达到最佳性能。
    • llama.cpp b2956【索引17, The ggml authors, llama.cpp, 2023】：控制GPU执行层数的ngl参数在环境1和2中分别设置为8和16。

• 硬件配置：

  • 实验在两个不同的硬件环境中进行，如表1所示。环境1的CPU和GPU配置弱于环境2。两个环境的GPU内存均不足以存储完整的模型参数。

表1：评估设置

4.2 实验结果

我们评估了Fiddler在三个服务单个请求的场景下的性能：a) 不同输入输出长度下的端到端延迟，b) 长上下文输入的预填充（prefill）处理，以及 c) 不同宽度的束搜索（beam search）的端到端延迟。

• 实验一：端到端推理速度 (场景a)
  • 实验内容：测试不同输入长度（[32, 64, 128, 256]）和输出长度（[64, 128, 256, 512]）组合下的推理速度，以每秒生成的token数衡量。
  • 实验结果：如图4所示，在所有配置和环境中，Fiddler的性能平均比表现最好的基线系统llama.cpp快1.26倍。
  • 分析结论：Fiddler的动态执行策略在常规的单批次推理场景中表现出显著优势。

• 实验二：长上下文预填充 (场景b)
  • 实验内容：测试长上下文输入（[512, 1024, 2048, 4096]）的预填充性能，以首个token生成时间（TTFT）衡量。
  • 实验结果：如图5所示，在此场景下，基于卸载的方法（DeepSpeed-MII和Mixtral-Offloading）优于llama.cpp。尽管如此，Fiddler的表现仍优于所有现有方法，平均性能比DeepSpeed-MII高1.07倍，比Mixtral-Offloading高1.65倍。
  • 分析结论：Fiddler能够识别出长序列预填充时的大批量输入，并选择将计算卸载到GPU，从而有效结合了卸载方法的优势。

• 实验三：束搜索推理 (场景c)
  • 实验内容：测试不同搜索宽度（[4, 8, 12, 16]）下的束搜索推理速度，以每秒生成的token数衡量。
  • 实验结果：如图6所示，与llama.cpp相比，Fiddler的平均性能提升了11.57倍。
  • 分析结论：束搜索会产生大量并行计算，Fiddler的动态策略能够有效利用CPU和GPU并行处理这些负载，从而获得巨大性能提升。

总体结论
实验结果表明，Fiddler在广泛的应用场景中均优于现有系统。这些优势主要来源于Fiddler能够根据CPU和GPU的批处理效应动态确定执行策略，并根据流行度配置文件来放置专家。值得注意的是，现有系统表现出不同的权衡（例如，基于卸载的方法在长序列预填充场景中表现出色，而像llama.cpp这样的方法在单批次延迟方面表现良好），而Fiddler系统则整合了两者的优点，在各种条件下都取得了均衡且高效的结果。

A5 结论

本文提出了Fiddler，一个在GPU资源有限的情况下用于MoE模型的高效推理系统。Fiddler通过确定最优的执行策略，策略性地利用了CPU和GPU的异构计算架构。在本地推理的各种常见场景中，Fiddler均实现了比现有最先进系统更优的性能，而这些系统通常只针对部分场景进行了优化。我们的评估表明，与最先进的系统相比，Fiddler在单批次推理中实现了1.26倍的加速，在长序列预填充处理中实现了1.30倍的加速，在束搜索推理中实现了11.57倍的加速。

A6 附录

A 微基准测试

微基准测试分析。本节展示微基准测试的结果。图7显示了以下工作负载的延迟：

• W copy: 将一个专家的权重从CPU内存传输到GPU内存
• A copy: 将一个激活值从GPU内存传输到CPU内存
• GPU N: 在GPU上执行一个专家，输入大小为N（不包括从CPU传输权重的时间）
• CPU N: 在CPU上执行一个专家，输入大小为N

对于每个值，我们执行工作负载32次（Mixtral-8x7B的每一层一次），并给出平均值和标准差结果。

GPU延迟特性。当任务在GPU上执行时，将权重从CPU内存传输到GPU内存的延迟大约是实际计算时间的2-5倍。GPU上的计算延迟在很大程度上与批大小无关，保持恒定。一个例外是在环境1中，当批大小为1时，因为PyTorch对单批次和多批次场景使用不同的实现。然而，与包括权重传输在内的总延迟相比，这种差异很小（约10%）。因此，我们在3.3节中将GPU延迟建模为常数。

CPU延迟特性。在CPU上，执行延迟通常随着输入批大小的增加而线性增长。然而，传输激活值所需的时间可以忽略不计（在单个输入的情况下不到延迟的1%）。由于这种微小的影响，我们在3.3节的模型中假设CPU延迟与输入数量呈线性关系。

B 稀疏性分析

Mixtral-8x7B的稀疏性挑战。本节分析了Mixtral-8x7B模型内的稀疏性，强调了应用先前研究中传统的基于稀疏性的优化技术【索引36, Yixin Song 等人, Powerinfer: Fast large language model serving with a consumer-grade gpu, 2023; 索引3, Keivan Alizadeh 等人, Llm in a flash: Efficient large language model inference with limited memory, 2023】所面临的挑战。这些方法主要针对使用ReLU激活函数的LLM，该函数会将负输入置零，从而允许剪除输出始终为零的通道。这种方法利用了ReLU输出的二元性（零或正值），使得可以直接识别并消除不活跃的通道，从而在不牺牲关键信息的情况下优化计算效率。

SiLU激活函数的影响。相反，最先进的MoE模型通常使用不同的激活函数，这使得直接应用这些利用稀疏性的策略变得复杂。例如，Mixtral-8x7B使用SiLU作为激活函数。与ReLU不同，SiLU没有提供一个明确的零阈值用于剪枝，这需要一种更复杂的方法来利用稀疏性。剪除那些不够接近零的通道可能会对模型的输出质量产生负面影响。

稀疏性数据分析。表2展示了对Mixtral-8x7B模型各层经过SiLU函数后绝对值的分析。该分析基于ShareGPT数据集中的100个样本数据，且未区分同一层中的不同专家。数据显示，接近零的值出现频率普遍较低。具体来说，对于所有层，绝对值低于0.001的通道比例均小于2%，而在32层中有30层的这一比例甚至低于1%。此外，在32层中有28层的小于0.01的值少于5%，在24层中小于0.1的值少于30%。尽管各层之间存在差异，这些结果共同表明，使用先前工作中的方法在该模型中利用稀疏性存在重大挑战。相比之下，据报道【索引20, Zichang Liu 等人, Deja vu: Contextual sparsity for efficient llms at inference time, 2023】，对于OPT模型【索引45, Susan Zhang 等人, Opt: Open pre-trained transformer language models, 2022】的MLP层，超过90%的ReLU函数后的值为零。如何在像Mixtral-8x7B这样的模型中利用稀疏性以在可容忍的质量损失下加速推理，仍然是一个值得未来研究的有趣方向。

表2：Mixtral-8x7B模型所有层经过SiLU函数后绝对值的分布。每个单元格显示其绝对值低于指定阈值的数值百分比。

C 专家流行度

专家选择频率可视化。图8展示了一张热力图，说明了Mixtral-8x7B模型中专家选择的流行度。与附录B中的分析类似，该配置文件是通过在ShareGPT数据集的随机样本上运行推理，并统计路由到每个专家的token数量生成的。每个单元格的颜色强度代表专家被选择的频率，相当于激活该专家的token数量。最受欢迎的专家的值被归一化为1，其他专家的流行度表示为相对于该值的比率。

流行度分布分析。在256个专家中，平均值为0.71，标准差为0.08，第25百分位数为0.67，第75百分位数为0.76。尽管最小值为0.22，但只有15个专家的值低于0.6，有27个专家的值超过0.8，这表明分布相对均衡。

放置策略对命中率的影响。在环境1中，从256个专家中选择56个最受欢迎的专家，可获得的最大预期命中率（专家权重在GPU内存中可用的概率）为25.2%，而最低为18.7%。随机选择的平均命中率为56/256 = 21.9%。在环境2中，GPU内存可容纳125个专家，最佳、最差和随机选择的预期命中率分别为53.0%、44.6%和48.8%。因此，我们可以得出结论，将热门专家放置在GPU上，与随机放置相比，可以将命中率提高约3到5个百分点。

D 数据集敏感性研究

研究动机。本节我们分析了Fiddler性能对输入数据集的敏感性，因为MoE模型的路由行为可能受输入数据分布特征的影响。

实验设置与结果。图9比较了Fiddler在使用ShareGPT【索引32, ShareGPT, Sharegpt】和LMSYS-Chat-1M【索引47, Lianmin Zheng 等人, Lmsys-chat-1m: A large-scale real-world llm conversation dataset, 2024】两个数据集时的性能，这两个数据集都是人与聊天机器人之间的对话数据集。除了数据集不同，实验设置与§4中的场景a相同，并使用环境1。

结论。平均而言，对于ShareGPT数据集，Fiddler的性能比最先进的系统（llama.cpp）快1.81倍；对于LMSYS数据集，则快1.56倍。这些结果表明Fiddler对于不同输入分布具有鲁棒性。

E Fiddler对不同模型的适用性

模型通用性验证。在§4中，我们评估了Mixtral-8x7B模型，因为它是所有基线系统都支持的唯一MoE模型。然而，我们的系统被设计为在MoE模型家族中是模型无关的。为了证明这一点，图10展示了Fiddler在Phi-3.5-MoE模型【索引1, Marah Abdin 等人, Phi-3 technical report: A highly capable language model locally on your phone, 2024】上的性能。我们展示了与DeepSpeed-MII的比较，因为它是唯一支持该模型的基线系统。

结果与结论。结果与Mixtral-8x7B模型一致，Fiddler的平均性能比DeepSpeed-MII高出6.5倍。这表明Fiddler的适用性超出了Mixtral-8x7B模型。

F 延迟分解

延迟细分分析。图4展示了以每秒生成token数衡量的性能，该指标由端到端延迟计算得出。为了补充这些数据，图11和图12分别展示了首个token生成时间（TTFT）和token间延迟（ITL）。

TTFT和ITL性能。在TTFT方面，Fiddler在两个环境中，针对不同输入长度，相较于所有基线系统平均实现了1.13倍的加速。在ITL方面，Fiddler在两个环境中，针对不同输入和输出长度，相较于所有基线系统平均实现了1.43倍的加速。