1M 上下文与 384K 输出：用 DeepSeek-V4.1-Flash 构建长上下文多模态 Agent

2026 年 9 月 10 日，DeepSeek 发布了新架构家族中最小尺寸的成员 DeepSeek-V4.1-Flash：552B 总参数 MoE、全新的 Causal-Encoder-Decoder（CED）非对称架构、1M tokens 上下文与384K tokens 最大输出，同时原生支持多模态视觉理解、思考模式三档强度与全套结构化输出能力。对长上下文多模态 Agent 的开发者而言，这一代模型真正的价值不在参数量，而在于它把 KV Cache 的 HBM 需求压到上一代的 1/4、SSD 存储压到 1/8，相比初代 DeepSeek 缩小约 437 倍——这让「把百万 token 的图片、文档、代码和历史会话长期驻留在一个 Agent 里」第一次变成可部署、可计费的工程方案。本文分两段展开：本段聚焦架构与 API 层，拆解 CED 非对称设计、显存账、模型名迁移、思考预算与多模态输入链路；下一段将进入端到端 Agent 编排、成本控制与生产级限流实战。

CED 非对称架构拆解：552B MoE 如何做到输入激活 8B、输出激活 16B

DeepSeek-V4.1-Flash 采用的是全新 Causal-Encoder-Decoder（CED）非对称架构。传统 decoder-only 模型中，输入侧和输出侧共享同一套注意力与前馈路径，导致「读 1M token」和「写 384K token」的成本结构几乎对称。CED 把这件事拆开了：输入侧走编码器路径，激活约 8B 参数；输出侧走解码器路径，激活约 16B 参数；两者共享 552B 总参数的 MoE 专家池，但按不同路由策略激活。

非对称的意义要从长上下文 Agent 的真实负载说起。一个典型的多模态长上下文 Agent 会话，绝大多数 token 是「被读」的：用户上传的 200 页 PDF、几十张截图、历史工具调用结果、检索回来的代码片段。模型真正「写」出来的 token 往往只占输入的一个小比例。CED 让输入编码只激活 8B，意味着在预填充阶段处理海量上下文时，单位 token 的算力与显存带宽压力显著低于输出侧。而输出侧激活 16B，则保证了生成质量——尤其是需要强推理的思考模式。

• 输入侧 8B 激活：面向 prefill 密集场景，降低长上下文的首 token 延迟与吞吐成本。
• 输出侧 16B 激活：面向 decode 的质量与推理深度，支撑 384K 长输出不塌陷。
• 共享 552B MoE：保证知识容量，同时用稀疏激活控制单 token 实际计算量。

工程上要注意：非对称结构意味着「输入 token 计费」和「输出 token 计费」的性价比差异会被放大。官方定价中缓存未命中输入空闲 1 元、输出空闲 4 元每百万 tokens，输出是输入的 4 倍。所以优化方向很明确——把可复用的上下文尽量推进缓存命中区（命中输入空闲仅 0.02 元），把昂贵的输出 token 留给真正需要模型生成的部分，而不是让模型复述已有内容。

1M 上下文与 384K 输出的显存账：KV Cache 降至 1/4、SSD 存储降至 1/8 的工程含义

官方公布了一个非常关键的数字：V4.1-Flash 的 KV Cache HBM 需求降至上一代的 1/4，SSD 存储降至 1/8。这两个数字直接决定了 1M 上下文能否真正上线，而不只是出现在公告里。

先理解 KV Cache 为什么是长上下文的真正瓶颈。在自回归生成中，每个 token 的 Key/Value 都要被保留供后续注意力计算复用。上下文长度线性增长，KV Cache 就线性膨胀；在 1M tokens 规模下，KV Cache 往往比模型权重本身还大得多，直接吃满显存。上一代方案要么截断上下文，要么把 KV Cache 卸载（offload）到 SSD，而 SSD 的容量与读写带宽又成为新瓶颈。

V4.1-Flash 的做法是把 HBM 占用压到 1/4：对于同样的并发会话数与上下文长度，单卡能驻留的状态更多，或同样状态占用更少卡。SSD 存储压到 1/8，则意味着把冷 KV Cache 下沉到 SSD 时，1M token 级会话的持久化存储开销大幅下降。这对 Agent 尤其重要，因为 Agent 的会话是长生命周期的：一次任务可能持续数小时、跨越几十轮工具调用。

