1
00:00:00,000 --> 00:00:23,400
大家好,歡迎來到新視頻。開始之前,我也想告訴大家,Deepseek的Harness也有新更新。我會在另一個頻道,ARC King上講。Deepseek V41 Flash現在已經正式發布了。

2
00:00:23,400 --> 00:00:31,380
经过我用正确的Thinking设置测试后

3
00:00:31,380 --> 00:00:38,620
我觉得这个模型真的很强

4
00:00:38,620 --> 00:00:42,960
另外还有一份技术报告

5
00:00:42,960 --> 00:00:45,940
解释DC是怎么让这个模型更高效的

6
00:00:45,940 --> 00:00:47,760
先看看到底新在哪

7
00:00:47,760 --> 00:00:50,720
然后我会给你看这些生成结果

8
00:00:50,720 --> 00:00:53,860
以及我给这些分数背后的代码

9
00:00:53,860 --> 00:00:59,440
Deep C把Flash称作新架构家族里最小的模型

10
00:00:59,440 --> 00:01:04,240
但报告里写的是

11
00:01:04,240 --> 00:01:08,000
它的主干是一个5520亿参数的Mix of Experts

12
00:01:08,000 --> 00:01:11,180
再加上1960亿参数的Ingram Memory Modules

13
00:01:11,180 --> 00:01:12,980
它还是个巨大的模型

14
00:01:12,980 --> 00:01:15,900
真正有意思的是它实际激活了多少参数

15
00:01:15,900 --> 00:01:18,300
处理输入时大约激活80亿参数

16
00:01:18,300 --> 00:01:20,140
生成输出时则是160亿

17
00:01:20,720 --> 00:01:22,580
新的英国编码器解码器设计

18
00:01:22,580 --> 00:01:26,140
让大多数输入token可以跳过完整的decoder计算

19
00:01:26,140 --> 00:01:27,380
这很重要

20
00:01:27,380 --> 00:01:29,720
因为coding agents会花很多时间读文件

21
00:01:29,720 --> 00:01:31,080
看工具结果

22
00:01:31,080 --> 00:01:32,120
还有对话历史

23
00:01:32,120 --> 00:01:33,480
Deepsea还表示

24
00:01:33,480 --> 00:01:35,020
在相同工作负载下

25
00:01:35,020 --> 00:01:38,200
Global Attention Cache的GPU显存用量

26
00:01:38,200 --> 00:01:39,960
大约只有上一代的四分之一

27
00:01:39,960 --> 00:01:43,500
Persistent Cache的存储占用只有八分之一

28
00:01:43,500 --> 00:01:46,600
这些节省都适用于缓存的上下文

29
00:01:46,600 --> 00:01:49,220
它们有助于解释更低的服务成本

30
00:01:49,220 --> 00:01:52,760
但并不意味着整个模型一下子变小了

31
00:01:52,760 --> 00:01:54,040
原生视觉理解意味着

32
00:01:54,040 --> 00:01:56,080
你可以把图片和文字一起发过去

33
00:01:56,080 --> 00:01:57,580
收到文字回复

34
00:01:57,580 --> 00:02:00,500
我这里的测试主要是看它在文本提示下

35
00:02:00,500 --> 00:02:01,400
写代码的能力

36
00:02:01,400 --> 00:02:04,160
所以视觉能力算是这次发布的一部分

37
00:02:04,160 --> 00:02:05,960
而不是我在这个视频里

38
00:02:05,960 --> 00:02:07,500
专门做过基准测试的内容

39
00:02:07,500 --> 00:02:09,860
官方公布的结果也挺有说服力

40
00:02:09,860 --> 00:02:14,020
DeepSeek报告的DeepSW1.1成绩是74.2

41
00:02:14,020 --> 00:02:16,700
而V4 Pro是62.7

42
00:02:16,700 --> 00:02:20,120
这里说的是他们在最高投入下的结果

43
00:02:20,120 --> 00:02:22,500
在一些更难的基准测试上

44
00:02:22,500 --> 00:02:23,900
其他模型还是领先

