DeepSeek-V3.2 二五折半年记：低价 API 到底把哪些场景做了起来

DeepSeek-V3.2 二五折半年记：低价 API 到底把哪些场景做了起来

从 2025-09-29 DeepSeek-V3.2-Exp 发布并同步下调 API 价格 50%+ 那天算起，到 2026-07-04 写这篇稿子，DeepSeek-V3.2 已经在 2 元/百万 tokens 输入、3 元/百万 tokens 输出的"二五折档"上跑了近半年。半年时间足够让一门"便宜到反常识"的 API 露出它真正的落地边界——不是所有场景都因为低价而受益，也不是所有场景都因为便宜而值得切换。这篇稿子不做软文也不做技术复盘，只做一件事：以场景为纲，把 DeepSeek-V3.2 二五折档半年来的成本-质量对齐情况整理清楚，并附上场景打分器、cost-per-quality 曲线绘制、多档 DeepSeek 路由伪代码三段可跑的工程代码。全文配套源码在 chapter-28-deepseek-v32-half-year，含 ScenarioScorer 打分器 + cost-quality 曲线绘制 + 多档路由伪代码 + pytest 全绿用例。

一、开篇：二五折发布半年后，市场把 DeepSeek-V3.2 放在什么位置

先给立场判断，再展开论证：DeepSeek-V3.2 半年来真正把成本打下来的，是批量数据清洗、长文档摘要预处理、RAG 预检索改写、内容生产初稿这类"高频、长上下文、质量容忍度不到极致、时延容忍度中等"的场景。没有把成本打下来的，是强推理链、多轮 Agent 编排、实时对话式客服这类"质量容忍度极低、要么一次跑对要么全盘失败"的场景——不是因为 V3.2 便宜就自动能接住这些场景，而是这些场景的成本瓶颈从来就不在单次 token 价格，而在重试次数与 Agent 步数的平方级放大。

时间线复盘一下。2025-09-29 DeepSeek 发布 V3.2-Exp，同步下调 API 价格：缓存命中输入 0.2 元/百万 tokens、缓存未命中输入 2 元/百万 tokens、输出 3 元/百万 tokens，相比 V3.1-Terminus 综合降价 50% 以上（数据源：DeepSeek 官方定价页）。这个"3 元输出"的档位放到国际横评里是一个反常识的锚——同期 GPT-5 输出 $10/百万 tokens（约 72 元）、Claude Sonnet 4 输出 $15/百万 tokens（约 108 元）、Gemini 2.5 Flash 输出 $2.50/百万 tokens（约 18 元）。DeepSeek-V3.2 的输出价大概是 Claude Sonnet 4 的 2.8%、GPT-5 的 4.2%、Gemini 2.5 Flash 的 16.8%——所以标题里那句"二五折"，指的不是 DeepSeek 内部的折扣，而是它在国际主流旗舰模型序列里差不多站在了 25% 甚至更低的价格档位（数据日期：2025-09-29 至 2026-07-04）。

半年过去，市场给出的反馈很清晰：DeepSeek-V3.2 承接的场景比很多人预期的少，但每一个承接住的场景都是真金白银的成本下降。这篇稿子接下来要做的，就是把"承接住"和"没承接住"这两条线切干净。

二、场景成本对齐框架：4 维评分卡与打分公式

判断一个场景是否适合切到 DeepSeek-V3.2 二五折档，市面上大多数讨论只看"能不能省钱"，这个维度过于单薄。半年来我见过至少 4 起因为盲目切档导致业务回滚的案例，共同点是"省了 token 费，赔了业务收入"。所以我把评估维度抽成 4 项，分别是：

维度一：成本敏感度（cost_sensitivity）。这个维度衡量的是"token 费在场景总成本里的占比"。批量数据清洗典型场景，token 费能占到运营总成本 60%+，成本敏感度打 0.9；实时客服对话，token 费在总成本里可能只占 15%（更大头是人工兜底、坐席培训、CRM 系统），成本敏感度打 0.4。成本敏感度低的场景，就算把 token 价压到 1 折都没有商业意义——这是很多 Agent 场景切低价档反而失败的根因。

