摘要

端侧推理具有保护隐私、支持离线使用和即时响应等优势，但消费级硬件会限制大语言模型（Large Language Model, LLM）的推理吞吐率与模型能力。为此，我们提出面向消费级家庭集群的分布式端侧推理系统 prima.cpp。该系统可利用混合 CPU/GPU，在 RAM/VRAM 不足、磁盘速度较慢、通过 Wi‑Fi 连接且操作系统各异的设备上运行 30–70B LLM。

概念说明

• 面向消费级家庭集群： 系统专门针对家庭中的普通台式机、笔记本电脑、手机和平板电脑等设备进行设计。这些设备通常通过家庭 Wi‑Fi 连接，硬件与操作系统各不相同，而且内存、显存、磁盘和网络性能均不及数据中心服务器。系统将这些已有设备组织成一个小型本地计算集群，不依赖服务器级硬件或专用加速设备。
• 分布式端侧推理： 大语言模型的同一次推理任务被拆分到多台本地设备上协同完成。例如，不同设备分别计算一部分模型层，再通过 Wi‑Fi 传递中间结果。这并不是让每台设备独立运行一份完整模型，也不是把数据发送到云端，而是让多台用户设备共同完成一次本地推理。

因此，“面向消费级家庭集群的分布式端侧推理系统”是指：利用家庭中已有的多台普通设备，在本地协同运行单台设备难以承载的大语言模型。

prima.cpp 包含两项核心设计：

• 流水线环式并行（Pipelined-Ring Parallelism, PRP）： 将磁盘 I/O 与计算、通信过程重叠，并解决基于 mmap 卸载时出现的预取–释放冲突。
• Halda 异构感知调度器： 在 RAM/VRAM 约束下，联合优化各设备的 CPU/GPU 工作负载分配与设备选择。

在由 4 台消费级家庭设备组成的测试平台上，prima.cpp 取得以下结果：

• 70B 模型： 在内存压力低于 6% 的情况下，每输出令牌时间（Time Per Output Token, TPOT）达到 674 ms/token。
• 32B 模型： 配合推测解码达到 26 tokens/s。
• 相对性能： 与 llama.cpp、exo 和 dllama 相比，TPOT 降低 5–17 倍。

此外，prima.cpp 支持从 8B 到 70B 的细粒度模型规模，具有更广泛的跨操作系统与量化兼容性，并且不会发生内存不足（Out Of Memory, OOM）。该系统还能适应 Wi‑Fi 环境、保护数据隐私，并且不依赖特定硬件。代码见 https://gitee.com/zonghang-li/prima.cpp。

1 引言

具身智能（Embodied AI）是下一代人工智能的代表，对隐私保护、稳定连接和长期财务成本极为敏感（Gupta et al., 2021）。家庭监控、持续监听的助手以及陪伴机器人不能把原始交互发送到云端。云服务还会遭遇频繁的网络故障、排队和超时，其成本随令牌用量及服务时长线性增长。因此，具身智能正在从云端迁移到设备端。

然而，要在端侧运行大模型，仍面临三方面限制：

1. 模型规模受限。 消费级设备的芯片性能有限、RAM 容量较小，通常很难运行 8B 以上的模型（MLC, 2025; Lugaresi et al., 2019; Ghorbani, 2025）；但可靠的长期规划和工具使用往往需要 32B 或更大的模型。
2. 磁盘卸载速度较慢。 磁盘卸载虽然能够提高可运行的模型容量，却会显著降低推理速度（Gerganov, 2025; Li, 2023）。例如，在一台配备 8 GiB 内存的 Mac M1 笔记本上，使用 llama.cpp 运行 Qwen 2.5-14B Q4K 需要 10 s/token。
3. 专用硬件成本较高。 近期工作借助 Jetson、Mac Studio 等专用设备运行更大的模型并提高推理速度（Ye et al., 2024; 2025），但此类设备对多数家庭而言成本过高。

基于上述限制，本文提出以下核心问题：

研究问题： 能否利用用户已有的消费级设备，实现高速的 30–70B 模型推理，同时满足表 1 所概括的具身智能需求？

表 1：云端与本地 LLM 部署对比。TPS1 表示单请求令牌速率，TPS2 表示在 32–70B 模型上测得的 TPS；OA 表示开放访问。

注：

