![]()
五一假期前一天,DeepSeek突然扔出來一份視覺多模態技術報告。
點開之前,我心里大概是有個預期的,無非就是具體能看到多遠、看得多清楚。
畢竟過去一年,多模態模型基本都在往這個方向卷。OpenAI講thinking with images,讓模型在推理過程中裁剪、放大、旋轉圖片;Gemini、Claude也都在想辦法讓模型處理更高分辨率、更復雜的視覺輸入。
大家的共同假設是,只要模型看得更細,視覺推理自然就會更強。
但DeepSeek這份報告看下來,你會發現,他們完全走上了另一條路。
DeepSeek沒有把重點放在“讓模型看到更多像素”上,他們把注意力放在了一個更底層的問題上。
就算模型已經看清楚了,但是它在推理過程中,你怎么能保證模型和你指的是同一個東西?
其實這是多模態推理里最容易被忽略的死穴。
人類看圖時,可以用手指去標記對象。比如“這個人是誰誰誰”、“那個人是誰誰誰”。但模型哪知道你說的這個是哪個?
模型只能用語言說“左邊那個”“上面那個”“這條線”。一旦畫面復雜起來,語言指代就會漂移,推理也會跟著崩。
于是DeepSeek就說了,那就給模型一根“手指”不就完了?
它把點和邊界框變成模型思考時的基本單位,讓模型能夠一邊用這根賽博手指指著對象,一邊進行推理。
01
從連續視覺到離散符號
DeepSeek在這份技術報告里,提出了一個很有意思的問題。他們認為,多模態模型真正難的地方,不是看見圖像,而是在連續推理過程中穩定地指向同一個視覺對象。
就比如你跟你的朋友說“菜市場里,張老太太的那個攤位賣的菜最新鮮”。但是菜市場里老頭老太太多了去了,哪個是張老太太?
但如果你直接用手指著說“就是那個”,你朋友就會馬上明白。
DeepSeek將這個問題命名為“引用鴻溝”(Reference Gap)。
過去一年,幾乎所有前沿多模態模型都在解決“感知鴻溝”(Perception Gap)這個問題。
假如說有一張照片放在你面前,如果照片太模糊、分辨率太低,你可能看不清楚里面的小字或者遠處的細節。AI也一樣,如果輸入的圖像質量不夠、處理方式不對,它就會“看不清”,這就是感知鴻溝。
GPT、Claude、Gemini這些模型不斷提高分辨率,引入高分辨率裁剪、動態分塊、多尺度處理,目的就是讓模型能看到更多細節。
這個方向當然有價值,但DeepSeek在報告里指出,就算模型看得再清楚,在復雜的空間推理任務上,仍然會出現邏輯崩潰。
問題出在自然語言本身。
照片里有十幾只狗,你說“左邊那只狗”,那模型就沒辦法理解你說的具體是哪只。
還有更絕的,如果你讓模型數一下照片里狗的數量,那么模型在推理過程中很容易就搞不清楚自己已經數過哪些、還有哪些沒數。
報告中還提到了迷宮導航這樣極端的情況,純語言根本無法準確描述不規則形狀的路徑和復雜的拓撲關系。
語言作為一種指代工具,在連續的視覺空間里天生就是模糊的。它擅長抽象概念和因果關系,但在空間定位和拓撲關系上,語言的表達能力存在根本性的局限。
可DeepSeek本身就是個通用的語言模型,那應該怎樣解決呢?
于是就有了文章開頭提到的這根“手指”。
他們提出的核心概念是“視覺基元”(Visual Primitives),具體來說就是把邊界框(bounding boxes)和點(points)這兩種計算機視覺里最基礎的空間標記,提升為“思維的最小單位”。
以前的多模態模型雖然也能畫框標注物體,但只是在最后給你看個結果,證明“我找到了”。就像考試時,你只交答案,不寫解題過程。
也有一些研究讓AI在思考過程中畫框,但目的只是為了“看得更準”,框框只是個輔助工具。就好比你做數學題時用草稿紙,草稿紙只是幫你算得更清楚,不是解題思路的一部分。
DeepSeek要做的完全不同。
他們把這些空間標記直接嵌入到模型的推理過程中,讓它們成為推理的有機組成部分。模型在思考的時候,不只是用語言描述“我看到了一只狗”,還同時輸出“我看到了一只狗,它在這里:[[x1,y1,x2,y2]]”。
這個機制被DeepSeek稱為“邊推理邊指向”(point while it reasons)。
![]()
模型的每一步思考都錨定在圖像的具體坐標上。
技術報告里就給了這樣一個例子:模型從起點出發,一路探索、回溯、再嘗試,最后輸出了一串完整的坐標路徑,每個坐標都對應迷宮里走過的一個點。
這樣一來,模型就不會在推理過程中“迷路”。它不會搞不清楚自己在說什么、指什么。每個視覺對象都有了明確的空間錨點,推理過程變得可追蹤、可驗證。
這條技術路線和OpenAI的方向形成了有趣的對比。
OpenAI在o3和o4-mini的官方介紹里明確提到了“thinking with images”的概念,即模型可以把圖像納入推理鏈,并通過裁剪、放大、旋轉等方式處理圖像。這個方向的重點是讓圖像本身成為思維鏈的一部分,模型可以在推理過程中生成新的圖像、修改圖像、對圖像進行操作。
OpenAI的路線強調的是通用能力,視覺、代碼、搜索、文件、工具調用一起協作。模型擁有一個強大的“視覺工作臺”,可以靈活地處理各種視覺任務。
DeepSeek的路線則更“符號化”一點。它讓坐標進入思維鏈。模型在推理文本里顯式寫出邊界框和點的坐標,把視覺對象變成推理時可復用的錨點。
這就導致,OpenAI的視覺推理發生在內部,用戶只能看到最終答案和必要解釋,中間的視覺處理過程是黑箱。DeepSeek則故意把中間視覺錨點顯式化,讓推理過程完全透明。
DeepSeek這樣做,好處是推理過程更容易被訓練、檢查和打分。這也讓它更容易設計格式、質量和任務級獎勵。尤其在迷宮、路徑追蹤這類任務中,可以對路徑合法性、軌跡覆蓋度等給出更細的反饋。
模型不只是學會輸出正確答案,更是學會了用視覺基元進行推理的方法。
02
效率才是核心
DeepSeek這份報告里有一個很容易被忽略但極其重要的細節,他們的模型在處理圖像時,用的token數量遠遠少于其他前沿模型。
報告里有一張對比圖,展示了不同模型處理一張800×800分辨率圖像時消耗的token數量。
Gemini-3-Flash約1100個,Claude-Sonnet-4.6約870個,GPT-5.4約740個,Qwen3-VL約660個,DeepSeek約361個,并在KV緩存里只保留約90個條目。
這個差距不是一點點。DeepSeek用的token數量只有Gemini的3分之1,KV緩存條目更是只有10分之1左右。
這種極致的效率是怎么實現的?
DeepSeek用了一個叫“壓縮稀疏注意力”(Compressed Sparse Attention, CSA)的機制。
你可以這樣理解,假如說你給朋友看一張全家福,你不會說“從左數第237個像素開始有一塊紅色區域……”,你會直接說“左邊是我媽,右邊是我爸”。
DeepSeek-ViT先把圖像壓成更少的視覺token,CSA再把這些視覺token在KV緩存中的表示進一步壓縮。
這個機制在DeepSeek-V4-Flash模型上就使用過,現在被應用到了視覺多模態之中。
具體的壓縮流程是這樣的。一張756×756的圖像,包含571536個像素。這些像素首先經過ViT處理,以14×14的patch size切分,生成2916個patch token。然后進行3×3的空間壓縮,把每9個相鄰的token沿著通道維度壓縮成1個,變成324個視覺token。
這324個token進入大語言模型進行預填充。最后,CSA機制會把這些視覺token在KV緩存里再壓縮4倍,最終只保留81個條目。
從571536個像素到81個KV緩存條目,整個壓縮比達到了7056倍。
一般AI大廠都是在用暴力方法去堆計算資源,而DeepSeek則是在信息論層面去做取舍,只留下最直觀易懂的信息。
其最直接的結果,就是推理速度變快了許多。
![]()
圖像token數量直接影響模型的推理延遲。在自回歸生成過程中,每生成一個新token,模型都需要對之前所有token的KV緩存進行注意力計算。如果圖像占用了1000個token,那么每次生成都要對這1000個token做注意力。如果只占用90個,計算量就大幅減少。
對于需要實時響應的應用場景,比如機器人視覺、自動駕駛、實時視頻分析,推理速度的提升起到了決定性作用。
然后它內存占用得也少。
KV緩存是大模型推理的內存瓶頸。特別是在處理長上下文或批量推理的時候,KV緩存會占用大量顯存。DeepSeek把視覺token的KV緩存壓縮到90個條目,意味著可以在同樣的硬件上處理更多圖像,或者處理更長的多輪對話。
這對于實際部署非常重要。很多公司的多模態模型在實驗室里表現很好,但一到實際部署就遇到成本問題。每張圖片消耗的token越多,推理成本就越高,可支持的并發用戶就越少。DeepSeek的效率優勢在規模化部署時會被放大。
同時也變相提高了模型的上下文容量。
如果一張圖片要占用1000個token,那么在一個128k的上下文窗口里,只能放100多張圖片。如果只占用300個token,就可以放400多張。這對于需要處理多圖對話、長視頻分析、大量文檔理解的場景至關重要。
DeepSeek的模型可以在一個對話里處理更多圖像,可以對比分析幾十張甚至上百張圖片,可以追蹤視頻里的長期變化。
最關鍵的是訓練成本。
雖然報告主要講推理效率,但這種壓縮機制在訓練階段同樣有效。更少的視覺token意味著更小的計算圖,更快的訓練速度,更低的硬件要求。
DeepSeek一直以“用更少資源做出更好效果”著稱。從R1的強化學習訓練,到V4的MoE架構,再到現在的視覺多模態,這種效率優先的哲學貫穿始終。
但這里有一個關鍵問題。壓縮會不會損失信息?
DeepSeek并沒有否認壓縮會帶來信息損失。它的主張是,在這組空間推理和計數任務上,壓縮后的表征仍然足夠有效。
每一步壓縮都在保留對推理最重要的信息,丟棄冗余和噪聲。
其實前面提到的DeepSeek的視覺基元機制,它本身也是一種信息壓縮。一個邊界框用4個數字就能精確定位一個物體,一個點用2個數字就能標記一個位置。這些離散符號攜帶的信息密度遠高于原始像素。
從實驗結果看,這種壓縮沒有損害性能,反而在某些任務上帶來了提升。
這說明對于很多視覺推理任務,瓶頸不在于看得不夠清楚,而在于沒有找到合適的表征方式。
這種效率優勢還證明了多模態智能不一定需要更大的模型、更多的算力、更高的成本。
從DeepSeek時刻誕生至今,這家公司一直有一條暗線,“真正的智能不在于算力,而在于對問題本質的理解”。
當你真正理解了視覺推理需要什么,你就不需要那么多token。當你找到了合適的表征方式,你就不需要那么大的模型。
從這個角度看,DeepSeek的極致效率不是目的,而是副產品。真正的目的是找到視覺推理的正確范式。效率只是證明了這個范式是對的。
03
未竟之事
DeepSeek在報告的局限性部分,坦誠地列出了當前方法存在的幾個問題。這些問題不是技術細節上的小瑕疵,而是指向了視覺推理的下一個階段。
第一個問題是觸發詞依賴。
報告里明確說,當前的“用視覺基元思考”能力需要顯式的觸發詞(explicit trigger words)才能激活。也就是說,模型還不能自然、自主地決定“什么時候該畫框、打點”。
它意味著模型還沒有真正學會判斷什么時候需要使用視覺基元,什么時候用語言就夠了。
理想的情況是,模型應該能根據任務的性質自主決策。但當用戶問“數一數圖里有幾只狗”的時候,模型應該自動切換到視覺基元模式,用邊界框來輔助計數。
從技術上說,這需要在模型里建立一個元認知層。這個元認知層可以評估當前任務的復雜度,判斷純語言推理是否足夠,決定是否需要調用視覺基元。
DeepSeek目前還沒有實現這個元認知層,但他們已經明確了方向。未來的版本可能會讓模型學會自主決定推理策略,而不是依賴外部觸發。
第二個問題是分辨率限制。
報告提到,受輸入分辨率限制,模型在細粒度場景下的表現還不夠好,輸出的視覺基元有時不夠精確。
這個問題和DeepSeek的效率優先策略有關。為了控制token數量,他們限制了視覺token的范圍在81到384之間。對于超出這個范圍的圖像,會進行縮放處理。
這種設計在大部分場景下是合理的,但在一些需要極高精度的任務上就會遇到瓶頸。比如醫療影像分析需要識別微小的病灶,工業質檢需要發現細微的瑕疵,這些場景對分辨率的要求很高。
DeepSeek在報告里提到,這個問題可以通過整合現有的高分辨率方法來解決。也就是說,他們的視覺基元框架和傳統的高分辨率裁剪方法不是對立的,而是互補的。
我覺得DeepSeek可以出個混合方案。
具體就是對于大部分常規任務,使用壓縮的視覺表征和視覺基元推理,保持高效率。對于需要細粒度分析的局部區域,動態調用高分辨率裁剪,提取更詳細的視覺信息。這樣既保持了整體效率,又滿足了局部精度需求。
這種混合方案的關鍵是讓模型學會判斷哪些區域需要高分辨率處理。于是這就又回到了剛才元認知的問題上。
第三個問題是跨場景泛化。
![]()
報告提到,用點作為視覺基元來解決復雜拓撲推理問題仍然很難,模型的跨場景泛化能力有限。
這個問題在迷宮導航和路徑追蹤任務上表現得比較明顯。雖然DeepSeek在自己構建的測試集上達到了66.9%和56.7%的準確率,超過了其他模型,但這個數字本身還不夠。
更重要的是,這些任務都是在合成數據上訓練和測試的。迷宮是用算法生成的,路徑追蹤的曲線也是程序化繪制的。當模型遇到真實世界里的拓撲推理問題時,比如在真實地圖上規劃路徑,在復雜管線圖里追蹤連接關系,表現可能會下降。
DeepSeek的方法是通過大規模、高多樣性的數據來提升泛化能力。他們爬取了97984個數據源,經過嚴格過濾后保留了31701個,最終得到超過4000萬個樣本。在迷宮和路徑追蹤任務上,他們也設計了多種拓撲結構、視覺風格、難度等級,試圖覆蓋盡可能多的變化。
然而數據多樣性只是泛化能力的一部分。模型是否真正理解了拓撲推理的本質?還是說它只是記住了訓練數據里的模式而已?
另外,DeepSeek的視覺基元是一套新的表征系統,需要專門的數據格式、訓練流程、評估方法。這和現有的多模態生態不完全兼容。
大部分多模態數據集和評測基準都是基于傳統的“圖像+文本”范式設計的,沒有考慮視覺基元。如果要在這些基準上評測DeepSeek的模型,要么需要關閉視覺基元功能,要么需要重新設計評測方法。
其他研究者如果想復現或改進這個工作,需要重新構建整個數據和訓練流程,門檻比較高。
DeepSeek能在報告中談及這些問題,說明他們對自己的工作有清醒的認識。
這可能比給出完美答案更有價值。因為真正推動社會進步的,往往不是答案,而是問題。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.