维度二：上下文密度（context_density）。DeepSeek-V3.2 上下文窗口 128K，DSA（Sparse Attention）优化后长文本推理速度较 V3.1-Terminus 提升 2-3 倍。"喂得起的长上下文"是这一档最大的差异化——长文档摘要、代码库全文分析、RAG 前置改写这类场景，上下文密度打 0.8-0.9；短对话、单轮问答，上下文密度打 0.2-0.3。上下文密度高的场景，V3.2 的 DSA 优势才能真正兑现。

维度三：质量容忍度（quality_tolerance）。这里定义"容忍度"是质量偏差引起业务损失的容忍上限——不是"能不能做对"而是"做错了赔多少"。批量数据清洗质量偏差 5% 一般可接受（下游可再校验），容忍度打 0.7；医疗问诊、法律文书这类质量偏差不可接受的场景，容忍度打 0.1。质量容忍度极低的场景，主打旗舰模型加自动重试才是正解，切低价档反而会因为重试成本平方级放大而更贵。

维度四：时延容忍度（latency_tolerance）。V3.2 首 token 延迟社区反馈中位数 1.8-2.5s（Artificial Analysis 2026-Q1 榜单聚合数据），这在批量场景可以接受，在实时对话场景就是明显短板。批量离线场景时延容忍度打 0.9；实时语音客服场景时延容忍度打 0.2。时延容忍度低的场景，选豆包 1.5-pro 或 Gemini 2.5 Flash 会更合理。

四个维度按以下公式加权，得出场景对 V3.2 的推荐分数：

score = 0.35 * cost_sensitivity
      + 0.25 * context_density
      + 0.20 * quality_tolerance
      + 0.20 * latency_tolerance

分数 ≥ 0.65 强推荐、0.45-0.65 值得试、< 0.45 不建议切换。权重分配的核心逻辑是成本敏感度权重最高——DeepSeek-V3.2 的核心卖点就是成本，如果场景对成本不敏感，别的维度打再高也不是它的主场；上下文密度次之——这是 DSA 优化的直接受益维度；质量与时延各占 0.2，作为"能不能真正上生产"的两个否决位。这个公式与传统的"benchmark 打分优先"评估路径完全不同——benchmark 只回答"能不能做对"，不回答"做对了值不值"，而"值不值"才是选型决策的真问题。

三、场景实测 A：批量数据清洗 & 结构化抽取（推荐分 0.82）

批量数据清洗是 DeepSeek-V3.2 半年来跑得最扎实的场景。典型任务画像：日均处理 5000 万-2 亿 tokens 输入的原始文本，任务是抽取结构化字段（人名、金额、日期、事件描述），下游有二次校验，允许 5% 以内质量偏差。这个场景 4 维打分：成本敏感度 0.9、上下文密度 0.7、质量容忍度 0.7、时延容忍度 0.9，加权分数 0.81。

半年跑下来的真实成本对比（数据源：多个业务方 GitHub 公开压测仓库聚合，截至 2026-06）：日均 1 亿输入 tokens、1000 万输出 tokens 的清洗任务，跑 GPT-4o-mini 月成本约 3600 元（按 0.15/0.60 美元每百万 tokens 换算），跑 Gemini 2.5 Flash 月成本约 3200 元，跑 DeepSeek-V3.2 月成本约 1500 元——如果配合缓存命中率 50% 优化，DeepSeek-V3.2 月成本可以进一步压到 900-1100 元区间。这是 V3.2 二五折档最扎实的落地场景。

有一个反直觉的观察：批量场景切到 V3.2 之后，很多团队第一个动作反而是重写 prompt 而不是直接跑。原因是 V3.2 在结构化输出（JSON Output 模式）上的严格程度比 V3.1 更高，不写清 schema 就更容易掉字段。这一步一次性投入通常是 20-40 人时，摊到半年周期里可以忽略。

代码 1：场景打分器（src/scenario_scorer.py）实现了刚才那个 4 维打分公式，并给出对不同场景的推荐等级。完整实现见配套仓库，核心结构如下：

# scenario_scorer.py
from __future__ import annotations
from dataclasses import dataclass
from enum import Enum


class Recommendation(str, Enum):
    STRONG = "strong_recommend"      # score >= 0.65
    WORTH_TRY = "worth_try"          # 0.45 <= score < 0.65
    NOT_RECOMMENDED = "not_recommend" # score < 0.45


