WEBVTT

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

00:00:23.400 --> 00:00:31.380
经过我用正确的Thinking设置测试后

00:00:31.380 --> 00:00:38.620
我觉得这个模型真的很强

00:00:38.620 --> 00:00:42.960
另外还有一份技术报告

00:00:42.960 --> 00:00:45.940
解释DC是怎么让这个模型更高效的

00:00:45.940 --> 00:00:47.760
先看看到底新在哪

00:00:47.760 --> 00:00:50.720
然后我会给你看这些生成结果

00:00:50.720 --> 00:00:53.860
以及我给这些分数背后的代码

00:00:53.860 --> 00:00:59.440
Deep C把Flash称作新架构家族里最小的模型

00:00:59.440 --> 00:01:04.240
但报告里写的是

00:01:04.240 --> 00:01:08.000
它的主干是一个5520亿参数的Mix of Experts

00:01:08.000 --> 00:01:11.180
再加上1960亿参数的Ingram Memory Modules

00:01:11.180 --> 00:01:12.980
它还是个巨大的模型

00:01:12.980 --> 00:01:15.900
真正有意思的是它实际激活了多少参数

00:01:15.900 --> 00:01:18.300
处理输入时大约激活80亿参数

00:01:18.300 --> 00:01:20.140
生成输出时则是160亿

00:01:20.720 --> 00:01:22.580
新的英国编码器解码器设计

00:01:22.580 --> 00:01:26.140
让大多数输入token可以跳过完整的decoder计算

00:01:26.140 --> 00:01:27.380
这很重要

00:01:27.380 --> 00:01:29.720
因为coding agents会花很多时间读文件

00:01:29.720 --> 00:01:31.080
看工具结果

00:01:31.080 --> 00:01:32.120
还有对话历史

00:01:32.120 --> 00:01:33.480
Deepsea还表示

00:01:33.480 --> 00:01:35.020
在相同工作负载下

00:01:35.020 --> 00:01:38.200
Global Attention Cache的GPU显存用量

00:01:38.200 --> 00:01:39.960
大约只有上一代的四分之一

00:01:39.960 --> 00:01:43.500
Persistent Cache的存储占用只有八分之一

00:01:43.500 --> 00:01:46.600
这些节省都适用于缓存的上下文

00:01:46.600 --> 00:01:49.220
它们有助于解释更低的服务成本

00:01:49.220 --> 00:01:52.760
但并不意味着整个模型一下子变小了

00:01:52.760 --> 00:01:54.040
原生视觉理解意味着

00:01:54.040 --> 00:01:56.080
你可以把图片和文字一起发过去

00:01:56.080 --> 00:01:57.580
收到文字回复

00:01:57.580 --> 00:02:00.500
我这里的测试主要是看它在文本提示下

00:02:00.500 --> 00:02:01.400
写代码的能力

00:02:01.400 --> 00:02:04.160
所以视觉能力算是这次发布的一部分

00:02:04.160 --> 00:02:05.960
而不是我在这个视频里

00:02:05.960 --> 00:02:07.500
专门做过基准测试的内容

00:02:07.500 --> 00:02:09.860
官方公布的结果也挺有说服力

00:02:09.860 --> 00:02:14.020
DeepSeek报告的DeepSW1.1成绩是74.2

00:02:14.020 --> 00:02:16.700
而V4 Pro是62.7

00:02:16.700 --> 00:02:20.120
这里说的是他们在最高投入下的结果

00:02:20.120 --> 00:02:22.500
在一些更难的基准测试上

00:02:22.500 --> 00:02:23.900
其他模型还是领先

00:02:23.900 --> 00:02:25.640
而且报告也显示

00:02:25.640 --> 00:02:28.860
围绕模型的agent软件会影响最终分数

00:02:28.860 --> 00:02:32.080
所以我想看看它在开源代码里能做什么

00:02:32.080 --> 00:02:32.780
现在

00:02:32.780 --> 00:02:34.920
我得纠正一下我最初的印象

00:02:34.920 --> 00:02:37.600
我原来那篇开源代码模型的条目里

00:02:37.600 --> 00:02:39.360
Thinking是被禁用的

00:02:39.360 --> 00:02:41.300
我一开始怀疑这是回退了

