社区讨论V2EX 程序员
我很难接受 space-bunny 和 minimax-m3.1-flash 是同一个模型
当初 openrouter 上线 bunny 的时候我用了不少, 那时我的体感上认为这是一个可以和 dv4-flash 简单掰掰手腕的模型 后来确认了这是 minimax-m3.1-flash 我还很惊讶, 因为我对 minimax 的模型此前还停留在一些很差的印象 我尝试想对 minimax 进行认知改观, 本着没有调查就没有发言权的态度, 我买了个 minimax 的 ¥ 119 plan 我首先放到了我的 CPA(一台美国服务器)上, 在 hermes 上用 3.1 让我很难受, 我不太能接受这是当时的 b…
内容摘要
当初 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 垫底
资讯来源
V2EX