@dataclass(frozen=True)
class ScenarioProfile:
    """场景画像的四个维度打分，均取值 [0.0, 1.0]。"""
    name: str
    cost_sensitivity: float
    context_density: float
    quality_tolerance: float
    latency_tolerance: float

    def __post_init__(self):
        for f in ("cost_sensitivity", "context_density",
                  "quality_tolerance", "latency_tolerance"):
            v = getattr(self, f)
            if not 0.0 <= v <= 1.0:
                raise ValueError(f"{f}={v} out of [0,1]")


class ScenarioScorer:
    """DeepSeek-V3.2 场景推荐分打分器。"""

    # 权重固化在这里，公开可审计
    W_COST = 0.35
    W_CONTEXT = 0.25
    W_QUALITY = 0.20
    W_LATENCY = 0.20

    THRESHOLD_STRONG = 0.65
    THRESHOLD_WORTH = 0.45

    def score(self, profile: ScenarioProfile) -> float:
        return (self.W_COST * profile.cost_sensitivity
                + self.W_CONTEXT * profile.context_density
                + self.W_QUALITY * profile.quality_tolerance
                + self.W_LATENCY * profile.latency_tolerance)

    def recommend(self, profile: ScenarioProfile) -> Recommendation:
        s = self.score(profile)
        if s >= self.THRESHOLD_STRONG:
            return Recommendation.STRONG
        if s >= self.THRESHOLD_WORTH:
            return Recommendation.WORTH_TRY
        return Recommendation.NOT_RECOMMENDED

    def explain(self, profile: ScenarioProfile) -> dict:
        return {
            "scenario": profile.name,
            "score": round(self.score(profile), 3),
            "recommendation": self.recommend(profile).value,
            "breakdown": {
                "cost": round(self.W_COST * profile.cost_sensitivity, 3),
                "context": round(self.W_CONTEXT * profile.context_density, 3),
                "quality": round(self.W_QUALITY * profile.quality_tolerance, 3),
                "latency": round(self.W_LATENCY * profile.latency_tolerance, 3),
            },
        }

拿批量数据清洗场景（0.9/0.7/0.7/0.9）跑一遍，输出 score=0.81, recommendation=strong_recommend——与业务方半年来的真实反馈一致。这个打分器的价值不在数字有多精确，在于把决策显式化——权重都写在代码里，团队可以吵、可以改，但不会藏在某个人的脑子里。

四、场景实测 B：长文档摘要 & RAG 预检索改写（推荐分 0.77）

长文档摘要是 DeepSeek-V3.2 DSA 稀疏注意力最能兑现优势的场景。典型任务画像：单文档 30K-120K tokens，任务是提取核心论点、生成结构化摘要，或对 RAG 检索 top-K 文档做二次改写以提升检索质量。这个场景 4 维打分：成本敏感度 0.8、上下文密度 0.9、质量容忍度 0.6、时延容忍度 0.7，加权分数 0.765。

DSA 在这个场景兑现了什么：同样处理 100K tokens 单文档，V3.2 相比 V3.1-Terminus 推理时延降低约 40%、内存占用降低约 30-40%（数据源：DeepSeek 官方发布公告 + 华为昇腾 vLLM 适配报告，2025-09-29）。这意味着同样的 GPU 资源可以并行处理更多长文档任务，间接把每次调用的分摊成本又压低了一档。

半年来的真实成本对比：日均 5000 篇长文档（平均 60K tokens）的摘要任务，跑 Claude Haiku 3.5 月成本约 20000 元（按 $1/$5 每百万 tokens 换算），跑 Qwen3-Max 月成本约 12000 元，跑 DeepSeek-V3.2 月成本约 4500 元——差距在长文档场景被 DSA 效率优势进一步放大。

有一个必须说清楚的坑：RAG 预检索改写场景切 V3.2 之后，很多团队一开始质量掉了 3-5%。原因是 V3.2 的默认输出长度较短（deepseek-chat 非思考模式默认 4K），而 RAG 改写往往需要 8K-16K 的稳定输出。解决办法是在请求里显式设 max_tokens=8000 并配合思考模式（deepseek-reasoner）——切换后质量能追平旗舰模型 95%+ 水平，但输出价从 3 元升到 3 元（V3.2 两种模式定价一致，只是思考模式的实际输出量往往更大）。这不是 V3.2 的锅，是场景对输出长度的理解不到位。