00:02:41.300 --> 00:02:41.580
不过

00:02:41.580 --> 00:02:44.380
开启Thinking并把effort调到最高后

00:02:44.380 --> 00:02:48.500
分数从53.75提升到了81.25%

00:02:48.500 --> 00:02:50.580
保存的绘画里有大量推理输出

00:02:50.580 --> 00:02:52.300
生成结果也明显更好了

00:02:52.300 --> 00:02:54.860
这些测试是在今天发布前

00:02:54.860 --> 00:02:56.740
使用临时的API模型跑的

00:02:56.740 --> 00:02:59.300
我还没有用新的正式版模型名

00:02:59.300 --> 00:03:00.500
重新跑一遍套件

00:03:00.500 --> 00:03:03.140
这些是我上手预览的结果

00:03:03.140 --> 00:03:04.840
外加官方发布信息

00:03:04.840 --> 00:03:06.860
我没有证据表明

00:03:06.860 --> 00:03:09.780
DIPS在第一轮偷偷用了一个更弱的版本

00:03:09.780 --> 00:03:12.240
Teambench 3有8个任务

00:03:12.240 --> 00:03:13.540
每个任务10分

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

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

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

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

00:03:40.540 --> 00:03:42.720
乘客也在各自楼层排队

00:03:42.720 --> 00:03:44.680
你可以看到人们上车的过程

00:03:44.680 --> 00:03:46.900
还能看到等待运行中和

00:03:46.900 --> 00:03:48.140
以到达的技术在更新

00:03:48.140 --> 00:03:49.900
在浏览器里检查时

00:03:49.900 --> 00:03:51.520
生成了两批个24个人

00:03:51.520 --> 00:03:53.360
两批加起来数量都对

00:03:53.360 --> 00:03:55.340
48名乘客全部到达

00:03:55.340 --> 00:03:57.840
而且任何时候都没有一部轿箱

00:03:57.840 --> 00:03:59.260
同时在超过一个人

00:03:59.260 --> 00:04:00.460
技术器

00:04:00.460 --> 00:04:02.900
在这次运行里也一直保持一致

00:04:02.900 --> 00:04:03.580
之前

00:04:03.580 --> 00:04:05.680
舱室会消失在屏幕外

00:04:05.680 --> 00:04:07.280
人也会被画到错误的位置

00:04:07.280 --> 00:04:10.120
新代码还会清理已经完成的乘客元素

00:04:10.540 --> 00:04:12.080
这对重复使用很有帮助

00:04:12.080 --> 00:04:14.100
现在还有一个重置边缘情况

00:04:14.100 --> 00:04:15.880
如果你在错开的生成

00:04:15.880 --> 00:04:17.280
还在进行式清空模拟

00:04:17.280 --> 00:04:19.980
之后可能还会出现一些带处理的乘客

00:04:19.980 --> 00:04:22.620
但主要模拟已经能正常工作了

00:04:22.620 --> 00:04:25.140
这部分从三分提升到了十分里的八分

00:04:25.140 --> 00:04:27.340
第二个任务是隐形眼镜盒

00:04:27.340 --> 00:04:28.900
我想要一个3D物体

00:04:28.900 --> 00:04:30.640
L和耳标时要很明显

00:04:30.640 --> 00:04:31.780
盖子点击后能打开

00:04:31.780 --> 00:04:33.660
这个版本就可信多了

00:04:33.660 --> 00:04:35.480
现在有一个干净的白色和尘

00:04:35.480 --> 00:04:36.860
薄荷绿的盖子

00:04:36.860 --> 00:04:38.720
还有大号清晰可读的字母

00:04:38.720 --> 00:04:40.640
两个盖子可以分别打开

00:04:40.640 --> 00:04:43.900
而且两个都打开按钮也确实如字面所示

00:04:43.900 --> 00:04:45.820
你也可以再把它们关上

00:04:45.820 --> 00:04:47.800
然后旋转这个物体来查看

00:04:47.800 --> 00:04:49.420
之前的版本还有

00:04:49.420 --> 00:04:50.920
字母有些破碎

00:04:50.920 --> 00:04:54.080
但在盖子下面能看到一个看起来很实的表面

