DeepSeek V4.1-Flash｜区分输入/输出激活规模并缩小 KV Cache
552B MoE 采用因输入与输出而异的激活规模，并通过新 API 路由替换旧 Flash 型号。
本文核心看点
DeepSeek 于 9 月 10 日发布 V4.1-Flash，这是一款具备原生视觉理解的 552B 参数 MoE 模型。新型因果编码器—解码器架构在输入阶段激活 8B 参数、输出阶段激活 16B；官方称，相比上一代，其 KV Cache 只需四分之一 HBM 与八分之一 SSD。模型已通过 deepseek-flash API 提供，旧 Flash 别名临时路由到新模型；官方计划北京时间9月14日12:00起将 V4-Pro 请求暂时转入 V4.1-Flash，团队需把预定路由切换视为生产变更。
直接回答
DeepSeek 于 9 月 10 日发布 V4.1-Flash，这是一款具备原生视觉理解的 552B 参数 MoE 模型。新型因果编码器—解码器架构在输入阶段激活 8B 参数、输出阶段激活 16B；官方称，相比上一代，其 KV Cache 只需四分之一 HBM 与八分之一 SSD。模型已通过 deepseek-flash API 提供，旧 Flash 别名临时路由到新模型；官方计划北京时间9月14日12:00起将 V4-Pro 请求暂时转入 V4.1-Flash，团队需把预定路由切换视为生产变更。
事实来源
DeepSeek 将 V4.1-Flash 描述为 552B 参数 MoE；因果编码器—解码器架构在输入时激活 8B 参数，在输出时激活 16B。
官方称，相比上一代，V4.1-Flash 的 KV Cache 需要四分之一 HBM 与八分之一 SSD，并把这与代理任务的缓存命中成本联系起来。
模型以 deepseek-flash 名称上线 API 并支持原生多模态；旧 Flash 别名临时指向它，官方计划北京时间 9 月 14 日 12:00 起让 V4-Pro 流量临时改道。
核心变化
- 输入理解与输出生成采用不同的参数激活规模
- KV Cache 的 HBM 与 SSD 占用被官方大幅下调
- API 主模型名统一为 deepseek-flash
- 旧 Flash 别名提供临时兼容路由；V4-Pro 调用计划于北京时间 9 月 14 日 12:00 起临时改道
对普通 AI 用户的影响
非对称激活让团队必须分别观察首 token 前的输入处理和持续解码，而不能只用一个吞吐数字代表整条链路。缓存占用下降可能改善长上下文与代理循环的成本，但比例来自官方与特定上一代对比。更直接的上线风险是别名改道：即使应用没有改模型名，输出质量、视觉输入、延迟和账单也可能变化，因此需要固定评测集与明确回滚目标。
给团队的操作清单
- 盘点所有 deepseek-flash、旧 V4 Flash 与 deepseek-v4-pro 调用，记录实际解析到的模型和费率。
- 用真实任务分别测量输入阶段、首 token 延迟、解码速度、KV Cache 占用和端到端成本。
- 对文本、图像、长上下文和工具调用建立回归集，并把厂商基准与自有结果分开记录。
- 在路由切换窗口设置质量、延迟与费用阈值，保留显式模型配置和可执行回滚步骤。
AI 前沿资讯与趋势解读、AI 软件应用与模型工具、AI 技能教程与验证方法、AI 账号服务与权限说明
FAQ
552B 是否表示每个 token 都会使用全部参数？
不是。官方称这是 MoE 总参数规模，输入阶段激活 8B，输出阶段激活 16B。
旧的 V4 Flash API 名称会立即失效吗？
不会立即失效。DeepSeek 表示旧别名会临时路由到 V4.1-Flash，但没有在该公告中给出终止日期。
官方是否证明所有工作负载都会更便宜、更快？
没有。页面给出架构、缓存与厂商测试表述，具体质量、速度和总成本仍需用自身任务验证。
总结
V4.1-Flash 的工程看点是把输入、输出与缓存成本拆开优化；对 API 使用方，最紧迫的工作则是识别别名改道，并用自己的评测和费用护栏验证变化。
本文由 AI 辅助撰写；发布前由 ENHE AI 自动化审计核对官方来源、双语字段、图片权利、页面安全与历史去重。
这对普通用户意味着什么？
非对称激活让团队必须分别观察首 token 前的输入处理和持续解码，而不能只用一个吞吐数字代表整条链路。缓存占用下降可能改善长上下文与代理循环的成本，但比例来自官方与特定上一代对比。更直接的上线风险是别名改道：即使应用没有改模型名，输出质量、视觉输入、延迟和账单也可能变化，因此需要固定评测集与明确回滚目标。
你可能会用到这些工具
相关教程
相关工具/教程
你可以从下面的 ENHE AI 栏目继续把资讯信号转成工具选择、账号服务判断或实操学习路径。
相关阅读
GitHub Copilot用量API开始统计OpenCode等客户端：请求数不能当提示数
GitHub于2026年10月23日在Copilot用量指标API加入totals_by_client，企业与组织可查看OpenCode、Claude Code、Codex、Zed、Copilot CLI、VS Code和JetBrains等客户端的请求、会话、令牌及模型分布。本文帮助管理员建立一日与28日报表，区分模型调用、用户提示和代理任务，并检查未知客户端、权限与空数组，避免把请求数直接解释成员工行为或精确账单。
GitHub Copilot用量API可识别自定义技能、代理与MCP：报表怎么读
GitHub于2026年10月22日更新Copilot用量指标API，自定义技能、代理、MCP服务器、斜杠命令和插件不再全部归入other或custom，而会按配置名称展示；每类列表上限由5项增至25项。本文帮助管理员升级所需客户端、核对命名、建立一日与28日报表，并解释旧历史、文件路径名称和被阻止遥测为何仍会漏记，避免把趋势数据误当精确账单。
GitHub Copilot模型策略API正式可用：四层权限怎么查与改
GitHub宣布Copilot模型策略REST API正式可用，管理员可在企业、企业团队、代理应用和组织四个层级读取或更新模型策略。本文面向技术管理员，说明这次API开放与此前网页端全局模型策略并非同一事件，并给出“先GET盘点、保存基线、人工审批、最小PATCH、再次GET验证”的操作顺序。示例不包含真实组织名称、令牌或生产写入，也不建议在没有变更窗口和回退记录时批量修改。
AWS 扩展 MoE 强化学习｜EKS、EFA 与 DeepEP 协同提升吞吐
AWS 于 9 月 25 日发布大规模混合专家模型强化学习架构，将 Amazon EKS、Elastic Fabric Adapter、DeepEP 与 Amazon S3 分别用于编排、高速通信和持久化存储。文章把 rollout 生成、奖励模型推理、策略训练、经验缓冲与检查点拆到不同节点组，使各层可以独立扩展。AWS 称在相同的 48 台 P5en 实例上，DeepEP over EFA 配置让内部工作负载的总 rollout 吞吐提高 40%，并扩展到约一千个加速器。该结果依赖特定模型、版本和拓扑，不能直接外推到所有训练任务。
AWS HyperPod Inference Gateway｜让 GPU 状态参与推理路由
AWS 于 9 月 18 日发布 SageMaker HyperPod Inference Gateway Tier 1。它作为 EKS 托管附加组件部署，通过 Body-Based Router 读取 OpenAI 兼容请求中的模型字段，再由 Endpoint Picker 根据 KV cache、队列深度、LoRA 适配器驻留、前缀缓存命中和运行请求选择后端。AWS 在相同副本的对照中报告多类负载的尾延迟改善，首页概括最高可降低 82% 的首 token 延迟；统一稳态负载则与轮询相当。团队应以自己的硬件、模型与流量重做基线。
Dense 与 MoE 选型清单｜别只比较模型总参数
NVIDIA 9 月 15 日的技术文章解释了 Dense 与 Mixture-of-Experts 模型的关键差异：Dense 每个 token 激活全部参数；MoE 把全部专家装入显存，但每个 token 只路由到部分专家，因此显存成本和计算成本不再同步。文章以 Nemotron 3.5 Lightning 为例，30B 总参数每个 token 激活 3B，并指出 MoE 在相同总参数下可能获得更高吞吐，但高并发时延迟优势会收窄，微调还需处理路由失衡，量化也会对路由与投影层产生不同影响。本清单把这些因素转成可重复的团队选型任务。