• Local 的两种部署。 Dedicated 指使用专门购买的本地高端设备，成本超过 1000 美元；Consumer 指使用家中已有的消费级设备，因此 Free 表示无需额外购买硬件，并非完全没有电力等运行成本。
• Local 各列。 Privacy 的 ✓ 表示数据留在本地；Speed 是在 32–70B 模型上测得的每秒生成令牌数（TPS）；Queue 的 × 表示无须等待云端排队；Net 的 × 表示不依赖外部互联网，但 prima.cpp 的家庭设备之间仍需通过局域网或 Wi‑Fi 通信。
• Support Model。 OA 表示开放访问（Open-Access），两种本地部署均支持不超过 70B 的开放访问模型。

分布式推理或许是在保持模型原始输出的前提下，同时提高可运行模型规模和推理速度的唯一方案。用户通常拥有多台设备，例如笔记本电脑、台式机、手机和平板电脑。一些笔记本和台式机配有 NVIDIA 20/30/40 系列等低端 GPU，一些 Mac 则配有 Apple Silicon GPU。通过汇聚家庭设备的计算与内存资源，我们可以运行更大的模型。

尽管近期已有进展，仍存在四项局限：

1. 现有系统要求聚合 RAM/VRAM 足以容纳完整模型（Ye et al., 2024; Exo, 2025; Tadych, 2025; Zhang et al., 2025; Lee et al., 2024; Zhao et al., 2023; Zhang et al., 2024），因而抬高硬件成本并限制模型规模。
2. 磁盘卸载会拖慢推理，使 TPOT 达到数十秒（Li et al., 2025）。
3. 层划分依赖第 1 项中的强假设，并忽略不同操作系统内存回收及磁盘访问方面的异构性。
4. 系统假设所有设备都必须参与，尽管移除慢设备反而可能提升速度。

这些局限提出了两个驱动本文设计的问题：Q1： 如何放宽内存约束以运行更大的模型？如果必须使用磁盘卸载，如何隐藏磁盘延迟？Q2： 在解决 Q1 后，如何设计异构感知的层划分方法，并识别瓶颈设备？

针对上述问题，我们提出 prima.cpp，即首个面向消费级家庭集群的分布式推理系统。即使设备混合使用 CPU/GPU，并且存在 RAM/VRAM 不足、磁盘较慢、采用 Wi‑Fi 链路及操作系统异构等限制，该系统仍能以实用速度运行 30–70B 模型。

prima.cpp 分别针对 Q1 和 Q2 提出以下解决方案：

1. 解决内存与磁盘延迟问题（Q1）。 第 3.1 节提出带预取的流水线环式并行，通过重叠磁盘 I/O、计算和通信，隐藏磁盘加载延迟，并解决基于 mmap 卸载时出现的预取–释放冲突。
2. 解决异构调度问题（Q2）。 第 3.2 节对计算、通信、内存、操作系统特定的内存回收及磁盘优化等异构性进行建模；第 3.3 节进一步提出 Halda，用于确定最优层划分并选择性能最佳的设备。

第 4 节在真实家庭集群上的实验得到以下结果：

• 70B 模型： 即使内存有限，仍能在内存压力低于 6% 的情况下达到 674 ms/token。
• 32B 模型： 配合推测解码（Leviathan et al., 2023）达到 26 tokens/s。

这些结果表明，prima.cpp 已具备实用的本地推理速度，并为家庭具身智能应用奠定了基础。

如表 1 所示，prima.cpp 运行在用户已有且无需额外付费的设备上；所有数据均留在本地；没有排队和超时；可离线运行；支持最高 70B 的模型。据我们所知，prima.cpp 是首个无需专用硬件（如 Jetson、NPU）、不改变模型输出，便能在这种受限环境下为 30–70B 模型提供实用性能的端侧系统。

注：

• Jetson。 NVIDIA 推出的嵌入式边缘 AI 计算平台，通常集成 ARM CPU、NVIDIA GPU、内存和配套软件，主要用于机器人及边缘 AI。它是一类完整设备，通常需要用户额外购买。
• NPU。 神经网络处理器（Neural Processing Unit），是针对矩阵、张量及低精度神经网络运算设计的专用加速器，能效较高，但可能受支持算子、模型格式和软件框架限制。
• 二者的区别。 Jetson 是完整的边缘计算平台，NPU 是一种处理器或加速单元。此处“无需专用硬件”表示 prima.cpp 可直接利用家庭已有设备的 CPU、GPU、RAM、VRAM 和磁盘，无须依赖上述专门平台或加速器。

2 相关工作

端侧 LLM 系统。 现有单设备端侧推理方案可以分为以下两类。