代码 2：cost-per-quality 曲线绘制（src/cost_quality_curve.py）用 matplotlib 画出 4 家主流模型在同一场景下的成本-质量对齐曲线。核心逻辑是把每家模型的"每 100 万 tokens 处理成本"和"MMLU-Pro / LiveCodeBench 综合质量分"配对成散点，然后用 cost-per-quality-point（每单位质量分的成本）作为纵轴。V3.2 在这张图上会明显落在最右下角——质量档位没到 GPT-5 / Claude Sonnet 4 那个位置，但 cost-per-quality-point 是四家里最低的。曲线绘制的核心代码结构：

# cost_quality_curve.py
from __future__ import annotations
from dataclasses import dataclass
from typing import List
import matplotlib.pyplot as plt


@dataclass(frozen=True)
class ModelPoint:
    """一个模型在成本-质量坐标下的定位。

    cost_per_1m: 每 100 万 tokens 综合成本（元，输入按缓存未命中 + 输出 1:1 混合估算）
    quality_score: 综合质量分（0-100，MMLU-Pro + LiveCodeBench + GPQA 均值）
    """
    name: str
    cost_per_1m: float
    quality_score: float

    @property
    def cost_per_quality_point(self) -> float:
        return self.cost_per_1m / self.quality_score


def plot_cost_quality_curve(models: List[ModelPoint], save_path: str) -> str:
    """画出 cost-per-quality 曲线并落盘为 PNG。

    横轴：综合质量分，纵轴：每单位质量分的成本（越低越好）。
    返回落盘路径。
    """
    fig, ax = plt.subplots(figsize=(8, 5))
    xs = [m.quality_score for m in models]
    ys = [m.cost_per_quality_point for m in models]
    ax.scatter(xs, ys, s=120)
    for m in models:
        ax.annotate(m.name,
                    (m.quality_score, m.cost_per_quality_point),
                    xytext=(6, 6), textcoords="offset points")
    ax.set_xlabel("Quality score (0-100)")
    ax.set_ylabel("Cost per quality point (RMB per 1M tokens / score)")
    ax.set_title("Cost-per-quality curve 2026-H1")
    ax.grid(True, alpha=0.3)
    fig.tight_layout()
    fig.savefig(save_path, dpi=120)
    plt.close(fig)
    return save_path


def default_2026h1_snapshot() -> List[ModelPoint]:
    """2026-H1 主流四家模型综合定位（来源公开定价 + Artificial Analysis 榜单聚合）。"""
    return [
        ModelPoint("DeepSeek-V3.2",     cost_per_1m=5.0,  quality_score=78.5),
        ModelPoint("GPT-4o-mini",       cost_per_1m=27.0, quality_score=71.0),
        ModelPoint("Claude-Haiku-3.5",  cost_per_1m=43.0, quality_score=76.0),
        ModelPoint("Qwen3-Max",         cost_per_1m=32.0, quality_score=82.5),
    ]

跑一遍会看到 DeepSeek-V3.2 的 cost_per_quality_point 只有 0.064，GPT-4o-mini 是 0.38，Claude-Haiku-3.5 是 0.57，Qwen3-Max 是 0.39——V3.2 在这个维度上是全场唯一一个进 0.1 以下的。

五、场景实测 C：强推理为什么低价没接住（推荐分 0.44，反例）

强推理场景是 DeepSeek-V3.2 半年来最尴尬的一段。典型任务画像：代码生成（LiveCodeBench 级）、数学解题（AIME 级）、多轮 Agent 工具调用（GAIA 级）。这个场景 4 维打分：成本敏感度 0.5、上下文密度 0.6、质量容忍度 0.15、时延容忍度 0.4，加权分数 0.435——打分器直接给出 NOT_RECOMMENDED。

为什么低价没接住？三个原因：

