加载失败
Mistral 这次推出的是 Mistral Medium 3.5，一个 128B dense 的 open-weight 文本模型，官方还给了 256k context 和修改过的 MIT license。评论里有人从 Mistral API 里扒出它的模型名和别名，说明它既能直接在官方 API 调用，也被放进了面向 coding/agent 的产品线里。讨论的背景是近一年来 open models、Claude Sonnet、Qwen、Kimi、GLM、DeepSeek 之间的追赶与反追赶，焦点不再只是能否达到 SOTA，而是量化后能否在 Mac Studio、Strix Halo 或多卡 GPU 上以可接受速度运行。因为很多人默认读者懂 quantization、MoE、SWE-bench Verified 和 agentic coding 这些概念，所以评论几乎都在围绕性能、成本、可控性和商业可持续性做取舍。
不少人先看能不能本地跑，因为这个 128B dense 模型据称在 Q4 后大约 70GB，已经接近 Mac Studio 128GB 这类消费级机器能碰到的范围。但评论反复强调，能装下不等于能快到可交互：dense 模型每个 token 都要读全量权重，实际常常只有几 tok/s，远低于云端 GPU。有人提到 TurboQuant、IQ4、QAT 之类方法可能比传统 Q4 更保质，但质量损失、带宽上限和长上下文下的 K/V cache 依然是硬约束。也有人因此认为，dense 的意义是用更少 GPU 换更高上限，而不是和 MoE 比速度。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
争议集中在 benchmark 和真实体验之间的落差。有人质疑宣传图里的分数来自原始权重或特殊格式，本地量化版、不同 sampler、不同上下文长度都会让结果偏移很多；另一些人则提醒，Sonnet 的 1M context、云端低延迟和更高吞吐并不是本地 256k 模型能直接对比的。还有人拿 SWE-bench Verified 的污染争议、SVG 绘图和浏览器/agent 任务举例，说这些才更接近实际工作流。于是对“超过最新 Sonnet”的说法，评论整体都比较谨慎。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
另一条主线是 agentic coding 时代到底还剩多少 frontier 优势。有人觉得 Claude Code、Codex、Gemini-cli、OpenCode 等工具链已经把默认提示词和 harness 的差异放大到和模型本身同等重要，换一套框架后未必能看出宣传里说的巨大鸿沟。也有人反驳说，真正的差距仍然体现在 context window、tool calling 和多步推理上，Claude 系列在长任务和自动改代码上还是更稳。讨论里顺带提到，很多人从 2024 年中后就把代码代理当成主用途了。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
帖子里还夹着很强的 Anthropic 反感情绪。有人因为 HERMES.md 相关的计费问题、错误收费和客服拒绝补偿而取消订阅，认为这说明闭源平台在自己系统出错时也不愿担责。评论把这当成“去掉 human in the loop”的反例：当平台连退款都要拖，用户更难相信它会在关键工作流里主动修 bug。结果就是一些人转向 OpenRouter、OpenCode 或直接找 open-weight 模型。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
不少人支持 Mistral，并不是因为它碾压了 SOTA，而是因为它提供了一个非美国、非中国的可用选择。对欧洲和企业用户来说，能做 on-prem 部署、私有数据微调、以及和厂商谈价格杠杆，比榜单上的几分差距更重要。也有人补充，像 LG 的 EXAONE、Naver 的 HyperCLOVA X、Sarvam 或 UAE 的模型并非不存在，只是整体竞争力和可获得性都还不足。真正能被大规模托管和采购的，还是少数几家。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
另一派则认为，这次 Medium 3.5 直接暴露了 Mistral 的落后：在价格、尺寸和实际表现上，它被 Qwen、Kimi、GLM 和 DeepSeek 一类中文 open models 压着打。评论里拿 Qwen3.6 27B、Qwen 35B A3B、GLM 5.1、DeepSeek V4 Flash、Kimi K2.5/K2.6 做对比，认为这些模型已经以更小的 footprint 提供更好的指标和更低的成本。即便有人认可所谓的 Pareto 目标——用 20% 成本换 80% 效果——也觉得如果定价比旧款 Mistral Large 更高，就很难算成功。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15] [来源16] [来源17]
还有一组评论关注的是 Mistral 自家产品体验和商业定价。有人说 Le Chat、Mistral Vibe 的网页端受严格 CSP 限制，预览和 Canvas 经常不好用，Vibe CLI 在 Windows 上也有明显 bug；更离谱的是，模型有时能直接调用，却不在 /models 列表里，命名和别名都让人困惑。价格上，mistral-medium-3.5 比 mistral-medium-2508 贵了不少，用户因此担心旧的便宜档位会不会被替换掉，以及 $15/月 或按 token 计费的模式能否撑住。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12]
dense model: 所有参数都参与推理的模型，通常更吃显存和带宽，但结构简单、质量上限高。
MoE: Mixture of Experts，推理时只激活部分专家，用更少计算换更高总参数。
Q4 / 4-bit quantization: 把权重压到 4-bit 的量化方式，能大幅省内存，但可能带来精度损失。
QAT: Quantization Aware Training，训练时就考虑量化误差，让低比特版本更接近原模型。
KV cache: 注意力机制缓存已生成的 key/value，长上下文时会占用大量显存。
Pareto-competitive: 常指用约 20% 的成本或体积，拿到约 80% 的效果。
SWE-bench Verified: 评估代码修复和 agent 能力的 benchmark，常被用来比较 coding model。