RK1828 多卡级联：端侧 27B 大模型部署方案解析

多卡级联的技术动因

端侧推理的两项约束

多卡级联的技术路径较为直接：将多张卡的显存与算力聚合，作为单一逻辑加速器统一调度。

模型的可切分性

Transformer 由结构相同的 Decoder 层堆叠而成，层与层首尾相接，各层参数相互独立。由此可得：

• 前若干层的计算完成后，其输出可直接交由持有后续层权重的另一块芯片继续计算
• 无需对原始权重做任何结构性裁剪，切分后重新组合仍为完整的原模型

整体架构与硬件形态

Host 侧承担编排职责：负责分词与词向量映射、设备发现、分段调度以及末段的 Logits 采样；各卡仅执行自身分段的 Decoder 层计算，并以中间特征（Hidden States）形式向下一段传递。

硬件形态与接入方式

RK1828 为 SO-DIMM 形态的 NPU 算力卡，官方提供三种接入方式：

三种方式对性能的影响有限：据瑞芯微官方测试，4K / 8K 输入下 PCIe 相较 USB3.0 在 TTFT 与 Prefill 上约有 2%~3% 的优势，Decode 阶段两者基本持平。

除了 SO-DIMM 形态，RK1828 还有 M.2 Key B-M 版本。

Host 平台支持

• ARM64 平台：RK3588、RK3576 等，支持 Linux 与 Android
• Windows x86 平台
• 复用 RKNN3 Runtime 与应用接口，无需为上层的应用重新适配

配置与模型规模对照

核心原理：层间流水线并行

模型分段方式

分段以 Decoder Layer 为单位连续切分。以 Qwen3.5-9B（32 层）双卡方案为例：

可以看出分段并非均分（19 / 13），而是由 RKNN3-Toolkit 按量化权重与内存占用均衡后确定；末段额外承担 Final Norm 与 LM Head。完整推理链路为：

Host 分词 / 词向量 → 卡 0 前段计算 → 中间特征传递 → 卡 1 后段 + 输出头 → Logits → Host 采样

四卡方案的原理相同，仅增加中间分段数量。

串行执行：数据依赖决定执行顺序

理解该方案的关键在于卡间数据传递机制。分段之间传递的是中间特征（Hidden States）与本段 KV Cache，而第 N+1 段的输入恰为第 N 段的输出——缺少输入即无法计算，因此后一段必须等待前一段完成。

就单个 token 而言，任一时刻仅有一个分段参与计算。 这并非调度策略的选择，而是数据依赖导致的必然结果。该过程可类比为数据流经多级级联滤波链：每一级仅完成自身对应的运算段，输出作为下一级输入，不存在多级同时处理同一样本的情形。

另有两点实现细节需要说明：

• 中间特征当前经 Host 侧传递，卡间直连仍在开发中
• 方案要求 stage_count = 分段数，且可用设备数 ≥ 分段数，否则无法完成一次完整推理

Prefill 流水线：Bucket 拆分与队列化并行

这是该方案在长输入场景下的关键优化，也修正了“prefill 只能纯串行”的直观印象。

实践中，长输入并不会作为一个整体串行流过所有分段，而是按 Bucket 拆分，各分段的执行队列化并行：

即当 Bucket 0 进入分段 1 时，Bucket 1 已可在分段 0 上开始计算。通过这种方式，各分段在长 prompt 场景下得以保持忙碌，Prefill 吞吐显著提升——Qwen3.8-27B 四卡方案的 Prefill 吞吐达 592.1 tokens/s，远高于其 Decode 吞吐的 13 tokens/s。

Decode 阶段则不同：由于每轮仅有一个 token，无法拆分成 bucket，各分段处于“逐个传递、轮流工作”的状态，流水线利用率天然偏低。这也是两阶段吞吐差异达数十倍的根本原因。

与张量并行的对比

端侧选择层间流水线并行，本质上是在卡间带宽受限条件下的工程取舍。

TTFT 与 TPOT：性能指标的成因分析

首 token 延迟（TTFT）的成因

由两个因素叠加导致。

因素一：模型必须先完成全部输入的编码。 Transformer 采用自回归生成方式，首个输出 token 需对全部输入 token 完成 attention 计算后方可预测。而 attention 的每一层都依赖上一层的完整输出，层间构成串行依赖链。

可类比为：查阅一份数千行的文档并作答，须先完整读取文档内容。这段“读取”耗时即对应 prefill 阶段。