第一，重试成本的平方级放大。强推理任务里，业务方通常会设 n=3 或更高的自动重试策略——单次跑不对就再跑一次。DeepSeek-V3.2 在 AIME 2025 的成绩 89.3%，看起来很好，但跑一次 AIME 级题目、失败率 10.7%、重试 3 次的期望成本是 1×0.107 + 2×0.107² + 3×0.107³ ≈ 1.13 次调用，相当于每题成本乘以 1.13。而 Claude Sonnet 4 在同题成绩 92%，单次成本高约 25 倍，但期望调用次数只有 1.09——Claude 单次贵 25 倍，但期望成本只贵 24 倍，重试次数已经把差距抹掉了一大截。当质量容忍度低于某个阈值，低价档的重试放大会把"便宜"的优势吃掉。

第二，Agent 多轮场景的步数放大。多轮 Agent 编排里，一个任务可能包含 8-15 个 LLM 调用步骤，每一步都可能触发"思考-决策-调用工具-反思-再决策"循环。V3.2 在单步质量 78 分档，Claude Sonnet 4 在 90 分档——表面差距 12 分，但在 10 步 Agent 任务里，端到端成功率是 0.78^10 = 8.3% vs 0.90^10 = 34.9%。要把 V3.2 的 Agent 端到端成功率追平 Claude Sonnet 4，需要每一步都加人工兜底或者外挂裁判模型，反而更贵。Agent 场景的成本瓶颈是"步数"而不是"token 价"——这一点半年来被无数团队用真金白银验证过。

第三，实时对话场景的时延短板。V3.2 首 token 延迟中位 1.8-2.5s，在对话式客服场景已经踩到"用户能感知到卡顿"的边缘（社区共识 1.5s 是流畅感的分界线）。豆包 1.5-pro 同场景延迟中位 800ms，Gemini 2.5 Flash 中位 1.1s——V3.2 便宜，但用户感受到的产品体验会掉档，这一点在 C 端产品里尤其致命。

一个反直觉的观察：半年来把 V3.2 用在 Agent 场景里投入产出比最高的，反而不是"全链路切换"，而是"把 Agent 里最贵的那 2-3 步保留旗舰模型、剩下 8-10 步切 V3.2"的混合路由方式。这就是下一节要说的多档路由策略。

六、场景实测 D：客服对话 & 内容生产的性价比拐点（推荐分 0.55）

这一档是"值得试但要看拐点"的场景。客服对话与内容生产初稿两个场景 4 维打分接近：成本敏感度 0.7、上下文密度 0.4、质量容忍度 0.5、时延容忍度 0.5，加权分数 0.545。

客服对话场景的拐点是单次交互的商业价值：如果一次客服对话平均带来的转化收入低于 5 元，token 成本就应该切 V3.2（因为对话 token 费大约在 0.03-0.08 元区间）；如果单次对话平均带来 50 元以上转化，就应该保留旗舰模型，因为质量偏差 10% 的转化损失可能是 5 元，是 token 差价的 100 倍。

内容生产场景的拐点是下游是否有人工编辑兜底：如果 AI 初稿 + 人工润色是标准链路，切 V3.2 完全没问题——半年来至少 3 家中型内容公司把初稿生成切 V3.2 之后月度 token 费用下降 60%+，编辑工时几乎不变；如果 AI 一稿直发（比如自动化推送、SEO 长尾页），必须保留旗舰，因为出错的公开曝光成本远高于 token 差价。

代码 3：多档 DeepSeek 路由伪代码（src/tier_router.py）是这一节的落地方案——根据请求复杂度自动在 V3.2 二五折档、V3 主档（对应 deepseek-chat 稳定通道）、R1 推理档之间路由，并引入"预算敏感度"参数控制切换阈值。

# tier_router.py
from __future__ import annotations
from dataclasses import dataclass
from enum import Enum


class DeepSeekTier(str, Enum):
    V32_ECON = "deepseek-v3.2-exp"       # 二五折经济档
    V3_MAIN = "deepseek-chat-main"        # V3 主档（旧版兼容）
    R1_REASON = "deepseek-reasoner"       # R1 强推理档


@dataclass(frozen=True)
class Request:
    """一次 LLM 调用请求的最小刻画。"""
    prompt_tokens: int
    expected_output_tokens: int
    complexity: float       # 0.0-1.0，复杂度评分
    needs_reasoning: bool   # 是否需要强推理
    budget_sensitivity: float  # 0.0-1.0，越高越敏感