1. 面向普通消费级设备的小模型方案。

   • MLC-LLM 与 MediaPipe： MLC-LLM（MLC, 2025）和 MediaPipe（Lugaresi et al., 2019）将 7B 模型部署到手机和浏览器。
   • PocketPal AI： PocketPal AI（Ghorbani, 2025）基于 llama.cpp（Gerganov, 2025）在 Android 设备上运行，最高支持 3.8B 模型。

2. 在单台设备上扩展模型规模的方案。

   • 按需加载： AirLLM（Li, 2023）只加载当前计算所需的模型层，以降低内存占用并支持更大模型，但会因频繁加载权重而降低推理速度。
   • 大容量内存： Apple M2 Ultra 借助 192 GiB RAM 运行 65B 模型；kTransformers（kvcache ai, 2025）依靠 382 GiB RAM 运行 671B 模型，而 70B 模型本身约需 75 GiB 内存。
   • CPU–GPU 协同： HeteGen（Zhao et al., 2024）与 kTransformers 类似，在单台设备上协同使用 CPU 与 GPU，以提高推理速度。

综上，现有单设备方案通常面临三种限制：普通消费级设备只能运行较小模型；按需加载能够扩大模型规模，但会牺牲推理速度；高速大模型推理则往往需要大容量 RAM、先进 CPU 或专用硬件，其配置和成本远超多数家庭能够获得的设备。

分布式端侧 LLM 系统。 这类分布式系统主要遵循两种并行范式：张量并行和流水线并行。

• 张量并行（Tensor Parallelism, TP）。 TP 将单个模型层中的张量切分到多台设备上，以分摊内存占用和计算负载（Shoeybi et al., 2019）。现有工作主要从以下三个方面改进 TP：

  1. 加速集合通信。 TP 需要频繁执行 All-Reduce。dllama（Tadych, 2025）使用 USB4 和 Thunderbolt 5 提供高速设备连接；AirInfer（Zhang et al., 2025）则利用无线模拟叠加，直接在空中完成 All-Reduce。
  2. 适应设备异构性。 Hepti（Lee et al., 2024）针对不同内存预算设计了三种张量切分策略；Galaxy（Ye et al., 2024）先根据设备算力分配负载，再依据内存容量进行调整，以提高速度并避免 OOM。
  3. 放宽聚合内存约束。 多数 TP 系统要求完整模型常驻于所有设备的聚合内存中，因此聚合内存不足时只能运行较小模型。TPI-LLM（Li et al., 2025）改为按需加载模型层，并通过预取隐藏部分磁盘加载延迟，使仅有 4 GiB RAM 的低端设备也能运行 70B 模型；但其速度只有 30 s/token，仍缺乏实用性。

  总体而言，现有 TP 方案要么依赖高速互连和充足的聚合内存，要么通过按需加载扩大模型容量但牺牲推理速度。

注：

• 聚合内存（aggregate memory）。 指参与分布式推理的所有设备可用于存放模型的 RAM 和 VRAM 容量之和。它是从整个集群角度统计的总容量，并不表示这些内存在物理上合并成了一块统一内存；传统 TP/PP 系统通常要求模型的全部分片及必要的运行时数据能够同时放入这一总容量中。除非另有说明，磁盘空间不计入聚合内存。
• VRAM（Video Random Access Memory，显存）。 指 GPU 直接使用的高速内存，推理时主要存放模型权重、KV Cache、中间激活和计算缓冲区。独立显卡通常具有专用 VRAM；采用统一内存架构的设备则由 CPU 和 GPU 共享物理内存。本文用 RAM/VRAM 区分主要由 CPU/GPU 使用的模型存储位置。
• 核心思想。 张量并行拆分的是单个模型层内部的权重矩阵，而不是把不同模型层分给不同设备。对于线性层 $Y=XW$，系统将 $W$ 划分为多个分片，每台设备只保存并计算其中一部分；随后通过集合通信合并局部结果。因此，同一次请求的每个 Transformer 层都需要多台设备共同参与，理想情况下每台设备的权重和计算量约降至原来的 $1/p$，其中 $p$ 为设备数。
• 切分与通信。 按列切分时，各设备计算不同的输出分片，必要时使用 All-Gather 将其拼接；按行切分时，各设备计算对同一输出的局部贡献，必须通过 All-Reduce 求和，并把完整结果返回给所有设备。All-Reduce 既包含“归约汇总”，也包含“向全部设备分发结果”。
• Transformer 中的使用及代价。 常见实现按注意力头切分多头注意力，并对 MLP 的升维层和降维层配对使用列切分与行切分，通常每个 Transformer 层需要约两次 All-Reduce。论文中的 8B 模型包含 32 层，因此需要 64 次 All-Reduce；70B 模型包含 80 层，需要 160 次。频繁同步使 TP 对带宽、延迟和慢设备非常敏感，这也是它在家庭 Wi‑Fi 上容易形成通信瓶颈的原因。

