DeepSeek V4 Flash 深度拆解：第一个为智能体而生的开源 MoE——从 2840 亿参数稀疏架构、百万上下文到 Agentic 工作流实战（2026）

2026 年 6 月底，OpenRouter 在一篇分析里把当时最值得关注的开源大模型概括为「开源 F4」。其中排在第一位的，是 DeepSeek V4 Flash——官方把它定义为「第一个被开发团队直接塞进智能体（Agent）工作流的开源模型」。它不是简单地把聊天模型开源，而是从训练目标、上下文长度、工具调用能力到部署形态，全部围绕「让模型能当一名真正干活的智能体」来设计。

本文从工程视角拆开这件事：MoE 稀疏架构到底省了什么、百万 token 上下文是怎么撑住的、13B 激活参数凭什么能在单张 A100 上跑起来、以及——最重要的——如何用 vLLM 把它部署成一个 OpenAI 兼容的 Agentic 服务，并写出真正能调用工具、跑多轮规划的应用代码。

一、背景介绍：为什么 2026 年的开源模型突然「能干活了」

1.1 从「对话模型」到「智能体模型」的拐点

过去三年，开源大模型的主线叙事一直是「追平闭源」。大家比的是 MMLU、比的是 HumanEval、比的是谁先开源一个能跟 GPT 掰手腕的权重。但 2025 年底到 2026 年，叙事变了。

真正的生产力不在「回答一个问题」，而在「替你完成一串动作」：读代码、改文件、跑测试、查数据库、调 API、汇总结果。这类任务的本质不是单次生成，而是长程规划 + 多轮工具调用 + 结构化输出。OpenRouter 的数据很说明问题：2026 年企业调用中国开源模型的 token 占比周周超过 30%，不是因为中文友好，而是因为「够便宜、够能干活、能自部署」。

DeepSeek V4 系列就是在这个拐点上发布的：

注意两个数字：285B 总参数但每次推理只激活 13B。这意味着它的「知识容量」接近一个巨型模型，但「单次推理成本」只相当于一个 13B 的小模型。这正是 MoE（Mixture of Experts，混合专家）架构的精髓，后面会展开。

1.2 为什么是 Flash 而不是 Pro 更适合做智能体

Pro 版 1.6T 参数，即便量化后也需要 8 卡以上的集群才能跑，属于「企业级算力」的范畴。而 Flash 版把激活参数压到 13B，FP8 量化后单张 A100 80G 就能落地。对大多数团队来说，这意味着：

• 不用排队等云厂商的 API；
• 数据不出内网，合规可控；
• 成本从「按 token 计费」变成「一次性硬件投入 + 电费」。

而它的 SWE-bench Verified 得分是 79.0%（Pro 版 80.6%）——这个指标衡量的是「能否真实修好 GitHub 上的软件缺陷」，比聊天指标更贴近「能不能干活」。79% 已经逼近 GPT-5.5 级别的智能体表现，但成本只有零头。

1.3 MIT 协议：可商用、可改、可再分发

Flash 版采用 MIT 协议开源。对比 LLAMA 系列的商用限制、对比部分「开源但不许商用」的权重，MIT 意味着你可以：用它在产品里做推理、微调后闭源分发、甚至把权重嵌进自己的软件里卖。这是它能被大规模工程化落地的法律前提。

二、核心概念：把 MoE 和「百万上下文」讲透

2.1 MoE 到底省了什么

传统 Dense 模型（比如 LLaMA、Qwen 的某些版本）每一层都有一个巨大的前馈网络（FFN），处理每个 token 时全部参数都参与计算。参数量上去，算力成本线性上涨，这就是「越大越贵」。

MoE 的做法是：把 FFN 切成很多个「专家」（expert），再放一个「路由网络」（router）。每个 token 进来，router 只挑其中 Top-K 个专家（通常 K=2 或 1）参与计算。

token ──► router ──► 选 Top-2 专家 ──► 只计算这 2 个专家 ──► 输出
                       （其余几百个专家「睡大觉」）

直观对比：

• Dense 模型：总参数 = 激活参数。285B 的 Dense 模型，每次推理要算 285B 次运算。
• MoE 模型：总参数 = 所有专家之和（285B），但激活参数 = Top-K 专家之和（13B）。每次推理只算 13B。

