DeepSeek V4.1-Flash-1017：DeepSWE 77.0、MIT 权重与 100 万 token 上下文

这次到底交付了什么

模型卡短而具体。V4.1-Flash-1017 在推理、编码、Agent 任务和视觉基准上都有提升，同时降低了任务执行时长和输出长度——模型卡把这个叫「在多个 Agent harness 上推进性能与成本的帕累托前沿」。权重和仓库都是 MIT 许可。上下文 100 万 token，推荐的采样参数是 temperature 1.0、top_p 1.0，max_tokens 至少 256K。

大多数人会跳过的是 prompt 编码那一节。这个版本不提供 Jinja 格式的 chat template。取而代之的是一个 encoding 目录，里面是自包含的 Python 参考实现，附带多轮对话、工具调用、思考模式、数值推理强度、对话中途的 system 消息、交错图片内容的测试用例；另外还有 deepseek-recipe：一组 Rust 库加 Python 绑定，把 Messages、Chat Completions、Responses API 请求转成 DeepSeek 的 Conversation 格式，再把模型输出解析成完整或流式响应。

如果你的技术栈假设「丢个 chat template 进去就行」，那这个假设现在变成了一项迁移任务。给它留预算。

# Search & Fetch are now first-class tools on the DeepSeek API (api-docs.deepseek.com/guides/search)
import requests

API = "https://api.deepseek.com"
HEADERS = {"Authorization": "Bearer <DeepSeek API Key>", "Content-Type": "application/json"}

resp = requests.post(
    f"{API}/v1/tools/search",
    headers=HEADERS,
    json={
        "query": 'deepseek "release notes" site:huggingface.co OR site:github.com lang:en after:2026-09',
        "count": 5,
        "need_content": True,
    },
    timeout=60,
)
resp.raise_for_status()
for r in resp.json()["results"]:
    # rerank_score runs 0-3; the docs treat 1.5+ as high quality
    print(round(r["rerank_score"], 2), r["date"], r["title"], r["url"])

怎么读这张基准表才不会骗自己

表里对比了 K3、GLM-5.3、GPT-5.6 Sol 和 Opus 5。有两个脚注比数字更重要：带剑标的 HLE 数字是纯文本子集，而且跑分用了特定 harness——Terminal-Bench 4.0 用 Claude Code，DeepSWE v1.1 用 Mini-SWE-V2。harness 的选择对 Agent 分数的影响，比表里某些差值还大。

改成按提升幅度排序而不是按绝对分数排，形状就清楚了。增益集中在执行层面：Terminal-Bench 4.0 涨 11.1，ProgramBench 涨 8.8，Apex Bench 涨 7.5，Automation-Bench 涨 5.7。知识类基准几乎没动，36.8 到 42.6，而且明显落后于 Opus 5。这是一次前后一致的产品选择：DeepSeek 不打算赢冷知识，它要赢的是「模型跑命令、读报错、再试一次」那个循环。

所以有人说这个模型打赢 Opus 5，你要问是哪一栏。DeepSWE 是赢了，77.0 对 74.0；ProgramBench 没有，NL2Repo 也没有。任何单一头条数字，都是你还没读过的那张表的摘要。

# Read the model card table as deltas against the previous checkpoint, not as absolute truth.
CARD = {
    # benchmark: (v4.1-flash-1017, v4.1-flash, opus-5)
    "HLE w/o tools":        (42.6, 36.8, 56.3),
    "Terminal-Bench 4.0":   (42.3, 31.2, 51.8),
    "DeepSWE v1.1":         (77.0, 74.2, 74.0),
    "ProgramBench":         (29.1, 20.3, 37.0),
    "NL2Repo-Bench":        (68.2, 65.4, 75.3),
    "Automation-Bench":     (60.5, 54.8, 50.3),
    "Agents' Last Exam":    (35.4, 31.8, 28.6),
    "Apex Bench v1.1":      (72.1, 64.6, 65.8),
}

