DeepSeek 终于开源视觉：V4-Flash-Vision 模型怎么用、贵不贵、能做什么

原创。DeepSeek 的 API 终于支持图片输入了：deepseek-v4-flash-vision-exp 可以看图说话、读截图、分析图表。这篇文章把官方文档里三种传图方式、token 计价规则和各类限制一次讲透，让你看完就能直接上手调 API。

DeepSeek 的 V4 系列火了半年，一直是纯文本模型。就在昨天（8 月 21 日），HN 上 393 票的热帖把 DeepSeek 官方 API 文档的 Vision 指南顶了上来——DeepSeek 终于给 Flash 版本加了视觉能力。模型名是 deepseek-v4-flash-vision-exp，后缀 exp 说明还是实验版本，但 API 已经开放，任何人都能调。

这事的价值在哪？国内开发者用 DeepSeek 主要图两件事：便宜和没有审核焦虑。以前要做图片理解，只能接 OpenAI 的 GPT-4o、或者国产闭源模型，要么贵要么要过一遍对方的合规流程。现在 DeepSeek 自己把这条路补上了，而且按照 Flash 系列的定价惯例，大概率会延续"卷价格"的路子。这篇文章基于官方 API 文档，把接入方式、计价规则、限制条件全部讲清楚。

一、模型能做什么，不能做什么

先说能力边界。deepseek-v4-flash-vision-exp 接受图片和文本混合输入，可以：

• 描述图片内容（"这张图里有什么"）
• 从截图里读文字（OCR 场景）
• 分析图表（柱状图、折线图、流程图）
• 看图回答问题（比如给 UI 截图让它找 bug）

支持的图片格式是 JPEG、PNG、GIF、WebP。有个细节值得注意：格式检测是看文件实际内容，不是看文件名或 MIME 类型。也就是说你传一个扩展名是 .png 但实际内容是 JPEG 的文件，它能正常识别；反过来，改了后缀想蒙混过关也行不通。

限制也很明确：

• 图片只能放在 user 消息里。放 system 或 assistant 消息会直接返回 400 错误。
• 只有 vision 模型接受图片。你用 deepseek-chat 或 deepseek-reasoner 传图，会收到 "This model does not support image" 的 400。
• 用户文本里包含保留的图片占位 token 会被拒绝。

一句话总结：这就是个"看图版本"的 Flash，不是新架构，是给现有模型加了个眼睛。文本能力和推理能力应该和 V4-Flash 一致，视觉部分单独走一套处理管线。

二、三种传图方式：Base64、URL、Files API

官方提供了三种把图片喂给模型的方式，都走 OpenAI 兼容的 Chat Completions 格式——content 从普通字符串变成内容块数组。base_url 是 https://api.deepseek.com。

方式一：Base64 内联（本地文件最省事）

把图片编码成 base64，塞进 data: URL 直接传。适合本地小文件，最简单直接：

import base64
from openai import OpenAI
 
client = OpenAI(api_key="<DeepSeek API Key>", base_url="https://api.deepseek.com")
 
with open("image.jpg", "rb") as f:
    b64 = base64.b64encode(f.read()).decode("utf-8")
 
response = client.chat.completions.create(
    model="deepseek-v4-flash-vision-exp",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "What is in this image?"},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{b64}"}},
            ],
        }
    ],
)
print(response.choices[0].message.content)

curl 版本同样支持，image_url.url 字段填 data:image/jpeg;base64,<BASE64_DATA> 即可。

注意：base64 编码后的数据会计入请求体大小限制——48 MiB。一张 5MB 的 JPEG 编码后约 6.7MB，一般没问题；但如果你要传大图或者多张图，很快就撞上限了。

方式二：外部图片 URL（最省流量）

直接传一个公开可访问的 http(s) 链接，模型会自己下载图片：

response = client.chat.completions.create(
    model="deepseek-v4-flash-vision-exp",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Describe this image."},
                {"type": "image_url", "image_url": {"url": "https://example.com/image.jpg"}},
            ],
        }
    ],
)

URL 方式有三个硬性限制：链接最长 8192 字符、图片文件最大 32 MiB、下载必须在 60 秒内完成。如果你的图片托管在慢速服务器上，或者链接带超长 query 参数，就可能踩到这些限制——这种情况官方建议改用 base64 或 Files API。

方式三：Files API（大图、复用图的正确选择）

先上传一次，拿到 file_id（形如 file-api-...），之后在请求里引用：

response = client.chat.completions.create(
    model="deepseek-v4-flash-vision-exp",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "What is in this image?"},
                {"type": "file", "file_id": "file-api-xxxxxxxxxxxxxxxx"},
            ],
        }
    ],
)

Files API 的优势很实在：

• 单图上限提到 64 MiB，不受 32 MiB 的单图检查约束
• 同一张图在多个请求里复用，不用反复上传
• 请求体超过 48 MiB 内联限制时的出路

还有个变体：file 块也可以直接内联 base64（file_data 字段），和 file_id 二选一，不能同时给。

什么时候该用 Files API？ 官方给了三个判断标准：单个请求会超过请求体大小限制、图片大于 32 MiB（只有 Files API 能传）、同一张图要在多个请求中重复引用。

三、detail 参数：低精度模式省 token

对 image_url 输入，可以设置 detail 字段控制图片处理方式：

{
  "type": "image_url",
  "image_url": {"url": "https://example.com/image.jpg", "detail": "low"}
}