省下来的不是参数，是 FLOPs 和显存带宽压力。 这也解释了为什么 Flash 能单卡跑：权重确实要全加载进显存（所以显存占用接近 285B 模型），但每次前向只激活 13B 的计算量（所以算力需求只是 13B 级别）。

2.2 共享专家 + 路由专家：DeepSeek 的工程取舍

DeepSeek 系列（从 V2/V3 延续到 V4）采用「共享专家 + 路由专家」的组合：

• 共享专家（shared experts）：每个 token 都会经过，负责承载通用的、共性的知识（语言结构、常识）。
• 路由专家（routed experts）：由 router 按 token 内容动态选择，负责承载专业化的、长尾的知识。

# 概念示意：简化版 MoE 前向（非真实源码，用于理解路由）
import torch
import torch.nn.functional as F

def moe_forward(hidden, shared_expert, routed_experts, router, k=2):
    # hidden: [seq, dim]
    shared_out = shared_expert(hidden)                 # 所有 token 都过共享专家
    router_logits = router(hidden)                     # [seq, num_experts]
    weights, indices = torch.topk(router_logits, k, dim=-1)  # 每个 token 选 Top-k
    weights = F.softmax(weights, dim=-1)
    routed_out = torch.zeros_like(hidden)
    for i in range(k):
        expert = routed_experts[indices[:, i]]          # 取出第 i 个被选中的专家
        routed_out += weights[:, i:i+1] * expert(hidden)
    return shared_out + routed_out

关键点：负载均衡。如果 router 永远选同一批专家，其他专家就「饿死」了，显存白占。DeepSeek 在 V3 引入的 auxiliary-loss-free（无辅助损失）负载均衡是重要创新——不靠额外惩罚项强制均衡，而是用一个可动态调整的偏置（bias）让 router 自然地把流量摊平到所有专家上。V4 延续了这一机制，并在 285B 规模上做更细的调优。

2.3 百万 token 上下文：不是「堆显存」而是「改注意力」

把上下文从 128K 拉到 1M，最直接的难点是注意力机制的平方级复杂度：标准注意力对每个 token 要和前面所有 token 算相似度，1M token 就是 10^12 量级的计算与显存。DeepSeek 从 V2 起就用 MLA（Multi-head Latent Attention，多头潜注意力） 解决这个问题。

MLA 的核心思想：不直接存每个 token 的完整 K/V（Key/Value），而是把 K/V 压缩成一个低维的「潜向量」（latent） 存下来。推理时再从这个小潜向量里解压出需要的 K/V。

标准 MHA:  存 [seq, n_heads, head_dim] 的 K/V   ──► 显存随 seq 线性爆炸
MLA:       只存 [seq, latent_dim] 的潜向量        ──► latent_dim << n_heads*head_dim

效果：KV Cache 体积大幅缩小（通常只有标准注意力的几分之一到十几分之一），这是 V4 能把上下文撑到 1M 且单卡可部署的底层原因之一。配合 V4 引入的新型长上下文注意力扩展机制（在 vLLM 里以专门实现的注意力后端形式存在，针对 1M 长度做优化），长文档、长代码库、超长对话才真正可用。

2.4 MTP（Multi-Token Prediction，多 token 预测）

Pro 版用到了 MTP 模块。传统模型一次只预测下一个 token；MTP 让模型一次预测接下来的多个 token。这不只是「生成更快」，在推理时它能配合投机解码（speculative decoding）：模型先「猜」几个 token，再由主模型一次性验证，命中率高时吞吐成倍提升。

传统:  t1 → t2 → t3 → t4   （4 次前向）
MTP:   主模型一次产出 [t1', t2', t3', t4'] 候选，验证通过 ──► 1 次前向拿 4 个 token

Flash 版虽然没有 Pro 那样完整的 MTP 模块，但在 vLLM 部署时仍可通过标准的投机解码（用一个小草稿模型）获得提速。

2.5 什么是「Agentic 模型」

「Agentic」不是营销词。一个合格的 Agentic 模型需要在训练阶段就被「喂」大量工具调用、多轮规划、结构化输出的样本。具体表现为：

1. 稳定的 Function Calling：能严格按 JSON Schema 输出工具调用参数，不漏字段、不胡编；
2. 长程一致性：在 50 轮对话里记住前面定下的计划、变量、约束；
3. 错误自纠：工具返回报错后，能读懂错误并换一种方式重试，而不是死循环；
4. 结构化输出：能稳定输出可被程序解析的 JSON / 代码块。