部署侧的直接推论：单实例可支撑的长上下文并发数显著提升，边缘或单机部署 1M 上下文从「理论上可能」变成「工程上可行」。同时，384K 输出意味着 decode 阶段会持续很长时间，KV Cache 会持续增长，因此 SSD 卸载策略必须和会话生命周期管理结合，例如对已完成推理的中间结果做压缩归档，而不是全部常驻。

从初代 DeepSeek 缩小约 437 倍：KV Cache 压缩路径与长上下文 Agent 的可行性边界

官方给出的最强锚点是：相比初代 DeepSeek，V4.1-Flash 的 KV Cache 占用缩小约 437 倍。这个数字不是营销口径，而是把「百万 token 上下文」从实验室搬进生产的分水岭。

437 倍的意义在于改变了 Agent 的状态模型。Agent 的核心难题从来不是单次问答，而是状态持久化与状态复用：用户会话要能中断后恢复、跨天继续、在多个工具调用之间保持一致的上下文。过去由于 KV Cache 太贵，工程上被迫做「滑动窗口 + 摘要压缩」，代价是信息丢失和前后不一致。压缩 437 倍后，可行边界外扩：

1. 会话持久化：整段 1M 上下文的 KV Cache 可以长期驻留或快速换入换出，会话可真正「记住」全部历史，而不只是摘要。
2. 状态复用：多轮工具调用中，前序工具结果无需反复重传和重新编码，缓存命中后输入成本降至空闲 0.02 元/百万 tokens。
3. 多模态持久化：图片经视觉理解后产生的上下文同样进入缓存体系，使「看图—推理—再引用原图」的链路可长期维持。

但边界依然存在。压缩的是存储与显存占用，不是注意力计算本身；1M 上下文的注意力仍是 O(n²) 级别的计算压力，超长上下文的首 token 延迟仍然可观。因此工程上仍应坚持「分层上下文」：高频复用的系统提示、工具定义放最前并命中缓存；中频的检索结果按需注入；低频的原始素材留在 Files API，用时再拉取。把 437 倍的红利用在持久化上，而不是无节制地堆满上下文窗口。

deepseek-flash 模型名与 2500 并发限制：API 迁移、旧名兼容路由与调用规划

API 层的第一个动作是把模型名统一到 deepseek-flash。旧名 deepseek-v4-flash 与 deepseek-v4-flash-vision-exp 已下线，但官方提供了兼容路由：短期内旧名请求会被路由到新模型，不会直接报错。这给了迁移缓冲期，但不应依赖——生产环境应尽快显式切换到 deepseek-flash，避免兼容路由在某个时间点被移除时出现故障。

第二个关键参数是并发限制 2500。这是一个相当高的并发上限，但对长上下文 Agent 来说，真正的瓶颈往往不是并发数，而是单请求持续时间：1M 上下文 prefill + 384K 输出 decode 可能占用连接数分钟甚至更久。2500 并发是「同时在飞的请求数」，不是 QPS。

• 连接池规划：按 P99 请求时长估算并发占用，而非按 QPS；长任务会长时间占用并发名额。
• 分级重试：对限流（429）采用指数退避 + 抖动；对超时任务改用流式或异步续写，而非整段重试。
• 幂等与断点续写：长输出应开启流式，把已生成部分落盘，避免超时后从头再来浪费输出 token。

import os
import time
import httpx

API_KEY = os.environ.get("DEEPSEEK_API_KEY", "your-deepseek-api-key")
BASE_URL = "https://api.deepseek.com"
MODEL = "deepseek-flash"

client = httpx.Client(
    base_url=BASE_URL,
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=httpx.Timeout(connect=10.0, read=600.0, write=60.0, pool=10.0),
)