00:04:54.080 --> 00:04:56.580
这里的结构是围绕脚链组织的

00:04:56.580 --> 00:04:57.880
所以动作逻辑就对了

00:04:57.880 --> 00:05:00.220
虽然内部空间看起来还是有点浅

00:05:00.220 --> 00:05:03.820
而且默认镜头在盖子完全打开时会把边缘裁掉

00:05:03.820 --> 00:05:05.840
所以还需要再打磨一下

00:05:05.840 --> 00:05:08.120
但这已经比提示词的理解好多了

00:05:08.120 --> 00:05:09.800
七分原来只有五分

00:05:09.800 --> 00:05:11.380
接下来是折叠桌

00:05:11.380 --> 00:05:14.760
这在第一次生成时是最明显的失败之一

00:05:14.760 --> 00:05:16.740
因为桌面是飘着的

00:05:16.740 --> 00:05:17.980
桌腿还埋在地下

00:05:17.980 --> 00:05:20.900
这次展开后的桌子稳稳地立着

00:05:20.900 --> 00:05:22.140
能看到四条腿

00:05:22.140 --> 00:05:23.820
木质表面也不错

00:05:23.820 --> 00:05:25.260
滑块反应很顺

00:05:25.260 --> 00:05:28.840
折叠部件也能作为一个整体保持在一起

00:05:28.840 --> 00:05:31.800
看看这两个结果的差别就知道了

00:05:31.800 --> 00:05:35.500
这段代码把腿连接到了合适的运动部件上

00:05:35.500 --> 00:05:37.640
解决了前面那个核心问题

00:05:38.120 --> 00:05:40.720
不过在完全折叠的状态下还是会扣分

00:05:40.720 --> 00:05:44.260
腿部横杆会和叠在一起的桌面板块相交

00:05:44.260 --> 00:05:48.400
所以整个机构并没有从头到尾都做到物理上干净

00:05:48.400 --> 00:05:50.520
我给它六分 满分十分

00:05:50.520 --> 00:05:51.760
它确实有进步

00:05:51.760 --> 00:05:55.480
但也很能说明模型还有哪些地方需要继续检查

00:05:55.480 --> 00:05:58.340
第四个任务是熊猫吃汉堡的SVG

00:05:58.340 --> 00:05:59.980
这个版本构图更干净

00:05:59.980 --> 00:06:02.760
表情也更生动 汉堡的层次还挺清楚

00:06:02.760 --> 00:06:05.380
爪子和一点点碎屑也增加了些趣味

00:06:05.380 --> 00:06:06.520
它是一幅锦凑

00:06:06.520 --> 00:06:07.900
完整的插画

00:06:07.900 --> 00:06:09.280
而且渲染的也正确

00:06:09.280 --> 00:06:11.200
剩下的问题是动作表现

00:06:11.200 --> 00:06:13.300
看起来更像熊猫抱着汉堡

00:06:13.300 --> 00:06:14.320
而不是在咬它

00:06:14.320 --> 00:06:16.580
所以我更喜欢这张插画

00:06:16.580 --> 00:06:18.740
但它还没有完全抓住那个动作

00:06:18.740 --> 00:06:20.540
这个提示词打了六分

00:06:20.540 --> 00:06:21.340
之前是五分

00:06:21.340 --> 00:06:22.880
现在这个弓箭游戏

00:06:22.880 --> 00:06:24.660
在视觉上是最明显的提升之一

00:06:24.660 --> 00:06:26.540
我们有日落场景

00:06:26.540 --> 00:06:27.900
背景里的群山

00:06:27.900 --> 00:06:29.060
一个弓箭手

00:06:29.060 --> 00:06:30.020
四个目标

00:06:30.020 --> 00:06:32.700
还有一个清晰的计时器

00:06:32.700 --> 00:06:34.580
拖动瞄准在松手

00:06:34.580 --> 00:06:37.680
感觉更像真正的射箭游戏了

00:06:37.680 --> 00:06:40.020
核心射击流程是通的

00:06:40.020 --> 00:06:42.280
在浏览器检查里

00:06:42.280 --> 00:06:44.400
四只箭都命中了四个目标

00:06:44.400 --> 00:06:47.360
目标被击中后也倒下了

