WEBVTT
Kind: captions
Language: zh

00:00:00.166 --> 00:00:02.766
Deepseek刚刚做了一件反常的事

00:00:02.900 --> 00:00:05.400
它发布了新一代V4.1Flash

00:00:05.566 --> 00:00:07.600
却准备让这款名字里带着

00:00:07.600 --> 00:00:10.600
轻量的模型接管上一代V4Pro

00:00:10.966 --> 00:00:13.366
北京时间9月14日中午以后

00:00:13.500 --> 00:00:15.866
用户即使继续调用Pro接口

00:00:16.000 --> 00:00:18.666
请求也会被转给V4.1Flash

00:00:18.800 --> 00:00:20.733
而且只收Flash的价格

00:00:20.933 --> 00:00:22.666
一款便宜模型为什么能

00:00:22.666 --> 00:00:24.766
让旗舰型号暂时退场

00:00:24.900 --> 00:00:26.466
答案藏在这次发布

00:00:26.466 --> 00:00:28.133
最容易被忽略的地方

00:00:28.566 --> 00:00:30.700
Deepseek换掉了计算方式

00:00:30.766 --> 00:00:32.133
也开始重新定义

00:00:32.133 --> 00:00:34.100
什么叫大模型的性价比

00:00:34.300 --> 00:00:38.266
V4.1 Flash是Deepseek下一代架构

00:00:38.266 --> 00:00:40.533
家族公开亮相的第一款产品

00:00:40.866 --> 00:00:42.500
升级范围远超增加

00:00:42.500 --> 00:00:44.566
视觉模块和改动版本号

00:00:44.933 --> 00:00:46.366
官方把它称为这个新

00:00:46.366 --> 00:00:48.666
家族中尺寸最小的成员

00:00:48.866 --> 00:00:51.700
可它拥有5,520亿个参数

00:00:51.966 --> 00:00:53.900
这个小只存在于Deepseek

00:00:54.066 --> 00:00:56.200
规划中的下一代产品线里

00:00:56.266 --> 00:00:58.200
放到普通开源模型市场

00:00:58.266 --> 00:01:00.500
它依然是一台需要数据中心级

00:01:00.500 --> 00:01:03.066
资源才能完整部署的庞然大物

00:01:03.166 --> 00:01:04.966
5,520亿之外

00:01:05.000 --> 00:01:07.666
80亿和160亿更能解释

00:01:07.666 --> 00:01:09.466
这款模型怎样运行

00:01:09.733 --> 00:01:12.966
V4.1Flash继续采用混合专家模型

00:01:13.200 --> 00:01:14.933
但输入与输出阶段

00:01:14.933 --> 00:01:16.700
使用不同的激活规模

00:01:16.933 --> 00:01:20.166
模型读取内容时大约激活80亿参数

00:01:20.466 --> 00:01:23.600
生成答案时大约激活160亿参数

00:01:23.766 --> 00:01:25.766
总参数负责储存能力

00:01:26.200 --> 00:01:27.500
参与每一步运算的

00:01:27.500 --> 00:01:29.566
参数则被压到更小范围

00:01:29.766 --> 00:01:31.666
Deepseek给这种设计起的

00:01:31.666 --> 00:01:34.200
名字是causal encoder decoder

00:01:34.600 --> 00:01:37.600
也就是因果编码器与解码器结构

00:01:37.800 --> 00:01:40.400
为什么要把输入和输出分开算

00:01:40.666 --> 00:01:43.166
因为AI的工作形态已经变了

00:01:43.533 --> 00:01:44.933
聊天机器人时代

00:01:45.066 --> 00:01:46.200
用户问一句

00:01:46.200 --> 00:01:47.400
模型答一段

00:01:47.600 --> 00:01:50.133
输入和输出长度相差不大

00:01:50.266 --> 00:01:52.166
智能体时代完全不同

00:01:52.166 --> 00:01:53.933
一个代码代理可能先读

00:01:53.933 --> 00:01:55.533
几十万个TOKEN的仓库

00:01:55.800 --> 00:01:58.400
检查报错文档和提交记录

00:01:58.700 --> 00:02:00.766
最后只修改几百行代码

00:02:00.766 --> 00:02:03.800
一个研究代理可能翻完上百页资料

00:02:04.000 --> 00:02:05.533
调用十几次工具

00:02:05.966 --> 00:02:07.733
最后只交付一份报告

00:02:07.933 --> 00:02:10.200
大量成本花在看懂现场

00:02:10.400 --> 00:02:12.900
真正写出来的内容反而很短

00:02:13.000 --> 00:02:15.133
传统架构如果用同一套高

00:02:15.133 --> 00:02:17.200
成本路径处理所有TOKEN

00:02:17.466 --> 00:02:20.200
就会在输入阶段浪费大量算力

00:02:20.466 --> 00:02:23.400
V4.1Flash把读取和生成

00:02:23.400 --> 00:02:24.866
做成不对称路径

00:02:25.300 --> 00:02:27.000
让输入侧更轻

00:02:27.133 --> 00:02:29.900
输出侧再投入更多专家能力

00:02:29.933 --> 00:02:32.166
这不保证每个任务都更快

00:02:32.333 --> 00:02:34.100
却准确集中了智能体

00:02:34.100 --> 00:02:35.700
最常见的成本结构

00:02:35.933 --> 00:02:37.933
Deepseek要解决的是代理

00:02:37.933 --> 00:02:39.700
连续工作几小时以后

00:02:39.866 --> 00:02:41.566
账单能否保持可控

00:02:41.900 --> 00:02:43.466
单轮回答的价格已经

00:02:43.466 --> 00:02:45.266
不足以衡量这类产品

00:02:45.366 --> 00:02:47.700
这也解释了为什么Deepseek把

00:02:47.700 --> 00:02:50.200
视觉理解直接放进基础架构

00:02:50.966 --> 00:02:52.133
旧产品线里

00:02:52.133 --> 00:02:56.866
文本版V4Flash和V4Flash vision xlarge分开存在

00:02:57.066 --> 00:02:58.533
新版本发布以后

00:02:58.566 --> 00:03:00.533
这两个旧模型都被下线

00:03:00.933 --> 00:03:03.700
接口名称暂时转向V4.1Flash

00:03:03.933 --> 00:03:05.700
开发者不再需要先判断

00:03:05.700 --> 00:03:07.933
请求属于文本还是图片

00:03:08.133 --> 00:03:09.733
再选择不同模型

00:03:10.000 --> 00:03:13.566
截图图表网页界面和文字

00:03:13.666 --> 00:03:15.900
可以进入同一套推理流程

00:03:15.966 --> 00:03:18.533
这项产品整合对智能体很关键

00:03:19.366 --> 00:03:20.700
现实中的电脑操作

00:03:20.700 --> 00:03:22.600
同时包含文字和画面

00:03:22.766 --> 00:03:24.100
按钮位置会改变

00:03:24.100 --> 00:03:25.766
错误提示藏在截图里

00:03:25.766 --> 00:03:28.533
图表数据没有完整写进网页代码

00:03:28.533 --> 00:03:31.733
远程桌面甚至指向模型提供画面

