DeepSeek V4 on KnightLi的博客

DeepSeek-V4 KV Cache 機制解析：為什麼 1M 上下文更省顯存

Mon, 18 May 2026 18:38:26 +0800

長上下文模型真正貴的地方，往往不是「能不能塞進 100 萬 Token」，而是推理時 KV Cache 要占多少顯存。

在 Transformer 解碼過程中，每生成一個新 Token，模型都要保留歷史 Token 對應的 Key 和 Value。上下文越長，KV Cache 越大；KV Cache 越大，顯存、記憶體頻寬、首字延遲和吞吐都會被拖慢。

DeepSeek-V4 的特別之處，是它沒有只在注意力頭數量上省快取，而是把壓縮進一步推進到序列長度維度。按照 Hugging Face 對 DeepSeek-V4 技術報告的解讀，在 1M Token 場景下，DeepSeek-V4-Pro 的 KV Cache 約為 DeepSeek-V3.2 的 10%；如果和常見的 bf16 GQA 架構相比，約為其 2% 左右。

這就是 DeepSeek-V4 快取機制最值得看的地方：它不是簡單把 KV 存得更小，而是減少需要長期保存和檢索的 KV 條目數量。

先看幾代 KV Cache 優化路線

KV Cache 優化大致可以分成幾條路線。

第一類是傳統 MHA，也就是 Multi-Head Attention。每個 Query 頭通常都有對應的 Key/Value 頭。它結構直接，但長上下文下快取隨序列長度線性成長，顯存壓力最大。

第二類是 GQA，也就是 Grouped Query Attention。多個 Query 頭共享較少的 Key/Value 頭。LLaMA、Mistral、Qwen 等很多現代模型都採用類似思路。它能顯著減少 KV 頭數量，是目前主流長上下文模型的常見節省手段。

第三類是 MLA，也就是 Multi-head Latent Attention。DeepSeek-V2、DeepSeek-V3 使用這一路線，把 Key/Value 壓縮成低秩潛在表示，從注意力頭維度進一步降低快取占用。

第四類就是 DeepSeek-V4 引入的混合壓縮注意力。它把重點放到序列長度維度：不是只減少每個 Token 要存多少 KV，而是把多個歷史 Token 壓縮成更少的 KV 條目，再用稀疏或稠密方式檢索。

可以粗略理解為：

MHA：每個頭都認真記。
GQA：多個 Query 頭共享一部分記憶。
MLA：把每個 Token 的 KV 表示壓成潛在向量。
DeepSeek-V4：把很多歷史 Token 聚合成更少的壓縮記憶塊。

DeepSeek-V4 的關鍵變化：從頭維度壓縮到序列維度壓縮

GQA 和 MLA 主要是在「每個 Token 存多少 KV」上做優化。這個方向很有效，但當上下文長度來到 1M Token 時，問題會變得更極端：即使每個 Token 的快取已經很小，Token 數量本身仍然太多。

DeepSeek-V4 選擇把舊上下文壓縮成塊。也就是說，模型不一定要為每個很久以前的 Token 都保留完整 KV，而是讓多個 Token 形成壓縮條目。

這有點像讀一本很長的書：剛讀過的幾頁你會記得細節，前面幾章則更多以摘要、主題和關鍵線索的形式保存。DeepSeek-V4 的注意力機制也有類似分工：近處保留細節，遠處用壓縮表示。

CSA：4 倍壓縮加稀疏檢索

CSA 全稱是 Compressed Sparse Attention，可以理解為較細粒度的長程壓縮機制。

在 CSA 中，模型會把序列中的若干相鄰 Token 壓縮成更少的 KV 條目。Hugging Face Transformers 文件裡給出的預設壓縮率是 m=4，也就是大致每 4 個 Token 形成一個壓縮條目。