00:06:47.360 --> 00:06:48.780
游戏内计时期显示

00:06:48.780 --> 00:06:51.440
这一轮四箭用了6.10秒

00:06:51.440 --> 00:06:53.500
这说的是游戏玩法表现

00:06:53.500 --> 00:06:56.540
和模型生成游戏所花的时间是分开的

00:06:56.540 --> 00:06:58.460
我的评分表上这是8分

00:06:58.460 --> 00:06:59.840
比之前的5分高了不少

00:06:59.840 --> 00:07:01.940
不过代码审查也发现了一个

00:07:01.940 --> 00:07:03.020
我必须说明的bug

00:07:03.020 --> 00:07:05.400
这样就不会弹出结果页面了

00:07:05.400 --> 00:07:06.980
所以在纳斯检查里

00:07:06.980 --> 00:07:08.540
分数没能保存

00:07:08.540 --> 00:07:10.840
射击分为合命中反馈都不错

00:07:10.840 --> 00:07:12.780
但完成流程还需要修

00:07:12.780 --> 00:07:14.820
这也是为什么不能只看低评

00:07:14.820 --> 00:07:17.640
第六个任务是那个数学题

00:07:17.640 --> 00:07:20.080
考的是在受限移动条件下

00:07:20.080 --> 00:07:22.560
统计有序对的排列数

00:07:22.560 --> 00:07:25.120
预期答案是20460

00:07:25.120 --> 00:07:27.240
这次保存的绘画里

00:07:27.240 --> 00:07:28.540
最终答案很清楚

00:07:28.540 --> 00:07:29.460
而且是对的

00:07:29.460 --> 00:07:31.880
还有一个SOVER可以再跑一遍

00:07:31.880 --> 00:07:33.240
我又跑了一次

00:07:33.240 --> 00:07:35.600
结果得到了20460

00:07:35.600 --> 00:07:39.760
而且和他检查过的小样本上的暴力枚举结果一致

00:07:39.760 --> 00:07:43.580
模型发现了自己最初转移逻辑里的一个错误

00:07:43.580 --> 00:07:45.440
把它改正了

00:07:45.440 --> 00:07:48.700
还先拿小规模暴力样例验证了修正后的算法

00:07:48.700 --> 00:07:50.720
然后才给出最终答案

00:07:50.720 --> 00:07:52.720
这种解题行为非常有用

00:07:52.720 --> 00:07:55.040
所以这是十分里的十分

00:07:55.740 --> 00:07:59.440
现在还有一条更清晰的证据链来支持这个结果

00:08:12.109 --> 00:08:15.909
这个项目里有一个完成了700次迭代的LORA训练

00:08:15.909 --> 00:08:17.409
保持了Adductors

00:08:17.409 --> 00:08:19.669
还有一个能正常运行的本地应用

00:08:19.669 --> 00:08:22.629
数据集里有151条人工编写的事实

00:08:22.629 --> 00:08:24.249
之前版本只有127条

00:08:24.249 --> 00:08:26.069
服务方式也更简单了

00:08:26.069 --> 00:08:28.889
模型和Adductors通过MLX直接加载

00:08:28.889 --> 00:08:31.409
并使用Tokenizer的Chat Template

00:08:31.409 --> 00:08:33.689
这样就去掉了上一个方案里

00:08:33.689 --> 00:08:35.489
额外的导出步骤和手写模板层

00:08:35.489 --> 00:08:36.929
界面也挺好看

00:08:36.929 --> 00:08:38.529
有一张简单的Panda插画

00:08:38.529 --> 00:08:40.349
一个清晰的事实卡片

00:08:40.349 --> 00:08:42.169
还有一个生成新试试的按钮

00:08:42.169 --> 00:08:45.129
布局在手机上也能正常显示

00:08:45.129 --> 00:08:47.529
刷新页面和点击按钮

00:08:47.529 --> 00:08:50.069
都可以生成新的内容

00:08:50.069 --> 00:08:53.269
在评审过程中模型产生了回复

00:08:53.269 --> 00:08:55.449
五个样本身程度很干净

00:08:55.449 --> 00:08:57.369
是完整的单据

00:08:57.369 --> 00:09:00.229
没有我们之前看到的那些多余标记