45
00:02:23,900 --> 00:02:25,640
而且报告也显示

46
00:02:25,640 --> 00:02:28,860
围绕模型的agent软件会影响最终分数

47
00:02:28,860 --> 00:02:32,080
所以我想看看它在开源代码里能做什么

48
00:02:32,080 --> 00:02:32,780
现在

49
00:02:32,780 --> 00:02:34,920
我得纠正一下我最初的印象

50
00:02:34,920 --> 00:02:37,600
我原来那篇开源代码模型的条目里

51
00:02:37,600 --> 00:02:39,360
Thinking是被禁用的

52
00:02:39,360 --> 00:02:41,300
我一开始怀疑这是回退了

53
00:02:41,300 --> 00:02:41,580
不过

54
00:02:41,580 --> 00:02:44,380
开启Thinking并把effort调到最高后

55
00:02:44,380 --> 00:02:48,500
分数从53.75提升到了81.25%

56
00:02:48,500 --> 00:02:50,580
保存的绘画里有大量推理输出

57
00:02:50,580 --> 00:02:52,300
生成结果也明显更好了

58
00:02:52,300 --> 00:02:54,860
这些测试是在今天发布前

59
00:02:54,860 --> 00:02:56,740
使用临时的API模型跑的

60
00:02:56,740 --> 00:02:59,300
我还没有用新的正式版模型名

61
00:02:59,300 --> 00:03:00,500
重新跑一遍套件

62
00:03:00,500 --> 00:03:03,140
这些是我上手预览的结果

63
00:03:03,140 --> 00:03:04,840
外加官方发布信息

64
00:03:04,840 --> 00:03:06,860
我没有证据表明

65
00:03:06,860 --> 00:03:09,780
DIPS在第一轮偷偷用了一个更弱的版本

66
00:03:09,780 --> 00:03:12,240
Teambench 3有8个任务

67
00:03:12,240 --> 00:03:13,540
每个任务10分

68
00:03:14,380 --> 00:03:21,640
这是我的实际评分,我还打开了生成出来的界面,检查了代码并保留了原始输出,那我们直接开始。

69
00:03:22,360 --> 00:03:26,360
首先是电梯模拟,这里应该有三部电梯,每部在一个人。

70
00:03:27,160 --> 00:03:36,480
人们在不同楼层等待,乘坐空闲的电梯,前往各自的目的地,把鼠标悬停上去时,应该能显示他们想去哪里。

71
00:03:37,000 --> 00:03:40,540
看新的结果,楼洞布局很清楚,三部电梯警都显示出来了。

72
00:03:40,540 --> 00:03:42,720
乘客也在各自楼层排队

73
00:03:42,720 --> 00:03:44,680
你可以看到人们上车的过程

74
00:03:44,680 --> 00:03:46,900
还能看到等待运行中和

75
00:03:46,900 --> 00:03:48,140
以到达的技术在更新

76
00:03:48,140 --> 00:03:49,900
在浏览器里检查时

77
00:03:49,900 --> 00:03:51,520
生成了两批个24个人

78
00:03:51,520 --> 00:03:53,360
两批加起来数量都对

79
00:03:53,360 --> 00:03:55,340
48名乘客全部到达

80
00:03:55,340 --> 00:03:57,840
而且任何时候都没有一部轿箱

81
00:03:57,840 --> 00:03:59,260
同时在超过一个人

82
00:03:59,260 --> 00:04:00,460
技术器

83
00:04:00,460 --> 00:04:02,900
在这次运行里也一直保持一致

84
00:04:02,900 --> 00:04:03,580
之前

85
00:04:03,580 --> 00:04:05,680
舱室会消失在屏幕外

86
00:04:05,680 --> 00:04:07,280
人也会被画到错误的位置

87
00:04:07,280 --> 00:04:10,120
新代码还会清理已经完成的乘客元素

88
00:04:10,540 --> 00:04:12,080
这对重复使用很有帮助

89
00:04:12,080 --> 00:04:14,100
现在还有一个重置边缘情况