def chat_with_retry(messages, max_retries=5, max_tokens=384000):
    """带指数退避的长上下文调用，适配 2500 并发下的限流场景。"""
    last_err = None
    for attempt in range(max_retries):
        try:
            resp = client.post(
                "/chat/completions",
                json={
                    "model": MODEL,
                    "messages": messages,
                    "max_tokens": max_tokens,
                    "stream": False,
                },
            )
            if resp.status_code == 429:
                raise RuntimeError("rate_limited")
            resp.raise_for_status()
            return resp.json()
        except Exception as e:  # noqa: BLE001
            last_err = e
            backoff = min(2 ** attempt, 30) + (time.time() % 1)
            time.sleep(backoff)
    raise RuntimeError(f"chat failed after {max_retries} retries: {last_err}")

if __name__ == "__main__":
    out = chat_with_retry([
        {"role": "system", "content": "You are a long-context multimodal agent."},
        {"role": "user", "content": "Summarize the attached 200-page spec into an action plan."},
    ])
    print(out["choices"][0]["message"]["content"][:500])

还要注意计费时间窗口：高峰为周一至周五 9:00-12:00、14:00-18:00，空闲为高峰一半。长上下文批量任务应尽量调度到空闲时段，输出成本可从高峰 8 元降到空闲 4 元每百万 tokens。另外，自北京时间 2026-09-14 12:00 起，deepseek-v4-pro 的请求会全部路由到 V4.1-Flash 并按 Flash 价计费，这实际上是一次面向老用户的隐性升级——存量 v4-pro 调用会自动获得 1M 上下文与新能力，但计费口径也随之改变，需在账单监控里单独拆分。

思考模式三档 low/high/max 与非思考模式：长上下文 Agent 的推理预算分配

V4.1-Flash 默认开启思考模式，并支持 low / high / max 三档强度，同时保留非思考模式。对长上下文 Agent 而言，思考强度本质上是输出 token 预算与推理深度的旋钮：强度越高，模型生成的思考链越长，输出 token 消耗越大，而对复杂任务的准确性提升也越明显。

选择依据可以归纳为一条原则：任务的不可分解推理步骤越多，档位越高。官方基准也侧面印证了上限能力——GPQA Diamond 90.9、Codeforces 评级 3471、MathArena Apex 65.6，这些高分通常需要高思考强度才能复现。但注意 384K 输出上限在高强度下会被真实消耗，若任务本身需要输出超长代码库或长报告，应把 max 留给「必须先想清楚」的阶段，最终产出改用非思考或 low 生成，避免思考链挤占正式输出额度。

另一个坑是：思考模式的中间推理内容也计入输出计费。因此在长上下文批量任务中，务必对相同输入做缓存复用，并尽量让思考链只针对真正变化的增量部分展开，而不是每轮都对整段上下文重新深想。

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

V4.1-Flash 具备原生多模态视觉理解能力，支持三种图片输入方式：图片链接、base64 与 Files API。三者不是简单等价，而是对应不同的工程权衡。

• 图片链接：传 URL，服务端拉取。适合图片已在公网可访问 CDN 的场景，请求体小、传输快。约束是链接必须可被稳定访问，且有失效风险。
• base64 内联：把图片编码进请求体。适合小图、内网图、一次性图片，无需额外存储。代价是请求体膨胀，大图会显著增加带宽与内存占用。
• Files API：先上传拿到文件引用，再在多轮请求中复用。适合长上下文 Agent——同一张图被反复引用时只上传一次，天然与缓存复用配合。

在长上下文多模态 Agent 中，推荐策略是以 Files API 为主、base64 为辅、链接为特例：进入会话的图片先上传 Files API 获得引用，后续所有轮次引用同一 ID，输入侧即可命中缓存；临时缩略图或一次性截图用 base64；已托管在 CDN 的公开素材直接用链接。这样既控制了请求体大小，又最大化了缓存命中率。

import os
import base64
import httpx

API_KEY = os.environ.get("DEEPSEEK_API_KEY", "your-deepseek-api-key")
BASE_URL = "https://api.deepseek.com"
MODEL = "deepseek-flash"

client = httpx.Client(
    base_url=BASE_URL,
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=httpx.Timeout(read=600.0),
)

def to_base64(path: str) -> str:
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")

def build_multimodal_messages(image_url=None, image_b64=None, file_id=None):
    """三种视觉输入路径统一组装为多模态消息。"""
    parts = [{"type": "text", "text": "Describe the architecture diagram in detail."}]
    if image_url:
        parts.append({"type": "image_url", "image_url": {"url": image_url}})
    if image_b64:
        parts.append({
            "type": "image_url",
            "image_url": {"url": f"data:image/png;base64,{image_b64}"},
        })
    if file_id:
        parts.append({"type": "file", "file_id": file_id})
    return [{"role": "user", "content": parts}]