但它不是簡單平均。CSA 使用帶學習能力的壓縮池，並結合重疊窗口，讓模型在壓縮時保留更有用的資訊。壓縮之後，查詢並不會對所有歷史壓縮塊都做完整注意力，而是先透過 Lightning Indexer 打分，挑出最相關的 top-k 壓縮塊，再進入核心注意力計算。

這個結構有兩層收益：

歷史 KV 條目數量先變少。
每次查詢只看最相關的一部分壓縮塊。

所以 CSA 適合處理遠距離但仍需要細節檢索的上下文，比如程式碼庫、長文件、工具呼叫歷史裡的關鍵資訊。

HCA：128 倍壓縮加稠密注意力

HCA 全稱是 Heavily Compressed Attention，壓縮更激進。

Transformers 文件裡給出的預設壓縮率是 m'=128。也就是說，HCA 會把更長的一段上下文壓成一個壓縮條目。壓縮後的序列已經很短，因此它不需要像 CSA 那樣再做稀疏 top-k 檢索，而是讓 Query 對所有 HCA 壓縮條目做稠密注意力。

HCA 的作用更像全局摘要。它不追求保留每個細節，而是用極低成本覆蓋很長的歷史範圍，讓模型對全局背景、長程主題和遠處資訊保持感知。

如果把 CSA 比作「可檢索的壓縮筆記」，HCA 更像「全局目錄和摘要」。

滑動窗口：最近上下文仍保留細節

DeepSeek-V4 並不是把所有上下文都壓縮掉。

在 CSA 和 HCA 之外，它還保留了滑動窗口分支，用來處理最近的一段未壓縮上下文。Transformers 文件裡提到，DeepSeek-V4 的 attention block 會把長程壓縮分支與滑動窗口 K/V 拼接在一起。

這個設計很重要。生成下一個 Token 時，最近幾十到幾百個 Token 往往最關鍵：變數名、函式簽名、正在寫的句子、剛返回的工具結果、最近使用者要求。它們如果被過度壓縮，輸出品質會明顯下降。

所以 DeepSeek-V4 的思路不是「全部壓縮」，而是：

近處：保留未壓縮細節。
中遠處：用 CSA 做可檢索壓縮。
更遠處：用 HCA 做重度全局壓縮。

混合層棧：不同層做不同注意力

DeepSeek-V4 不是在所有層裡使用同一種注意力。

Hugging Face 的 DeepSeek-V4 文章提到，V4-Pro 的 61 層結構中，前兩層使用 HCA，之後的層在 CSA 和 HCA 之間交替，末尾的 MTP block 使用滑動窗口。Transformers 文件也說明，V4-Pro 預設是 2 層 HCA bootstrap 加交替 CSA/HCA。

這說明 DeepSeek-V4 把注意力機制當成分層系統來設計。不同層承擔不同資訊流角色：有的層更偏全局壓縮，有的層更偏稀疏檢索，有的部分保留局部窗口。

相比所有層統一使用一種注意力，這種混合結構更複雜，但也更適合 1M Token 這種極長上下文。

FP8 和 FP4 進一步降低快取成本

DeepSeek-V4 的快取節省不只來自壓縮率。

Hugging Face 的文章提到，V4 的大部分 KV 條目使用 FP8 儲存，RoPE 相關維度保留 BF16，而 CSA 裡的 Lightning Indexer 使用 FP4。壓縮比例、低精度儲存、稀疏檢索疊加在一起，才形成了非常低的 KV Cache 占用。

這也提醒我們：不要只看「上下文長度 1M」這個宣傳數字。真正決定可部署性的，是長上下文下的顯存占用、頻寬壓力、推理延遲和工程實現。

和其他模型的差異

與傳統 MHA 相比，DeepSeek-V4 不再為長歷史裡每個 Token 保留完整注意力記憶，快取壓力下降非常明顯。

與 GQA 相比，DeepSeek-V4 不只是減少 KV head 數量，還減少長歷史的 KV 條目數量。GQA 仍然要隨序列長度線性累積快取，而 V4 會把遠處上下文壓成塊。