00:09:00.229 --> 00:09:03.349
两次本地直连请求各花了大约半秒

00:09:03.349 --> 00:09:06.049
这是本地微调后的GEM模型在回答

00:09:06.049 --> 00:09:08.709
和DeepSeek的API生成速度是分开的

00:09:08.709 --> 00:09:10.349
我把这个任务打了10分

00:09:10.349 --> 00:09:11.449
比之前的6分高

00:09:11.449 --> 00:09:12.909
不过还是要说明

00:09:12.909 --> 00:09:14.509
数据质量仍然有一些限制

00:09:14.509 --> 00:09:15.869
所有验证答案

00:09:15.869 --> 00:09:17.429
其实都已经出现在训练集中

00:09:17.429 --> 00:09:19.509
测试文件是复制的训练性

00:09:19.509 --> 00:09:22.349
而且有些人工编写的事实并不准确

00:09:22.349 --> 00:09:23.649
在评审过程中

00:09:23.649 --> 00:09:25.729
Refresh还重复了一条事实

00:09:25.729 --> 00:09:27.849
所以完成整个工作流

00:09:27.849 --> 00:09:29.329
并不能说明

00:09:29.329 --> 00:09:31.729
每个生成出来的Panda结果都可靠

00:09:31.729 --> 00:09:34.629
但能把训练和本地应用这样跑通

00:09:34.629 --> 00:09:35.749
还是很厉害的

00:09:35.749 --> 00:09:37.509
最后是这只手表

00:09:37.509 --> 00:09:39.829
这大概是我改观的最佳视觉证明

00:09:39.829 --> 00:09:42.529
第一版的表盘还是一整块金色表面

00:09:42.529 --> 00:09:44.669
现在有了更细致的表盘

00:09:44.669 --> 00:09:46.289
清晰的指标金属表带

00:09:46.289 --> 00:09:48.329
能读的星期和日期窗口

00:09:48.329 --> 00:09:49.189
汇动的指针

00:09:49.189 --> 00:09:51.409
还有一个第二时区的小表盘

00:09:51.409 --> 00:09:53.349
整体观感精致多了

00:09:53.349 --> 00:09:54.329
交互也没问题

00:09:54.329 --> 00:09:56.569
你可以选两个时区互相切换

00:09:56.569 --> 00:09:58.409
开关星期和日期显示

00:09:58.409 --> 00:10:00.289
还能在扫秒和跳秒之间切换

00:10:00.289 --> 00:10:02.149
控制检查也通过了

00:10:02.149 --> 00:10:05.169
说明设计下面那些关键部分也没问题

00:10:05.169 --> 00:10:08.089
指针在午夜时能准确对齐

00:10:08.089 --> 00:10:10.469
梦买的半小时偏一夜

00:10:10.469 --> 00:10:11.969
有效了

00:10:11.969 --> 00:10:13.829
纽约的下令时切换也正常

00:10:13.829 --> 00:10:16.469
第二个时区能正确滚到第二天

00:10:16.469 --> 00:10:18.949
代码还附用了时间格式画起

00:10:18.949 --> 00:10:22.169
避免像旧版本那样每一针都重复创建

00:10:22.169 --> 00:10:25.649
视觉结构和时钟逻辑终于配合起来了

00:10:25.649 --> 00:10:28.089
我真的很喜欢这个结果

00:10:28.089 --> 00:10:30.289
它从四分涨到了十分

00:10:30.289 --> 00:10:32.489
是复册里提升最大的一个

00:10:32.489 --> 00:10:35.069
现在我们来看最后的图表

00:10:35.069 --> 00:10:36.489
电梯8分

00:10:36.489 --> 00:10:37.769
隐形眼镜和7分

00:10:37.769 --> 00:10:38.509
桌子6分

00:10:38.509 --> 00:10:39.469
SVG6分

00:10:39.469 --> 00:10:40.269
射简8分

00:10:40.269 --> 00:10:41.489
数学

00:10:41.489 --> 00:10:44.169
Fine Tuning Workflow和手表都是10分

00:10:44.169 --> 00:10:45.909
总分是65分

00:10:45.909 --> 00:10:46.749
满分80分

00:10:46.749 --> 00:10:48.349
也就是81.25%