00:03:31.800 --> 00:03:34.733
一个不能稳定理解视觉环境的代理

00:03:34.966 --> 00:03:36.333
工具再多也只能在

00:03:36.333 --> 00:03:37.900
半个互联网里行动

00:03:38.200 --> 00:03:41.166
原生视觉让V4.1 Flash更

00:03:41.166 --> 00:03:43.600
接近真正的电脑操作模型

00:03:44.133 --> 00:03:46.066
能力范围已经超出调用

00:03:46.066 --> 00:03:48.100
搜索接口的聊天机器人

00:03:48.366 --> 00:03:49.466
深度求索为这套

00:03:49.466 --> 00:03:51.100
架构设定了四个目标

00:03:51.366 --> 00:03:53.533
提高能力上限和推理速度

00:03:53.600 --> 00:03:54.566
扩大吞吐

00:03:54.700 --> 00:03:57.300
再把同一设计延伸到更大的模型

00:03:57.500 --> 00:03:59.333
最后一项尤其值得留意

00:03:59.700 --> 00:04:02.333
V4.1Flash很可能只是这一代

00:04:02.333 --> 00:04:04.700
架构的第一场公开压力测试

00:04:04.866 --> 00:04:06.166
输入激活80亿

00:04:06.166 --> 00:04:08.333
输出激活160亿的设计

00:04:08.700 --> 00:04:11.733
如果能在大规模API流量里保持稳定

00:04:11.966 --> 00:04:14.966
未来V4.1Pro就可以沿着同

00:04:14.966 --> 00:04:16.600
一条路线扩大容量

00:04:16.766 --> 00:04:19.566
而不用让成本跟参数量同步膨胀

00:04:20.000 --> 00:04:21.066
模型架构里还有另

00:04:21.066 --> 00:04:22.600
一条更实际的变化

00:04:22.766 --> 00:04:24.733
KV cache被继续压缩

00:04:25.000 --> 00:04:26.766
长上下文模型会把已经

00:04:26.766 --> 00:04:28.933
处理过的信息保存成缓存

00:04:29.200 --> 00:04:32.133
避免生成下一个TOKEN时从头计算

00:04:32.333 --> 00:04:33.666
上下文越长

00:04:33.700 --> 00:04:35.100
缓存占用越大

00:04:35.266 --> 00:04:36.933
模型跑100万TOKEN

00:04:37.266 --> 00:04:39.133
同时服务大量用户时

00:04:39.300 --> 00:04:42.266
系统瓶颈会同时出现在计算芯片

00:04:42.566 --> 00:04:45.866
显存容量数据搬运速度与外部存储

00:04:45.866 --> 00:04:48.566
上Deepseek公布的数据称

00:04:49.133 --> 00:04:54.200
V4.1Flash对HBM的需求降到上一代的1/4

00:04:54.300 --> 00:04:57.000
对SSD的需求降到1/8

00:04:57.000 --> 00:04:59.533
与Deepseek最早一代架构相比

00:04:59.600 --> 00:05:02.766
KV CACHE累计缩小约437倍

00:05:03.266 --> 00:05:05.800
这些数字需要等待独立部署测试

00:05:05.933 --> 00:05:08.900
但它们揭示了产品真正争夺的资源

00:05:09.100 --> 00:05:11.700
模型公司过去比谁有更多算力

00:05:11.933 --> 00:05:13.766
现在还要比谁能用更少

00:05:13.766 --> 00:05:16.100
显存保存更长的工作记忆

00:05:16.500 --> 00:05:18.466
HBM为什么如此重要

00:05:18.566 --> 00:05:21.133
因为它是高端AI芯片旁边最

00:05:21.133 --> 00:05:23.400
昂贵也最紧缺的部件之一

00:05:23.733 --> 00:05:26.400
模型参数激活值和上下文

00:05:26.400 --> 00:05:29.133
缓存都在争夺同一块高速空间

00:05:29.366 --> 00:05:30.733
缓存膨胀以后

00:05:31.133 --> 00:05:33.333
服务器要么减少并发用户

00:05:33.400 --> 00:05:35.300
要么增加GPU数量

00:05:35.400 --> 00:05:36.900
要么把部分数据

00:05:36.933 --> 00:05:38.700
挪到速度较慢的存储

00:05:39.100 --> 00:05:40.900
三条路都会增加成本

00:05:40.966 --> 00:05:42.500
把缓存压下来

00:05:42.600 --> 00:05:44.266
相当于在不购买同等

00:05:44.266 --> 00:05:46.000
数量新硬件的情况下

00:05:46.100 --> 00:05:48.733
为现有服务器腾出更多座位

00:05:48.966 --> 00:05:52.200
SSD需求下降会减少硬盘投入

00:05:52.200 --> 00:05:54.533
也会缓解长任务的数据交换

00:05:54.933 --> 00:05:56.266
为了维持上下文

00:05:56.266 --> 00:05:58.366
系统可能需要在显存和

00:05:58.366 --> 00:06:00.800
外部存储之间不断搬运数据

00:06:01.000 --> 00:06:02.133
交换越频繁

00:06:02.500 --> 00:06:03.533
延迟越高

00:06:03.566 --> 00:06:05.800
系统也越难保持稳定吞吐

00:06:06.066 --> 00:06:09.166
Deepseek把SSD需求压到1/8

00:06:09.166 --> 00:06:10.666
是在减少智能体

00:06:10.666 --> 00:06:12.866
长时间运行时的存储交通

00:06:13.166 --> 00:06:15.800
用户感受到的可能只是回复更快

00:06:16.000 --> 00:06:17.933
服务商看到的却是每台

00:06:17.933 --> 00:06:20.400
机器能承载更多并发任务

00:06:20.500 --> 00:06:24.100
V4.1Flash的第一层意义是重新安排

00:06:24.100 --> 00:06:26.900
参数显存和存储之间的关系

00:06:27.166 --> 00:06:30.100
基准题多做对几个只是结果之一

00:06:30.133 --> 00:06:32.000
大模型的能力竞争

00:06:32.000 --> 00:06:33.600
进入下一阶段以后

00:06:34.000 --> 00:06:36.100
真正难的工作是把高水平

00:06:36.100 --> 00:06:38.666
推理变成可以长期供应的服务

00:06:38.800 --> 00:06:41.566
模型只在演示中聪明没有用

00:06:42.066 --> 00:06:44.666
必须让数百万个代理同时工作

00:06:44.866 --> 00:06:47.066
企业才可能建立稳定收入

00:06:47.133 --> 00:06:49.666
第二层意义来自它的能力定位

00:06:49.900 --> 00:06:54.933
Deepseek公布的GPQA Diamond成绩是90.9

00:06:55.200 --> 00:07:00.533
HLE是36.8 codeforces评分达到3471

00:07:00.666 --> 00:07:03.066
数学与科学推理依然重要

00:07:03.700 --> 00:07:06.400
但这次最醒目的提升集中在终端

00:07:06.600 --> 00:07:10.266
代码仓库自动化和网络安全任务

00:07:10.500 --> 00:07:13.133
terminal bench 2.1达到90.6