简化执行流程：

                       同一模型层的输入 X
                   ┌────────┼────────┐
                   ↓        ↓        ↓
              D1：分片 W1  D2：分片 W2  …  Dp：分片 Wp
                   ↓        ↓        ↓
                  Z1       Z2       Zp
                   └────────┼────────┘
                    All-Reduce / All-Gather
                             ↓
                       完整或分片输出 Y
                             ↓
                        下一模型层

切分方式	每台设备的局部计算	结果合并方式
按列切分	$Y_i=X{W}_i$，得到不同输出列	拼接；需要完整输出时使用 All-Gather
按行切分	$Z_i=X_i{W}_i$，得到同一输出的局部贡献	求和；通常使用 All-Reduce

• 流水线并行（Pipeline Parallelism, PP）。 PP 按模型层将完整模型划分为多个连续段，并把不同模型段分配给不同设备。相较于需要频繁集合通信的 TP，PP 主要在相邻设备之间传递中间激活，通信次数较少，因此更适合高延迟的家庭 Wi‑Fi 集群。

  PP 的基本执行流程如下：

  1. 划分模型。 系统依据设备的内存、计算能力和网络条件，将模型切分为多个连续的模型段（split the model into segments and assign them to devices based on memory, compute, and network conditions）。
  2. 分段计算。 每台设备只计算分配给自己的模型段。
  3. 传递结果。 当前设备完成计算后，将中间激活发送给下一台设备；该过程依次进行，直到最后一台设备输出下一个令牌。

  现有方法的主要区别在于模型段的划分策略：

  • Exo（2025）： 按设备内存容量的比例分配模型层。
  • LinguaLinked（Zhao et al., 2023）： 使用线性优化（linear optimization）求解模型层与设备之间的分配方案。
  • EdgeShard（Zhang et al., 2024）： 使用动态规划（dynamic programming）确定模型划分与设备分配方案。

表 2：分布式端侧 LLM 系统对比（缩写：Quant. 表示量化，Hete. 表示异构性）。

然而，这些系统要么需要专用硬件（如 Jetson AGX/Nano），要么要求聚合内存足以常驻完整模型；它们只支持 CPU 或 GPU 后端，忽略异构性（尤其是磁盘卸载时的异构性），并带来较高内存压力。表 2 总结了这些系统的特征。这些局限抬高硬件成本、把应用限制在小模型上、造成推理缓慢和设备卡死，也会阻碍用户在家部署 LLM。

注：

• 指代范围。 “这些系统”指表 2 中前述基于 TP 或 PP 的分布式端侧 LLM 系统，包括 dllama、AirInfer、Hepti、Galaxy、TPI-LLM、exo、LinguaLinked 和 EdgeShard，不包括随后作为改进方案介绍的 prima.cpp。以下限制是对这类系统的总体概括，并非每个系统都同时具有全部问题。
• 硬件与内存门槛。 部分系统依赖 Jetson AGX/Nano 等需要额外购买的专用设备；多数系统要求完整模型常驻于所有设备的聚合 RAM/VRAM 中，聚合内存不足时只能缩小模型或面临 OOM。TPI-LLM 虽通过按需磁盘加载放宽了内存约束，但速度仅为 30 s/token。
• 资源协同与异构建模不足。 表中的 CPU/GPU、RAM/VRAM 主要表示支持其中一种后端或存储位置，不等同于 prima.cpp 的 CPU&GPU、RAM&VRAM 联合使用。部分系统虽能感知算力、内存或网络差异，却没有完整建模 CPU/GPU 协同、磁盘吞吐率、mmap 卸载和不同操作系统的内存回收行为。
• 实际影响。 专用硬件会提高部署成本；高内存压力会挤占家庭应用资源，引发频繁换页、OOM、卡顿甚至暂时失去响应；通信或磁盘加载开销则可能显著降低推理速度。因此，这些系统难以在普通家庭设备上同时兼顾模型规模、速度和用户体验。