90
00:04:14,100 --> 00:04:15,880
如果你在错开的生成

91
00:04:15,880 --> 00:04:17,280
还在进行式清空模拟

92
00:04:17,280 --> 00:04:19,980
之后可能还会出现一些带处理的乘客

93
00:04:19,980 --> 00:04:22,620
但主要模拟已经能正常工作了

94
00:04:22,620 --> 00:04:25,140
这部分从三分提升到了十分里的八分

95
00:04:25,140 --> 00:04:27,340
第二个任务是隐形眼镜盒

96
00:04:27,340 --> 00:04:28,900
我想要一个3D物体

97
00:04:28,900 --> 00:04:30,640
L和耳标时要很明显

98
00:04:30,640 --> 00:04:31,780
盖子点击后能打开

99
00:04:31,780 --> 00:04:33,660
这个版本就可信多了

100
00:04:33,660 --> 00:04:35,480
现在有一个干净的白色和尘

101
00:04:35,480 --> 00:04:36,860
薄荷绿的盖子

102
00:04:36,860 --> 00:04:38,720
还有大号清晰可读的字母

103
00:04:38,720 --> 00:04:40,640
两个盖子可以分别打开

104
00:04:40,640 --> 00:04:43,900
而且两个都打开按钮也确实如字面所示

105
00:04:43,900 --> 00:04:45,820
你也可以再把它们关上

106
00:04:45,820 --> 00:04:47,800
然后旋转这个物体来查看

107
00:04:47,800 --> 00:04:49,420
之前的版本还有

108
00:04:49,420 --> 00:04:50,920
字母有些破碎

109
00:04:50,920 --> 00:04:54,080
但在盖子下面能看到一个看起来很实的表面

110
00:04:54,080 --> 00:04:56,580
这里的结构是围绕脚链组织的

111
00:04:56,580 --> 00:04:57,880
所以动作逻辑就对了

112
00:04:57,880 --> 00:05:00,220
虽然内部空间看起来还是有点浅

113
00:05:00,220 --> 00:05:03,820
而且默认镜头在盖子完全打开时会把边缘裁掉

114
00:05:03,820 --> 00:05:05,840
所以还需要再打磨一下

115
00:05:05,840 --> 00:05:08,120
但这已经比提示词的理解好多了

116
00:05:08,120 --> 00:05:09,800
七分原来只有五分

117
00:05:09,800 --> 00:05:11,380
接下来是折叠桌

118
00:05:11,380 --> 00:05:14,760
这在第一次生成时是最明显的失败之一

119
00:05:14,760 --> 00:05:16,740
因为桌面是飘着的

120
00:05:16,740 --> 00:05:17,980
桌腿还埋在地下

121
00:05:17,980 --> 00:05:20,900
这次展开后的桌子稳稳地立着

122
00:05:20,900 --> 00:05:22,140
能看到四条腿

123
00:05:22,140 --> 00:05:23,820
木质表面也不错

124
00:05:23,820 --> 00:05:25,260
滑块反应很顺

125
00:05:25,260 --> 00:05:28,840
折叠部件也能作为一个整体保持在一起

126
00:05:28,840 --> 00:05:31,800
看看这两个结果的差别就知道了

127
00:05:31,800 --> 00:05:35,500
这段代码把腿连接到了合适的运动部件上

128
00:05:35,500 --> 00:05:37,640
解决了前面那个核心问题

129
00:05:38,120 --> 00:05:40,720
不过在完全折叠的状态下还是会扣分

130
00:05:40,720 --> 00:05:44,260
腿部横杆会和叠在一起的桌面板块相交

131
00:05:44,260 --> 00:05:48,400
所以整个机构并没有从头到尾都做到物理上干净

132
00:05:48,400 --> 00:05:50,520
我给它六分 满分十分

133
00:05:50,520 --> 00:05:51,760
它确实有进步

134
00:05:51,760 --> 00:05:55,480
但也很能说明模型还有哪些地方需要继续检查

