DeepSeek 开「天眼」！识图模式灰度上线 + LiveBench 开源第一，V4 多模态全面解析

转载请注明出处：莫潇羽@无忆研习社（www.wuyi.wiki）

快速摘要

本文核心结论，先读这里，3 分钟抓住全部要点——

① 识图模式正式灰度推送： DeepSeek 在 2026 年 4 月 29 日悄然上线「识图模式」，这是真正的图像语义理解，而非以往只识文字的 OCR。当前仍在逐步推送阶段，尚未覆盖所有用户。

② 开源榜首实锤： DeepSeek-V4-Pro 在 LiveBench 以 73.58 分登顶开源模型排行榜，前 10 名全为闭源模型（GPT-5.5、Gemini 3.1 Pro、Claude Opus/Sonnet Thinking 系列等），V4-Pro 是开源阵营里最高的那一个。

③ V4 架构颠覆传统注意力机制： V4 引入 CSA（压缩稀疏注意力）+ HCA（高度压缩注意力）双轨混合机制，在 100 万 token 上下文下，推理算力消耗只有上代 V3.2 的 27%，KV 缓存只需 10%。

④ API 折扣续期至 5 月底： 原定 5 月 5 日到期的 2.5 折优惠延长至 5 月 31 日 23:59，缓存命中价格 0.025 元/百万 token，这是目前主流旗舰模型中极具竞争力的定价。

⑤ 操作要点： 调用 API 时需手动开启 1M 上下文（Model ID 末尾加 [1m]），并将推理强度设为 max，才能激活 V4-Pro 的完整能力。

往下读，有识图原理、技术架构深度拆解、API 代码示例与 LiveBench 完整数据分析。

一、那条被删掉又换掉的帖子

4 月 28 日下午，陈小康发了一条帖子。

他是 DeepSeek 多模态研究组的负责人，北京大学博士，主导了 Janus、JanusFlow、DeepSeek-VL2 等几乎全部 DeepSeek 多模态方向的核心项目。这位研究者在 DeepSeek 内部低调而高效，很少出现在公开媒体上，大多数时候只在技术社区和论文里留下署名。

帖子内容只有一句话：「Soon, we see you. 👀」，配图是两只 DeepSeek 标志性的蓝色鲸鱼——左边那只戴着黑色眼罩，右边那只睁开了眼。发完没多久，帖子就删了。

这种删帖，在 AI 圈是一种特殊的暗语。发帖是兴奋，删帖是谨慎——可能是发布时机还没到，也可能是功能还在最后的调试阶段。经历过 DeepSeek 历次发布节奏的人，一看这个删帖动作就知道：某件大事快来了。

沉默了 24 小时之后，同一个账号，原地换了一个词。

「Now, we see you. 👀」

有时候，「Soon」变成「Now」这短短的一个字的改动，代表着一整个团队长达数年的技术积淀终于落地。

与此同时，DeepSeek 官网和 App 的界面上，出现了一个全新的按钮选项：「识图模式」。它和「快速模式」「专家模式」并列摆放，位于输入框上方第三个位置。这个新按钮的出现，对于长期关注 DeepSeek 产品动态的用户来说，意义不亚于一次正式发布——多模态能力的产品化，终于走到了用户面前。

这不是 DeepSeek 第一次提供图片相关能力。早些时候，DeepSeek 支持过 OCR 文字识别，可以将图片中的文字提取出来。但那和「识图模式」是截然不同的两件事。此次灰度上线的，是真正意义上的图像语义理解——让模型「看懂」一张图，而不只是「读出」图里的字。

蓝色小鲸鱼，这下真的开了「天眼」。

二、先搞清楚：OCR 和「图像理解」差在哪里

在深入讲 DeepSeek 识图模式之前，有必要先把一个基础概念说清楚，因为不少人容易把这两件事混淆。

OCR：只认识「字」

OCR（Optical Character Recognition，光学字符识别）的核心任务，是把图片里的文字像素转换成可编辑的文本数据。它的工作原理，本质上是一种模式匹配——把图片里的像素块和已知字符字形进行比对，识别出「这里写的是什么字」。

