> **TL;DR 速览**
> 
> -   **计费结构**：高峰 = **周一至周五 9:00–12:00、14:00–18:00**（**不含法定节假日**），其余时段全按闲时；**闲时是高峰的 50%**
> -   **一条罕见的细节**：**调休上班的周末仍按周末识别**——计费认的是行政日历，不是你实际有没有上班
> -   **单价表（元/百万 tokens，闲时）**：flash 缓存命中输入 **0.02** / 未命中 **1** / 输出 **4**；V4-Pro 命中 **0.15** / 未命中 **4.5** / 输出 **13.5**；**高峰全部翻倍**
> -   **最大的价差不在峰谷**：峰谷差 **2 倍**，而 flash 的缓存命中与未命中差 **50 倍**
> -   **V4.1-Flash 的结构**：**552B 非对称 MoE**，输入激活 **8B**、输出激活 **16B**，**1M 上下文**，**KV cache 占用降 75%**

![04_deepseek_pricing_calendar.jpg](https://developer.qcloudimg.com/http-save/yehe-12721511/8b0a07949c0b44f4c43678f7597f67b5.jpg)

DeepSeek 更新了 API 定价规则，做了一件别家没做的事：**把中国的行政日历写进了计费逻辑。** 高峰时段被定义为工作日上下午各一段，法定节假日排除在外，闲时按高峰的五折计费。更值得注意的是补充说明里的一句——**调休上班的周末仍然按周末识别**。

这篇文章不讨论价格贵还是便宜，只算一件事：**在这样一张价目表下，一个工程团队最该动的是哪个旋钮。** 结论可能和直觉相反——不是把任务挪到夜里，而是改 prompt 的结构。

## 一、高峰时段怎么定义，以及"调休"这一条为什么重要

先把规则抄清楚：

| 时段 | 定义 | 计费 |
| --- | --- | --- |
| **高峰** | 周一至周五 **9:00–12:00**、**14:00–18:00** | 标准价 |
| **闲时** | 高峰以外的全部时间（含夜间、周末、**法定节假日全天**） | 标准价的 **50%** |

当天有效工作时段合计 7 小时，也就是**一周 35 小时**。按一周 168 小时算，**闲时占约 79%**。所以"能不能把任务排到闲时"这件事，覆盖的时间窗口其实相当宽。

**真正特殊的是"调休"那一条。**

中国的调休制度会让某些周六、周日变成实际的工作日。如果计费系统按"实际上班日"来判断，那这些调休的周末就会被算成工作日高峰。**DeepSeek 明确说不这么做——调休上班的周末仍按周末识别。**

这条对定时任务有直接含义：**一个跑在周六的批处理，即使那天是调休工作日，账单仍然按周末的闲时算。** 把离线批处理固定排在周末，是一个不受调休干扰的选择；而排在"周一至周五的上班时间"则一定会撞高峰。

**反过来，节假日全天闲时这一条也很实用。** 长假期间跑历史数据回补、离线评估、批量重跑这类任务，成本直接减半。

## 二、真正的价差在缓存命中，不在峰谷

这是这篇最核心的一段。

把闲时单价排在一起看：

| 项目 | flash（元/百万） | V4-Pro（元/百万） |
| --- | --- | --- |
| 输入 · 缓存命中 | **0.02** | **0.15** |
| 输入 · 缓存未命中 | **1** | **4.5** |
| 输出 | **4** | **13.5** |

两个比值值得单独算出来：

**flash 的命中 / 未命中 = 1 ÷ 0.02 = 50 倍。** **V4-Pro 的命中 / 未命中 = 4.5 ÷ 0.15 = 30 倍。** **峰谷比 = 2 倍。**

也就是说，**在 flash 上，输入命中与否的单价差距，是峰谷时段的 25 倍。** 把任务从高峰挪到闲时，省一半；把输入的缓存命中率提上去，输入的账可以直接差一个数量级。

**更关键的是两者的性质不同：**

**峰谷是调度问题** —— 动的是"什么时候跑"。批处理、离线任务、评估任务可以挪；但线上接口不能挪，用户白天提问你不能让他等到晚上。

**缓存命中是工程问题** —— 动的是"prompt 长什么样"。它对线上接口同样有效，而且是 **100% 可叠加**：闲时 + 高命中率 = 最低成本，两者不冲突。

**所以优化顺序应该是先缓存、后峰谷。** 缓存那一边对延迟敏感的业务也管用，峰谷那一边只对能延迟的任务管用。

## 三、为什么缓存能差这么多：几个典型调用场景的账

用一组虚拟场景把这笔账落到具体数字上。**下面全部是按官方定价表推算，不是实测。**

**场景 A：固定长前缀被反复使用。** 假设一个应用有一段 20000 token 的固定前缀（工具说明、规范、few-shot 示例），被反复调用。

|  | 计算 | 每次成本 |
| --- | --- | --- |
| 全部未命中 | 20000 × 1 ÷ 1e6 | **0.02 元** |
| 全部命中 | 20000 × 0.02 ÷ 1e6 | **0.0004 元** |

**单次差 0.0196 元。** 按每天 10 万次调用算，**一天差约 1960 元**——而且这是在闲时口径下，高峰还要翻倍。

**场景 B：长文档问答。** 输入 30000 token（其中 29000 是文档），输出 500 token。

|  | 输入 | 输出 | 合计 |
| --- | --- | --- | --- |
| 命中（29000 命中 + 1000 未命中） | 0.00058 + 0.001 | 0.002 | **约 0.0036 元** |
| 未命中（全部 30000） | 0.03 | 0.002 | **约 0.032 元** |

**差约 9 倍。** 注意这里输出占了命中场景成本的 55%——**当输入被缓存压到很低之后，输出反而成了主要成本项。**

**场景 C：短输入高输出。** 输入 500 token，输出 2000 token：输入 0.0005 元，输出 0.008 元。**输出占 94%，缓存在这里几乎没意义。**

三个场景合起来给出的判断很清楚：**缓存优化的收益，与你 prompt 里"固定部分的占比"成正比。** 前缀越固定、越重复、越靠前，收益越大。短输入高输出的场景，该优化的是输出长度（限长、少啰嗦），不是缓存。

## 四、缓存命中率怎么提：动手的四个方向

缓存命中的前提是**前缀完全一致**。所以提升命中率的动作，本质上都是"减少前缀的无谓变化"。

**第一，把不变的东西全部前置。** 缓存按前缀匹配，**一个 token 变了，它之后的所有内容都失效**。所以顺序应该是：系统指令 → 工具定义 → 固定示例 → 可变的知识片段 → 用户问题。**把"当前时间""用户 ID""随机 trace id"这类每次都变的东西塞在系统提示词里，会让整段前缀每次全部失效。** 这是最常见也最贵的一个错误。

**第二，把可变信息挪到后面。** 时间戳、会话 id、请求 id 这类东西，如果业务上真的需要，放到用户消息那一段，别放进系统提示词。

**第三，把知识片段做成"拼接"而不是"重写"。** 检索到的文档如果能按固定顺序拼接、且顺序稳定，命中的概率会明显好于每次用不同顺序拼。

**第四，监控命中率本身。** 只优化不监控，改完不知道有没有效果。命中率应该是这个指标的名字，而不是账单金额——账单里还混着峰谷和输出长度的影响。

## 五、为什么缓存会变便宜：非对称 MoE 与 KV cache

价格表背后是模型结构的变化，这一层值得知道。

V4.1-Flash 是一个 **552B 参数的"非对称" MoE**：

-   **输入激活 8B、输出激活 16B** —— 注意两侧不一样，输出侧激活参数是输入侧的两倍
-   **1M 上下文**
-   **KV cache 占用降低 75%**

**"非对称"这个设计有意思的地方在于它承认了两件事的不对称。** 读 prompt 和写回复对模型的要求不一样：读的时候要广（覆盖信息），写的时候要深（保证连贯和格式）。把输出侧给更多激活参数，是用更少的额外成本去买生成质量。

**KV cache 降 75% 则直接解释了缓存命中为什么能这么便宜。** 上下文越长，KV cache 越大，服务端的显存占用就是成本的硬约束。把 KV cache 压下来，长上下文请求才能在服务端放得下更多并发——**这是"便宜"能成立的前提，而不只是一个定价策略。**

这也是为什么这套优化对**长前缀**特别有利：前缀越长，省下的 KV cache 越多，服务端越愿意给一个好价钱。

## 六、同赛道的另一种做法：包时段 vs 包额度

同赛道的另一种思路是把优惠绑在**时段**上，比如某家 Flash 模型在**夜间 23:00 至次日 9:00** 在自家工具内把额度清零。

两种做法的差别不只是折扣力度：

|  | 计费日历（时段价） | 包时段（额度清零） |
| --- | --- | --- |
| 优惠形式 | 单价打折（50%） | 特定时段额度不计费 |
| 生效范围 | 全部 API 调用 | 指定工具/入口内 |
| 迁移成本 | 无（改调用时间即可） | 需要把工作流搬进指定工具 |
| 适合 | 已有自建流水线，任务可调度 | 原本就在该工具里干活 |

**判断依据是"你愿不愿意为了折扣搬家"。** 如果流水线是自建的、任务本来就可以调度，那按需计费打五折更省事；如果本来就在某个工具里工作，额度清零的收益更直接。

**这两条路对同一个团队的启示是一样的：算力单价的竞争已经从"多少钱一度"延伸到"什么时候算、怎么算更省"。** 对使用方来说，**"把任务排程和 prompt 结构一起优化"这件事的回报，正在变得比"换一家更便宜的供应商"更高。**

## 七、上手清单

按收益从高到低，六步：

1.  **审计系统提示词里有没有易变字段。** 时间、用户标识、请求 id、随机种子——有就挪到用户消息里。这是投入产出比最高的一步。
2.  **重排前缀顺序。** 固定内容全部前置，索引顺序固定。改完等一两天看命中率变化。
3.  **统计你的输入 / 输出 token 比。** 输入占绝对多数 → 优化缓存；输出占绝对多数 → 先限输出长度，缓存帮不上你。
4.  **把可延迟的任务固定排到闲时。** 离线评估、数据回补、批量重跑。**优先排周末**——因为调休不影响它，稳定性最好。
5.  **节假日做重活。** 长假全天闲时，适合跑那些平时不敢跑的全量任务。
6.  **把命中率写进监控。** 跟成本曲线放一起看。只看总账单的话，命中率提升带来的下降，会被任务量增长掩盖掉。

## 八、一句话结论

**这张价格表真正在说的，是"可复用的输入理应比不可复用的输入便宜得多"。** 峰谷折扣是在补偿服务端的负载波动，而缓存命中折扣是在奖励那个真正省了算力的做法——**同一段前缀，不必算第二遍。**

对读者的动作建议：**今天就去看一眼你的系统提示词里有没有时间戳和请求 id。** 有的话，挪走它，这是唯一一个改一行代码就可能省下近半个输入成本的动作。

计费结构：高峰 = 周一至周五 9:00–12:00、14:00–18:00（不含法定节假日），其余时段全按闲时；闲时是高峰的 50%

DeepSeek 把日历写进了价格表：API 账单里最该优化的是缓存命中

人工智能

云计算

后端

DeepSeek计费核心在缓存命中：flash命中价0.02元/百万tokens，未命中1元，差50倍；峰谷仅2倍。调休周末按闲时计费，离线任务优先排周末。优化顺序：先调prompt前缀固定化，后挪闲时。短输出场景优先限长。

DeepSeek

快速部署LLM、AI绘画等应用,助你玩转AIGC！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

DeepSeek 把日历写进了价格表：API 账单里最该优化的是缓存命中-腾讯云开发者社区-腾讯云

DeepSeek 把日历写进了价格表：API 账单里最该优化的是缓存命中

DeepSeek 把日历写进了价格表：API 账单里最该优化的是缓存命中

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