if __name__ == "__main__":
    msgs = build_multimodal_messages(image_url="https://example.com/diagram.png")
    resp = client.post(
        "/chat/completions",
        json={"model": MODEL, "messages": msgs, "max_tokens": 4096},
    )
    resp.raise_for_status()
    print(resp.json()["choices"][0]["message"]["content"][:300])

工程坑：不同输入方式对缓存命中的友好度不同。base64 图片如果内容有细微差异（例如重新编码导致字节不同），会导致缓存未命中，因此同一张图应保持固定编码产物。Files API 的引用 ID 稳定，最适合长会话复用。此外，多模态输入会显著抬高 prefill 计算量，应在会话规划阶段限制单轮图片数量，避免首 token 延迟失控。

JSON Output、Tool Calls 与 Responses API：长上下文多模态 Agent 的结构化输出链路

V4.1-Flash 支持 JSON Output、Tool Calls、Responses API，这三者组合起来才是完整的 Agent 输出链路。JSON Output 保证模型输出可被程序解析；Tool Calls 让模型能声明并调用外部工具；Responses API 则提供了更贴近 Agent 编排的请求/响应抽象。

推荐的分层设计是：用 Responses API 承载会话与状态，用 Tool Calls 驱动动作，用 JSON Output 约束最终结构化结果。具体而言，工具调用的参数由模型以结构化形式给出（JSON Output 在其底层保证可解析），工具执行结果作为新的上下文回注，再由 Responses API 维持整段会话的连续性与缓存命中。

import os
import json
import httpx

API_KEY = os.environ.get("DEEPSEEK_API_KEY", "your-deepseek-api-key")
BASE_URL = "https://api.deepseek.com"
MODEL = "deepseek-flash"

client = httpx.Client(
    base_url=BASE_URL,
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=httpx.Timeout(read=600.0),
)

tools = [{
    "type": "function",
    "function": {
        "name": "search_repo",
        "description": "Search a code repository by natural language query.",
        "parameters": {
            "type": "object",
            "properties": {
                "query": {"type": "string"},
                "top_k": {"type": "integer", "default": 5},
            },
            "required": ["query"],
        },
    },
}]

def agent_turn(messages):
    resp = client.post(
        "/chat/completions",
        json={
            "model": MODEL,
            "messages": messages,
            "tools": tools,
            "tool_choice": "auto",
            "response_format": {"type": "json_object"},
            "max_tokens": 8192,
        },
    )
    resp.raise_for_status()
    msg = resp.json()["choices"][0]["message"]
    calls = msg.get("tool_calls") or []
    return msg, calls

if __name__ == "__main__":
    msgs = [{"role": "user", "content": "Find auth-related bugs and summarize."}]
    msg, calls = agent_turn(msgs)
    if calls:
        for c in calls:
            args = json.loads(c["function"]["arguments"])
            print("tool:", c["function"]["name"], "args:", args)
    else:
        print("final:", msg.get("content"))

工程要点：JSON Output 与思考模式可以并存，但思考链本身不应被当作结构化输出解析，必须只解析最终 content。Tool Calls 的参数校验要放在服务端做二次校验，不能盲信模型输出。Responses API 适合需要跨请求维护状态的场景，能更好配合 KV Cache 持久化；而对简单一问一答，Chat Completions 更轻。组合使用时务必给每个工具写清晰的 description 与 JSON Schema，否则长上下文下模型容易选错工具。

Anthropic API、对话前缀续写与 FIM：多协议兼容下的 Agent 代码生成实践

V4.1-Flash 同时提供 Anthropic API 兼容、对话前缀续写与 FIM（仅非思考模式）。这三者在代码类 Agent 中各有明确落点。