135
00:05:55,480 --> 00:05:58,340
第四个任务是熊猫吃汉堡的SVG

136
00:05:58,340 --> 00:05:59,980
这个版本构图更干净

137
00:05:59,980 --> 00:06:02,760
表情也更生动 汉堡的层次还挺清楚

138
00:06:02,760 --> 00:06:05,380
爪子和一点点碎屑也增加了些趣味

139
00:06:05,380 --> 00:06:06,520
它是一幅锦凑

140
00:06:06,520 --> 00:06:07,900
完整的插画

141
00:06:07,900 --> 00:06:09,280
而且渲染的也正确

142
00:06:09,280 --> 00:06:11,200
剩下的问题是动作表现

143
00:06:11,200 --> 00:06:13,300
看起来更像熊猫抱着汉堡

144
00:06:13,300 --> 00:06:14,320
而不是在咬它

145
00:06:14,320 --> 00:06:16,580
所以我更喜欢这张插画

146
00:06:16,580 --> 00:06:18,740
但它还没有完全抓住那个动作

147
00:06:18,740 --> 00:06:20,540
这个提示词打了六分

148
00:06:20,540 --> 00:06:21,340
之前是五分

149
00:06:21,340 --> 00:06:22,880
现在这个弓箭游戏

150
00:06:22,880 --> 00:06:24,660
在视觉上是最明显的提升之一

151
00:06:24,660 --> 00:06:26,540
我们有日落场景

152
00:06:26,540 --> 00:06:27,900
背景里的群山

153
00:06:27,900 --> 00:06:29,060
一个弓箭手

154
00:06:29,060 --> 00:06:30,020
四个目标

155
00:06:30,020 --> 00:06:32,700
还有一个清晰的计时器

156
00:06:32,700 --> 00:06:34,580
拖动瞄准在松手

157
00:06:34,580 --> 00:06:37,680
感觉更像真正的射箭游戏了

158
00:06:37,680 --> 00:06:40,020
核心射击流程是通的

159
00:06:40,020 --> 00:06:42,280
在浏览器检查里

160
00:06:42,280 --> 00:06:44,400
四只箭都命中了四个目标

161
00:06:44,400 --> 00:06:47,360
目标被击中后也倒下了

162
00:06:47,360 --> 00:06:48,780
游戏内计时期显示

163
00:06:48,780 --> 00:06:51,440
这一轮四箭用了6.10秒

164
00:06:51,440 --> 00:06:53,500
这说的是游戏玩法表现

165
00:06:53,500 --> 00:06:56,540
和模型生成游戏所花的时间是分开的

166
00:06:56,540 --> 00:06:58,460
我的评分表上这是8分

167
00:06:58,460 --> 00:06:59,840
比之前的5分高了不少

168
00:06:59,840 --> 00:07:01,940
不过代码审查也发现了一个

169
00:07:01,940 --> 00:07:03,020
我必须说明的bug

170
00:07:03,020 --> 00:07:05,400
这样就不会弹出结果页面了

171
00:07:05,400 --> 00:07:06,980
所以在纳斯检查里

172
00:07:06,980 --> 00:07:08,540
分数没能保存

173
00:07:08,540 --> 00:07:10,840
射击分为合命中反馈都不错

174
00:07:10,840 --> 00:07:12,780
但完成流程还需要修

175
00:07:12,780 --> 00:07:14,820
这也是为什么不能只看低评

176
00:07:14,820 --> 00:07:17,640
第六个任务是那个数学题

177
00:07:17,640 --> 00:07:20,080
考的是在受限移动条件下

178
00:07:20,080 --> 00:07:22,560
统计有序对的排列数

179
00:07:22,560 --> 00:07:25,120
预期答案是20460

180
00:07:25,120 --> 00:07:27,240
这次保存的绘画里

181
00:07:27,240 --> 00:07:28,540
最终答案很清楚

182
00:07:28,540 --> 00:07:29,460
而且是对的

183
00:07:29,460 --> 00:07:31,880
还有一个SOVER可以再跑一遍

184
00:07:31,880 --> 00:07:33,240
我又跑了一次

