2026/9/20 7:00:28
FEATURED · 精选文章 
在端侧把 27B 甚至 31B 的大模型跑起来听起来很像营销号标题但最近我在 RK1828 这套新一代端侧 SoC 上做本地推理验证时确实把这条路走通了。目标很朴素不依赖服务器、不依赖云让 27B/31B 这一档的开源模型在四块板卡组成的边缘设备上稳定出字。从“装不下”到“能聊天”中间踩的坑比预想多但复盘下来核心就三件事内存容量怎么凑、带宽怎么用、模型怎么切。这篇文章就是一次完整的项目复盘涉及 4 卡级联的架构设计、RK1828 端侧部署的软硬件配置、模型量化方案、性能和功耗实测结果以及大量排查实录。适合正在做端侧 AI 硬件部署的工程师也适合想把手里几块开发板拼成一台“小集群”来跑大模型本地部署的玩家参考。我会直接把计算公式、命令、参数配置和踩坑教训都摆出来不搞虚的。1. 为什么端侧跑 27B/31B 这么难先算清内存和带宽的账很多人拿到板子后的第一反应是“算力不够”其实 27B/31B 这种体量的模型在端侧跑不动的核心原因首先是内存容量其次是内存带宽算力反而是最后才需要担心的问题。1.1 模型到底吃多少内存先做一道简单的乘法大模型占用的内存可以粗略拆成三块权重、KV cache、运行时开销。权重部分直接用乘法定量权重内存 ≈ 参数量 × 每个权重的字节数FP1627B × 2 字节 54GB31B ≈ 62GBINT827B × 1 字节 27GB31B ≈ 31GBQ4 量化27B 大概 14~16GB31B 大概 16~18GB注意这还只是权重。推理时还要给每层保存 KV cache预填充阶段的中间激活值也占内存再加上推理框架本身的 buffer实际占用要比权重文件大一圈。我习惯在做方案时按下面这个表格估算留 30% 的安全余量模型档位量化格式权重估算8K 上下文 KV激活估算单节点总内存估算27BFP1654GB5~7GB62GB27BINT8 / Q827GB5~7GB34GB27BQ4_K_M15GB5~7GB22GB31BQ4_K_M17GB6~8GB25GB所以单卡 16GB 的常规端侧板卡无论怎么优化都装不下一个完整的 27B 模型FP16 更别想。这也是 4 卡级联最直接的动机把内存池化四块 16GB 板卡凑出 64GB 的可用空间Q4 量化后的 27B/31B 模型加上 KV cache 和运行时开销就能从容装下。1.2 带宽决定生成速度一个关键的除法公式模型装下了能不能跑得快要看内存带宽。大模型解码阶段有一个非常基础的经验规律每生成一个 token理论上要把全部权重读一遍。所以生成速度的下界可以这样估算单 token 理论时延 ≈ 权重总字节数 ÷ 内存总带宽举个例子31B 模型 Q4 量化后约 17GB。如果单块 RK1828 板卡的内存带宽在 50GB/s 左右那么每生成一个 token 的纯读取时间就是 17GB ÷ 50GB/s ≈ 0.34 秒折算下来大概只有 3 token/s。这个速度用于对话体验很勉强。4 卡级联的意义之一就是把这四套内存带宽并起来用。在多路并发场景下总带宽可以按四倍估算Q4 权重的 17GB 读取时间就变成 17GB ÷ 200GB/s ≈ 0.085 秒理论上限能拉到 10 token/s 以上。当然这是理想值实际还要扣除通信开销、流水线气泡和系统调度损耗后面我会给真实的参考范围。1.3 算力其实不是瓶颈别把劲使错地方很多人一听到“跑大模型”就先堆 NPU 算力这是方向性错误。单看解码阶段一个 token 需要的乘法运算量大约等于 2 × 参数量31B 模型也就是 620 亿次运算。RK1828 这类端侧 SoC 的 NPU 算力普遍在几十 TOPS四卡合计超过百 TOPS处理这 620 亿次运算只需要几毫秒。所以结论很清楚解码阶段被内存带宽卡住预填充阶段被算力卡住而级联方案的真正收益是“把多个节点的内存和带宽拼在一起”而不是简单地把 TOPS 加起来。我见过不少人一上来就在调 NPU 算子结果速度纹丝不动最后发现内存带宽根本没吃满非常浪费精力。2. 4 卡级联架构设计模型怎么切卡之间怎么传级联不是把四块卡堆在一起就完事最关键的是模型切分方式。切得不好四块卡的利用率可能还不如一块卡。下面把三种常见方案对比完你就知道为什么最终选了“层切 流水线”。2.1 三种模型切分方案全量复制、张量并行、流水线并行方案模型分布方式单 token 通信量对互联要求端侧可落地性全量复制每块卡放一份完整模型几乎为 0低模型装不下直接排除张量并行每层矩阵按维度切开多头多头分到各卡每层前向都要同步通信量极大需要 NVLink 级别的超高速互联端侧普通 PCIe 扛不住流水线并行按层切成 4 段每块卡跑若干连续层每 token 只传一次激活值普通 PCIe 3.0 x4 就够端侧级联主力方案27B/31B 模型的 hidden_size 大概在 4096~5120 这个区间一个 token 的中间激活值只有 20~30KB通过 PCIe 3.0 x4 传输耗时可以忽略不计。相比之下张量并行每一层都需要做 all-reduce 同步通信量随模型宽度放大好几个数量级在边缘设备上极其不划算。2.2 级联的通信拓扑一张接力图“级联”这个词很容易让人想到一条串行链实际工程上也确实接近接力跑四块板卡通过 PCIe 交换芯片组成一个小型互连网络模型按层分成 4 段Card 0Embedding 第 1~N/4 层Card 1第 N/41~N/2 层Card 2第 N/21~3N/4 层Card 3第 3N/41~N 层 输出层每个 token 的前向计算依次经过 Card 0 → Card 1 → Card 2 → Card 3每块卡只负责自己那段层处理完把激活值传给下一块。KV cache 也按层分摊到各块卡上长上下文场景不会出现某块卡内存爆掉、其他卡空闲的尴尬。需要特别说明的是这种接力结构对单用户、单请求来说并不会让单 token 延迟变成原来的四分之一。道理很简单接力跑不会让总路程变短只是让每个人少背装备。通道上仍然要读完所有层的权重所以单流延迟和单卡全量读取差不多。级联的真正优势是“装得下”以及多路并发时总吞吐可以成倍提升。2.3 用微批和多路并发把流水线气泡填掉流水线并行有个经典问题叫“流水线气泡”单条请求在 Card 0 算的时候Card 1/2/3 都在闲着。解决方式是在软件层引入微批micro-batch或并发请求让多个请求错开进入流水线。比如请求 A 进入 Card 0 时请求 B 提前在 Card 1 等待请求 A 到 Card 1 时请求 B 已经被推到 Card 2请求 C 进入 Card 0。这样四块卡都能持续干活总吞吐才会接近“四倍带宽”的理论值。在我们实际的 RK1828 级联验证里单路并发时只有 3~5 token/s一旦开 4 路并发总吞吐能到 14 token/s 上下差距非常大。所以软件配置里“允许几路并发”不是可有可无的参数而是级联架构能不能发挥价值的分水岭。3. RK1828 端侧落地的硬件组网与软件栈配置架构想清楚之后落地就是硬功夫了。RK1828 的量产模组规格会随固件批次有差异我这里按照工程验证板的常见配置来写单模组 16GB LPDDR5配备 PCIe 接口和独立散热结构。实际部署时请以板卡厂商提供的规格书为准。3.1 四卡硬件组网清单不只是插四块板把四块模组拼成一整台设备每一步都比单卡复杂一个量级载板至少需要一个带 PCIe 交换芯片的载板把四块模组的 PCIe 通道收敛到主机侧。别用网线串联的方案做推理数据面延迟和带宽都不够。供电先算总功耗。单块 RK1828 满载大约 15~25W四块加交换芯片和保护电路峰值往 100W 算。电源至少要留 30% 余量12V 10A 是一个比较安全的下限。电源纹波大是通信随机卡死的常见原因之一。存储模型权重文件 15~18GB放在 eMMC 上冷启动要读很久。我建议至少在第一块卡上挂一块 NVMe SSD把模型文件和量化校准数据都放进去冷启动时间能从 80 秒压到 15 秒以内。散热四块 SoC 挤在一块板卡上热功耗密度比单卡高很多。猜猜导致性能波动最大的因素是什么不是模型切分是温度。RK1828 一旦触发高温降频性能会掉 30%~50%而且斜率非常陡。必须上主动风冷或者用热管把热量导到大面积散热片上。提示级联系统第一次上电时先不要急着装软件。用电流表确认各卡功耗正常再用工具扫一遍 PCIe 链路是否全部协商到预期速率。链路降级是后期各种怪问题的温床排查成本极高。3.2 软件栈选型llama.cpp 优先专属工具链兜底RK1828 这类端侧 SoC 的软件栈通常有两条路一条是通用 CPU/GPU 推理路径一条是厂商 NPU 的离线编译路径。我的建议是先用通用路径把模型跑起来验证架构和网络再考虑把热点算子迁移到 NPU。第一步先用 llama.cpp 做多卡层切。它的命令行参数对多设备切分支持得比较直接以下是参考启动方式./llama-server \ -m /models/qwen2.5-27b-q4_k_m.gguf \ --ctx-size 8192 \ --split-mode layer \ --main-gpu 0 \ --parallel 4 \ --port 8080这里的--split-mode layer表示按层切分--parallel 4是关键它控制并发槽位。如果你发现生成的并发请求数上不去多半是这个参数没调。要说明的是如果 RK1828 的 NPU 没有暴露成 llama.cpp 支持的设备后端那这一步实际是走 CPU 或者随芯片提供的通用加速库但切分思路完全一致。第二步如果一定要走厂商 NPU 工具链做法是把每一段模型分别离线编译成子图然后在主机侧写一个调度器把上一段的输出藏给下一段。伪代码思路如下stages [node0:9000, node1:9001, node2:9002, node3:9003] def inference(hidden_states): hidden_states tp_call(stages[0], hidden_states) # embedding 第1段 hidden_states tp_call(stages[1], hidden_states) # 第2段 hidden_states tp_call(stages[2], hidden_states) # 第3段 logits tp_call(stages[3], hidden_states) # 第4段 输出层 return logits这个调度器要注意做异步发送上一段算完就把数据丢给下一段不要同步等待结果否则通信延迟全部叠加到关键路径上。3.3 量化方案Q4_K_M 是端侧性价比之王27B/31B 模型要塞进 64GB 级联内存量化是必须走的。我对比过 GGUF 的 Q4_K_M、Q5_K_M 和 AWQ/GPTQ 离线量化。在 RK1828 这类边缘设备上最推荐 GGUF Q4_K_M兼容性好、加载快、不需要额外的校准过程模型质量也够用。如果你追求效果建议用 imatrix 工具重新做一次量化校准而不是直接用网上下载的通用量化文件。校准过程很简单# 先用一批真实语料生成重要性矩阵 llama-imatrix \ -m /models/model-f16.gguf \ -f /data/calibration.txt \ -o /models/imatrix.dat # 再用这个矩阵做 Q4_K_M 量化 llama-quantize \ --imatrix /models/imatrix.dat \ /models/model-f16.gguf \ /models/model-q4_k_m.gguf \ Q4_K_M校准集不用太大几百篇覆盖业务场景的文本即可。我踩过一次坑随便拿维基百科做校准量化后模型写代码时经常答非所问。换成代码和技术文档混排后效果立刻正常。4. 跑起来之后性能实测与关键参数调优模型能出字只是第一步能不能好用要看性能。部署大模型时性能指标要拆成预填充和解码两段看混为一谈会得出完全错误的结论。4.1 预填充看首 token 延迟解码看生成速率预填充阶段把用户的整段 prompt 一次性算完属于计算密集型解码阶段逐 token 输出属于带宽密集型。所以首 token 时间TTFT主要看 NPU/CPU 算力和预填充并行度后续 token 速度TPOT主要看内存带宽和流水线气泡是否被填满。在级联架构里如果预填充只压在 Card 0 上首 token 会非常慢。正确做法是把预填充的批次拆成多个微批让四块卡都参与计算最后再把完整激活值按层顺序拼接起来。这个优化能把 1024 token 输入的 TTFT 从 8 秒压到 4 秒左右。4.2 参考性能数据一个可以复用的数量级以下数据来自我们在同类规格设备上的工程验证RK1828 具体批次和内存频率不同会有波动但数量级可以作为方案设计的起点配置单路解码速度4 路并发总吞吐1024 token 输入 TTFT27B Q4_K_M 4×16GB3~5 token/s12~16 token/s3~5s31B Q4_K_M 4×16GB2~4 token/s10~14 token/s4~6s27B Q4_K_M 4×16GB 张量并行混合5~8 token/s15~20 token/s2~4s从这张表能看出纯粹层切级联的单路速度并不惊艳但并发吞吐是能用的。如果业务要求单用户延迟也必须快可以考虑混合方案段内张量并行、段间流水线并行。代价是通信复杂度和互联带宽要求直线上升普通 PCIe 3.0 不一定扛得住我建议先评估业务是否需要不要一上来就上混合。4.3 调参优先级先看内存再看并发最后才调算子在 RK1828 级联上我整理了一套调参顺序按优先级排确认 KV cache 空间足够。上下文长度设太大预填充时直接 OOM 或换成 CPU 慢速路径这是最常见的性能杀手。调并发槽位。--parallel或你自己调度器里的微批数至少要等于 4才能把流水线气泡填掉。开 KV cache 量化。llama.cpp 里可以设--cache-type-k q8_0 --cache-type-v q8_0内存能省 30%~40%对 31B 这类大模型尤其重要。最后才去抠算子。没有前两步调算子对整体时延的改善非常有限。性能验证可以用llama-bench做基准也可以用 OpenAI 兼容接口直接 curl 实测curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {model:local,messages:[{role:user,content:写一段快速排序代码}],max_tokens:256} \ -w \n总耗时: %{time_total}s\n5. 级联部署踩坑记录问题排查与避坑技巧这部分是我最想写的因为级联部署的坑和单卡完全不在一个维度。很多问题不是模型代码的问题而是系统和架构的问题。5.1 我踩过的三个大坑第一个坑是“级联后速度反而更慢”。第一版跑起来后单路速度居然只有 1.5 token/s比单卡还慢。排查了很久才发现是并发槽位没开四块卡上只有一块在干活其他三块全在等数据。把并发路数提到 4 之后速度立刻翻了几倍。记住流水线并行必须配套微批和并发否则就是花钱买了三块摆设。第二个坑是“OOM 总是发生在预填充阶段而不是加载阶段”。模型加载明明很顺利一旦发长 prompt 就报内存不足。原因是 KV cache 在预填充时才按上下文长度分配上下文设置太激进或者没有开 KV cache 量化。我把默认 32K 上下文改回 8K再打开 Q8_0 KV cache问题消失。第三个坑是“第二块卡内存占用异常高第一块卡却吃不满”。这是因为默认的层分配逻辑把大部分非重复层都放在主卡上导致负载不均匀。需要在配置里手动指定权重映射比如按四块卡内存比例 1:1:1:1 或者 3:2:2:1 来做人工分配。对于 RK1828 这类内存完全相同的板卡建议直接用均匀分配避免某块卡成为瓶颈。5.2 常见问题速查表现象可能原因处理办法首 token 非常慢预填充算子没有上 NPU检查算子映射表不支持 NPU 的层留在 CPU/通用后端生成速度低且不稳定流水线气泡严重增加并发槽位开启异步 stage 通信报 OOM上下文太长或 KV cache 未量化缩短 ctx-size开启 Q8_0 类型 KV cache某块卡内存占用异常层分配不均衡手动指定各卡权重比例速度忽快忽慢温度触发降频改善散热限制满载持续时间通信超时或卡死PCIe 链路降级或电源纹波过大检查链路协商速度增加电源余量模型输出乱码或重复量化校准集质量差用业务语料重新生成 imatrix 并量化冷启动读取权重太长模型放在 eMMC 上迁移到 NVMe SSD5.3 排障工具与方法先把指标暴露出来级联系统最怕黑盒。我的习惯是先把四个关键指标全部可视化每块卡的内存占用、每块卡的 NPU/CPU 利用率、每块卡的 stage 耗时、PCIe 链路速度。用htop看 CPU 负载分布判断是否有卡在傻等用厂商提供的 devfreq 节点或 debugfs 看 NPU 频率确认是否降频用lspci -vvv检查 PCIe 链路协商是否低于预期这是通信性能劣化的第一大元凶在调度器里给每个 stage 打毫秒级时间戳哪一段慢了直接看数字定位比靠猜靠谱得多。我还习惯在跑长任务时同步读一下整机功耗如果功耗远低于预期大概率有卡在空转功耗持续顶着上限那大概率是发热降频的前兆。最后分享一点个人体会端侧跑 27B/31B 大模型最大的心路转变是接受“单用户速度不会有本质提升”这个现实。4 卡级联带给你的是容量和并发吞吐不是魔改单路延迟。我建议所有想复现这个方案的人先不要直接上四卡而是用两卡把流水线验证跑通再把并发路数打开确认收益明显后再扩展到四卡。这样能省掉大量排查时间。另外有一个非常实用的小技巧设备刚上电时先把 PCIe 链路速度和内存频率记下来存档。遇到性能不对的时候第一步查链路是否降级第二步查温度第三步才去怀疑模型切分。绝大多数“玄学问题”最后都落在电源、散热和通信这三件事上。先把这三件事盯住你的级联部署就已经赢了一半。
端侧多卡级联跑27B/31B大模型：内存、带宽与模型切分实战
在端侧把 27B 甚至 31B 的大模型跑起来听起来很像营销号标题但最近我在 RK1828 这套新一代端侧 SoC 上做本地推理验证时确实把这条路走通了。目标很朴素不依赖服务器、不依赖云让 27B/31B 这一档的开源模型在四块板卡组成的边缘设备上稳定出字。从“装不下”到“能聊天”中间踩的坑比预想多但复盘下来核心就三件事内存容量怎么凑、带宽怎么用、模型怎么切。这篇文章就是一次完整的项目复盘涉及 4 卡级联的架构设计、RK1828 端侧部署的软硬件配置、模型量化方案、性能和功耗实测结果以及大量排查实录。适合正在做端侧 AI 硬件部署的工程师也适合想把手里几块开发板拼成一台“小集群”来跑大模型本地部署的玩家参考。我会直接把计算公式、命令、参数配置和踩坑教训都摆出来不搞虚的。1. 为什么端侧跑 27B/31B 这么难先算清内存和带宽的账很多人拿到板子后的第一反应是“算力不够”其实 27B/31B 这种体量的模型在端侧跑不动的核心原因首先是内存容量其次是内存带宽算力反而是最后才需要担心的问题。1.1 模型到底吃多少内存先做一道简单的乘法大模型占用的内存可以粗略拆成三块权重、KV cache、运行时开销。权重部分直接用乘法定量权重内存 ≈ 参数量 × 每个权重的字节数FP1627B × 2 字节 54GB31B ≈ 62GBINT827B × 1 字节 27GB31B ≈ 31GBQ4 量化27B 大概 14~16GB31B 大概 16~18GB注意这还只是权重。推理时还要给每层保存 KV cache预填充阶段的中间激活值也占内存再加上推理框架本身的 buffer实际占用要比权重文件大一圈。我习惯在做方案时按下面这个表格估算留 30% 的安全余量模型档位量化格式权重估算8K 上下文 KV激活估算单节点总内存估算27BFP1654GB5~7GB62GB27BINT8 / Q827GB5~7GB34GB27BQ4_K_M15GB5~7GB22GB31BQ4_K_M17GB6~8GB25GB所以单卡 16GB 的常规端侧板卡无论怎么优化都装不下一个完整的 27B 模型FP16 更别想。这也是 4 卡级联最直接的动机把内存池化四块 16GB 板卡凑出 64GB 的可用空间Q4 量化后的 27B/31B 模型加上 KV cache 和运行时开销就能从容装下。1.2 带宽决定生成速度一个关键的除法公式模型装下了能不能跑得快要看内存带宽。大模型解码阶段有一个非常基础的经验规律每生成一个 token理论上要把全部权重读一遍。所以生成速度的下界可以这样估算单 token 理论时延 ≈ 权重总字节数 ÷ 内存总带宽举个例子31B 模型 Q4 量化后约 17GB。如果单块 RK1828 板卡的内存带宽在 50GB/s 左右那么每生成一个 token 的纯读取时间就是 17GB ÷ 50GB/s ≈ 0.34 秒折算下来大概只有 3 token/s。这个速度用于对话体验很勉强。4 卡级联的意义之一就是把这四套内存带宽并起来用。在多路并发场景下总带宽可以按四倍估算Q4 权重的 17GB 读取时间就变成 17GB ÷ 200GB/s ≈ 0.085 秒理论上限能拉到 10 token/s 以上。当然这是理想值实际还要扣除通信开销、流水线气泡和系统调度损耗后面我会给真实的参考范围。1.3 算力其实不是瓶颈别把劲使错地方很多人一听到“跑大模型”就先堆 NPU 算力这是方向性错误。单看解码阶段一个 token 需要的乘法运算量大约等于 2 × 参数量31B 模型也就是 620 亿次运算。RK1828 这类端侧 SoC 的 NPU 算力普遍在几十 TOPS四卡合计超过百 TOPS处理这 620 亿次运算只需要几毫秒。所以结论很清楚解码阶段被内存带宽卡住预填充阶段被算力卡住而级联方案的真正收益是“把多个节点的内存和带宽拼在一起”而不是简单地把 TOPS 加起来。我见过不少人一上来就在调 NPU 算子结果速度纹丝不动最后发现内存带宽根本没吃满非常浪费精力。2. 4 卡级联架构设计模型怎么切卡之间怎么传级联不是把四块卡堆在一起就完事最关键的是模型切分方式。切得不好四块卡的利用率可能还不如一块卡。下面把三种常见方案对比完你就知道为什么最终选了“层切 流水线”。2.1 三种模型切分方案全量复制、张量并行、流水线并行方案模型分布方式单 token 通信量对互联要求端侧可落地性全量复制每块卡放一份完整模型几乎为 0低模型装不下直接排除张量并行每层矩阵按维度切开多头多头分到各卡每层前向都要同步通信量极大需要 NVLink 级别的超高速互联端侧普通 PCIe 扛不住流水线并行按层切成 4 段每块卡跑若干连续层每 token 只传一次激活值普通 PCIe 3.0 x4 就够端侧级联主力方案27B/31B 模型的 hidden_size 大概在 4096~5120 这个区间一个 token 的中间激活值只有 20~30KB通过 PCIe 3.0 x4 传输耗时可以忽略不计。相比之下张量并行每一层都需要做 all-reduce 同步通信量随模型宽度放大好几个数量级在边缘设备上极其不划算。2.2 级联的通信拓扑一张接力图“级联”这个词很容易让人想到一条串行链实际工程上也确实接近接力跑四块板卡通过 PCIe 交换芯片组成一个小型互连网络模型按层分成 4 段Card 0Embedding 第 1~N/4 层Card 1第 N/41~N/2 层Card 2第 N/21~3N/4 层Card 3第 3N/41~N 层 输出层每个 token 的前向计算依次经过 Card 0 → Card 1 → Card 2 → Card 3每块卡只负责自己那段层处理完把激活值传给下一块。KV cache 也按层分摊到各块卡上长上下文场景不会出现某块卡内存爆掉、其他卡空闲的尴尬。需要特别说明的是这种接力结构对单用户、单请求来说并不会让单 token 延迟变成原来的四分之一。道理很简单接力跑不会让总路程变短只是让每个人少背装备。通道上仍然要读完所有层的权重所以单流延迟和单卡全量读取差不多。级联的真正优势是“装得下”以及多路并发时总吞吐可以成倍提升。2.3 用微批和多路并发把流水线气泡填掉流水线并行有个经典问题叫“流水线气泡”单条请求在 Card 0 算的时候Card 1/2/3 都在闲着。解决方式是在软件层引入微批micro-batch或并发请求让多个请求错开进入流水线。比如请求 A 进入 Card 0 时请求 B 提前在 Card 1 等待请求 A 到 Card 1 时请求 B 已经被推到 Card 2请求 C 进入 Card 0。这样四块卡都能持续干活总吞吐才会接近“四倍带宽”的理论值。在我们实际的 RK1828 级联验证里单路并发时只有 3~5 token/s一旦开 4 路并发总吞吐能到 14 token/s 上下差距非常大。所以软件配置里“允许几路并发”不是可有可无的参数而是级联架构能不能发挥价值的分水岭。3. RK1828 端侧落地的硬件组网与软件栈配置架构想清楚之后落地就是硬功夫了。RK1828 的量产模组规格会随固件批次有差异我这里按照工程验证板的常见配置来写单模组 16GB LPDDR5配备 PCIe 接口和独立散热结构。实际部署时请以板卡厂商提供的规格书为准。3.1 四卡硬件组网清单不只是插四块板把四块模组拼成一整台设备每一步都比单卡复杂一个量级载板至少需要一个带 PCIe 交换芯片的载板把四块模组的 PCIe 通道收敛到主机侧。别用网线串联的方案做推理数据面延迟和带宽都不够。供电先算总功耗。单块 RK1828 满载大约 15~25W四块加交换芯片和保护电路峰值往 100W 算。电源至少要留 30% 余量12V 10A 是一个比较安全的下限。电源纹波大是通信随机卡死的常见原因之一。存储模型权重文件 15~18GB放在 eMMC 上冷启动要读很久。我建议至少在第一块卡上挂一块 NVMe SSD把模型文件和量化校准数据都放进去冷启动时间能从 80 秒压到 15 秒以内。散热四块 SoC 挤在一块板卡上热功耗密度比单卡高很多。猜猜导致性能波动最大的因素是什么不是模型切分是温度。RK1828 一旦触发高温降频性能会掉 30%~50%而且斜率非常陡。必须上主动风冷或者用热管把热量导到大面积散热片上。提示级联系统第一次上电时先不要急着装软件。用电流表确认各卡功耗正常再用工具扫一遍 PCIe 链路是否全部协商到预期速率。链路降级是后期各种怪问题的温床排查成本极高。3.2 软件栈选型llama.cpp 优先专属工具链兜底RK1828 这类端侧 SoC 的软件栈通常有两条路一条是通用 CPU/GPU 推理路径一条是厂商 NPU 的离线编译路径。我的建议是先用通用路径把模型跑起来验证架构和网络再考虑把热点算子迁移到 NPU。第一步先用 llama.cpp 做多卡层切。它的命令行参数对多设备切分支持得比较直接以下是参考启动方式./llama-server \ -m /models/qwen2.5-27b-q4_k_m.gguf \ --ctx-size 8192 \ --split-mode layer \ --main-gpu 0 \ --parallel 4 \ --port 8080这里的--split-mode layer表示按层切分--parallel 4是关键它控制并发槽位。如果你发现生成的并发请求数上不去多半是这个参数没调。要说明的是如果 RK1828 的 NPU 没有暴露成 llama.cpp 支持的设备后端那这一步实际是走 CPU 或者随芯片提供的通用加速库但切分思路完全一致。第二步如果一定要走厂商 NPU 工具链做法是把每一段模型分别离线编译成子图然后在主机侧写一个调度器把上一段的输出藏给下一段。伪代码思路如下stages [node0:9000, node1:9001, node2:9002, node3:9003] def inference(hidden_states): hidden_states tp_call(stages[0], hidden_states) # embedding 第1段 hidden_states tp_call(stages[1], hidden_states) # 第2段 hidden_states tp_call(stages[2], hidden_states) # 第3段 logits tp_call(stages[3], hidden_states) # 第4段 输出层 return logits这个调度器要注意做异步发送上一段算完就把数据丢给下一段不要同步等待结果否则通信延迟全部叠加到关键路径上。3.3 量化方案Q4_K_M 是端侧性价比之王27B/31B 模型要塞进 64GB 级联内存量化是必须走的。我对比过 GGUF 的 Q4_K_M、Q5_K_M 和 AWQ/GPTQ 离线量化。在 RK1828 这类边缘设备上最推荐 GGUF Q4_K_M兼容性好、加载快、不需要额外的校准过程模型质量也够用。如果你追求效果建议用 imatrix 工具重新做一次量化校准而不是直接用网上下载的通用量化文件。校准过程很简单# 先用一批真实语料生成重要性矩阵 llama-imatrix \ -m /models/model-f16.gguf \ -f /data/calibration.txt \ -o /models/imatrix.dat # 再用这个矩阵做 Q4_K_M 量化 llama-quantize \ --imatrix /models/imatrix.dat \ /models/model-f16.gguf \ /models/model-q4_k_m.gguf \ Q4_K_M校准集不用太大几百篇覆盖业务场景的文本即可。我踩过一次坑随便拿维基百科做校准量化后模型写代码时经常答非所问。换成代码和技术文档混排后效果立刻正常。4. 跑起来之后性能实测与关键参数调优模型能出字只是第一步能不能好用要看性能。部署大模型时性能指标要拆成预填充和解码两段看混为一谈会得出完全错误的结论。4.1 预填充看首 token 延迟解码看生成速率预填充阶段把用户的整段 prompt 一次性算完属于计算密集型解码阶段逐 token 输出属于带宽密集型。所以首 token 时间TTFT主要看 NPU/CPU 算力和预填充并行度后续 token 速度TPOT主要看内存带宽和流水线气泡是否被填满。在级联架构里如果预填充只压在 Card 0 上首 token 会非常慢。正确做法是把预填充的批次拆成多个微批让四块卡都参与计算最后再把完整激活值按层顺序拼接起来。这个优化能把 1024 token 输入的 TTFT 从 8 秒压到 4 秒左右。4.2 参考性能数据一个可以复用的数量级以下数据来自我们在同类规格设备上的工程验证RK1828 具体批次和内存频率不同会有波动但数量级可以作为方案设计的起点配置单路解码速度4 路并发总吞吐1024 token 输入 TTFT27B Q4_K_M 4×16GB3~5 token/s12~16 token/s3~5s31B Q4_K_M 4×16GB2~4 token/s10~14 token/s4~6s27B Q4_K_M 4×16GB 张量并行混合5~8 token/s15~20 token/s2~4s从这张表能看出纯粹层切级联的单路速度并不惊艳但并发吞吐是能用的。如果业务要求单用户延迟也必须快可以考虑混合方案段内张量并行、段间流水线并行。代价是通信复杂度和互联带宽要求直线上升普通 PCIe 3.0 不一定扛得住我建议先评估业务是否需要不要一上来就上混合。4.3 调参优先级先看内存再看并发最后才调算子在 RK1828 级联上我整理了一套调参顺序按优先级排确认 KV cache 空间足够。上下文长度设太大预填充时直接 OOM 或换成 CPU 慢速路径这是最常见的性能杀手。调并发槽位。--parallel或你自己调度器里的微批数至少要等于 4才能把流水线气泡填掉。开 KV cache 量化。llama.cpp 里可以设--cache-type-k q8_0 --cache-type-v q8_0内存能省 30%~40%对 31B 这类大模型尤其重要。最后才去抠算子。没有前两步调算子对整体时延的改善非常有限。性能验证可以用llama-bench做基准也可以用 OpenAI 兼容接口直接 curl 实测curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {model:local,messages:[{role:user,content:写一段快速排序代码}],max_tokens:256} \ -w \n总耗时: %{time_total}s\n5. 级联部署踩坑记录问题排查与避坑技巧这部分是我最想写的因为级联部署的坑和单卡完全不在一个维度。很多问题不是模型代码的问题而是系统和架构的问题。5.1 我踩过的三个大坑第一个坑是“级联后速度反而更慢”。第一版跑起来后单路速度居然只有 1.5 token/s比单卡还慢。排查了很久才发现是并发槽位没开四块卡上只有一块在干活其他三块全在等数据。把并发路数提到 4 之后速度立刻翻了几倍。记住流水线并行必须配套微批和并发否则就是花钱买了三块摆设。第二个坑是“OOM 总是发生在预填充阶段而不是加载阶段”。模型加载明明很顺利一旦发长 prompt 就报内存不足。原因是 KV cache 在预填充时才按上下文长度分配上下文设置太激进或者没有开 KV cache 量化。我把默认 32K 上下文改回 8K再打开 Q8_0 KV cache问题消失。第三个坑是“第二块卡内存占用异常高第一块卡却吃不满”。这是因为默认的层分配逻辑把大部分非重复层都放在主卡上导致负载不均匀。需要在配置里手动指定权重映射比如按四块卡内存比例 1:1:1:1 或者 3:2:2:1 来做人工分配。对于 RK1828 这类内存完全相同的板卡建议直接用均匀分配避免某块卡成为瓶颈。5.2 常见问题速查表现象可能原因处理办法首 token 非常慢预填充算子没有上 NPU检查算子映射表不支持 NPU 的层留在 CPU/通用后端生成速度低且不稳定流水线气泡严重增加并发槽位开启异步 stage 通信报 OOM上下文太长或 KV cache 未量化缩短 ctx-size开启 Q8_0 类型 KV cache某块卡内存占用异常层分配不均衡手动指定各卡权重比例速度忽快忽慢温度触发降频改善散热限制满载持续时间通信超时或卡死PCIe 链路降级或电源纹波过大检查链路协商速度增加电源余量模型输出乱码或重复量化校准集质量差用业务语料重新生成 imatrix 并量化冷启动读取权重太长模型放在 eMMC 上迁移到 NVMe SSD5.3 排障工具与方法先把指标暴露出来级联系统最怕黑盒。我的习惯是先把四个关键指标全部可视化每块卡的内存占用、每块卡的 NPU/CPU 利用率、每块卡的 stage 耗时、PCIe 链路速度。用htop看 CPU 负载分布判断是否有卡在傻等用厂商提供的 devfreq 节点或 debugfs 看 NPU 频率确认是否降频用lspci -vvv检查 PCIe 链路协商是否低于预期这是通信性能劣化的第一大元凶在调度器里给每个 stage 打毫秒级时间戳哪一段慢了直接看数字定位比靠猜靠谱得多。我还习惯在跑长任务时同步读一下整机功耗如果功耗远低于预期大概率有卡在空转功耗持续顶着上限那大概率是发热降频的前兆。最后分享一点个人体会端侧跑 27B/31B 大模型最大的心路转变是接受“单用户速度不会有本质提升”这个现实。4 卡级联带给你的是容量和并发吞吐不是魔改单路延迟。我建议所有想复现这个方案的人先不要直接上四卡而是用两卡把流水线验证跑通再把并发路数打开确认收益明显后再扩展到四卡。这样能省掉大量排查时间。另外有一个非常实用的小技巧设备刚上电时先把 PCIe 链路速度和内存频率记下来存档。遇到性能不对的时候第一步查链路是否降级第二步查温度第三步才去怀疑模型切分。绝大多数“玄学问题”最后都落在电源、散热和通信这三件事上。先把这三件事盯住你的级联部署就已经赢了一半。 