• Anthropic API 兼容：让已有基于 Anthropic 协议栈的 Agent 框架几乎零改造切换，适合迁移存量代码 Agent。
• 对话前缀续写：给定对话历史的最后一段前缀，让模型接着写。适合「约束模型从某个确定位置继续」的场景，例如要求模型从指定的函数签名开始补全。
• FIM（Fill-In-the-Middle）：只支持非思考模式，给定前缀与后缀，让模型补中间。这是代码补全、局部修改、单测生成的利器，但不能与思考模式同用。

实践中的组合原则很清晰：需要深度推理的代码任务走思考模式 + Tool Calls；需要精确插入或补全的走 FIM 或对话前缀续写。把 FIM 用在长上下文代码仓库的局部修改上，可以避免让模型重写整段代码，从而大幅节省输出 token。对话前缀续写则适合要求格式严格一致的批量生成——先给出符合规范的头部，让模型顺着写下去。

兼容性坑：Anthropic API 与 OpenAI 风格 API 在工具调用、系统提示、停止序列的语义上并不完全一致，跨协议迁移时要逐项核对，尤其是 system 字段与 stop 序列的处理。FIM 只能走非思考模式，因此不要在需要强推理的重构任务上强行用 FIM，否则质量会明显下降。最后，前缀续写要控制前缀长度，过长前缀会占据上下文预算，应配合缓存优先注入。

本段到此完成了架构、显存、命名与协议层的拆解：CED 非对称把输入激活压到 8B、输出留 16B；KV Cache 的 HBM 1/4、SSD 1/8 与相对初代 437 倍缩小，让 1M 上下文和 384K 输出进入可部署区间；deepseek-flash 命名与 2500 并发决定了调用规划；思考三档与多模态三路径、结构化输出与多协议决定了 Agent 的行为边界。下一段我们将把这些零件组装成完整的端到端长上下文多模态 Agent，并深入成本模型、缓存命中策略与生产级限流重试的实战细节。

在上一段中，我们已经把 DeepSeek-V4.1-Flash 的架构底座（552B MoE + CED 非对称激活）、1M 输入 / 384K 输出的能力边界、以及多模态与思考模式的接入方式搭了起来。这一部分我们进入真正的“答卷”环节：基准数字到底意味着什么、Agent 场景能不能扛住、钱怎么花、迁移怎么走、代码里有哪些坑。

GPQA Diamond 90.9 与 Codeforces 3471：V4.1-Flash 基准全面超越 V4 Pro 的解读

先看官方公布的硬数字。V4.1-Flash 在 GPQA Diamond 拿到 90.9，这是一个由领域专家出题、以物理/化学/生物研究生水平为目标的高难度推理集，非记忆型题库，能上 90 意味着模型在多步科学推理上已接近稳定正确。而 Codeforces 评级 3471 更激进——这不是“代码补全”的分数，而是竞赛级算法题的实战 Elo 水平，需要模型同时完成题面理解、算法设计、复杂度控制与边界处理。再叠加 MathArena Apex 65.6，这三个指标共同指向一件事：V4.1-Flash 作为新架构家族的最小尺寸成员，在推理与代码的核心能力上已经全面超越上一代的旗舰 V4 Pro。

这个“小尺寸反超旗舰”的结论之所以重要，是因为它把工程选型逻辑彻底改写了。过去我们的默认假设是：能力强的模型一定贵、一定慢、一定上下文短。而 V4.1-Flash 给出的组合是：1M tokens 上下文 + 384K 最大输出 + 超越 V4 Pro 的基准 + 更低的 KV Cache 开销。对 Agent 开发者而言，这意味着“把最强模型留给规划、把海量上下文交给便宜模型”的分层架构，可以直接简化为“一个模型干到底”。

需要保持清醒的是基准的边界：GPQA 不是开放域真实性评测，Codeforces 评级来自官方基准而非真实随机赛题，MathArena Apex 也是特定题型分布。生产系统里仍应保留你自己的评估集，尤其是长上下文下的推理质量衰减曲线——1M 上下文能装进去，不代表在 900K 位置上的检索与推理仍然可靠。

Terminal-Bench 2.1 得分 90.6 与 CyberGym 88.1：Agent 类任务评测表现拆解