185
00:07:33,240 --> 00:07:35,600
结果得到了20460

186
00:07:35,600 --> 00:07:39,760
而且和他检查过的小样本上的暴力枚举结果一致

187
00:07:39,760 --> 00:07:43,580
模型发现了自己最初转移逻辑里的一个错误

188
00:07:43,580 --> 00:07:45,440
把它改正了

189
00:07:45,440 --> 00:07:48,700
还先拿小规模暴力样例验证了修正后的算法

190
00:07:48,700 --> 00:07:50,720
然后才给出最终答案

191
00:07:50,720 --> 00:07:52,720
这种解题行为非常有用

192
00:07:52,720 --> 00:07:55,040
所以这是十分里的十分

193
00:07:55,740 --> 00:07:59,440
现在还有一条更清晰的证据链来支持这个结果

194
00:08:12,109 --> 00:08:15,909
这个项目里有一个完成了700次迭代的LORA训练

195
00:08:15,909 --> 00:08:17,409
保持了Adductors

196
00:08:17,409 --> 00:08:19,669
还有一个能正常运行的本地应用

197
00:08:19,669 --> 00:08:22,629
数据集里有151条人工编写的事实

198
00:08:22,629 --> 00:08:24,249
之前版本只有127条

199
00:08:24,249 --> 00:08:26,069
服务方式也更简单了

200
00:08:26,069 --> 00:08:28,889
模型和Adductors通过MLX直接加载

201
00:08:28,889 --> 00:08:31,409
并使用Tokenizer的Chat Template

202
00:08:31,409 --> 00:08:33,689
这样就去掉了上一个方案里

203
00:08:33,689 --> 00:08:35,489
额外的导出步骤和手写模板层

204
00:08:35,489 --> 00:08:36,929
界面也挺好看

205
00:08:36,929 --> 00:08:38,529
有一张简单的Panda插画

206
00:08:38,529 --> 00:08:40,349
一个清晰的事实卡片

207
00:08:40,349 --> 00:08:42,169
还有一个生成新试试的按钮

208
00:08:42,169 --> 00:08:45,129
布局在手机上也能正常显示

209
00:08:45,129 --> 00:08:47,529
刷新页面和点击按钮

210
00:08:47,529 --> 00:08:50,069
都可以生成新的内容

211
00:08:50,069 --> 00:08:53,269
在评审过程中模型产生了回复

212
00:08:53,269 --> 00:08:55,449
五个样本身程度很干净

213
00:08:55,449 --> 00:08:57,369
是完整的单据

214
00:08:57,369 --> 00:09:00,229
没有我们之前看到的那些多余标记

215
00:09:00,229 --> 00:09:03,349
两次本地直连请求各花了大约半秒

216
00:09:03,349 --> 00:09:06,049
这是本地微调后的GEM模型在回答

217
00:09:06,049 --> 00:09:08,709
和DeepSeek的API生成速度是分开的

218
00:09:08,709 --> 00:09:10,349
我把这个任务打了10分

219
00:09:10,349 --> 00:09:11,449
比之前的6分高

220
00:09:11,449 --> 00:09:12,909
不过还是要说明

221
00:09:12,909 --> 00:09:14,509
数据质量仍然有一些限制

222
00:09:14,509 --> 00:09:15,869
所有验证答案

223
00:09:15,869 --> 00:09:17,429
其实都已经出现在训练集中

224
00:09:17,429 --> 00:09:19,509
测试文件是复制的训练性

225
00:09:19,509 --> 00:09:22,349
而且有些人工编写的事实并不准确

226
00:09:22,349 --> 00:09:23,649
在评审过程中

227
00:09:23,649 --> 00:09:25,729
Refresh还重复了一条事实

228
00:09:25,729 --> 00:09:27,849
所以完成整个工作流

229
00:09:27,849 --> 00:09:29,329
并不能说明

230
00:09:29,329 --> 00:09:31,729
每个生成出来的Panda结果都可靠

