★ FEATURED ARTICLE 三周从预览到权重：Le Chonk 的时间线10月29日，Mistral 把自家旗舰 Mistral Large 4（绰号 Le Chonk）的权重正式放上 Hugging Face。这不是一次临时起意的开源：10月6日官方先开了公共预览 API，明确说「weights drop end of this month」，之后用三周时间继续 scaling 强化学习，专攻编码和防御性网络安全两块，再把打磨后的版本连权重一起放出。预览到开源之间只隔23 天，但官方口径是「收益仍在加速，没有看到饱和迹象」。这次放出的不是一个文件，而是一整套部署件。官方变体有两个：FP8 精度的Mistral-Large-4-1T-A52B和 NVFP4 精度的Mistral-Large-4-1T-A52B-NVFP4，Hugging Face 模型卡附带 vLLM 和 SGLang 的部署配方。社区侧 Unsloth 和 llama.cpp 团队在同一天放出了 GGUF 量化，给没有整机柜显存的玩家留了条路。许可证用的是 Mistral Ecosystem Open-Weight License，一份 MIT 衍生协议，商用基本不受限。微软当天宣布该模型进入 Foundry 企业平台，欧洲方面的 Crdit Agricole 则把它当作「主权 AI」的样板模型在欧洲数据中心训练，权重可自部署，数据不出域。把这条时间线和一个月前的 Mistral Large 3 放在一起看，节奏很清楚：Large 3 是 675B 总参、41B 激活，训练用了 3000 块 H200；Large 4 直接跳到 1T 总参，训练集群换成约 4000 块 Grace Blackwell，跑了大约两个月。Mistral 用一年时间把自家旗舰的总参数量翻了一倍多，激活参数却只从 41B 涨到 52B，稀疏化的路线没有变，变的是专家池的厚度。还有一个背景值得交代：这次开源被放进了欧洲「主权 AI」的叙事框架里。训练全程在 Mistral 自有的欧洲数据中心完成，Crdit Agricole 的人工智能部门直接把 Le Chonk 写进了集团级合作，微软 Foundry 同步上架，官方通稿里「战略自主」和「组织韧性」这类措辞出现的频率远高于以往的模型发布。对选型者来说这不是公关辞藻，而是实打实的部署含义：一个在欧洲司法辖区训练、权重完全可下载、许可证允许商用的前沿模型，把数据驻留和供应链审查这两道门都提前打开了。发布节奏上还有一个细节。官方在 10 月 6 日的预览公告里就明确写了「weights drop end of this month」，等于提前 23 天把开源日期锁死。这种先把日期钉死再交付的做法在头部实验室里并不多见多数厂商的开源时间表都带缓冲措辞。Mistral 敢钉死日期，说明预览期的强化学习进度是可预期的，三周后 Terminal-Bench 从 28% 爬到 41% 的结果也印证了这一点。架构账：1T 总参 52B 激活的 granular MoE先看模型名里的硬信息：A52B 就是 active 52B 的意思。Mistral Large 4 是原生多模态的细粒度混合专家模型，总参数约 1 万亿，每个 token 激活 52B，激活比例大约 5%。作为对比，Dense 架构的模型每 token 要过全部参数，而 MoE 只点亮一小撮专家这就是 1T 体量还能谈部署经济学的根本原因：显存账按 1T 算，计算账按 52B 算。上下文窗口给到了100 万 token。这个数字决定了 KV 缓存的账会非常难看，后面显存一节会算给你看：单并发跑满 1M 上下文，光 KV 缓存就是几百 GB 量级，比很多中端模型的权重还大。多语言能力覆盖 160 多种语言，包括欧盟全部官方语言，这对欧洲政企客户是硬指标，对中文用户则意味着多语混合语料上的基线能力不会太差。训练侧的账也值得记一笔：约 4000 块 Grace Blackwell 跑两个月。按 GB200 单卡每小时 2.5 美元量级的云报价粗估，仅训练算力账单就是千万美元量级这个数字是按公开报价量级推算的演示值，实际合同价会低不少，但数量级不会差太多。欧洲自建数据中心加自训，是 Mistral 一直强调的「主权」叙事的基础设施部分。还有一个容易忽略的点：这是一个把 instruct 和 reasoning 合在单一权重里的混合模型，提供三档推理模式来权衡成本与性能。不像有些厂商把推理版单独发一个模型，Le Chonk 的一份权重覆盖了日常指令跟随和长链推理两种用法，自部署方只需要维护一套服务。granular（细粒度）这个词在 MoE 语境里有具体含义：专家数量更多、单个专家更小、每个 token 路由到的专家组合更精细。粗粒度 MoE 可能只有 8 到 64 个大专家，细粒度路线把专家切到几百个量级，路由网络每 token 从中挑选一小撮。这样做的好处是知识容量可以堆得很大1T 总参的容量逼近 Dense 模型的知识天花板而每 token 的实际计算量被路由机制锁在 52B 的水平。用 FLOPs 的话说：一次前向传播的浮点运算量按 52B 算，不是按 1T 算，这是推理成本能被压到每百万 token 一美元量级的架构基础。激活比 52B/1000B 约等于 5.2%，这个数字在同代 MoE 里属于中等偏稀疏。激活比越低，单 token 计算越省，但专家之间的协作效率对路由网络的依赖就越强；激活比越高，效果上限越好抬，但推理成本线性上涨。Mistral 从 Mixtral 87B 时代大约 25% 的激活比一路压到今天的 5.2%，说明他们把路由质量的问题解决得不错路由网络能不能把 token 准确送给「懂行」的专家，是细粒度 MoE 成败的全部关键。1M 上下文对注意力的压力也要单独算。注意力分数的计算量随序列长度平方增长，KV 缓存的显存占用随长度线性增长前者烧算力，后者烧显存。实务上 1M 窗口是个「可用但不便宜」的配置：单次长文档分析没问题，高并发服务里人人跑满 1M 会把 KV 缓存撑爆，这也是为什么后文显存账要把并发路数作为独立参数。能力账：编码与网络安全的基准数字预览阶段官方放出的 DeepSWE v1.1 长周期软件工程基准成绩是62%，对比同图表里的 GLM-5.3 是 61%、DeepSeek V4 Pro 是 57%。需要注意这类厂商自报数字的配置口径差异DeepSWE 公开排行榜按各家最优公开配置重排时座次会有变化，引用时以「官方自报」为准。开源版相比预览多吃了三周强化学习，官方称 Terminal-Bench 4.0 从预览的 28% 提到41%， FrontierCode 上领跑开源权重阵营。网络安全是这次的差异化卖点。在 Artificial Analysis Cyber Index 这项独立评测里，它进入全球前五，并且在非中国产的开源权重模型里拉开明显身位。更有意思的是拒绝率：在 JailbreakBench、StrongREJECT、AgentHarm 的网络安全提示集上，它的平均拒绝率高于所有其他开源权重模型。Mistral 把这件事包装成「防御者优先」能力强但边界清楚，这正是安全团队敢用的前提。Gemini 4 Carbon 走的是另一条路：谷歌把最强的网络能力先锁给 Fairwind 计划的防御方，而 Mistral 直接把权重给你自己管。对自托管团队来说，这组数字的实际含义是：过去要在「能力够用的开源模型」和「能碰生产代码库」之间妥协，现在这个妥协空间被压缩了。一个可以在自己机房里跑、在编码和漏洞复现修补上接近前沿的模型，把「数据出境」这个最大的合规障碍从选型表里划掉了。三档推理模式的设计也值得单独看。同一个权重文件，通过推理深度的档位切换来权衡成本和效果：日常对话和指令跟随用低档，响应快、token 消耗少；代码调试和多步规划用中高档，让模型展开更长的内部推理链。对自托管方来说，这等于把「按场景选模型」压缩成了「按场景选档位」，运维上只需要维护一个服务端点，路由逻辑写在网关层就够了。多模态侧，Le Chonk 原生支持图像输入，视觉编码器与语言模型在同一份权重里。官方定位里明确提到了视觉落地（visual grounding）场景把画面里的区域和文字描述对应起来，这对工业质检、文档版式理解这类企业场景是直接可用的能力。加上 160 多种语言的底子，它瞄准的是「一个模型覆盖跨国企业全部知识工作」的位置。把关键数字集中核对一遍，方便后续引用：指标数值口径说明总参数 / 激活参数1T / 52B官方模型名 1T-A52B上下文窗口1M token官方模型卡Terminal-Bench 4.041%官方自报，预览版为 28%DeepSWE v1.162%预览期官方自报，配置口径需注意Cyber Index全球前五Artificial Analysis 独立评测训练集群约 4000 块 GB200媒体报道引官方口径显存账：FP8、NVFP4、GGUF 三档怎么估部署第一道坎是显存。权重占用的估算公式很朴素：参数量乘以每参数字节数。FP8 每参数 1 字节，1T 参数就是约931 GiB；NVFP4 每参数约 0.5 字节，折半到约466 GiB；社区 GGUF Q4 档大约 512 GiB。这还只是权重，KV 缓存在 1M 上下文下完全无法忽略。KV 缓存的公式是：2（K 和 V 两份）乘层数、乘 KV 头数、乘头维度、乘精度字节、乘上下文长度、乘并发路数。层数和 KV 头数官方模型卡未在首屏标注，下面按 80 层、8 个 KV 头、128 维的典型 GQA 量级取值（以官方模型卡实际参数替换），单并发跑满 1M 上下文就是约305 GiB。核心估算代码如下，直接代入自己的数字即可复算：GB = 1024.0 def weight_memory_gb(total_params_b, bytes_per_param): return total_params_b * 1e9 * bytes_per_param / GB ** 3 def kv_cache_gb(layers, kv_heads, head_dim, bytes_per_elem, ctx_tokens, batch): elems = 2 * layers * kv_heads * head_dim * ctx_tokens * batch return elems * bytes_per_elem / GB ** 3 print(weight_memory_gb(1000, 1.0)) # FP8 权重：931.3 GB print(kv_cache_gb(80, 8, 128, 2.0, 1_000_000, 1)) # 单并发 1M 上下文：305.2 GB把权重加 KV 缓存再预留 15% 的框架与通信开销，对照三种主流 8 卡节点，结论一目了然：节点配置显存总量FP8（约1422 GB需求）NVFP4（约887 GB需求）8H100 80GB640 GB装不下装不下8H200 141GB1128 GB装不下装得下8B200 192GB1536 GB装得下装得下上一代 Large 3（675B）的官方参考配置是 FP8 单机 8H200、NVFP4 单机 8H100；按同样的显存账推到 Large 4，门槛整体上移了一档：FP8 需要 B200 节点才宽裕，H200 节点只能走 NVFP4，H100 节点直接出局。如果不跑满 1M 上下文，把窗口压到 128K，KV 缓存缩到约 39 GiB，8H200 跑 FP8 的账会变成 931 加 39 再乘 1.15，约 1116 GB，刚好擦着 1128 GB 的天花板这就是为什么官方 vLLM 配方里专门提示可以用 max-model-len 参数压显存。并发是另一个会把账掀翻的变量。上面的表只算了单并发跑满上下文的场景；生产环境里如果开 32 路并发、每路平均 128K 上下文，KV 缓存就是 305 乘 0.128 再乘 32，约 1.2 TB，比权重本身还大。所以真实部署的第一课不是「买多大的卡」，而是「定死上下文上限和并发上限」：把 max-model-len 锁在业务真实需要的长度，把 max-num-batched-tokens 锁在吞吐与延迟的平衡点上，剩下的显存才谈得上规划。这也是为什么很多团队最终选择 NVFP4省下的 465 GB 不是目的，换回来的 KV 缓存余量才是。量化档位的选择还有精度层面的考虑。官方在上一代模型卡里明确写过：计划做后续微调的话选 FP8，某些场景下它比 NVFP4 更精确。这个建议沿用到 Large 4 依然成立FP8 保留了更多权重动态范围，微调时的梯度更新不容易被量化噪声淹没；纯推理上线、追求显存效率的场景选 NVFP4 更划算。GGUF 则是另一套逻辑：为 llama.cpp 的 CPU 加 GPU 混合推理准备，精度损失最大，但门槛最低。三条部署路径：vLLM、SGLang 与 GGUF官方模型卡给了两条服务端到端路径：vLLM 和 SGLang，配方随权重一起发布，包含张量并行切分、工具调用解析和推测解码的配套配置。上一代的做法是用官方配套的 Eagle 草稿模型做推测解码，3 个推测 token 能把交互延迟压低一截，这次官方延续了同一套思路。部署命令层面的关键开关有三个：max-model-len 压上下文省显存，max-num-batched-tokens 在吞吐与延迟之间取平衡，enable-auto-tool-choice 加 tool-call-parser 打开原生函数调用。具体参数以官方模型卡为准，不要照抄上一代模板。第二条路是 GGUF 加 llama.cpp，Unsloth 和 llama.cpp 团队已经放出量化件。这条路的目标用户不是生产服务方，而是想在单机大内存工作站上做评测、微调研制或数据不出本机处理的团队。Q4 档权重约 512 GiB，内存加显存凑够这个量级就能跑，代价是 token 生成速度掉到个位数适合批量离线任务，不适合在线服务。第三条路是云托管：Mistral 自家 API、OpenRouter，以及微软 Foundry。Foundry 这条线对已在 Azure 体系内的企业最省事，合规审查和计费都走既有通道。三条路的分工很清晰：要主权和定制选 vLLM 自部署，要评测和研究选 GGUF，要速度和免运维选 API。vLLM 与 SGLang 两条服务端路径怎么选，官方没有明说，按社区通行经验可以这么分：vLLM 的生态最成熟，生产案例、监控插件、推理优化都最全，团队第一次自部署大模型时选它踩坑最少；SGLang 在结构化输出、多轮 Agent 工作流的调度上更激进，RadixAttention 对共享前缀的场景（比如多路会话共用同一段系统提示）有实打实的缓存收益。1T 模型的张量并行切分两者都支持 8 卡起步，切分配置文件随模型卡给出，不需要自己算切分方案。推测解码这条线单独提一句。Mistral 从 Large 3 开始配套发布 Eagle 草稿模型，原理是用一个小模型先猜 3 个 token，大模型只做验证猜中的部分一次前向出多个 token，交互延迟能压下三四成。对编码助手这类「人盯着屏幕等输出」的场景，这个优化直接决定体验好坏。部署时草稿模型要和主模型同版本配套，混用不同代际的草稿模型会让命中率塌掉。成本临界点：API 与自托管的盈亏平衡最后是钱的账。把节点时租、整机吞吐、API 报价放进同一个计算器，才能回答「什么时候自托管反而便宜」。下面这段代码把前面的显存估算和成本模型合在一起，直接可运行，所有输入都是可替换的演示值节点时租取 8H200 约 55 美元每小时、聚合输出吞吐取 1200 token/s、API 报价取输入 0.70 美元与输出 2.10 美元每百万 token 的公开量级，实际选型时替换成你拿到的报价即可：GB = 1024.0 def weight_memory_gb(total_params_b, bytes_per_param): """权重显存：FP8=1.0 字节/参数，NVFP4≈0.5，BF16=2.0""" return total_params_b * 1e9 * bytes_per_param / GB ** 3 def kv_cache_gb(layers, kv_heads, head_dim, bytes_per_elem, ctx_tokens, batch): elems = 2 * layers * kv_heads * head_dim * ctx_tokens * batch return elems * bytes_per_elem / GB ** 3 def fits_in_node(weight_gb, kv_gb, gpus, vram_per_gpu_gb, reserve_ratio=0.15): total = (weight_gb + kv_gb) * (1 + reserve_ratio) capacity = gpus * vram_per_gpu_gb return {"need_gb": round(total, 1), "capacity_gb": capacity, "fits": total = capacity} def selfhost_cost_per_mtoken(node_hourly_usd, output_tps): """自托管每百万输出 token 成本：时租 ÷ 每小时产出 × 1e6""" return node_hourly_usd / (output_tps * 3600) * 1e6 def api_cost_per_mtoken(input_price, output_price, input_output_ratio=3.0): """按输入:输出比例折算的综合成本""" return (input_price * input_output_ratio + output_price) / (1 + input_output_ratio) def breakeven_mtokens_per_day(node_hourly_usd, output_tps, api_per_mtok): if selfhost_cost_per_mtoken(node_hourly_usd, output_tps) = api_per_mtok: return float("inf") return node_hourly_usd * 24 / api_per_mtok w = weight_memory_gb(1000, 0.5) kv = kv_cache_gb(80, 8, 128, 2.0, 1_000_000, 1) print(fits_in_node(w, kv, 8, 141)) sh = selfhost_cost_per_mtoken(55.0, 1200.0) ap = api_cost_per_mtoken(0.70, 2.10) be = breakeven_mtokens_per_day(55.0, 1200.0, ap) print(f"自托管 {sh:.2f} vs API {ap:.2f} 美元/百万输出token, 平衡点 {be}")真实运行结果：8H200 配 NVFP4 返回 fits 为 True；成本侧自托管约12.73 美元每百万输出 token，API 约1.05 美元，平衡点输出 inf打不平。这个反直觉的结论值得展开说：Mistral 把 API 定价压到了自托管硬件成本以下近 12 倍，即便把聚合吞吐乐观调到上万 token/s，自托管的 token 单价也只是勉强追平。换句话说，在 Le Chonk 这个价位上，纯 token 经济学已经不存在「用量大就该自托管」的临界点。那自托管的钱到底花在什么地方？答案是三笔 API 替代不了的账。第一笔是合规账：金融、医疗、政务场景数据不能出境出域，API 再便宜也用不了。第二笔是定制账：拿到权重才能做领域微调和 RLHF 再训练，API 只开放有限的微调接口。第三笔是确定性账：自建服务不依赖外部限流与排队，延迟的 P99 可以自己压。把这三笔账和 token 账放在一起，选型公式就清楚了：再做一组敏感性分析，看看结论对参数的依赖程度。把节点时租从 55 美元压到 35 美元（年付预留实例的量级），自托管成本降到约 8.1 美元每百万 token，仍是 API 的 7 倍多；把聚合吞吐从 1200 乐观抬到 8000 token/s（极限批量、短上下文的理想工况），成本降到约 1.9 美元，才勉强进入 API 价格的 2 倍区间。换句话说，这个结论对演示参数的选择并不敏感时租减半加吞吐翻倍的叠加优化，也只能把差距从 12 倍缩到 2 倍以内，翻不了盘。Mistral 的 API 定价明显是把推理效率的红利直接让给了调用方，用它自己的话说，三档推理模式就是为了让成本随任务复杂度伸缩。还要提醒一笔隐性成本：自托管的人力和运维。一个 8 卡节点跑 1T 模型，需要有人盯显存水位、推理延迟、模型升级和漏洞补丁；权重每次更新都是几百 GB 的下载加滚动重启。按一名平台工程师四分之一的人力折算，月成本就是数千美元量级，这笔钱在 token 账里完全看不见，但在真实 TCO 里经常比硬件还贵。小团队算账时最容易漏掉的就是这一项。场景特征推荐路径决定性因素通用业务、用量波动大APItoken 成本差 12 倍，免运维数据主权硬性要求vLLM 自部署 NVFP4合规不可交易深度定制与微调自部署 FP8 + B200权重在手才能训练离线评测与研究GGUF + llama.cpp单工作站即可，容忍慢速落地清单：四个问题定路径先把账本的边界说清楚：本文所有的显存数字都是按公开公式推算的工程估算值，实际部署时以 vLLM 启动日志里的真实占用为准；所有的成本数字都是可替换的演示值，换成你的合同价再跑一遍代码即可。工具给你了，数字代入权在你。把全文收束成四个按顺序回答的问题。第一个：数据能不能出域？不能，直接走自部署，后面问题不用看。第二个：需不需要动权重？要做领域微调或继续训练，必须自部署 FP8 档，节点选 8B200。第三个：日 token 用量是否稳定超过百亿级且持续增长？即便超过，按本文的账面数字 API 仍然便宜，自托管的理由只能回到前两问。第四个：只是想先把模型跑起来摸清能力边界？GGUF 单机和 API 各花一天，成本加起来不到一顿团队聚餐。Le Chonk 这次开源最大的信号不是某个基准数字，而是定价与权重的组合：API 便宜到让自托管的 token 账失去意义，权重又开放到让合规账有了出口。两条路都通，选哪条取决于你的约束写在成本表里，还是写在监管文件里。实际落地时还有一个混合架构值得考虑：日常流量走 API，敏感流量走自托管。具体做法是在网关层按数据分类路由涉及客户隐私、未公开财报、源代码的请求转发到自建节点，其余通用请求走 Mistral API 或 OpenRouter。这样自托管节点只需要承接 10% 到 20% 的敏感流量，一台 8H200 跑 NVFP4 就绰绰有余，剩下的成本全部按 API 的低价结算。很多欧洲银行采用的就是这个模式，它把合规账和成本账拆开算，各取最优。最后说升级节奏。Mistral 过去一年的发布间隔大约是两到三个月一代重要更新，Large 3 到 Large 4 隔了约十个月但中间穿插了 Medium 和 Ministral 系列的更新。自托管团队需要把「权重更新流程」当成常规运维项来设计：新权重下载、灰度节点验证、基准回归测试、滚动切换，一整套流程跑顺了之后，每次升级的成本就是一两天的人力。这个流程不建好，权重开源的红利就吃不全你手里跑的永远是半年前的版本。
阅读完成 · 觉得有帮助？
