DeepSeek V4 多模態開源，我們把它的視覺鏈路拆了一遍

圖片不只被編碼，還直接參與 Attention、MoE 與 Agent 推理。作者丨鄭佳美 編輯丨岑 峰 這不是一個全新的模型突然出現。早在 8 月 21 日，DeepSeek 就已經把它接入 API，當時外界只能看到結果：V4 開始能處理圖片，而且在 ApexBench、Agents' Last Exam、Chartography 等多模態 Agent 基準上整體提升。現在不一樣了。隨著權重和參考推理代碼公開，V4 的視覺部分第一次可以直接拆開看。

Vision Encoder 怎麼處理圖片，Aligner 怎麼把視覺特徵壓進語言空間，視覺 Token 怎麼進入 DFlash，MoE 又怎麼給圖片選擇專家，這些東西都已經暴露出來。拆完代碼會發現，DeepSeek 做的並不是簡單給 V4 接一個看圖模塊。圖片經過視覺編碼以後，會被直接塞進 V4 原有的 Token 序列，繼續參與長上下文 Attention、MoE 路由和後面的 Agent 推理。甚至連注意力窗口和專家路由，都專門為視覺 Token 改了規則。

所以這次開放權重之後，更值得研究的問題已經從 V4 會不會看圖，變成了另一件事：DeepSeek 到底是怎麼把視覺塞進一個原本為長上下文和 Agent 設計的 V4 主幹裡的？01視覺怎樣進入 V4先看一張圖片怎樣變成 V4 序列中的 Token。視覺前端是一套 32 層 ViT，隱藏維度 1024，擁有 16 個 Attention Head，patch size 為 14。圖片先經過尺寸調整，再被切成 14 × 14 的 patch，每個 patch 映射成一個 1024 維向量。視覺位置編碼使用二維 RoPE。代碼會分別建立圖像網格的橫向和縱向座標，再將兩組位置寫入 Attention。

對於網頁和 GUI，這種設計很關鍵，因為界面語義大量存在於空間關係裡：按鈕位於哪個區域，表頭和數據怎樣對應，彈窗覆蓋了什麼內容，圖例和圖表之間是什麼位置關係。ViT 在這裡負責先把二維結構建出來。問題出現在 ViT 後面。V4 主幹隱藏維度是 4096，視覺側只有 1024，而且 ViT 產生的 patch 數量仍然偏大。DeepSeek 在兩者中間放了一個 Aligner，同時解決維度轉換和 Token 壓縮。它會把相鄰 3 × 3 個視覺特徵放到一起，9 個 1024 維向量合併以後形成 9216 維輸入，再經過 9216 → 4096 → 4096 的兩層映射進入 V4。

打個比方，這個 Aligner就相當於向“老闆”V4彙報的秘書，先將老闆要處理的文件進行精煉彙總：橫向縮小 3 倍，縱向縮小 3 倍，所以進入語言主幹的視覺網格規模大致下降到原來的九分之一。這一步非常關鍵。DeepSeek 沒有直接降低 ViT 的觀察密度，而是在視覺編碼完成以後再壓縮序列。前端仍然可以利用較密的 patch 讀取頁面細節，到了計算量更大的 V4 主幹之前，再削減視覺 Token 數。配置裡的 visionmaxntoken = 384 也應該放在這裡理解。384 指的是進入 V4 序列後的單圖預算，並非 ViT 只看 384 個 patch。

ViT 前端實際處理的視覺單元更多，經過 3 × 3 Aligner 後，才被壓縮成幾百個語言側視覺 Token。DeepSeek API 同樣規定單張圖片轉換後的輸入不超過 384 Token。對於單輪圖像問答，這種限制可能只是一次計算取捨；對於 Agent，它直接決定每觀察一次環境，需要往長上下文裡新增多少內容。隨後還有一個很容易被忽略的細節：視覺 Token 並沒有按照普通的逐行順序進入 V4。buildimageblock() 會給圖片加入 IMAGESTART、換行、Padding 和 IMAGEEND，然後把相鄰兩行視覺網格重新交織。

代碼還通過 COMPRESSPADTO = 4，讓視覺序列的位置與 4 Token 邊界對齊。V4 主幹內部恰好大量存在 compressratio = 4 的壓縮層，同時還交替使用 ratio 為 128 的層。僅憑公開代碼還不能斷言 N-layout 就是專門為 CSA 的 4 Token 壓縮設計。但兩者的粒度明顯一致：圖像進入模型前已經主動改變二維網格的線性排列，並進行 4 Token 對齊，說明視覺序列的組織方式考慮了後面壓縮主幹的處理方式。所以從像素到 V4，並非簡單經歷 ViT 加一個投影層。