231
00:09:31,729 --> 00:09:34,629
但能把训练和本地应用这样跑通

232
00:09:34,629 --> 00:09:35,749
还是很厉害的

233
00:09:35,749 --> 00:09:37,509
最后是这只手表

234
00:09:37,509 --> 00:09:39,829
这大概是我改观的最佳视觉证明

235
00:09:39,829 --> 00:09:42,529
第一版的表盘还是一整块金色表面

236
00:09:42,529 --> 00:09:44,669
现在有了更细致的表盘

237
00:09:44,669 --> 00:09:46,289
清晰的指标金属表带

238
00:09:46,289 --> 00:09:48,329
能读的星期和日期窗口

239
00:09:48,329 --> 00:09:49,189
汇动的指针

240
00:09:49,189 --> 00:09:51,409
还有一个第二时区的小表盘

241
00:09:51,409 --> 00:09:53,349
整体观感精致多了

242
00:09:53,349 --> 00:09:54,329
交互也没问题

243
00:09:54,329 --> 00:09:56,569
你可以选两个时区互相切换

244
00:09:56,569 --> 00:09:58,409
开关星期和日期显示

245
00:09:58,409 --> 00:10:00,289
还能在扫秒和跳秒之间切换

246
00:10:00,289 --> 00:10:02,149
控制检查也通过了

247
00:10:02,149 --> 00:10:05,169
说明设计下面那些关键部分也没问题

248
00:10:05,169 --> 00:10:08,089
指针在午夜时能准确对齐

249
00:10:08,089 --> 00:10:10,469
梦买的半小时偏一夜

250
00:10:10,469 --> 00:10:11,969
有效了

251
00:10:11,969 --> 00:10:13,829
纽约的下令时切换也正常

252
00:10:13,829 --> 00:10:16,469
第二个时区能正确滚到第二天

253
00:10:16,469 --> 00:10:18,949
代码还附用了时间格式画起

254
00:10:18,949 --> 00:10:22,169
避免像旧版本那样每一针都重复创建

255
00:10:22,169 --> 00:10:25,649
视觉结构和时钟逻辑终于配合起来了

256
00:10:25,649 --> 00:10:28,089
我真的很喜欢这个结果

257
00:10:28,089 --> 00:10:30,289
它从四分涨到了十分

258
00:10:30,289 --> 00:10:32,489
是复册里提升最大的一个

259
00:10:32,489 --> 00:10:35,069
现在我们来看最后的图表

260
00:10:35,069 --> 00:10:36,489
电梯8分

261
00:10:36,489 --> 00:10:37,769
隐形眼镜和7分

262
00:10:37,769 --> 00:10:38,509
桌子6分

263
00:10:38,509 --> 00:10:39,469
SVG6分

264
00:10:39,469 --> 00:10:40,269
射简8分

265
00:10:40,269 --> 00:10:41,489
数学

266
00:10:41,489 --> 00:10:44,169
Fine Tuning Workflow和手表都是10分

267
00:10:44,169 --> 00:10:45,909
总分是65分

268
00:10:45,909 --> 00:10:46,749
满分80分

269
00:10:46,749 --> 00:10:48,349
也就是81.25%

270
00:10:48,349 --> 00:10:51,309
不开启思考时的成绩是80分里的43分

271
00:10:51,309 --> 00:10:53,549
修正配置并重新跑任务后

272
00:10:53,549 --> 00:10:54,909
我们竟提升了22分

273
00:10:54,909 --> 00:10:56,989
也就是27.5个百分点

274
00:10:56,989 --> 00:11:00,589
这个新分数也高于我之前V4Flash的72.5%

275
00:11:00,589 --> 00:11:03,349
以及V4Pro条目的76.25%

276
00:11:03,349 --> 00:11:04,989
它在这个排行榜上

277
00:11:04,989 --> 00:11:06,689
和Gemina3.8Flash打平

278
00:11:06,689 --> 00:11:07,689
只比Open4

279
00:11:07,689 --> 00:11:09,729
8的80%高一点

280
00:11:09,729 --> 00:11:11,369
虽然没排到总榜第一

