Mistral Small 3.2 24B 实测：单 GPU 可运行的开源模型

TL;DR — Mistral Small 3.2 24B 是一款密集型视觉模型，上下文窗口达 131,072 个 token，小到可以在单块 24GB GPU 或 32GB Mac 上运行。测试显示，其编码和多步推理能力扎实，生成速度约 25-27 tokens/sec，不过有一个结构化输出测试撞到了上游 rate limit，而非模型本身的问题。它非常适合离线编码辅助、本地文档问答以及隐私受限的起草场景——但如果需要长文档多文档合成或前沿级别的推理深度，它并不能替代大型 MoE 模型。

大多数开源权重模型的发布都要求你：要么租一整个机架，要么凑合用个玩具。Mistral Small 3.2 24B 则精准切入两者之间的空白：一款 240 亿参数的密集型模型，上下文窗口 131,072 个 token，支持视觉输入，体积刚好能塞进单块工作站 GPU 而不是需要一整个集群。这就是它的定位。下面来看看实际表现如何。

包装里到底有什么

根据其元数据，Mistral Small 3.2 24B（Hugging Face ID：mistralai/Mistral-Small-3.2-24B-Instruct-2506）上下文长度为 131,072 个 token——这是完整的 128K 级别，不是从更小规模向上取整的营销数字。在 OpenRouter 上，其定价为每百万 prompt token 0.075 美元、每百万 completion token 0.20 美元，价格足够低，长文档任务中成本不再是你回避它的理由。HF ID 中的 "2506" 表明它是 Small 系列 2025 年中期的更新版本，且支持视觉输入——并非纯文本模型，截图、图表、扫描文档均在处理范围内，不仅限于纯文本。

它是密集型模型（而非混合专家模型）这一点很关键：这 240 亿参数在每个 token 上都是激活的，而这正是它能在合理量化下塞进 24GB GPU 或 32GB Mac 的原因，而大型 MoE 需要多得多的显存才能把那些（大部分处于空闲状态的）专家参数库整个装进内存。

这款模型真正的用武之地

对于 240 亿密集型模型，有趣的问题不是"它聪明吗"——而是"什么任务它的大小刚刚好"。三种场景尤为突出：

单台机器上的离线编码辅助。一块 GPU 能装下的 240 亿密集型模型，意味着开发者可以在笔记本或工作站上运行真正的编码助手——无需 API 调用、数据不离开本地、不会随着代码库增长而让按 token 计费的账单悄悄膨胀。在代码测试中，要求模型写一个 Python merge_intervals 函数并说明其复杂度，模型给出了正确的排序后合并实现，并正确识别为 O(n log n)——这类小型、独立的任务，这个参数量级处理得干净利落，用时 6.1 秒，速度 27 tokens/sec。

利用完整上下文窗口进行本地文档问答。有了 131,072 个 token 的上下文和视觉支持，你可以把一堆合同、扫描发票或长篇设计文档直接丢给模型，而无需先切分成小块——当你的需求是"根据文档回答，而不是凭记忆回答"时，这比那些上下文窗口更小的模型有实实在在的优势。

隐私受限的起草工作。法务团队、临床相关工作流（仅限起草，不做诊断）以及内部 HR 或合规撰写都有一个共同约束：文本不能离开网络。一款完全运行在本地、在单个团队已有硬件上就能跑的模型，彻底把供应商数据处理问题从讨论中移除，这往往比在基准分数上多那么几分更有价值。

共同的主题是：这些场景里，"够用、私密、全天运行成本低"胜过"最强模型，但跑在别人的服务器上"。

测试实际显示了些什么

推理测试更能说明问题。给出一个水箱注水的文字题——2,400 升，一个注水泵和一个排水泵同时运行 20 分钟，然后排水泵关闭——模型正确计算了净注入速率（30 L/min）、20 分钟后的体积（600 升）、剩余体积（1,800 升）以及以 90 L/min 继续注水所需额外时间（20 分钟）。每一步算术都正确。回答在第 353 个 token 处被截断，句子写到一半，没有给出最终的 boxed 答案，运行速度 24.8 tokens/sec，耗时 14.2 秒——推理过程本身没问题，只是回答在收尾前被切断了。

结构化输出测试要求模型从发票中提取供应商、日期和总额，输出严格 JSON——根本没有返回可用结果，API 提供商返回了 429 upstream rate-limit 错误，在生成任何 token 之前就触发了。这是基础设施的小故障，而非模型 JSON 提取能力的判决，值得如实说明而非掩盖：有时候测试反映的是当天的流量状况，而非模型本身。

240 亿参数实际力不从心的地方

为单块 GPU 量身定制的体积是优点，直到任务规模超出这个尺寸。240 亿密集型模型有固定的容量上限——没有专家路由可以依赖，在遇到突发领域特定推理需求时无法像大型 MoE 那样借力。实际中，这体现在几个方面：

跨数十个长文档的多文档合成，模型需要同时持有并协调比单文档问答任务多得多的事实冲突——这是大型 MoE 的优势所在，它们有远超单文档的总量参数可以调用。

需要多次工具调用和长期规划的长链路 Agent 任务，累积的上下文和复合推理步骤受益于比 240 亿密集型模型所能提供的更充沛的原始算力。

需要前沿级别细微理解的任务——微妙歧义的消解、对抗性提示、高度技术性的领域推理处于模型训练的边缘地带——密集型中量级模型大部分时候表现尚可，在边缘处会悄然失误。

以上都不是对这个模型的批评——只是"塞进单块 GPU"这个定位诚实的边界。对于它为之构建的工作负载——本地编码辅助、单上下文窗口内的文档问答、以及不能离开大楼的起草工作——Mistral Small 3.2 24B 以 big MoE 完全无法匹敌的价格和硬件占用完成工作，因为 MoE 从一开始就不是设计用来放在你桌上的。

这是 30 天系列的第 3 天——明天我们来看 Unsloth AI 及其桌面应用，以及自己微调这样一个模型究竟需要什么。

实测数字（非引用）

今天写这篇文章之前，我通过托管 API 对 Mistral Small 3.2 24B 跑了三个快速测试。样本量小、单一时点快照、经过的硬件我不控制——当作气味测试而非基准来看：

Effective tokens/sec 包含排队时间和首个 token 的响应时间——这是你实际体验到的，而非峰值解码速度。

Model card：上下文窗口 131,072 tokens · 托管定价 $0.075/M 输入 · $0.2/M 输出 · 权重：Hugging Face 上的 mistralai/Mistral-Small-3.2-24B-Instruct-2506

致谢

Mistral AI——训练了 Mistral Small 3.2 24B 并公开权重：mistralai/Mistral-Small-3.2-24B-Instruct-2506。正是这样的开源发布，此类系列才得以存在。

OpenRouter——今天直播测试和定价/上下文数据所及的托管 API。

量化器和运行时维护者——那些大多无偿工作的人，让每个开源发布在数日内变成能在真实硬件上运行的东西。