大模型部署：算力、內(nèi)存與選型指南)
最近這半年我接到的端側(cè)AI選型咨詢里十有八九都會繞到同一個問題1B、3B、7B的大模型到底該用RK3588、RK3576還是RK3568主板算力和內(nèi)存怎么配才不浪費、不卡頓說實話這個問題沒有標準答案但有一套可以復用的計算方法。本文就結(jié)合瑞迅科技這三款主流ARM主板的實際方案把端側(cè)部署大模型的算力賬、內(nèi)存賬和應(yīng)用場景賬一筆一筆算清楚。本文適合三類人看一是正在做邊緣計算盒子、智能座艙、工業(yè)AI網(wǎng)關(guān)的產(chǎn)品經(jīng)理二是準備把開源大模型落到ARM板上的嵌入式工程師三是對端側(cè)推理感興趣、想用RK3588跑通自己第一個大模型Demo的開發(fā)者。讀完你至少能回答手里的項目該選哪顆芯片、配多大內(nèi)存、用什么量化精度、跑起來大概什么速度。1. 三個平臺先交底RK3588、RK3576、RK3568各是什么水平很多朋友一上來就問“RK3588能不能跑7B”但7B只是個參數(shù)規(guī)模數(shù)字真正影響部署體驗的還包括模型結(jié)構(gòu)、量化方式、上下文長度、并發(fā)數(shù)以及芯片的內(nèi)存帶寬和NPU算子優(yōu)化程度。在談選型之前先把這三款芯片的家底摸清楚。1.1 三款芯片的核心規(guī)格對比以瑞迅科技目前主推的幾款工業(yè)級ARM主板為例三款芯片的定位差異非常明顯芯片型號CPU架構(gòu)NPU算力INT8內(nèi)存支持典型接口亮點產(chǎn)品定位RK35884×Cortex-A76 4×Cortex-A556 TOPSLPDDR4/4x/5最大32GBPCIe3.0、雙千兆網(wǎng)口、HDMI2.1、多路MIPI/CSI、USB3.0旗艦邊緣算力平臺RK35764×Cortex-A72 4×Cortex-A536 TOPSLPDDR4/4x/5最大16GBPCIe2.1、雙千兆、HDMI2.0、支持8K編解碼上探邊緣AI、下壓工控RK35684×Cortex-A550.8 TOPSLPDDR4/4x最大8GB雙千兆、PCIe3.0、HDMI2.0入門邊緣計算/工控這里有個容易踩坑的點RK3576和RK3588的NPU算力標稱都是6 TOPS但CPU、GPU、內(nèi)存控制器、接口豐富度完全不是一個級別。RK3576可以理解為“把NPU核心能力下放到中端”的方案整體成本更低但7B模型的推理性價比不如RK3588。RK3568的NPU算力只有0.8 TOPS跑大模型非常吃力更適合配合輕量模型做嵌入式語音、簡單質(zhì)檢這類任務(wù)。我一直強調(diào)一個觀點選芯片不能只看NPU算力還要看整個SoC的協(xié)同能力。RK3588的優(yōu)勢在于CPU性能強跑Python推理腳本、做前后處理、甚至直接跑llama.cpp的CPU版本都不至于太難受這在研發(fā)調(diào)試階段非常關(guān)鍵。1.2 算力評估的底層邏輯TOPS、FLOPs與token生成速率的換算想要搞懂端側(cè)大模型需要多強算力先得建立一個基本概念大模型生成一個token可以粗略理解為一個漢字或一個英文單詞的一部分需要完成多少次計算。以自回歸生成模型為例每生成一個token的理論計算量大約是2乘以模型參數(shù)量即7B模型約需14 GFLOPs1.4×10^10 FLOPs。3B模型約6 GFLOPs1B模型約2 GFLOPs。這個數(shù)字是理論下限實際推理過程中還有注意力計算、采樣、內(nèi)存存取開銷通常會比這個理論值高出不少。那6 TOPS的NPU能跑多快按理論值算6 TOPS相當于每秒執(zhí)行6×10^12次INT8運算跑7B模型的理論速度上限是每秒幾百token。但實測遠達不到原因有幾點NPU算子的實際利用率通常只有峰值的20%~40%尤其是Attention算子很多芯片優(yōu)化得并不理想自回歸生成是“一次只算一個token”無法把所有計算并行塞滿大量時間浪費在內(nèi)存訪問上尤其是參數(shù)權(quán)重讀取和KV Cache讀寫int4量化模型雖然內(nèi)存減半但NPU對4bit算子的支持效率不等同于int8需要看編譯器支持情況所以我的經(jīng)驗是想要估算端側(cè)真實速度別用TOPS直接除FLOPs而是用“同平臺、同模型、同量化方式”的實測經(jīng)驗值做錨點。下面這張表是我在不同瑞迅主板上實測下來的速度區(qū)間雖然不同模型結(jié)構(gòu)、RKLLM版本和散熱狀態(tài)會有差異但數(shù)量級是可信的平臺模型規(guī)模量化方式生成速度經(jīng)驗值體驗判斷RK35880.5B~1BINT420~40 token/s流暢可做實時對話RK35883BINT48~15 token/s能接受適合問答RK35887BINT42~5 token/s可跑偏慢適合異步任務(wù)RK35761B~3BINT43B約6~12 token/s3B以下體驗尚可RK35680.5B~1BINT43~8 token/s僅適合極輕量任務(wù)看到這里你應(yīng)該已經(jīng)直觀感受到RK3568跑大模型屬于“能響但急死人”的水平RK3588是真正能承擔“可用級”端側(cè)大模型的底線平臺。至于為什么下面就從內(nèi)存和帶寬層面進一步拆。2. 內(nèi)存才是端側(cè)大模型的第一瓶頸很多選型的朋友只盯著NPU算力問但我實際調(diào)試下來發(fā)現(xiàn)內(nèi)存容量和帶寬對端側(cè)LLM的影響甚至比算力更致命。模型加載時內(nèi)存不夠直接OOM內(nèi)存帶寬不夠NPU就算算得再快也只能排隊等數(shù)據(jù)。2.1 模型、量化與內(nèi)存占用的換算模型參數(shù)量乘以每個參數(shù)占用的字節(jié)數(shù)就是權(quán)重部分的內(nèi)存占用FP1616bit半精度每參數(shù)2字節(jié)INT88bit量化每參數(shù)1字節(jié)INT44bit量化每參數(shù)0.5字節(jié)以7B模型為例FP16權(quán)重約14GBINT8約7GBINT4約3.5GB。這就是為什么端側(cè)部署首選INT4量化——只有這樣才能把7B模型塞進RK3588的16GB內(nèi)存版本里。但注意權(quán)重內(nèi)存只是“模型文件本身”的開銷。推理過程中還有激活值、KV Cache、推理中間緩沖區(qū)和運行時代碼占用。我習慣用“權(quán)重內(nèi)存 運行開銷”來估算總內(nèi)存需求經(jīng)驗上運行開銷大約是權(quán)重內(nèi)存的1.2~1.5倍還要再加系統(tǒng)內(nèi)存占用。下面是一張選型時可以直接套用的對照表模型規(guī)模量化精度權(quán)重內(nèi)存約推薦內(nèi)存檔位適用場景1BINT40.5GB2GB~4GB語音指令、文本分類1BINT81GB4GB輕量問答3BINT41.5GB4GB~8GB對話機器人、摘要3BINT83GB8GB更高精度問答7BINT43.5GB8GB~16GB知識庫問答、復雜推理7BINT87GB16GB~32GB不建議端側(cè)跑INT8我特別注意了一下目前RK3588平臺配16GB內(nèi)存是7B INT4模型的“甜點檔位”既能容納模型權(quán)重又給KV Cache和系統(tǒng)服務(wù)留了余量。如果預算緊張選8GB也不是完全不能跑但上下文長度和并發(fā)能力會被卡得很死后面細說。2.2 KV Cache一個被嚴重低估的內(nèi)存殺手KV Cache是大模型推理時緩存歷史token鍵值對的內(nèi)存區(qū)。每生成一個tokenK和V都會隨序列增長而增加所以它和上下文長度是線性關(guān)系。上下文越長KV Cache占用越大。拿7B模型舉例如果設(shè)置上下文長度2048KV Cache大約要占0.5GB到1GB如果把上下文拉到4096這個數(shù)字會漲到1.5GB到2GB。3B模型雖然小一些但長上下文同樣會吃掉幾百MB甚至1GB內(nèi)存。1B模型在短上下文下壓力不大但一旦多開幾路也會快速膨脹。這解釋了為什么端側(cè)大模型在實際產(chǎn)品里往往限制上下文長度而不是無限擴展。我調(diào)試瑞迅RK3588板子時默認把context_len設(shè)置為1024或2048既不影響大多數(shù)問答場景又給系統(tǒng)留足余量。忽略KV Cache盲目拉長上下文是端側(cè)部署最常見的內(nèi)存失控原因。內(nèi)存帶寬這方面也要多說一句。自回歸生成是“訪存密集型”任務(wù)NPU每算一個token都要把模型權(quán)重從頭到尾讀一遍。INT4量化后7B模型每次生成也要讀3.5GB權(quán)重如果內(nèi)存帶寬不夠速度瓶頸就卡在存儲而非NPU。RK3588和RK3576支持LPDDR5帶寬明顯優(yōu)于只支持LPDDR4x的RK3568這也是后者跑大模型體驗差的關(guān)鍵原因之一。2.3 結(jié)合瑞迅主板的內(nèi)存檔位怎么選瑞迅科技在RK3588、RK3576、RK3568三款平臺上都提供了不同的板型和內(nèi)存版本。以我接觸到的方案為例RK3588主板常見4GB/8GB/16GB/32GB版本。跑7B INT4模型建議直接選16GB起步8GB版本更適合3B及以下32GB版本適合跑INT8精度或多路并發(fā)場景但成本和功耗也上去了RK3576主板常見4GB/8GB/16GB版本。這款芯片NPU算力和RK3588同級但內(nèi)存帶寬和CPU性能略低跑3B以內(nèi)很舒服跑7B屬于“能跑但緊張”建議8GB起步RK3568主板常見2GB/4GB/8GB版本。跑0.5B~1B模型選4GB足夠8GB版本可以給系統(tǒng)更多余量但不建議跑3B以上的模型每次選型我都會畫一條“模型檔位-內(nèi)存檔位-芯片檔位”的三維匹配線先定模型和量化方式算出權(quán)重KV Cache系統(tǒng)的總內(nèi)存需求再反推平臺和內(nèi)存版本。這是最穩(wěn)妥的路徑比拿著芯片參數(shù)表猜半天靠譜得多。3. 用RKLLM工具鏈把模型部署到瑞迅板卡上選好了平臺和內(nèi)存接下來就是真刀真槍的部署環(huán)節(jié)。瑞芯微官方提供的RKLLM工具鏈是目前在RK3588/RK3576/RK3568上部署LLM最順手的路徑它把模型轉(zhuǎn)換、量化、板端runtime三層全部打通了。瑞迅主板作為瑞芯微方案的主流工業(yè)級落地形態(tài)同樣適用這一套工具鏈。3.1 一份可直接抄作業(yè)的部署流程整體流程大概是從HuggingFace下載開源模型在x86主機上用RKLLM Toolkit做格式轉(zhuǎn)換和量化生成.rkllm格式的模型文件然后放到板子上通過C/C或Python接口調(diào)用。模型選擇上目前在瑞迅板卡上跑得比較成熟的是Qwen系列、Llama-3.2系列、ChatGLM系列。我的推薦組合是輕量任務(wù)Qwen2.5-0.5B-Instruct、Llama-3.2-1B-Instruct中等任務(wù)Qwen2.5-1.5B/3B-Instruct、Llama-3.2-3B-Instruct偏重任務(wù)Qwen2.5-7B-InstructINT4量化轉(zhuǎn)換這一步建議在一臺內(nèi)存不低于32GB的x86主機上做因為量化和格式轉(zhuǎn)換過程本身就很吃內(nèi)存。命令行大致長這樣git clone https://github.com/airockchip/rknn-llm.git cd rknn-llm/rkllm_toolkit pip install -r requirements.txt python convert.py \ --model_path /path/to/Qwen2.5-3B-Instruct \ --output qwen2.5_3b_w4a16.rt \ --target_platform rk3588 \ --quantized_dtype w4a16其中target_platform要嚴格對應(yīng)實際板卡芯片填錯會導致模型在板端加載失敗。quantized_dtype參數(shù)里w4a16是目前端側(cè)LLM的主流配置意思是權(quán)重4bit、激活16bit我實測這個配置在精度和性能之間取得了一個不錯的平衡點。轉(zhuǎn)換完成后把生成好的.rkllm文件拷貝到板子上比如放在/data目錄下。板端集成的C接口大致是這樣#include rkllm.h rkllm_context ctx; RKLLMParam param rkllm_createDefaultParam(); param.model_path /data/qwen2.5_3b_w4a16.rt; param.top_k 40; param.top_p 0.9f; param.temperature 0.7f; rkllm_init(ctx, param, nullptr); RKLLMInput input; input.text 請用三句話介紹瑞迅科技RK3588主板; RKLLMOutput output; rkllm_run(ctx, input, output, callback, nullptr);這里有個非常重要的點rkllm_run是異步調(diào)用推理結(jié)果通過callback回調(diào)返回。所以實際產(chǎn)品里要維護好一個上下文狀態(tài)不能簡單當成同步函數(shù)處理。我一開始在這里踩過坑以為調(diào)用完直接拿output結(jié)果回調(diào)先觸發(fā)、主線程還在等邏輯就亂了。3.2 RKLLM關(guān)鍵參數(shù)怎么設(shè)兼談context_len和max_new_tokensRKLLM默認參數(shù)能跑通但不代表適合你的場景。有兩個參數(shù)直接決定內(nèi)存占用和響應(yīng)體驗第一個是context_len也就是模型能參考的歷史上下文長度。端側(cè)場景我建議設(shè)為1024或2048。設(shè)得越大KV Cache占用的連續(xù)內(nèi)存越多。曾有客戶為了“顯著高級”把context_len設(shè)為8192結(jié)果7B模型在16GB板子上頻繁崩潰后來縮到2048就穩(wěn)了。第二個是max_new_tokens也就是每次生成的最大新token數(shù)量。端側(cè)部署建議按任務(wù)類型設(shè)定比如短問答設(shè)128或256總結(jié)類任務(wù)設(shè)512。如果設(shè)成1024甚至更大一方面生成時間線性增長另一方面需要預留的KV Cache內(nèi)存也跟著漲。很多“生成到一半卡死”的現(xiàn)象其實不是推理引擎掛了而是KV Cache內(nèi)存不夠被系統(tǒng)殺掉了。還有一個容易被忽視的點temperature和top_p這兩個采樣參數(shù)會影響輸出質(zhì)量和穩(wěn)定性。如果發(fā)現(xiàn)模型輸出的內(nèi)容在各種無關(guān)主題間跳躍或者回答明顯重復可以先檢查這兩個參數(shù)而不是懷疑模型沒部署好。我一般用temperature0.7、top_p0.9作為默認值追求確定性答案時再把temperature降到0.3以下。3.3 常見內(nèi)存分配失敗與模型加載報錯部署過程中最讓人頭疼的不是模型轉(zhuǎn)換而是板端運行時報各種內(nèi)存錯誤。我整理幾個高頻問題現(xiàn)象根本原因解決辦法rkllm_init返回內(nèi)存分配失敗系統(tǒng)可用連續(xù)內(nèi)存不足檢查cma參數(shù)關(guān)閉不需要的GPU/VPU服務(wù)重啟后立即加載模型模型文件加載失敗target_platform填錯或模型文件損壞重新轉(zhuǎn)換確認平臺匹配用RKLLM驗證工具檢查推理一段時間后進程被殺KV Cache內(nèi)存超限調(diào)低context_len和max_new_tokens轉(zhuǎn)換過程主機OOM量化需要大量內(nèi)存換32GB以上內(nèi)存的機器減小batch size瑞迅主板的Linux系統(tǒng)默認可能預留了一部分內(nèi)存給GPU、VPU等硬件模塊。跑大模型時如果發(fā)現(xiàn)系統(tǒng)內(nèi)存顯示充足但加載失敗優(yōu)先檢查CMAContiguous Memory Allocator配置。我調(diào)試時習慣在啟動參數(shù)里顯式預留連續(xù)內(nèi)存比如在/boot/extlinux/extlinux.conf的內(nèi)核啟動參數(shù)中加上cma256M給模型加載留出充足空間。這里多提一句堆外內(nèi)存的問題。如果你是在Android系統(tǒng)上通過JNI調(diào)用RKLLM或者用Java/Python混合方式寫推理服務(wù)native層內(nèi)存和Java堆內(nèi)存是分開管理的。很多內(nèi)存不足問題出在native層而不是JVM堆。我的建議是端側(cè)部署優(yōu)先用純C/C或Python直接驅(qū)動RKLLM盡量減少跨語言層既省內(nèi)存又省排查負擔。4. 推理速度實測與能效表現(xiàn)哪些組合能用哪些是硬上理論算完還是得回到實測。以瑞迅RK3588主板為例我把常見的幾組模型組合跑了一遍總體感覺是1B到3B是體驗分水嶺7B屬于“技術(shù)驗證可跑、產(chǎn)品落地要謹慎”的檔位。4.1 我實測的推理速度區(qū)間測試條件瑞迅RK3588主板LPDDR5 16GBUbuntu系統(tǒng)RKLLM最新版本w4a16量化context_len2048單路請求。模型組合實測生成速度首token延遲內(nèi)存峰值占用約備注Qwen2.5-0.5B35~45 token/s約0.5s1.5GB響應(yīng)非?？爝m合語音交互Qwen2.5-1.5B18~28 token/s約0.8s2.5GB日常問答流暢Llama-3.2-1B20~30 token/s約0.7s2.5GB英文任務(wù)表現(xiàn)不錯Llama-3.2-3B8~12 token/s約1.2s5GB能接受適合專業(yè)問答Qwen2.5-3B8~14 token/s約1.2s5GB中文能力均衡Qwen2.5-7B2~4 token/s約3s9GB速度偏慢適合離線異步任務(wù)這個速度區(qū)間的實際體驗可以這么理解30 token/s以上人幾乎無感知適合語音助手、交互式對話10~20 token/s能感覺到模型在“打字”但可接受適合知識庫問答、文檔摘要10 token/s以下交互會明顯卡頓適合單次生成較長的文本或者接受“提交后等一會兒再看結(jié)果”的產(chǎn)品形態(tài)。我把瑞迅RK3576也測試了幾輪3B模型的速度大約比RK3588低20%左右6~10 token/s屬于“能用但不夠爽”。RK3568我只跑了0.5B和1B的模型3~8 token/s適合做離線指令識別不適合做多輪對話。4.2 從DDR帶寬看3576和3588的差距前面提到RK3576的NPU算力和RK3588同為6 TOPS但推理速度卻有差距核心原因就在內(nèi)存帶寬。RK3588支持的LPDDR5頻率更高帶寬理論上可以達到60GB/s級別而RK3576雖然也支持LPDDR5但整體內(nèi)存控制器規(guī)格略低實際帶寬不如RK3588。為什么帶寬對大模型推理這么重要因為自回歸生成就是“一遍遍重復讀權(quán)重”的過程。7B模型INT4量化后約3.5GB權(quán)重每生成一個token就要把這3.5GB從頭到尾讀一遍。如果內(nèi)存帶寬是20GB/s光讀權(quán)重就要0.175秒再加上計算和數(shù)據(jù)搬運最終速度很容易被壓到3 token/s左右。這也是為什么端側(cè)大模型的體驗天花板往往不由TOPS決定而是由“芯片能多快地把權(quán)重喂給NPU”決定。選型時同TOPS的情況下優(yōu)先選內(nèi)存帶寬更高的平臺這是一個很關(guān)鍵的隱藏指標。4.3 能效與散熱跑大模型不只看性能還有一個選型時容易被忽略的因素功耗和散熱。RK3588在滿負荷跑7B模型時SoC功耗可以到10W以上這還沒算內(nèi)存和外圍器件。如果在密閉的工業(yè)盒子里長時間跑推理溫度會快速積累觸發(fā)降頻后速度進一步下滑。瑞迅主板一般會引出風扇供電和PWM控制引腳我建議量產(chǎn)設(shè)備一定要把主動散熱做成標配。后續(xù)章節(jié)我會專門講風扇控制和板級調(diào)優(yōu)這里先給個結(jié)論端側(cè)大模型產(chǎn)品的算力選型一定要把散熱成本算進去否則標稱6 TOPS的NPU在過熱降頻后可能連3 TOPS都發(fā)揮不出來。5. 典型應(yīng)用場景選型參考與落地建議聊完參數(shù)和實測回到最實際的選型表?；谖以诠I(yè)、商業(yè)、智能硬件項目里的開發(fā)經(jīng)驗整理了六類典型的端側(cè)大模型應(yīng)用場景對應(yīng)瑞迅三款平臺和內(nèi)存檔位的推薦配置。5.1 六類場景配置推薦應(yīng)用場景推薦平臺模型檔位內(nèi)存推薦說明智能語音交互盒子RK3576/35881B~3B INT48GB需要低首token延遲建議1B為主本地知識庫問答終端RK35883B~7B INT416GB需要檢索增強和長上下文內(nèi)存留足工業(yè)視覺AI質(zhì)檢RK3588視覺模型1B~3B8GB~16GB視覺模型和大語言模型共享算力與內(nèi)存邊緣AI網(wǎng)關(guān)/車聯(lián)網(wǎng)RK35761B~3B INT48GB側(cè)重多路接入和數(shù)據(jù)轉(zhuǎn)發(fā)低功耗嵌入式終端RK35680.5B~1B INT44GB簡單指令識別、文本分類邊緣AI開發(fā)工作站RK35883B~7B INT416GB~32GB開發(fā)者調(diào)試、多場景驗證這六類場景里我覺得第一個“智能語音交互盒子”是當前最成熟的端側(cè)大模型落地形態(tài)。它不需要那么強的上下文能力1B模型加一個語音喚醒加ASR再加TTS整個鏈路在RK3576上就能跑得很流暢成本相比云端方案有明顯優(yōu)勢。如果是做“本地知識庫問答終端”7B檔位就比較剛需因為知識庫中的文件內(nèi)容往往較長模型需要有足夠的推理能力才能生成靠譜回答。這種場景我不建議用1B或3B雖然速度更快但回答質(zhì)量會明顯下降常見表現(xiàn)是“答非所問”或者“只復述不推理”。5.2 盡量別做的事7B全精度、長上下文、高并發(fā)聊完推薦再說幾個我實際踩過的“硬上”案例第一件別做的事是在RK3588上跑7B模型的全精度FP16版本。14GB的權(quán)重加運行開銷16GB內(nèi)存基本被占滿系統(tǒng)稍微有點其他服務(wù)就被OOM killer殺掉。即使勉強跑起來速度也只有1~2 token/s實用性非常差。端側(cè)7B的現(xiàn)實路徑一定是INT4量化。第二件別做的事是把上下文長度拉到4096甚至8192。端側(cè)設(shè)備的內(nèi)存是有限資源長上下文會成倍放大KV Cache占用。我見過一個案例客戶堅持要8192上下文做“長文檔分析”結(jié)果16GB板子在生成到第幾百個token時直接重啟。后來我建議他們在應(yīng)用層做文檔切片用多次短上下文的輪詢方式替代單次長上下文問題就解決了。這個思路在端側(cè)尤其重要——別讓模型一次吃進所有內(nèi)容而是讓應(yīng)用層幫模型“分段消化”。第三件別做的事是在端側(cè)大模型上做高并發(fā)。云端GPU集群可以橫向擴展端側(cè)SoC是單芯片單內(nèi)存多路并發(fā)意味著每個請求都要分配獨立的KV Cache和推理緩沖。RK3588跑7B模型單路都只有2~4 token/s如果同時壓上3路請求每路都會被拖到1 token/s以下首token延遲更是不可接受。端側(cè)大模型產(chǎn)品應(yīng)該設(shè)計成單用戶、低并發(fā)、異步處理的形態(tài)這符合硬件能力邊界也能給用戶一個合理的預期。5.3 外設(shè)占用對推理穩(wěn)定性的隱性影響端側(cè)設(shè)備通常不只是跑大模型還要承擔攝像頭采集、串口通信、云端上報等任務(wù)。RK3588的NPU和CPU共享內(nèi)存帶寬GPU編解碼也會搶占DMA資源這些都可能導致大模型推理速度波動。我有一個實操建議量產(chǎn)階段一定要做“整機滿載測試”把所有外設(shè)同時開啟連續(xù)跑24小時大模型推理任務(wù)記錄速度波動和系統(tǒng)日志。瑞迅主板外設(shè)接口豐富但每個接口的驅(qū)動和DMA通道都有可能和RKLLM的連續(xù)內(nèi)存分配產(chǎn)生競爭。提前發(fā)現(xiàn)這些干擾因素比發(fā)貨后客戶反饋“推理變慢”要省心得多。還有一點值得注意盡量在量產(chǎn)系統(tǒng)里關(guān)閉不使用的服務(wù)模塊比如藍牙、Wi-Fi的省電模式、不必要的GPU合成等。跑LLM時系統(tǒng)越“干凈”速度越穩(wěn)定。我甚至會把桌面環(huán)境都禁掉只保留業(yè)務(wù)自啟動進程這樣內(nèi)存占用能少將近1GB。6. 板級調(diào)優(yōu)與研發(fā)期避坑到了這一章節(jié)假設(shè)你已經(jīng)選好主板、部署好模型接下來就是讓整套系統(tǒng)在工業(yè)環(huán)境里穩(wěn)定跑起來。這部分經(jīng)驗往往是最難查到的因為文檔和手冊不會寫這些細節(jié)。6.1 散熱與PWM風扇控制RK3588跑7B模型時SoC溫度上升很快不加散熱片和風扇幾分鐘內(nèi)就能沖到85攝氏度以上觸發(fā)降頻。瑞迅RK3588主板通常帶有PWM風扇接口系統(tǒng)里配置好pwm-fan節(jié)點就能實現(xiàn)溫控。在設(shè)備樹里加一個pwm-fan節(jié)點大致配置如下pwm0 { status okay; }; pwm-fan { compatible pwm-fan; pwms pwm0 0 25000 0; cooling-levels 0 64 128 192 255; #cooling-cells 2; };其中cooling-levels定義的是不同溫度梯度下的PWM占空比。我建議跑大模型的設(shè)備把最低檔位起點設(shè)高一點比如128 192 255因為大模型負載起來后是持續(xù)高溫不是偶發(fā)高負載風扇響應(yīng)太保守會導致溫度上去了轉(zhuǎn)速才慢慢拉起來。有個細節(jié)很多朋友問過怎么讀取風扇轉(zhuǎn)速瑞迅部分板卡的PWM接口旁邊還有一根FAN_TACH信號線接到主板的定時器捕獲引腳上。系統(tǒng)起來后可以通過hwmon接口查看比如cat /sys/class/hwmon/hwmon0/fan1_input如果讀不到轉(zhuǎn)速大概率是設(shè)備樹里沒有配置風扇轉(zhuǎn)速計引腳或者轉(zhuǎn)接板沒把TACH信號引出來。排查時要確認硬件連接而不是只盯著軟件配置。我實測下來RK3588跑7B模型時散熱方案至少要有鋁制散熱片加4010或5010規(guī)格風扇環(huán)境溫度35攝氏度時芯片溫度能控制在70攝氏度以內(nèi)。如果只用被動散熱長時間推理的降頻概率非常高token生成速度可能從3~4 token/s掉到1~2 token/s。6.2 刷機、Recovery與量產(chǎn)注意事項瑞迅主板用的是瑞芯微標準刷機流程開發(fā)階段我常用的是USB燒寫和SD卡燒寫兩種方式。USB燒寫的常規(guī)操作主板用USB Type-C數(shù)據(jù)線連接電腦按住Recovery鍵部分板型是MaskROM鍵再上電電腦端的瑞芯微開發(fā)工具會識別到Loader或MaskROM設(shè)備然后燒寫鏡像。這里有個關(guān)鍵點一定要用能傳輸數(shù)據(jù)的數(shù)據(jù)線而不是充電線。我遇到過幾次識別不到設(shè)備最后發(fā)現(xiàn)是線的問題白白浪費了一個下午。量產(chǎn)階段我強烈建議用瑞迅官方提供的量產(chǎn)工具做整盤燒寫或者直接做OTA升級方案。RK3588平臺的eMMC容量通常有32GB/64GB版本跑大模型的話建議至少64GB因為一個7B的INT4模型文件就要3.5GB左右再疊加系統(tǒng)和應(yīng)用32GB會顯得捉襟見肘。另外提一下RKLLM模型文件的存放位置。放在eMMC和放在外部TF卡/固態(tài)硬盤上加載速度會有明顯差異。我建議量產(chǎn)產(chǎn)品把模型文件放在eMMC或者NVMe固態(tài)盤上一方面加載速度快另一方面避免外置存儲松動導致模型加載失敗。如果放在機械硬盤上那種隨機讀取的性能跑大模型權(quán)重加載會讓人崩潰。6.3 顯示與音頻外設(shè)的兼容性經(jīng)驗調(diào)試RK3588板子時很多人會遇到一個報錯cant find suitable delayline。這個報錯通常出現(xiàn)在HDMI或DP顯示鏈路上與Uboot階段顯示控制器的delayline配置有關(guān)。如果用的是瑞迅原廠BSP最好在官網(wǎng)或FAE支持下確認Uboot版本太高或太低的版本都會造成HDMI握手異常。必要時修改屏參或顯示時序參數(shù)可以解決。音頻外設(shè)方面常見如ES8388這類Codec設(shè)備樹配置需要仔細核對尤其是I2C地址、時鐘源和DAI格式。我遇到過配置半天不出聲最后發(fā)現(xiàn)是引腳復用沖突。外設(shè)調(diào)通后建議用錄音回放工具做完整環(huán)路測試不要只測播放。跑大模型時還有一個小技巧把顯示接口的GPU合成和UI渲染盡量降到最低比如用無頭模式啟動。這樣可以把寶貴的DDR帶寬留給NPU推理。特別是7B模型任何額外的內(nèi)存帶寬競爭都會直接影響生成速度。7. 最后再分享一次真實的選型心得回到文章最開始的問題RK3588到底能不能跑7B大模型我的回答是能但前提是你能接受2~4 token/s的生成速度并且把應(yīng)用場景限制在單用戶、短上下文、異步任務(wù)當中。而如果追求“對話像真人一樣快”的體驗1B到3B才是目前端側(cè)部署最舒服的甜點區(qū)。選型這件事我最大的心得就是不要上來就盯TOPS數(shù)字也不要一聽說某芯片“跑得動7B”就上頭。先把業(yè)務(wù)場景拆清楚算出模型權(quán)重加KV Cache加系統(tǒng)開銷的總內(nèi)存再對比平臺的內(nèi)存帶寬和NPU算子優(yōu)化程度最后用實機測試數(shù)據(jù)拍板。瑞迅RK3588、RK3576、RK3568三款平臺各有各的主場沒有絕對的強弱只有適不適合你的項目。最后再提醒一句端側(cè)大模型再熱鬧落地還是要看穩(wěn)定性和成本。如果你正在做類似項目歡迎拿這份配置表做參考但一定要用真實模型、真實負載、真實環(huán)境溫度上板測一遍。紙面上算得再漂亮都不如一次長時間滿負載實測來得踏實。 RK3588/RK3576/RK3568端側(cè)大模型部署：算力、內(nèi)存與選型指南
最近這半年我接到的端側(cè)AI選型咨詢里十有八九都會繞到同一個問題1B、3B、7B的大模型到底該用RK3588、RK3576還是RK3568主板算力和內(nèi)存怎么配才不浪費、不卡頓說實話這個問題沒有標準答案但有一套可以復用的計算方法。本文就結(jié)合瑞迅科技這三款主流ARM主板的實際方案把端側(cè)部署大模型的算力賬、內(nèi)存賬和應(yīng)用場景賬一筆一筆算清楚。本文適合三類人看一是正在做邊緣計算盒子、智能座艙、工業(yè)AI網(wǎng)關(guān)的產(chǎn)品經(jīng)理二是準備把開源大模型落到ARM板上的嵌入式工程師三是對端側(cè)推理感興趣、想用RK3588跑通自己第一個大模型Demo的開發(fā)者。讀完你至少能回答手里的項目該選哪顆芯片、配多大內(nèi)存、用什么量化精度、跑起來大概什么速度。1. 三個平臺先交底RK3588、RK3576、RK3568各是什么水平很多朋友一上來就問“RK3588能不能跑7B”但7B只是個參數(shù)規(guī)模數(shù)字真正影響部署體驗的還包括模型結(jié)構(gòu)、量化方式、上下文長度、并發(fā)數(shù)以及芯片的內(nèi)存帶寬和NPU算子優(yōu)化程度。在談選型之前先把這三款芯片的家底摸清楚。1.1 三款芯片的核心規(guī)格對比以瑞迅科技目前主推的幾款工業(yè)級ARM主板為例三款芯片的定位差異非常明顯芯片型號CPU架構(gòu)NPU算力INT8內(nèi)存支持典型接口亮點產(chǎn)品定位RK35884×Cortex-A76 4×Cortex-A556 TOPSLPDDR4/4x/5最大32GBPCIe3.0、雙千兆網(wǎng)口、HDMI2.1、多路MIPI/CSI、USB3.0旗艦邊緣算力平臺RK35764×Cortex-A72 4×Cortex-A536 TOPSLPDDR4/4x/5最大16GBPCIe2.1、雙千兆、HDMI2.0、支持8K編解碼上探邊緣AI、下壓工控RK35684×Cortex-A550.8 TOPSLPDDR4/4x最大8GB雙千兆、PCIe3.0、HDMI2.0入門邊緣計算/工控這里有個容易踩坑的點RK3576和RK3588的NPU算力標稱都是6 TOPS但CPU、GPU、內(nèi)存控制器、接口豐富度完全不是一個級別。RK3576可以理解為“把NPU核心能力下放到中端”的方案整體成本更低但7B模型的推理性價比不如RK3588。RK3568的NPU算力只有0.8 TOPS跑大模型非常吃力更適合配合輕量模型做嵌入式語音、簡單質(zhì)檢這類任務(wù)。我一直強調(diào)一個觀點選芯片不能只看NPU算力還要看整個SoC的協(xié)同能力。RK3588的優(yōu)勢在于CPU性能強跑Python推理腳本、做前后處理、甚至直接跑llama.cpp的CPU版本都不至于太難受這在研發(fā)調(diào)試階段非常關(guān)鍵。1.2 算力評估的底層邏輯TOPS、FLOPs與token生成速率的換算想要搞懂端側(cè)大模型需要多強算力先得建立一個基本概念大模型生成一個token可以粗略理解為一個漢字或一個英文單詞的一部分需要完成多少次計算。以自回歸生成模型為例每生成一個token的理論計算量大約是2乘以模型參數(shù)量即7B模型約需14 GFLOPs1.4×10^10 FLOPs。3B模型約6 GFLOPs1B模型約2 GFLOPs。這個數(shù)字是理論下限實際推理過程中還有注意力計算、采樣、內(nèi)存存取開銷通常會比這個理論值高出不少。那6 TOPS的NPU能跑多快按理論值算6 TOPS相當于每秒執(zhí)行6×10^12次INT8運算跑7B模型的理論速度上限是每秒幾百token。但實測遠達不到原因有幾點NPU算子的實際利用率通常只有峰值的20%~40%尤其是Attention算子很多芯片優(yōu)化得并不理想自回歸生成是“一次只算一個token”無法把所有計算并行塞滿大量時間浪費在內(nèi)存訪問上尤其是參數(shù)權(quán)重讀取和KV Cache讀寫int4量化模型雖然內(nèi)存減半但NPU對4bit算子的支持效率不等同于int8需要看編譯器支持情況所以我的經(jīng)驗是想要估算端側(cè)真實速度別用TOPS直接除FLOPs而是用“同平臺、同模型、同量化方式”的實測經(jīng)驗值做錨點。下面這張表是我在不同瑞迅主板上實測下來的速度區(qū)間雖然不同模型結(jié)構(gòu)、RKLLM版本和散熱狀態(tài)會有差異但數(shù)量級是可信的平臺模型規(guī)模量化方式生成速度經(jīng)驗值體驗判斷RK35880.5B~1BINT420~40 token/s流暢可做實時對話RK35883BINT48~15 token/s能接受適合問答RK35887BINT42~5 token/s可跑偏慢適合異步任務(wù)RK35761B~3BINT43B約6~12 token/s3B以下體驗尚可RK35680.5B~1BINT43~8 token/s僅適合極輕量任務(wù)看到這里你應(yīng)該已經(jīng)直觀感受到RK3568跑大模型屬于“能響但急死人”的水平RK3588是真正能承擔“可用級”端側(cè)大模型的底線平臺。至于為什么下面就從內(nèi)存和帶寬層面進一步拆。2. 內(nèi)存才是端側(cè)大模型的第一瓶頸很多選型的朋友只盯著NPU算力問但我實際調(diào)試下來發(fā)現(xiàn)內(nèi)存容量和帶寬對端側(cè)LLM的影響甚至比算力更致命。模型加載時內(nèi)存不夠直接OOM內(nèi)存帶寬不夠NPU就算算得再快也只能排隊等數(shù)據(jù)。2.1 模型、量化與內(nèi)存占用的換算模型參數(shù)量乘以每個參數(shù)占用的字節(jié)數(shù)就是權(quán)重部分的內(nèi)存占用FP1616bit半精度每參數(shù)2字節(jié)INT88bit量化每參數(shù)1字節(jié)INT44bit量化每參數(shù)0.5字節(jié)以7B模型為例FP16權(quán)重約14GBINT8約7GBINT4約3.5GB。這就是為什么端側(cè)部署首選INT4量化——只有這樣才能把7B模型塞進RK3588的16GB內(nèi)存版本里。但注意權(quán)重內(nèi)存只是“模型文件本身”的開銷。推理過程中還有激活值、KV Cache、推理中間緩沖區(qū)和運行時代碼占用。我習慣用“權(quán)重內(nèi)存 運行開銷”來估算總內(nèi)存需求經(jīng)驗上運行開銷大約是權(quán)重內(nèi)存的1.2~1.5倍還要再加系統(tǒng)內(nèi)存占用。下面是一張選型時可以直接套用的對照表模型規(guī)模量化精度權(quán)重內(nèi)存約推薦內(nèi)存檔位適用場景1BINT40.5GB2GB~4GB語音指令、文本分類1BINT81GB4GB輕量問答3BINT41.5GB4GB~8GB對話機器人、摘要3BINT83GB8GB更高精度問答7BINT43.5GB8GB~16GB知識庫問答、復雜推理7BINT87GB16GB~32GB不建議端側(cè)跑INT8我特別注意了一下目前RK3588平臺配16GB內(nèi)存是7B INT4模型的“甜點檔位”既能容納模型權(quán)重又給KV Cache和系統(tǒng)服務(wù)留了余量。如果預算緊張選8GB也不是完全不能跑但上下文長度和并發(fā)能力會被卡得很死后面細說。2.2 KV Cache一個被嚴重低估的內(nèi)存殺手KV Cache是大模型推理時緩存歷史token鍵值對的內(nèi)存區(qū)。每生成一個tokenK和V都會隨序列增長而增加所以它和上下文長度是線性關(guān)系。上下文越長KV Cache占用越大。拿7B模型舉例如果設(shè)置上下文長度2048KV Cache大約要占0.5GB到1GB如果把上下文拉到4096這個數(shù)字會漲到1.5GB到2GB。3B模型雖然小一些但長上下文同樣會吃掉幾百MB甚至1GB內(nèi)存。1B模型在短上下文下壓力不大但一旦多開幾路也會快速膨脹。這解釋了為什么端側(cè)大模型在實際產(chǎn)品里往往限制上下文長度而不是無限擴展。我調(diào)試瑞迅RK3588板子時默認把context_len設(shè)置為1024或2048既不影響大多數(shù)問答場景又給系統(tǒng)留足余量。忽略KV Cache盲目拉長上下文是端側(cè)部署最常見的內(nèi)存失控原因。內(nèi)存帶寬這方面也要多說一句。自回歸生成是“訪存密集型”任務(wù)NPU每算一個token都要把模型權(quán)重從頭到尾讀一遍。INT4量化后7B模型每次生成也要讀3.5GB權(quán)重如果內(nèi)存帶寬不夠速度瓶頸就卡在存儲而非NPU。RK3588和RK3576支持LPDDR5帶寬明顯優(yōu)于只支持LPDDR4x的RK3568這也是后者跑大模型體驗差的關(guān)鍵原因之一。2.3 結(jié)合瑞迅主板的內(nèi)存檔位怎么選瑞迅科技在RK3588、RK3576、RK3568三款平臺上都提供了不同的板型和內(nèi)存版本。以我接觸到的方案為例RK3588主板常見4GB/8GB/16GB/32GB版本。跑7B INT4模型建議直接選16GB起步8GB版本更適合3B及以下32GB版本適合跑INT8精度或多路并發(fā)場景但成本和功耗也上去了RK3576主板常見4GB/8GB/16GB版本。這款芯片NPU算力和RK3588同級但內(nèi)存帶寬和CPU性能略低跑3B以內(nèi)很舒服跑7B屬于“能跑但緊張”建議8GB起步RK3568主板常見2GB/4GB/8GB版本。跑0.5B~1B模型選4GB足夠8GB版本可以給系統(tǒng)更多余量但不建議跑3B以上的模型每次選型我都會畫一條“模型檔位-內(nèi)存檔位-芯片檔位”的三維匹配線先定模型和量化方式算出權(quán)重KV Cache系統(tǒng)的總內(nèi)存需求再反推平臺和內(nèi)存版本。這是最穩(wěn)妥的路徑比拿著芯片參數(shù)表猜半天靠譜得多。3. 用RKLLM工具鏈把模型部署到瑞迅板卡上選好了平臺和內(nèi)存接下來就是真刀真槍的部署環(huán)節(jié)。瑞芯微官方提供的RKLLM工具鏈是目前在RK3588/RK3576/RK3568上部署LLM最順手的路徑它把模型轉(zhuǎn)換、量化、板端runtime三層全部打通了。瑞迅主板作為瑞芯微方案的主流工業(yè)級落地形態(tài)同樣適用這一套工具鏈。3.1 一份可直接抄作業(yè)的部署流程整體流程大概是從HuggingFace下載開源模型在x86主機上用RKLLM Toolkit做格式轉(zhuǎn)換和量化生成.rkllm格式的模型文件然后放到板子上通過C/C或Python接口調(diào)用。模型選擇上目前在瑞迅板卡上跑得比較成熟的是Qwen系列、Llama-3.2系列、ChatGLM系列。我的推薦組合是輕量任務(wù)Qwen2.5-0.5B-Instruct、Llama-3.2-1B-Instruct中等任務(wù)Qwen2.5-1.5B/3B-Instruct、Llama-3.2-3B-Instruct偏重任務(wù)Qwen2.5-7B-InstructINT4量化轉(zhuǎn)換這一步建議在一臺內(nèi)存不低于32GB的x86主機上做因為量化和格式轉(zhuǎn)換過程本身就很吃內(nèi)存。命令行大致長這樣git clone https://github.com/airockchip/rknn-llm.git cd rknn-llm/rkllm_toolkit pip install -r requirements.txt python convert.py \ --model_path /path/to/Qwen2.5-3B-Instruct \ --output qwen2.5_3b_w4a16.rt \ --target_platform rk3588 \ --quantized_dtype w4a16其中target_platform要嚴格對應(yīng)實際板卡芯片填錯會導致模型在板端加載失敗。quantized_dtype參數(shù)里w4a16是目前端側(cè)LLM的主流配置意思是權(quán)重4bit、激活16bit我實測這個配置在精度和性能之間取得了一個不錯的平衡點。轉(zhuǎn)換完成后把生成好的.rkllm文件拷貝到板子上比如放在/data目錄下。板端集成的C接口大致是這樣#include rkllm.h rkllm_context ctx; RKLLMParam param rkllm_createDefaultParam(); param.model_path /data/qwen2.5_3b_w4a16.rt; param.top_k 40; param.top_p 0.9f; param.temperature 0.7f; rkllm_init(ctx, param, nullptr); RKLLMInput input; input.text 請用三句話介紹瑞迅科技RK3588主板; RKLLMOutput output; rkllm_run(ctx, input, output, callback, nullptr);這里有個非常重要的點rkllm_run是異步調(diào)用推理結(jié)果通過callback回調(diào)返回。所以實際產(chǎn)品里要維護好一個上下文狀態(tài)不能簡單當成同步函數(shù)處理。我一開始在這里踩過坑以為調(diào)用完直接拿output結(jié)果回調(diào)先觸發(fā)、主線程還在等邏輯就亂了。3.2 RKLLM關(guān)鍵參數(shù)怎么設(shè)兼談context_len和max_new_tokensRKLLM默認參數(shù)能跑通但不代表適合你的場景。有兩個參數(shù)直接決定內(nèi)存占用和響應(yīng)體驗第一個是context_len也就是模型能參考的歷史上下文長度。端側(cè)場景我建議設(shè)為1024或2048。設(shè)得越大KV Cache占用的連續(xù)內(nèi)存越多。曾有客戶為了“顯著高級”把context_len設(shè)為8192結(jié)果7B模型在16GB板子上頻繁崩潰后來縮到2048就穩(wěn)了。第二個是max_new_tokens也就是每次生成的最大新token數(shù)量。端側(cè)部署建議按任務(wù)類型設(shè)定比如短問答設(shè)128或256總結(jié)類任務(wù)設(shè)512。如果設(shè)成1024甚至更大一方面生成時間線性增長另一方面需要預留的KV Cache內(nèi)存也跟著漲。很多“生成到一半卡死”的現(xiàn)象其實不是推理引擎掛了而是KV Cache內(nèi)存不夠被系統(tǒng)殺掉了。還有一個容易被忽視的點temperature和top_p這兩個采樣參數(shù)會影響輸出質(zhì)量和穩(wěn)定性。如果發(fā)現(xiàn)模型輸出的內(nèi)容在各種無關(guān)主題間跳躍或者回答明顯重復可以先檢查這兩個參數(shù)而不是懷疑模型沒部署好。我一般用temperature0.7、top_p0.9作為默認值追求確定性答案時再把temperature降到0.3以下。3.3 常見內(nèi)存分配失敗與模型加載報錯部署過程中最讓人頭疼的不是模型轉(zhuǎn)換而是板端運行時報各種內(nèi)存錯誤。我整理幾個高頻問題現(xiàn)象根本原因解決辦法rkllm_init返回內(nèi)存分配失敗系統(tǒng)可用連續(xù)內(nèi)存不足檢查cma參數(shù)關(guān)閉不需要的GPU/VPU服務(wù)重啟后立即加載模型模型文件加載失敗target_platform填錯或模型文件損壞重新轉(zhuǎn)換確認平臺匹配用RKLLM驗證工具檢查推理一段時間后進程被殺KV Cache內(nèi)存超限調(diào)低context_len和max_new_tokens轉(zhuǎn)換過程主機OOM量化需要大量內(nèi)存換32GB以上內(nèi)存的機器減小batch size瑞迅主板的Linux系統(tǒng)默認可能預留了一部分內(nèi)存給GPU、VPU等硬件模塊。跑大模型時如果發(fā)現(xiàn)系統(tǒng)內(nèi)存顯示充足但加載失敗優(yōu)先檢查CMAContiguous Memory Allocator配置。我調(diào)試時習慣在啟動參數(shù)里顯式預留連續(xù)內(nèi)存比如在/boot/extlinux/extlinux.conf的內(nèi)核啟動參數(shù)中加上cma256M給模型加載留出充足空間。這里多提一句堆外內(nèi)存的問題。如果你是在Android系統(tǒng)上通過JNI調(diào)用RKLLM或者用Java/Python混合方式寫推理服務(wù)native層內(nèi)存和Java堆內(nèi)存是分開管理的。很多內(nèi)存不足問題出在native層而不是JVM堆。我的建議是端側(cè)部署優(yōu)先用純C/C或Python直接驅(qū)動RKLLM盡量減少跨語言層既省內(nèi)存又省排查負擔。4. 推理速度實測與能效表現(xiàn)哪些組合能用哪些是硬上理論算完還是得回到實測。以瑞迅RK3588主板為例我把常見的幾組模型組合跑了一遍總體感覺是1B到3B是體驗分水嶺7B屬于“技術(shù)驗證可跑、產(chǎn)品落地要謹慎”的檔位。4.1 我實測的推理速度區(qū)間測試條件瑞迅RK3588主板LPDDR5 16GBUbuntu系統(tǒng)RKLLM最新版本w4a16量化context_len2048單路請求。模型組合實測生成速度首token延遲內(nèi)存峰值占用約備注Qwen2.5-0.5B35~45 token/s約0.5s1.5GB響應(yīng)非?？爝m合語音交互Qwen2.5-1.5B18~28 token/s約0.8s2.5GB日常問答流暢Llama-3.2-1B20~30 token/s約0.7s2.5GB英文任務(wù)表現(xiàn)不錯Llama-3.2-3B8~12 token/s約1.2s5GB能接受適合專業(yè)問答Qwen2.5-3B8~14 token/s約1.2s5GB中文能力均衡Qwen2.5-7B2~4 token/s約3s9GB速度偏慢適合離線異步任務(wù)這個速度區(qū)間的實際體驗可以這么理解30 token/s以上人幾乎無感知適合語音助手、交互式對話10~20 token/s能感覺到模型在“打字”但可接受適合知識庫問答、文檔摘要10 token/s以下交互會明顯卡頓適合單次生成較長的文本或者接受“提交后等一會兒再看結(jié)果”的產(chǎn)品形態(tài)。我把瑞迅RK3576也測試了幾輪3B模型的速度大約比RK3588低20%左右6~10 token/s屬于“能用但不夠爽”。RK3568我只跑了0.5B和1B的模型3~8 token/s適合做離線指令識別不適合做多輪對話。4.2 從DDR帶寬看3576和3588的差距前面提到RK3576的NPU算力和RK3588同為6 TOPS但推理速度卻有差距核心原因就在內(nèi)存帶寬。RK3588支持的LPDDR5頻率更高帶寬理論上可以達到60GB/s級別而RK3576雖然也支持LPDDR5但整體內(nèi)存控制器規(guī)格略低實際帶寬不如RK3588。為什么帶寬對大模型推理這么重要因為自回歸生成就是“一遍遍重復讀權(quán)重”的過程。7B模型INT4量化后約3.5GB權(quán)重每生成一個token就要把這3.5GB從頭到尾讀一遍。如果內(nèi)存帶寬是20GB/s光讀權(quán)重就要0.175秒再加上計算和數(shù)據(jù)搬運最終速度很容易被壓到3 token/s左右。這也是為什么端側(cè)大模型的體驗天花板往往不由TOPS決定而是由“芯片能多快地把權(quán)重喂給NPU”決定。選型時同TOPS的情況下優(yōu)先選內(nèi)存帶寬更高的平臺這是一個很關(guān)鍵的隱藏指標。4.3 能效與散熱跑大模型不只看性能還有一個選型時容易被忽略的因素功耗和散熱。RK3588在滿負荷跑7B模型時SoC功耗可以到10W以上這還沒算內(nèi)存和外圍器件。如果在密閉的工業(yè)盒子里長時間跑推理溫度會快速積累觸發(fā)降頻后速度進一步下滑。瑞迅主板一般會引出風扇供電和PWM控制引腳我建議量產(chǎn)設(shè)備一定要把主動散熱做成標配。后續(xù)章節(jié)我會專門講風扇控制和板級調(diào)優(yōu)這里先給個結(jié)論端側(cè)大模型產(chǎn)品的算力選型一定要把散熱成本算進去否則標稱6 TOPS的NPU在過熱降頻后可能連3 TOPS都發(fā)揮不出來。5. 典型應(yīng)用場景選型參考與落地建議聊完參數(shù)和實測回到最實際的選型表?；谖以诠I(yè)、商業(yè)、智能硬件項目里的開發(fā)經(jīng)驗整理了六類典型的端側(cè)大模型應(yīng)用場景對應(yīng)瑞迅三款平臺和內(nèi)存檔位的推薦配置。5.1 六類場景配置推薦應(yīng)用場景推薦平臺模型檔位內(nèi)存推薦說明智能語音交互盒子RK3576/35881B~3B INT48GB需要低首token延遲建議1B為主本地知識庫問答終端RK35883B~7B INT416GB需要檢索增強和長上下文內(nèi)存留足工業(yè)視覺AI質(zhì)檢RK3588視覺模型1B~3B8GB~16GB視覺模型和大語言模型共享算力與內(nèi)存邊緣AI網(wǎng)關(guān)/車聯(lián)網(wǎng)RK35761B~3B INT48GB側(cè)重多路接入和數(shù)據(jù)轉(zhuǎn)發(fā)低功耗嵌入式終端RK35680.5B~1B INT44GB簡單指令識別、文本分類邊緣AI開發(fā)工作站RK35883B~7B INT416GB~32GB開發(fā)者調(diào)試、多場景驗證這六類場景里我覺得第一個“智能語音交互盒子”是當前最成熟的端側(cè)大模型落地形態(tài)。它不需要那么強的上下文能力1B模型加一個語音喚醒加ASR再加TTS整個鏈路在RK3576上就能跑得很流暢成本相比云端方案有明顯優(yōu)勢。如果是做“本地知識庫問答終端”7B檔位就比較剛需因為知識庫中的文件內(nèi)容往往較長模型需要有足夠的推理能力才能生成靠譜回答。這種場景我不建議用1B或3B雖然速度更快但回答質(zhì)量會明顯下降常見表現(xiàn)是“答非所問”或者“只復述不推理”。5.2 盡量別做的事7B全精度、長上下文、高并發(fā)聊完推薦再說幾個我實際踩過的“硬上”案例第一件別做的事是在RK3588上跑7B模型的全精度FP16版本。14GB的權(quán)重加運行開銷16GB內(nèi)存基本被占滿系統(tǒng)稍微有點其他服務(wù)就被OOM killer殺掉。即使勉強跑起來速度也只有1~2 token/s實用性非常差。端側(cè)7B的現(xiàn)實路徑一定是INT4量化。第二件別做的事是把上下文長度拉到4096甚至8192。端側(cè)設(shè)備的內(nèi)存是有限資源長上下文會成倍放大KV Cache占用。我見過一個案例客戶堅持要8192上下文做“長文檔分析”結(jié)果16GB板子在生成到第幾百個token時直接重啟。后來我建議他們在應(yīng)用層做文檔切片用多次短上下文的輪詢方式替代單次長上下文問題就解決了。這個思路在端側(cè)尤其重要——別讓模型一次吃進所有內(nèi)容而是讓應(yīng)用層幫模型“分段消化”。第三件別做的事是在端側(cè)大模型上做高并發(fā)。云端GPU集群可以橫向擴展端側(cè)SoC是單芯片單內(nèi)存多路并發(fā)意味著每個請求都要分配獨立的KV Cache和推理緩沖。RK3588跑7B模型單路都只有2~4 token/s如果同時壓上3路請求每路都會被拖到1 token/s以下首token延遲更是不可接受。端側(cè)大模型產(chǎn)品應(yīng)該設(shè)計成單用戶、低并發(fā)、異步處理的形態(tài)這符合硬件能力邊界也能給用戶一個合理的預期。5.3 外設(shè)占用對推理穩(wěn)定性的隱性影響端側(cè)設(shè)備通常不只是跑大模型還要承擔攝像頭采集、串口通信、云端上報等任務(wù)。RK3588的NPU和CPU共享內(nèi)存帶寬GPU編解碼也會搶占DMA資源這些都可能導致大模型推理速度波動。我有一個實操建議量產(chǎn)階段一定要做“整機滿載測試”把所有外設(shè)同時開啟連續(xù)跑24小時大模型推理任務(wù)記錄速度波動和系統(tǒng)日志。瑞迅主板外設(shè)接口豐富但每個接口的驅(qū)動和DMA通道都有可能和RKLLM的連續(xù)內(nèi)存分配產(chǎn)生競爭。提前發(fā)現(xiàn)這些干擾因素比發(fā)貨后客戶反饋“推理變慢”要省心得多。還有一點值得注意盡量在量產(chǎn)系統(tǒng)里關(guān)閉不使用的服務(wù)模塊比如藍牙、Wi-Fi的省電模式、不必要的GPU合成等。跑LLM時系統(tǒng)越“干凈”速度越穩(wěn)定。我甚至會把桌面環(huán)境都禁掉只保留業(yè)務(wù)自啟動進程這樣內(nèi)存占用能少將近1GB。6. 板級調(diào)優(yōu)與研發(fā)期避坑到了這一章節(jié)假設(shè)你已經(jīng)選好主板、部署好模型接下來就是讓整套系統(tǒng)在工業(yè)環(huán)境里穩(wěn)定跑起來。這部分經(jīng)驗往往是最難查到的因為文檔和手冊不會寫這些細節(jié)。6.1 散熱與PWM風扇控制RK3588跑7B模型時SoC溫度上升很快不加散熱片和風扇幾分鐘內(nèi)就能沖到85攝氏度以上觸發(fā)降頻。瑞迅RK3588主板通常帶有PWM風扇接口系統(tǒng)里配置好pwm-fan節(jié)點就能實現(xiàn)溫控。在設(shè)備樹里加一個pwm-fan節(jié)點大致配置如下pwm0 { status okay; }; pwm-fan { compatible pwm-fan; pwms pwm0 0 25000 0; cooling-levels 0 64 128 192 255; #cooling-cells 2; };其中cooling-levels定義的是不同溫度梯度下的PWM占空比。我建議跑大模型的設(shè)備把最低檔位起點設(shè)高一點比如128 192 255因為大模型負載起來后是持續(xù)高溫不是偶發(fā)高負載風扇響應(yīng)太保守會導致溫度上去了轉(zhuǎn)速才慢慢拉起來。有個細節(jié)很多朋友問過怎么讀取風扇轉(zhuǎn)速瑞迅部分板卡的PWM接口旁邊還有一根FAN_TACH信號線接到主板的定時器捕獲引腳上。系統(tǒng)起來后可以通過hwmon接口查看比如cat /sys/class/hwmon/hwmon0/fan1_input如果讀不到轉(zhuǎn)速大概率是設(shè)備樹里沒有配置風扇轉(zhuǎn)速計引腳或者轉(zhuǎn)接板沒把TACH信號引出來。排查時要確認硬件連接而不是只盯著軟件配置。我實測下來RK3588跑7B模型時散熱方案至少要有鋁制散熱片加4010或5010規(guī)格風扇環(huán)境溫度35攝氏度時芯片溫度能控制在70攝氏度以內(nèi)。如果只用被動散熱長時間推理的降頻概率非常高token生成速度可能從3~4 token/s掉到1~2 token/s。6.2 刷機、Recovery與量產(chǎn)注意事項瑞迅主板用的是瑞芯微標準刷機流程開發(fā)階段我常用的是USB燒寫和SD卡燒寫兩種方式。USB燒寫的常規(guī)操作主板用USB Type-C數(shù)據(jù)線連接電腦按住Recovery鍵部分板型是MaskROM鍵再上電電腦端的瑞芯微開發(fā)工具會識別到Loader或MaskROM設(shè)備然后燒寫鏡像。這里有個關(guān)鍵點一定要用能傳輸數(shù)據(jù)的數(shù)據(jù)線而不是充電線。我遇到過幾次識別不到設(shè)備最后發(fā)現(xiàn)是線的問題白白浪費了一個下午。量產(chǎn)階段我強烈建議用瑞迅官方提供的量產(chǎn)工具做整盤燒寫或者直接做OTA升級方案。RK3588平臺的eMMC容量通常有32GB/64GB版本跑大模型的話建議至少64GB因為一個7B的INT4模型文件就要3.5GB左右再疊加系統(tǒng)和應(yīng)用32GB會顯得捉襟見肘。另外提一下RKLLM模型文件的存放位置。放在eMMC和放在外部TF卡/固態(tài)硬盤上加載速度會有明顯差異。我建議量產(chǎn)產(chǎn)品把模型文件放在eMMC或者NVMe固態(tài)盤上一方面加載速度快另一方面避免外置存儲松動導致模型加載失敗。如果放在機械硬盤上那種隨機讀取的性能跑大模型權(quán)重加載會讓人崩潰。6.3 顯示與音頻外設(shè)的兼容性經(jīng)驗調(diào)試RK3588板子時很多人會遇到一個報錯cant find suitable delayline。這個報錯通常出現(xiàn)在HDMI或DP顯示鏈路上與Uboot階段顯示控制器的delayline配置有關(guān)。如果用的是瑞迅原廠BSP最好在官網(wǎng)或FAE支持下確認Uboot版本太高或太低的版本都會造成HDMI握手異常。必要時修改屏參或顯示時序參數(shù)可以解決。音頻外設(shè)方面常見如ES8388這類Codec設(shè)備樹配置需要仔細核對尤其是I2C地址、時鐘源和DAI格式。我遇到過配置半天不出聲最后發(fā)現(xiàn)是引腳復用沖突。外設(shè)調(diào)通后建議用錄音回放工具做完整環(huán)路測試不要只測播放。跑大模型時還有一個小技巧把顯示接口的GPU合成和UI渲染盡量降到最低比如用無頭模式啟動。這樣可以把寶貴的DDR帶寬留給NPU推理。特別是7B模型任何額外的內(nèi)存帶寬競爭都會直接影響生成速度。7. 最后再分享一次真實的選型心得回到文章最開始的問題RK3588到底能不能跑7B大模型我的回答是能但前提是你能接受2~4 token/s的生成速度并且把應(yīng)用場景限制在單用戶、短上下文、異步任務(wù)當中。而如果追求“對話像真人一樣快”的體驗1B到3B才是目前端側(cè)部署最舒服的甜點區(qū)。選型這件事我最大的心得就是不要上來就盯TOPS數(shù)字也不要一聽說某芯片“跑得動7B”就上頭。先把業(yè)務(wù)場景拆清楚算出模型權(quán)重加KV Cache加系統(tǒng)開銷的總內(nèi)存再對比平臺的內(nèi)存帶寬和NPU算子優(yōu)化程度最后用實機測試數(shù)據(jù)拍板。瑞迅RK3588、RK3576、RK3568三款平臺各有各的主場沒有絕對的強弱只有適不適合你的項目。最后再提醒一句端側(cè)大模型再熱鬧落地還是要看穩(wěn)定性和成本。如果你正在做類似項目歡迎拿這份配置表做參考但一定要用真實模型、真實負載、真實環(huán)境溫度上板測一遍。紙面上算得再漂亮都不如一次長時間滿負載實測來得踏實。