DeepSeek-V4.1-Flash 架构深度解析：CED 非对称架构与 KV Cache 压缩革命

2026 年 9 月 10 日，DeepSeek 发布了新架构家族中最小尺寸的成员 DeepSeek-V4.1-Flash。它并非一次常规的版本迭代，而是把 552B 总参数 MoE 与全新的 Causal-Encoder-Decoder（CED）非对称架构捆绑在一起：输入端只激活 8B、输出端激活 16B，配合 KV Cache 的激进压缩，把 HBM 需求压到上一代的 1/4、SSD 存储压到 1/8，相比初代 DeepSeek 整体缩小约 437 倍。在 1M tokens 上下文、384K tokens 最大输出、原生多模态与三档思考强度的组合下，Flash 的基准分全面超越 V4 Pro。这篇文章分两段展开，本段先拆架构与资金账，下一段再讲工程落地与迁移策略。理解 CED 的非对称激活，是理解 Flash 一切成本优势的起点。

CED 非对称架构总览：552B MoE 为何在输入侧只激活 8B、输出侧激活 16B

Causal-Encoder-Decoder 的设计直觉是：把「读懂长输入」和「写出长输出」拆成两段算力预算。输入端面对的是 1M tokens 的上下文，它的任务本质上是编码——把上下文压成可被解码器反复查询的表示；输出端面对的是 384K tokens 的生成，每一个新 token 都要经过完整注意力与 FFN 前向，是推理成本真正的放大器。于是 Flash 在 MoE 路由上做了非对称切分：输入侧只激活 8B，输出侧激活 16B。

这个比例不是拍脑袋。输入端一次性处理 1M tokens 的预填充与编码，若把激活参数堆到很高，prefill 的算力峰值和显存带宽会被瞬时打满；而输入端编码质量只要「足够让解码器查询」即可，8B 激活足以覆盖长文档、代码库、多模态视觉特征这类需要被理解但不需要被逐字复现的内容。输出端则相反：生成的每一个 token 都会被后续 token 依赖，输出质量对激活容量更敏感，因此给到 16B。用一句话概括：输入端买的是「覆盖率」，输出端买的是「生成质量」。

对推理成本的影响是双重的。第一，prefill 阶段（长上下文最贵的阶段）按 8B 激活规模计费，单 token 的激活算力明显低于同期同量级模型；第二，decode 阶段按 16B 激活规模计费，比全对称的 16B 输入输出模型省下了输入端那一份冗余。配合后文要讲的 KV Cache 压缩，Flash 的缓存未命中输入定价落在空闲 1 元/百万 tokens、高峰 2 元/百万 tokens，输出空闲 4 元、高峰 8 元，相对 V4 Flash 缓存命中降价 60%、未命中降价约 33.3%、输出降价约 11.1%。定价结构本身就反映了非对称激活带来的成本曲线。

需要强调的是，CED 的「非对称」不只是激活参数量的非对称，更是计算模式的非对称：输入端是类编码器的因果注意力，输出端才是标准自回归解码。这两段共享同一套 552B MoE 底座，通过路由与门控按阶段选择不同的激活子集，而不是两个独立模型。这也是它能作为单一模型对外提供服务、只暴露一个 deepseek-flash 模型名的原因。

Causal-Encoder 与 Decoder 的职责切分：1M 上下文的注意力路径如何走

在注意力路径上，Causal Encoder 与 Decoder 的分工决定了缓存写在哪里、读在哪里。输入侧 Causal Encoder 负责对 1M tokens 做一次完整的因果注意力前向，把每一层的 K/V 表示计算出来并写入 KV Cache；输出侧 Decoder 在生成时读取这些已固化的 K/V，只对自己新产生的 token 追加新的 K/V 条目。换句话说：写缓存发生在编码阶段，读缓存主导解码阶段。这种切分让输入端的重活只做一次，解码端的每一步都尽量轻。