如果说上面三个是“脑力分”，那么接下来两个就是“动手分”。Terminal-Bench 2.1 得分 90.6，衡量的是模型在真实终端环境中完成多步操作任务的能力：读文件、跑命令、解析报错、修正再重试。这个分数直接对应我们常说的Computer Use / Shell Agent 场景。CyberGym 88.1 则聚焦安全攻防类任务，V4 Pro 在这两项上的对应成绩是 87.9 和 83.3，也就是说 V4.1-Flash 在 Terminal-Bench 上提升约 2.7 分，在 CyberGym 上提升约 4.8 分。

拆开看更值得注意：CyberGym 这种安全场景对长链条、强约束、不可出错的要求极高，提升幅度反而比通用终端任务更大，说明新预训练方法与 RL 后训练带来的增益，在需要严密推理与工具调用的任务上被放大了。工程上这对应两个落地方向：

• 运维与 CI/CD Agent：让模型接管日志分析、构建失败定位、依赖冲突修复，长上下文使它能一次性读入完整构建日志而不是被截断。
• 安全分析 Agent：漏洞复现、流量研判、规则生成，配合思考模式 max 档做深度推理。

但请务必记住一个铁律：基准分不等于无人值守的可靠性。90.6 意味着 100 个任务里仍有接近 10 个会失败，而终端 Agent 的一次误操作（比如 rm -rf）代价极高。所以真实部署必须叠加沙箱、命令白名单、危险操作二次确认与完整的回滚快照，基准分只是让我们“敢用”，不是“不用防护”。

定价与时段策略：缓存命中/未命中与高峰空闲费率下的长上下文成本优化

长上下文 Agent 的头号敌人永远是成本。V4.1-Flash 的官方定价（北京时间 2026-09-10 12:00 生效，单位为元/百万 tokens）给了我们非常明确的优化抓手：

高峰时段定义为周一至周五的 9:00-12:00 与 14:00-18:00，空闲时段价格为高峰的一半。这张表里最关键的一组倍率不是“降价多少”，而是缓存命中与未命中的价差：1 元 vs 0.02 元，整整 50 倍。换句话说，同一个 100K tokens 的文档，命中缓存后输入成本几乎可以忽略不计。

由此推导出三条可执行策略：

1. 把稳定前缀做满缓存。系统提示、工具定义、代码仓库摘要、长文档前部等在多轮之间不变的内容，全部放在 prompt 的最前面，保证缓存命中。变化的内容一律后置——这是长上下文成本优化的第一性原理。
2. 用空闲时段跑批。所有非实时任务（离线评测、批量代码审查、知识抽取、夜间数据管道）挪到空闲窗口执行，直接省掉一半费用。
3. 控制输出成本。输出是 4/8 元，且 384K 输出能力很容易被滥用。要求模型返回结构化短结果（JSON Output），把长篇内容让它写成文件而不是打印到对话里。

下面是一段真实可跑的 Python 成本感知调用示例，核心是“固定前缀 + 变化后缀 + 结构化输出”：

import os, json
from openai import OpenAI

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

# 稳定前缀：放最前面，最大化缓存命中
FROZEN_PREFIX = (
    "你是代码仓库审查 Agent。以下是仓库约定的审查规范与工具说明，内容长期不变：\n"
    "1) 只报告可复现的高危问题；2) 输出严格 JSON；3) 不臆测未提供的文件。\n"
)

def review(repo_summary: str, changed_file: str) -> dict:
    messages = [
        {"role": "system", "content": FROZEN_PREFIX + "\n仓库整体摘要：\n" + repo_summary},
        {"role": "user", "content": "请审查该变更文件：\n" + changed_file}
    ]
    resp = client.chat.completions.create(
        model="deepseek-flash",
        messages=messages,
        response_format={"type": "json_object"},
        max_tokens=4096
    )
    usage = resp.usage
    return {
        "result": json.loads(resp.choices[0].message.content),
        "cache_hit": getattr(usage, "prompt_cache_hit_tokens", 0),
        "cache_miss": getattr(usage, "prompt_cache_miss_tokens", 0)
    }

if __name__ == "__main__":
    out = review("仓库摘要占位", "diff 占位")
    print(json.dumps(out, ensure_ascii=False))

注意我们把 repo_summary 拼进 system 前缀而非每轮 user 消息，且所有多轮请求复用同一段前缀文本——缓存命中判定依赖前缀逐字节一致，任何改动（哪怕多一个换行）都会导致未命中，成本直接翻 50 倍。