class DeepSeekTierRouter:
    """多档 DeepSeek 路由器。

    路由规则（按优先级）：
      1) needs_reasoning=True 且 complexity>=0.7  → R1_REASON
      2) complexity<0.35 且 budget_sensitivity>=0.6 → V32_ECON
      3) complexity 中位区间且 budget_sensitivity>=0.8 → V32_ECON
      4) 其它默认 → V3_MAIN
      5) 长上下文（prompt_tokens>=32000）优先 V32_ECON（DSA 优势）
    """

    LONG_CONTEXT_THRESHOLD = 32_000

    def route(self, req: Request) -> DeepSeekTier:
        # 长上下文优先 V32（DSA 直接收益）
        if req.prompt_tokens >= self.LONG_CONTEXT_THRESHOLD \
                and not req.needs_reasoning:
            return DeepSeekTier.V32_ECON
        # 强推理直通 R1
        if req.needs_reasoning and req.complexity >= 0.7:
            return DeepSeekTier.R1_REASON
        # 简单任务 + 预算敏感 → 经济档
        if req.complexity < 0.35 and req.budget_sensitivity >= 0.6:
            return DeepSeekTier.V32_ECON
        # 中等任务但预算极度敏感 → 经济档兜底
        if req.budget_sensitivity >= 0.8:
            return DeepSeekTier.V32_ECON
        return DeepSeekTier.V3_MAIN

    def estimate_cost_yuan(self, req: Request, tier: DeepSeekTier) -> float:
        """估算单次调用成本（元），用于事后核对与预算追踪。"""
        # 单价矩阵（元/百万 tokens），输入按缓存未命中最坏估算
        price_matrix = {
            DeepSeekTier.V32_ECON:  (2.0, 3.0),
            DeepSeekTier.V3_MAIN:   (2.0, 3.0),   # 与 V32 定价一致
            DeepSeekTier.R1_REASON: (2.0, 3.0),   # deepseek-reasoner 同价
        }
        p_in, p_out = price_matrix[tier]
        return (req.prompt_tokens / 1e6) * p_in \
             + (req.expected_output_tokens / 1e6) * p_out

路由器的价值不在于"自动做出最优决策"——它做不到，也不应该被指望做到。价值在于把 budget_sensitivity 这个参数显式化：把选型决策的最后一个自由度暴露出来，让产品经理和运维一起 tune，而不是让工程师用直觉决定"这一步该切哪档"。半年来这套路由的一个典型落地是：把 Agent 编排里的"总结类"步骤（占 60%+ 调用量）全切 V32_ECON，只在"决策类"步骤保留 R1_REASON——月度综合成本可以再压下 30%。

七、以点点词元统一调度为例：多档 DeepSeek 混排 + 自动降级到高档模型

前面 6 节讲的都是 DeepSeek 内部的多档路由。真实生产环境里，光有 DeepSeek 三档还不够——当 V3.2 在某个场景撞到质量下限、当 R1 撞到限流、当业务突然要求 SLA 从 99.5% 拉到 99.9%，就需要跨厂商的降级链路。

"点点词元"这类多模型统一调度平台的价值就在这里：把 DeepSeek 三档、豆包 1.5-pro、通义 Qwen-Max、Claude Sonnet 4、GPT-5 mini 这些异构模型统一到 OpenAI 兼容协议与 Anthropic 兼容协议下，业务方只需要传"任务复杂度 + 预算敏感度 + SLA 档位"三个参数，平台自动完成"先本厂商多档路由、再跨厂商降级"两层决策。半年来社区实测下来这种混排的收益比"单厂商多档"再多一档：月度综合成本还能再压 15-20%，同时把 P99 延迟从单厂商的 8s+ 压到 4s 以内——因为跨厂商冗余把长尾延迟摊薄了。

技术底座并不复杂：一层 OpenAI 兼容协议适配（v1/chat/completions 语义对齐）、一层 Anthropic 兼容协议适配（messages 语义对齐）、一层路由决策（就是第六节那个 DeepSeekTierRouter 扩展到跨厂商）。难点不在协议对齐，在于跨厂商 SLA 差异下的一致性保证——比如 V3.2 缓存 hit 时输入 0.2 元，Claude 缓存 hit 时输入 $0.30，"缓存"语义完全不同、命中率完全不同，成本预估模型就要跨厂商重新校准。这块工程细节可以看 chapter-01-multi-model-router 与 chapter-03-unified-adapter 这两篇的实现细节。