这套分工之所以能支撑 1M tokens，关键在于注意力计算的分块与稀疏化被放在 Encoder 侧完成，Decoder 侧只面对「已有压缩缓存 + 新 token」的小工作集。若把 1M 上下文的全部 K/V 原样保留，显存需求会随长度线性爆炸；Flash 的做法是在 Encoder 写入缓存前就完成淘汰与量化，使得进入缓存的条目在数量与位宽上都被压缩。这也是 HBM 与 SSD 两项官方指标能够同时大幅下降的结构基础。

工程上要理解一个反直觉的点：1M 上下文不等于 1M 的注意力矩阵常驻显存。Flash 通过分块预填充把长输入切成多个块，逐块编码、逐块写缓存，峰值显存只与块大小和缓存条目数相关，而不是与总长度线性相关。这是它能在批处理场景下仍服务 1M 上下文的前提。下面的调用示例展示了超长输入的基本形态：

from openai import OpenAI

client = OpenAI(
    api_key="your-deepseek-api-key",
    base_url="https://api.deepseek.com"
)

# 1M tokens 级长文档输入：依赖 Causal Encoder 分块预填充
# 思考模式默认开启，这里显式指定 max 档便于观察长上下文推理
resp = client.chat.completions.create(
    model="deepseek-flash",
    messages=[
        {"role": "system", "content": "你是一名严谨的长文档分析助手。"},
        {"role": "user", "content": long_document + "\n\n请给出结构化的风险清单。"}
    ],
    extra_body={"thinking": {"type": "enabled", "intensity": "max"}}
)
print(resp.choices[0].message.content)

KV Cache 压缩革命：HBM 降至 1/4、SSD 降至 1/8 的机制推导

官方给出的两个数字是理解 Flash 经济性的核心：HBM 需求降至上一代的 1/4，SSD 存储降至 1/8，相比初代 DeepSeek 缩小约 437 倍。压缩发生在两个层面：其一，缓存结构本身被重构，Encoder 侧写入的是经过淘汰与量化的紧凑 K/V 表示，层数×头数×位宽的乘积被系统性压小；其二，调度层面把冷缓存下沉到 SSD，热缓存留在 HBM，形成分层缓存。1/4 对应的是 HBM 层的容量下降，1/8 对应的是 SSD 层的存储下降，两者不是同一个数字的两种口径。

437 倍这个量级的来源，是把「初代 DeepSeek 在同等上下文规模下的缓存足迹」与「Flash 压缩后的分层缓存足迹」做比值。它同时叠加了架构代际收益、非对称激活带来的缓存条目减少、以及量化与淘汰策略。理解这一点很重要：437 倍不是单一技术带来的，而是架构 + 缓存结构 + 分层调度的乘积。任何把它归因于某一个技巧的说法都不准确。

对开发者的直接含义是缓存命中的价值被放大。官方定价中缓存命中的输入只要空闲 0.02 元、高峰 0.04 元每百万 tokens，而未命中是空闲 1 元、高峰 2 元——命中与未命中的价差达到 50 倍。这意味着在长上下文、多轮对话、重复系统提示的场景里，把前缀稳定住、复用缓存，是比换模型更有效的省钱手段。下表对比了不同方案在缓存与成本上的取舍：

工程坑在于：缓存命中的前提是前缀逐字节一致。任何在系统提示里插入时间戳、随机 ID 的做法都会让命中率归零，把成本从 0.02 元推回 1 元。稳定前缀、把可变内容放到 user 消息尾部，是长上下文应用的基本纪律。

1M 输入与 384K 最大输出：长上下文下的显存与吞吐工程约束

1M tokens 上下文与 384K tokens 最大输出是两个独立约束，不能混为一谈。1M 是输入端 Encoder 要编码的长度，384K 是 Decoder 单次能生成的上限。它们对工程的要求不同：输入端要解决分块预填充与缓存写入的峰值管理，输出端要解决长生成过程中的显存稳态与流式返回。