因素二：输入编码过程被切分为多站流水，且随输入长度线性增长。 总 prefill 时间 ≈ 各段计算耗时 + 卡间传输耗时之和。因此 TTFT 与输入长度近似成正比（下表为官方测试数据）：

输入长度翻倍，TTFT 亦接近翻倍——说明 Prefill 阶段的时间主要消耗在输入 token 的处理上，而非固定开销。

后续 token 耗时（TPOT）的成因

关键在于 KV Cache。prefill 阶段各卡计算得到的键值缓存均保留在本地显存中，此后每一轮 decode：

• 仅需将单个新 token（上一轮输出）送入流水线，无需重新计算全部输入 token
• 各卡以新 token 与已缓存 KV 进行增量计算
• 仍需经过全部分段，但每段仅处理单个 token 的计算量

单位成本对比

就单个 token 的处理成本而言，prefill 较 decode 低 40 余倍。 这也解释了工程中一项常见优化：相同的长系统提示词在第二次提问时响应明显加快，原因在于 KV Cache 可直接复用，prefill 无需重跑（前缀缓存 / Prompt Cache）。

结论可归纳为：

TTFT 偏高源于“完整输入编码”与“分段串行传递”两项因素的叠加，且随输入长度线性增长；Decode 阶段的单 token 延迟则主要受访存带宽限制。

软件栈：从应用入口到 NPU 的完整链路

第 1 层 · 应用层     浏览器 / OpenAI SDK / OpenCode
        ↓
第 2 层 · API 层     本地 Web UI / OpenAI-compatible API
        ↓
第 3 层 · Server 层  RKLLM3 Server / Agent 编排
        ↓
第 4 层 · Runtime 层 RKNN3 Runtime
        ↓
第 5 层 · 硬件层     RK1828 NPU 算力卡 × N

请求自上而下传递，生成结果沿相反方向以流式 token 返回

性能数据

测试条件：RK3588 Host · RK1828 SO-DIMM · 量化 W4A16 · Output 固定 128 tokens（瑞芯微官方测试）

注：官方测试中，PCIe 接口在 TTFT 与 Prefill 上相较 USB3.0 约有 2%~3% 的优势。

指标定义

数据解读

1. 参数规模翻倍带来吞吐显著下降。 Qwen3.5-9B 双卡 Decode 达 33.19 tokens/s，Qwen3.8-27B 四卡降至 13.02 tokens/s。模型参数量与分段数同时增加，单 token 需经历更多段的串行计算与传递。级联解决的是容量问题，而非吞吐问题。

2. 输入长度是 TTFT 的主导因素。 同为 4 卡配置，输入由 4K 增至 8K，TTFT 从 6.92s 升至 13.67s；而 Decode 吞吐几乎不变（13.02 → 12.74）。这印证了 Prefill 与 Decode 两阶段的瓶颈性质完全不同。

3. 接口差异在 Prefill 可见，在 Decode 不可见。 PCIe 与 USB3.0 的 TTFT 差距稳定在 2%~3%，而 Decode TPS 两者相同（均为 13.02）。原因是 Decode 阶段每轮传输的数据量极小，瓶颈落在权重读取而非链路带宽。

4. Prefill 吞吐随卡数下降，但降幅远小于 Decode。 9B 双卡 853.7 → 27B 四卡 592.1（降约 31%），而 Decode 从 33.19 降至 13.02（降约 61%）。这与 3.3 节的 Bucket 流水机制一致——Prefill 阶段的流水线可以被多个 bucket 填满，而 Decode 阶段无法。

资源占用与系统功耗

除性能指标外，Host 侧资源占用与整机功耗同样是端侧部署的关键约束。

Host 系统开销

测试条件：RK3588 Host · RK1828 SO-DIMM，以 4 核 A76 满载为 100% 基准（瑞芯微官方数据）

Host 侧 CPU 占用率均在 3% 以内，内存占用为百 MB 量级——说明主机几乎不参与实际推理计算，主要承担编排与调度，计算负载已全部下沉至算力卡。

系统功耗

测试条件：RK3588 Host · 4× RK1828 SO-DIMM，整机（含散热风扇）验证（瑞芯微官方数据）

按卡数折算，单卡功耗量级约 15W（平均），与常规端侧算力卡相当。对功耗敏感的设备（电池供电、车载、机器人本体），这一量级需纳入整机功耗预算评估：27B 四卡方案的峰值功耗接近 120W，已超出多数小型移动平台的供电能力。