與 DeepSeek-V3 的 MLA 相比，V4 的重點從「每個 Token 的表示更緊湊」進一步擴展到「歷史 Token 數量也被壓縮」。MLA 已經大幅降低單 Token KV 占用，但面對百萬級上下文時，序列長度本身仍是壓力來源。

與普通稀疏注意力相比，DeepSeek-V4 的 CSA 是先壓縮再稀疏檢索，索引器面對的是更短的壓縮序列；HCA 則透過 128 倍壓縮讓全量稠密注意力也變得便宜。

對 Agent 和長任務有什麼意義

Agent 工作流特別吃長上下文：它會讀文件、呼叫工具、接收工具返回、生成計畫、修正計畫、繼續呼叫工具。上下文越長，KV Cache 越容易成為瓶頸。

DeepSeek-V4 這種快取機制的潛在價值在於：

更容易承載長程式碼庫、長文件、多輪工具呼叫歷史。
首字延遲和吞吐更不容易被 KV Cache 拖垮。
同等硬體上可以跑更長上下文或更多並發請求。
對百萬 Token 場景，部署成本更接近實際可用，而不是只停留在論文指標。

不過也要注意，壓縮注意力不是免費午餐。把歷史 Token 壓縮成塊，必然涉及資訊取捨。模型需要在「省顯存」和「保留可檢索細節」之間做平衡。真正效果還要看任務類型：程式碼定位、法律文件、長篇問答、Agent 工具鏈，對細節召回的要求並不一樣。

不要把 2% 理解成所有成本都降到 2%

「KV Cache 約為 GQA 的 2%」很容易被誤讀。

它主要指 KV Cache 顯存規模，不等於總推理成本只剩 2%，也不等於所有場景速度都會提升 50 倍。推理還包括模型權重讀取、MoE 路由、前饋網路、注意力計算、調度開銷、通訊開銷等。

Hugging Face 的文章裡也把兩個數字分開講：在 1M Token 場景，DeepSeek-V4-Pro 相對 DeepSeek-V3.2 的單 Token 推理 FLOPs 是 27%，KV Cache 是 10%。這說明快取和計算是兩個不同維度。

所以更穩妥的說法是：DeepSeek-V4 讓超長上下文的 KV Cache 壓力顯著降低，從而改善百萬 Token 場景的部署可行性；但具體吞吐和延遲仍取決於實現、硬體、批處理、量化和推理框架。

小結

DeepSeek-V4 的快取機制和其他大模型最大的不同，是它把 KV Cache 優化從注意力頭維度推進到了序列維度。

GQA 是少存一些 KV 頭，MLA 是把每個 Token 的 KV 表示壓得更緊，DeepSeek-V4 則進一步把遠處 Token 聚合成壓縮塊，並透過 CSA、HCA、滑動窗口和低精度儲存組合起來，讓百萬 Token 上下文不再被 KV Cache 輕易卡死。

這不是單一技巧，而是一整套長上下文推理架構：近處保細節，遠處做壓縮，需要細節時稀疏檢索，需要全局時重度摘要。

對開發者和 Agent 應用來說，它的意義很直接：長上下文不只是「能輸入更多」，還要「跑得起、跑得穩、成本能接受」。DeepSeek-V4 真正改變的，正是這一點。

參考資料

DeepSeek V4 Flash 做 Godot 遊戲 Demo：幾毛錢能跑通到什麼程度？

Wed, 06 May 2026 09:22:18 +0800

DeepSeek V4 Flash 用來開發 Godot 遊戲 Demo，到底能不能打？

重點很直接：它能不能做出一個可執行、可觀察、帶物理效果的 Godot 小 Demo。

結論先說：可以跑通，效果不算商業級，但已經足夠作為玩法原型和物理互動 Demo 使用。更重要的是，成本非常低，適合快速驗證想法。

Demo 表現

這個 Demo 的重點是物理互動。

