逐字稿文字預覽
Deepseek刚刚做了一件反常的事 它发布了新一代V4.1Flash 却准备让这款名字里带着 轻量的模型接管上一代V4Pro 北京时间9月14日中午以后 用户即使继续调用Pro接口 请求也会被转给V4.1Flash 而且只收Flash的价格 一款便宜模型为什么能 让旗舰型号暂时退场 答案藏在这次发布 最容易被忽略的地方 Deepseek换掉了计算方式 也开始重新定义 什么叫大模型的性价比 V4.1 Flash是Deepseek下一代架构 家族公开亮相的第一款产品 升级范围远超增加 视觉模块和改动版本号 官方把它称为这个新 家族中尺寸最小的成员 可它拥有5,520亿个参数 这个小只存在于Deepseek 规划中的下一代产品线里 放到普通开源模型市场 它依然是一台需要数据中心级 资源才能完整部署的庞然大物 5,520亿之外 80亿和160亿更能解释 这款模型怎样运行 V4.1Flash继续采用混合专家模型 但输入与输出阶段 使用不同的激活规模 模型读取内容时大约激活80亿参数 生成答案时大约激活160亿参数 总参数负责储存能力 参与每一步运算的 参数则被压到更小范围 Deepseek给这种设计起的 名字是causal encoder decoder 也就是因果编码器与解码器结构 为什么要把输入和输出分开算 因为AI的工作形态已经变了 聊天机器人时代 用户问一句 模型答一段 输入和输出长度相差不大 智能体时代完全不同 一个代码代理可能先读 几十万个TOKEN的仓库 检查报错文档和提交记录 最后只修改几百行代码 一个研究代理可能翻完上百页资料 调用十几次工具 最后只交付一份报告 大量成本花在看懂现场 真正写出来的内容反而很短 传统架构如果用同一套高 成本路径处理所有TOKEN 就会在输入阶段浪费大量算力 V4.1Flash把读取和生成 做成不对称路径 让输入侧更轻 输出侧再投入更多专家能力 这不保证每个任务都更快 却准确集中了智能体 最常见的成本结构 Deepseek要解决的是代理 连续工作几小时以后 账单能否保持可控 单轮回答的价格已经 不足以衡量这类产品 这也解释了为什么Deepseek把 视觉理解直接放进基础架构 旧产品线里 文本版V4Flash和V4Flash vision xlarge分开存在 新版本发布以后 这两个旧模型都被下线 接口名称暂时转向V4.1Flash 开发者不再需要先判断 请求属于文本还是图片 再选择不同模型 截图图表网页界面和文字 可以进入同一套推理流程 这项产品整合对智能体很关键 现实中的电脑操作 同时包含文字和画面 按钮位置会改变 错误提示藏在截图里 图表数据没有完整写进网页代码 远程桌面甚至指向模型提供画面 一个不能稳定理解视觉环境的代理 工具再多也只能在 半个互联网里行动 原生视觉让V4.1 Flash更 接近真正的电脑操作模型 能力范围已经超出调用 搜索接口的聊天机器人 深度求索为这套 架构设定了四个目标 提高能力上限和推理速度 扩大吞吐 再把同一设计延伸到更大的模型 最后一项尤其值得留意 V4.1Flash很可能只是这一代 架构的第一场公开压力测试 输入激活80亿 输出激活160亿的设计 如果能在大规模API流量里保持稳定 未来V4.1Pro就可以沿着同 一条路线扩大容量 而不用让成本跟参数量同步膨胀 模型架构里还有另 一条更实际的变化 KV cache被继续压缩 长上下文模型会把已经 处理过的信息保存成缓存 避免生成下一个TOKEN时从头计算 上下文越长 缓存占用越大 模型跑100万TOKEN 同时服务大量用户时 系统瓶颈会同时出现在计算芯片 显存容量数据搬运速度与外部存储 上Deepseek公布的数据称 V4.1Flash对HBM的需求降到上一代的1/4 对SSD的需求降到1/8 与Deepseek最早一代架构相比 KV CACHE累计缩小约437倍 这些数字需要等待独立部署测试 但它们揭示了产品真正争夺的资源 模型公司过去比谁有更多算力 现在还要比谁能用更少 显存保存更长的工作记忆 HBM为什么如此重要 因为它是高端AI芯片旁边最 昂贵也最紧缺的部件之一 模型参数激活值和上下文 缓存都在争夺同一块高速空间 缓存膨胀以后 服务器要么减少并发用户 要么增加GPU数量 要么把部分数据 挪到速度较慢的存储 三条路都会增加成本 把缓存压下来 相当于在不购买同等 数量新硬件的情况下 为现有服务器腾出更多座位 SSD需求下降会减少硬盘投入 也会缓解长任务的数据交换 为了维持上下文 系统可能需要在显存和 外部存储之间不断搬运数据 交换越频繁 延迟越高 系统也越难保持稳定吞吐 Deepseek把SSD需求压到1/8 是在减少智能体 长时间运行时的存储交通 用户感受到的可能只是回复更快 服务商看到的却是每台 机器能承载更多并发任务 V4.1Flash的第一层意义是重新安排 参数显存和存储之间的关系 基准题多做对几个只是结果之一 大模型的能力竞争 进入下一阶段以后 真正难的工作是把高水平 推理变成可以长期供应的服务 模型只在演示中聪明没有用 必须让数百万个代理同时工作 企业才可能建立稳定收入 第二层意义来自它的能力定位 Deepseek公布的GPQA Diamond成绩是90.9 HLE是36.8 codeforces评分达到3471 数学与科学推理依然重要 但这次最醒目的提升集中在终端 代码仓库自动化和网络安全任务 terminal bench 2.1达到90.6 deepsw 1.1达到74.2 NL to Repo bench达到65.4 cybergem达到88.1 这些名字对普通用户不够直观 Terminal bench测试模型能不能在真实 终端环境里连续执行命令并完成 任务 Deepseek和NL to repo关注模型是否能 理解软件仓库定位问题并修改代码 Automation bench考察跨工具自动化 cyberjail与Seckbench则把模型 放进网络安全任务中 他们共同测试模型能否把事情做完 聊天是否流畅只占很小一部分 过去一款Flash模型往往 意味着速度快价格低 复杂任务需要交给Pro V4.1Flash想打破这套分工 官方称它在性能价格速度和 任务总耗时上都超过V4Pro 因此决定有序下线旧Pro 最有冲击力的是Deepseek 愿意把实际Pro流量交给Flash 单个分数领先反倒居于其次 如果新模型在生产环境里撑不住 这种路由会直接影响付费客户 不过厂商敢切换流量不等于 所有性能结论已经得到独立证明 代码代理基准采用 Deepseek Harness的minimal模式 并使用最大推理强度 和百万TOKEN上下文 不同模型如果采用不同 工具框架提示方式和预算 最终成绩很难完全横向比较 基准能证明V4.1Flash有 很强的代理能力 却不能证明它在任何代码 库里都比所有旗舰模型可靠 稀疏激活本身也不会 自动兑现成低延迟 混合专家模型需要先判断 每个TOKEN该送给哪些专家 再让不同设备交换结果 专家分布不均时 部分GPU会排队 另一些GPU却在等待 夸卡通信如果处理不好 省下来的乘法运算 可能被数据搬运吃掉 V4.1 Flash能否跑得快 取决于路由算法并行策略和 推理框架能不能共同配合 架构给出了效率空间 工程系统负责把空间变成 用户真正感受到的速度 这也让官方速度与 本地速度成为两个问题 Deepseek自己的API可以围绕 固定硬件做高度优化 社区部署却要面对不同GPU 不同带宽和不同量化方式 一套在大型集群上 表现优秀的专家路由 移到规模较小的服务器后 未必保持同样吞吐 开放权重让外界有机会验证 却不会让官方服务的成本优势 自动复制到每一家企业机房 还有一个常见误区 任务分数提高 不代表模型的每一步操作都更可信 智能体需要连续执行 几十甚至上百个动作 每一步只有很小的错误概率 累积到长链任务里也会明显放大 终端基准做到90分 进入企业生产环境以后 仍要面对权限管理依赖 冲突过时文档和不可逆操作 模型越能行动 安全边界就越重要V4.1Flash 在cyberjams上得到88.1 也会带来双重影响 防守团队可以用它审计 代码复现漏洞和处理告警 供给者同样可以让 模型自动寻找入口 开源权重和廉价API降低了 先进能力的使用门槛 也会降低滥用门槛 评价这款模型需要同时 检查任务能力与部署治理 后者包括限制权限记录 操作并阻止高风险行为 第三层意义是价格 V4.1Flash上线后 Deepseek继续采用峰谷计费 闲时每百万TOKEN的缓存 命中输入只收0.02元 未命中输入1元 输出4元 高峰时段分别是0.04元2元和8元 缓存命中价格低到几乎是在 鼓励开发者重复携带长上下文 这套定价为智能体量身定做 一个代理每天处理同一套公司规则 同一个代码仓库和同一批长期记忆 大部分输入会反复出现 缓存命中以后 服务商不需要重新完成全部计算 客户也获得更低价格 只有新问题新网页和新任务 产生的内容按未命中计费 上下文越稳定 成本优势越明显 便宜的缓存还会改变产品设计 过去开发者为了省钱 会主动删掉历史记录 把复杂任务切成短对话 这样虽然减少TOKEN 却容易丢失目标约束和中间结果 缓存价格降到每 百万TOKEN几分钱以后 保留长期记忆变得更可行 产品可以让代理记住项目状态 而不用每次启动都重新解释背景 输出价格依然远高于缓存命中输入 这也在引导开发者 减少无意义长回答 代理最理想的工作方式是大量读取 少量决策 精确行动 V4.1 Flash的非对称激活和API 价格指向同一个方向 输入可以很长 输出应该服务于任务 那些依靠生成大段 文本制造工作量的产品 反而无法充分利用这套成本结构 峰谷计费则暴露出 Deepseek的另一项现实约束 闲时价格只有高峰的一半 说明算力需求仍然 会在特定时间集中 Deepseek用价格把非紧急 任务推向空闲时段 让数据中心保持更稳定的利用率 批量代码检查离线研究和 夜间数据处理可以延后执行 即时客服与在线编程 则继续支付高峰成本 这套价格承担着算力调度功能 传统云服务按机器使用时间收费 Deepseek把电力服务器利用率和 请求时段直接写进TOKEN价格 用户看到的是一张价格表 Deepseek考虑的是怎样 减少昂贵GPU的空转 模型架构压低单次推理成本 峰谷价格在平衡总流量 两者组合起来才形成真正的低价 腾讯的work Buddy code Buddy和open code 已经成为首批官方合作伙伴 这组名单也说明V4.1Flash瞄准的市场 办公代理和代码工具 成为首批展示场景 娱乐聊天与图片问答被放到后面 开发者会在这些 产品里连续调用模型 使用量大 对延迟和成本极其敏感 也最容易验证Flash能否 承担原本属于Pro的任务 Deepseek为什么愿意让Pro请求转到Flash 一方面新架构可能确实把 相近能力做得更便宜 另一方面 统一流量也能减少 维护多款旧模型的成本 每多保留一个生产模型 服务商都要准备独立容量监控 质量修补安全问题并处理接口兼容 把旧Flash 视觉实验版和Pro流量集中到V4.1Flash 可以提高集群利用率 这种统一也有风险 部分客户选择Pro 可能依赖它在特殊姿势长 推理或固定输出风格上的表现 接口名称不变 底层模型却换了 自动化流程就可能 出现难以发现的漂移 Deepseek需要让API返回明确版本信息 并给企业足够的迁移窗口 一次回答贵几分钱 通常可以计算生产 结果突然改变才是企业 客户最难控制的成本 模型权重仓库同步出现在hugging face 意味着社区能够继续 进行量化适配和私有部署 开放权重会让更多 团队检查模型行为 也能推动SG Lang VLLM等推理 框架快速支持新架构 但5,520亿总参数提醒了一个现实 普通游戏电脑无法 顺畅运行完整模型 部署仍需要大规模GPU和存储集群 所以Flash这个名字 不能被误读为消费级 他描述Deepseek产品线中的计算效率 绝对硬件门槛依然很高 输入激活只有80亿 总权重仍有5,520亿 激活参数决定单步计算量 总参数则决定权重存储规模 很多宣传会把两者混在一起 制造80亿参数达到旗舰水平的错觉 这并不准确 对企业来说 API可能比自建集群更现实 私有部署能够控制数据和成本 但需要承担模型切分推理 优化故障恢复与硬件采购 只有调用量足够大 数据足够敏感 完整部署才可能划算 Deepseek留下大规模部署合作入口 说明它也知道开放权重不 等于普通客户能够独立跑起来 企业还要计算一笔常被忽略的账 模型权重免费并不 代表每次调用免费 自建集群需要为峰值流量预留硬件 低谷时机器又可能闲置 官方API可以把不同 客户的波峰摊在一起 若企业每天调用量不稳定 购买GPU通常比按TOKEN付费更贵 只有数据不能离开内网 延迟要求极高 或者调用规模长期稳定时 自建部署的控制权才 可能抵消运维成本 私有部署仍有独特价值 团队可以固定版本 避免接口悄悄换模 也能针对自己的文档 和代码建立专用缓存 高度监管行业还可以把日志权限 和数据保留策略掌握在自己手里 V4.1Flash 真正扩大的是选择空间 企业可以先用低价API验证任务 再决定哪些高频流程值得搬回本地 而不用一开始就为整套集群下注 V4.1Flash给闭源模型带来的最大压力 也许来自价格参照 绝对能力只是其中一部分 只要他能用较低成本完成 大部分代码代理和自动化任务 客户就会开始追问 更昂贵的旗舰模型 到底多解决了哪些问题 如果差距只存在于少数极难任务 企业会把日常工作交给Flash 只在失败时升级到高价模型 这种分层路由可能成为 下一阶段的标准架构 简单任务先由低成本模型处理 复杂任务再转给更强模型 V4.1 Flash现在更进一步 它试图把原本属于高价 层的大部分工作吞掉 旗舰模型不会消失 但调用频率可能下降 角色从默认入口变成异常处理器 这会迫使其他厂商重新定价 模型公司过去用更大 上下文更高基准分数吸引客户 接下来必须证明每 一美元能完成多少有效任务 只公布输入单价不够 还要计算完成一次 代码修改需要几轮对话 多少工具调用和多长时间 便宜但反复返工的模型并不便宜 单价较高却一次做对 的模型也未必昂贵 Deepseek强调总用时超过V4Pro 就是在争夺这项新指标 智能体成本由TOKEN价格 生成长度执行轮数失败 重试和等待时间共同组成 一款模型每百万TOKEN便宜一半 如
本次執行流程與問題處理
下達指令
預期流程
- 採用來源字幕（略過語音辨識）
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：2.6 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：53.0 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.1 秒
關係：依序執行
結果：完成
4. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.1 秒
關係：依序執行
結果：完成
5. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.2 秒
關係：依序執行
結果：完成
6. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.2 秒
關係：依序執行
結果：完成
7. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.2 秒
關係：依序執行
結果：完成
8. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：150.5 秒
關係：依序執行
結果：完成
9. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.6 秒
關係：依序執行
結果：完成
10. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.7 秒
關係：依序執行
結果：完成
手動來源字幕
自動來源字幕
Whisper 字幕
- 尚未產生
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.source.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。
- 音訊下載不穩定，需更新 cookies / PO token 後重試精進模式。