OCR 技术已经相当成熟，各类扫描仪、手机 App 都内置了 OCR 功能。给它一张身份证照片，它能把姓名、证件号码完整地提取出来；给它一页书，它能把每行文字都转成文本。但是，OCR 根本不理解图片的内容。它看到一张风景照里有一块路牌，可以识别出路牌上的文字，但它不知道这是什么地方、路牌周围是山还是海、天气好不好、拍照的人站在哪个方向。

一张没有任何文字的图片，OCR 对它完全无能为力——它只能告诉你「图中无可识别的文字」。

图像理解：真正「看懂」图片

图像理解（Visual Understanding）完全不同。它的目标是让模型从图片的视觉内容中提取语义信息——理解场景、物体、关系、情绪、动作，乃至推理出图中没有直接展示的信息。

一个具备图像理解能力的模型，面对一张没有文字的拿铁咖啡照片，可以告诉你：这是一杯拿铁，杯子上有拉花，花型是心形，杯子放在一张木质咖啡桌上，桌子旁边有一本翻开的书，背景里有暖光灯源，整体氛围偏午后咖啡馆风格。

这背后的技术路线，和 OCR 完全不是一回事。图像理解依赖的是视觉编码器（Visual Encoder）将图像像素转化为高维向量表示，再经过跨模态对齐（Cross-modal Alignment），让语言模型的 Transformer 结构能够「阅读」这些视觉向量，从而产生与图像内容对应的自然语言输出。

从 OCR 到图像理解，是从「识字」到「看懂世界」的跃迁。

三、DeepSeek 多模态技术体系：从 VL2 到识图模式

DeepSeek 在多模态方向的技术积累，并非一夕之功。要读懂「识图模式」背后的技术底座，需要梳理 DeepSeek 多模态方向的几个关键里程碑。

DeepSeek-VL2：MoE 架构首次进入视觉语言领域

DeepSeek-VL2 是 DeepSeek 多模态研究最重要的前序成果之一。它将在大语言模型领域被广泛验证的 MoE（Mixture of Experts，混合专家）架构引入到视觉语言模型中，带来了显著的效率提升。

在 VL2 的框架下，模型并不是每次推理都激活全部参数，而是根据输入内容动态选择最合适的「专家子网络」进行计算。这意味着，面对一张图片，模型会自动判断：这张图里更多的是文字内容、图表结构，还是自然场景，然后调用相应擅长领域的专家网络来处理。

这种「按需分配算力」的机制，使得 VL2 在推理速度和理解质量之间取得了更好的平衡。它支持动态分块（Dynamic Tiling）图像处理策略，根据图像内容自适应地将图片分割为多个区块进行精细理解，这在处理包含细节文字或复杂图表的图片时尤为重要。

VL2 还具备上下文视觉定位能力，给定一张图片，无论是否有额外的视觉提示，模型都能在另一张图片中找到语义相关的目标区域，这是多图理解和视觉推理的基础能力。

Janus：解耦视觉编码，终结「理解-生成」的对立

在视觉语言模型的发展历史上，长期存在一个矛盾：图像理解和图像生成在视觉编码层面的需求是冲突的。

理解任务需要视觉编码器捕捉图像的高层语义，比如场景类型、物体关系、情感氛围，而生成任务需要视觉编码器保留图像的低层像素细节，比如纹理、色彩分布、结构几何。如果强行用同一个视觉编码器同时服务两件事，两者都会打折扣——这是大多数早期统一多模态模型的通病。

DeepSeek 提出的 Janus 框架，正面解决了这个问题。Janus 的核心思路，是将视觉编码路径解耦为两条独立的通道：

• 理解通道：使用针对语义理解优化的视觉编码器，负责从图片中提取「这是什么」的高层语义信息，输入到语言模型进行理解、问答、描述。
• 生成通道：使用针对像素保真优化的视觉量化编码器（Codebook），负责将图像量化为离散的视觉 token，用于后续的图像生成任务。