281
00:11:11,369 --> 00:11:14,549
但这个结果已经非常有竞争力了

282
00:11:14,549 --> 00:11:15,649
再说速度

283
00:11:15,649 --> 00:11:17,009
我看了OpenCode日志

284
00:11:17,009 --> 00:11:19,489
它为这个新的测试文件夹

285
00:11:19,489 --> 00:11:20,769
保存了绘画记录

286
00:11:20,769 --> 00:11:23,449
共有64条已完成的模型回复

287
00:11:23,449 --> 00:11:25,989
有可用的Token数和时间记录

288
00:11:25,989 --> 00:11:27,489
像绘画标题

289
00:11:27,489 --> 00:11:29,289
这类后台调用都被排除了

290
00:11:29,289 --> 00:11:30,989
另外还排除了一条

291
00:11:30,989 --> 00:11:32,809
没完成的Restorch回复

292
00:11:32,809 --> 00:11:34,829
在这些已完成的回复里

293
00:11:34,829 --> 00:11:37,549
一共生成了364574个Token

294
00:11:37,549 --> 00:11:40,469
大约294000个是Risning Tokens

295
00:11:40,469 --> 00:11:41,489
另外大约70

296
00:11:41,489 --> 00:11:44,209
000个是正常生成的Token

297
00:11:44,209 --> 00:11:48,049
包括Code2调用参数和答案等其他输出

298
00:11:48,049 --> 00:11:48,949
所以

299
00:11:48,949 --> 00:11:52,809
这次生成的Token大多都用在了思考上

300
00:11:52,809 --> 00:11:55,569
这两个数字都包含了Risning

301
00:11:55,569 --> 00:11:58,049
它们是根据OpenCode的时间

302
00:11:58,049 --> 00:11:59,709
戳重建出来的估算值

303
00:11:59,709 --> 00:12:02,729
它们不包括后面执行工具花的时间

304
00:12:02,729 --> 00:12:05,549
也不是服务器内部解码速度的精确测量

305
00:12:05,549 --> 00:12:07,809
我把每次响应的时长加总了

306
00:12:07,809 --> 00:12:09,029
所以同时跑多个任务

307
00:12:09,029 --> 00:12:11,369
不会把单次响应速率认为太高

308
00:12:11,369 --> 00:12:13,109
我觉得这很厉害

309
00:12:13,109 --> 00:12:14,909
他一边处理多个任务

310
00:12:14,909 --> 00:12:17,629
一边花了几万tokens做listening

311
00:12:17,629 --> 00:12:20,849
同时还能保持很高的生成速度

312
00:12:20,849 --> 00:12:24,349
完整任务耗时能让你从另一个角度来看

313
00:12:24,349 --> 00:12:27,509
电梯任务大概花了4分20秒

314
00:12:27,509 --> 00:12:29,589
SVG任务大约11秒

315
00:12:29,589 --> 00:12:32,889
本地翻桌的流程大约花了11分38秒

316
00:12:32,889 --> 00:12:35,769
包括搭建环境训练和检查APP的时间

317
00:12:35,769 --> 00:12:40,029
所以最高强度的思考可能意味着成品要等更久

318
00:12:40,029 --> 00:12:41,429
在这次附色里

319
00:12:41,429 --> 00:12:43,829
这些额外的工作带来了结果的大幅提升

320
00:12:43,829 --> 00:12:45,509
这个取舍我很满意

321
00:12:45,509 --> 00:12:48,629
现在API价格已经上线了

322
00:12:48,629 --> 00:12:49,649
非高峰时段

323
00:12:49,649 --> 00:12:52,769
每百万未缓存输入token15美分

324
00:12:52,769 --> 00:12:55,409
每百万输出token60美分

325
00:12:55,409 --> 00:12:57,909
高峰时段输入是30美分

326
00:12:57,909 --> 00:12:59,689
输出是1.2美元

327
00:12:59,689 --> 00:13:03,189
缓存输入在非高峰时段每百万Token