在批处理层面，长上下文会显著降低有效批大小。因为每个请求的 K/V 缓存都占显存，1M 上下文的请求一旦并发，HBM 很快被吃满。解决办法是分块预填充：把长输入切成固定大小的块逐块送进 Encoder，控制单次峰值显存；同时利用缓存命中，让同一前缀的多个请求共享已编码的 K/V。输出侧则必须开启流式，384K tokens 的输出若等全量完成再返回，既不现实也不利于客户端尽早消费。

显存峰值管理的另一条经验是：不要在同一请求里既塞满 1M 输入又要求 384K 输出。输入编码的缓存占用与输出追加的缓存占用会叠加，接近上限时容易触发淘汰，反而拖慢 decode。合理做法是把「重输入理解」和「重输出生成」拆成两个阶段或两个请求，用对话前缀续写把中间结果接起来。下面是一个带工具调用与 JSON 输出的稳态请求示例：

import json
from openai import OpenAI

client = OpenAI(
    api_key="your-deepseek-api-key",
    base_url="https://api.deepseek.com"
)

# JSON Output + Tool Calls 组合：结构化输出，便于下游解析
resp = client.chat.completions.create(
    model="deepseek-flash",
    messages=[
        {"role": "user", "content": "读取 /data/metrics.csv 并总结异常指标。"}
    ],
    tools=[{
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "读取本地文件",
            "parameters": {
                "type": "object",
                "properties": {"path": {"type": "string"}},
                "required": ["path"]
            }
        }
    }],
    response_format={"type": "json_object"}
)
print(json.loads(resp.choices[0].message.content))

新预训练方法 + 更大规模 RL 后训练：基准全面超越 V4 Pro 的训练侧解读

官方表述是「采用新预训练方法 + 更大规模 RL 后训练，基准全面超越 V4 Pro」。从训练侧看，这两条对应两个不同能力维度。新预训练方法主要改善的是表示质量与长上下文外推，它解释了为什么 Flash 在 1M 上下文下仍能保持推理稳定性；更大规模 RL 后训练改善的是指令遵循、工具使用与推理链质量，它解释了 Terminal-Bench、CyberGym 这类偏 agent 与安全的基准提升。

官方基准里最值得对照的是两处：CyberGym 88.1 对 V4 Pro 的 83.3，Terminal-Bench 2.1 得分 90.6 对 V4 Pro 的 87.9。这两项都高度依赖多步工具调用与长程规划，恰好是 RL 后训练规模放大的受益项。硬件侧指标也很亮眼：GPQA Diamond 90.9、Codeforces 评级 3471、MathArena Apex 65.6，说明推理与代码能力没有因为激活参数小而缩水——非对称激活省的是推理算力，不是能力上限。

需要克制的是，官方只公布了这些基准分与训练方法的方向性描述，没有公布预训练数据量、RL 步数或算力规模。任何具体数字都不可猜测。本段能确定的是：Flash 以家族最小尺寸、输入端 8B / 输出端 16B 的激活规模，拿到了全面超越 V4 Pro 的成绩，训练侧的两个变量（新预训练方法、更大规模 RL）是可归因的两条主线。

思考模式三档强度：low / high / max 与默认思考模式的调用策略

Flash 支持非思考模式与思考模式，且思考模式是默认开启的。思考强度分 low、high、max 三档，直接对应延迟、成本与准确率的三方权衡。一个实用的判断框架是：能用规则或检索回答的，用非思考；需要多步推理但路径明确的，用 low；需要探索、验证、纠错的，用 high；agent 长程任务与高难度数学代码，用 max。

