前言
记一次真实测评系列,正式停更。
停更的原因有两个,首先是它占用了我较多的时间。
其次是只有一个测试案例,且没有完全标准的评测标准。虽然这个案例能够大致反映模型的可用性,但是仅此而已,与我所期望测评能够带来的参考性有所差距。
我在考虑发布一个更全面、准确性更高、标准且透明化的评测。
而在此之前,我将减少测评的频率,并且这个测试案例会以短的测评系列和大家分享。
感谢大家的支持和阅读!
本次测试案例
这是一个 Unity C# 项目,我进行测试的是一份皮肤系统需求案,我已经做了好预制体,而模型需要编写代码。
DeepSeek V4.1 Flash
效率
排名 |
模型 |
时间(分钟) |
备注 |
|---|
1 |
DeepSeek V4.1 Flash |
13 |
|
2 |
Grok 4.6(xhigh) |
16 |
|
3 |
DeepSeek V4 Flash 0731 |
17 |
|
4 |
Claude-Fable-5(xhigh) |
23 |
|
5 |
DeepSeek V4 Pro 0813 |
25 |
|
6 |
DeepSeek V4 Flash Vision Exp |
27 |
|
7 |
GPT 5.6 Sol |
36 |
|
8 |
GLM-5.3-Flash |
46 |
|
9 |
Qwen 3.8 Max |
52 |
|
10 |
GLM-5.3 |
54 |
|
11 |
Claude Opus 5 |
55 |
|
12 |
Qwen 3.8 Flash Next |
55 |
|
13 |
Kimi K3 |
93 |
|
14 |
GPT 5.6 Luna |
95 |
|
- 首 token 平均(TTFT):1.8秒
- 输出速度(TPS):282 tok/s
- 总步数:196 步
- 总 token 数:31.6M
- 总花费:¥1.28
DeepSeek V4.1 Flash 的首 token 和输出速度非常惊人,持续在 300 tok/s 左右,
这使得它在最近发布的新模型中夺得速度榜的首位。
相对于上一代 DeepSeek V4 Flash 0731,完成时间缩短了 23%(4 分钟),
相对于实验模型 DeepSeek V4 Flash Vision Exp,完成时间缩短了一半。
其实我也测试了 DeepSeek V4.1 Flash 的中间版本,当时价格还没有下降,成绩是:
而这次评测时价格调整已经生效,且与测试中间版本时一样处于闲时段,所以可以横向对比一下价格,
相比之前成本低了将近 2.5 倍。
可以注意到中间版本消耗了 70M 左右的令牌,非常夸张,而现在的正式版本回到了正常水平。
而再比较一下之前处于 0731 时期的价格:
分别计算每百万的单价之后,竟然比之前还要便宜 10%!
现在 Flash 的闲时价格其实与之前未涨价的价格一致,但是输出价格由 2 元翻倍至了 4 元,
所以出现更便宜的原因我猜是输出令牌数量减少了,导致总花费下降。
至于令牌效率的提升倒是不大,甚至还有些下降。
效果
排名 |
模型/层级 |
说明 |
|---|
|
Tier 0 |
该等级的模型实现与线上基线高度一致。 |
1 |
Claude-Fable-5 |
|
2 |
GPT 5.6 Sol |
|
3 |
Claude Opus 5 |
|
4 |
GPT 5.5(xhigh) |
|
|
Tier 1 |
该等级的模型的代码正确完整且可编译,仅少量边界问题或轻微不一致。 |
5 |
Claude Opus 4.8(Max) |
|
6 |
Kimi K3 |
|
7 |
DeepSeek V4.1 Flash |
|
8 |
DeepSeek V4 Pro 0813 |
|
9 |
DeepSeek V4 Flash Vision Exp |
|
10 |
GLM 5.3 Flash |
|
11 |
GLM 5.3 |
|
12 |
Grok 4.6 |
|
13 |
Qwen 3.8 Flash Next |
|
14 |
DeepSeek V4 Flash 0731 |
|
15 |
GPT 5.6 Luna |
|
|
Tier 2 |
该等级的模型的代码至少可编译或仅极少量的语法错误,但是存在明显功能错误、遗漏或与需求/线上不一致。 |
16 |
Qwen 3.8 Max |
|
17 |
Minimax M3 |
|
18 |
Mimo V2.5 Pro |
|
19 |
Claude Sonnet 4.6(high) |
|
20 |
KAT-Coder-Pro V2 |
|
|
Tier 3 |
该等级的模型的问题很多且无法编译,或者存在不少幻觉。 |
21 |
Claude Opus 4.7(Max) |
|
22 |
Hy3 Preview |
|
23 |
Gemini 3.1 Pro(high) |
|
审查结果:
[高] 启动拥有态初始化错误: useSkins 只写入使用字典,没有将正在使用的皮肤登记为已拥有;列表响应到达前或请求失败时,正在使用的皮肤会显示锁定和“前往获取”。UnityProject/Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:193
[中] 倒计时使用设备时间: 过期判断和剩余时间使用 DateTimeOffset.UtcNow,未使用服务器校准后的 RealityTimeSys.NowTimeMilliseconds,设备时间偏差会导致提前或延后过期。UnityProject/Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:340
[中] 称号预览置灰不完整: 未拥有称号时仅称号节点置灰,建筑预览被强制恢复正常颜色,不符合“当前展示节点及所有子节点置灰”。UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:807
虽然实现上有三个细节问题,但是,体感可以说非常惊喜!
在测试中间版本的时候,它就读取了配置表、预制体,并在最后汇报给了我:
配置缺行:skin.xlsx 有 13002(主城皮肤 2),但 item.xlsx 没有 13002 行 → 名称取不到(面板显示空名)、品质回退为 3。请补 item 行或确认该皮肤是否应存在。
顺带发现两处既有路径笔误(非本次改动):PlayerInfoUI.cs 里 m_layerTitle/m_btnAvatar/m_imgAvatarFrame、m_layerTitle/m_scrollBarProgress/m_textUpGradeTips 在预制体中并不存在(实际节点名为 imgAvatarFrame 等),会取到 null。
在之前的模型中,猜猜只有哪些模型做了类似的事情?
Fable 5 和 GPT 5.6 Sol。
但是在测试正式版本时,上面两条没有出现,而是汇报了一条新的问题:
SkinUI.prefab 的 m_tabWorldPreview/m_tabCityPreview/cityIcon/worldIcon 在原有生成代码中缺失,已补绑定;列表项根节点无 Button,运行时补上并复用 bg 作为 targetGraphic 使整项可点击。
两次的汇报截然不同,这么说效果还是有点不稳定。
但是,至少是有了,在之前,这种行为只在 Fable 5 和 GPT 5.6 Sol 上出现过。
给我的感觉是有灵性,有智商但可能还不太可靠。
回头再看官方给出的基准测试分数,一开始我是完全不信的,现在变成了半信半疑,我觉得需要更多的测试。
但是不管怎么说,现有的测试基准还是被 DeepSeek 刷爆了,也证明了现有的基准均有其局限性。
而 DeepSeek V4.1 Flash 的实际表现我认为达到预期,并且性价比在执行 Agent 任务这种输出少的情况下基本回到了之前的水平,推荐大家试试!