DeepSeek V4 Flash 的训练目标里直接包含「把模型塞进智能体工作流」这一项，所以它在上面几点上的表现明显优于「聊天模型硬改工具调用」的方案。

三、架构分析：DeepSeek V4 的部署拓扑与成本拆解

3.1 一次推理的资源账

以 Flash 版为例，先算显存账：

BF16 权重：285B 参数 × 2 字节 = 约 570 GB   ──► 单卡根本装不下
FP8 权重：285B 参数 × 1 字节 = 约 285 GB    ──► 仍需多卡，但近乎腰斩
INT4 权重：285B × 0.5 字节 ≈ 142 GB          ──► 2×A100 80G 可装（权重部分）

为什么「单张 A100 80G 能跑 Flash」？因为实际落地用的是 FP8 量化 + 专家并行：权重被切分到多卡，但常用配置下通过量化把单卡权重大小压到 7080G 区间，加上 KV Cache 用 FP8，单卡也能起。严格说「单卡流畅跑 1M 上下文」需要更激进的配置，但对 32K128K 上下文的常规 Agentic 场景，单卡 A100 80G 是可行的。

3.2 部署拓扑：EP、TP 与 PD 分离

MoE 模型部署有三个关键维度：

• TP（Tensor Parallel，张量并行）：把一个专家「竖切」到多卡。适合 Dense 层。
• EP（Expert Parallel，专家并行）：把不同专家「横放」到不同卡。MoE 的天然选择——每个专家完整放在一张卡上，router 把 token 路由过去。
• DP（Data Parallel，数据并行）：多份相同模型副本，分别处理不同请求。

DeepSeek V4 官方推荐的 vLLM 启动参数暴露了这套拓扑：

docker run --gpus all \
  --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:deepseekv4-cu130 \
  deepseek-ai/DeepSeek-V4-Pro \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --enable-expert-parallel \
  --data-parallel-size 8 \
  --compilation-config '{"cudagraph_mode":"FULL_AND_P"}'

逐项拆解：

3.3 生产级部署：EP + PD 分离

高并发场景下，还有一个关键架构：PD 分离（Prefill-Decode Disaggregation）。

• Prefill（预填充）：处理整段输入 prompt，计算量大、算力密集、延迟不敏感；
• Decode（解码）：逐 token 生成，延迟敏感、batch 小、显存带宽密集。

把两者放在同一批 GPU 上会互相干扰（Prefill 的长任务拖慢 Decode 的响应）。PD 分离把它们拆到不同实例：Prefill 集群算完 K/V 后，把结果传给 Decode 集群继续生成。阿里云 PAI 文档明确提到 DeepSeek-V4-Flash-FP8 / Pro-FP8 都可采用 EP+PD 分离方式部署。这是把吞吐和延迟同时拉满的工业级做法。

[Prompt] ──► Prefill 集群（算 K/V）──┐
                                     ├──► Decode 集群（逐 token 生成）──► [Output]
[Prompt] ──► Prefill 集群（算 K/V）──┘

四、代码实战：从零部署一个 Agentic 推理服务

下面进入干货。我们用 vLLM 把 DeepSeek V4 Flash 部署成 OpenAI 兼容服务，并写出能真正调用工具、跑多轮规划的 Agent 应用。

4.1 环境准备：拉镜像、下权重

# 1) 拉取带 DeepSeek V4 支持的 vLLM 镜像（cu129/cu130 视驱动而定）
docker pull vllm/vllm-openai:deepseekv4-cu129

# 2) 用 huggingface-cli 或 modelscope 下载 FP8 量化权重（推荐 FP8，显存与精度平衡）
#    HF:
hf download deepseek-ai/DeepSeek-V4-Flash-FP8 --local-dir /data/models/dsv4-flash-fp8
#    国内镜像（ModelScope）更快:
modelscope download --model deepseek-ai/DeepSeek-V4-Flash-FP8 --local_dir /data/models/dsv4-flash-fp8

4.2 单卡 FP8 部署 Flash（开发 / 中小流量）