print(f"{'benchmark':22}{'delta vs prev':>14}{'vs Opus 5':>12}")
for name, (new, prev, opus) in sorted(CARD.items(), key=lambda kv: kv[1][0] - kv[1][1], reverse=True):
    print(f"{name:22}{new - prev:+14.1f}{new - opus:+12.1f}")

# Read: +11.1 on Terminal-Bench 4.0 is a real jump for agent work.
# But ProgramBench and NL2Repo still trail, so "beats Opus 5" is only true on DeepSWE.

价格表才是这次真正的功能

API 模型名是 deepseek-flash，上下文 100 万，最大输出 384K，并发上限 2,500。每百万 token 定价：缓存命中输入，低谷 $0.003、高峰 $0.006；缓存未命中输入，低谷 $0.15、高峰 $0.30；输出低谷 $0.60、高峰 $1.20。高峰时段是 UTC 周一至周五 01:00–04:00 与 06:00–10:00，中国法定节假日除外。其余时间全部是低谷，半价。

一次消耗 100 万缓存未命中输入 token 加 100 万输出 token 的任务，落在高峰窗口里是 $1.50，落在窗口外是 $0.75。同样的 token，同样的模型，账单差一倍。我见过不少批处理流水线把夜间任务正好排在错的那个小时，因为没人去查「高峰」的定义。这只是一行调度器改动，附带五折。

并发 2,500 也值得记一下。这个值足够高，意味着扇出型任务的瓶颈通常在你自己的编排层，而不是服务商。

# Peak hours are published, so cost per run is a scheduling decision, not a constant.
from datetime import datetime, timezone

# deepseek-flash, USD per 1M tokens (api-docs.deepseek.com/quick_start/pricing)
PRICE = {
    "cache_hit":  {"off": 0.003, "peak": 0.006},
    "cache_miss": {"off": 0.15,  "peak": 0.30},
    "output":     {"off": 0.60,  "peak": 1.20},
}
PEAK_BLOCKS = [(1, 4), (6, 10)]  # UTC, Monday-Friday, excluding Chinese public holidays

def is_peak(ts: datetime) -> bool:
    if ts.weekday() >= 5:
        return False
    return any(start <= ts.hour < end for start, end in PEAK_BLOCKS)

def run_cost(in_miss, out, ts, in_hit=0.0):
    band = "peak" if is_peak(ts) else "off"
    total = (
        in_hit / 1e6 * PRICE["cache_hit"][band]
        + in_miss / 1e6 * PRICE["cache_miss"][band]
        + out / 1e6 * PRICE["output"][band]
    )
    return band, round(total, 4)

now = datetime(2026, 10, 19, 2, 0, tzinfo=timezone.utc)   # inside the 01:00-04:00 UTC window
print(run_cost(1_000_000, 1_000_000, now))                 # ('peak', 1.5)
later = now.replace(hour=12)
print(run_cost(1_000_000, 1_000_000, later))               # ('off', 0.75)
# Same tokens, half the bill. Batch jobs should not run at 02:00 UTC on a Tuesday.

公布的高峰窗口之外是半价。调度器是最便宜的优化项。

输出长度是定价功能，不是脚注

模型卡把「输出更短、任务完成更快」放在很前面，而在 Agent 循环里，钱就出在这两点上。输入 token 每个季度都在变便宜，输出 token 不会，因为模型得一个一个生成。一个任务用 3,500 个输出 token 而不是 4,200 个完成，单价上就先省了约 17%，还没算少跑几轮带来的时间成本。

实际的含义是：要量「每个完成任务消耗的输出 token」，而不是「每个请求消耗的 token」。回答短但需要三次重试的模型，比话多但一次做对的模型更贵。下面那段闸门代码就是这个思路：通过率、啰嗦程度、重试次数三项绑在一起看。

# A migration gate: same harness, same tasks, old checkpoint vs new checkpoint.
import statistics

def score_run(results):
    done = [r for r in results if r["completed"]]
    return {
        "pass_rate": len(done) / len(results),
        "tool_call_valid": sum(r["valid_tool_calls"] for r in results) / max(1, sum(r["tool_calls"] for r in results)),
        "out_tokens_per_task": statistics.mean(r["output_tokens"] for r in results),
        "retries_per_task": statistics.mean(r["retries"] for r in results),
    }