成本上，思考强度越高，模型产生的思考 token 越多，输出计费越高。由于输出空闲价 4 元、高峰 8 元每百万 tokens，max 档的长思考会明显推高账单。延迟上，max 档的首 token 延迟与总时长都显著高于 low。因此不要把 max 当默认值：默认的思考模式在未指定强度时已有合理平衡，只有在确实需要时才显式拉满。

工程坑在于：FIM 仅支持非思考模式。如果你的代码补全链路依赖 FIM，就必须显式关闭思考模式，否则请求会失败或走不到 FIM 路径。这也是把思考强度配置与功能能力解耦的原因——它们不是正交的。下面的示例展示了非思考模式的显式配置：

from openai import OpenAI

client = OpenAI(
    api_key="your-deepseek-api-key",
    base_url="https://api.deepseek.com"
)

# 非思考模式：FIM 代码补全的唯一合法组合
resp = client.completions.create(
    model="deepseek-flash",
    prompt="def quicksort(arr):\n    ",
    extra_body={
        "thinking": {"type": "disabled"},
        "fim": True
    }
)
print(resp.choices[0].text)

FIM 仅限非思考模式：代码补全场景的接口边界与替代方案

官方明确 FIM 只在非思考模式可用。这条边界的工程含义是：代码补全是一条独立的、低延迟、无思考链的快速路径，它与 agent 式代码生成是两种形态。在 IDE 补全场景里，低延迟比长推理更重要，因此关闭思考、走 FIM 是正确选择；而在「根据需求重写整个文件」这类任务里，应当走思考模式 + Tool Calls 或对话前缀续写，而不是强行用 FIM。

需要规避的配置组合有两个：一是 FIM + 思考模式开启，直接不合法；二是 FIM + 对话前缀续写，两者语义重叠、不应混用。替代方案是：需要带上下文感知的补全时，用非思考模式 + 长前缀（把文件上文塞进 prompt），让缓存命中前缀降低输入成本；需要跨文件推理时，切到思考模式走 chat 接口。

JSON Output、Tool Calls 与对话前缀续写：结构化输出的实现要点

Flash 在结构化输出上给了多套能力组合：JSON Output、Tool Calls、Responses API、Anthropic API、对话前缀续写，以及仅非思考可用的 FIM。它们的适用场景不同。JSON Output 适合固定 schema 的抽取与分类，下游直接解析；Tool Calls 适合需要模型主动决定调用哪个外部函数的 agent 流程；Responses API 适合需要服务端维护状态与多步交互的应用；Anthropic API 兼容则让已有 Claude 工具链的团队低成本迁移；对话前缀续写适合让模型在给定前缀后继续，用于可控生成与拼接。

组合使用时有一个重要约束：JSON Output 与 Tool Calls 可以共存，但思考强度与 FIM 互斥。另外，对话前缀续写会改变缓存键的前缀结构，若前缀频繁变动会降低缓存命中率。模型名方面，新模型名是 deepseek-flash，并发限制 2500；旧名 deepseek-v4-flash 与 deepseek-v4-flash-vision-exp 已下线，但保留了兼容路由，因此老代码不会立刻报错，但应尽快切换到新名。

还有一个时间点对成本影响很大：北京时间 2026-09-14 12:00 起，deepseek-v4-pro 的请求全部路由到 V4.1-Flash 并按 Flash 价计费。定价自 2026-09-10 12:00 生效，高峰为周一至五 9:00-12:00 与 14:00-18:00，空闲为高峰的一半。把批处理任务排到空闲窗口，可以直接省掉一半成本。原生多模态视觉理解支持图片链接、base64 与 Files API 三种输入方式，为文档与截图理解提供了统一入口。下一段我们会把上述能力落到迁移与调优的具体工程方案上。

承接上文对 CED（Causal-Encoder-Decoder）非对称架构的原理拆解与 KV Cache 压缩的量化分析——输入端 8B 激活、输出端 16B 激活的职责分离，以及 HBM 降至上一代 1/4、SSD 降至 1/8、相比初代 DeepSeek 缩小约 437 倍的存储结构——本节进入落地层，把架构优势翻译成可执行的工程决策。

