当初openrouter上线bunny的时候我用了不少, 那时我的体感上认为这是一个可以和dv4-flash简单掰掰手腕的模型
后来确认了这是minimax-m3.1-flash我还很惊讶, 因为我对minimax的模型此前还停留在一些很差的印象
我尝试想对minimax进行认知改观, 本着没有调查就没有发言权的态度, 我买了个minimax的 ￥119 plan
我首先放到了我的CPA(一台美国服务器)上, 在hermes上用3.1让我很难受, 我不太能接受这是当时的bunny, 在TPS比kimi高的情况下竟然比kimi的效率还低, 我观察了一下, 似乎是minimax写出来的脚本执行效率极低或等待时间极长
今天刚好遇到了一个小bug要优化, 很简单的一个优化, 在我古法编程了两分钟写完后, 我心血来潮想再试一下minimax的表现如何
以下结果均为在pi中使用
当m3.1-flash又卡在一个查询脚本执行3分钟后, 我彻底屋檐了
此时我还在反思是否换回国内ip请求会好一些, 我在pi中设置了minimax的官方api key, 直连请求
然后我得到了:
Error: 529 {"type":"error","error":{"type":"overloaded_error","message":"当前服务集群负载较高，请稍后重试，感谢您的耐心等待。 (2064)
(529)"},"request_id":"----"}
我不知道该说什么了
因为我手里还有grok和kimi的订阅, deepseek也还有余额, 就测了这三个模型, 简单总结一下(依然是在pi中):
- deepseek-v4 共耗时4分钟, 请求次数45次, token: 1,144,847,
- grok-4.7 共耗时大概40s, 请求次数9次, token: 120,743
- kimi-k3 共耗时4分钟, 请求次数20次, token: 312,086
ds依旧仗着TPS一骑绝尘肆无忌惮的雷霆调用, grok依旧神秘寡言直觉男, kimi依旧TPS垫底
我印象里他还不如豆包，可用性很差