两条通道在语言模型主干之前分开处理，分别对齐各自任务的需求，再汇入统一的 Transformer 主干进行联合建模。这个架构被命名为 Janus，取自古罗马神话中拥有双面的神灵 Janus——一张面孔回顾过去，一张面孔眺望未来，恰好对应「理解」与「生成」两种方向。

从训练策略来看，Janus 采用三阶段训练：第一阶段只训练适配层（Adaptor），让视觉编码器的输出对齐到语言模型的嵌入空间；第二阶段进行统一预训练，联合优化理解和生成两个方向的损失；第三阶段进行监督微调，在高质量对话数据上精调指令跟随能力。这种分阶段的训练策略使得每个阶段的学习目标更加聚焦，避免了多目标同时优化时的梯度干扰。

解耦之后的效果是显著的：Janus 在多模态理解基准上的表现超过了同期其他统一多模态模型，同时在文本到图像生成任务上也保持了不亚于专用生成模型的质量。

JanusFlow：把整流流融入自回归框架

Janus 解决了理解与生成的解耦问题，JanusFlow 则在生成质量上迈出了更大的一步。

在 Janus 框架中，图像生成依赖的是自回归 token 预测——模型一个 token 一个 token 地预测出图像的离散编码，再解码成像素。这种方式的问题在于，生成过程缺乏连续性，难以精细控制像素级别的细节。

JanusFlow 将整流流（Rectified Flow）引入了这个框架。整流流是一种连续生成范式，通过学习从随机噪声到目标图像的直线路径来完成图像生成，比传统扩散模型的弯曲路径更短、更高效。JanusFlow 让自回归模型处理语义决策（这张图要画什么），让整流流处理像素细化（这张图具体长什么样），两者协同分工。

配合 SDXL-VAE 作为图像的连续编码解码器，JanusFlow 在 384×384 分辨率的图像生成上取得了明显优于前代 Janus 的视觉质量，且架构无需复杂改造，整个生成流直接嵌入现有大语言模型框架中。

Janus-Pro：数据与规模的双重升级

Janus-Pro 是在 JanusFlow 基础上的全面强化。主要升级体现在两个维度：

数据层面，多模态理解的预训练数据增加了约 9000 万条样本，涵盖图像描述（如 YFCC 数据集）、表格理解、图表解析、文档识别（如 Docmatix 数据集）等多个复杂场景。视觉生成方面，引入了约 7200 万条高审美合成数据，将真实数据与合成数据的比例调整为 1:1，从根源上解决了早期版本因真实数据噪声过大而导致的生成不稳定问题。

模型规模层面，Janus-Pro 将模型从 1.5B 参数扩展到 7B，验证了解耦视觉编码方法的可扩展性——更大的语言模型底座，在理解损失和生成损失上收敛都更快，效果更优。

正是在这一系列多模态技术积累的基础上，才有了今天「识图模式」的正式亮相。识图模式背后，站着的是整个 DeepSeek 多模态团队数年来在架构创新、数据工程上的持续投入。

四、识图模式：功能详解与上手指南

4.1 识图模式是什么

「识图模式」是 DeepSeek App 和网页端新增的第三种对话模式，与「快速模式」（处理简单任务，响应速度快）和「专家模式」（支持复杂推理，适合深度分析）并列显示在输入框上方。

它的定位是：上传图片，获得真正基于图像内容的理解与回答，而非简单的文字提取。根据已获得内测权限的用户反馈，识图模式具备以下核心能力：

• 场景描述：能够识别图片中的环境、氛围、物体和布局，输出自然语言描述。
• 内容分析：对图片中的信息进行深层解析，包括图表数据读取、场景推理、物体关系判断。
• 图片问答：用户可以就图片内容提问，模型会结合视觉信息给出针对性的回答。
• 文档图片处理：对包含表格、图示、手写内容的图片，能够结合视觉语义和文字信息进行整合理解，不局限于单纯的文字识别。

值得注意的是，识图模式目前仍处于灰度推送阶段，并非所有用户都能立即看到这个按钮。官方在功能说明中也标注了「图片理解能力内测中」的字样，意味着该功能仍在收集反馈、持续迭代。

4.2 如何进入识图模式（操作步骤）