2026-09-14 12:00 起 deepseek-v4-pro 全量路由到 V4.1-Flash：迁移影响与计费变化

官方明确：北京时间 2026-09-14 12:00 起，所有发往 deepseek-v4-pro 的请求将被全部路由到 V4.1-Flash，并按 Flash 的价格计费。同时旧模型名 deepseek-v4-flash 与 deepseek-v4-flash-vision-exp 已下线并做兼容路由，当前应统一使用 deepseek-flash。

对生产系统而言，这条政策有三层影响：

• 成本下降是确定的。V4 Pro 流量落到 Flash 价，输入输出都更便宜，属于“能力更强还更省钱”的窗口期。
• 行为差异是隐性风险。即使基准分更高，两个模型在输出风格、拒答边界、工具调用格式、思考模式默认行为上仍可能有差异。V4.1-Flash 默认开启思考模式，这会让延迟与输出 token 数显著变化，如果你的下游解析器假设“返回即最终答案”，可能在 9-14 之后突然收到思考过程的包装。
• 迁移窗口只有几天。不要等到路由生效当天才发现问题。

推荐的动作清单：

1. 立刻把代码里的硬编码模型名改为 deepseek-flash，让路由行为显式化。
2. 在预发环境用 影子流量对比 V4 Pro 与 V4.1-Flash 的输出差异，重点看 JSON 可解析率、工具调用参数正确率、平均输出长度。
3. 评估 思考强度 的档位选择：低延迟场景用非思考或 low，复杂规划用 high/max，避免全局默认吃掉延迟预算。
4. 检查计费与配额监控：并发限制为 2500，确认你的限流器与新上限匹配。

{
  "model": "deepseek-flash",
  "messages": [
    {"role": "system", "content": "你是迁移校验 Agent，请对比两版输出差异。"},
    {"role": "user", "content": "请核对以下约束：输出严格 JSON、不新增字段、不输出思考过程。"}
  ],
  "response_format": {"type": "json_object"},
  "thinking": {"type": "enabled", "budget": "high"},
  "max_tokens": 8192
}

这段 JSON 是请求体形态示意：显式声明 response_format 保证结构化，显式声明思考档位避免默认值漂移，从而把迁移带来的行为不确定性收敛到可控范围。

552B MoE + 新预训练与更大规模 RL 后训练：能力提升背后的训练侧机制

为什么“最小尺寸成员”能反超旗舰？答案在训练侧。V4.1-Flash 是 552B 总参数 MoE，采用全新的 Causal-Encoder-Decoder（CED）非对称架构：输入侧只激活 8B，输出侧激活 16B。这个设计的直觉是——理解比生成更“便宜”。输入侧面对的是给定的上下文，任务是把 1M tokens 压成有效表示，8B 激活足够；而输出侧需要逐步生成、需要更强的推理与决策，所以给到 16B 激活。非对称激活让模型在长上下文输入场景下的算力花在刀刃上。

与之配套的是两项训练侧变化：新的预训练方法 与 更大规模的 RL 后训练。预训练决定知识底座与长上下文建模能力，RL 后训练决定“会不会用工具、会不会按格式交付、会不会在多步任务里保持目标”。这正好解释了为什么 Terminal-Bench 2.1（90.6）和 CyberGym（88.1）这类强过程、强约束的 Agent 指标提升明显——它们本质上考的是 RL 后训练塑造出来的行为策略，而不是单纯的知识量。

还有一个容易被忽视的工程事实：KV Cache 的 HBM 需求降至上一代的 1/4，SSD 存储降至 1/8，相比初代 DeepSeek 缩小约 437 倍。这意味着 1M 上下文不再只是“接口支持”，而是可长期驻留、可高并发服务的工程能力。对做多轮 Agent 的团队，这直接决定了你能不能在会话之间持久化上下文，而不是每次重建。

Hugging Face 权重与官方合作伙伴接入：WorkBuddy、CodeBuddy 与 OpenCode 的落地参考

V4.1-Flash 的 权重已在 Hugging Face 放出，并附带技术报告。对需要私有化、需要审计、需要自定义推理栈的团队，这是完整的落地路径；对大多数应用团队，更实用的参考是官方合作伙伴：WorkBuddy（含 CodeBuddy）与 OpenCode 已全量接入。