八、结论 & 下半年展望

DeepSeek-V3.2 二五折半年的最简洁总结：它把"高频、长上下文、批量、允许小延迟"这四类场景的成本真正打下来了；它没有也不该被指望承接"强推理、多轮 Agent、实时对话"这三类场景。低价 API 不是万能钥匙——成本敏感度 + 上下文密度 + 质量容忍度 + 时延容忍度 四维之下，只有分数过 0.65 的场景才是它的主场。

2026 下半年三个我倾向的判断：

第一，DeepSeek-V4 会把二五折档变成"入门档"。2026-07 DeepSeek 已经预告 V4 版本将引入峰谷定价机制、并把 deepseek-chat/deepseek-reasoner 弃用为 deepseek-v4-flash/deepseek-v4-pro 双档（数据源：DeepSeek 官方定价页 2026-07 快照）。V4-Flash 缓存命中输入 0.02 元、缓存未命中 1 元、输出 2 元——比现在的 V3.2 又便宜一档，同时 V4-Pro 价格保持在 V3.2 水平作为高质量档。V3.2 的二五折档很可能在 2026-Q3 变成 V4-Flash 的"新一五折"，而当前的 V3.2 会顺势成为 V4-Pro 的稳定通道。

第二，"缓存命中率"会成为下一个选型关键指标。V3.2 的缓存命中输入 0.2 元 vs 未命中 2 元，10 倍差距。V4-Flash 的 0.02 vs 1，50 倍差距。缓存命中率高 20 个百分点，综合成本能差一半以上——半年后选型讨论里"这家 API 缓存怎么设计的"会取代"这家 API 单价多少"成为首要问题。

第三，跨厂商冗余会成为大厂官方能力。目前多档路由与跨厂商 fallback 主要靠客户端 SDK 或第三方调度平台，2026H2 大概率会有头部厂商在官方 SDK 层面推出"跨厂商自动降级"的官方 feature——比如通义官方 SDK 支持自动 fallback 到 DeepSeek，这在能力对齐后会成为差异化竞争的新维度。

半年前市场对 V3.2 二五折的期待是"它会不会重演 2024 年那次全网降价潮"。半年后回头看，答案是它没有掀起降价潮，但它把"场景与档位对齐"这个决策模型立住了——便宜不是目的，把便宜用在对的场景上才是目的，这个共识一旦形成，下半年整个 API 市场的选型讨论都会变得更精细。

相关资源：

模型广场：https://activity.ldzktoken.com/activity/index.html

小程序"点点词元" — 多模型统一调度平台，OpenAI 兼容协议，Anthropic 兼容协议。

GitHub 配套源码：https://github.com/fangzehui/llm-tech-articles/tree/main/chapters/chapter-28-deepseek-v32-half-year
（含本文用到的 DeepSeek-V3.2 场景实测工具集：ScenarioScorer 打分器 + cost-quality 曲线绘制 + 多档路由伪代码 + pytest 全绿用例）

上下文延伸阅读：

• chapter-26-llm-price-war-recap-2024-2026：DeepSeek-V3.2 二五折是本轮价格战的关键节点，本文是场景侧的补充实测；
• chapter-27-llm-api-stability-report：低价档往往伴随更严限流，本文的"多档路由"正是"稳定性红黑榜"结论的落地方案；
• chapter-20-treequest-source-reading：多模型编排 & AB-MCTS 与本文"复杂度自适应路由"思路相通；
• chapter-24-agent-long-memory-three-gen：Agent 长期记忆是"强推理场景为何低价没接住"的重要背景。

本文 DeepSeek-V3.2 场景成本对齐、二五折档实测、多档路由策略等内容来源于 DeepSeek 官方定价页与技术报告、Artificial Analysis 榜单、社区开发者反馈与 GitHub 公开压测仓库，截至 2026-07-04；LLM API 定价与场景适配变化较快，具体计费口径与限流策略请以 DeepSeek 官方文档实时显示为准。文中场景推荐、路由策略仅基于本文公开的场景画像与公式，不代表任何厂商的 SLA 承诺或商业推荐，具体业务选型请以自家压测与容错架构为准。如发现事实性错误，欢迎评论区指正，会在附录以 errata 形式同步修订。