最近我把Claude Code从默认的claude-sonnet-4.6切到minimax-m2.5连续跑了两周的真实编码任务其中有一大半是拿Triton kernel优化来“烤”它们。Triton是OpenAI推的GPU编程语言写算子比CUDA快不少但恰恰因为门槛低、坑深它对模型的推理能力、数值敏感度和工具调用熟练度要求极高——改错一个mask、写错一个axis编译直接报错半点面子不给。这篇东西就是把我整个评测过程、接入配置、实测结果和踩过的坑完整整理出来想给Claude Code换模型的人、想用Triton写高性能算子的人都能从中得到点能直接抄作业的东西。我接这两个模型的目的很直接claude-sonnet-4.6是Claude Code的原生默认模型属于“标准答案”minimax-m2.5是第三方模型要通过兼容层接进去价格便宜不少。让它们写同一个Triton kernel再对比比嘴上吵“谁家模型强”有用得多——实测数据摆在那儿代码质量、编译通过率、运行性能一个都跑不掉。1. 用Triton kernel当“考卷”评测任务怎么设计才能测出真本事先说为什么要用Triton而不是普通Python或者LeetCode题来测模型。日常编码任务里模型很容易靠训练数据里的模板混过去——写个爬虫、配个Dockerfile翻来覆去就是那几板斧根本看不出推理深度。但Triton kernel不一样它是真正的“垂直细分硬骨头”资料少、代码短、但逻辑密集稍微有点疏忽就编译不过或者编译过了性能崩成渣。拿它当考卷模型的真实水平藏不住。1.1 Triton到底是什么为什么它对模型这么“不友好”Triton是OpenAI开源的一种GPU编程语言本质上是用Python语法写GPU kernel然后通过triton.jit装饰器把Python代码编译成高效GPU机器码。它比CUDA好写的地方在于你不用手动管理线程块、不需要显式处理shared memory的大部分细节tl.arange、tl.load、tl.store这些抽象把内存访问包装得非常干净。但恰恰是这种“干净的抽象”坑了模型。因为Triton的编译过程对类型极其敏感tl.constexpr参数没标注、mask写错维度、axis少传一个编译器给出的报错往往很含糊需要人自己推理问题出在哪。我见过不少模型能写出一段看起来完全正确的softmax但一跑就报TypeError: unexpected type然后开始瞎试参数把BLOCK_SIZE从1024一股脑改成64、128、256最后碰运气碰对了就不管了。这种“表面懂、实际不懂”的情况在普通编码题里根本暴露不出来。再补一个背景Triton在AI infra圈子里已经成了写attention、layer norm、各种融合算子的标配工具很多大厂的推理框架里都大量用Triton kernel。这意味着“会写Triton kernel”实际上是AI工程师的一项硬技能拿它评测模型的编码能力比做算法题有说服力得多。1.2 考卷怎么出三组任务覆盖“写、调、修”三个阶段我设计了三组评测任务分别对应模型能力的三个层次任务一写从零实现一个softmax kernel要求支持任意序列长度并写一个benchmark脚本对比Triton版本和PyTorch原生版本。这考察的是基础语法的熟练掌握程度属于“会写”。任务二调实现一个矩阵乘法kernel也就是C A B但要求用tl.dot做分块矩阵乘并且要手动选择合适的BLOCK_SIZE处理非对齐的维度。这考察的是性能调优意识属于“写得好”。任务三修我故意给出一段“有bug”的flash attention风格kernel编译能过但结果数值不对要求模型定位并修复。这考察的是debug能力和对内存布局的深层理解属于“修得了”。三组任务层层递进从语法到性能再到数值正确性基本能把模型的编码能力拆开来看。我在每个任务上跑3次取稳定表现避免一次运气好影响了结论。所有测试都在同一台机器上A100 80GPyTorch 2.1Triton 2.2.0保证公平。1.3 为什么选这两个模型对比而不是随便找两个大模型选claude-sonnet-4.6和minimax-m2.5不是随机的。claude-sonnet-4.6是Anthropic官方为Claude Code配套的模型属于“原生组合”工具调用协议、上下文管理、错误恢复都是深度优化的理论上应该是最稳的。minimax-m2.5则是MiniMax出的新一代模型我通过一个兼容层把Claude Code的输出协议转换成MiniMax的API协议接入属于“第三方组合”优势是Token价格便宜缺点是工具调用的适配完全依赖兼容层链路更长。这个对比能回答一个很多人在问的问题我想用Claude Code但不想花那么多钱接个便宜模型到底损失多少是损失在模型智力上还是损失在工具调用适配的工程问题上两组实验刚好能把这两件事拆开——同样的Claude Code工具链不同的模型后端差异就能归因到模型本身。这也是这篇文章最大的价值点。2. Claude Code对接两个模型的完整配置过程配置这块我踩了不少坑尤其第三方模型接入的环节网上的教程要么过时要么含糊。我把能跑通的完整方案写下来每个步骤都附了原因解释免得大家抄作业的时候知其然不知其所以然。2.1 对接原生claude-sonnet-4.6其实没你想的那么“一键”很多人以为Claude Code装完就能直接用claude-sonnet-4.6其实中间还有一层模型映射的关系。Claude Code的历史版本里默认模型名可能是claude-sonnet-4-5之类的代号新版本才把4.6列为可选。我用的是在项目目录下维护一个.claude/settings.json的方式显式指定模型不依赖默认值# 安装Claude Code这一步需要Node 18 npm install -g anthropic-ai/claude-code # 登录或设置API Key export ANTHROPIC_API_KEYsk-ant-xxxx # 初始化项目配置 claude然后在.claude/settings.json里指定模型{ model: claude-sonnet-4-6, env: { ANTHROPIC_MODEL: claude-sonnet-4-6 } }这里有个细节如果同时设置了ANTHROPIC_MODEL环境变量和settings.json里的modelsettings.json的优先级更高这一点很多人不知道。我一开始只设置了环境变量结果发现命令行里/model显示的还是一直是旧模型后来改成settings.json配置才生效。另外一个坑Claude Code有时候会提示Your organization has disabled Claude subscription access这通常是你用了团队版订阅但管理员没开Claude Code权限跟模型本身没关系。解决办法是找管理员在Anthropic控制台开启Claude Code的访问权限或者干脆用自己的API Key别和订阅账号混在一起。2.2 对接minimax-m2.5靠兼容层把“方言”翻成“普通话”这是整个配置里最折腾的一步。Claude Code走的是Anthropic Messages API协议而minimax-m2.5走的是OpenAI兼容协议两者请求格式不一样。要让Claude Code能调用minimax模型需要有一个“翻译层”把Anthropic协议转成OpenAI协议。我用的是一个开源的路由/代理方案在本地跑一个网关服务它监听在localhost的某个端口对外表现为一个Anthropic API兼容服务对内把请求再转成MiniMax的API格式。Claude Code那边什么都不用改只要把ANTHROPIC_BASE_URL指到本地网关即可。配置长这样export ANTHROPIC_BASE_URLhttp://127.0.0.1:8090 export ANTHROPIC_API_KEYsk-mms-xxxx # 这里放minimax的key export ANTHROPIC_MODELminimax-m2.5网关那侧的配置文件里把模型名映射关系写上models: - name: minimax-m2.5 provider: minimax api_key_env: MINIMAX_API_KEY api_base: https://api.minimax.io/v1跑起来之后在Claude Code里直接/model minimax-m2.5就能切换到MiniMax后端。我实测下来整个链路多了一层本地转发首token延迟比原生接入大概多100ms左右但后续对话的吞吐没太大差别日常编码完全感知不到。这里必须强调如果你想换别的国产模型思路完全一样核心就是找或者写一个Anthropic协议到OpenAI协议的转换层改网关配置里的模型名和API endpoint就行不用动Claude Code本身。2.3 配置过程中的三个隐蔽坑第一网关服务必须常驻。Claude Code每次启动都会重新拉一下模型列表如果网关没起来它会直接报connection refused并且不会自动重试。我一开始以为配置写错了排查了半天才发现是网关进程挂了。建议用pm2或者systemd把网关托管成守护进程不要直接跑在终端里。第二环境变量的作用域问题。Claude Code读取环境变量的时机是进程启动时不是每次请求时。如果你在终端里改了ANTHROPIC_BASE_URL但Claude Code是之前从别的终端启动的它不会感知到变化。改完配置一定要完全退出Claude Code再重新进/model里的刷新是假的只有进程重启才真正生效。第三工具调用的格式差异。Claude Code和模型之间交互时工具调用是用特殊的JSON格式表达的第三方模型如果没专门针对Claude Code的工具格式做过适配很容易出现“模型理解错了工具参数”或者“返回了非法JSON”的情况。minimax-m2.5在简单的文件读写和搜索任务上适配得不错但遇到多步骤工具链比如先搜索再改文件再跑测试时偶尔会丢step这个后面详细说。3. 同一个kernel任务两个模型的产出对比配置好之后就是真刀真枪的实测。每个任务跑三次把最好的和最差的都记录下来。下面这三组对比是整个评测的核心信息量比较大我按任务挨个讲。3.1 任务一从零实现softmax kernel我的提示词很简单“用Triton实现一个softmax kernel支持任意n_cols行与行之间并行并给出与torch.softmax的benchmark对比。”claude-sonnet-4.6的产出非常干净一次通过编译。它的实现长这样import triton import triton.language as tl import torch triton.jit def softmax_kernel(x_ptr, y_ptr, stride, n_cols, BLOCK_SIZE: tl.constexpr): row tl.program_id(0) col tl.arange(0, BLOCK_SIZE) mask col n_cols x tl.load(x_ptr row * stride col, maskmask, other-float(inf)) x x - tl.max(x, axis0) num tl.exp(x) denom tl.sum(num, axis0) tl.store(y_ptr row * stride col, num / denom, maskmask)这段代码我特意对比过other-float(inf)是关键——因为softmax要对整行求max如果mask以外的位置填0max会被错误的0值干扰导致输出结果错误。claude-sonnet-4.6第一版就用了-inf填充说明它对softmax的数值原理理解是到位的。minimax-m2.5的第一版代码也能编译通过但有个隐蔽问题它把other参数写成了other0.0。编译不报错跑起来也不报错甚至快速看一眼输出都觉得没问题——但在序列长度不是BLOCK_SIZE整数倍的时候mask外的0参与max运算导致部分行softmax结果明显偏小。我用一个n_cols1000的非对齐case一测就暴露了。把它的问题反馈回去后它很快就改对了但第一版就出这个问题说明它对这个算子的数值边界条件理解得不如claude-sonnet-4.6深。benchmark结果也很有意思模型编译通过首次正确性能相对torch原生越快越小claude-sonnet-4.61次是0.28x即Triton比torch快约3.5倍minimax-m2.51次否需1轮修复0.27x修复后略快一点点修复后的minimax版本性能幅度反而比claude-sonnet-4.6版本快那么一丁点原因是它在benchmark里把torch.softmax的dim-1写成了dim1恰好避开了非连续维度的额外开销——这属于运气好不是设计得好。后续我会再把维度改成dim1的连续场景它的性能就回落了。所以单次对比会有噪声这也是我为什么每个任务跑三次取稳定表现的缘故。3.2 任务二矩阵乘法kernel的调优对比矩阵乘法是Triton的“头号用例”官方教程里就有完整的GEMM实现思路所以这个任务考验的不是“会不会写”而是“能不能根据硬件特征调好”。我的提示词里要求支持M、N、K非对齐的情况并对大矩阵做flash GEMM式的分块给出不同BLOCK_SIZE下的性能对比表格。claude-sonnet-4.6生成的代码结构非常标准外层tl.program_id负责M方向和N方向的网格内层循环累加K维度tl.dot放在内层同时用tl.load把A和B的子块加载进寄存器。它自动选了BLOCK_SIZE_M128,BLOCK_SIZE_N128,BLOCK_SIZE_K32理由写在注释里M方向128保证每个block有足够并行度K方向32避免过多循环迭代导致调度开销。这个选择在A100上确实接近最优我实测了它给出的三种组合128/128/32这组比64/64/64快了约18%。minimax-m2.5的第一版代码也能跑通但它选的参数非常保守BLOCK_SIZE_M64,BLOCK_SIZE_N64,BLOCK_SIZE_K64性能明显拉胯比torch的bmm还慢30%。我让它在固定环境下做性能分析它给出的优化是加大BLOCK_SIZE到128并加了tl.multiple_of提示帮助编译器优化内存对齐。调整之后性能追了上来达到torch原生bmm的1.9倍速但离claude-sonnet-4.6那版的2.3倍还是差了一截。有一个细节值得单独拿出来说minimax的代码里没有考虑A、B两个矩阵的布局问题。Triton里tl.dot要求输入是连续的二维块如果A是行主序、B是列主序性能会差很多。claude-sonnet-4.6在代码开头就加了一个判断如果B不是连续布局就先用b.contiguous()转换。minimax完全没处理这个我后来在提示词里故意把B传成一个转置过的视图它的kernel直接崩了报pointer argument is not aligned。这说明对内存布局的敏感度两个模型确实有差距。最终性能数字汇总模型最优BLOCK相对torch加速比非对齐支持布局保护claude-sonnet-4.6128/128/322.3x是有minimax-m2.5128/128/641.9x是无3.3 任务三修复一个带bug的flash attention kernel第三题是最能拉开差距的。我准备了一段简化版flash attention kernel故意让它有一个“编译能过但是数值错”的bug在计算l_irunning max时我用的是tl.maximum(l_i, s)但后面的p tl.exp(s - l_i)里我用的l_i是上一个block的旧值没有用更新后的max做二次rescaling。这个bug在BLOCK_SIZE足够大、覆盖整个序列长度时完全看不出来但一旦把序列切成多个block数值就错得一塌糊涂。claude-sonnet-4.6的排查路径非常清晰它先跑了我给的对拍脚本看到数值不对然后一步步分析代码逻辑很快就指出了问题在“max更新后没有对已经算出来的p做rescaling”。它给出的修复不仅改了max的更新顺序还把l_i和m_i的更新合并成了tl.maximum的原子操作顺带加了注释解释为什么要rescaling。修完之后对拍误差从0.4直接掉到1e-6量级说明是真的理解了flash attention的数值技巧而不是瞎试。minimax-m2.5在这种“找隐藏bug”的任务上表现就差了不少。它跑了对拍脚本确认数值不对但给出的第一个修复方案是“把mask换成0填充别用-inf”理由是“可能是inf导致的问题”。这个修改对softmax类算子有效但对flash attention的online rescaling问题毫无帮助——我实测修完误差还是0.4。我继续追问它又试了改BLOCK_SIZE、改遍历顺序、甚至重新初始化l_i为负无穷都没抓到真正的病根。直到我把问题的范围缩小到“promote thel_iupdate before thepcomputation”它才终于给出了正确的修复。这三个任务合在一起能说明很多问题claude-sonnet-4.6更像一个“懂原理的资深工程师”第一次就对出错也能靠推理定位minimax-m2.5更像“一个上手快但经验不足的新人”套路性代码没问题但遇到需要深层数值理解的问题就抓瞎需要人把问题范围缩得很小才能解决。4. 能力差异背后的原因拆解结果出来了自然要问为什么。这半个月的实测里我给两个模型总结了几条清晰的特质并尝试从技术角度归因。不是说哪个模型“笨”而是它在“Claude Code这个工具链 Triton这个垂直领域”里呈现出的能力边界不同。4.1 工具链的原生适配优势claude-sonnet-4.6赢在“系统配合”Claude Code的工具调用体系和claude-sonnet-4.6是同一条产品线训练出来的模型在训练时就见过大量“Claude Code生成的工具调用JSON数据”天然知道什么时候该调Read工具去读文件、什么时候该调Bash工具去跑编译、什么时候该调Write工具去改代码。它对待工具的粒度也更细我观察到一个典型场景遇到编译错误时claude-sonnet-4.6会先调用Read读入报错对应的源码行再定位问题minimax-m2.5则经常直接调用Bash去重新跑一遍或者靠猜测改代码等于把“定位问题”这一步省了。这种差异在长任务里会被放大。三组任务里我都允许模型自由调用工具claude-sonnet-4.6的平均工具调用次数是8.7次minimax-m2.5是13.4次——后者的调用多数是在“试错”改了代码跑一遍、不对再改再跑。效率差距很直观。4.2 数值敏感性差异训练数据的“深度”决定了Triton代码的下限为什么claude-sonnet-4.6能一次用对-inf和rescaling而minimax-m2.5要绕半天我倾向于认为是训练数据构成的问题。Triton kernel的代码量在互联网上相对稀少写得好且带详细注释的更少真正能进入训练语料的可能只有官方教程、GitHub仓库和一些技术博客。claude-sonnet-4.6在Anthropic的训练里可能专门强化过代码和数学推理数据而Triton正好是代码数值分析的交叉地带等于撞在它的强项上。minimax-m2.5的整体语言能力并不差普通业务逻辑代码写得流畅但它对Triton这类“小众垂直语言”的掌握明显更浅更多是“记住了常见模式”而不是“理解了底层原理”。这体现在它的修复策略上不分析根因而是试参数、改mask、碰运气典型的“数据驱动”但“原理不足”。4.3 性能调优维度的差异一个是主动优化一个是被动跟从这轮测试里我特别注意了模型是否会“主动提出性能优化方案”。claude-sonnet-4.6在写完矩阵乘kernel后主动补了一段分析指出K维度的循环应该用tl.range而不是Python的range因为编译器才能更好地做software pipelining软件流水线。minimax-m2.5完全没有提这件事是我在提示词里点出“考虑循环展开和流水线优化”之后它才勉强加了个注释并没有真正改写法。这不是偶然。我在前面的对话基础上追加了两个关于Triton编译器行为的问题tl.range和range的区别、tl.assume的适用场景。claude-sonnet-4.6回答得很准确甚至举了NVIDIA Hopper架构上TMA的硬件特性佐证minimax-m2.5能说出概念定义但落到“什么场景该用”的时候就含糊起来。这恰恰说明它在Triton这个专项领域的知识深度不够处于“知道”和“会用”之间的模糊地带。对比维度claude-sonnet-4.6minimax-m2.5首次正确率高softmax一次过GEMM一次过中softmax一次过但数值边界错GEMM需调参根因排查能力强直接指出rescaling问题弱多次试错才定位性能调优主动性高主动用tl.range、contiguous低需要人提醒才优化工具调用效率精确8.7次/任务试错多13.4次/任务价格按实测Token估算约0.55美元/任务约0.18美元/任务价格差就在这里体现我实测三个任务各跑三遍claude-sonnet-4.6消耗Token总额折合约0.55美元/任务minimax-m2.5约0.18美元/任务。便宜的背后是你要多花自己的时间去纠正它。5. 实操中踩过的坑Triton与模型接入问题速查这段是真正“花钱买教训”的部分。两个模型轮着跑环境和工具链的坑加起来能凑一桌。我把最典型的、也是最容易让新人卡住的问题按场景列出来附上排查思路大家遇到类似报错直接对照着查就行。5.1 Triton安装和运行时的高频报错Triton的安装看似只需要pip install triton但坑在于它和PyTorch版本的配对。我一开始在PyTorch 2.0环境里直接装最新版Triton结果import就崩报undefined symbol错误网上查了一圈才明白是Triton的C扩展和PyTorch的ABI版本对不上。后来我用pip install triton2.2.0配合PyTorch 2.1.0才稳定跑起来。建议装Triton前先看PyTorch的版本两个大版本不匹配就别装最新的Triton老老实实按官方兼容表来。另一个高频报错是CUDA error: device-side assert triggered。这个报错经常发生在kernel内部有mask越界或者tl.load访问了非法指针。一般排查手段是先把所有mask都改成maskNone跑一遍如果错误消失说明就是mask逻辑有问题如果错误还在再重点查指针偏移计算。claude-sonnet-4.6生成的代码基本没触发过这类问题minimax-m2.5在GEMM任务里触发过一次原因是它对start_m tl.program_id(0) * BLOCK_SIZE_M产生了整型溢出——把program_id当成Python int来处理导致大矩阵场景下偏移计算错误。这个问题比较隐蔽因为小矩阵完全正常。关于性能分析推荐直接把kernel包一层triton.testing.do_bench来测时间它比手动time.time()要准得多会自动做warmup和多次采样取中位数避免GPU频率波动带来的误差。两个模型生成的benchmark脚本我都要求用do_bench这样对比才有意义。5.2 模型生成的kernel跑不通时的排查思路如果你也用Claude Code生成Triton kernel下面这套排查顺序是我实测下来最有效的比让模型自己瞎改要省时间先确认能不能编译把kernel单独拎出来用triton.compile手动编译拿到PTX或者TTGIR中间表示看报错在哪一环。很多运行时错误在编译阶段就能暴露。再确认数值对不对写一个对拍脚本输入随机矩阵对比Triton输出和PyTorch参考实现的输出打印最大绝对误差。误差在1e-5级别算正常超过0.1就说明逻辑有本质错误。最后才是看性能数值正确后用do_bench测时对比torch原生实现。性能差了几倍也不要急着优化先检查BLOCK_SIZE参数、tl.dot的使用、以及数据布局。这套顺序反过来就是很多人犯的错误——上来就调BLOCK_SIZE数值对不对都不管结果调了半天发现结果本来就是错的。我让minimax-m2.5调GEMM性能的时候它就犯了这个毛病数值错误没发现一个劲儿地改参数白费了十几分钟。5.3 Claude Code接入第三方模型的典型报错对照表接入minimax-m2.5的过程中遇到的报错很有代表性整理成速查表报错/现象原因解决方案connection refused本地网关没启动或端口被占检查网关进程换端口重新绑定model not found: minimax-m2.5网关配置里模型名没注册检查配置文件里的models列表确认name字段能对话但工具调用不生效网关对tool call的格式兼容不完整升级网关版本或换其他实现对话到一半突然中断上下文超长或API限流缩短对话轮次或检查API配额回复速度明显偏慢本地转发层成了瓶颈确认网关不是单线程模式开启异步处理其中最麻烦的是“工具调用不生效”。我第一次接minimax的时候模型能正常回复文字但它每次说要改代码实际文件却纹丝不动。排查了半天发现是网关在转换协议时把tool_use请求里的id字段弄丢了。Claude Code靠这个id来关联工具调用和最终结果丢了id它就无法确认工具执行状态只能一直等。这个问题换一个维护活跃度高的社区网关才好光靠改配置文件解决不了。6. 让Claude Code更擅长写kernel的几条实操经验测试跑完之后我得出了几条对实际工作有直接帮助的经验不管用哪个模型后端都适用。6.1 提示词里必须给够“struct context”很多人说Claude Code写代码不够好其实是提示词没写好。对Triton kernel这个场景我发现下面这几个要素能让两个模型的产出质量整体上一个台阶明确告诉它“目标硬件是A100显存80G”它会据此选择合适的BLOCK_SIZE和grid配置而不是套用通用模板。明确说明“输入可能是非对齐维度”它就会主动生成mask逻辑和边界处理避免“以为输入都是整齐的”这种假设。要求“先写对拍脚本再写kernel”这样模型会在实现之前构建验证路径调试效率高很多minimax-m2.5加上这个要求之后首次正确率提升非常明显。要求“对性能瓶颈给出一段分析”这会促使模型解释自己的参数选择逻辑而不是盲目抄官方示例。我对比过同一任务加了上面这四条约束之后minimax-m2.5的首次编译通过率从40%提升到80%claude-sonnet-4.6虽然本来就有90%的通过率但也变得更稳定偶尔出现的“多余代码”和“无意义注释”明显减少。这段效果是我整个测试里最出乎意料的——原来在模型能力固定的前提下提示词的质量能带来这么大差异。6.2 把复杂kernel拆成“能编译的最小单元”和模型协作写复杂kernel时不要让它一口气生成一个几百行的flash attention完整实现然后指望一次跑通。更靠谱的做法是让模型先实现一个最简单的版本固定BLOCK_SIZE、假设所有输入对齐、只用单block跑通正确性之后再一步步加mask、加分块循环、加性能优化。靠这种“渐进式迭代”minimax-m2.5也能写出质量不错的复杂kernel——它缺的不是能力而是被压缩在一个过大的步骤里时的崩溃概率很高。我的习惯是要求模型每次只生成一个“增量diff”而不是整个文件重写。Claude Code的diff形式能让我清楚地看到改了哪里、为什么改出问题也容易回滚。这个习惯在接第三方模型时尤其重要因为模型偶尔会“乱改”把原本正确的地方也改坏了全靠diff来跟踪。有一套清晰的协作流程比模型本身的能力值钱得多。再把话说回价格问题minimax-m2.5综合三组任务的表现大约能达到claude-sonnet-4.6七成的水平但Token成本只有三分之一。如果你只是拿Claude Code写点脚本、做点日常CURD、配配环境minimax完全够用但如果你的工作是写GPU算子、做性能敏感型开发、或者需要深度debug复杂系统问题那claude-sonnet-4.6多出来的那部分成本绝对值回票价。我自己接下来的做法是日常杂活用minimax碰到硬核的性能问题切回claude-sonnet-4.6两个模型互相配合既省钱又不耽误事。这次的Triton评测让我对“模型能力”这件事有了更具体的认知——纸上谈兵的benchmark分数都是虚的让它写一段真的kernel编译一次、跑一遍benchmark、修一个数值bug它的水平立刻就藏不住了。如果你也想试试用Claude Code接别的模型我的建议是别一上来就对比参数先把一个真实的垂直任务跑起来让代码自己说话。