这两类接入方的工程价值在于，它们代表了两种典型 Agent 形态：IDE 内的编码 Agent 与 终端/工作流 Agent。它们必须真实处理长上下文截断、工具调用并发、思考模式开关、失败重试与状态恢复——这些正是你自己要踩的坑。参考它们的取舍，能少走很多弯路。同时，权重开源 + 技术报告意味着你可以做本地评测基线，把官方基准与你的业务评估集对齐，而不是盲信单一榜单。

长上下文多模态 Agent 的工程坑：从 1M 输入到 384K 输出的截断、重试与状态管理

这一节是全文最“疼”的部分。1M 输入、384K 输出听起来很美，实际落地会撞上一连串问题：

• 请求体过大导致网关超时。1M tokens 的请求序列化后体积巨大，客户端与中间层都要放宽限制，并优先使用 Files API / 图片链接 而不是把 base64 直接塞进消息体。原生多模态支持图片链接、base64 与 Files API 三种方式，长会话中优先选链接与 Files API。
• 384K 输出不等于一次能吐完。长输出极易触发超时与截断，正确做法是分片生成 + 增量落盘：让模型按章节/模块分段输出，每段结束就持久化，失败只重试当前段，而不是整篇重来。
• 重试必须幂等。Agent 调用工具时重试可能造成重复写操作。为每个工具调用生成确定性 ID，服务端做去重；对写操作要求模型给出唯一键。
• 并发与限流。并发上限 2500，但真实瓶颈常在 token 吞吐。用令牌桶按 tokens 限流而非按请求数，并对高峰期做退避。
• 多轮状态管理。不要把全部历史无限追加，否则缓存前缀频繁失效。策略是：固定前缀（缓存）+ 滚动摘要（压缩历史）+ 最近 N 轮原文。
• 截断检测。检查 finish_reason 是否为长度截断，若截断则用“从前文继续”的提示续写，而不是重新发起完整任务。
• 思考模式的坑。思考模式默认开启，输出里可能包含思考内容；FIM 仅支持非思考模式；对话前缀续写与思考模式的组合要单独验证。

另外提醒：JSON Output、Tool Calls、Responses API、Anthropic API、对话前缀续写、FIM 都支持，但能力矩阵并非完全正交——FIM 只在非思考模式可用。设计降级路径时要按“能力组合”而不是“能力清单”来测。

总结与最佳实践

• 选型收敛：V4.1-Flash 基准全面超越 V4 Pro（GPQA Diamond 90.9、Codeforces 3471、MathArena Apex 65.6、Terminal-Bench 2.1 90.6、CyberGym 88.1），可以把它作为默认主力模型，不再需要“强模型规划 + 弱模型执行”的分层。
• 立即改名：统一使用 deepseek-flash，旧名 deepseek-v4-flash 与 deepseek-v4-flash-vision-exp 已下线并走兼容路由。
• 盯紧 9-14 12:00：该时刻起 deepseek-v4-pro 请求全部路由到 V4.1-Flash 并按 Flash 价计费，成本下降但行为可能漂移，务必提前做影子对比。
• 成本三板斧：稳定前缀做满缓存（命中/未命中价差 50 倍）、非实时任务挪到空闲时段（价格为高峰一半）、输出尽量结构化短小（384K 是上限不是目标）。
• 显式声明行为：明确指定思考强度（low/high/max）与 response_format，不要依赖默认值；FIM 仅用于非思考模式。
• 多模态取流：优先图片链接与 Files API，base64 仅作兜底。
• 长输出工程化：分片生成、增量落盘、按段重试、检测 finish_reason 截断并续写。
• 安全兜底：终端与安全类 Agent 必须叠加沙箱、命令白名单、危险操作二次确认与快照回滚，基准分高不等于可无人值守。
• 状态策略：固定前缀 + 滚动摘要 + 最近 N 轮原文，避免无限追加历史导致缓存失效。
• 本地基线：结合 Hugging Face 权重与技术报告建立私有评估集，参考 WorkBuddy（含 CodeBuddy）与 OpenCode 的全量接入实践，把官方基准转化为你的业务指标。