00:07:13.366 --> 00:07:16.366
deepsw 1.1达到74.2

00:07:16.766 --> 00:07:19.666
NL to Repo bench达到65.4

00:07:19.966 --> 00:07:22.100
cybergem达到88.1

00:07:22.266 --> 00:07:24.966
这些名字对普通用户不够直观

00:07:25.933 --> 00:07:28.766
Terminal bench测试模型能不能在真实

00:07:28.766 --> 00:07:31.600
终端环境里连续执行命令并完成

00:07:31.600 --> 00:07:32.400
任务

00:07:32.666 --> 00:07:36.500
Deepseek和NL to repo关注模型是否能

00:07:36.500 --> 00:07:39.666
理解软件仓库定位问题并修改代码

00:07:40.000 --> 00:07:43.333
Automation bench考察跨工具自动化

00:07:43.566 --> 00:07:46.500
cyberjail与Seckbench则把模型

00:07:46.500 --> 00:07:48.333
放进网络安全任务中

00:07:48.666 --> 00:07:51.466
他们共同测试模型能否把事情做完

00:07:51.500 --> 00:07:54.333
聊天是否流畅只占很小一部分

00:07:54.466 --> 00:07:56.200
过去一款Flash模型往往

00:07:56.200 --> 00:07:58.300
意味着速度快价格低

00:07:58.466 --> 00:08:00.300
复杂任务需要交给Pro

00:08:00.700 --> 00:08:03.200
V4.1Flash想打破这套分工

00:08:03.300 --> 00:08:06.000
官方称它在性能价格速度和

00:08:06.000 --> 00:08:08.600
任务总耗时上都超过V4Pro

00:08:08.800 --> 00:08:11.100
因此决定有序下线旧Pro

00:08:11.466 --> 00:08:13.100
最有冲击力的是Deepseek

00:08:13.366 --> 00:08:15.900
愿意把实际Pro流量交给Flash

00:08:16.133 --> 00:08:18.866
单个分数领先反倒居于其次

00:08:18.966 --> 00:08:21.500
如果新模型在生产环境里撑不住

00:08:21.500 --> 00:08:24.100
这种路由会直接影响付费客户

00:08:24.133 --> 00:08:26.266
不过厂商敢切换流量不等于

00:08:26.266 --> 00:08:28.900
所有性能结论已经得到独立证明

00:08:29.600 --> 00:08:31.066
代码代理基准采用

00:08:31.066 --> 00:08:33.300
Deepseek Harness的minimal模式

00:08:33.700 --> 00:08:35.366
并使用最大推理强度

00:08:35.366 --> 00:08:37.300
和百万TOKEN上下文

00:08:37.366 --> 00:08:39.000
不同模型如果采用不同

00:08:39.000 --> 00:08:41.600
工具框架提示方式和预算

00:08:41.700 --> 00:08:44.166
最终成绩很难完全横向比较

00:08:44.400 --> 00:08:46.900
基准能证明V4.1Flash有

00:08:46.900 --> 00:08:48.266
很强的代理能力

00:08:48.600 --> 00:08:50.566
却不能证明它在任何代码

00:08:50.566 --> 00:08:53.066
库里都比所有旗舰模型可靠

00:08:53.300 --> 00:08:54.900
稀疏激活本身也不会

00:08:54.900 --> 00:08:56.566
自动兑现成低延迟

00:08:57.166 --> 00:08:59.166
混合专家模型需要先判断

00:08:59.166 --> 00:09:01.366
每个TOKEN该送给哪些专家

00:09:01.500 --> 00:09:03.666
再让不同设备交换结果

00:09:03.866 --> 00:09:05.466
专家分布不均时

00:09:05.466 --> 00:09:07.100
部分GPU会排队

00:09:07.200 --> 00:09:09.133
另一些GPU却在等待

00:09:09.466 --> 00:09:11.533
夸卡通信如果处理不好

00:09:11.700 --> 00:09:13.133
省下来的乘法运算

00:09:13.133 --> 00:09:15.000
可能被数据搬运吃掉

00:09:15.333 --> 00:09:18.266
V4.1 Flash能否跑得快

00:09:18.500 --> 00:09:21.566
取决于路由算法并行策略和

00:09:21.566 --> 00:09:24.066
推理框架能不能共同配合

00:09:24.333 --> 00:09:26.100
架构给出了效率空间

00:09:26.500 --> 00:09:28.700
工程系统负责把空间变成

00:09:28.700 --> 00:09:30.900
用户真正感受到的速度

00:09:30.966 --> 00:09:32.733
这也让官方速度与

00:09:32.733 --> 00:09:34.900
本地速度成为两个问题

00:09:35.166 --> 00:09:37.500
Deepseek自己的API可以围绕

00:09:37.500 --> 00:09:39.466
固定硬件做高度优化

00:09:39.933 --> 00:09:42.666
社区部署却要面对不同GPU

00:09:42.666 --> 00:09:45.133
不同带宽和不同量化方式

00:09:45.266 --> 00:09:46.900
一套在大型集群上

00:09:46.900 --> 00:09:48.600
表现优秀的专家路由

00:09:48.866 --> 00:09:51.100
移到规模较小的服务器后

00:09:51.133 --> 00:09:52.900
未必保持同样吞吐

00:09:53.300 --> 00:09:55.500
开放权重让外界有机会验证

00:09:55.600 --> 00:09:58.100
却不会让官方服务的成本优势

00:09:58.200 --> 00:10:00.533
自动复制到每一家企业机房

00:10:00.600 --> 00:10:02.000
还有一个常见误区

00:10:02.333 --> 00:10:03.700
任务分数提高

00:10:03.700 --> 00:10:06.500
不代表模型的每一步操作都更可信

00:10:06.733 --> 00:10:08.366
智能体需要连续执行

00:10:08.366 --> 00:10:10.300
几十甚至上百个动作

00:10:10.466 --> 00:10:12.700
每一步只有很小的错误概率

00:10:13.366 --> 00:10:16.266
累积到长链任务里也会明显放大

00:10:16.400 --> 00:10:18.333
终端基准做到90分

00:10:18.400 --> 00:10:20.133
进入企业生产环境以后

00:10:20.133 --> 00:10:22.166
仍要面对权限管理依赖

00:10:22.166 --> 00:10:24.566
冲突过时文档和不可逆操作

00:10:24.666 --> 00:10:25.900
模型越能行动

00:10:25.900 --> 00:10:29.066
安全边界就越重要V4.1Flash

00:10:29.400 --> 00:10:31.866
在cyberjams上得到88.1

00:10:31.866 --> 00:10:33.533
也会带来双重影响

00:10:33.866 --> 00:10:35.533
防守团队可以用它审计

00:10:35.533 --> 00:10:38.000
代码复现漏洞和处理告警

00:10:38.400 --> 00:10:39.733
供给者同样可以让

00:10:39.733 --> 00:10:41.366
模型自动寻找入口

00:10:41.466 --> 00:10:44.166
开源权重和廉价API降低了

00:10:44.166 --> 00:10:45.800
先进能力的使用门槛

00:10:45.933 --> 00:10:47.733
也会降低滥用门槛

