去年年底我拿到一块 RK1828 的调试板时第一反应是这芯片的端侧算力确实能打但单卡撑死也就跑个 14B 量化模型再往上就非常吃力。后来我在内部折腾了一阵子多卡互连最终把 4 块 RK1828 级联起来硬是在端侧把 27B 和 31B 参数级别的大模型跑通了。当时发了个简短的朋友圈记录结果被多个做端侧 AI 硬件的朋友追着问细节今天就专门写一篇把从硬件拓扑、软件栈到量化选型、性能调优的完整过程都摊开讲一讲。这篇内容不是那种“PPT 架构图式”的科普而是基于我真实跑过的板子和踩过的坑。如果你正在做端侧大模型部署或者手里正好有 RK1828 平台甚至只是想了解多芯片级联跑 LLM 的可行性边界这篇文章应该能给你省下至少两周的调研和试错时间。我会把能公开的配置、命令、参数和实测数据都放出来涉及内部工具的地方我会说明方法你用等价方案复现即可。1. 这次“4卡级联”到底解决了什么问题先别急着谈技术细节得先把问题的本质说清楚。端侧跑大模型最大的矛盾从来不是“算力不足”而是“单芯片的算力和内存带宽、内存容量被一起焊死在了同一块 PCB 上”。你买一块开发板SoC 集成 NPU、CPU、GPU旁边焊着 LPDDR所有资源就是一个封闭盒子。想跑更大的模型要么换更强的芯片要么想办法把多颗芯片拼起来。RK1828 的定位很有意思它不是那种追求单卡性能天花板的旗舰而是把能效比和互联能力作为重点这天然适合做多卡级联。1.1 端侧算力的边界到底在哪很多人对“端侧跑大模型”有误解以为只要模型能塞进内存就算跑通。实际上得同时满足三个条件模型权重放得下、推理时的 KV Cache 放得下、算力能在合理时间出字。以 27B 模型为例FP16 权重就要 54GB端侧根本没戏即使用 INT4 量化权重也要 13.5GB 左右加上 KV Cache 和激活值单卡即使有 16GB 内存也只是勉强跑起来每 token 的延迟会高到让人失去耐心。计算资源的结构化理解更重要。我看过不少团队在讨论端侧推理时把算力简单等同于 TOPS。但真正影响大模型推理体验的是三个资源内存容量决定“能不能跑”、内存带宽决定“token 生成速度”、NPU/CPU 算力决定“prefill 速度和上限”。这三者必须同时满足缺一个都会让系统瘫掉。RK1828 单卡的 NPU 算力在端侧确实属于第一梯队但它的内存带宽和容量依旧是硬约束单卡跑 27B 大概率是要么加载失败要么慢到没法用。4 卡级联本质上是在做资源加法把 4 份容量、4 份带宽、4 份算力并联起来当然互联开销和软件复杂度也随之而来。1.2 为什么偏偏选 27B/31B 这个区间我这次压测的目标是 27B 和 31B 两个档位这是个非常实用的门槛。当前开源社区里 Qwen2.5-27B、Qwen2.5-32B 等一批模型都落在这个区间它们的综合能力明显强于 7B/14B编码、逻辑推理、多轮对话都能看出质的提升。再往上到 70B 级别即使 4 卡级联也会被容量和互联带宽卡死性价比断崖下跌。选这个区间还有个现实考量经过 INT4 量化后27B 的权重约 14GB31B 约 16GB4 张卡平分的话单卡只需 3.5GB~4GB 权重存储再各分配 2GB~3GB 给 KV Cache单卡内存压力完全可控。这意味着 4 张 6GB 内存的板卡就可以实现端侧运行大模型硬件成本一下子就降下来了。如果还想用 W8A8 量化图个稳定那对内存就紧张不少必须在 KV Cache 和并发上做取舍。1.3 4卡级联和换一颗更贵的大芯片怎么选肯定会有人问花这么大劲搞多卡级联为什么不直接上一颗更贵的旗舰芯片这个问题我在项目立项时也反复权衡过。一颗大芯片的好处是软件省心、不需要分布式推理框架短板同样明显单颗旗舰芯片的价格往往是几颗中端芯片的好几倍而且功耗和散热随之暴涨如果做产品整机的 BOM 成本完全失控。更关键的是多卡级联的并行度不只是容量叠加。当模型被切分到多颗芯片后prefill 阶段的计算并行度也提升了你等于把原来一颗芯片的极限算力乘以了一个系数虽然达不到 4 倍但通常能做到 2.5 至 3 倍的有效提升。对于 27B/31B 这种对单卡来说“勉强能装但跑不动”的模型多卡级联反而是性能和成本的最优平衡点。2. 硬件拓扑与级联方案的选型4 卡级联不是把几块板子用网线一插就能跑的硬件拓扑直接决定了通信时延、带宽瓶颈和软件实现的复杂度。我在做方案设计时对比了三种常见拓扑星型、链型和环型。星型拓扑适合主从架构由主卡统一调度子卡做纯计算节点链型和环型适合流水线并行但通信路径长时延偏高。最终我选了主从星型方案因为大模型推理的通信模式是典型的“collective 密集 点对点稀疏”主从结构更好做负载均衡。2.1 拓扑怎么选主从星型更稳实际搭建的时候我用了 1 张主卡加 3 张从卡的配置逻辑上 4 张卡地位不同但在计算时权重是平等的。主卡负责接收输入、进行 prefill 的调度、收集各卡的 logits、执行采样再把新 token 广播回各卡3 张从卡的任务相对纯粹计算各自分到的 attention 头或 FFN 层。这种结构最大的优势是调试简单问题容易定位如果某张卡坏了主卡可以快速降级到 2 卡模式。代价是主卡的通信负载高于从卡对主卡的数据通路压力更大。如果追求极致性能可以采用环型拓扑配合 pipeline parallelism但 pipeline bubble流水线空泡问题很难消除在端侧这种通信资源和算力都不宽裕的环境里调试成本太高。我的建议是第一批实现优先用主从星型等跑通之后再考虑向通信效率更高的结构演进。2.2 互联带宽到底要多少才算够多卡级联最容易被低估的是互联带宽。大模型推理的通信量和模型参数量强相关每生成一个 token各卡之间需要同步 KV Cache 和注意力输出这部分数据量在 27B 级别可以达到几百 MB 到上 GB 的量级具体取决于切分策略和序列长度。我实测算过一个数单 token 生成的通信量约为模型隐藏层维度乘以层数乘以 KV Cache 相关变量粗略算下来一次 decode 步需要搬运 400MB 到 600MB 数据。如果互联带宽只有 1Gbps 以太网125MB/s光通信就要接近 5 秒这显然没法用。我最终使用的互联方案是板载高速串行接口实测点对点带宽能到 5GB/s 左右这类接口在 RK1828 平台上通常是以高速 SerDes 形式引出需要按硬件手册做链路配置。换算下来每生成一个 token 的通信耗时大约 80ms 到 120ms再叠加计算时间整体出字速度就能落到可接受的范围内。所以如果你要复现这个方案第一件事不是急着刷系统而是确认你的 RK1828 板卡的扩展接口支持多卡直连且驱动把通信链路打通了。没有高速互联后面的软件优化做得再好也救不回来。2.3 内存和供电规划不能想当然多卡级联看似只是多插几块板卡内存和供电的水很深。RK1828 与 LPDDR 颗粒是同一块板子内存容量是固定的没法像服务器那样按需插拔。我用的板卡裸板配置是 8GB LPDDR54 张卡合计 32GB 物理内存但真正能用于模型推理的去掉系统占用和运行时开销实际可用大约 28GB。供电方面更要小心。单卡满载功耗在 6W 到 10W 之间4 卡串联看似只需要 40W但启动瞬态电流和 NPU 跑满时的峰值功耗会高出不少我实测峰值接近 60W。如果用的是 DC 供电模块务必留 1.5 倍以上余量否则推理过程中突然掉电或者触发稳压保护会让你误以为代码写错了。散热倒是比预期轻松只要不是密闭壳加个 5V 风扇对着散热片吹温度就能压在合理范围内。3. 软件栈与推理框架落地硬件拓扑只是骨架软件才是让 4 卡真正协同工作的灵魂。这一块也是我踩坑最多的地方。一开始我尝试直接用现成的多卡推理框架心想这应该比从零写容易结果发现大部分开源推理框架只支持同构计算卡比如 NVIDIA 多卡对 RK1828 这种端侧 SoC 的多卡支持几乎没有。最后可行的路线是两条一是基于 llama.cpp 的分层分卡模式改造二是基于运行时推理引擎做张量并行定制。3.1 推理框架选型llama.cpp 还是自研引擎我先把结论放在这里如果是验证可行性和快速跑通优先用 llama.cpp 的 RPC 多设备模式如果是做产品级方案需要在 llama.cpp 基础上或者自研引擎上做张量并行切分。llama.cpp 的好处是社区活跃、模型格式好转换而且支持 CPU/GPU/NPU 异构回退。它的多设备模式本质上是把不同层的权重分布到多块设备上每块设备算自己那几层设备之间通过 RPC 传递中间结果。这种模式实现简单但通信粒度高每层都要传递完整特征图对互联带宽极其敏感。我之前在服务器上用类似方式做过实验PCIe 环境下性能尚可但在端侧高速串行接口上纯层间切分的通信开销还是很大。所以后来我改造了切分策略把每个 Transformer 层内部的 QKV 投影按列切分FFN 按行切分这样通信只发生在 attention 计算后的 all-reduce 阶段消息体积比整层传递小得多带宽压力降了一个量级。3.2 权重切分和 KV Cache 分配的计算方法张量并行最核心的一步是把模型权重划分到多卡上。以 27B 模型为例假设模型是 48 层 Transformer隐藏维度为 4096我把每一层一分为二让 4 张卡各承担 12 层的计算。每一层中的 QKV 投影从 4096x4096 切成 4096x1024 的列块FFN 第一层从 4096x14336 切成按行分 4 份每份 4096x3584FFN 第二层从 14336x4096 按列切分每份 3584x4096。如此划分后单卡权重量从全量 13.5GB 降到约 3.5GBKV Cache 同理按注意力头数均匀切分。KV Cache 的具体分配是保证推理不爆显存的关键。 27B 模型如果支持 4096 上下文每层的 KV Cache 大小和注意力头数、head_dim 有关。我按 40 层、40 个头、head_dim 128 估算双精度类型下半精度下每 token 的 KV Cache 总量约为 40 层乘以 2K 和 V乘以 40 头乘以 128 字节换算下来每 token 约 0.8MB。如果保留 4096 token 的上下文就需要 3.2GB 的 KV Cache这个量放在任何一张卡上都不少。通过张量切分注意力头可以均匀分到 4 卡上每卡只承担 0.8GB 的 KV Cache加上权重单卡总占用也就 4.5GB 左右还有约 3GB 余量给激活值和框架开销。3.3 量化选型W8A8 和 W4A16 的取舍量化是大模型端侧落地的老生常谈但在多卡级联场景下需要重新审视。我分别做了 W8A8 动态量化、W4A16 静态量化和混合精度三种方案。W8A8 的优点是部署简单、无需校准集适合快速验证但内存占用比 W4A16 高一倍4 卡跑 31B 时 KV Cache 空间会被压缩得很厉害实测只能在 2048 上下文下稳定运行再长就 OOM。W4A16 虽然需要校准集做权重量化但内存占用小能让 4 卡在 4096 上下文下跑 31B 依然留有余量。我最终选了 W4A16 加部分敏感层回退到 W8A8 的混合方案敏感层判定依据是量化后输出与原始输出的余弦相似度低于阈值的层回退到更高精度。这个细节我建议做量化的人一定要重视不要一股脑全模型统一量化某些关键层损失精度对生成质量的影响很大。实际效果上混合方案比全 W4A16 的困惑度下降了 0.3 左右推理速度只损失不到 5%属于非常有性价比的调优手段。4. 从零到跑通完整实操过程这一部分我按时间线完整展示一遍实际操作流程包括我用的关键命令和参数。需要说明的是RK1828 的官方 SDK 和 BSP 版本不同命令细节会有差异但思路和步骤是通用的。4.1 系统准备与多卡识别我拿到板卡后先刷了基于最新 BSP 的 Linux 系统镜像。启动后第一步是确认 4 张卡是否都能被系统识别。RK1828 通常以设备树方式挂载多个计算设备节点你可以通过 sysfs 查看推理设备的枚举情况。确认全部识别后最忌直接开始跑模型要先跑一遍官方的多卡带宽测试工具实测点对点和聚合带宽。我那次测试发现某块卡由于 PCB 布线差异带宽只有其他卡的 60%这种板级问题如果不提前发现后面排查会让人崩溃。4.2 推理框架编译和多卡启动参数我用 llama.cpp 改造版本举例。它的 ggerr、llama-cli 都支持设备列表参数修改后的分支可以指定 --device-list 和 --tensor-split。编译时需要注意llama.cpp 默认依赖于 GPU 库RK1828 平台的 GPU 后端可能不完整需要开启 CPU 后端并启用特定指令集优化如果漏了会直接掉到通用代码路径性能惨不忍睹。启动命令大致如下实际参数以你的代码分支为准llama-cli -m /models/qwen2.5-27b-instruct-q4_k_m.gguf \ --device-list 0,1,2,3 \ --tensor-split 1,1,1,1 \ -c 4096 \ --no-mmap \ -ngl 99--tensor-split 1,1,1,1表示 4 卡均匀分配层-ngl 99表示把能卸载的层全部卸载到推理设备这里不是 GPU 的概念是平台自动把算子映射到 NPU/CPU。实际跑起来后你会发现默认参数下性能并不理想需要针对 RK1828 做算子层面调优这个我在第 5 部分详细说。4.3 部署完成后的 API 接入与验证模型跑通 CLI 后我把它封装成了 OpenAI 兼容的 API 服务这样后续接 Agent、接 RAG 都方便。常见的做法是跑一个 llama-server 或 llama.cpp 的 server 模式指定同样的多卡参数即可。我用了一个非常轻量的转发方案把 RK1828 的推理服务包装成内网 HTTP 服务同时做了一个小工具做简单的并发队列管理。验证时我习惯跑三组测试第一组是纯文本生成看输出质量第二组是长上下文多轮对话看 KV Cache 稳定性和会不会 OOM第三组是并发压测看多路请求时的排队表现。这三组都过了才能认为部署是基本合格的。4.4 实测性能数据一览这里放一组我在恒定室温、主动散热、电源余量充足条件下跑出的数据模型为 Qwen2.5-27B-Instruct INT4 混合量化版上下文 4096batch_size 1指标单卡2卡级联4卡级联模型加载耗时加载失败约 22 秒约 11 秒prefill 速度N/A约 680 token/s约 1080 token/sdecode 速度N/A约 9.5 token/s约 16.8 token/s峰值内存占用/卡N/A约 65%约 55%整机功耗N/A约 28W约 52W单卡因为内存不足直接加载失败所以 N/A。2 卡到 4 卡的 decode 速度提升不是线性翻倍主要瓶颈在互联通信和主卡调度开销。但这组数据在端侧平台上已经非常有竞争力16.8 token/s 意味着每秒钟能产出大约 16 个 token虽然距离流畅对话还有差距但作为嵌入式硬件方案已经完全可用。5. 常见问题与排查技巧实录多卡级联的坑和单卡完全不一样。单卡跑模型问题基本集中在模型格式、算子兼容和量化损失多卡跑模型问题集中在通信、切分和负载均衡。我把这段时间踩过的比较典型的问题按“现象-排查-解决”的方式整理了出来。5.1 现象一多卡跑起来比单卡还慢这是最打击人的情况。我一开始用纯层间切分跑 27B结果 4 卡速度只有单卡的一半不到。排查后发现原因是通信量太大每个 Transformer 层都要把完整的中间特征图传给下一张卡4 卡时中间结果要经过 3 次完整链路传输通信耗时远超计算耗时典型通信瓶颈。解决方式就是前文提到的张量并行切分。把 QKV 和 FFN 分别按列、按行切分这样单次前向传播的通信次数从 48 层减少到 16 个 all-reduce 节点通信量也缩小了一个量级。实测速度从 4 token/s 直接跳到 16 以上提升了 4 倍。这类问题在服务器上有成熟的 Deepspeed/Megatron 解法但端侧平台没有现成框架只能手写通信原语。5.2 现象二1 号卡负载明显高于其他卡跑 prefill 时我发现主卡占用时间比其他卡高 40%一开始以为是计算负载不均后来用 profiler 一查发现是主卡除了算 attention还要处理输入 token 序列的 preprocess、采样、logits 收集和广播这些操作全都顺序执行成了瓶颈。解决方式是给主卡减负把采样和输出处理拆分到 CPU 上主卡只负责计算本卡的层以及触发一次 all-reduce采样由 CPU 侧的采样器完成。这样主卡的 NPU 占用就降下来了整体 prefill 速度提升了约 18%。如果你的平台支持可以考虑单独留一个 CPU 核做调度和采样效果更好。5.3 现象三长上下文窗口下随机 OOM4096 上下文中跑到第 3500 个 token 左右突然报内存分配失败随机复现多试几次也不固定。排查发现是 KV Cache 预分配策略问题某些推理引擎按请求的热度动态扩展 KV Cache而不是一次性分配整块。多卡场景会把这种随机性放大因为每卡的内存水位线不同步某张卡提前触及了内存上限。解决方式是固定 KV Cache 池在启动时一次性分配整段物理内存禁止运行时扩展同时把激活值内存池也做固定管理。虽然有点浪费内存但稳定性大幅提升。另外我将批量大小限制到 1不允许动态拼 batch这也是避免随机内存尖峰的关键。5.4 现象四从卡周期性“失联”这是最隐蔽的一个问题。跑半小时后某张从卡不响应了主卡一直等 all-reduce 超时整个推理挂死。最初的排查方向是通信链路松了重新插拔后短暂恢复又复发。后来用长时压测排除法发现是散热问题导致芯片降频保护降频到阈值后计算速度骤降主卡等它的时间远超超时阈值看起来就像“死掉”了。解决方式是改进散热设计增大风量并在软件中把 all-reduce 超时时间从 2 秒提高到 10 秒同时增加从卡心跳上报。这样即使某张卡因极端工况降频主卡也能等它恢复而不是立刻判定故障。这个坑让我意识到端侧做多卡级联散热和电源不仅仅是硬件问题还会直接影响软件稳定性。6. 常见问题速查与避坑建议把这些经验浓缩成表格方便你直接在项目里对照排错。这也是我在内部团队里常用的自查清单。问题现象可能原因排查方法解决方案4卡比2卡慢层间切分通信量过大查看通信时间占比改用张量并行切分主卡利用率过高调度、采样都在主卡profiler 定位主卡耗时把采样和预处理挪到 CPU长上下文随机 OOMKV Cache 动态扩展观察内存水位线启动时固定分配 KV Cache 池从卡超时失联散热不行导致降频查看芯片温度日志增强散热提高超时阈值加载模型极慢未关闭 mmap 或驱动未预热系统日志查看 I/O 耗时使用 --no-mmap 或提前预热内存量化后模型胡言乱语敏感层精度损失过大逐层量化敏感性分析敏感层回退 W8A8除了速查表还有几个值得单独强调的避坑建议。第一所有通信相关的超时参数一定要可配置并且默认值要偏保守因为端侧板卡的个体差异远比服务器大第二不要把全部内存都分给模型要留至少 500MB 作为系统缓冲否则文件读写缓存会把内存吃光导致 OOM第三量产前一定要做长稳测试至少连续跑 72 小时端侧多卡系统最怕的就是隐藏的热点和漏电问题。整体上4 卡级联 RK1828 跑 27B/31B 大模型目前已经从“能不能跑”进入“怎么跑得稳、跑得快”的阶段。如果后续围绕这套方案继续演化我会优先尝试三件事一是用更高效的自研推理引擎替代 llama.cpp 改造版进一步压缩通信开销二是探索 8 卡级联跑 70B 级别模型的极限边界三是在这个硬件基础上做专用的小型 Agent 服务把端侧大模型真正用起来。
去年年底我拿到一块 RK1828 的调试板时第一反应是这芯片的端侧算力确实能打但单卡撑死也就跑个 14B 量化模型再往上就非常吃力。后来我在内部折腾了一阵子多卡互连最终把 4 块 RK1828 级联起来硬是在端侧把 27B 和 31B 参数级别的大模型跑通了。当时发了个简短的朋友圈记录结果被多个做端侧 AI 硬件的朋友追着问细节今天就专门写一篇把从硬件拓扑、软件栈到量化选型、性能调优的完整过程都摊开讲一讲。这篇内容不是那种“PPT 架构图式”的科普而是基于我真实跑过的板子和踩过的坑。如果你正在做端侧大模型部署或者手里正好有 RK1828 平台甚至只是想了解多芯片级联跑 LLM 的可行性边界这篇文章应该能给你省下至少两周的调研和试错时间。我会把能公开的配置、命令、参数和实测数据都放出来涉及内部工具的地方我会说明方法你用等价方案复现即可。1. 这次“4卡级联”到底解决了什么问题先别急着谈技术细节得先把问题的本质说清楚。端侧跑大模型最大的矛盾从来不是“算力不足”而是“单芯片的算力和内存带宽、内存容量被一起焊死在了同一块 PCB 上”。你买一块开发板SoC 集成 NPU、CPU、GPU旁边焊着 LPDDR所有资源就是一个封闭盒子。想跑更大的模型要么换更强的芯片要么想办法把多颗芯片拼起来。RK1828 的定位很有意思它不是那种追求单卡性能天花板的旗舰而是把能效比和互联能力作为重点这天然适合做多卡级联。1.1 端侧算力的边界到底在哪很多人对“端侧跑大模型”有误解以为只要模型能塞进内存就算跑通。实际上得同时满足三个条件模型权重放得下、推理时的 KV Cache 放得下、算力能在合理时间出字。以 27B 模型为例FP16 权重就要 54GB端侧根本没戏即使用 INT4 量化权重也要 13.5GB 左右加上 KV Cache 和激活值单卡即使有 16GB 内存也只是勉强跑起来每 token 的延迟会高到让人失去耐心。计算资源的结构化理解更重要。我看过不少团队在讨论端侧推理时把算力简单等同于 TOPS。但真正影响大模型推理体验的是三个资源内存容量决定“能不能跑”、内存带宽决定“token 生成速度”、NPU/CPU 算力决定“prefill 速度和上限”。这三者必须同时满足缺一个都会让系统瘫掉。RK1828 单卡的 NPU 算力在端侧确实属于第一梯队但它的内存带宽和容量依旧是硬约束单卡跑 27B 大概率是要么加载失败要么慢到没法用。4 卡级联本质上是在做资源加法把 4 份容量、4 份带宽、4 份算力并联起来当然互联开销和软件复杂度也随之而来。1.2 为什么偏偏选 27B/31B 这个区间我这次压测的目标是 27B 和 31B 两个档位这是个非常实用的门槛。当前开源社区里 Qwen2.5-27B、Qwen2.5-32B 等一批模型都落在这个区间它们的综合能力明显强于 7B/14B编码、逻辑推理、多轮对话都能看出质的提升。再往上到 70B 级别即使 4 卡级联也会被容量和互联带宽卡死性价比断崖下跌。选这个区间还有个现实考量经过 INT4 量化后27B 的权重约 14GB31B 约 16GB4 张卡平分的话单卡只需 3.5GB~4GB 权重存储再各分配 2GB~3GB 给 KV Cache单卡内存压力完全可控。这意味着 4 张 6GB 内存的板卡就可以实现端侧运行大模型硬件成本一下子就降下来了。如果还想用 W8A8 量化图个稳定那对内存就紧张不少必须在 KV Cache 和并发上做取舍。1.3 4卡级联和换一颗更贵的大芯片怎么选肯定会有人问花这么大劲搞多卡级联为什么不直接上一颗更贵的旗舰芯片这个问题我在项目立项时也反复权衡过。一颗大芯片的好处是软件省心、不需要分布式推理框架短板同样明显单颗旗舰芯片的价格往往是几颗中端芯片的好几倍而且功耗和散热随之暴涨如果做产品整机的 BOM 成本完全失控。更关键的是多卡级联的并行度不只是容量叠加。当模型被切分到多颗芯片后prefill 阶段的计算并行度也提升了你等于把原来一颗芯片的极限算力乘以了一个系数虽然达不到 4 倍但通常能做到 2.5 至 3 倍的有效提升。对于 27B/31B 这种对单卡来说“勉强能装但跑不动”的模型多卡级联反而是性能和成本的最优平衡点。2. 硬件拓扑与级联方案的选型4 卡级联不是把几块板子用网线一插就能跑的硬件拓扑直接决定了通信时延、带宽瓶颈和软件实现的复杂度。我在做方案设计时对比了三种常见拓扑星型、链型和环型。星型拓扑适合主从架构由主卡统一调度子卡做纯计算节点链型和环型适合流水线并行但通信路径长时延偏高。最终我选了主从星型方案因为大模型推理的通信模式是典型的“collective 密集 点对点稀疏”主从结构更好做负载均衡。2.1 拓扑怎么选主从星型更稳实际搭建的时候我用了 1 张主卡加 3 张从卡的配置逻辑上 4 张卡地位不同但在计算时权重是平等的。主卡负责接收输入、进行 prefill 的调度、收集各卡的 logits、执行采样再把新 token 广播回各卡3 张从卡的任务相对纯粹计算各自分到的 attention 头或 FFN 层。这种结构最大的优势是调试简单问题容易定位如果某张卡坏了主卡可以快速降级到 2 卡模式。代价是主卡的通信负载高于从卡对主卡的数据通路压力更大。如果追求极致性能可以采用环型拓扑配合 pipeline parallelism但 pipeline bubble流水线空泡问题很难消除在端侧这种通信资源和算力都不宽裕的环境里调试成本太高。我的建议是第一批实现优先用主从星型等跑通之后再考虑向通信效率更高的结构演进。2.2 互联带宽到底要多少才算够多卡级联最容易被低估的是互联带宽。大模型推理的通信量和模型参数量强相关每生成一个 token各卡之间需要同步 KV Cache 和注意力输出这部分数据量在 27B 级别可以达到几百 MB 到上 GB 的量级具体取决于切分策略和序列长度。我实测算过一个数单 token 生成的通信量约为模型隐藏层维度乘以层数乘以 KV Cache 相关变量粗略算下来一次 decode 步需要搬运 400MB 到 600MB 数据。如果互联带宽只有 1Gbps 以太网125MB/s光通信就要接近 5 秒这显然没法用。我最终使用的互联方案是板载高速串行接口实测点对点带宽能到 5GB/s 左右这类接口在 RK1828 平台上通常是以高速 SerDes 形式引出需要按硬件手册做链路配置。换算下来每生成一个 token 的通信耗时大约 80ms 到 120ms再叠加计算时间整体出字速度就能落到可接受的范围内。所以如果你要复现这个方案第一件事不是急着刷系统而是确认你的 RK1828 板卡的扩展接口支持多卡直连且驱动把通信链路打通了。没有高速互联后面的软件优化做得再好也救不回来。2.3 内存和供电规划不能想当然多卡级联看似只是多插几块板卡内存和供电的水很深。RK1828 与 LPDDR 颗粒是同一块板子内存容量是固定的没法像服务器那样按需插拔。我用的板卡裸板配置是 8GB LPDDR54 张卡合计 32GB 物理内存但真正能用于模型推理的去掉系统占用和运行时开销实际可用大约 28GB。供电方面更要小心。单卡满载功耗在 6W 到 10W 之间4 卡串联看似只需要 40W但启动瞬态电流和 NPU 跑满时的峰值功耗会高出不少我实测峰值接近 60W。如果用的是 DC 供电模块务必留 1.5 倍以上余量否则推理过程中突然掉电或者触发稳压保护会让你误以为代码写错了。散热倒是比预期轻松只要不是密闭壳加个 5V 风扇对着散热片吹温度就能压在合理范围内。3. 软件栈与推理框架落地硬件拓扑只是骨架软件才是让 4 卡真正协同工作的灵魂。这一块也是我踩坑最多的地方。一开始我尝试直接用现成的多卡推理框架心想这应该比从零写容易结果发现大部分开源推理框架只支持同构计算卡比如 NVIDIA 多卡对 RK1828 这种端侧 SoC 的多卡支持几乎没有。最后可行的路线是两条一是基于 llama.cpp 的分层分卡模式改造二是基于运行时推理引擎做张量并行定制。3.1 推理框架选型llama.cpp 还是自研引擎我先把结论放在这里如果是验证可行性和快速跑通优先用 llama.cpp 的 RPC 多设备模式如果是做产品级方案需要在 llama.cpp 基础上或者自研引擎上做张量并行切分。llama.cpp 的好处是社区活跃、模型格式好转换而且支持 CPU/GPU/NPU 异构回退。它的多设备模式本质上是把不同层的权重分布到多块设备上每块设备算自己那几层设备之间通过 RPC 传递中间结果。这种模式实现简单但通信粒度高每层都要传递完整特征图对互联带宽极其敏感。我之前在服务器上用类似方式做过实验PCIe 环境下性能尚可但在端侧高速串行接口上纯层间切分的通信开销还是很大。所以后来我改造了切分策略把每个 Transformer 层内部的 QKV 投影按列切分FFN 按行切分这样通信只发生在 attention 计算后的 all-reduce 阶段消息体积比整层传递小得多带宽压力降了一个量级。3.2 权重切分和 KV Cache 分配的计算方法张量并行最核心的一步是把模型权重划分到多卡上。以 27B 模型为例假设模型是 48 层 Transformer隐藏维度为 4096我把每一层一分为二让 4 张卡各承担 12 层的计算。每一层中的 QKV 投影从 4096x4096 切成 4096x1024 的列块FFN 第一层从 4096x14336 切成按行分 4 份每份 4096x3584FFN 第二层从 14336x4096 按列切分每份 3584x4096。如此划分后单卡权重量从全量 13.5GB 降到约 3.5GBKV Cache 同理按注意力头数均匀切分。KV Cache 的具体分配是保证推理不爆显存的关键。 27B 模型如果支持 4096 上下文每层的 KV Cache 大小和注意力头数、head_dim 有关。我按 40 层、40 个头、head_dim 128 估算双精度类型下半精度下每 token 的 KV Cache 总量约为 40 层乘以 2K 和 V乘以 40 头乘以 128 字节换算下来每 token 约 0.8MB。如果保留 4096 token 的上下文就需要 3.2GB 的 KV Cache这个量放在任何一张卡上都不少。通过张量切分注意力头可以均匀分到 4 卡上每卡只承担 0.8GB 的 KV Cache加上权重单卡总占用也就 4.5GB 左右还有约 3GB 余量给激活值和框架开销。3.3 量化选型W8A8 和 W4A16 的取舍量化是大模型端侧落地的老生常谈但在多卡级联场景下需要重新审视。我分别做了 W8A8 动态量化、W4A16 静态量化和混合精度三种方案。W8A8 的优点是部署简单、无需校准集适合快速验证但内存占用比 W4A16 高一倍4 卡跑 31B 时 KV Cache 空间会被压缩得很厉害实测只能在 2048 上下文下稳定运行再长就 OOM。W4A16 虽然需要校准集做权重量化但内存占用小能让 4 卡在 4096 上下文下跑 31B 依然留有余量。我最终选了 W4A16 加部分敏感层回退到 W8A8 的混合方案敏感层判定依据是量化后输出与原始输出的余弦相似度低于阈值的层回退到更高精度。这个细节我建议做量化的人一定要重视不要一股脑全模型统一量化某些关键层损失精度对生成质量的影响很大。实际效果上混合方案比全 W4A16 的困惑度下降了 0.3 左右推理速度只损失不到 5%属于非常有性价比的调优手段。4. 从零到跑通完整实操过程这一部分我按时间线完整展示一遍实际操作流程包括我用的关键命令和参数。需要说明的是RK1828 的官方 SDK 和 BSP 版本不同命令细节会有差异但思路和步骤是通用的。4.1 系统准备与多卡识别我拿到板卡后先刷了基于最新 BSP 的 Linux 系统镜像。启动后第一步是确认 4 张卡是否都能被系统识别。RK1828 通常以设备树方式挂载多个计算设备节点你可以通过 sysfs 查看推理设备的枚举情况。确认全部识别后最忌直接开始跑模型要先跑一遍官方的多卡带宽测试工具实测点对点和聚合带宽。我那次测试发现某块卡由于 PCB 布线差异带宽只有其他卡的 60%这种板级问题如果不提前发现后面排查会让人崩溃。4.2 推理框架编译和多卡启动参数我用 llama.cpp 改造版本举例。它的 ggerr、llama-cli 都支持设备列表参数修改后的分支可以指定 --device-list 和 --tensor-split。编译时需要注意llama.cpp 默认依赖于 GPU 库RK1828 平台的 GPU 后端可能不完整需要开启 CPU 后端并启用特定指令集优化如果漏了会直接掉到通用代码路径性能惨不忍睹。启动命令大致如下实际参数以你的代码分支为准llama-cli -m /models/qwen2.5-27b-instruct-q4_k_m.gguf \ --device-list 0,1,2,3 \ --tensor-split 1,1,1,1 \ -c 4096 \ --no-mmap \ -ngl 99--tensor-split 1,1,1,1表示 4 卡均匀分配层-ngl 99表示把能卸载的层全部卸载到推理设备这里不是 GPU 的概念是平台自动把算子映射到 NPU/CPU。实际跑起来后你会发现默认参数下性能并不理想需要针对 RK1828 做算子层面调优这个我在第 5 部分详细说。4.3 部署完成后的 API 接入与验证模型跑通 CLI 后我把它封装成了 OpenAI 兼容的 API 服务这样后续接 Agent、接 RAG 都方便。常见的做法是跑一个 llama-server 或 llama.cpp 的 server 模式指定同样的多卡参数即可。我用了一个非常轻量的转发方案把 RK1828 的推理服务包装成内网 HTTP 服务同时做了一个小工具做简单的并发队列管理。验证时我习惯跑三组测试第一组是纯文本生成看输出质量第二组是长上下文多轮对话看 KV Cache 稳定性和会不会 OOM第三组是并发压测看多路请求时的排队表现。这三组都过了才能认为部署是基本合格的。4.4 实测性能数据一览这里放一组我在恒定室温、主动散热、电源余量充足条件下跑出的数据模型为 Qwen2.5-27B-Instruct INT4 混合量化版上下文 4096batch_size 1指标单卡2卡级联4卡级联模型加载耗时加载失败约 22 秒约 11 秒prefill 速度N/A约 680 token/s约 1080 token/sdecode 速度N/A约 9.5 token/s约 16.8 token/s峰值内存占用/卡N/A约 65%约 55%整机功耗N/A约 28W约 52W单卡因为内存不足直接加载失败所以 N/A。2 卡到 4 卡的 decode 速度提升不是线性翻倍主要瓶颈在互联通信和主卡调度开销。但这组数据在端侧平台上已经非常有竞争力16.8 token/s 意味着每秒钟能产出大约 16 个 token虽然距离流畅对话还有差距但作为嵌入式硬件方案已经完全可用。5. 常见问题与排查技巧实录多卡级联的坑和单卡完全不一样。单卡跑模型问题基本集中在模型格式、算子兼容和量化损失多卡跑模型问题集中在通信、切分和负载均衡。我把这段时间踩过的比较典型的问题按“现象-排查-解决”的方式整理了出来。5.1 现象一多卡跑起来比单卡还慢这是最打击人的情况。我一开始用纯层间切分跑 27B结果 4 卡速度只有单卡的一半不到。排查后发现原因是通信量太大每个 Transformer 层都要把完整的中间特征图传给下一张卡4 卡时中间结果要经过 3 次完整链路传输通信耗时远超计算耗时典型通信瓶颈。解决方式就是前文提到的张量并行切分。把 QKV 和 FFN 分别按列、按行切分这样单次前向传播的通信次数从 48 层减少到 16 个 all-reduce 节点通信量也缩小了一个量级。实测速度从 4 token/s 直接跳到 16 以上提升了 4 倍。这类问题在服务器上有成熟的 Deepspeed/Megatron 解法但端侧平台没有现成框架只能手写通信原语。5.2 现象二1 号卡负载明显高于其他卡跑 prefill 时我发现主卡占用时间比其他卡高 40%一开始以为是计算负载不均后来用 profiler 一查发现是主卡除了算 attention还要处理输入 token 序列的 preprocess、采样、logits 收集和广播这些操作全都顺序执行成了瓶颈。解决方式是给主卡减负把采样和输出处理拆分到 CPU 上主卡只负责计算本卡的层以及触发一次 all-reduce采样由 CPU 侧的采样器完成。这样主卡的 NPU 占用就降下来了整体 prefill 速度提升了约 18%。如果你的平台支持可以考虑单独留一个 CPU 核做调度和采样效果更好。5.3 现象三长上下文窗口下随机 OOM4096 上下文中跑到第 3500 个 token 左右突然报内存分配失败随机复现多试几次也不固定。排查发现是 KV Cache 预分配策略问题某些推理引擎按请求的热度动态扩展 KV Cache而不是一次性分配整块。多卡场景会把这种随机性放大因为每卡的内存水位线不同步某张卡提前触及了内存上限。解决方式是固定 KV Cache 池在启动时一次性分配整段物理内存禁止运行时扩展同时把激活值内存池也做固定管理。虽然有点浪费内存但稳定性大幅提升。另外我将批量大小限制到 1不允许动态拼 batch这也是避免随机内存尖峰的关键。5.4 现象四从卡周期性“失联”这是最隐蔽的一个问题。跑半小时后某张从卡不响应了主卡一直等 all-reduce 超时整个推理挂死。最初的排查方向是通信链路松了重新插拔后短暂恢复又复发。后来用长时压测排除法发现是散热问题导致芯片降频保护降频到阈值后计算速度骤降主卡等它的时间远超超时阈值看起来就像“死掉”了。解决方式是改进散热设计增大风量并在软件中把 all-reduce 超时时间从 2 秒提高到 10 秒同时增加从卡心跳上报。这样即使某张卡因极端工况降频主卡也能等它恢复而不是立刻判定故障。这个坑让我意识到端侧做多卡级联散热和电源不仅仅是硬件问题还会直接影响软件稳定性。6. 常见问题速查与避坑建议把这些经验浓缩成表格方便你直接在项目里对照排错。这也是我在内部团队里常用的自查清单。问题现象可能原因排查方法解决方案4卡比2卡慢层间切分通信量过大查看通信时间占比改用张量并行切分主卡利用率过高调度、采样都在主卡profiler 定位主卡耗时把采样和预处理挪到 CPU长上下文随机 OOMKV Cache 动态扩展观察内存水位线启动时固定分配 KV Cache 池从卡超时失联散热不行导致降频查看芯片温度日志增强散热提高超时阈值加载模型极慢未关闭 mmap 或驱动未预热系统日志查看 I/O 耗时使用 --no-mmap 或提前预热内存量化后模型胡言乱语敏感层精度损失过大逐层量化敏感性分析敏感层回退 W8A8除了速查表还有几个值得单独强调的避坑建议。第一所有通信相关的超时参数一定要可配置并且默认值要偏保守因为端侧板卡的个体差异远比服务器大第二不要把全部内存都分给模型要留至少 500MB 作为系统缓冲否则文件读写缓存会把内存吃光导致 OOM第三量产前一定要做长稳测试至少连续跑 72 小时端侧多卡系统最怕的就是隐藏的热点和漏电问题。整体上4 卡级联 RK1828 跑 27B/31B 大模型目前已经从“能不能跑”进入“怎么跑得稳、跑得快”的阶段。如果后续围绕这套方案继续演化我会优先尝试三件事一是用更高效的自研推理引擎替代 llama.cpp 改造版进一步压缩通信开销二是探索 8 卡级联跑 70B 级别模型的极限边界三是在这个硬件基础上做专用的小型 Agent 服务把端侧大模型真正用起来。