原生多模态视觉理解：图片链接、base64 与 Files API 三种输入路径

DeepSeek-V4.1-Flash 原生支持多模态视觉理解，提供三条输入路径：图片链接（URL）、base64 内联、Files API。三者并非简单等价，在 CED 架构下差异会被放大，因为视觉 token 在编码器侧（8B 激活）先被压缩成隐状态，再由解码器侧消费。选择哪条路径，直接决定调用链长度、缓存命中率与带宽成本。

• 图片链接：请求体只带一个 URL，最轻量。服务端需在预处理阶段完成抓取、解码与校验。优点是调用链短、请求体积小，适合图片已托管在可公网访问 CDN 的场景；缺点是引入外部网络依赖，抓取失败、超时或链接失效都会导致整次请求 4xx/5xx，且外链图片无法被提示缓存（prompt cache）跨请求复用，因为内容不固定。
• base64 内联：图片二进制直接放进请求体。优点是自包含、可重复、可精确控制内容字节，进而有机会命中缓存；缺点是请求体积膨胀约 33%（base64 编码开销），一张 2MB 的图会变成约 2.7MB 的请求体，在 1M tokens 上下文与 2500 并发叠加时，极易触及网关的请求体上限与上传带宽瓶颈。
• Files API：先上传文件，拿到 file id 后在对话中引用。这是生产环境最推荐的视觉路径。图片只上传一次，后续所有请求复用同一 id；对 CED 架构的词元化与缓存复用最友好，因为同一 id 对应的视觉隐状态有机会在缓存层稳定命中，从而显著摊薄未命中输入（1~2 元/百万 tokens）的成本。

工程建议：高频复用图走 Files API，一次性小图走 base64，公网已托管的静态图可走 URL；务必保证字节级稳定，否则缓存命中率会归零。

import base64
import requests

API_KEY = "your-deepseek-api-key"
BASE = "https://api.deepseek.com"
HEADERS = {"Authorization": f"Bearer {API_KEY}"}

# 路径一：Files API 上传一次，后续用 file id 复用
with open("diagram.png", "rb") as f:
    upload = requests.post(
        f"{BASE}/files",
        headers=HEADERS,
        files={"file": ("diagram.png", f, "image/png")},
        data={"purpose": "vision"},
    ).json()
file_id = upload["id"]

# 路径二：base64 内联
with open("small.png", "rb") as f:
    b64 = base64.b64encode(f.read()).decode()

payload = {
    "model": "deepseek-flash",
    "messages": [{
        "role": "user",
        "content": [
            {"type": "image_url", "image_url": {"url": f"file://{file_id}"}},
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{b64}"}},
            {"type": "text", "text": "对比两张架构图的差异并输出 JSON。"},
        ],
    }],
    "response_format": {"type": "json_object"},
}
resp = requests.post(f"{BASE}/chat/completions", headers=HEADERS, json=payload)
print(resp.json()["choices"][0]["message"]["content"])

API 迁移实战：deepseek-flash 模型名、旧名兼容路由与 2500 并发限制

2026-09-10 发布后，官方 API 的正式模型名为 deepseek-flash；旧名 deepseek-v4-flash 与 deepseek-v4-flash-vision-exp 已下线，但保留兼容路由。这意味着线上存量请求不会因改名而 404，而是被透明转发到 deepseek-flash。工程上这既是福利也是陷阱：福利是零改造迁移；陷阱是兼容路由不保证参数语义完全一致，尤其视觉实验版旧名对应的部分视觉参数可能被规范化。