00:10:47.966 --> 00:10:49.766
评价这款模型需要同时

00:10:49.766 --> 00:10:51.966
检查任务能力与部署治理

00:10:52.166 --> 00:10:54.666
后者包括限制权限记录

00:10:54.666 --> 00:10:57.000
操作并阻止高风险行为

00:10:57.366 --> 00:10:58.900
第三层意义是价格

00:10:59.166 --> 00:11:01.533
V4.1Flash上线后

00:11:01.600 --> 00:11:04.200
Deepseek继续采用峰谷计费

00:11:04.500 --> 00:11:06.300
闲时每百万TOKEN的缓存

00:11:06.300 --> 00:11:08.700
命中输入只收0.02元

00:11:09.266 --> 00:11:10.666
未命中输入1元

00:11:10.800 --> 00:11:11.866
输出4元

00:11:12.266 --> 00:11:16.566
高峰时段分别是0.04元2元和8元

00:11:16.700 --> 00:11:18.900
缓存命中价格低到几乎是在

00:11:18.900 --> 00:11:21.966
鼓励开发者重复携带长上下文

00:11:22.400 --> 00:11:24.866
这套定价为智能体量身定做

00:11:24.866 --> 00:11:27.733
一个代理每天处理同一套公司规则

00:11:27.900 --> 00:11:31.000
同一个代码仓库和同一批长期记忆

00:11:31.566 --> 00:11:33.700
大部分输入会反复出现

00:11:33.966 --> 00:11:35.266
缓存命中以后

00:11:35.366 --> 00:11:38.066
服务商不需要重新完成全部计算

00:11:38.200 --> 00:11:40.000
客户也获得更低价格

00:11:40.666 --> 00:11:43.133
只有新问题新网页和新任务

00:11:43.133 --> 00:11:45.533
产生的内容按未命中计费

00:11:45.866 --> 00:11:47.300
上下文越稳定

00:11:47.366 --> 00:11:48.933
成本优势越明显

00:11:49.100 --> 00:11:51.666
便宜的缓存还会改变产品设计

00:11:52.200 --> 00:11:54.000
过去开发者为了省钱

00:11:54.000 --> 00:11:55.766
会主动删掉历史记录

00:11:55.766 --> 00:11:57.900
把复杂任务切成短对话

00:11:58.500 --> 00:12:00.000
这样虽然减少TOKEN

00:12:00.000 --> 00:12:03.200
却容易丢失目标约束和中间结果

00:12:03.466 --> 00:12:04.733
缓存价格降到每

00:12:04.733 --> 00:12:06.666
百万TOKEN几分钱以后

00:12:06.700 --> 00:12:09.066
保留长期记忆变得更可行

00:12:09.666 --> 00:12:12.133
产品可以让代理记住项目状态

00:12:12.200 --> 00:12:15.000
而不用每次启动都重新解释背景

00:12:15.200 --> 00:12:18.566
输出价格依然远高于缓存命中输入

00:12:18.733 --> 00:12:20.300
这也在引导开发者

00:12:20.300 --> 00:12:21.933
减少无意义长回答

00:12:22.466 --> 00:12:25.333
代理最理想的工作方式是大量读取

00:12:25.333 --> 00:12:26.333
少量决策

00:12:26.366 --> 00:12:27.400
精确行动

00:12:27.533 --> 00:12:31.366
V4.1 Flash的非对称激活和API

00:12:31.366 --> 00:12:32.966
价格指向同一个方向

00:12:33.400 --> 00:12:34.600
输入可以很长

00:12:34.600 --> 00:12:36.333
输出应该服务于任务

00:12:36.366 --> 00:12:37.966
那些依靠生成大段

00:12:37.966 --> 00:12:40.066
文本制造工作量的产品

00:12:40.266 --> 00:12:42.933
反而无法充分利用这套成本结构

00:12:43.100 --> 00:12:44.800
峰谷计费则暴露出

00:12:44.800 --> 00:12:47.133
Deepseek的另一项现实约束

00:12:47.766 --> 00:12:50.066
闲时价格只有高峰的一半

00:12:50.133 --> 00:12:51.766
说明算力需求仍然

00:12:51.766 --> 00:12:53.500
会在特定时间集中

00:12:53.900 --> 00:12:56.366
Deepseek用价格把非紧急

00:12:56.366 --> 00:12:58.266
任务推向空闲时段

00:12:58.400 --> 00:13:01.366
让数据中心保持更稳定的利用率

00:13:01.500 --> 00:13:03.766
批量代码检查离线研究和

00:13:03.766 --> 00:13:06.166
夜间数据处理可以延后执行

00:13:06.566 --> 00:13:08.533
即时客服与在线编程

00:13:08.533 --> 00:13:10.500
则继续支付高峰成本

00:13:10.733 --> 00:13:13.566
这套价格承担着算力调度功能

00:13:13.866 --> 00:13:16.766
传统云服务按机器使用时间收费

00:13:17.000 --> 00:13:19.733
Deepseek把电力服务器利用率和

00:13:19.733 --> 00:13:22.300
请求时段直接写进TOKEN价格

00:13:22.566 --> 00:13:24.700
用户看到的是一张价格表

00:13:25.133 --> 00:13:26.733
Deepseek考虑的是怎样

00:13:26.733 --> 00:13:28.966
减少昂贵GPU的空转

00:13:29.133 --> 00:13:31.700
模型架构压低单次推理成本

00:13:31.933 --> 00:13:34.100
峰谷价格在平衡总流量

00:13:34.200 --> 00:13:37.066
两者组合起来才形成真正的低价

00:13:37.200 --> 00:13:40.766
腾讯的work Buddy code Buddy和open code

00:13:41.100 --> 00:13:43.400
已经成为首批官方合作伙伴

00:13:43.500 --> 00:13:47.200
这组名单也说明V4.1Flash瞄准的市场

00:13:47.466 --> 00:13:49.300
办公代理和代码工具

00:13:49.333 --> 00:13:51.133
成为首批展示场景

00:13:51.500 --> 00:13:54.500
娱乐聊天与图片问答被放到后面

00:13:54.566 --> 00:13:55.733
开发者会在这些

00:13:55.733 --> 00:13:57.500
产品里连续调用模型

00:13:57.733 --> 00:13:58.800
使用量大

00:13:58.800 --> 00:14:01.200
对延迟和成本极其敏感

00:14:01.333 --> 00:14:03.666
也最容易验证Flash能否

00:14:03.666 --> 00:14:05.700
承担原本属于Pro的任务

00:14:05.933 --> 00:14:09.000
Deepseek为什么愿意让Pro请求转到Flash

00:14:09.200 --> 00:14:11.333
一方面新架构可能确实把

00:14:11.333 --> 00:14:13.100
相近能力做得更便宜

00:14:13.566 --> 00:14:14.366
另一方面

00:14:14.533 --> 00:14:15.933
统一流量也能减少

00:14:15.933 --> 00:14:17.866
维护多款旧模型的成本

00:14:17.933 --> 00:14:20.100
每多保留一个生产模型

00:14:20.466 --> 00:14:23.466
服务商都要准备独立容量监控