幾個比較直觀的效果包括：

繩子可以被切斷。
箱子會掉到地上。
調大質量後，箱子碰撞會更猛烈。
繩子表現出比較明顯的彈性。
調整摩擦力和彈性後，箱子會出現明顯的滑動和反彈。

從呈現效果看，它已經不是「只生成幾段 Godot 腳本」那麼簡單，而是一個能執行、能觀察物理表現的小型原型。

可用程度

這個 Demo 的價值在於「能跑、能看、能改」。它不是完整遊戲，也不是可以直接商業化的工程，但已經能說明幾個問題：

DeepSeek V4 Flash 能理解 Godot Demo 的基本目標。
AI Agent 可以把需求轉成可執行工程。
Godot 物理互動這種非網頁類任務，已經可以進入低成本原型階段。
對個人開發者來說，它能把「想法」快速變成「能看的東西」。

如果目標是做一個正式遊戲，它當然還不夠；但如果目標是驗證「這個玩法有沒有意思」「物理效果大概能不能做出來」，這個 Demo 已經可用。

成本意義

最值得關注的不是畫面有多精緻，而是成本。

如果一個 Godot 物理 Demo 只需要幾毛錢級別的模型成本，就能得到一個可執行版本，那麼它的意義就不是替代專業遊戲開發，而是大幅降低原型試錯成本。

以前想驗證一個小遊戲想法，至少需要自己熟悉 Godot、寫腳本、調場景、調物理參數。現在可以先讓 AI Agent 生成一個可執行版本，再由人判斷方向對不對。

對獨立開發者來說，這類低成本試錯很有用：

快速驗證玩法概念。
生成臨時 Demo 給別人看。
探索 Godot API 和物理系統。
把想法轉成能跑的初版工程。
在不確定方向前減少手寫程式碼成本。

DeepSeek V4 Flash 的表現

比較值得注意的是，使用的是 DeepSeek V4 Flash，而不是更貴、更重的旗艦模型。

它在「低成本原型」這個定位上表現不錯。它不是最強、最穩、最適合交付生產工程的模型，但在預算敏感、想快速試一下方向的場景裡，很有吸引力。

適合什麼場景

DeepSeek V4 Flash + Agent + Godot 更適合下面這些任務：

小型玩法原型。
物理效果 Demo。
UI 或互動概念驗證。
教學示例。
輔助理解 Godot 專案結構。
生成第一版可執行工程。

不太適合直接承擔這些任務：

大型遊戲架構。
複雜角色控制器。
網路同步。
商業專案核心程式碼。
高精度物理模擬。
不經過人工測試的自動提交。

換句話說，它適合做「第一稿」和「試驗場」，不適合當生產工程負責人。

這說明了什麼

這說明，AI 程式設計正在從網頁、腳本、後端介面，繼續向遊戲開發和互動原型擴展。

過去遊戲開發的門檻很高，尤其是引擎、腳本、資源管理和物理系統混在一起時，新手很容易卡住。現在模型加 Agent 工具，可以先把工程搭起來，讓開發者把注意力放在玩法判斷和效果調優上。

它帶來的變化可能有三點：

第一，遊戲原型會更便宜。很多想法不用等到完整開發階段才驗證，可以先得到可執行 Demo。

第二，獨立開發者會更敢嘗試。不會 Godot 的人，也可以借助 AI 先摸到專案結構和基本流程。

第三，模型穩定性會變得更重要。遊戲開發不是只要程式碼能跑，還要效果合理、手感正常、參數可控。未來誰能更好地結合實際畫面和執行狀態，誰就更適合做這類任務。

小結

DeepSeek V4 Flash 做 Godot Demo，可以概括成一句話：效果不完美，但足夠便宜、足夠快，也足夠適合做原型。

它離商業遊戲還很遠，但如果目標是用極低成本驗證一個小遊戲想法，它已經很有價值。