相较之下，prima.cpp 可在消费级设备上运行，通过磁盘卸载支持更大模型，并使用 PRP 重叠磁盘延迟。它同时运行于 GPU 和 CPU，组合使用 RAM 与 VRAM，并对系统异构性建模，从而优化每台设备内部的 GPU–CPU 层划分。此外，它把模型权重存储在操作系统页缓存中，使操作系统能够按需回收内存，以维持良好用户体验。这些特性使 prima.cpp 有别于现有系统。

3 PRIMA.CPP：在 LLAMA.CPP 中采用流水线环式并行

3.1 带预取的流水线环式并行

当聚合内存充足时，PP 对批量推理很有效；然而家庭环境通常无法满足这一前提。在这类场景中，端侧 LLM 的用户很少、调用频率低，通常一次仅有一个请求（注：本文以单请求为目标，但可通过动态批处理扩展到批量请求，见附录 A.11。），无法使用小批处理，并会留下大量流水线气泡。此外，家庭设备数量少且可用内存有限（注：不能占满全部内存，否则可能干扰 TikTok 等其他应用，并促使用户终止 LLM 服务。），用户很难构建一个能够在内存中容纳完整模型的集群。

注：

• 自回归生成阶段。 LLM 推理通常先通过预填充（prefill）处理完整提示词并建立 KV Cache，再进入自回归解码（decode）：每轮根据当前上下文生成一个新令牌，并将它追加到上下文后继续下一轮。若当前令牌为 $y_t$，只有等它经过全部模型层并产生输出概率后，系统才能选出 $y_{t+1}$；在此之前，$y_{t+1}$ 的内容未知，无法提前开始下一轮。KV Cache 可以避免重复计算历史令牌的部分数据，但每个新令牌仍须经过全部模型层。

• 两类依赖与单请求气泡。 假设设备 A、B、C 分别负责连续的模型层段。同一令牌必须按照 A → B → C 的顺序计算，这是层与层之间的数据依赖；层间依赖本身只是必要的计算顺序，只有当它造成其他 PP 阶段无事可做时，相应的设备空闲时间才称为流水线气泡。对于单个自回归请求，$y_{t+1}$ 又依赖 $y_t$ 的最终输出，因此在 C 完成 $y_t$ 之前，A 不能用 $y_{t+1}$ 填补空闲：

  时段 1：A 处理 y_t；B、C 空闲
  时段 2：B 处理 y_t；A、C 空闲
  时段 3：C 处理 y_t，并生成 y_(t+1)；A、B 空闲
  时段 4：A 才能开始处理 y_(t+1)；B、C 空闲
  

• PP 为何适合批量推理。 PP 把模型的不同层段放在不同设备上，单个请求必须依次经过各设备。存在多个独立请求或微批次时，前一请求进入后续设备后，前面的设备可以立即处理下一请求，使多个流水线阶段同时工作；除流水线填充和排空阶段外，设备利用率通常较高：

  时段 1：A 处理请求 1
  时段 2：A 处理请求 2；B 处理请求 1
  时段 3：A 处理请求 3；B 处理请求 2；C 处理请求 1
  

• 家庭环境的双重限制。 一方面，请求并发度低，无法用小批处理填满流水线；另一方面，设备数量少，而且 RAM/VRAM 还需留给操作系统和其他应用，可供 LLM 使用的聚合内存可能无法让完整模型及其运行时数据同时常驻。换言之，传统 PP 在这里既可能“放不下”完整模型，也可能因流水线“跑不满”而效率较低。

为放宽内存约束，我们以 llama.cpp（Gerganov, 2025）为基础，首先构建了一种使用 mmap 和预取的朴素 PP 扩展。其工作流程如下：

1. 按需加载。 当计算需要某个模型层时，mmap 将该层从外部存储按需载入内存。
2. 内存回收。 出现内存压力时，操作系统可以逐出已载入的模型层，从而降低常驻内存需求，使小内存集群也能运行更大的模型。
3. 提前预取。 为隐藏磁盘加载延迟，设备在计算当前模型段时，提前从磁盘加载下一个模型段。

注：

• mmap（memory mapping，内存映射）。 mmap 将模型文件的一段内容映射到进程的虚拟地址空间，使程序可以像访问普通内存一样访问模型权重，但建立映射时不必立即把整个文件读入 RAM。当程序访问尚未驻留在 RAM 中的映射页时，系统会触发缺页异常，并由操作系统将相应数据从外部存储载入页缓存；出现内存压力时，这些文件页可以被逐出，之后再次访问时再重新加载。这里的缺页异常通常是正常的按需加载机制，而非程序错误。借助这一机制，设备可以运行大于可用物理内存的模型，但频繁磁盘读取仍会增加推理延迟。
• 预取（prefetching）。 预取是指在计算真正访问下一模型段之前，预测其即将被使用并提前将其从磁盘载入内存。例如，设备计算当前模型段时，可以同时预取下一个模型段，从而让磁盘 I/O 与计算或通信重叠。预取不会减少需要读取的数据量，也不会让磁盘本身变快；如果预取能在计算开始前完成，它可以减少计算暴露出来的磁盘等待时间。因此，mmap 负责支持按需映射、加载与回收，预取则把预计会发生的加载提前执行。