00:14:23.466 --> 00:14:26.900
质量修补安全问题并处理接口兼容

00:14:27.066 --> 00:14:28.366
把旧Flash

00:14:28.933 --> 00:14:32.533
视觉实验版和Pro流量集中到V4.1Flash

00:14:32.733 --> 00:14:34.466
可以提高集群利用率

00:14:34.500 --> 00:14:36.066
这种统一也有风险

00:14:36.533 --> 00:14:38.000
部分客户选择Pro

00:14:38.266 --> 00:14:40.733
可能依赖它在特殊姿势长

00:14:40.733 --> 00:14:43.066
推理或固定输出风格上的表现

00:14:43.200 --> 00:14:44.466
接口名称不变

00:14:44.700 --> 00:14:46.166
底层模型却换了

00:14:46.200 --> 00:14:47.666
自动化流程就可能

00:14:47.666 --> 00:14:49.533
出现难以发现的漂移

00:14:49.766 --> 00:14:53.266
Deepseek需要让API返回明确版本信息

00:14:53.266 --> 00:14:55.566
并给企业足够的迁移窗口

00:14:55.733 --> 00:14:57.400
一次回答贵几分钱

00:14:57.400 --> 00:14:58.966
通常可以计算生产

00:14:59.366 --> 00:15:01.066
结果突然改变才是企业

00:15:01.066 --> 00:15:02.766
客户最难控制的成本

00:15:02.933 --> 00:15:06.100
模型权重仓库同步出现在hugging face

00:15:06.533 --> 00:15:08.333
意味着社区能够继续

00:15:08.333 --> 00:15:11.466
进行量化适配和私有部署

00:15:11.900 --> 00:15:13.266
开放权重会让更多

00:15:13.266 --> 00:15:14.933
团队检查模型行为

00:15:15.000 --> 00:15:18.300
也能推动SG Lang VLLM等推理

00:15:18.300 --> 00:15:20.300
框架快速支持新架构

00:15:20.366 --> 00:15:23.766
但5,520亿总参数提醒了一个现实

00:15:24.600 --> 00:15:26.066
普通游戏电脑无法

00:15:26.066 --> 00:15:27.800
顺畅运行完整模型

00:15:28.300 --> 00:15:31.533
部署仍需要大规模GPU和存储集群

00:15:31.600 --> 00:15:33.000
所以Flash这个名字

00:15:33.000 --> 00:15:34.700
不能被误读为消费级

00:15:35.166 --> 00:15:38.400
他描述Deepseek产品线中的计算效率

00:15:38.600 --> 00:15:40.700
绝对硬件门槛依然很高

00:15:40.800 --> 00:15:42.733
输入激活只有80亿

00:15:42.866 --> 00:15:45.366
总权重仍有5,520亿

00:15:45.733 --> 00:15:47.933
激活参数决定单步计算量

00:15:48.100 --> 00:15:50.700
总参数则决定权重存储规模

00:15:50.866 --> 00:15:53.333
很多宣传会把两者混在一起

00:15:53.333 --> 00:15:56.533
制造80亿参数达到旗舰水平的错觉

00:15:56.566 --> 00:15:57.766
这并不准确

00:15:57.800 --> 00:15:59.133
对企业来说

00:15:59.400 --> 00:16:02.066
API可能比自建集群更现实

00:16:02.500 --> 00:16:04.800
私有部署能够控制数据和成本

00:16:04.866 --> 00:16:07.166
但需要承担模型切分推理

00:16:07.166 --> 00:16:09.666
优化故障恢复与硬件采购

00:16:09.866 --> 00:16:11.500
只有调用量足够大

00:16:11.500 --> 00:16:12.766
数据足够敏感

00:16:12.900 --> 00:16:14.666
完整部署才可能划算

00:16:14.900 --> 00:16:17.966
Deepseek留下大规模部署合作入口

00:16:18.066 --> 00:16:20.066
说明它也知道开放权重不

00:16:20.066 --> 00:16:22.300
等于普通客户能够独立跑起来

00:16:22.533 --> 00:16:25.000
企业还要计算一笔常被忽略的账

00:16:25.400 --> 00:16:27.133
模型权重免费并不

00:16:27.133 --> 00:16:28.933
代表每次调用免费

00:16:29.266 --> 00:16:32.100
自建集群需要为峰值流量预留硬件

00:16:32.100 --> 00:16:34.100
低谷时机器又可能闲置

00:16:34.300 --> 00:16:35.700
官方API可以把不同

00:16:35.700 --> 00:16:37.500
客户的波峰摊在一起

00:16:37.866 --> 00:16:39.966
若企业每天调用量不稳定

00:16:40.066 --> 00:16:43.133
购买GPU通常比按TOKEN付费更贵

00:16:43.200 --> 00:16:45.266
只有数据不能离开内网

00:16:45.500 --> 00:16:46.966
延迟要求极高

00:16:47.066 --> 00:16:49.666
或者调用规模长期稳定时

00:16:49.800 --> 00:16:51.933
自建部署的控制权才

00:16:51.933 --> 00:16:53.600
可能抵消运维成本

00:16:53.800 --> 00:16:55.700
私有部署仍有独特价值

00:16:56.400 --> 00:16:57.800
团队可以固定版本

00:16:57.800 --> 00:16:59.466
避免接口悄悄换模

00:16:59.666 --> 00:17:01.133
也能针对自己的文档

00:17:01.133 --> 00:17:02.966
和代码建立专用缓存

00:17:03.200 --> 00:17:05.800
高度监管行业还可以把日志权限

00:17:05.800 --> 00:17:08.766
和数据保留策略掌握在自己手里

00:17:08.933 --> 00:17:10.100
V4.1Flash

00:17:10.500 --> 00:17:12.533
真正扩大的是选择空间

00:17:12.733 --> 00:17:15.600
企业可以先用低价API验证任务

00:17:15.733 --> 00:17:19.133
再决定哪些高频流程值得搬回本地

00:17:19.300 --> 00:17:22.166
而不用一开始就为整套集群下注

00:17:22.466 --> 00:17:25.933
V4.1Flash给闭源模型带来的最大压力

00:17:26.266 --> 00:17:28.000
也许来自价格参照

00:17:28.166 --> 00:17:30.300
绝对能力只是其中一部分

00:17:30.566 --> 00:17:32.533
只要他能用较低成本完成

00:17:32.533 --> 00:17:35.066
大部分代码代理和自动化任务

00:17:35.266 --> 00:17:36.900
客户就会开始追问

00:17:37.200 --> 00:17:38.566
更昂贵的旗舰模型

00:17:38.566 --> 00:17:40.400
到底多解决了哪些问题

00:17:40.500 --> 00:17:43.466
如果差距只存在于少数极难任务

00:17:43.733 --> 00:17:46.166
企业会把日常工作交给Flash

00:17:46.366 --> 00:17:49.000
只在失败时升级到高价模型

00:17:49.133 --> 00:17:50.933
这种分层路由可能成为

00:17:50.933 --> 00:17:52.700
下一阶段的标准架构

00:17:53.400 --> 00:17:56.066
简单任务先由低成本模型处理

00:17:56.200 --> 00:17:58.466
复杂任务再转给更强模型