• 模型名替换：新代码一律写 deepseek-flash；旧代码可短期保留旧名，但建议在一个迭代周期内完成替换并回归测试。
• 兼容路由行为：旧名请求被路由到 V4.1-Flash，计费按 Flash 价，能力按 Flash 规格。若旧代码依赖实验版视觉的特殊返回结构，务必灰度验证。
• 2500 并发限制：这是账户级并发上限，超出会触发 429。设计上要区分瞬时突发与持续高并发：前者用指数退避重试即可，后者必须上令牌桶或信号量做本地限流。

import time
import threading
import requests

API_KEY = "your-deepseek-api-key"
URL = "https://api.deepseek.com/chat/completions"
MAX_CONCURRENCY = 2500
sem = threading.Semaphore(200)  # 本地保守限流，留出突发余量

def call_once(prompt, retries=5):
    for i in range(retries):
        with sem:
            r = requests.post(
                URL,
                headers={"Authorization": f"Bearer {API_KEY}"},
                json={"model": "deepseek-flash", "messages": [{"role": "user", "content": prompt}]},
                timeout=120,
            )
        if r.status_code == 200:
            return r.json()
        if r.status_code == 429:
            time.sleep(min(2 ** i + 0.1 * i, 30))
            continue
        r.raise_for_status()
    raise RuntimeError("retry exhausted")

2026-09-14 路由切换：deepseek-v4-pro 请求全部转向 V4.1-Flash 的兼容处理

北京时间 2026-09-14 12:00 起，所有 deepseek-v4-pro 请求全部路由到 V4.1-Flash，并按 Flash 价计费。这是一个不可逆的迁移窗口，线上系统需提前做三件事：

1. 能力回归：虽然官方基准显示 V4.1-Flash 全面超越 V4 Pro（如 GPQA Diamond 90.9、CyberGym 88.1 对 V4 Pro 的 87.9 与 83.3），但仍建议对你自己的业务集做一次 A/B，确认输出风格、JSON 结构与工具调用行为一致。
2. 成本预期重算：路由到 Flash 后按 Flash 价计费，缓存命中 0.02/0.04 元、未命中 1/2 元、输出 4/8 元（空闲/高峰）。若你原来按 Pro 价做预算，需要重新计提，并利用降价空间调整并发与缓存策略。
3. 模型名收敛：把代码中的 deepseek-v4-pro 显式替换为 deepseek-flash，避免长期依赖隐式路由，便于后续做参数级灰度。

兼容策略上，建议在网关层做一层模型名映射表，把旧名统一归一化到 deepseek-flash，同时记录原始模型名用于观测，方便定位切换前后差异。

定价结构与高峰/空闲时段：缓存命中、未命中与输出的成本优化账

定价自北京时间 2026-09-10 12:00 生效。高峰时段为周一至周五 9:00-12:00、14:00-18:00，其余为空闲；空闲价为高峰的一半。相对 V4 Flash：缓存命中降价 60%、未命中降价约 33.3%、输出降价约 11.1%。

成本优化的核心杠杆是缓存命中：命中与未命中价差达 50 倍（空闲 0.02 vs 1）。把稳定前缀（系统提示、工具定义、固定文档）固化在请求前部，利用对话前缀续写与提示缓存，能把这部分 token 压到 0.02 元档。其次是把非实时任务挪到空闲窗口，直接砍半。输出侧因只降 11.1%，控制输出长度（如限制 max tokens、用 JSON Output 约束结构）比压缩输入更值得投入。

官方基准深读：GPQA Diamond 90.9、Codeforces 3471、Terminal-Bench 2.1 90.6 的能力画像

官方基准给出了一幅清晰的能力画像：

• GPQA Diamond 90.9：研究生级科学问答，逼近顶尖水平，说明 CED 解码器侧 16B 激活在复杂推理链上效率很高。
• Codeforces 评级 3471：竞赛级编程达到极高水平，配合 Tool Calls 与 FIM（仅非思考），适合做代码补全与自动化修复。
• MathArena Apex 65.6：高难数学基准，体现思考模式在长链推理上的增益。
• Terminal-Bench 2.1 得分 90.6：终端/命令行任务代理能力突出，适合作为智能体执行层。
• CyberGym 88.1：网络安全场景得分，与 V4 Pro 的 83.3 相比提升明显。