00:10:48.349 --> 00:10:51.309
不开启思考时的成绩是80分里的43分

00:10:51.309 --> 00:10:53.549
修正配置并重新跑任务后

00:10:53.549 --> 00:10:54.909
我们竟提升了22分

00:10:54.909 --> 00:10:56.989
也就是27.5个百分点

00:10:56.989 --> 00:11:00.589
这个新分数也高于我之前V4Flash的72.5%

00:11:00.589 --> 00:11:03.349
以及V4Pro条目的76.25%

00:11:03.349 --> 00:11:04.989
它在这个排行榜上

00:11:04.989 --> 00:11:06.689
和Gemina3.8Flash打平

00:11:06.689 --> 00:11:07.689
只比Open4

00:11:07.689 --> 00:11:09.729
8的80%高一点

00:11:09.729 --> 00:11:11.369
虽然没排到总榜第一

00:11:11.369 --> 00:11:14.549
但这个结果已经非常有竞争力了

00:11:14.549 --> 00:11:15.649
再说速度

00:11:15.649 --> 00:11:17.009
我看了OpenCode日志

00:11:17.009 --> 00:11:19.489
它为这个新的测试文件夹

00:11:19.489 --> 00:11:20.769
保存了绘画记录

00:11:20.769 --> 00:11:23.449
共有64条已完成的模型回复

00:11:23.449 --> 00:11:25.989
有可用的Token数和时间记录

00:11:25.989 --> 00:11:27.489
像绘画标题

00:11:27.489 --> 00:11:29.289
这类后台调用都被排除了

00:11:29.289 --> 00:11:30.989
另外还排除了一条

00:11:30.989 --> 00:11:32.809
没完成的Restorch回复

00:11:32.809 --> 00:11:34.829
在这些已完成的回复里

00:11:34.829 --> 00:11:37.549
一共生成了364574个Token

00:11:37.549 --> 00:11:40.469
大约294000个是Risning Tokens

00:11:40.469 --> 00:11:41.489
另外大约70

00:11:41.489 --> 00:11:44.209
000个是正常生成的Token

00:11:44.209 --> 00:11:48.049
包括Code2调用参数和答案等其他输出

00:11:48.049 --> 00:11:48.949
所以

00:11:48.949 --> 00:11:52.809
这次生成的Token大多都用在了思考上

00:11:52.809 --> 00:11:55.569
这两个数字都包含了Risning

00:11:55.569 --> 00:11:58.049
它们是根据OpenCode的时间

00:11:58.049 --> 00:11:59.709
戳重建出来的估算值

00:11:59.709 --> 00:12:02.729
它们不包括后面执行工具花的时间

00:12:02.729 --> 00:12:05.549
也不是服务器内部解码速度的精确测量

00:12:05.549 --> 00:12:07.809
我把每次响应的时长加总了

00:12:07.809 --> 00:12:09.029
所以同时跑多个任务

00:12:09.029 --> 00:12:11.369
不会把单次响应速率认为太高

00:12:11.369 --> 00:12:13.109
我觉得这很厉害

00:12:13.109 --> 00:12:14.909
他一边处理多个任务

00:12:14.909 --> 00:12:17.629
一边花了几万tokens做listening

00:12:17.629 --> 00:12:20.849
同时还能保持很高的生成速度

00:12:20.849 --> 00:12:24.349
完整任务耗时能让你从另一个角度来看

00:12:24.349 --> 00:12:27.509
电梯任务大概花了4分20秒

00:12:27.509 --> 00:12:29.589
SVG任务大约11秒

00:12:29.589 --> 00:12:32.889
本地翻桌的流程大约花了11分38秒

00:12:32.889 --> 00:12:35.769
包括搭建环境训练和检查APP的时间

00:12:35.769 --> 00:12:40.029
所以最高强度的思考可能意味着成品要等更久

00:12:40.029 --> 00:12:41.429
在这次附色里

00:12:41.429 --> 00:12:43.829
这些额外的工作带来了结果的大幅提升

00:12:43.829 --> 00:12:45.509
这个取舍我很满意

00:12:45.509 --> 00:12:48.629
现在API价格已经上线了

00:12:48.629 --> 00:12:49.649
非高峰时段

