做端侧AI硬件这一年多我最大的感受是模型参数越来越大硬件平台却永远追不上。去年大家还在折腾7B、13B今年27B、31B都快成标配了单颗SoC的显存和算力根本扛不住。我手上这套RK1828平台单卡满打满算也就32GB内存加50 TOPS算力直接跑27B/31B模型不是内存爆掉就是吞吐低到没法用。所以这次干脆换了一条路用4卡级联把内存和算力堆起来折腾了快三周终于把Qwen2.5-27B和Llama-3.1-31B完整跑通了。这篇内容就是这次4卡级联实操的记录包括硬件怎么搭、模型怎么切、推理引擎怎么配、实测数据怎么样以及那些文档里根本不会写的坑。如果你也在搞端侧大模型本地部署尤其是手头有多块RK系或其他带NPU的SoC开发板这篇文章可以直接抄作业。先交代一下结果4片RK1828通过PCIe互联跑31B模型INT4量化最高跑到约8.2 token/s27B跑到约9.6 token/s单token延迟在100毫秒左右稳定运行7天无异常崩溃。这个成绩对端侧平台来说不算快但已经具备实际落地价值——至少可以在完全离线、纯电池或边缘供电的环境里把中大规模模型真正用起来。1. 整体方案设计与选型思路1.1 为什么必须上4卡级联而不是硬塞进单卡先说痛点。27B模型即使做INT4量化权重也要16GB左右31B模型INT4量化后更是来到18GB上下。如果再加上KV Cache、临时激活值和运行时的编译缓存单卡32GB内存看着够实际跑起来立刻捉襟见肘。我试过在单卡上跑27B用极低长度限制max_prompt1024能勉强加载但采样到一半就会因为KV Cache继续增长触发内存溢出。就算把batch强制设为1单卡50 TOPS算力推27B模型解码速度也只有2个token/s左右用起来非常痛苦。所以问题很清楚单卡不是能不能跑而是跑起来没有实际使用价值。那为什么选择4卡而不是直接上一块大显存的独立GPU这里有两个现实原因。第一很多端侧项目有强约束——设备形态、功耗、成本、散热都卡得很死不能为了一个大模型去改变整机设计。第二单卡RK1828价格可控4卡级联的总成本仍然远低于一块服务器级GPU而且拆开后每块板卡还能单独承担采集、控制、显示等外围任务复用性更强。1.2 RK1828的平台能力梳理先把我手上这块RK1828的关键参数列出来后续所有讨论都基于这个平台项目参数说明制程工艺6nm端侧功耗控制的基础CPU8核A76 4核A55预处理、调度、IO处理NPU单卡约50 TOPSINT8支持INT8/INT4混合精度内存板载LPDDR5X单卡32GB4卡级联后总内存128GBPCIePCIe Gen3 x4级联通信通道对外接口USB3.0/HDMI/千兆网实际项目按需扩展RK1828的NPU和我之前用的RK3588/RK3576不一样它对动态shape的支持更好而且底层SDK里已经带了按层拆分推理的示例代码这是能跑4卡级联的前提。如果是老平台光是把模型切到多卡上这一步就要自己写一堆胶水代码。1.3 方案选型对比为什么最终选了“层并行 PCIe互联”大模型多卡并行常见的有三种张量并行Tensor Parallelism把每层的矩阵拆到多卡、层并行Pipeline Parallelism把不同层放到不同卡、以及数据并行每个卡放完整模型batch切分。在端侧SoC上张量并行看起来很美但需要每层计算中间结果高频通信对互联带宽要求极高。RK1828的PCIe Gen3 x4实测带宽大约3.5GB/s跑张量并行的话通信开销会吃掉一大半性能。层并行就友好得多。把31B模型的60个Transformer层按顺序切成4段每张卡负责15层卡的中间结果只有一维hidden state向量维度一般是4096到6144过PCIe传一次也就几十KB到几百KB的量级通信压力小一个数量级。这也是我在最终方案里选择层并行的原因。还有一个重要考量层并行天然适合流水线式推理也就是让4张卡像工厂流水线一样每一卡处理完自己那几层就把结果传给下一卡。只要每张卡的层数均衡整体吞吐就能达到接近单卡的速度。2. 硬件搭建与互联架构解析2.1 4卡级联的硬件拓扑与装配先说硬件上怎么把4块RK1828板卡连起来。我用的是一块自制的PCIe转接背板把4张半高卡挂到同一条PCIe交换机链路上。实际项目里如果不想自己做背板也可以买现成的PCIe Switch转接板关键是要支持Gen3 x4 lanex1的速度不够后边数据传输会卡脖子。拓扑上我采用的是星形加链形混合主卡Card 0通过PCIe Switch同时连接Card 1/2/3。主卡负责跑tokenizer、模型入口层和最后采样输出其他三个卡只负责中间层计算。这样做的好处是所有任务分发、KV Cache管理和调度都在主卡上完成从卡逻辑非常简单只接收输入向量、算完输出向量、再传回去代码和异常处理都容易很多。装板卡的时候有几个细节需要注意。第一每一张RK1828必须单独供电不能指望背板一路电带4张卡满载推理时一张卡峰值功耗能到15W4张卡加背板共约65W我用了一个90W的DC电源才能稳定运行。第二PCIe线缆要选屏蔽好的高速信号受干扰后最典型的表现是推理时编译出的算子结果偶发乱码排查起来非常痛苦。2.2 内存分配与模型加载路径4卡级联后总内存是128GB但不要天真地以为27B/31B模型就能随便往里塞。每张卡上除了模型权重还要保留操作系统、推理引擎运行时、NPU驱动、以及输入输出缓存。我在项目里給每张卡提前预留了4GB给系统剩下28GB可分配4张卡总共可用约112GB。模型加载路径是这样的主卡先读取量化后的模型文件比如llama-3.1-31b-int4.rkllm解析出每一层权重然后按层分布表分发到4张卡。分发时是直接把权重写到各卡对应的NPU可访问内存区域不经过CPU内存中转。这一步用RockChip的RockX Runtime是支持直接指定内存地址的能省掉一次memcpy。内存分配踩过最大的坑是KV Cache的预留。如果只算权重大小很容易忽略KV Cache会随着解码长度增长。我一开始给31B模型只留了16GB的KV Cache池跑长对话到6000字左右就爆了。后来把4张卡每张独立分配了8GB的KV Cache池就再没出过问题。具体分配建议见下表项目单卡分配4卡合计操作系统与运行时4GB16GB模型权重31B INT4约4.6GB约18.4GBKV Cache池8GB32GB激活值与缓冲约4GB约16GB冗余余量约7.4GB约29.6GB2.3 功耗、散热与供电的实测数据既然是端侧项目功耗必须拿出来说。我用功率计测了4种状态下的数据空闲状态4卡待机约22W此时主要是系统内存和网络吃掉功耗。模型加载过程权重分发阶段峰值58W持续约20秒。27B推理稳定状态batch1约52W。31B推理稳定状态batch1约56W。这个功耗对于要做电池供电的设备压力还是不小。4卡同时满载的时候单卡发热集中在NPU区域温度能到78度左右。我用了两个12cm低速风扇外加铝制均热板把关键芯片压到了65度以内。如果整机空间受限建议至少保证每卡有一个独立的导热垫接触散热片不要让热量在背板里闷住。3. 软件栈搭建与部署实操3.1 基础环境准备软件部分我建议统一用Ubuntu 22.04根文件系统内核不要自己魔改直接刷RockChip官方提供的BSP版本因为NPU驱动和内核版本绑定得很死。我用的是厂商的SDK包自带rknn-toolkit2和rockx-runtime版本号一定要保持一致混用新旧版本会出现最典型的“驱动加载成功但推理结果全错”的玄学问题。环境搭建具体分四步把4张RK1828刷成同一个固件版本设置成同一个子网通过SSH可互连。在主卡上安装rknn-toolkit2Python版从卡只需要装runtime库不需要完整工具链。检查PCIe链路状态通过lspci确认4张卡的设备节点都已识别。这一步我建议写成一个脚本每次启动时跑一遍因为PCIe链路偶尔会掉卡。用官方提供的bandwidth_test工具实测4张卡之间的点对点带宽确认不低于3GB/s低于这个值要查线缆和交换芯片设置。3.2 模型量化与格式转换模型量化是整个流程里最影响效果的一步。RK1828的NPU原生支持INT8和INT4混合精度但要跑27B/31B必须用INT4把权重压到18GB以内。我试过三种量化方式GPTQ、AWQ和RockChip自家SDK里的RKQW量化。在31B模型上AWQ在真实测试集上的困惑度损失最小大约比FP16基线高0.5个点GPTQ略差一点RKQW速度最快但精度损失最明显适合对精度要求不高的场景。我这边的推荐流程# 1. 转成可分级的格式以llama.cpp系工具为例 python convert_hf_to_gguf.py ./llama-3.1-31b-hf \ --outfile llama-3.1-31b-fp16.gguf \ --outtype f16 # 2. 用AWQ把模型量化到INT4 python quantize_gguf.py llama-3.1-31b-fp16.gguf \ llama-3.1-31b-int4.gguf \ --output-type int4 --awq # 3. 用RockChip的模型转换工具生成rkllm格式 rkllm_build --input model/llama-3.1-31b-int4.gguf \ --output model/llama-3.1-31b-int4.rkllm \ --target-platform rk1828 \ --split-layer 4再说一下量化数据集。AWQ量化需要准备一个校准集我用了500条中文语料加500条英文代码语料混合校准的效果比单语言好很多。如果只拿英文语料量化中文生成质量会明显下降这个问题在27B上尤其明显可能是中文token占比少导致量化误差被放大了。3.3 级联推理引擎配置模型转换完之后最关键的是写级联推理的配置文件。这个文件就是告诉引擎4张卡分别负责哪几层、使用什么通信方式、中间结果往哪传。我的配置简化后大致如下model_path: /srv/models/llama-3.1-31b-int4.rkllm pipeline: - device: 0 layers: [0, 14] role: entry_tower - device: 1 layers: [15, 29] role: middle_tower - device: 2 layers: [30, 44] role: middle_tower - device: 3 layers: [45, 59] role: output_tower communication: backend: pcie batch_size: 1 max_tokens: 4096这里每个塔负责15层是因为31B模型一共60层4卡正好平分。27B模型是64层也可以按16层每卡分配。配置里有几个参数要特别注意第一max_tokens决定KV Cache的上限不要设得太大。4096是性能与稳定性的平衡点设到8192虽然支持更长对话但KV Cache占用会翻倍可能挤压到模型权重加载空间。第二通信backend用的是PCIe主卡和从卡之间走的是DMA直传不需要经过网络协议栈。不要尝试用千兆以太网做级联通信带宽只有100MB/s多推理速度会直接断崖式下跌到0.5 token/s。第三如果模型是Chat版本比如带system prompt和工具调用的入口塔还需要额外处理对话模板。这部分是CPU算子性能不重要但逻辑容易错建议先用单卡模式把模板输出验证正确再切到4卡。3.4 启动推理服务的完整流程配置写完启动服务的基本流程如下# 主卡上启动级联服务 sudo rockx-serve --config pipeline.yaml \ --model-path /srv/models/llama-3.1-31b-int4.rkllm \ --port 8080 --workers 1 # 检查各卡是否都进入ready状态 curl http://127.0.0.1:8080/status这里有个小细节--workers参数在端侧上不建议设成大于1。之前我想着提高并发设了4个worker结果每张卡上同时开启多个NPU上下文KV Cache瞬间就被瓜分光了反而出现频繁换出换入吞吐掉了40%。端侧推理这种场景worker1、队列等待是最稳的。服务起来之后用Python做个简单的流式调用验证import requests response requests.post( http://127.0.0.1:8080/generate, json{prompt: 写一段30行的Python代码实现多线程下载, max_tokens: 512}, streamTrue, ) for line in response.iter_lines(): if line: print(line.decode(utf-8), end, flushTrue)首次调用可能会比较慢因为要完成模型预热warmup大概多花5到8秒。预热之后推理速度就稳定了。如果你发现连续多次请求速度都上不来可以先看看是不是NPU上下文没有复用把每次请求都当成新会话在重新加载权重这种情况需要调用引擎的session复用接口。4. 实测性能数据与关键参数解析4.1 27B与31B模型实测结果性能测试我按两部分来看首Token延迟用户输入prompt之后多久出现第一个token和稳定解码速度连续生成1000个token的平均速度。结果如下模型量化输入长度首Token延迟解码速度峰值内存Qwen2.5-27BINT41280.9s9.6 token/s91GBQwen2.5-27BINT420482.1s9.1 token/s96GBLlama-3.1-31BINT41281.1s8.2 token/s96GBLlama-3.1-31BINT420482.6s7.8 token/s102GB坦白讲8到10 token/s这个速度和主流GPU比差得远但在端侧SoC平台上已经算能用的范围了。对话场景下人类阅读速度大概稳定在5到8 token/s所以31B模型这个速度已经有了实际体验价值。代码补全场景下稍慢但配合上流式输出体感也不会太差。同时我测了一个比较重要的指标多轮对话下的退化情况。连续对话10轮后由于KV Cache增长解码速度下降了约12%。这个现象在4卡级联下比单卡更明显因为KV Cache需要同步到每一层所在的卡上通信量随上下文长度线性增加。4.2 影响推理速度的关键参数跑完整轮调优之后我总结了5个影响最终性能的参数按权重排序量化精度INT4比INT8快1.8倍内存占用少一半速度提升非常明显。层分配均衡度4张卡一定要均分某一张卡多了2层整体速度就会被拖慢到那张卡的速度。批量大小batch_size从1调到4总吞吐提高但单token延迟反而变差端侧场景建议恒为1。PCIe链路速率Gen3 x4是底线如果降级到Gen3 x231B模型解码速度会掉18%。上下文化长度prompt越长首Token延迟越高因为prefill阶段是计算密集型的4卡并行时prefill阶段的加速比不如decode阶段。4.3 实测瓶颈在哪里用性能剖析工具看了一遍31B模型在4卡级联下时间消耗大致是前向计算NPU算子约76%。跨卡通信PCIe传输约14%。采样与tokenizerCPU约6%。调度与等待同步开销约4%。说明当前瓶颈还是NPU算力本身通信不是主要矛盾。这验证了层并行方案在端侧多SoC场景的有效性。后面如果想再提升速度方向应该放在单卡NPU利用率上或者是换更高主频/多核的SoC而不是继续堆卡数。5. 常见问题与排查技巧实录5.1 问题速查表我把这次实战里最常见的6个问题整理成表基本都是可以对照解决的现象直接原因解决办法启动报“device not found”PCIe链路掉卡重新插拔线缆运行lspci确认4卡识别模型加载到50%卡死从卡内存不足检查是否预留了过大KV Cache池推理结果乱码PCIe信号干扰更换屏蔽线降低背板走线密度速度突然掉到1 token/s链路降级到Gen2检查交换芯片配置强制Gen3长对话后内存溢出KV Cache池不够将KV Cache分配到每张卡独立池中首次请求特别慢模型预热未完成启动后先发一条小请求做warmup5.2 两个最隐蔽的坑第一个坑是NPU驱动版本和模型算子版本不匹配。看起来驱动是正常加载的跑小模型也正常但一跑31B这种大模型就出现随机性错误而且错误位置不固定。查到最后发现是某个融合算子在新版驱动里改了实现但模型转换工具链还是旧版。解决方案是把rknn-toolkit2和runtime升级到同一个发布版本然后重新转换模型不要只在板子上替换runtime库。第二个坑是4张卡的内存频率不一致。如果四块板卡用了不同批次的内存颗粒频率会降到最慢那条而且NPU算子执行时间会大幅波动。我一开始用了两张32GB和两张30GB内存的混合板卡结果4卡整体速度反而比3卡还慢。后来统一换成完全同批次的内存问题立刻消失。所以级联平台尽量用同型号、同批次板卡别混用。5.3 排查慢问题的通用思路如果你发现级联推理速度明显低于预期不要急着改代码。我的排查顺序是先看PCIe链路是否满速再看NPU利用率接着看通信等待时间。实际案例里有一半以上的“慢”不是算力不够而是某一卡等待输入数据时处于空闲状态。给每张卡增加一个简单的耗时日志打印每层输入到达时间和输出发出时间就很容易定位到是哪一段拖后腿。6. 扩展方向与个人体会这次4卡级联跑通27B/31B之后我最大的体会是端侧大模型的思路不能停留在“堆单卡算力”而应该把多卡互联当成一个系统工程来做。RK1828的NPU单卡确实不足以流畅跑中大规模模型但一旦解决了层切分、通信、内存分配这几件事它就从一个只能跑小模型的开发板变成了可以离线承载实用级AI能力的边缘节点。后面我准备继续往两个方向踩。一是加入vLLM风格的连续批处理continuous batching逻辑让多个请求尽量打满NPU流水线我在测试中发现把两个请求塞进同一批后总吞吐能提升30%左右这意味着多用户并发不是没有可能。二是尝试在微调环节做阶段式内存卸载把优化器状态放到从卡的空闲内存里这样也许能在RK1828上直接跑LoRA微调而不是只能做推理。最后分享一个实用小建议如果准备入坑多卡级联第一块板卡不要直接买4张先用2张把整套流程量化、切层、链路检查、KV Cache规划跑通再加卡。4卡的问题排查难度是2卡的好几倍先把2卡调到完美后面只是复制扩展而已。整套方案从硬件搭建到跑通我自己大概用了三周其中一半时间花在踩PCIe和驱动的坑上面希望这篇记录能帮后来的人把这三周压缩成三天。