00:17:58.666 --> 00:18:01.300
V4.1 Flash现在更进一步

00:18:01.366 --> 00:18:03.266
它试图把原本属于高价

00:18:03.266 --> 00:18:05.066
层的大部分工作吞掉

00:18:05.266 --> 00:18:06.666
旗舰模型不会消失

00:18:06.666 --> 00:18:08.533
但调用频率可能下降

00:18:08.566 --> 00:18:11.266
角色从默认入口变成异常处理器

00:18:11.533 --> 00:18:13.866
这会迫使其他厂商重新定价

00:18:14.000 --> 00:18:15.600
模型公司过去用更大

00:18:15.600 --> 00:18:18.533
上下文更高基准分数吸引客户

00:18:18.666 --> 00:18:20.000
接下来必须证明每

00:18:20.000 --> 00:18:22.300
一美元能完成多少有效任务

00:18:22.500 --> 00:18:24.533
只公布输入单价不够

00:18:24.866 --> 00:18:26.333
还要计算完成一次

00:18:26.333 --> 00:18:28.700
代码修改需要几轮对话

00:18:28.866 --> 00:18:31.400
多少工具调用和多长时间

00:18:31.933 --> 00:18:34.400
便宜但反复返工的模型并不便宜

00:18:34.600 --> 00:18:36.300
单价较高却一次做对

00:18:36.300 --> 00:18:37.900
的模型也未必昂贵

00:18:38.133 --> 00:18:41.366
Deepseek强调总用时超过V4Pro

00:18:41.366 --> 00:18:43.333
就是在争夺这项新指标

00:18:43.500 --> 00:18:45.566
智能体成本由TOKEN价格

00:18:45.600 --> 00:18:48.333
生成长度执行轮数失败

00:18:48.333 --> 00:18:50.666
重试和等待时间共同组成

00:18:50.900 --> 00:18:53.366
一款模型每百万TOKEN便宜一半

00:18:53.700 --> 00:18:55.366
如果需要多跑三轮

00:18:55.400 --> 00:18:57.466
最终账单仍可能更高

00:18:57.600 --> 00:19:00.266
V4.1Flash若能同时减少

00:19:00.266 --> 00:19:02.133
生成量和任务轮数

00:19:02.766 --> 00:19:05.466
价格优势才会真正落到客户手里

00:19:05.533 --> 00:19:07.866
新架构的输入输出不对称

00:19:08.133 --> 00:19:10.100
也可能影响模型行为

00:19:10.266 --> 00:19:12.333
输出阶段激活更多参数

00:19:12.566 --> 00:19:14.333
理论上可以在生成决策

00:19:14.333 --> 00:19:16.466
时调动更丰富的专家

00:19:16.866 --> 00:19:18.333
输入阶段更精简

00:19:18.533 --> 00:19:20.066
则要确保压缩以后

00:19:20.066 --> 00:19:21.666
不会漏掉关键细节

00:19:21.900 --> 00:19:24.300
代码库里一个不起眼的配置文件

00:19:24.400 --> 00:19:26.766
可能决定整个任务是否成功

00:19:27.466 --> 00:19:29.000
如何在降低输入成本

00:19:29.000 --> 00:19:31.100
的同时保留关键信息

00:19:31.366 --> 00:19:34.100
是独立测试最需要关注的问题

00:19:34.300 --> 00:19:36.933
百万TOKEN上下文需要同时

00:19:36.933 --> 00:19:39.066
检查容量和信息利用率

00:19:39.733 --> 00:19:41.800
模型能够装下100万TOKEN

00:19:42.100 --> 00:19:45.000
不等于能稳定使用其中每一处信息

00:19:45.366 --> 00:19:47.866
长上下文常见问题包括中间

00:19:47.866 --> 00:19:50.566
信息被忽视跨文件关系判断

00:19:50.566 --> 00:19:53.900
错误以及旧指令与新指令发生冲突

00:19:54.166 --> 00:19:56.166
kv CACHE减少了保存成本

00:19:56.166 --> 00:19:59.066
却没有自动解决检索与注意力质量

00:19:59.100 --> 00:20:01.566
真正的测试应该观察模型在超长

00:20:01.566 --> 00:20:04.766
任务末尾还能否准确引用早期约束

00:20:05.100 --> 00:20:07.700
视觉能力也需要经过相同审查

00:20:08.366 --> 00:20:11.400
原生多模态说明模型可以处理图片

00:20:11.400 --> 00:20:13.200
不代表它已经适合无人

00:20:13.200 --> 00:20:15.133
监督地操作所有界面

00:20:15.333 --> 00:20:17.166
网页按钮可能被遮挡

00:20:17.600 --> 00:20:19.200
确认框会改变状态

00:20:19.500 --> 00:20:21.533
恶意页面还能把提示注入

00:20:21.533 --> 00:20:22.700
藏在图片中

00:20:22.866 --> 00:20:24.466
视觉代理如果同时拥有

00:20:24.466 --> 00:20:27.066
终端浏览器和支付权限

00:20:27.300 --> 00:20:30.200
错误的代价远高于识别错一张照片

00:20:30.300 --> 00:20:33.566
这也是V4.1Flash最值得讨论的矛盾

00:20:34.466 --> 00:20:37.600
Deepseek正在把能力速度和价格

00:20:37.600 --> 00:20:40.066
同时推向智能体大规模应用

00:20:40.166 --> 00:20:41.400
可智能体的治理

00:20:41.400 --> 00:20:43.133
能力并没有自动跟上

00:20:43.300 --> 00:20:44.466
模型越便宜

00:20:44.800 --> 00:20:46.300
部署数量越大

00:20:46.600 --> 00:20:47.900
部署数量越大

00:20:48.066 --> 00:20:50.933
偶发错误就越容易变成系统性事故

00:20:51.100 --> 00:20:53.166
行业需要降低推理成本

00:20:53.200 --> 00:20:56.000
也要同步建立权限隔离日志

00:20:56.000 --> 00:20:58.800
审计人工批准和事故响应

00:20:58.966 --> 00:21:00.466
从竞争角度看

00:21:00.533 --> 00:21:03.366
这款模型也透露出Deepseek的节奏

00:21:03.900 --> 00:21:05.466
V4在4月亮相

00:21:05.666 --> 00:21:07.266
7月底更新Flash

00:21:07.466 --> 00:21:09.800
9月又推出V4.1Flash

00:21:10.266 --> 00:21:11.966
更新速度越来越快

00:21:12.166 --> 00:21:14.500
旧模型生命周期越来越短

00:21:14.800 --> 00:21:16.666
开发者获得了更强能力

00:21:16.866 --> 00:21:18.866
也承担更频繁的迁移

00:21:19.066 --> 00:21:20.866
模型厂商如果每隔几周

00:21:20.866 --> 00:21:22.566
改变接口背后的行为

00:21:22.900 --> 00:21:24.333
软件工程中的稳定

00:21:24.333 --> 00:21:26.166
版本观念就会受到挑战

00:21:26.600 --> 00:21:28.533
Deepseek用兼容路由

00:21:28.766 --> 00:21:30.666
减少了接口迁移成本