更準確的路徑是：圖片先以較高密度建立二維表示，隨後進行 3 × 3 空間壓縮，再轉換到 4096 維隱藏空間，接著重新組織視覺 Token 的排列，最後才進入 V4。做到這一步，圖片已經被改造成一種適合長上下文主幹處理的序列。新的問題隨之出現：進入序列以後，V4 能不能直接把這些視覺 Token 當成文字處理？02進入主幹以後答案從代碼裡看得很清楚：不能完全按照文字處理。V4 會先正常生成文本 embedding，然後 mergeimageembeddings() 找到圖片佔位區域，把經過 ViT 和 Aligner 得到的視覺 embedding 原地寫進去。

從隱藏層角度看，文字和圖片此時已經進入同一個 4096 維空間。後面的 Transformer 可以讓頁面內容和自然語言指令直接發生交互，例如任務要求在文字 Token 中，當前網頁狀態位於視覺 Token 中，兩者進入同一條推理序列。不過 DeepSeek 特意保留了視覺 Token 的身份。普通詞表大小是 129280，而圖像特殊 Token 被放在詞表範圍之外。主幹只需要檢查 inputids >= vocabsize，就能判斷當前位置來自圖片。為什麼進入統一隱藏空間以後，還要留下這個標記？因為二維圖片和文字序列的計算需求並不一樣。先看 Attention。

V4 的普通局部滑窗只有 128 Token，而一張圖片可以佔接近 384 個語言側 Token。如果完全按照文字的局部規則處理，一張完整截圖可能被切成數段。比如一個網頁的表頭在頂部，操作按鈕位於頁面下方。二維空間中它們屬於同一張界面，但轉換成一維視覺序列後，兩者距離可能超過 128 Token。普通滑窗會削弱同一張圖片內部遠距離區域的直接聯繫。代碼因此加入了 getimagevisible()。它會識別 IMAGESTART 與 IMAGEEND，計算一個 Token 在當前圖片範圍內向左和向右還有多少視覺內容。V4 隨後可以在普通局部窗口之外，擴展圖片內部的可見範圍。

代碼甚至要求一整段圖片必須在 prefill 階段一次寫入，不能在後續 decode 中把同一張圖拆成幾塊追加。這解決的是視覺的空間完整性。MoE 處理的是另一個問題：視覺 Token 應該調用哪些參數。V4 擁有 256 個路由專家，每個 Token 會激活 6 個專家。視覺版本的 Router 中增加了單獨的 biasvl。普通文字 Token 使用常規 expert bias，圖片 Token 則換成視覺專用的 biasvl 來影響 top-k 專家選擇。這個 bias 負責調整專家被選中的順序，真正用於計算輸出的路由權重仍然來自原始 scores。

前面的 Hash-MoE 層處理得更加直接。文字 Token 可以利用 Token ID 對應已有專家映射，但圖片沒有正常詞表中的語義 ID，所以視覺位置會跳過這套路由，根據當前隱藏狀態重新選擇專家。這形成了一種很有意思的結構：視覺和文字共享同一個 V4 主幹，也共享專家池；進入內部計算時，模型仍然允許視覺走不同的可見關係和專家分配路徑。這種做法比把視覺徹底變成偽文字更靈活。語言主幹積累下來的代碼、推理、工具調用和知識能力可以繼續複用；視覺 Token 又不需要強行服從語言序列的全部假設。開放權重以後，biasvl 也提供了一個很直接的研究入口。

可以統計網頁截圖、圖表、自然圖像、IDE 界面分別激活哪些專家，再觀察視覺和文本進入深層以後，專家分佈是否逐漸融合。到這裡，V4 已經解決了兩件事：視覺怎樣進入長上下文，以及主幹怎樣識別視覺。剩下的問題開始轉向系統層面。如果圖片只出現一次，這些設計的代價還比較容易控制；Agent 會讓模型一輪又一輪地重新看環境，計算模式就完全變了。03視覺成本會被一輪輪放大DeepSeek 給 V4-Flash-Vision-Exp 加視覺，並沒有把重點停留在圖片描述。官方發佈時專門強調 Multimodal Agent，並且 Responses API 支持圖文輸入和工具使用。

這意味著圖片可以和工具執行流程放在一起：模型讀取環境，生成行動，工具執行，然後新的環境狀態再次返回模型。瀏覽器 Agent 就是一個典型例子。模型先看到網頁截圖，根據任務決定點擊按鈕；點擊完成以後頁面改變，Agent 再截一張圖；模型讀取新頁面，決定是否輸入、滾動或者執行下一項操作。普通聊天經常經歷一次較長的 prefill，隨後連續 decode。視覺 Agent 的工作負載不一樣。每產生一次新的環境觀察，就需要重新執行圖片縮放、patch 化、32 層 ViT、Aligner，再把新增加的視覺 Token 送進 V4 做 prefill。