对于已经灰度到「识图模式」的用户，具体操作流程如下：

网页端（chat.deepseek.com）：

• 打开 DeepSeek 官网，进入对话界面。
• 在输入框上方找到模式切换按钮区域，点击「识图模式」（第三个按钮，图标为眼睛形状）。
• 点击输入框左侧的图片上传按钮（回形针图标），选择本地图片文件。
• 上传完成后，在输入框中输入你的问题，回车发送即可。

App 端（iOS / Android）：

• 打开 DeepSeek App，进入新对话。
• 在底部工具栏切换至「识图模式」。
• 点击「+」号或图片图标，从相册选择图片，或直接拍照上传。
• 输入问题后发送。

目前支持的图片格式： JPG / PNG / WEBP / BMP 等常见格式均可，单张图片建议不超过 10MB。

小提示（莫潇羽@无忆研习社）： 如果你在界面上没有找到「识图模式」按钮，说明你的账号还没有被灰度到。可以尝试退出重新登录、清除缓存后刷新，或者等待官方全量推送。目前判断没有特定的触发条件，纯粹是随机灰度分批推送。

4.3 实测：各大模型的「数手指」难题

在识图模式上线后，社区里流传最广的一个测试案例，是经典的「数手指」问题——给模型看一张人手的图片，让它数出图中手指的数量。

这道题之所以难，在于它对空间感知和遮挡关系推理有较高要求。手指的排列方式、弯曲程度、相互遮挡，都需要模型在视觉层面进行精确的空间分析。

实测结果如下：

从这个测试可以得到几个结论：

第一，DeepSeek 识图模式并非无懈可击，在某些对空间精确感知要求极高的任务上仍有不足。第二，这道题对目前几乎所有主流模型来说都是难题，DeepSeek 不是唯一答错的。第三，即便答错了手指数量，DeepSeek 对图片整体内容的描述是准确的——它知道这是一只手，能描述手的姿势和背景，这已经远超 OCR 能做的事情。

Gemini 系列目前在精细视觉感知方面的优势相对明显，这与 Google 多年来在视觉 AI 领域的深厚积累有关。DeepSeek 识图模式还处于内测阶段，后续仍有大量优化空间。

4.4 识图模式的能力边界

理解一项新功能的上限，同样重要。目前来看，识图模式在以下场景中表现较为出色：

• 图片内容描述和场景理解（效果较好）
• 图表和数据可视化内容的读取与分析（中等偏上）
• 图文混合文档（如截图笔记）的整合理解（效果较好）
• 手写字迹识别（依赖笔迹清晰度，表现参差）

在以下场景中，识图模式目前仍存在明显局限：

• 精确的空间位置判断（手指数量、像素级定位）
• 极细微的视觉差异辨别（如两张相似图片的细节对比）
• 动态内容（视频帧）理解（目前仅支持静态图片）
• 超高分辨率图片的完整细节保留

这些局限，大部分来自当前视觉编码器的分辨率上限和空间建模能力，属于整个行业在多模态领域面临的共同挑战，而非 DeepSeek 独有的问题。

4.5 识图模式的实战使用技巧

对于已经内测到识图模式的用户，以下几点实战经验（莫潇羽@无忆研习社整理）可以帮助你更高效地使用这个功能：

提问要具体，别丢给它一张图让它「自由发挥」。 模型面对一张图时，需要知道你关心的是什么。问「这张图里有什么」和问「这张架构图里数据库和应用服务器之间的箭头含义是什么」，得到的回答质量相差悬殊。越具体的提问，越能引导模型把注意力集中到你真正需要的区域。

上传图片前先做基本处理。 如果图片分辨率过低（低于 800×600），或者存在严重的光线不足、运动模糊，识别质量会明显下降。对于截图类内容，确保截图清晰、文字大小合适；对于实拍图，确保拍摄稳定、主体清晰。

复杂文档类图片，最好拆分上传。 如果一张图里同时有大量文字、表格、图示三种内容，模型的注意力可能分散。把一份报告截成多张分块图，针对每块分别提问，往往比把整份文档截成一张大图、让模型全部分析效果更好。