实际使用建议：如果只是"看图里有没有某个元素"、读大段文字这种不需要精细细节的场景，用 low 就够了；需要识别图表细节、小字、边缘情况时再用 original。

四、计价规则：一张图最多 384 token

这是大家最关心的部分。图片会按尺寸转换成 token，和文本 token 一起计费。具体规则是：推理前所有图片都会自动缩放，保持宽高比，把总像素数压到约 800×800 的水平——小于 384×384 的图会放大，大于的缩小。

这意味着：

• 单张图片的 token 上限是 384。一张 2000×2000 的图和一张 5000×5000 的图，缩放后消耗的 token 完全相同——因为都压到 800×800 左右了。
• 多张图各自独立计算，没有"多图打包优惠"，也没有额外的多图计算规则。

算笔账：V4-Flash 的输入价格是 2 元/百万 token（输出 8 元/百万，官方 7 月发布时的定价）。一张图按满额 384 token 算，折合人民币约 0.0008 元/张——也就是一万张图才 8 块钱。当然这只是极端估算（小图实际 token 更少），但结论很清楚：视觉能力的增量成本低到可以忽略，这对图片批处理类应用（截图分析、表单 OCR、UI 审查）是重大利好。

官方还提供了一个图片 token 计算器页面（Token & Token Usage），想精确估算特定尺寸图片的成本可以去查。

五、硬性限制速查表

把官方文档里的限制汇总成一张表，方便你设计系统时对照：

两个容易踩的坑提醒一下：一是 600 张图的限制看着很大，但 15 张以上边长上限会从 8192px 掉到 4096px，大图批量处理时要注意；二是 64 MiB 的"每请求总大小"在混用 file_id 和普通图片时有不同算法，别按一个数算。

六、Anthropic 兼容端点也能传图

DeepSeek 一直提供 Anthropic 兼容的 /messages 端点（base_url = https://api.deepseek.com/anthropic），这次视觉能力也同步支持。区别在内容块的形状：OpenAI 格式用 image_url，Anthropic 格式用 image 块，里面包一个 source 对象：

import anthropic
 
client = anthropic.Anthropic()  # ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
 
message = client.messages.create(
    model="deepseek-v4-flash-vision-exp",
    max_tokens=1024,
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "What is in this image?"},
                {
                    "type": "image",
                    "source": {
                        "type": "base64",
                        "media_type": "image/jpeg",
                        "data": "<BASE64_DATA>",
                    },
                },
            ],
        }
    ],
)
print(message.content)

source.type 三种取值对应 OpenAI 的三种方式：base64（需带 media_type）、url（同样限 8192 字符）、file（Files API 的 file_id，需要加请求头 anthropic-beta: files-api-2025-04-14）。

对已经在用 Claude Code、或基于 Anthropic SDK 开发的应用来说，这意味着把 ANTHROPIC_BASE_URL 指到 DeepSeek，就能直接获得视觉能力，代码一行不用改。

七、Responses API 同样支持

如果你用的是更新的 Responses API（client.responses.create），图片通过 input_image 内容块传入：

response = client.responses.create(
    model="deepseek-v4-flash-vision-exp",
    input=[
        {
            "role": "user",
            "content": [
                {"type": "input_text", "text": "What is in this image?"},
                {"type": "input_image", "image_url": "https://example.com/image.jpg", "detail": "low"},
            ],
        }
    ],
)
print(response.output_text)

input_image 同样支持 detail 参数，语义和前面一致。两个细节：detail 在通过 file_id 传图时会被忽略；image_url 和 file_id 互斥，不能同时出现。图片可以出现在 user/developer 消息里，也可以出现在 function_call_output / custom_tool_call_output 中——这意味着 Agent 工具调用的返回结果里可以带图，多模态 Agent 的玩法就打开了。

八、怎么用好它：几个实用场景

官方文档只给了 API 用法，结合我自己的判断，几个值得先试的场景：

截图驱动的 UI 测试。以前 UI 自动化测试断言靠 DOM 选择器，现在可以让视觉模型直接看截图找问题——"这个弹窗的按钮被遮挡了吗""这页的报错提示在哪"。配合 detail: low 控制成本，跑一轮全量截图审查花不了几毛钱。

表单和票据 OCR。身份证、发票、快递单这类结构化文档，视觉模型 + 结构化输出 prompt 组合，比传统 OCR 管线（检测 + 识别 + 后处理三件套）省事得多。V4-Flash 级别的模型处理这类任务精度已经够用。

多模态 Agent 的工具链。Responses API 支持工具输出里带图，意味着 Agent 可以"截图确认自己的操作结果"——给浏览器截图，让模型判断页面是否按预期变化，形成闭环。

注意 exp 后缀：实验版模型的能力和定价都可能调整，生产环境接入前先做好回归测试，并关注官方后续的正式版发布。

写在最后

DeepSeek 补上视觉这块拼图后，V4 系列在"开源 + 便宜 + 多模态"三个维度上都齐了。对个人开发者来说，最直接的收益是：多模态应用的 API 成本从"每百万像素级 token 计费"降到了"单图封顶 384 token"，图片类应用的毛利空间一下子打开了。官方文档里还有 Files API 和 Responses API 的完整指南，想深入的话可以顺着链接读。

DeepSeek Vision 官方文档 | Files API 文档 | Responses API 文档