对照 V4 Pro：官方口径为 GPQA Diamond 90.9 对 87.9、CyberGym 88.1 对 83.3，其余项目全面超越。这意味着从 Pro 迁移到 Flash 不是降级而是升级，且成本更低。

开源与生态接入：Hugging Face 权重、技术报告与 WorkBuddy、OpenCode 集成

官方已将权重发布在 Hugging Face，并附技术报告，覆盖 CED 非对称结构、KV Cache 压缩细节与训练配方。对自研团队而言，这意味着可以在私有环境做量化、蒸馏与领域微调。生态侧，官方合作伙伴 WorkBuddy（含 CodeBuddy） 与 OpenCode 已全量接入，开发者可在这些工具中直接使用 V4.1-Flash 的视觉、工具调用与长上下文能力，降低集成门槛。

• 权重：Hugging Face 直接获取，配合技术报告理解 CED 实现细节。
• WorkBuddy / CodeBuddy：面向办公与编码场景的即插即用接入。
• OpenCode：面向开源编码工作流的集成，适合自动化开发流程。
• API 侧：JSON Output、Tool Calls、Responses API、Anthropic API、对话前缀续写、FIM（仅非思考）均可用。

CED 非对称架构的工程坑：缓存一致性、多模态混排与长输出截断的排查清单

CED 的非对称设计（输入 8B 激活、输出 16B 激活）在带来效率的同时，也引入几类典型问题：

1. 缓存一致性坑：前缀中任何字节变化（时间戳、随机 id、图片重编码）都会导致缓存未命中，成本从 0.02 跳到 1 元。排查：把动态字段移到前缀之后，固定系统提示与工具定义；对图片先上传 Files API 拿稳定 id。
2. 多模态混排坑：视觉 token 与文本 token 交错时，若图片顺序或占位方式不稳定，会破坏缓存前缀。排查：统一图片在 content 数组中的位置与顺序，保持 base64 或 id 字节级一致。
3. 384K 长输出截断坑：最大输出 384K tokens，超出会被截断。排查：设置 max_tokens 上限并检测 finish_reason，截断时走续写（对话前缀续写）而非重试全量。
4. 思考模式切换坑：默认思考模式，low/high/max 三档强度影响延迟与成本。排查：非推理任务显式关思考，FIM 仅非思考时可用。
5. 并发与限流坑：2500 并发上限下，突发流量易触发 429。排查：本地信号量 + 指数退避，区分突发与持续负载。

总结与最佳实践

• 模型名统一：新代码一律用 deepseek-flash；旧名 deepseek-v4-flash / deepseek-v4-flash-vision-exp 依赖兼容路由，尽快替换。
• 9-14 迁移窗口：北京时间 2026-09-14 12:00 起 v4-pro 全量路由到 V4.1-Flash 并按 Flash 价计费，提前做能力回归与成本重算。
• 视觉输入选型：高频复用图走 Files API，一次性小图走 base64，公网静态图走 URL；保证字节稳定以命中缓存。
• 成本优化：优先提缓存命中（0.02 元档），非实时任务挪空闲窗口，输出侧控长度；缓存命中价差达 50 倍。
• 并发设计：2500 并发上限下用本地信号量 + 指数退避，区分突发与持续高并发。
• 能力自信：GPQA Diamond 90.9、Codeforces 3471、MathArena Apex 65.6、Terminal-Bench 2.1 90.6、CyberGym 88.1，全面超越 V4 Pro。
• 长上下文：1M tokens 上下文、384K 最大输出，注意截断检测与续写策略。
• 生态与开源：Hugging Face 权重 + 技术报告已放出，WorkBuddy（含 CodeBuddy）与 OpenCode 全量接入。