结合专家模式使用效果更佳。 目前识图模式和专家模式是独立的两个按钮，但很多需要图像理解的任务同时也需要深度推理。如果你上传的是一张数学几何题的图片，希望模型给出完整解题过程，可以先用识图模式描述出题目条件，然后切换到专家模式让它完成推理。未来这两种能力更深度融合后，使用体验会更流畅。

不要期望它做「计数」类任务。 正如前文「数手指」测试所揭示的，当前多模态模型普遍在精确计数方面存在不足。如果你的任务核心是「数清楚这里有几个」，建议配合人工核对，或者等模型后续迭代版本。

4.6 为什么图像理解比文字处理难得多

很多人看到识图模式之后，第一反应是「这不就是 GPT-4V 早就有的东西吗」。但理解「为什么图像理解对语言模型来说比文字处理难得多」，有助于正确设定对这项功能的预期。

对于大语言模型来说，文字输入天然就是离散 token 序列——「你好世界」可以直接被分词为 ["你", "好", "世", "界"] 这样的离散符号，再通过 Embedding 查表转化为向量。整个处理流程天然契合 Transformer 的自注意力机制。

但图片不是这样工作的。一张 512×512 的图片，包含 262144 个像素，每个像素有 RGB 三个通道，原始信息量远超同等篇幅的文字。更重要的是，图片的信息是空间结构化的——哪个物体在图片左侧，哪个在右侧，哪两个物体存在遮挡关系，这些空间关系需要模型在处理时明确建模，而语言模型的 Transformer 架构天然只擅长处理序列中的位置关系。

因此，多模态模型需要在语言主干前额外插入一个视觉编码器，把二维图像信息压缩并转化为语言模型能够「读懂」的一维向量序列，这个转化过程不可避免地会有信息损耗。如何在编码压缩率和信息保留度之间取得最优平衡，是多模态研究的核心难题之一，也是各家模型在视觉感知精度上存在差异的根本原因。

DeepSeek-VL2 引入的动态分块（Dynamic Tiling）策略，正是在尝试应对这个问题——针对高分辨率图像，自适应地将其分割为多个区块，每个区块独立编码后再融合，最大程度保留原始图像的细节信息，减少因过度压缩导致的精度损失。

五、V4 的技术架构深度拆解

识图模式是 V4 时代多模态能力的外在体现，而支撑它的底层技术架构，同样值得深入了解。V4 系列在架构层面做出了若干重要创新，使其在性能和效率上实现了双重突破。

5.1 MoE 稀疏专家架构：大而不笨

DeepSeek-V4-Pro 的总参数量达到 1.6 万亿（1.6T），这是一个相当庞大的数字。但和很多人的直觉相反，参数多并不意味着每次推理都要把这 1.6T 参数全部跑一遍。

V4 采用的是 MoE（Mixture of Experts，混合专家）架构。这个架构的核心逻辑是：把整个模型分成许多个「专家子网络」，每次接收到一个输入 token 时，由一个轻量级的「路由器」决定激活其中的几个专家来处理这个 token，其他专家处于休眠状态。

用一个更直观的类比来理解：假设你面前有 1600 位各领域专家，每当你提出一个问题，不是所有 1600 位专家一起回答，而是由一位「调度官」根据问题内容，快速筛选出最匹配的 49 位专家，由他们协作给出答案。问的是数学题，就调数学专家；问的是代码问题，就调编程专家；问的是法律相关，就调法律知识专家。其他 1551 位专家在这次回答中不被激活，节省了大量计算资源。

具体到 V4-Pro，每次推理实际激活的参数只有 49B，而不是全部的 1.6T。这意味着：

• 模型拥有 1.6T 参数带来的庞大知识储量和泛化能力
• 但每次推理的实际计算量相当于一个 49B 的密集模型

这种「大而省」的设计，是 DeepSeek 能够在保持世界级性能的同时将推理成本压到极低水平的核心原因之一。V4-Flash 版本的参数规模更小，总参数 284B，激活参数 13B，进一步降低了部署门槛。

