arm64下OpenOffice Docker镜像包制作：三条路线与Dockerfile实战
2026/10/13 1:21:35
📋 目录
- 📊 一、被漏掉的那个数字
- ⚙️ 二、为什么这件事只在Agent 场景里疼
- 🔍 三、更重要的一件事：V4-Pro 已经下线了
- 🎯 四、这件事在企业侧意味着什么
- ✅ 七、可以带走的判断清单
📊 一、被漏掉的那个数字
先把价格表摆全。这是 2026 年 8 月 16 日 16:00 UTC（北京时间 8 月 17 日 0 点）起生效的 V4-Pro 定价。
| 项目 | 预览期原价（美元/百万token） | 闲时（美元） | 高峰（美元） |
|---|---|---|---|
| 输入（缓存未命中） | 0.435 | 0.66 | 1.32 |
| 输入（缓存命中） | 0.003625 | 0.022 | 0.044 |
| 输出 | 0.87 | 1.98 | 3.96 |
人民币口径（据国内报道）：
| 模型 | 时段 | 输入未命中（¥/M） | 缓存命中（¥/M） | 输出（¥/M） |
|---|---|---|---|---|
| V4-Pro | 闲时 | 4.5 | 0.15 | 13.5 |
| V4-Pro | 高峰 | 9.0 | 0.30 | 27.0 |
| V4-Flash | 闲时 | 1.5 | 0.05 | 4.5 |
| V4-Flash | 高峰 | 3.0 | 0.10 | 9.0 |
高峰时段为北京时间 9:00–12:00 与 14:00–18:00，其余为闲时。
大部分报道盯住的是这两条：输出价从 ¥6 涨到闲时 ¥13.5（+125%），输入未命中从 ¥3 涨到 ¥4.5（+50%）。
但真正被砍掉的是缓存折扣。
原定价下，缓存命中价是输入价的 0.003625 / 0.435 =约 1/120。
新定价下，闲时是 0.022 / 0.66 =约 1/30。
从 1/120 到 1/30，缓存折扣被缩小了四倍，缓存命中价上涨约 500%。
DataNorth 的分析明确点了这一条：缓存命中价从 0.003625 美元涨到闲时 0.022、高峰 0.044，缓存折扣从大约百分之一缩到三十分之一。他们的结论是：“对于反复读取相同文件的 Agent 来说，这是这次改动中最贵的部分。”
⚙️ 二、为什么这件事只在Agent 场景里疼
先说清楚一个反直觉的点：峰谷定价的方向和直觉相反。
大多数云服务的"闲时折扣"是鼓励你错峰，用低价时段换资源闲置。DeepSeek 这套是闲时价 = 高峰价的一半，高峰时段（北京时间上午9-12、下午 2-6）反而更贵。
这个设计针对的是中国的工作日作息——高峰时段对应北京的工作时间，欧洲下午落在低费率区间。
但这还不是最关键的。关键在缓存。
2.1 缓存命中在Agent 里是什么角色
一个 Agent 干活的过程大致是：读一批文件 → 理解 → 调工具 → 读一批文件 → 理解 → 调工具……
同一个任务里，同一批文件会被反复读取多次。第一次是缓存未命中，后面全是缓存命中。
这意味着在 Agent 场景下，输入 token 里可能有很大比例走的是缓存命中通道。而缓存命中价涨了 500%，等于每一次重复读取的成本涨了5倍。
2.2 一个具体的测算
假设一个典型的代码 Agent 任务（本文用于说明口径的示例模型，非特定实测）：
- 单次任务输入 50,000 token（系统提示 + 项目上下文）
- 其中 40,000 token 走缓存命中（重复读取的项目文件），10,000 走未命中
- 输出 5,000 token
单次成本按闲时价计算：
| 项目 | 计算 | 成本（美元） |
|---|---|---|
| 输入未命中 | 10,000 / 1M × 0.66 | 0.0066 |
| 输入缓存命中 | 40,000 / 1M × 0.022 | 0.00088 |
| 输出 | 5,000 / 1M × 1.98 | 0.0099 |
| 合计 | 0.0174 |
如果按预览期原价（$0.435 / $0.003625 / $0.87）：
| 项目 | 计算 | 成本（美元） |
|---|---|---|
| 输入未命中 | 10,000 / 1M × 0.435 | 0.00435 |
| 输入缓存命中 | 40,000 / 1M × 0.003625 | 0.000145 |
| 输出 | 5,000 / 1M × 0.87 | 0.00435 |
| 合计 | 0.00885 |
涨幅约 96%。
现在做个关键对照：如果缓存命中的占比更高呢？
| 缓存命中占比 | 按预览期原价 | 按闲时新价 | 涨幅 |
|---|---|---|---|
| 0%（纯未命中） | 0.00870 | 0.01650 | 90% |
| 50% | 0.00878 | 0.01694 | 93% |
| 80% | 0.00885 | 0.01738 | 96% |
| 95% | 0.00887 | 0.01747 | 97% |
结论有点反直觉：缓存命中占比越高，总涨幅越大。
原因是缓存命中价虽然绝对值极低，但它的涨幅倍数最大（500%），权重越大、放大效应越强。
这和"缓存很重要所以要优化它"的直觉一致——只是这次优化的经济动机比以往更强了。
2.3 如果跑在高峰时段
同样的任务按高峰价：
| 项目 | 计算 | 成本（美元） |
|---|---|---|
| 输入未命中 | 10,000 / 1M × 1.32 | 0.0132 |
| 输入缓存命中 | 40,000 / 1M × 0.044 | 0.00176 |
| 输出 | 5,000 / 1M × 3.96 | 0.0198 |
| 合计 | 0.0348 |
高峰价是闲时价的两倍，也比预览期原价的 0.00885 高出近 3 倍。
对需要在北京工作时间跑 Agent 的团队，这是实打实的两倍成本差。
🔍 三、更重要的一件事：V4-Pro 已经下线了
这一条几乎所有中文报道都没提。
据 ai-tldr 的模型页和 DeepSeek 官方公告：DeepSeek 于 2026 年 9 月 10 日宣布逐步下线 V4-Pro，从 2026 年 9 月 14 日 04:00 UTC 起，所有deepseek-v4-pro请求按 V4.1-Flash 的费率路由到 DeepSeek-V4.1-Flash。
这意味着：如果你今天还在用deepseek-v4-pro这个模型名，你实际调用的是 V4.1-Flash，按 Flash 的价格计费。
MIT 许可的开源权重仍然留在Hugging Face 上，可以自己部署。
这个变化的时间点值得算一下：
| 日期 | 事件 |
|---|---|
| 2026-04-24 | V4 系列预览版发布，开源权重 |
| 2026-07-24 | 旧模型名deepseek-chat/deepseek-reasoner停用 |
| 2026-07-31 | V4-Flash 转正 |
| 2026-08-13 | V4-Pro-0813 正式版上线（GA） |
| 2026-08-16 | 峰谷定价生效 |
| 2026-09-10 | 宣布逐步下线 V4-Pro |
| 2026-09-14 | deepseek-v4-pro请求切至 V4.1-Flash |
| 2026-09-18 | 第三方核价页更新 |
GA 上了不到一个月就下线了。
这个序列读起来更像是产品线重整，而不是某个模型"失败"。但对已经在用 V4-Pro 做成本测算的团队来说，测算基数在9月14日那天悄悄换了。
3.1 V4-Pro 本身的规格
顺带把规格列一下（据 Hugging Face 模型卡和多家核验）：
| 项目 | 规格 |
|---|---|
| 总参数 | 1.6T（部分来源作1.65T） |
| 激活参数 | 49B |
| 架构 | MoE |
| 上下文 | 1M token |
| 最大输出 | 384K token |
| 许可 | MIT |
| 注意力机制 | Compressed Sparse Attention + Heavily Compressed Attention |
DeepSeek 称这套注意力方案把百万 token 场景下的单 token 推理算力压到 V3.2 世代的 27%，KV cache 压到 10%。两个 V4 模型都在 32 万亿以上 token 上预训练。
关于参数规模有个小分歧值得指出：多数来源作 1.6T，theaibench 作 1.65T，vectorwire 作 1.7T。DataNorth 明确提醒：“DeepSeek 在发布文章里没有重述参数规模，所以应该把那个数字当作已报道而非已确认。”
模型能力方面，DeepSeek 自报的数据是：Terminal Bench 2.1 = 87.9，Cybergym = 83.3，DeepSWE = 62.7，Toolathlon-Verified = 74.1，Agents’ Last Exam = 25.7。
这些数字全部是厂商自测，且是在 DeepSeek 自家Harness 的 minimal 模式下跑的（只有 bash 和文本编辑器两个工具），推理强度开到 max。theaibench 的评价很直接：这些都算"claims rather than findings"，在独立数据出现之前不能当结论。
相比预览版的提升幅度确实很大：Terminal Bench 2.1 从 72.1 到 87.9，DeepSWE 从 12.8 到 62.7（约 4.9 倍）。
但 DeepSWE 那个 4.9 倍最需要谨慎：从 12.8 涨到 62.7 的同时，测试用的 Harness 也是同一家公司做的。
🎯 四、这件事在企业侧意味着什么
平台让判断标准可执行、可追溯，但标准本身对不对仍需专家确定。对企业来说，这几个成本口径的坑是共通的：
4.1 模型名 ≠ 实际模型 ≠ 实际价格
上面deepseek-v4-pro那个例子是最极端的情况：模型名指向的东西和实际调用的东西可以不一致。
这是模型下线、别名路由、版本别名等运维操作的正常产物，但很多成本测算表里写的还是三个月前的模型名。
对应的做法：
- 成本核算挂到实际响应，不挂到请求的模型名。从响应元数据里取真实计费口径，而不是从请求参数推断。
- 模型下线要有告警。模型映射表变更时，主动通知所有使用方，而不是等发现账单变了才追查。
- 定期对照官方价格页和弃用公告。这类变更的节奏现在是几周一次，半年校准一次是不够的。
4.2 峰谷定价要落到排程层，而不是留在文档里
两倍的成本差，如果靠开发记得"避开高峰"，等于没做。
- 批量任务排到闲时。夜间跑的批处理、离线索引、数据清洗这类，对时延不敏感，全部应该排到闲时窗口。
- 交互式请求接受高峰价，但要监控成本。用户实时请求没法挪时间，这一部分的成本要单独看。
- 成本报表按时段分列。只看总账单发现不了"一半任务跑在高峰"这种问题。
按 DeepSeek 的划分，UTC 01:00–04:00 和 06:00–10:00 是高峰（对应北京时间 09:00–12:00、14:00–18:00），其余全部是闲时，闲时价是高峰的一半。对大多数面向中国用户的系统，重活排到夜间是最直接的动作。
4.3 缓存命中率应该成为 Agent 的核心指标
这次改动让缓存从一个"优化项"变成"决定成本量级的变量"。
- Agent 场景要单独统计缓存命中率，不要和普通问答混在一起看。普通问答的命中率可能只有 30%，Agent 可能到 80%，两者混算会掩盖问题。
- 提示词稳定性直接影响命中率。如果每个请求都重新拼接一份不同的上下文，缓存永远不命中。把不变的部分放在前面、变化的部分放后面，这是最直接的优化。
- 多轮会话不要重发全部历史。Agent 会话里重复发送完整历史是最常见的缓存杀手。
4.4 厂商自测分数不进选型依据
V4-Pro 那一串漂亮数字（87.9、83.3、62.7）全部是厂商在自己 harness 上跑出来的。这带来一个判断原则：
选型要看的是"在你的场景、你的工具链、你的评测集上的表现"，不是"厂商报告的最大值"。
一个具体的评测集定义要求：
| 要素 | 要求 | 为什么 |
|---|---|---|
| 任务集 | 用自己的真实任务，不用公开 benchmark | 公开 benchmark 已被针对性优化 |
| 工具链 | 用自己实际接的工具 | harness 不同结果差极大 |
| 评测人 | 要么有独立评测，要么交叉验证 | 厂商自测有强立场 |
| 报告口径 | 要求原始样本量 | 只有均值的分数没有意义 |
能被说服的方式是：让候选方在你的数据上跑，而不是看它的宣传材料。
4.5 选型判断流程
这张图的落点是 K 和 L 两行。定价规则的变更频率已经到了按月计的程度，任何一次架构评审之后都需要重新过一遍。
✅ 七、可以带走的判断清单
- 最该关注的不是输出价，是缓存折扣。从约1/120 缩到 1/30，涨 500%，Agent 场景首当其冲。
- 峰谷定价方向和直觉相反。闲时是高峰的一半，不是"闲时便宜一点"。高峰时段是北京时间 9-12、14-18。
- 缓存命中占比越高，总涨幅越大。因为缓存价涨幅倍数最大，权重越大放大越强。
- 跑高峰就是跑双倍价。同一任务闲时 0.0174 美元，高峰 0.0348 美元。
deepseek-v4-pro现在路由到 Flash。9月14日起生效。做成本测算要先确认实际计费对象。- 模型名不等于实际模型，也不等于实际价格。成本核算要挂到实际响应，不要从请求参数推断。
- V4-Pro 的 87.9 / 62.7 是厂商在自家 harness 上的自测。DeepSeek 从 12.8 到 62.7 的同时，测试工具也是同家的。
- 参数规模有 1.6T / 1.65T / 1.7T 三个版本，官方发布文没重述这个数字。
- 定价规则变更已到了按月计的节奏，季度复评是最低要求。
最后一条最实际：现在去拉一份自己的成本台账，看看有多少比例的调用落在高峰时段、缓存命中率是多少。这两个数一出来，DeepSeek 这轮调价对你的真实影响基本就有数了。
你们团队的模型调用，高峰时段占比和缓存命中率这两个数现在能拿到吗？如果拿不到，说明成本核算的口径本身还没建起来——评论区说说你们现在统计到哪一层了，我帮你看补哪一项最省事。