这种设计能够以较低内存压力支持更大模型，但推理速度仍然很慢。原因是预取可能发生预取–释放冲突，其过程如下（详见附录 A.1）：

1. 后续层快速载入。 当磁盘读取较快时，预取会在计算到达先前预取的层之前，继续把更靠后的模型层载入页缓存。
2. 先前预取层被逐出。 后加载的层占用有限的页缓存空间，使操作系统逐出先前已经预取、但尚未开始计算的模型层。
3. 计算时重新加载。 等计算真正需要这些层时，它们已不在页缓存中，系统会触发缺页异常并再次从磁盘加载。

因此，预取带来的磁盘延迟隐藏效果被重新加载抵消，流水线气泡仍然显著（见附录 A.2 图 6d、6e）。附录 A.14 的性能分解进一步表明：即使预取已经完成，计算期间仍可能需要重新加载所需的模型权重。

注：

• 容量与性能是两个目标。 mmap 和操作系统回收只让当前所需模型层常驻内存，使大模型能在有限聚合内存中运行；预取则提前读取后续层，以重叠磁盘 I/O 与计算或通信。若预取层在使用前被回收，容量目标仍能实现，但磁盘等待会在计算时再次出现。
• 重载为何形成流水线气泡。 PP 设备访问已被逐出的模型层时，必须暂停计算并等待缺页重载。后续设备因缺少中间输出而停顿；单请求下，前序设备通常也无其他任务。因此，“预取失效 → 计算期重载 → 当前设备停顿 → 其他设备等待”表现为显著的流水线气泡。

带预取的流水线环式并行（PRP）。 为解决预取–释放冲突，我们进一步提出 PRP：将设备首尾相接成环，并通过多轮计算预测一个令牌。每一轮中，不同设备从磁盘预取不同的层段；预取与其他设备正在执行的计算、通信和磁盘加载等操作相重叠。每轮只加载一个小段，其大小称为层窗口大小（layer window size），因此既能避免内存溢出，又能降低预取层被逐出的概率，从而缓解预取–释放冲突（示例见附录 A.2 图 4、图 5）。此外，PRP 在头设备上同时处理输入与输出，可增强交互隐私。

图 1：流水线环式并行。 本例中，6 台设备处理一个 36 层模型。层窗口大小为 2，模型被划分为 18 个段，并按环顺序分配给 6 台设备，因此每台设备需要 3 轮才能预测一个令牌。

图 1 的执行配置。 所有设备的层窗口大小均为 2，即每台设备每轮处理两个模型层。6 台设备每轮共处理 12 层，因此需要 3 轮才能让一个令牌经过全部 36 层。

磁盘速度的影响。 附录 A.2 的图 6a、6b 分别展示了 PRP 在具有快速和慢速磁盘的同构设备上的时间线。快磁盘能在设备轮到计算前完成整个层窗口的预取，因而预取延迟可被完全重叠；慢磁盘只能提前加载一部分，因此 PRP 虽然用预取填补了原来的空闲气泡，计算过程中仍可能因所需层尚未全部载入而触发缺页，并等待剩余模型层，此时 CPU 与磁盘交替工作。

多轮设计的收益。 令 $k$ 表示预测一个令牌所需的轮数。当 $k=1$ 时，PRP 等价于普通 PP；图 2 表明，对大模型增加轮数可使 TPOT 降低约 50%，而对小模型，PRP 会收敛到 PP，二者 TPOT 相近。附录 A.12 给出了完整系统设计。

注：

• PRP 的权衡。 PRP 通过减小层窗口、增加环形通信和执行轮次，缩小单轮内存工作集并减少磁盘重载。对于内存不足的大模型，节省的磁盘 I/O 可能超过新增通信开销，从而降低总延迟；但对于内存充足的小模型或网络较慢的环境，额外通信与调度开销可能抵消收益，因此轮数并非越多越好。