一個動作可能只生成幾個 Token，但在生成之前卻要處理一整張新截圖。於是任務運行時間越長，視覺編碼和反覆 prefill 的佔比就越高。V4 支持超過 100 萬 Token 上下文，這能容納很長的任務軌跡；容量大並不等於計算可以忽略。每張圖片有 384 Token 的語言側預算，同時主幹還運行 43 層 Transformer、256 個專家和稀疏 Attention。連續幾十輪環境觀察以後，歷史中會同時存在任務指令、工具結果、文字頁面內容和多輪視覺狀態。這裡會出現一個比上下文長度更麻煩的問題：重複計算。

Agent 連續操作網頁時，相鄰兩張截圖可能只有一個按鈕、一個彈窗或者某塊結果區域發生變化，頁面的大部分像素保持原樣。目前這種視覺輸入路徑仍然會把新截圖重新送進 ViT。換句話說，視覺 Agent 很容易反覆計算沒有變化的環境。這可能成為後續推理優化中非常大的空間。一種方向是緩存 ViT 中間結果。頁面只改變局部區域時，只更新發生變化的 patch。另一種方向是做視覺差分。系統先判斷前後兩幀哪些區域發生變化，再決定哪些視覺內容值得重新寫進上下文。還可以採用混合環境表示。

網頁正文和表單信息交給 DOM 或 Accessibility Tree，canvas、圖表、複雜佈局以及程序接口難以表達的界面狀態交給視覺模型。這樣無需每一步把整個頁面重新當作像素處理。這類優化和提升單張圖片理解能力屬於完全不同的問題。Agent 看圖的核心壓力在頻率。模型需要持續觀察、持續更新狀態，而且每一輪觀察必須足夠便宜，才能讓任務執行幾十步後仍然保持可用速度。MoE 又會增加一層部署變量。既然視覺 Token 存在獨立的 biasvl，不同視覺輸入可能形成不同專家負載。如果大量 GUI Agent 請求集中進入服務，視覺路由會不會讓部分專家承受更高流量，需要通過真實推理數據才能判斷。

因此，V4-Flash-Vision-Exp 後續真正難做的地方，很可能逐漸從視覺識別轉向視覺狀態管理。如何減少重複編碼，如何控制歷史截圖進入 KV Cache 的方式，如何讓舊畫面退出活躍上下文，以及如何在視覺信息和結構化工具信息之間分配計算資源，這些問題直接決定視覺 Agent 的端到端效率。04V4 正在把環境狀態變成上下文V4 -Flash-Vision-Exp 開放權重後，可以看到 DeepSeek 這次做的事情已經超出給語言模型增加圖片輸入。它正在修改 V4 對上下文的定義。過去，上下文主要來自文字：用戶要求、代碼、工具返回值以及任務歷史。

現在，網頁當前長什麼樣，軟件執行之後界面發生了什麼變化，圖表呈現出怎樣的結構，也可以直接成為 V4 內部的序列狀態。視覺模塊在這裡承擔的是環境接口。這也解釋了 DeepSeek 為什麼沒有讓圖片停留在模型外圍。視覺信息被壓進 V4 的隱藏空間以後，DFlash 需要理解圖片邊界，MoE 需要知道它面對的是視覺 Token，長上下文則需要容納連續的環境變化。當這套鏈路接上 Agent，模型獲得的就不只是多一種輸入模態。它開始形成一個完整循環：讀取環境狀態，產生行動，讓工具改變環境，再根據新的狀態繼續推理。

開放權重之後，外部已經可以從視覺壓縮、Attention 可見範圍、專家路由和多輪推理效率幾個層面直接研究這條鏈路。過去，我們評價一個多模態模型，通常會問：“它能不能認出這張圖中包含了什麼梗？”但 DeepSeek V4 開放權重的這一刻，把行業的及格線徹底拉高了。當圖片不再只是被編碼的死物，而是直接參與到大模型的 Attention 滑窗、MoE 專家路由甚至整個長上下文的推理閉環中時，視覺就變成了大模型理解複雜物理世界的“原生上下文”。在未來的多模態模型競爭中，能看懂圖片只是入場券。

當整個行業開始捲起來，V4 後續能不能成為更成熟的視覺 Agent 底座，很大程度上會取決於另一個問題：模型不僅要看懂環境，還要用足夠低的計算開銷持續看下去。上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。