Kimi和豆包实测谁更强？
上周末我喂了Kimi K3一份80万token的代码仓库，让它做架构review。说实话我是带着质疑去的，之前好几个模型号称长上下文，实际一到50万token就开始丢信息、胡说八道。K3这次没让我失望。它准确指出了三个跨文件的循环依赖，有两个是我自己都忘了的陈年坑。我特意翻了它引用的代码行号，全对得上，没有幻觉。这点让我有点意外，因为之前K2.5在长文档处理上虽然排名不错，但细节经常飘。对比豆包，上下文窗口是硬伤。Seed 2.0 Pro是25.6万token，Seed 2.1 Pro也没公开突破这个数。我试过喂豆包一个30万token的微服务文档，它会在中后段开始跳过内容，总结变得笼统。LMArena的排名也反映了这个差距，豆包综合第9，Kimi K2.5第19，但UXBench上Kimi K2.6排第5，豆包Seed 2.0 Pro排第11，长上下文场景Kimi明显占优。K3有个设计让我印象深刻。它对历史思考内容特别敏感，连续48小时自主完成芯片设计验证这种任务，它能记住前面几轮的决策上下文。代价是Token消耗快，推理速度慢，官方自己也承认是"电老虎"。我跑那个架构review，等了快十分钟才出结果，期间GPU风扇狂转。豆包的强项在别处。UXBench的恢复率测试，豆包Seed 2.0 Pro 10.8%，Kimi K2.6 11.4%，差距不大，说明两个模型在纠错能力上接近。但豆包响应速度快得多，日常对话基本秒回，K3那个推理延迟摆在那。MCP-Atlas测试豆包83.8分，K3 84.2分，几乎打平，但豆包的成本只有K3的五分之一。长上下文是Kimi的护城河，但护城河不便宜。
发布于 福建
分享
评论
赞
未登录
友善发言
评论
加载中