00:12:49.649 --> 00:12:52.769
每百万未缓存输入token15美分

00:12:52.769 --> 00:12:55.409
每百万输出token60美分

00:12:55.409 --> 00:12:57.909
高峰时段输入是30美分

00:12:57.909 --> 00:12:59.689
输出是1.2美元

00:12:59.689 --> 00:13:03.189
缓存输入在非高峰时段每百万Token

00:13:03.189 --> 00:13:04.589
只要0.3美分

00:13:04.589 --> 00:13:06.789
高峰时段价格翻倍

00:13:06.789 --> 00:13:09.629
我会把当前的价格表面接放在下面

00:13:09.629 --> 00:13:12.149
要使用这个已发布的模型

00:13:12.149 --> 00:13:15.249
请选择DeepSeek API地址

00:13:15.249 --> 00:13:19.149
DeepSeek在支持的工具里列出了OpenCode

00:13:19.149 --> 00:13:21.129
记得把Thinking打开

00:13:21.129 --> 00:13:22.709
并把Efford设为Max

00:13:22.709 --> 00:13:25.469
如果你想看这次回测用的配置

00:13:25.469 --> 00:13:27.869
旧的V4 Flash模型已经退役了

00:13:27.869 --> 00:13:30.449
API名字会临时录游到V4.1 Flash

00:13:30.449 --> 00:13:35.429
V4 Pro的请求会在9月14日UTC凌晨4点开始按Flash价格录游到V4

00:13:35.429 --> 00:13:37.809
E Flash直到V4.1 Pro发布

00:13:37.809 --> 00:13:39.829
如果你依赖Pro模型名

00:13:39.829 --> 00:13:41.389
这个时间点就很重要

00:13:41.389 --> 00:13:45.109
Rizni也会消耗可计费的Output Tokens

00:13:45.109 --> 00:13:49.389
所以即使把Effort设到最高还是会有成本

00:13:49.389 --> 00:13:54.089
不过结合这个定价实测速度和81.25%的结果V4

00:13:54.089 --> 00:13:57.249
E Flash还是一个很有吸引力的编程选择

00:13:57.869 --> 00:14:00.629
DeepSea还分享了技术报告和模型仓库

00:14:00.629 --> 00:14:02.349
并表示他正在于

00:14:02.349 --> 00:14:05.229
开源社区在推理支持和部署选项方面

00:14:05.229 --> 00:14:07.429
我的看法有了很大变化

00:14:07.429 --> 00:14:09.469
因为Max开启了Thinking Mode

00:14:09.469 --> 00:14:12.529
这个模型在我的测试里表现得非常不错

00:14:12.529 --> 00:14:15.149
尤其是在万表和本地模型工作流上

00:14:15.149 --> 00:14:17.169
电梯案例也很清楚地说明

00:14:17.169 --> 00:14:18.649
改进不只是界面更好看

00:14:18.649 --> 00:14:20.829
不过还有一些bug要处理

00:14:20.829 --> 00:14:22.989
表格和SVG的分数较低

00:14:22.989 --> 00:14:25.509
说明他并不是每个任务都一样强

00:14:25.509 --> 00:14:27.949
但我还是会非常愿意重新看看

00:14:27.949 --> 00:14:29.209
他在编码上的表现

00:14:29.209 --> 00:14:31.789
配置错误让第一次印象不太公平

00:14:31.789 --> 00:14:34.349
这次复色让我们看到了更真实的情况

00:14:34.349 --> 00:14:36.289
总体来说挺酷的

00:14:36.289 --> 00:14:37.009
总之

00:14:37.009 --> 00:14:39.589
欢迎在评论区告诉我你的想法

00:14:39.589 --> 00:14:41.569
如果你喜欢这个视频

00:14:41.569 --> 00:14:43.129
可以通过Super Thanks打赏

00:14:43.129 --> 00:14:45.529
或者点击中按钮成为会员

00:14:45.529 --> 00:14:46.369
另外

00:14:46.369 --> 00:14:47.729
给这个视频点个赞

00:14:47.729 --> 00:14:48.949
订阅我的频道

00:14:48.949 --> 00:14:50.489
我们下期见

00:14:50.489 --> 00:14:51.009
拜拜