對個人開發者來說，最現實的用法不是把遊戲全交給 AI，而是讓 AI 先給出能跑的工程，再由人負責判斷、取捨和打磨。這樣用，DeepSeek V4 Flash 這類低成本模型反而會很香。

本地部署 DeepSeek V4：Pro、Flash 與 Base 版本顯存占用估算表

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 和 Gemma 4 的本地部署不是一個量級。 Gemma 4 的 26B、31B 還能討論 24GB、32GB 顯卡怎麼選量化版；DeepSeek V4 則是超大 MoE 模型，真正完整本地部署時，顯存需求會直接進入多卡工作站或伺服器級別。

官方發布的 DeepSeek V4 Preview 主要包含兩個推理版本：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

Hugging Face 官方 collection 裡還包含兩個 Base 版本：

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

這篇只討論完整載入模型權重時的大致顯存門檻。 MoE 的 active params 主要影響每個 token 的計算量，不等於只需要載入這部分參數。如果沒有專家按需載入、CPU/NVMe offload、分散式推理或專門執行時最佳化，顯存仍然要按完整權重來估。

先看結論

顯存規模	能比較現實地嘗試什麼	不建議期待什麼
24GB	不能完整跑 DeepSeek V4；只能跑小型蒸餾模型或 API	V4-Flash / V4-Pro 完整本地載入
48GB	仍不適合完整載入；可做小模型或遠端 API 用戶端	V4-Flash Q4 穩定執行
80GB	理論上可嘗試 V4-Flash Q2/Q3 或強 offload	V4-Pro
128GB	V4-Flash Q4 比較現實；Q5/Q6 仍緊	V4-Pro Q4
192GB	V4-Flash FP8/Q6 更從容；Pro Q2 勉強進入討論	V4-Pro Q4
256GB	V4-Flash FP8 比較穩；Pro Q2/Q3 可實驗	V4-Pro Q5 以上
512GB	V4-Pro Q4 開始進入可討論範圍	V4-Pro FP8
1TB+	V4-Pro FP8、Pro-Base 低位寬更現實	單機低成本部署
2TB+	Pro-Base FP8 級別	普通工作站部署

如果你的目標是個人電腦本地執行，DeepSeek V4 並不是合適對象。更現實的路線是：

用 DeepSeek 官方 API 或相容服務；
等社群穩定的 GGUF/EXL2/MLX 量化和推理支援；
使用更小的 DeepSeek 蒸餾模型；
或者把本地模型換成 Qwen、Gemma、Llama 等 7B 到 70B 級別模型。

官方權重體積

以下是 Hugging Face 官方倉庫的 model.safetensors.index.json 中統計到的權重總量。它反映的是目前公開權重檔案大小，不等於長上下文執行時的完整顯存占用。

模型	參數規模	官方權重體積	說明
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	推理版，體積相對最小
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	推理版，能力更強，體積巨大
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base 版，更接近全量 FP8 權重體積
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base 版，約 1.6TB 級別

可以看到，即使是最小的 V4-Flash，官方權重也已經接近 160GB。這就是為什麼它不能按「13B active params」理解成 13B 小模型。

DeepSeek V4 Flash 顯存估算

V4-Flash 是 DeepSeek V4 裡最適合本地嘗試的一檔。但「最適合」只是相對 Pro 而言，它仍然不是消費級單卡模型。

下面按官方 159.61GB 權重體積做折算。其中 Q4/Q3/Q2 是按位寬估算，不代表目前已經有穩定可用的官方 GGUF 版本。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	159.61GB	192GB	256GB	多卡伺服器、推理服務
`Q6`	120GB	160GB	192GB	品質優先的量化嘗試
`Q5`	100GB	128GB	160GB	品質和體積折中
`Q4`	80GB	96GB	128GB	Flash 本地化較現實的起點
`Q3`	60GB	80GB	96GB	大顯存單卡或多卡實驗
`Q2`	40GB	48GB	64GB	極限低位寬實驗，品質風險明顯