00:21:30.800 --> 00:21:32.400
旧名称仍能调用

00:21:32.500 --> 00:21:34.066
程序不会立即报错

00:21:34.333 --> 00:21:36.966
但行为兼容比接口兼容更难

00:21:37.066 --> 00:21:38.966
相同提示在新模型上

00:21:38.966 --> 00:21:40.600
可能生成不同长度

00:21:40.733 --> 00:21:41.933
调用不同工具

00:21:41.933 --> 00:21:43.766
或采用不同决策顺序

00:21:44.066 --> 00:21:45.300
企业需要保存

00:21:45.300 --> 00:21:46.266
回归测试

00:21:46.400 --> 00:21:48.566
用自己的任务验证升级

00:21:48.800 --> 00:21:51.333
官方总榜只能充当初步参考

00:21:51.700 --> 00:21:54.066
V4.1Flash的发布也说明

00:21:54.333 --> 00:21:56.500
开源与闭源竞争正在从

00:21:56.500 --> 00:21:58.933
模型权重扩展到服务体系

00:21:59.266 --> 00:22:00.366
权重可以下载

00:22:00.766 --> 00:22:01.766
真正好用

00:22:01.866 --> 00:22:04.600
还需要推理框架缓存系统

00:22:04.700 --> 00:22:08.200
工具协议监控平台和稳定API

00:22:08.400 --> 00:22:10.600
Deepseek一边开放仓库

00:22:10.666 --> 00:22:13.800
一边通过极低API价格吸引流量

00:22:13.800 --> 00:22:15.200
形成双重策略

00:22:15.733 --> 00:22:17.700
社区帮助它适配硬件

00:22:17.733 --> 00:22:19.166
官方服务则把最怕

00:22:19.166 --> 00:22:21.166
麻烦的客户留在平台上

00:22:21.266 --> 00:22:23.300
价格低到一定程度以后

00:22:23.500 --> 00:22:25.966
模型本身可能变成入口

00:22:26.366 --> 00:22:29.333
作为利润中心的重要性会下降

00:22:29.533 --> 00:22:31.566
开发者围绕Deepseek建立

00:22:31.566 --> 00:22:33.966
代理插件和工作流

00:22:34.066 --> 00:22:35.533
平台就能积累真实

00:22:35.533 --> 00:22:37.666
任务数据与生态影响力

00:22:37.866 --> 00:22:40.866
腾讯和open code把V4.1Flash放进

00:22:40.866 --> 00:22:43.000
开发者每天使用的工具里

00:22:43.366 --> 00:22:44.733
这层入口价值已经

00:22:44.733 --> 00:22:46.466
超过普通渠道合作

00:22:46.700 --> 00:22:48.300
谁掌握默认模型

00:22:48.466 --> 00:22:49.700
谁就更容易影响

00:22:49.700 --> 00:22:51.666
下一代软件的技术选择

00:22:51.766 --> 00:22:53.133
可是低价也会给

00:22:53.133 --> 00:22:54.900
Deepseek自己施加压力

00:22:55.400 --> 00:23:00.066
API收入必须覆盖GPU折旧电力带宽

00:23:00.066 --> 00:23:03.366
运维和研发缓存压缩与稀疏激活

00:23:03.366 --> 00:23:06.066
可以降低成本价格战却可能把

00:23:06.066 --> 00:23:08.533
节省下来的空间迅速让给客户

00:23:08.866 --> 00:23:11.066
只要竞争对手继续跟价

00:23:11.300 --> 00:23:12.766
模型服务就会越来越

00:23:12.766 --> 00:23:14.800
像云计算基础设施

00:23:15.166 --> 00:23:17.600
规模和利用率将决定利润

00:23:18.200 --> 00:23:20.733
发布当天的热度很快就会消退

00:23:21.000 --> 00:23:23.766
缓存命中价尤其容易制造误解

00:23:24.000 --> 00:23:25.966
每百万TOKEN2分钱只

00:23:25.966 --> 00:23:27.766
适用于系统已经保存

00:23:27.800 --> 00:23:29.333
再次复用的内容

00:23:29.900 --> 00:23:31.700
首次送入的新资料仍

00:23:31.700 --> 00:23:33.533
按未命中价格计算

00:23:34.200 --> 00:23:36.733
模型输出也按更高价格收费

00:23:36.800 --> 00:23:39.000
代理如果每轮都改写提示

00:23:39.300 --> 00:23:40.666
重新排序文档

00:23:40.966 --> 00:23:42.866
哪怕信息大致相同

00:23:42.966 --> 00:23:44.966
也未必形成稳定缓存

00:23:45.366 --> 00:23:47.100
真正省钱的产品需要把

00:23:47.100 --> 00:23:49.566
系统规则知识库片段和

00:23:49.566 --> 00:23:52.266
项目上下文设计成可重复前缀

00:23:52.566 --> 00:23:54.466
价格优势最终会奖励

00:23:54.466 --> 00:23:56.066
良好的上下文工程

00:23:56.166 --> 00:23:58.533
这会催生一种新的产品分工

00:23:58.933 --> 00:24:00.300
模型厂商负责把

00:24:00.300 --> 00:24:02.366
缓存做得更密更便宜

00:24:02.733 --> 00:24:04.166
应用开发者负责让

00:24:04.166 --> 00:24:06.200
任务产生可复用内容

00:24:06.766 --> 00:24:08.300
企业则要判断哪些

00:24:08.300 --> 00:24:10.066
信息适合长期保存

00:24:10.333 --> 00:24:11.733
缓存保留越多

00:24:12.200 --> 00:24:15.100
隐私和数据生命周期问题也越突出

00:24:15.266 --> 00:24:18.166
低价上下文不能无限保存客户秘密

00:24:18.733 --> 00:24:19.966
服务商必须说明

00:24:19.966 --> 00:24:22.100
缓存是否跨请求复用

00:24:22.100 --> 00:24:23.166
保存多久

00:24:23.266 --> 00:24:25.366
以及用户能否要求删除

00:24:25.400 --> 00:24:27.700
这正是V4.1Flash比一张

00:24:27.700 --> 00:24:29.600
跑分表更重要的原因

00:24:29.733 --> 00:24:31.133
它把模型竞争里的

00:24:31.133 --> 00:24:33.100
三条路线压到了一起

00:24:33.300 --> 00:24:35.666
用非对称架构减少计算

00:24:35.866 --> 00:24:38.066
用缓存压缩释放硬件

00:24:38.600 --> 00:24:41.500
再用价格和接口迁移扩大调用量

00:24:41.566 --> 00:24:43.500
任何一条单独成立都不够

00:24:43.600 --> 00:24:45.066
三条同时成立

00:24:45.300 --> 00:24:48.666
Deepseek才有机会让Flash真正替代Pro

00:24:48.733 --> 00:24:50.733
接下来需要观察四件事

00:24:50.900 --> 00:24:53.300
第一独立评测能否复现

00:24:53.300 --> 00:24:54.900
代码和智能体成绩

00:24:55.466 --> 00:24:57.766
第二百万上下文中的信息

00:24:57.766 --> 00:24:59.533
保持能力是否稳定