但在实际家庭环境中，设备是异构的。统一的层窗口大小仍会产生流水线气泡（见附录 A.2 图 6c），而为不同设备设置不同窗口大小可以减少气泡（见附录 A.2 图 6f）。一般而言，应向更强的设备分配更大的窗口。然而，判断哪些设备更强、其窗口应有多大并不容易。除常见的计算、通信和内存异构性外，磁盘加载还深受操作系统特定内存回收机制和磁盘读取吞吐率影响。这种复杂异构性使磁盘延迟难以量化。

3.2 层到设备分配问题

如表 2 所述，prima.cpp 被设计为使用多种后端（注：当前原型支持 CUDA、Metal 和 CPU 后端；经过少量适配，也可支持 Vulkan、ROCm 等其他后端。）。在一个层窗口内，一部分层常驻 VRAM 并在 GPU 上执行，其余层卸载到 RAM 并在 CPU 上执行。如果分配给 CPU 的层超出可用 RAM，溢出部分会进一步卸载到外部存储，并通过 mmap 重新载入 RAM（注：本文把模型层固定在 VRAM 中，不像磁盘–RAM 那样分页；否则磁盘–RAM 与 RAM–VRAM 传输会争用 PCIe（或共享）带宽，增加磁盘重载量并放大加载延迟，抵消 GPU 加速收益。）。由此产生两个问题：每台设备的层窗口应如何设置？哪些层在 GPU 上运行，哪些层在 CPU 上运行？

以往工作假设聚合 VRAM 充足，并据此提出以下启发式划分策略：

• Exo（2025）： 按内存比例划分模型层，使 RAM/VRAM 更多的设备承担更多层。
• Ye et al.（2024）： 先按算力划分模型层，再把 OOM 设备上的层迁移到仍有空闲内存的设备。

这些启发式方法在某些测试平台上有效，但不总是最优（见附录 A.10 图 10），因为内存大小不等于算力；在磁盘卸载条件下，内存更大但 CPU/GPU 较弱的设备，甚至可能不如内存较小但 CPU 与磁盘更快的设备。

要得到最优划分，必须建立解析模型来量化 TPOT。建模的困难在于需要同时刻画以下因素：

• 计算与后端异构性。 不同设备的 CPU/GPU 能力不同，模型还需考虑设备内部的 CPU–GPU 协同。
• 内存架构与争用。 部分 PC 使用独立 GPU 和独立 VRAM；Mac M 系列等设备采用 CPU/GPU 共享物理内存的统一内存架构（Unified Memory Architecture, UMA）；论文还将部分无 GPU 设备归入非统一内存访问（Non-Uniform Memory Access, NUMA）情形。
• 操作系统与后端的回收机制。 UMA 设备上的内存回收可能更加激进，不同操作系统的回收阈值也不同；即使在同一设备上，启用与不启用 Metal 时的回收行为仍可能变化。
• 磁盘访问优化。 例如，Linux 会优化顺序磁盘读取，使被逐出的模型层能够更快地重新加载。
• 量化方式。 量化会同时影响计算延迟、内存访问、磁盘加载以及 RAM/VRAM 约束。

这些因素相互影响，并共同决定 TPOT 和最优层划分，因此仅依据内存容量或算力进行划分并不可靠。

注：

• 跨层关系。 从系统设计角度看，prima.cpp 可视为一种跨“模型执行—分布式运行时—操作系统—硬件资源”的协同设计。Halda 把 CPU/GPU 算力、RAM/VRAM 容量、磁盘 I/O、网络延迟与带宽，以及操作系统的内存回收行为纳入同一个性能模型，再用这些底层信息决定上层 LLM 的执行方式：

  底层 CPU/GPU、内存、磁盘、网络和 OS 行为
                      ↓
                 Halda 建模
                      ↓
       决定模型层划分、设备选择和 PRP 轮数
                      ↓
      改变计算、通信、缺页和磁盘 I/O 的关键路径
  

• “跨层”的边界。 这里的跨层是对论文机制的系统级概括，不表示论文修改了 TCP/Wi-Fi 协议、操作系统回收算法或 Transformer 模型结构。更准确地说，它是让上层 ML 运行时感知并适配底层系统与硬件特性的 cross-stack co-design。

经过附录 A.3 的详细性能分析和初步实验，我们把问题形式化为如下层到设备分配（Layer-to-Device Assignment, LDA）问题。