docker run --gpus "device=0" \
  --ipc=host -p 8000:8000 \
  -v /data/models:/data/models \
  vllm/vllm-openai:deepseekv4-cu129 \
  deepseek-ai/DeepSeek-V4-Flash-FP8 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --enable-expert-parallel \
  --tensor-parallel-size 1 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.92 \
  --served-model-name deepseek-v4-flash

启动后，服务监听 http://localhost:8000，完全兼容 OpenAI 的 /v1/chat/completions 接口。验证一下：

curl -sS http://localhost:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [{"role":"user","content":"用一句话解释 MoE 架构"}],
    "max_tokens": 200
  }' | python3 -m json.tool

4.3 多卡 EP 部署 Pro（高并发 / 长上下文）

docker run --gpus all \
  --ipc=host -p 8000:8000 \
  -v /data/models:/data/models \
  vllm/vllm-openai:deepseekv4-cu130 \
  deepseek-ai/DeepSeek-V4-Pro \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --enable-expert-parallel \
  --tensor-parallel-size 8 \
  --data-parallel-size 1 \
  --max-model-len 1000000 \
  --gpu-memory-utilization 0.95

4.4 调用官方 API（不想自部署时）

如果暂时不想管显卡，直接用 DeepSeek 官方 API，改个 model 名即可：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DEEPSEEK_API_KEY",
    base_url="https://api.deepseek.com/v1",   # 或你自建的 http://localhost:8000/v1
)

resp = client.chat.completions.create(
    model="deepseek-v4-flash",                # 或 deepseek-v4-pro
    messages=[{"role": "user", "content": "帮我写个快排"}],
    max_tokens=512,
)
print(resp.choices[0].message.content)

下面所有实战代码都同时适用于「自部署 vLLM」和「官方 API」——只要把 base_url 和 model 换掉。这就是 OpenAI 兼容接口的红利。

4.5 Function Calling 实战：让模型真正「动手」

Agentic 的核心不是「会说话」，是「会调用工具」。下面写一个天气查询 + 计算器的小智能体。tools 用 JSON Schema 描述，模型负责决定「什么时候调、传什么参」。

import json
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

# ---- 真实工具实现（模型不会碰这些代码，它只产出调用意图）----
def get_weather(city: str) -> str:
    # 真实场景这里调气象 API；示例返回模拟数据
    return json.dumps({"city": city, "temp_c": 26, "condition": "晴"})

def calc(expression: str) -> str:
    # 注意：生产环境别用 eval，这里仅为演示
    try:
        return str(eval(expression, {"__builtins__": {}}, {}))
    except Exception as e:
        return f"计算错误: {e}"

TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "查询指定城市的当前天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名，如 上海"}
                },
                "required": ["city"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "calc",
            "description": "计算一个数学表达式",
            "parameters": {
                "type": "object",
                "properties": {
                    "expression": {"type": "string", "description": "如 (3+5)*2"}
                },
                "required": ["expression"],
            },
        },
    },
]

DISPATCH = {"get_weather": get_weather, "calc": calc}

messages = [
    {"role": "user", "content": "上海现在多少度？如果比北京高 5 度，那北京实际多少度？"}
]

# 第一轮：模型决定要不要调工具
resp = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=messages,
    tools=TOOLS,
    tool_choice="auto",
)
msg = resp.choices[0].message
messages.append(msg)

# 执行模型请求的工具调用
for call in (msg.tool_calls or []):
    fn = json.loads(call.function.arguments)
    result = DISPATCH[call.function.name](**fn)
    print(f"[工具调用] {call.function.name}({fn}) -> {result}")
    messages.append({
        "role": "tool",
        "tool_call_id": call.id,
        "content": result,
    })

# 第二轮：把工具结果喂回模型，让它给出最终自然语言答案
final = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=messages,
)
print("回答:", final.choices[0].message.content)

这个循环揭示了一个关键事实：Agentic 模型的「智能」体现在第一轮——它读懂了「比北京高 5 度」这个隐含关系，先查上海天气，再算出北京温度，两次工具调用是有逻辑顺序的，而不是一次性把两个工具都甩出来。 这正是 V4 Flash「agentic-first」训练带来的差异。

4.6 多轮规划：写一个 ReAct 风格 Agent 框架

工具一多，手写 if/else dispatch 就崩了。下面写一个通用的 ReAct（Reason + Act）循环，支持任意工具、自动终止、最大步数保护（防止模型陷入死循环烧钱）。