如果未來社群出現成熟的 V4-Flash Q4，它大機率也不是 24GB 顯卡的模型。更現實的硬體起點是 96GB 到 128GB 級別的總顯存，或者依賴 CPU 記憶體/offload 換速度。

DeepSeek V4 Pro 顯存估算

V4-Pro 是旗艦推理版，官方權重體積約 864.70GB。即使做 4-bit 量化，完整權重也仍然是數百 GB 級別。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	864.70GB	1TB	1.2TB+	多機多卡推理服務
`Q6`	648GB	768GB	1TB	高品質量化服務
`Q5`	540GB	640GB	768GB	高品質與成本折中
`Q4`	432GB	512GB	640GB	Pro 本地化較現實的最低品質線
`Q3`	324GB	384GB	512GB	低位寬實驗
`Q2`	216GB	256GB	320GB	極限實驗，品質和穩定性風險高

對個人使用者來說，V4-Pro 更適合透過 API 使用。如果目標是完整本地部署，至少要把它當成多卡伺服器模型，而不是 4090、5090、RTX PRO 單卡模型。

DeepSeek V4 Flash-Base 顯存估算

Base 版通常用於研究、微調或繼續訓練，不是普通聊天部署的首選。 V4-Flash-Base 官方權重體積約 294.67GB。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	294.67GB	384GB	512GB	研究、訓練前處理、評測
`Q6`	221GB	256GB	320GB	高品質量化研究
`Q5`	184GB	224GB	256GB	品質和體積折中
`Q4`	147GB	192GB	224GB	Base 版低成本實驗
`Q3`	111GB	128GB	160GB	低位寬實驗
`Q2`	74GB	96GB	128GB	極限實驗

如果只是要使用 DeepSeek V4 能力，不建議從 Base 版開始。 Base 版的部署和調優成本更高，普通應用更適合推理版或 API。

DeepSeek V4 Pro-Base 顯存估算

V4-Pro-Base 是最重的一檔，官方權重體積約 1606.03GB。這已經是 1.6TB 級別的模型檔案。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	1606.03GB	2TB	2.4TB+	大規模研究叢集
`Q6`	1205GB	1.5TB	2TB	高品質量化研究
`Q5`	1004GB	1.2TB	1.5TB	研究與評測
`Q4`	803GB	1TB	1.2TB	低位寬研究
`Q3`	602GB	768GB	1TB	極限低位寬研究
`Q2`	402GB	512GB	640GB	極限實驗

這類模型不適合被放進「家用顯卡能不能跑」的框架裡討論。哪怕是 Q4，也已經超過絕大多數單機工作站的舒適範圍。

為什麼不能只看 active params

DeepSeek V4 是 MoE 模型。 MoE 的特點是每個 token 只啟用一部分專家，因此計算量會明顯低於總參數量。但這不等於顯存只需要放 active params。

完整本地推理通常還要考慮：

所有專家權重是否需要常駐 GPU；
是否支援按需專家載入；
CPU 記憶體與 GPU 顯存之間的資料搬運成本；
NVMe offload 的延遲；
KV cache 在長上下文下的增長；
1M context 場景下的額外執行時開銷；
多機多卡通訊成本。

所以，49B active 的 V4-Pro 不能當成 49B 模型來部署。 13B active 的 V4-Flash 也不能當成 13B 小模型來部署。

怎麼選

如果你只是普通個人使用者：

不建議完整本地部署 DeepSeek V4。
需要 DeepSeek V4 能力時，優先用官方 API。
需要本地私有化時，優先看是否有成熟推理服務商或內部多卡伺服器。
只有 24GB 到 48GB 顯存時，轉向 7B、14B、32B、70B 級別量化模型更實際。

如果你有 128GB 到 256GB 總顯存：

可以關注 V4-Flash Q4/Q5 是否有穩定社群實作。
不建議把 V4-Pro 當成主力本地模型。

