Qwen 3.7 Max追平Opus？别急着吹，落地才是硬道理

实测过Qwen 2.5的长上下文确实容易崩，3.7 Max要是没上flash attention和MoE稀疏化，那高分大概率是刷榜出来的。工程落地这块，阿里一直有个毛病——论文好看，部署起来各种坑。Token事业群整合是好事，但之前钉钉和通义千问各搞各的，内部协同能不能跑通才是关键。

前两天刚在内部试了3.7 Max的API，说实话，跑benchmark确实好看，但一上生产就露怯了。我们有个长文档问答的场景，上下文拉到100K左右，显存直接飙到80G+，比之前2.5版本优化了但不多。flash attention应该是加了的，但感觉没完全吃到红利，可能跟sparse attention的粒度有关，希望官方能出个详细的工程优化文档，不然我们调优全靠猜。

MoE这块，我倒是觉得阿里这次挺聪明的，没学DeepSeek那种全参数MoE，而是用了更保守的共享专家+路由专家的混合结构，推理开销确实下去了，但代价是部分长尾任务的效果下降了——我们测了几个垂直领域的实体抽取，3.7 Max反而比3.0的dense版本还差一点，可能跟专家容量分配有关。

至于Token事业群整合，我其实更关心钉钉那边会不会把Qwen的API搞成独占的。现在钉钉上的AI助手已经绑死通义了，如果后续钉钉场景的私有化部署版本只能用Qwen，那对做企业应用的小团队来说，成本压力会特别大。毕竟钉钉生态里很多SaaS厂商之前用的是其他模型，迁移成本和适配风险都不小。希望阿里能像百度那样搞个开放平台，让开发者自己选基座，不然整合红利没吃到，先被绑定了。

确实，benchmark追平是一回事，落地又是另一回事。去年我用Qwen 2.5跑长文档的时候，显存直接炸了，后来切了GLM才稳下来。这次3.7 Max要是没在attention机制上做优化，光靠分数吹到Opus水平，那真就是实验室里的自嗨了。flash attention和MoE稀疏化是硬门槛，尤其是长上下文场景下，显存优化不到位，再高的分也扛不住实际压力。阿里这次合并事业群确实有想法，但内部协同的工程坑我太熟了——之前我们团队和阿里云那边对接过，模型组和业务组之间的版本同步经常滞后，甚至出现推理服务用的还是老版tokenizer。这次把Qwen、千问APP、钉钉绑一起，好处是数据闭环和场景打通，坏处是如果组织架构没理顺，资源内耗反而会拖慢迭代。我比较好奇的是，3.7 Max在推理加速上有没有做layer cache或者kv cache的量化？如果还是依赖传统的全量注意力，那拉长上下文大概率还是得靠堆显存，这对中小企业部署很不友好。另外，他们说的“追平Opus”具体是哪个榜单？如果是MMLU或GSM8K这类，那参考价值有限，真刀真枪比coding和agent任务可能更说明问题。总之，分数可以吹，但落地成本、延迟、稳定性才是硬指标，建议多放点A/B测试的对比数据出来，别光给个榜单截图。