00:24:59.700 --> 00:25:02.366
第三视觉工具调用在真实

00:25:02.366 --> 00:25:04.166
网页里能否控制错误

00:25:04.400 --> 00:25:06.400
第四Pro流量切换以后

00:25:06.533 --> 00:25:08.933
企业客户是否出现质量回退

00:25:09.100 --> 00:25:11.166
这些结果比发布会上的领先

00:25:11.166 --> 00:25:14.366
百分比更能决定V4.1Flash的位置

00:25:14.466 --> 00:25:15.866
对普通用户而言

00:25:15.866 --> 00:25:18.666
最直接的变化可能没有那么戏剧化

00:25:19.100 --> 00:25:20.566
应用响应会更快

00:25:20.666 --> 00:25:22.900
更多产品会加入图片理解

00:25:23.166 --> 00:25:25.566
长任务不再轻易因为费用中断

00:25:25.866 --> 00:25:27.533
用户甚至未必知道

00:25:27.533 --> 00:25:29.300
底层模型已经更换

00:25:29.400 --> 00:25:32.366
真正剧烈的变化发生在开发者后台

00:25:32.666 --> 00:25:35.000
同样预算能够运行更多代理

00:25:35.366 --> 00:25:37.066
过去不值得自动化的小

00:25:37.066 --> 00:25:39.400
任务开始变得有经济意义

00:25:39.533 --> 00:25:40.733
一家公司每天有

00:25:40.733 --> 00:25:42.533
10万份文档需要分类

00:25:42.733 --> 00:25:44.300
模型价格下降一点

00:25:44.600 --> 00:25:46.866
全年成本就会出现巨大差异

00:25:47.000 --> 00:25:48.566
一个代码平台每天

00:25:48.566 --> 00:25:51.000
处理数百万次仓库查询

00:25:51.366 --> 00:25:53.566
缓存需求减少3/4

00:25:53.700 --> 00:25:55.333
硬件规划也会改变

00:25:55.500 --> 00:25:59.533
V4.1Flash争夺的就是这些看起来无聊

00:25:59.766 --> 00:26:01.600
调用量却极大的任务

00:26:01.966 --> 00:26:03.933
消费级聊天带来知名度

00:26:04.166 --> 00:26:05.400
重复发生的企业

00:26:05.400 --> 00:26:07.400
流程才带来持续流量

00:26:07.466 --> 00:26:09.333
对国内模型行业来说

00:26:09.533 --> 00:26:12.500
Deepseek还在提高低价旗舰的门槛

00:26:12.933 --> 00:26:14.533
其他厂商无法只拿

00:26:14.533 --> 00:26:16.466
一个更小模型参加竞争

00:26:16.800 --> 00:26:19.100
还得同时支持长上下文

00:26:19.266 --> 00:26:21.966
视觉工具调用和代码代理

00:26:22.166 --> 00:26:23.600
能力追平以后

00:26:23.766 --> 00:26:25.600
价格又必须足够低

00:26:25.866 --> 00:26:28.166
这样的竞争会加速行业整合

00:26:28.400 --> 00:26:30.600
拥有算力工程和分发

00:26:30.600 --> 00:26:32.700
能力的平台更容易留下

00:26:32.733 --> 00:26:34.333
单纯依靠模型演示

00:26:34.333 --> 00:26:36.066
的公司会越来越难

00:26:36.133 --> 00:26:37.700
对海外厂商而言

00:26:37.800 --> 00:26:39.566
压力来自另一种方向

00:26:39.966 --> 00:26:41.566
闭源模型仍可能在

00:26:41.566 --> 00:26:43.466
最高难度任务上领先

00:26:43.566 --> 00:26:46.566
也拥有成熟企业合规与服务支持

00:26:47.100 --> 00:26:50.766
但V4.1Flash会迫使客户进行任务拆分

00:26:50.866 --> 00:26:53.766
大量日常调用如果能转向便宜模型

00:26:53.800 --> 00:26:55.333
高价厂商只能从最

00:26:55.333 --> 00:26:57.300
复杂的少数请求中赚钱

00:26:57.666 --> 00:27:00.333
他们需要证明的不再是模型最好

00:27:00.366 --> 00:27:02.966
而是领先部分足以抵消价格差

00:27:03.266 --> 00:27:05.366
Deepseek这次没有发布一款

00:27:05.366 --> 00:27:07.200
真正意义上的小模型

00:27:07.533 --> 00:27:10.333
他发布的是一台把庞大参数藏

00:27:10.333 --> 00:27:13.000
在稀疏计算后面的工业机器

00:27:13.100 --> 00:27:15.800
5,520亿参数提供容量

00:27:15.900 --> 00:27:19.333
80亿和160亿激活规模控制成本

00:27:19.533 --> 00:27:22.166
压缩缓存负责承载长期任务

00:27:22.333 --> 00:27:25.333
原生视觉负责进入真实电脑环境

00:27:25.733 --> 00:27:27.666
最后再用API低价把这些

00:27:27.666 --> 00:27:29.533
能力送进开发者工具

00:27:29.700 --> 00:27:31.866
开头那个问题现在有了答案

00:27:32.133 --> 00:27:35.500
V4.1Flash能够暂时接管Pro

00:27:35.566 --> 00:27:37.566
靠的是把旗舰能力装进

00:27:37.566 --> 00:27:39.466
更低成本的运行结构

00:27:39.933 --> 00:27:42.300
Flash这个名称并没有失去意义

00:27:42.533 --> 00:27:45.200
Deepseek想淘汰一款旧模型

00:27:45.333 --> 00:27:47.566
也在挑战能力越强就

00:27:47.566 --> 00:27:49.400
一定越贵的行业惯性

00:27:49.500 --> 00:27:51.133
这场测试才刚开始

00:27:51.400 --> 00:27:53.500
官方基准可以证明方向

00:27:53.566 --> 00:27:55.666
生产流量才能证明结果

00:27:55.933 --> 00:27:58.700
如果9月14日以后的Pro请求真的在

00:27:58.700 --> 00:28:01.766
用户无感的情况下由Flash完成

00:28:02.100 --> 00:28:05.300
V4.1就会成为一次重要的架构转折

00:28:05.466 --> 00:28:06.800
如果质量回退

00:28:07.000 --> 00:28:09.933
长任务失控或视觉代理频繁犯错

00:28:09.966 --> 00:28:11.566
这次激进迁移也会

00:28:11.566 --> 00:28:13.000
暴露新架构的边界

00:28:13.400 --> 00:28:15.133
Deepseek把最强的承诺

00:28:15.133 --> 00:28:16.600
写进了路由系统

00:28:16.933 --> 00:28:19.733
宣传页面上的文字反倒居于其次

00:28:20.166 --> 00:28:22.700
便宜模型要接管昂贵模型的工作

00:28:22.866 --> 00:28:24.800
最终裁判不会是排行榜

00:28:25.133 --> 00:28:27.000
裁判是每一次完成的任务

00:28:27.066 --> 00:28:28.600
每一笔实际账单

00:28:28.666 --> 00:28:31.566
以及企业敢不敢把关键流程交给他