定义 1（层到设备分配，Layer-to-Device Assignment）： 假设有 $M$ 台设备，$w_m$ 是设备 $d_m$ 的层窗口大小，$n_m$ 是 $w_m$ 中的 GPU 层数。决策变量为 ${\mathbf{w}}^{\mathrm{T}}=[w_1,w_2,\dots ,w_M]$ 和 ${\mathbf{n}}^{\mathrm{T}}=[n_1,n_2,\dots ,n_M]$。目标是寻找最优的 $\mathbf{w}$ 与 $\mathbf{n}$，使 TPOT 最小：

$$\underset{\mathbf{w},\mathbf{n}}{\min }L\cdot \frac{{\mathbf{a}}^{\mathrm{T}}\mathbf{w}+{\mathbf{b}}^{\mathrm{T}}\mathbf{n}+{\mathbf{e}}^{\mathrm{T}}\mathbf{c}}{{\mathbf{e}}^{\mathrm{T}}\mathbf{w}}+\kappa ,\text{\hspace{1em}(1)}$$

约束为

$$w_m\in {\mathbb{Z}}_{>0},n_m\in {\mathbb{Z}}_{\ge 0},n_m\le w_m\le L,\text{\hspace{1em}(2)}$$

$$L-k({\mathbf{e}}^{\mathrm{T}}\mathbf{w})=0,k\in {\mathbb{Z}}_{>0},\text{\hspace{1em}(3)}$$

$${\mathbf{P}}_w{\mathbf{w}}^{\prime }+{\mathbf{P}}_n{\mathbf{n}}^{\prime }+({\mathbf{e}}^{\mathrm{T}}\mathbf{w})\mathbf{z}\le 0,\text{\hspace{1em}(4)}$$

$$-{\mathbf{P}}_n^{\mathrm{gpu}}{\mathbf{z}}^{\mathrm{gpu}}({\mathbf{e}}^{\mathrm{T}}\mathbf{w})+{\mathbf{P}}_n^{\mathrm{gpu}}\mathbf{n}\le 0.\text{\hspace{1em}(5)}$$

其中，$L$ 是模型层数；$\mathbf{a}$、$\mathbf{b}$、$\mathbf{c}$ 是由各设备的计算延迟、内存访问延迟、磁盘加载延迟和通信延迟决定的系数向量；$\kappa$ 是常数延迟偏移；$k$ 是预测一个令牌所需的轮数；${\mathbf{w}}^{\prime }$、${\mathbf{n}}^{\prime }$ 是 $\mathbf{w}$、$\mathbf{n}$ 的扩展向量；$\mathbf{z}$、${\mathbf{z}}^{\mathrm{gpu}}$ 是 RAM 与 VRAM 约束向量；${\mathbf{P}}_w$、${\mathbf{P}}_n$、${\mathbf{P}}_n^{\mathrm{gpu}}$ 是用于激活或停用决策变量的对角矩阵；$\mathbf{e}$ 是全 1 向量。约束 (2) 保证层数不越界；约束 (3) 保证所有设备被分配相同数量的窗口，且所有窗口均被填满（注：在实现中这并非强制要求，但可简化问题模型。）；约束 (4)、(5) 保证 RAM 和 VRAM 用量处于限制内。表 6 汇总了主要符号。

为构造 $\mathbf{a},\mathbf{b},\mathbf{c},\kappa ,{\mathbf{w}}^{\prime },{\mathbf{n}}^{\prime },\mathbf{z},{\mathbf{P}}_w,{\mathbf{P}}_n$，我们把设备分为四个集合：

1. ${\mathcal{M}}_1$：未启用 Metal 且 RAM 不足的 macOS 设备；
2. ${\mathcal{M}}_2$：启用 Metal 且 RAM 不足的 macOS 设备；
3. ${\mathcal{M}}_3$：RAM 不足的 Linux 和 Android 设备；
4. ${\mathcal{M}}_4$：RAM 充足或磁盘较慢的设备。

对于应该过载的集合 ${\mathcal{M}}_1$–${\mathcal{M}}_3$，RAM 使用量应保持在可用 RAM 之上；对于不允许过载的集合 ${\mathcal{M}}_4$，RAM 使用量应保持在可用 RAM 之下。其他操作系统可以归入这些集合，也可另建集合并调整变量维度。

该问题是 NP 难的整数线性分式规划（Integer Linear Fractional Program, ILFP）：目标函数分子和分母均为决策变量的线性函数，所有约束都是线性不等式。设备是否过载取决于 $\mathbf{w}$ 和 $\mathbf{n}$；例如，较大的 $w_m-n_m$ 会使 RAM 过载。然而，求解 LDA 前无法确定设备所属集合；没有集合分配，又无法求解 LDA。这形成了循环依赖。