演算法系統協同最佳化，vivo與港中文推出BlueLM-V-3B，手機秒變多模態AI專家
机器之心發表於2024-11-29
AIxiv專欄是機器之心釋出學術、技術內容的欄目。過去數年，機器之心AIxiv專欄接收報導了2000多篇內容，覆蓋全球各大高校與企業的頂級實驗室，有效促進了學術交流與傳播。如果您有優秀的工作想要分享，歡迎投稿或者聯絡報導。投稿郵箱：liyazhou@jiqizhixin.com；zhaoyunfeng@jiqizhixin.com
BlueLM-V-3B 是一款由 vivo AI 研究院與香港中文大學聯合研發的端側多模態模型。該模型現已完成對天璣 9300 和 9400 晶片的初步適配，未來將逐步推出手機端應用，為使用者帶來更智慧、更便捷的體驗。近年來，多模態大語言模型（MLLM）的迅猛發展，為我們的日常生活帶來了無限可能。手機作為我們形影不離的「智慧伴侶」，無疑是 MLLM 最理想的落地平臺。它能夠將強大的 AI 能力，無縫融入我們的日常任務，讓科技真正服務於生活。然而，要將 MLLM 部署到手機上，並非易事。記憶體大小和計算能力的限制，就像兩座大山，橫亙在 MLLM 與手機之間。未經最佳化的模型，難以在手機上實現流暢、實時的處理，更遑論為使用者帶來良好的體驗。- 論文地址：https://arxiv.org/abs/2411.10640
為了攻克這一難題，vivo AI 全球研究院和香港中文大學多媒體實驗室共同推出了 BlueLM-V-3B。這是一款專為移動平臺量身打造的 MLLM，採用了演算法與系統協同設計的創新理念，重新設計了主流 MLLM 的動態解析度方案，並針對手機硬體特性進行了深度系統最佳化，從而實現了在手機上高效、流暢地執行 MLLM。研究團隊分析了經典 MLLM 使用的動態解析度方案，發現了影像過度放大的問題，並提出了針對性的解決方案。此外，他們還針對硬體感知部署進行了一系列系統設計和最佳化，使 MLLM 在移動裝置上能夠更高效地進行推理，充分發揮硬體潛力。BlueLM-V-3B 在效能上表現出色，在引數規模相似的模型中達到了 SOTA 水平（例如，在 OpenCompass 基準測試中取得了 66.1 的高分）。更令人驚喜的是，BlueLM-V-3B 甚至超越了一系列引數規模更大的 MLLM（例如，MiniCPM-V-2.6、InternVL2-8B），展現了其強大的實力。BlueLM-V-3B 在移動端部署方面同樣表現優異。以聯發科天璣 9300 處理器為例，其記憶體需求僅為 2.2GB，能夠在約 2.1 秒內完成對 768×1536 解析度影像的編碼，並實現 24.4token/s 的 token 輸出速度。這意味著，使用者可以在手機上享受到流暢、高效的 MLLM 體驗，而無需擔心算力瓶頸。BlueLM-V-3B 延續了傳統的 LLaVA 架構，包括視覺編碼器 SigLIP-400M，MLP 線性對映層，以及大語言模型 BlueLM-3B。為了更好地處理高解析度圖片，和主流 MLLM 一樣，BlueLM-V-3B 採用了動態解析度方案，並針對 InternVL 1.5 和 LLaVA-NeXT 中存在的影像過度放大問題進行了改進。此外，為了應對手機 NPU 在處理長輸入 token 時的效能限制，BlueLM-V-3B 還引入了 token 降取樣的方案，以確保模型在移動裝置上的順利部署。為了提升多模態模型應對高解析度圖片的能力，主流的 MLLM 往往採用動態解析度的方案進行圖片的放縮和裁切。該團隊發現主流動態解析度方案，如 LLaVA-NeXT 和 InternVL 1.5 往往伴隨圖片過度放大。傳統的動態解析度方案往往會選擇一個解析度（如 384x384）作為基準尺寸，並選擇合適的長寬比對影像進行縮放。對於 LLaVA-NeXT，給定一個解析度為 394×390 的影像，它會選擇 2:2 的圖片比例，然後將原始影像調整並填充至 768×768（放大 4 倍）。對於 InternVL1.5，給定一個解析度為 380×76 的影像，它會選擇 5:1 的比例，直接將原始影像調整至 1920×384（放大 25 倍）。這種放大並不一定豐富了影像資訊，但會導致更多的影像切塊，從而增加影像 token 的數量，增加移動裝置上的部署難度。鑑於此，BlueLM-V-3B 基於 LLaVA-NeXT 設計了一種寬鬆的長寬比選擇演算法，綜合考慮了放縮後圖片的有效資訊解析度以及浪費的空間，有效提高了圖片資訊的利用率，減少了部署時的圖片 token 長度，降低圖片的處理延時。影像並行編碼：經過動態解析度處理後，影像被分為多個區域性切塊以及一張全域性縮圖切塊。為了加速部署推理，BlueLM-V-3B 採用並行策略來利用 NPU 的計算能力。與高階語言（例如 Python）不同，硬體加速設計需要對計算資源進行底層控制，例如記憶體佈局和基於暫存器大小的計算最佳化。由於 NPU 的計算能力有限，所有圖片切塊無法同時有效處理；相反，BlueLM-V-3B 一次處理固定數量的切塊，以獲得並行處理和硬體效能的平衡。流水線並行處理：在模型推理過程中，BlueLM-V-3B 實現了流水線並行方案，以最佳化影像切塊的編碼效率。具體而言，對於從單個影像中提取的不同切塊，BlueLM-V-3B 為 SigLIP 視覺嵌入模組的 Conv2D 層和 ViT 層設計了流水線並行方案。這種方法有效地隱藏了 Conv2D 操作的執行延遲，提升了整體處理速度。雖然 BlueLM-V-3B 設計了一種寬鬆的長寬比選擇演算法來降低部署過程中圖片 token 的數量，但動態解析度帶來的圖片 token 數量依然很多。為此，BlueLM-V-3B 採用了 VILA 提出的 token 數量下采樣方案，將每 2×2 個影像 token 合併為一個 token，並採用一個線性層做資訊融合，降低了部署難度。分塊計算輸入 token：在 LLM 推理過程中，傳統 GPU 透過平行計算技術同時處理所有輸入 token 以加速計算。然而，由於影像 token 長度較長、上下文資訊複雜以及 NPU 計算能力有限，導致並行處理效率低下。逐個 token 的順序處理也不是最佳選擇。因此，BlueLM-V-3B 在移動裝置上採用了分塊策略，每次迭代並行處理 128 個輸入 token（t128），然後合併結果，以在並行處理與 NPU 計算資源之間實現平衡。混合引數精度：BlueLM-V-3B 透過混合精度量化降低記憶體使用並提升推理速度。權重方面，SigLIP 和 MLP 線性對映層採用 INT8 精度，LLM 則使用 INT4 精度，平衡了計算效率與模型精度。由於啟用值對量化更敏感，LLM 的啟用使用 INT16 精度，SigLIP 及對映層的啟用則使用 FP16，以確保模型效能。推理過程中，KV 快取採用 INT8 精度儲存。為了提高部署效率，BlueLM-V-3B 將影像處理與使用者輸入解耦。在模型初始化時，ViT 和 LLM 模型同時載入到記憶體中。使用者上傳影像時，由於 MLLM 在本地部署，上傳幾乎沒有延遲。影像上傳後，ViT 立即開始處理，使用者可以同時輸入指令；對於音訊指令，BlueLM-V-3B 會先將其轉換為文字。影像處理完成後，使用者的命令提交給 LLM 生成響應，ViT 可以從記憶體中釋放。這種並行處理減少了第一個 token 生成的等待時間，提高了響應速度，並將 BlueLM-V-3B 的峰值記憶體使用限制在 2.2GB。BlueLM-V-3B 從 BlueLM-3B 語言模型開始分兩個階段進行訓練。在第一階段，預訓練線性對映層，同時保持 ViT 和 LLM 凍結。在第二階段，使用大量的影像 - 文字對對模型進行全面微調。第一階段旨在賦予模型基本的多模態能力。在這一階段，該團隊利用開源資料集，建立了一個由 250 萬條影像 - 文字對組成的綜合預訓練資料集，這些資料集來自 LLaVA、ShareGPT4V 和 ALLaVA。在這一階段，研究團隊精心構建了一個包含 6億+ 條影像 - 文字對的資料集，其中包括開源資料集和內部資料集。該資料集涵蓋了各種下游任務和多樣化的資料型別，如影像描述、視覺問答、文字圖片識別和純文字資料。除了開源資料集，他們還加入了大量內部資料以增強模型的能力。比如，從各種網站上爬取了大量的純文字資料和影像 - 文字對。對於不同的資料類別，如 PDF、公式、圖表、解題資料、多語種資料，團隊還手動渲染並建立了大量的影像-文字對，以豐富訓練資料的多樣性。除了進行影像渲染外，研究團隊還使用 GPT-4o 和 Gemini Pro 構造和修改圖片描述及視覺問答對。開源與專有資料的結合顯著提升了模型的能力，使其能從多樣化的示例中學習，並在多種任務和模態上提升效能。該團隊在 LLaVA 665k 訓練集上驗證了改進方案是否能降低部署成本。為公平對比，他們將 LLaVA-NeXT、InternVL 1.5 和改進方案的最大分塊數均設定為 9。與 LLaVA-NeXT 相比，提出的方法在 2.9 萬個樣例中選擇了更小的長寬比；而在與 InternVL 1.5 的比較中，在 52.3 萬個樣例中採用了更小的長寬比，在 2.5 萬個樣例中選擇了更大的長寬比。這顯著提升了 NPU 上的推理效率。研究團隊在 MiniCPM-2B 和 BlueLM-3B（均為 2.7B 引數量）兩個模型上進行實驗，利用 LLaVA 558k 進行第一階段訓練，用 LLaVA 665k 進行第二階段訓練。比較 LLaVA-NeXT、InternVL 1.5 和改進方案在測評集上的效能表現。由於 3B 模型的學習速度較慢，每個階段訓兩輪。該團隊統計了在多個常用測評集上的結果。可以看到新設計的動態解析度方案不僅降低了部署成本，還提升了測評集上的準確率。下圖展示了全量微調完的 BlueLM-V-3B 模型在 OpenCompass 測評集上的精度表現，並和總引數量小於等於 10B 的模型進行比較。可以看到，BlueLM-V-3B 模型在 4 個測試專案中取得最高分，並在均分上排名第二。這展示了 BlueLM-V-3B 模型的強勁效能。下圖是 BlueLM-V-3B 與引數量相近的多模態模型在 TextVQA，DocVQA 以及多語種多模態資料集 MTVQA 上的評測結果。可以看到，在 OCR 相關任務上，BlueLM-V-3B 取得了非常有競爭力的成績，並在多語言測評中遠超主流的多模態模型。團隊彙報了在搭載天璣 9300 處理器的 vivo X100 手機上的部署結果。實驗中，採用了 2:4 的分塊方案（對手機螢幕的處理採用 2:4 方案），共有 2x4=8 個區域性分塊和一個全域性分塊。該團隊測試了同時處理 1 塊、2 塊、4 塊、6 塊影像切塊的 NPU 處理延時。可以看到，同時處理 4 個切塊的總延時最低，僅為 1.9 秒。該團隊設計了對 SigLIP 模型的 Conv2D 和 ViT 部分在 CPU 和 NPU 上的流水線並行，並測試了 2:4 分塊方案下的部署效率。如上文流水線管線所示，可以掩蓋 200 毫秒的 Conv2D 的處理延時。該團隊在 NPU 上採用了一種分塊處理策略，每次迭代並行處理 128 個輸入 token（t128），以平衡並行處理與 NPU 效能。在此展示並行處理不同數量輸入 token 時的 LLM 首詞延時：t32、t128、t512 和 t2048。論文中還列出了輸出 token 的生成速度，其中僅顯示了 t1 的情況，因為 LLM 在輸出時一次處理一個 token。輸入 token 長度被固定為 2048，KV 快取長度被設定為 2048。可以看到，t128/t1 實現了最低的延遲和最快的生成速度。該團隊對 BlueLM-V-3B 與 MiniCPM-V 論文中提供的統計資料進行了直接比較。MiniCPM-V 論文僅報告了 8B 引數量的 MiniCPM-V 2.5 模型在天璣 9300 晶片的 CPU 上使用 llama.cpp 部署的情況。BlueLM-V-3B 團隊使用解析度為 768×1536 的影像，固定輸入 token 長度為 2048，並將 KV 快取長度設為 2048。MiniCPM-V 將模型載入時間也計入了延遲。對於 BlueLM-V-3B，在系統初始化階段，同時載入 ViT 和 LLM 的時間僅為 0.47 秒。結果顯示，BlueLM-V-3B 因其較小的引數量和優秀的系統設計，在延遲和 token 吞吐量上更具優勢。在 BlueLM-V-3B 的開發過程中，vivo 和港中文團隊在確保良好使用者體驗的同時，注重演算法 - 系統協同設計和硬體感知最佳化。據實驗與統計分析顯示，BlueLM-V-3B 在移動裝置上表現出色，效能強勁且部署高效。未來，該團隊將繼續致力於提升端側模型的可擴充套件性，並探索先進演算法，持續最佳化效能與可用性，以適應更多的手機裝置。