如果你有 512GB 以上總顯存：

V4-Pro Q4 才開始進入工程驗證範圍。
仍然要關注推理框架、專家調度、KV cache、吞吐和並發。

DeepSeek V4 的本地部署重點不是「下載哪個量化檔案」，而是「有沒有足夠的系統級推理能力」。它更接近一個伺服器模型，而不是普通桌面模型。

參考來源

GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max 怎麼選

Tue, 28 Apr 2026 22:18:00 +0800

如果你現在只想知道一句話答案，那可以先記這個版本：

要最穩、最省時間，優先看 GPT 5.5
要頁面觀感、創意和展示感，Claude Opus 4.7 還是強
要看國產模型裡誰最接近第一梯隊，Qwen 3.6 Max 現在很有競爭力
DeepSeek V4 不是不能打，但波動比前面幾家更明顯

很多人問「現在最強編程 AI 到底是誰」，其實問到最後，通常不是在問排行榜，而是在問一件更實際的事：
我現在要寫頁面、做 demo、生成小工具、補互動，哪一個最容易一次就給我能用的東西。

從這個角度看，這幾家模型的差別已經很清楚了。

先說總判斷

如果把 GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max 放在一起看，綜合能力最穩的還是 GPT 5.5。

它不一定每次都是最花俏的那個，但它很少讓你明顯失望。速度快，第一次生成的完成度高，邏輯、互動、動效、小遊戲這一類綜合任務通常都比較順。

Claude Opus 4.7 的特點很不一樣。它最強的地方不是「最穩」，而是頁面氣質、UI 組織和展示感。很多時候你一打開它寫的東西，會先覺得「這個看起來像回事」。如果你更在意頁面呈現，它還是很值得看。

Qwen 3.6 Max 是這幾家裡最值得重新看的一個。它已經不是「國產裡能用」這個級別了，而是有些場景下真的能和 GPT 5.5 直接拼效果。尤其是前端頁面、視覺完成度、擬真感這些部分，它已經開始有明顯存在感。

DeepSeek V4 的問題不是完全不行，而是不夠穩。它能寫出來的時候並不弱，甚至有些場景還不錯，但上下限差得比另外幾家更明顯。你有時候會覺得它挺能打，有時候又會覺得怎麼突然掉下去了。

`GPT 5.5` 強在哪

如果你平時最常做的是這些事：

直接生成一個完整網頁
做帶動效的小 demo
寫有一點邏輯的互動頁面
生成小遊戲或多狀態互動
想盡量少返工

那 GPT 5.5 基本還是最穩的答案。

它的優勢主要有幾個：

出代碼速度快
第一次成品可用度高
邏輯和互動比較少出硬傷
綜合題表現穩定

說得更直接一點，GPT 5.5 最像一個「你把需求丟過去，它大概率能先把地基搭對」的模型。
很多人真正缺的不是某一項最驚艷，而是第一版別翻車。這件事上它現在還是最讓人省心。

當然，它也不是完全沒有短板。

某些偏視覺表現的頁面，不一定是最有驚喜的
有時候太穩了，反而少一點設計感上的記憶點

所以如果你問「要一個預設推薦」，那還是 GPT 5.5。
但如果你問「要不要只看它」，答案也不是。

`Claude Opus 4.7` 適合什麼人

Claude Opus 4.7 這類模型的吸引力，更多來自頁面觀感。

它的長處通常是：

UI 結構更順
視覺表現更完整
某些頁面更有展示感
在可視化和創意感上更容易出彩

如果你讓模型去做的是這些東西：

演示頁面
數據展示頁面
強調觀感的小網頁
想要一打開就「看起來比較高級」的結果

那 Claude 依然值得進前排。

不過它的問題也一直比較明顯：

穩定性不如 GPT 5.5
有時看著不錯，但細節邏輯會偏掉
個別場景裡會出現功能能跑，但核心體驗不夠準的情況