在 1M token 的超长上下文场景下，V4-Pro 的单 token 推理 FLOPs 只有 V3.2 的 27%，KV 缓存只有 10%。换句话说，上下文容量扩大了近 8 倍，实际单次 token 的计算成本却下降了。这个反常识的结论，正是 CSA+HCA 混合注意力机制和 MoE 稀疏激活共同作用的结果。

5.2 CSA + HCA：百万上下文的秘密

一百万 token 的上下文窗口，意味着模型可以一次性处理约 75 万个汉字或约 75 万个英文单词的文本。这在一年前还是 Gemini 独家的「王牌功能」，如今 V4 让它成为标配，靠的是一套全新的注意力机制。

传统的注意力机制（Attention）有一个天然缺陷：处理长序列时，每个 token 都需要与所有历史 token 做一次注意力计算，计算量随序列长度的平方增长。序列从 128K 扩展到 1M，计算量会爆炸式增加到约 60 倍。

V4 引入了 CSA（Compressed Sparse Attention，压缩稀疏注意力） 和 HCA（Heavily Compressed Attention，高度压缩注意力） 两种新型注意力机制，交错堆叠在模型层中：

CSA 的工作原理：

每隔 (m=4) 个 token，将它们的 KV（键值）缓存压缩合并为 1 个条目，然后在计算注意力时，每个查询 token 只需要关注 (k=512\sim1024) 个压缩后的 KV 条目（由 Lightning Indexer 轻量索引器动态选出最重要的块），而不是全部历史条目。序列长度在进入注意力计算之前，就被压缩到了 (1/m)。

HCA 的工作原理：