import json
from openai import OpenAI
from typing import Callable

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

SYSTEM = (
    "你是一个严谨的助手。当需要信息时调用工具；"
    "拿到工具结果后继续推理，直到能完整回答用户再停止调用工具。"
)

def run_agent(user_query: str, tools: list, dispatch: dict, max_steps: int = 8):
    messages = [
        {"role": "system", "content": SYSTEM},
        {"role": "user", "content": user_query},
    ]
    for step in range(max_steps):
        resp = client.chat.completions.create(
            model="deepseek-v4-flash",
            messages=messages,
            tools=tools,
            tool_choice="auto",
        )
        msg = resp.choices[0].message
        messages.append(msg)

        if not msg.tool_calls:
            # 模型不再请求工具 → 认为已得出最终答案
            return msg.content

        for call in msg.tool_calls:
            args = json.loads(call.function.arguments)
            try:
                result = dispatch[call.function.name](**args)
            except Exception as e:
                result = f"工具执行失败: {e}"
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": str(result),
            })
    return "（达到最大步数，未完成任务）"

这个框架可以无缝接上你公司的内部系统：把「查订单」「发短信」「读数据库」写成工具函数，丢进 tools 列表，V4 Flash 就能自己编排调用顺序。一个有意思的工程细节是 max_steps——开源模型偶尔会在工具报错后反复重试同一个失败调用，不设上限会无限烧 token，这是自部署必须加的护栏。

4.7 让 Agent 读代码库：把长上下文用起来

1M 上下文的真正价值，是能把整个代码库塞进 prompt，让模型基于真实代码回答问题、改 bug。配合前面说的 MLA 压缩 KV Cache，长上下文的边际成本远低于直觉。

import pathlib, fnmatch

def collect_codebase(root: str, patterns=("*.py", "*.go", "*.ts"), max_files=60):
    files, size = [], 0
    for p in pathlib.Path(root).rglob("*"):
        if p.is_file() and any(fnmatch.fnmatch(p.name, pat) for pat in patterns):
            text = p.read_text(errors="ignore")
            files.append(f"# 文件: {p}\n{text}")
            size += len(text)
            if len(files) >= max_files or size > 600_000:   # 控制总 token 量
                break
    return "\n\n".join(files)

codebase = collect_codebase("/path/to/your/project")
prompt = f"以下是项目源码：\n{codebase}\n\n请找出所有未处理异常的数据库调用并给出修复建议。"

resp = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": prompt}],
    max_tokens=2048,
)
print(resp.choices[0].message.content)

实践提醒：1M 上下文不等于「无脑全塞」。真正生产里建议先做文件级检索 / tree-sitter 符号抽取，只把相关文件喂进去（类似 Graphify 的思路），既省钱又减少模型「注意力稀释」。V4 Flash 的长上下文是兜底能力，不是默认用法。

五、性能优化：把吞吐和成本压到极致

5.1 KV Cache 量化：FP8 是必选项

注意力占用的显存大头是 KV Cache。开启 --kv-cache-dtype fp8 后，KV Cache 显存直接减半，几乎是「免费」的优化，精度损失在长上下文下几乎不可感知。更激进可用 --kv-cache-dtype fp8_e5m2（更省但略有损）。

5.2 权重量化精度损失评估

量化是把开源模型「用得起」的前提，但要知道代价。一个实用的评估脚本：

def eval_quant(model_name, base_url, samples):
    """对比同一模型在 BF16 / FP8 / INT4 下对一批任务的一致性"""
    client = OpenAI(base_url=base_url, api_key="EMPTY")
    scores = {}
    for q in samples:
        r = client.chat.completions.create(
            model=model_name, messages=[{"role":"user","content":q}], max_tokens=256
        )
        scores[q] = r.choices[0].message.content
    return scores

# 经验值（行业实测，非精确基准）：
# BF16 -> FP8:  精度损失 < 1%，显存 ~50%，强烈推荐
# FP8  -> INT4: 精度损失 2~5%，显存再 ~50%，长上下文任务建议先测再上

经验法则：Agentic / 代码任务对量化比「聊天闲聊」更敏感。上线 INT4 前，务必用你真实的工具调用样本跑一遍回归，确认 JSON 字段不丢、参数类型不错。

5.3 投机解码（Speculative Decoding）