所以 Claude 更像一個有審美加成的前端型選手。
你要是更看重頁面「長得好不好」，它很有優勢；你要是最怕第一次輸出就出邏輯問題，那還是得更謹慎一點。

`Qwen 3.6 Max` 為什麼值得認真看

這幾家裡，Qwen 3.6 Max 給人的最大變化感最明顯。

以前很多人看國產編程 AI，更多是抱著「能不能跟上」的心態。現在看 Qwen 3.6 Max，已經是另一種問題了：
它在一些前端直出場景裡，到底能不能直接和國外頭部模型打。

它現在比較突出的地方有這些：

頁面觀感不錯
某些動效和擬真效果做得挺好
生成結果比較有完成感
有些題目裡，效果已經能接近甚至咬住 GPT 5.5

這說明一件事：
如果你的使用場景偏網頁、偏前端、偏展示結果，那 Qwen 3.6 Max 已經不是「備用選項」，而是可以認真放進主選名單的模型。

當然，它還沒有穩到完全沒有短板。

互動邏輯題上，偶爾還是會掉一點完成度
有些頁面很好看，但有些任務又會突然平一點
起伏比 GPT 5.5 還是大一些

但整體上，它現在的存在感已經非常強了。
如果你想知道「國產模型裡現在最該重點看誰」，那 Qwen 3.6 Max 很難繞開。

`DeepSeek V4` 現在處在什麼位置

DeepSeek V4 的情況稍微複雜一點。

它的問題不是完全做不好，而是你不太容易預判它這次會落在哪個區間。
有時候它能把事情做出來，觀感和功能都不算差；有時候遇到稍微複雜一點、同時要求動畫、邏輯、數據表現的任務，它又容易掉鏈子。

它目前給人的感覺更像這樣：

能力有
不算弱
某些題目可以交卷
但穩定性還不夠讓人完全放心

這就決定了它現在更適合什麼樣的人。

如果你願意多試幾次、能接受偶爾需要重來、或者你本來就會自己檢查和修代碼，那 DeepSeek V4 還是可以繼續用。
但如果你就是想少折騰、想把第一次生成成功率放在前面，那它現在還不是最穩的答案。

普通用戶到底該怎麼選

如果你不是做模型評測，而是真的想拿來幹活，那其實可以直接按用途選。

1. 想少折騰，想提高第一次成功率

選 GPT 5.5。

它最適合的就是「我給需求，你先給我一版能用的」。
尤其是你沒有太多時間來回調、反覆修的時候，它的綜合穩定性最有價值。

2. 更看重頁面展示感和視覺完成度

選 Claude Opus 4.7。

如果你想要的是一個看起來更像成品的頁面，或者你做的是偏演示型、展示型的東西，Claude 的優勢會更容易體現出來。

3. 想重點看國產裡最強的前端直出能力

優先看 Qwen 3.6 Max。

它現在已經不是「將就用」，而是真的可以拿來正面比較。
如果你的任務偏網頁、偏動效、偏展示，Qwen 的競爭力已經很實際了。

4. 能接受波動，想繼續觀察國產綜合能力

可以繼續看 DeepSeek V4。

它的問題不是沒實力，而是發揮不夠整齊。
如果後面穩定性繼續補上，它的存在感還會更強。

最後一句話

現在這幾家主流編程 AI，差距已經不再是「誰能寫、誰不能寫」，而是「誰更穩、誰更好看、誰更適合你的任務」。

如果你就想要一個最省事的答案，GPT 5.5 還是第一選擇。
如果你想要更強的展示感，Claude Opus 4.7 仍然很有味道。
如果你關心國產模型裡誰最值得認真看，Qwen 3.6 Max 現在已經站到很靠前的位置。
DeepSeek V4 則更像一個還在繼續補穩定性的強力選手。

真要壓成一句最短結論，就是：

最穩看 GPT 5.5，最有觀感看 Claude，國產裡最值得重點看的是 Qwen 3.6 Max。