328
00:13:03,189 --> 00:13:04,589
只要0.3美分

329
00:13:04,589 --> 00:13:06,789
高峰时段价格翻倍

330
00:13:06,789 --> 00:13:09,629
我会把当前的价格表面接放在下面

331
00:13:09,629 --> 00:13:12,149
要使用这个已发布的模型

332
00:13:12,149 --> 00:13:15,249
请选择DeepSeek API地址

333
00:13:15,249 --> 00:13:19,149
DeepSeek在支持的工具里列出了OpenCode

334
00:13:19,149 --> 00:13:21,129
记得把Thinking打开

335
00:13:21,129 --> 00:13:22,709
并把Efford设为Max

336
00:13:22,709 --> 00:13:25,469
如果你想看这次回测用的配置

337
00:13:25,469 --> 00:13:27,869
旧的V4 Flash模型已经退役了

338
00:13:27,869 --> 00:13:30,449
API名字会临时录游到V4.1 Flash

339
00:13:30,449 --> 00:13:35,429
V4 Pro的请求会在9月14日UTC凌晨4点开始按Flash价格录游到V4

340
00:13:35,429 --> 00:13:37,809
E Flash直到V4.1 Pro发布

341
00:13:37,809 --> 00:13:39,829
如果你依赖Pro模型名

342
00:13:39,829 --> 00:13:41,389
这个时间点就很重要

343
00:13:41,389 --> 00:13:45,109
Rizni也会消耗可计费的Output Tokens

344
00:13:45,109 --> 00:13:49,389
所以即使把Effort设到最高还是会有成本

345
00:13:49,389 --> 00:13:54,089
不过结合这个定价实测速度和81.25%的结果V4

346
00:13:54,089 --> 00:13:57,249
E Flash还是一个很有吸引力的编程选择

347
00:13:57,869 --> 00:14:00,629
DeepSea还分享了技术报告和模型仓库

348
00:14:00,629 --> 00:14:02,349
并表示他正在于

349
00:14:02,349 --> 00:14:05,229
开源社区在推理支持和部署选项方面

350
00:14:05,229 --> 00:14:07,429
我的看法有了很大变化

351
00:14:07,429 --> 00:14:09,469
因为Max开启了Thinking Mode

352
00:14:09,469 --> 00:14:12,529
这个模型在我的测试里表现得非常不错

353
00:14:12,529 --> 00:14:15,149
尤其是在万表和本地模型工作流上

354
00:14:15,149 --> 00:14:17,169
电梯案例也很清楚地说明

355
00:14:17,169 --> 00:14:18,649
改进不只是界面更好看

356
00:14:18,649 --> 00:14:20,829
不过还有一些bug要处理

357
00:14:20,829 --> 00:14:22,989
表格和SVG的分数较低

358
00:14:22,989 --> 00:14:25,509
说明他并不是每个任务都一样强

359
00:14:25,509 --> 00:14:27,949
但我还是会非常愿意重新看看

360
00:14:27,949 --> 00:14:29,209
他在编码上的表现

361
00:14:29,209 --> 00:14:31,789
配置错误让第一次印象不太公平

362
00:14:31,789 --> 00:14:34,349
这次复色让我们看到了更真实的情况

363
00:14:34,349 --> 00:14:36,289
总体来说挺酷的

364
00:14:36,289 --> 00:14:37,009
总之

365
00:14:37,009 --> 00:14:39,589
欢迎在评论区告诉我你的想法

366
00:14:39,589 --> 00:14:41,569
如果你喜欢这个视频

367
00:14:41,569 --> 00:14:43,129
可以通过Super Thanks打赏

368
00:14:43,129 --> 00:14:45,529
或者点击中按钮成为会员

369
00:14:45,529 --> 00:14:46,369
另外

370
00:14:46,369 --> 00:14:47,729
给这个视频点个赞

371
00:14:47,729 --> 00:14:48,949
订阅我的频道

372
00:14:48,949 --> 00:14:50,489
我们下期见

373
00:14:50,489 --> 00:14:51,009
拜拜