HCA 采用更激进的压缩率，每 (m'=128) 个 token 压缩为 1 个，但在压缩后的序列上保持全量稠密注意力（不进行稀疏化）。HCA 适用于信息密度较低、局部依赖程度较弱的上下文区段。

CSA 与 HCA 在模型层中交错排布，兼顾效率（减少 KV 缓存）与表达力（保留必要的全局信息）。

最终效果是：在 1M token 上下文设置下，V4-Pro 的单 token 推理 FLOPs 只有 V3.2 的 27%，KV 缓存只有 V3.2 的 10%。 上下文窗口从 128K 扩展到了约 8 倍，但单 token 算力需求反而下降了。

5.3 mHC 流形约束超连接：强化层间信号传递

V4 还引入了 mHC（Manifold-Constrained Hyper-Connections，流形约束超连接） 来替代传统的残差连接（Residual Connection）。

残差连接是 Transformer 架构中保证深层网络梯度顺畅流动的标准做法——每一层的输出加上这一层的输入，再传给下一层。但在极深的模型（V4 有数百层）中，简单的残差相加容易导致不同层之间的信息混合效率不高，信号在传递过程中可能发生衰减或失真。

mHC 在残差连接的基础上引入了流形约束，让超连接的权重被约束在一个低维流形空间内，从而保证层间信号的传播更稳定、更具表达力，减少了训练过程中的梯度不稳定问题，也有助于最终模型在复杂推理任务上的泛化表现。

5.4 Muon 优化器：更快收敛，更稳训练

V4 在优化器层面放弃了 AdamW，转向 Muon 优化器。

Muon 优化器的核心思路是对梯度矩阵做奇异值分解方向上的归一化处理，使得每个方向上的更新步长更加均匀，避免了 Adam 系优化器中某些参数方向更新过慢、另一些更新过快的问题。具体到 DeepSeek 的实现版本，他们采用了 hybrid Newton-Schulz 迭代，分 10 步执行：前 8 步用激进系数快速将奇异值推向 1 附近，后 2 步用温和系数精确稳定在 1，效率和稳定性兼顾。

Muon 在 Kimi K2.6（Moonshot AI 的 1T 参数 MoE 模型）上已经过验证，V4 是 Muon 在大规模模型训练上的第二次重要实践。与 Kimi 的 QK-Clip 防止注意力爆炸的方案不同，V4 选择从源头用 RMSNorm 压制 Query 和 KV 的激活值，走的是两条不同的路，但殊途同归。

5.5 后训练的两阶段范式

V4 的后训练（Post-training）也值得一提。它采用了「先独立培养领域专家，再统一整合」的两阶段范式：

第一阶段：针对数学、代码、Agent、指令跟随等不同目标领域，分别独立训练专门的专家模型。每个专家先用高质量领域数据做 SFT（监督微调），再用 GRPO（Group Relative Policy Optimization）做强化学习，让专家的行为进一步与领域目标对齐。

第二阶段：通过 on-policy distillation（在线蒸馏）训练一个统一模型，让统一模型作为「学生」，同时向多个领域专家「教师」学习，最小化与各教师输出的反向 KL 散度。这样最终的统一模型，既具备通用的对话和指令跟随能力，又在各个专业领域保留了专家水平的表现。

5.6 从 V3 到 V4：这次升级了什么

和上一代 DeepSeek-V3.2 相比，V4 系列主要在以下几个维度做了系统性升级：

上下文长度：V3.2 的原生上下文为 128K，V4 将其扩展到 1M，且在 1M 长度下的单 token 推理计算量反而比 V3.2 在 128K 时更低，这是 CSA+HCA 机制带来的直接收益。

长文本召回率：根据 MRCR（Multi-hop Retrieval in Complex Reasoning）1M 测试，V4-Pro 得分 83.5，高于 Gemini-3.1-Pro 的 76.3。一年前这是国产模型几乎无力触及的指标，如今已经超越了老牌的 Google 顶级模型。

Agent 能力：V4 的 SWE-bench Verified 成绩达到 80.6 分，这是真实 GitHub Issue 修复任务的评测，代表模型在真实工程代码环境中的实际能力，而非教科书式的算法题解题能力。80.6 分是目前全球开源模型的最高水平之列。

知识广度：在 SimpleQA-Verified（全球事实性知识问答）上，V4-Pro-Max 拿到 57.9 分，开源第一且领先第二名约 20 个百分点（Kimi-K2.6 的 36.9、GLM-5.1 的 38.1）。中文知识评测（Chinese-SimpleQA）84.4 分，甚至超过了 Claude Opus 4.6-Max 的 76.4 和 GPT-5.4-xHigh 的 76.8，在中文知识覆盖上拥有明显优势。

架构创新密度：V3.2 是在 V3 基础上引入 DSA 稀疏注意力的增量版本，而 V4 是从注意力机制、残差连接、优化器、后训练范式多个层面同时做系统性重构，是真正意义上的代际升级。

六、LiveBench 榜单：开源最强的含金量

6.1 LiveBench 是什么，为什么值得关注

提到 AI 模型评测榜单，很多人首先想到的是 MMLU、HumanEval 这类经典基准。但这些传统基准存在一个根本性的问题：它们的测试题是固定的，早就被收录进了各家模型的训练数据里。模型在这些榜单上得高分，可能只是因为它在训练时「见过」这些题目，而非真的具备对应的推理能力。这种现象在学界被称为「基准污染」（Benchmark Contamination），是近两年来 AI 评测体系饱受批评的核心痛点。

LiveBench 的设计逻辑完全不同。它的名字里有个「Live」，核心特点是持续更新——每隔一段时间，LiveBench 会从最新的学术论文、数学竞赛题、编程比赛、新闻报道等来源中抽取新题目加入评测集，确保测试题目不太可能出现在模型的训练数据中。LiveBench 覆盖的能力维度也比较全面，涵盖数学推理、语言理解、代码生成、逻辑推理、数据分析等多个子项，整个评测流程相对透明，评测结果由参与团队自行提交，官方做统一的格式校验和分数计算。

这种持续滚动的出题机制，使得 LiveBench 的评测结果更能反映模型的真实泛化能力，而不是死记硬背的能力。因此，LiveBench 的榜单被很多研究者和开发者认为是当前最具参考价值的 AI 能力横向对比之一。

6.2 V4-Pro 的成绩拆解

根据最新 LiveBench 数据，DeepSeek-V4-Pro 的综合得分为 73.58 分，在全榜排名第 11 位。前 10 名清一色是闭源商业模型：

将 V4-Pro 的综合分数按子项拆解：

• 数学：90.68 分——强项，接近榜首水平
• 推理：82.69 分——强项，与头部闭源模型差距较小
• 语言理解：78.13 分——中等偏上
• 编程：69.99 分——短板，与 GPT-5.5 的 82.47 差距明显
• 数据分析：约 71 分——中等水平

数学和推理是 V4-Pro 最耀眼的两个维度，这和 DeepSeek 系列一贯的技术路线一致——深度强化学习驱动的推理能力提升。编程维度的相对薄弱，部分原因在于 LiveBench 的编程题偏向竞赛风格的算法题，而 V4-Pro 在真实工程代码场景（如 SWE-bench）上的表现实际上已经达到开源最高水平（80.6 分），两者衡量的不完全是同一维度的能力。

6.3 与 GPT-5.5 差 7 分意味着什么

V4-Pro 的 73.58 分与榜首 GPT-5.5 的 80.71 分之间差了 7 分多，如何理解这个差距？

从绝对分值来看，7 分差距在一个 0~100 的评分体系里看起来不大，但实际上集中体现在编程和某些需要综合多步推理的复杂任务上。对于大多数日常任务——写作、分析、数学计算、代码调试、文档整理——V4-Pro 的实际体验差距比分数差距要小得多。

更重要的是：GPT-5.5 是一个完全闭源的商业模型，开发者无法下载权重本地部署，API 调用成本也远高于 DeepSeek。V4-Pro 以开源权重的形式发布，MIT 协议允许商业使用，本地部署、二次微调均无障碍。这 7 分的分数差距，换来的是几十倍的价格差异和完全的模型控制权，对大多数实际应用场景来说，这笔账并不难算。

6.4 用 LiveBench 评测结果指导实际选型

很多读者看到评测榜单后，最常问的问题是：「那我应该用哪个模型？」

坦率来说，LiveBench 综合分是参考，但不是决策依据。实际选型更需要考虑以下几个维度：

任务类型匹配。如果你的核心需求是数学推理和科学计算，V4-Pro 在这方面的成绩是可信的参考；如果你的核心需求是代码生成，建议同时对比 LiveCodeBench（专注代码能力的评测榜单），在那里 V4-Pro 的 SWE-bench 成绩（80.6 分）实际上是全球最高水平之列，优势比 LiveBench 综合分更明显。

延迟与吞吐量需求。对于对话应用，First Token Time（首个 token 生成延迟）和 Token 吞吐量比综合评分更重要。V4-Flash 的延迟明显低于 V4-Pro，对实时对话场景更友好。

成本预算。在优惠期内，V4-Pro 的综合性价比极高；优惠期结束后，V4-Flash 在大多数常规任务上仍能提供不亚于旗舰的体验，且成本只有 Pro 的约八分之一。

自建部署还是调 API。如果团队有足够的 GPU 算力，下载 V4 开源权重自建推理服务，在大规模调用时总成本往往低于直接调用 API；如果算力资源有限，API 调用更灵活，无需承担硬件运维成本。

建议在正式接入前，用自己的典型业务数据集做 5~10 个代表性 Case 的人工评测，比任何公开榜单都更能反映模型在你具体场景下的实际表现。这也是 莫潇羽@无忆研习社 在所有 AI 选型文章里反复强调的一点：公开榜单提供方向，自测数据做决策。

七、DeepSeek-V4 API 完整使用指南

7.1 API 基础信息

DeepSeek-V4 系列的 API 与 OpenAI ChatCompletions 接口完全兼容，同时也支持 Anthropic 接口格式。对于已经在使用 OpenAI API 的开发者，迁移成本极低，只需要修改 base_url 和 model 两个参数即可。

API Base URL：

https://api.deepseek.com

当前可用模型名称：

• deepseek-v4-pro（完整旗舰版，1.6T 参数，49B 激活）
• deepseek-v4-flash（经济轻量版，284B 参数，13B 激活）

注意事项（莫潇羽@无忆研习社）： 旧模型名 deepseek-chat 和 deepseek-reasoner 当前仍可使用，分别指向 V4-Flash 的非思考模式和思考模式，但将于 2026 年 7