Decode 阶段是逐 token 的，延迟瓶颈在「每步都要等一次前向」。投机解码让一个小草稿模型先猜 N 个 token，主模型一次验证：

# 用一个小模型当草稿，加速 Flash 的 Decode
docker run --gpus all -p 8000:8000 \
  vllm/vllm-openai:deepseekv4-cu129 \
  deepseek-ai/DeepSeek-V4-Flash-FP8 \
  --trust-remote-code --kv-cache-dtype fp8 \
  --speculative-config '{"method":"ngram","num_speculative_tokens":5}'

ngram 是无需额外草稿模型的方案，靠 prompt 里的 n-gram 命中来投机；若用独立小模型（如 Qwen-0.5B）当草稿，命中率更高、提速更明显。实测在代码生成场景，投机解码能带来 1.5x~2x 的 Decode 提速。

5.4 Continuous Batching 与并发

vLLM 的 continuous batching 已经默认开启：不同请求不必等长，token 级动态拼批。但你要在客户端配合——别把请求串行化。下面是一个并发压测示例，用于找到你硬件的甜点并发数：

import asyncio, time
from openai import AsyncOpenAI

client = AsyncOpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

async def one_req(i: int):
    t0 = time.perf_counter()
    await client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{"role":"user","content":f"用 50 字解释第 {i} 个素数"}],
        max_tokens=120,
    )
    return time.perf_counter() - t0

async def bench(concurrency: int):
    tasks = [one_req(i) for i in range(concurrency)]
    lat = await asyncio.gather(*tasks)
    print(f"并发={concurrency} 平均延迟={sum(lat)/len(lat):.2f}s 吞吐={concurrency/sum(lat):.1f} req/s")

asyncio.run(bench(16))
asyncio.run(bench(32))
asyncio.run(bench(64))

通过逐步加压，找到「延迟开始陡增」的那个拐点并发数，它就是你的生产并发上限。

5.5 显存速查表（Flash 版，推理阶段）

注：上表是「权重」占用，未含 KV Cache 和激活显存。实际部署用 --gpu-memory-utilization 0.9 左右，给碎片留余量。

六、总结展望：开源模型「能干活」意味着什么

6.1 三个正在发生的趋势

1. 模型中立化：Codex 开放第三方模型接入、vLLM 把主流开源模型统一成 OpenAI 接口——「模型绑定」正在崩塌。团队可以今天用 DeepSeek V4 Flash，明天换 Qwen3.6，业务代码几乎不改。这对闭源 API 厂商是压力，对工程师是自由。

2. Agentic 成为模型的一等公民：从「聊天模型加工具调用外挂」到「训练目标里就包含智能体工作流」，模型的工具使用稳定性、长程一致性会持续拉开差距。选模型时，SWE-bench Verified、TAU-bench 这类「真干活」指标会比 MMLU 更值得看。

3. 自部署门槛断崖式下降：13B 激活 + FP8 量化，让「前沿级模型单卡可跑」从幻想变成采购清单上的一行。数据合规、成本可控、离线可用，这三件事对小团队和中大型企业的价值，远超那点 benchmark 差距。

6.2 给你的工程建议

• 选型：做智能体 / 代码任务，先上 DeepSeek V4 Flash（FP8 自部署或官方 API），成本和能力的平衡点目前最好；要做超长文档理解或极限推理，再上 Pro。
• 部署：中小流量用单卡 FP8 + KV Cache FP8；高并发务必上 EP + PD 分离。
• 护栏：自部署 Agent 必须加 max_steps、工具超时、输入校验——开源模型偶尔会「钻牛角尖」式重试，不设限就是烧钱黑洞。
• 长上下文：1M 是好东西，但默认用法是「检索 + 精准喂入」，不是「全库塞进去」。

6.3 最后一句

2026 年再看「开源追平闭源」这句话，已经不准确了。更准确的说法是：在「能不能替你把活干完」这件事上，开源模型第一次站到了同一起跑线，而且便宜一个数量级。 DeepSeek V4 Flash 不是这条路上的终点，但它是第一个让普通团队「自己就能跑起来一个能干活的智能体」的里程碑。

本文代码均基于 vLLM + OpenAI 兼容接口，自部署与官方 API 通用。具体镜像标签、量化版本请以 DeepSeek 官方仓库与 vLLM 发布说明为准。