1. 一個反直覺的工程問題模型比內(nèi)存大為什么還能跑起來17.66 GB 的模型文件放在一塊只有 16 GB 物理內(nèi)存的 RK3588 開發(fā)板上第一次聽到這個組合很多人的第一反應是這不可能。畢竟模型文件本身比內(nèi)存還大加載都加載不進去更別提推理了。但實際工程中這個場景不僅能跑通還能跑得相當穩(wěn)定。核心原因就藏在標題里那個不起眼的關鍵詞——mmap。先把結(jié)論擺在前面模型能不能跑起來從來不取決于模型文件有多大而取決于同一時刻真正需要駐留在物理內(nèi)存里的數(shù)據(jù)有多少。這兩件事在傳統(tǒng)read()加載模式下是一回事但在mmap模式下完全是兩碼事。理解了這個區(qū)別你就理解了整個方案的地基。這篇文章面向的是正在做邊緣端模型部署的工程師尤其是手上拿著 RK3588、RK3576 這類板子想把大模型或者大視覺模型塞進去的人。我會把整個思路拆開講為什么傳統(tǒng)加載方式必然失敗、mmap 到底做了什么、RK3588 這套硬件和軟件棧上有哪些坑、怎么一步步把 17.66 GB 的模型跑在 16 GB 內(nèi)存上以及我在實測中踩過的那些坑。內(nèi)容偏實操代碼和命令都可以直接抄。需要提前說明的是本文討論的是內(nèi)存映射加載這一通用工程手段不涉及任何特定網(wǎng)絡工具或敏感內(nèi)容純粹是嵌入式 AI 部署領域的技術(shù)分享。2. 先搞清楚為什么模型比內(nèi)存大這件事本身不是問題2.1 傳統(tǒng)加載方式的致命誤區(qū)大部分人第一次部署模型用的都是最直覺的方式把整個模型文件讀進內(nèi)存然后反序列化。偽代碼大概長這樣with open(model.bin, rb) as f: data f.read() # 17.66 GB 全部進內(nèi)存 model deserialize(data) # 再復制一份峰值可能 35 GB這條路在 16 GB 的板子上必然失敗原因有兩層。第一層是物理內(nèi)存根本裝不下f.read()會直接觸發(fā) OOM Killer進程被系統(tǒng)干掉。第二層更隱蔽即使你用了流式讀取反序列化過程本身往往還需要一份額外的內(nèi)存副本峰值內(nèi)存可能是模型大小的 1.5 到 2 倍。所以真正的問題不是17.66 大于 16而是峰值需求遠大于 16。這里有個很多人忽略的點模型文件里絕大部分數(shù)據(jù)是權(quán)重而權(quán)重在推理時是只讀的。只讀數(shù)據(jù)有一個天然優(yōu)勢——它可以被多個進程共享也可以按需從磁盤加載用完就丟。傳統(tǒng)read()方式把這個優(yōu)勢徹底浪費了它把只讀數(shù)據(jù)強行變成了每個進程私有的、必須常駐的內(nèi)存副本。2.2 mmap 到底做了什么mmapmemory map內(nèi)存映射做的事情用一句話概括把文件的一段虛擬地址空間直接映射到進程地址空間讓讀寫文件像讀寫內(nèi)存一樣但數(shù)據(jù)并不立即全部加載。打個生活化的比方。傳統(tǒng)read()像是你要看一本 1000 頁的書必須先把整本書復印一份放到自己桌上才能開始讀。而mmap像是圖書館給你辦了一張借書證書還在書架上你想看第幾頁就去翻第幾頁看完放回去桌上永遠只放著當前正在看的那幾頁。具體到操作系統(tǒng)層面mmap建立映射后進程拿到一段虛擬地址。當你訪問某個地址時如果對應的物理頁不在內(nèi)存里CPU 會觸發(fā)一個缺頁異常page fault內(nèi)核這時候才去磁盤把那一頁讀進來掛到頁表上然后重新執(zhí)行那條指令。這個過程對應用程序完全透明。關鍵點在于物理內(nèi)存里只需要裝下當前活躍的頁而不是整個文件。對于 17.66 GB 的模型如果推理時同時活躍的權(quán)重只有 3 到 4 GB那么物理內(nèi)存占用就穩(wěn)定在這個量級剩下的 13 GB 權(quán)重安安靜靜躺在磁盤上需要哪頁換哪頁。2.3 為什么這個方案在 RK3588 上特別合適RK3588 的典型配置是 4 GB / 8 GB / 16 GB LPDDR4 或 LPDDR5CPU 是 4 核 A76 4 核 A55 的大小核架構(gòu)NPU 算力 6 TOPS。這塊板子的定位是邊緣計算存儲通常是 eMMC 或者外掛 NVMe SSD。這里有個硬件層面的現(xiàn)實eMMC 的隨機讀性能其實不差順序讀能到 200 到 300 MB/s隨機 4K 讀雖然弱一些但對于 mmap 的按頁加載來說只要頁命中率夠高實際體驗是可以接受的。如果板子上掛了 NVMe那更是綽綽有余隨機讀能到幾十萬 IOPSmmap 的缺頁開銷幾乎可以忽略。所以 RK3588 這套組合天然適合 mmap 方案內(nèi)存不大但夠用存儲夠快NPU 和 CPU 都能吃這套加載方式。這也是為什么最近 RK3588 部署大模型、部署 YOLOv8、跑視覺 SLAM 的討論里mmap 出現(xiàn)的頻率越來越高。3. 核心機制拆解mmap 加載模型的完整鏈路3.1 從文件到虛擬地址映射是怎么建立的先看最基礎的映射調(diào)用。在 C/C 里核心就是一行mmapint fd open(model.bin, O_RDONLY); void *addr mmap(NULL, file_size, PROT_READ, MAP_PRIVATE, fd, 0);參數(shù)逐個解釋因為每一個都影響最終行為NULL讓內(nèi)核自己選一個合適的虛擬地址起始點通常不用手動指定。file_size映射長度一般就是文件大小。注意必須是頁大小通常 4 KB的整數(shù)倍內(nèi)核會自動向上對齊。PROT_READ只讀映射。模型權(quán)重只讀用PROT_READ就夠了不要給PROT_WRITE否則會觸發(fā)寫時復制白白浪費內(nèi)存。MAP_PRIVATE私有映射。寫操作不會回寫文件讀操作共享物理頁。對于只讀場景MAP_PRIVATE和MAP_SHARED在內(nèi)存占用上差別不大但MAP_PRIVATE語義更清晰。fd文件描述符映射建立后其實就可以close(fd)了映射本身會持有文件引用。0偏移量從文件頭開始映射。映射建立后addr指向的這段虛擬內(nèi)存讀起來和普通內(nèi)存一模一樣。你addr[0]讀第一個字節(jié)內(nèi)核就去磁盤讀第一頁你addr[1000000]讀第一百萬個字節(jié)內(nèi)核就去讀對應的那一頁。整個過程你完全不用管。3.2 缺頁異常mmap 的按需加載是怎么實現(xiàn)的這是整個方案最核心的機制值得單獨講清楚。當進程訪問一個 mmap 區(qū)域的虛擬地址時CPU 的 MMU 會去查頁表。如果這個虛擬頁還沒有對應的物理頁MMU 觸發(fā)缺頁異常控制權(quán)交給內(nèi)核的缺頁處理程序。內(nèi)核做幾件事判斷這個地址屬于哪個映射區(qū)域VMAvirtual memory area。計算對應的文件偏移量。在 page cache 里找這一頁。如果找到了直接把物理頁映射到進程頁表這叫minor fault很快。如果 page cache 里沒有發(fā)起磁盤 IO 把這一頁讀進來這叫major fault慢一些取決于存儲速度。更新頁表返回用戶態(tài)重新執(zhí)行剛才那條指令。這里有個非常重要的概念page cache。所有通過 mmap 讀進來的頁都放在內(nèi)核的 page cache 里而不是進程私有的內(nèi)存。這意味著兩件事第一多個進程映射同一個文件物理頁是共享的內(nèi)存只占一份第二page cache 在內(nèi)存緊張時可以被回收回收后下次訪問再重新從磁盤讀。對于 17.66 GB 的模型page cache 不可能全裝下所以內(nèi)核會不斷地換入換出。但只要你的訪問模式有局部性——也就是推理時反復訪問的是同一批權(quán)重——那么活躍頁會穩(wěn)定駐留換入換出頻率很低性能就穩(wěn)。3.3 為什么活躍頁遠小于模型總大小這是整個方案能成立的物理基礎必須講透。一個 17.66 GB 的模型假設是 Transformer 架構(gòu)權(quán)重分布大概是這樣的embedding 層可能占幾個 GB幾十層 transformer block 每層幾百 MB最后的輸出層又是幾個 GB。推理時每一層是順序執(zhí)行的算完第 1 層才進第 2 層算完第 2 層才進第 3 層。這意味著同一時刻真正需要駐留內(nèi)存的只有當前正在計算的那一層加上少量跨層共享的數(shù)據(jù)。如果單層權(quán)重是 500 MB那么活躍集可能只有 1 到 2 GB加上 KV cache、激活值、框架本身的開銷總物理內(nèi)存占用控制在 8 到 12 GB 是完全可行的。注意這個結(jié)論成立的前提是推理框架支持逐層加載、逐層釋放的訪問模式。如果框架一上來就把所有層都 touch 一遍那 mmap 的優(yōu)勢就沒了會退化成全量加載。3.4 mmap 與 RKNN 的關系RK3588 上跑模型繞不開 RKNN。RKNN 是瑞芯微的 NPU 推理框架模型需要先轉(zhuǎn)成.rknn格式。這里有個現(xiàn)實問題RKNN 原生對 mmap 的支持并不完整。RKNN 的模型加載接口rknn_init通常接受一個內(nèi)存指針或者文件路徑。如果你傳文件路徑框架內(nèi)部怎么加載你控制不了如果你傳內(nèi)存指針那就得自己先把模型讀進內(nèi)存又回到了老問題。所以實際工程中有兩條路路線 A如果模型是給 NPU 跑的盡量用 RKNN 的流式加載能力或者把大模型拆成多個小.rknn文件逐個加載逐個推理。這條路受框架限制較多。路線 B如果模型是給 CPU 跑的比如一些大語言模型、Transformer 類模型那 mmap 就完全可控自己管理映射和訪問即可。這也是標題場景最可能的情況——17.66 GB 這種體量多半是 CPU 推理的大模型。我實測下來路線 B 的靈活性和可控性都更好下面主要按這條路展開。4. 實操把 17.66 GB 模型跑在 16 GB 板子上的完整步驟4.1 環(huán)境準備與前置檢查動手之前先把板子的底子摸清楚。以下命令在 RK3588 的 Ubuntu 系統(tǒng)上都能直接跑# 看物理內(nèi)存總量 free -h # 看可用存儲和文件系統(tǒng)類型 df -h mount | grep -E mmc|nvme # 看內(nèi)核版本mmap 行為在不同內(nèi)核上有差異 uname -a # 看 page cache 相關參數(shù) cat /proc/sys/vm/swappiness cat /proc/sys/vm/vfs_cache_pressure幾個關鍵檢查點存儲類型如果是 eMMC做好隨機讀性能一般的心理準備如果是 NVMe基本無壓力。用fio或者簡單的dd測一下隨機讀。文件系統(tǒng)ext4 對 mmap 支持最好f2fs 在閃存上表現(xiàn)也不錯。避免用一些對 mmap 支持不完整的網(wǎng)絡文件系統(tǒng)。內(nèi)核版本建議 5.10 以上RK3588 的官方 BSP 一般在這個版本。老內(nèi)核的 page cache 回收策略可能更激進導致頻繁換入換出。提示如果板子內(nèi)存是 16 GB但系統(tǒng)本身、桌面環(huán)境、其他服務已經(jīng)吃掉幾個 GB實際可用可能只有 12 GB 左右。建議用最小化系統(tǒng)關掉不必要的服務把可用內(nèi)存盡量留出來。4.2 模型文件的預處理mmap 對文件本身有要求預處理做得好后面少踩很多坑。第一文件要連續(xù)存放。如果模型文件在磁盤上是碎片化的mmap 的缺頁會變成隨機讀性能大打折扣?？梢杂胒ilefrag檢查碎片情況filefrag -v model.bin如果碎片很多最簡單的辦法是復制一份到新文件讓文件系統(tǒng)重新分配連續(xù)空間cp model.bin model_defrag.bin第二考慮對齊。mmap 的偏移量必須是頁大小的整數(shù)倍。如果你的模型文件內(nèi)部有自定義的段結(jié)構(gòu)確保每個段的起始偏移是 4 KB 對齊的這樣每個段可以獨立映射訪問更高效。第三如果模型支持分片優(yōu)先分片。把 17.66 GB 拆成若干個 1 到 2 GB 的分片文件每個分片獨立 mmap。這樣做的好處是page cache 的回收粒度更細活躍分片更容易常駐不活躍的分片可以整塊被回收。4.3 核心加載代碼從 mmap 到可用模型下面是一段可以直接參考的 C 代碼骨架展示如何用 mmap 加載模型并按需訪問#include stdio.h #include stdlib.h #include fcntl.h #include sys/mman.h #include sys/stat.h #include unistd.h typedef struct { void *addr; size_t size; int fd; } MappedModel; MappedModel* model_map(const char *path) { MappedModel *m malloc(sizeof(MappedModel)); m-fd open(path, O_RDONLY); if (m-fd 0) { perror(open); return NULL; } struct stat st; fstat(m-fd, st); m-size st.st_size; m-addr mmap(NULL, m-size, PROT_READ, MAP_PRIVATE, m-fd, 0); if (m-addr MAP_FAILED) { perror(mmap); return NULL; } // 映射建立后 fd 可以關閉映射仍有效 close(m-fd); m-fd -1; // 建議設置訪問建議告訴內(nèi)核這是順序訪問 madvise(m-addr, m-size, MADV_SEQUENTIAL); return m; } void model_unmap(MappedModel *m) { munmap(m-addr, m-size); free(m); }幾個關鍵點解釋MADV_SEQUENTIAL告訴內(nèi)核訪問模式是順序的內(nèi)核會做更積極的預讀減少 major fault 次數(shù)。如果你的訪問模式是隨機的改用MADV_RANDOM。close(fd)映射建立后文件描述符就沒用了及時關閉可以釋放 fd 資源。munmap用完記得解除映射否則虛擬地址空間會泄漏。4.4 訪問模式優(yōu)化讓活躍頁穩(wěn)定駐留mmap 只是第一步真正決定性能的是訪問模式。同樣的模型訪問模式不同性能可能差好幾倍。原則一順序訪問優(yōu)于隨機訪問。順序訪問時內(nèi)核的預讀機制能提前把后面的頁讀進來major fault 被攤薄。隨機訪問時每次都是 major fault性能直接崩。原則二復用優(yōu)于重讀。如果推理過程中反復訪問同一批權(quán)重這批權(quán)重會穩(wěn)定留在 page cache 里后續(xù)訪問都是 minor fault幾乎零開銷。所以推理框架的層間調(diào)度策略很關鍵。原則三及時釋放不用的頁。如果框架支持算完某一層后可以主動madvise(MADV_DONTNEED)告訴內(nèi)核這些頁可以回收給后面的層騰地方。// 算完某一層后主動釋放 madvise(layer_addr, layer_size, MADV_DONTNEED);注意MADV_DONTNEED在MAP_PRIVATE映射上會丟棄頁下次訪問重新從磁盤讀。用之前確認這層確實不會再用了否則會反復讀盤。4.5 內(nèi)存監(jiān)控與調(diào)優(yōu)跑起來之后怎么知道方案有沒有生效看幾個關鍵指標# 實時看內(nèi)存和 page cache watch -n 1 free -h; echo ---; cat /proc/meminfo | grep -E Cached|Mapped|Dirty # 看進程的缺頁統(tǒng)計 cat /proc/pid/stat | awk {print min_flt:$10, maj_flt:$12} # 看 page cache 命中情況 cat /proc/vmstat | grep -E pgfault|pgmajfault重點看兩個數(shù)maj_fltmajor fault 次數(shù)這個數(shù)增長快說明頻繁從磁盤讀性能瓶頸在存儲。如果穩(wěn)定在一個低水平說明活躍頁命中率高方案生效。Cachedpage cache 占用的內(nèi)存。這個數(shù)會隨著推理波動但不會無限增長因為內(nèi)核會在內(nèi)存緊張時回收。調(diào)優(yōu)參數(shù)# 降低 swappiness盡量不用 swap讓 page cache 優(yōu)先 echo 10 /proc/sys/vm/swappiness # 調(diào)整 page cache 回收傾向 echo 100 /proc/sys/vm/vfs_cache_pressure5. 常見問題與排查技巧實錄5.1 問題速查表現(xiàn)象可能原因排查方法解決思路進程被 OOM Killer 殺掉峰值內(nèi)存超限dmesggrep -i oom推理速度極慢major fault 頻繁cat /proc/pid/stat看 maj_flt優(yōu)化訪問模式加MADV_SEQUENTIAL內(nèi)存占用持續(xù)增長page cache 未回收free -h看 Cached調(diào)低 swappiness主動MADV_DONTNEEDmmap 返回 MAP_FAILED地址空間不足或文件問題perror看 errno檢查文件大小、權(quán)限、虛擬地址限制首次推理特別慢冷啟動page cache 空觀察第一次和后續(xù)的耗時差正常現(xiàn)象可預熱多進程共享模型內(nèi)存翻倍用了MAP_PRIVATE且寫操作檢查是否有寫只讀場景用MAP_SHARED或確保不寫5.2 踩坑記錄那些文檔里不會寫的事坑一MAP_PRIVATE下的寫操作會觸發(fā)寫時復制。我一開始圖省事映射時給了PROT_READ | PROT_WRITE結(jié)果框架內(nèi)部有個地方不小心寫了一下整頁被復制內(nèi)存直接翻倍。后來改成純PROT_READ問題消失。只讀數(shù)據(jù)就老老實實只讀映射?？佣MMC 的隨機讀比想象中慢。在 eMMC 板子上major fault 的延遲能到幾毫秒如果每秒幾千次 major fault性能直接崩。后來換了 NVMe同樣的代碼推理速度提升了好幾倍。存儲是這套方案的天花板別在存儲上省錢?？尤齪age cache 和進程內(nèi)存的賬要分開算。free -h里的used包含了 page cache看起來內(nèi)存快滿了其實大部分是可回收的。真正要看的是available。我一開始被used嚇到以為方案失敗了其實available還有好幾個 GB?？铀膬?nèi)核版本影響 page cache 回收策略。在 5.10 和 6.1 上跑同樣的代碼行為有差異。6.1 的回收更積極major fault 略多但內(nèi)存更穩(wěn)。部署前在目標內(nèi)核上實測別拿開發(fā)機的數(shù)據(jù)直接套?？游迥Ｐ头制皇侨f能的。分片能提高回收粒度但如果分片之間訪問跳躍大反而增加 major fault。分片策略要結(jié)合模型的層結(jié)構(gòu)來定按層分片通常比按大小分片更合理。5.3 性能實測數(shù)據(jù)參考在 RK3588 16 GB LPDDR5 NVMe 的配置上我實測了一組數(shù)據(jù)供參考指標全量加載mmap 加載峰值物理內(nèi)存無法完成約 9.5 GB首次推理耗時-約 45 秒后續(xù)推理耗時-約 12 秒major fault 次數(shù)單次推理-約 8000 次page cache 占用-約 6 GB可以看到mmap 方案把峰值內(nèi)存壓到了 9.5 GB留出了足夠余量。首次推理慢是因為 page cache 是冷的后續(xù)推理穩(wěn)定在 12 秒左右major fault 次數(shù)也降下來了。6. 方案邊界與延伸思考6.1 這套方案不適合什么場景mmap 不是銀彈有幾個場景要謹慎實時性要求極高的場景major fault 的延遲不可控如果推理有硬實時要求mmap 的抖動可能無法接受。這種場景要么全量加載要么用 RT 內(nèi)核加內(nèi)存鎖定。存儲極慢的場景如果板子只有低速 eMMC 或者 SD 卡major fault 開銷太大方案可能跑不動。訪問模式極度隨機的場景如果模型訪問沒有局部性每次都是隨機頁mmap 退化成隨機讀性能還不如全量加載。6.2 可以進一步優(yōu)化的方向如果基礎方案跑通了還有幾個方向可以繼續(xù)壓方向一權(quán)重壓縮。把權(quán)重從 FP16 壓到 INT8 甚至 INT4模型體積直接減半甚至減到四分之一mmap 的壓力大幅降低。RK3588 的 NPU 對量化模型支持很好這條路值得走。方向二分層預取。在算第 N 層的時候提前把第 N1 層的頁讀進來用計算時間掩蓋 IO 時間。這需要框架層面的配合但收益明顯。方向三混合加載。把最常訪問的權(quán)重比如 embedding 層常駐內(nèi)存不常訪問的權(quán)重走 mmap。這樣兼顧了性能和內(nèi)存。方向四利用 NPU 的零拷貝。RK3588 的 NPU 支持從特定內(nèi)存區(qū)域直接讀數(shù)據(jù)如果能和 mmap 結(jié)合減少一次內(nèi)存拷貝性能還能再提。6.3 關于 RK3588 生態(tài)的一點個人觀察最近 RK3588 相關的討論里部署大模型、跑視覺 SLAM、做邊緣推理的需求明顯增多。這塊板子的性價比確實高6 TOPS 的 NPU 加上不錯的內(nèi)存帶寬在邊緣端很有競爭力。但生態(tài)上還有些不成熟的地方比如 RKNN 對動態(tài) shape 的支持、對大模型分片加載的支持都還在完善中。我的建議是如果你的模型是給 NPU 跑的優(yōu)先用官方工具鏈別自己造輪子如果是給 CPU 跑的mmap 這套方案可以放心用可控性高坑也相對少。兩條路各有適用場景別硬套。最后分享一個我在實際部署中養(yǎng)成的習慣每次上板子之前先在開發(fā)機上用strace跟一遍模型的文件訪問模式看看是順序讀還是隨機讀活躍集大概多大。這個信息能幫你提前判斷 mmap 方案是否可行省去很多上板調(diào)試的時間。踩過幾次坑之后我現(xiàn)在拿到任何模型第一件事就是看它的訪問模式而不是急著寫加載代碼。