def gate(baseline, candidate, min_pass=0.0, max_out_ratio=1.0):
    verdict = {
        "pass_rate_ok": candidate["pass_rate"] >= baseline["pass_rate"] + min_pass,
        "tool_calls_ok": candidate["tool_call_valid"] >= baseline["tool_call_valid"] - 0.005,
        "verbosity_ok": candidate["out_tokens_per_task"] <= baseline["out_tokens_per_task"] * max_out_ratio,
        "retries_ok": candidate["retries_per_task"] <= baseline["retries_per_task"],
    }
    verdict["ship"] = all(verdict.values())
    return verdict

# Fill these with your own 20-task suite, run through the identical harness
# (the card itself uses the Claude Code harness for Terminal-Bench and Mini-SWE-V2 for DeepSWE).
print(gate({"pass_rate": 0.55, "tool_call_valid": 0.98, "out_tokens_per_task": 4200, "retries_per_task": 0.6},
           {"pass_rate": 0.65, "tool_call_valid": 0.99, "out_tokens_per_task": 3500, "retries_per_task": 0.4}))

Search 与 Fetch 也进了工具面

DeepSeek 还在 /v1/tools 下开放了 Search 和 Fetch，鉴权和主 API 一样用 Bearer。Search 接受 1–128 字符的 query、1–50 的 count、可选的原始问题（用于改善查询理解）、可选本地化 IP，以及 need_content 开关。每条结果带 0–3 的 rerank_score，文档把 1.5 及以上视为高质量。Fetch 则直接抓取页面。

查询语法支持我真正会用的操作符：site: 与 -site:、用引号做精确短语、lang:、after:/before: 日期过滤。这意味着像第一段代码那样写检索步骤，可以不付搜索厂商的钱，代价是你继承的是 DeepSeek 自己的排序而不是自建排序。这个排序在你所在领域准不准是个开放问题，而且测起来很便宜：拿 200 条你已经知道正确答案的查询，看正确 URL 落在第几位。

# The card ships no Jinja chat template. Use the reference encoder or deepseek-recipe,
# and keep your own prompt regression tests, because token ids for tool calls can move.
import subprocess, json

def encode_with_reference(conversation_path: str) -> dict:
    out = subprocess.run(
        ["python3", "encoding/encoding.py", "--input", conversation_path],
        capture_output=True, text=True, check=True,
    )
    return json.loads(out.stdout)

def assert_tool_call_roundtrip(payload: dict):
    ids = payload["token_ids"]
    assert len(ids) > 0, "empty encoding"
    # multi-turn, tool calling, thinking mode and interleaved images are all covered
    # by the shipped test cases; run them against the exact revision you pin.
    return {"tokens": len(ids), "model": payload.get("model"), "revision": payload.get("revision")}

print(assert_tool_call_roundtrip({"token_ids": [1, 2, 3], "model": "deepseek-v4.1-flash-1017", "revision": "main"}))

Agent 的进步体现在执行类基准上，不在知识类基准上。

切换前我会卡哪几道门

先钉住版本号。模型卡的技术报告指向母模型，增量的说明很薄，所以你今天下载到的权重，应该被哈希并留存。然后把你自己那套二十个任务，用完全相同的 harness 在旧权重和新权重上各跑一遍，比四个数：通过率、工具调用合法率、每任务输出 token 数、每任务重试次数。

最先咬你的会是两件事。一是编码变化，任何假设 Jinja 模板的代码，在工具调用上都会悄悄生成错的 token 序列。二是长上下文行为，100 万 token 的窗口在诱惑你把整个仓库塞进去，而长上下文恰恰是注意力预算、延迟和成本会同时朝坏方向动的地方。

这两条都不是不试的理由。MIT 权重，加上低谷时段每百万输入 token $0.15 的 API，是能让一些「原本跑不起、只能偶尔跑」的东西变成「可以一直跑」的组合。只是别让一张基准表替你做决定。