单卡跑1280亿参数大模型：NVFP4四位量化把显存"瘦身"到底怎么做到的，一篇讲透混合精度、长上下文与本地部署

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

先给只想要答案的朋友一句话结论：英伟达把 Mistral 那台 1280 亿参数（128B）的旗舰稠密模型做了一次 NVFP4 四位浮点量化，模型文件从 BF16 全精度的两百多 GB 压到了八十 GB 上下，一张 Blackwell 架构的大显存卡（比如 B200）就有机会单卡把它跑起来。更关键的是，MMLU Pro、GPQA Diamond、AIME 这些硬核跑分几乎原地不动，最多也就是小数点后面的波动，长上下文召回率反而还涨了一截。 也就是说，以前要靠三四张卡才能伺候的稠密大模型，现在压缩之后单卡就能本地跑通，显存这道最劝退的门槛被硬生生拉低了。

这件事之所以值得聊，不是因为"又出了个新模型"，而是它把一条很实用的工程路径摆到了台面上：顶级能力 + 亲民显存，过去这两个词几乎是矛盾的。我自己长期在无忆研习社折腾各种本地部署，最头疼的从来不是模型能力不够，而是显卡不够——一台稠密的大模型能把显存吃到你怀疑人生。这次的量化版本，恰好是冲着这个痛点去的。

下面我会从"为什么大模型这么吃显存"讲起，一路拆到量化原理、NVFP4 这套四位格式的门道、这次混合精度到底动了哪些层、跑分为什么几乎没掉、模型能干什么，最后落到国内环境下的硬件门槛与合规注意事项，以及想自己动手大概该怎么走。想看完整拆解，往下翻。

一、先搞懂一件事：大模型为什么这么"吃"显存

想理解量化的价值，得先弄明白显存是被谁吃掉的。这一节我尽量用大白话讲，哪怕你之前没碰过部署也能跟上。

参数量到显存，中间隔着一个"精度"

大模型里所谓的"参数"，你可以粗暴地理解成一大堆数字——每一个数字都是模型在训练里学出来的一个权重。1280 亿参数，就是模型体内塞了一千两百八十亿个这样的数字。

问题在于，每个数字在显卡里都要占地方，占多大取决于用什么精度去存。最常见的全精度是 BF16（16 位浮点），一个参数占 2 个字节。于是最粗略的显存估算公式就是这么来的：

[ \text{权重占用显存} \approx \text{参数量} \times \text{每个参数的字节数} ]

按这个公式算一下，128B 参数在 BF16 下光是权重就要 128 × 2 = 256 GB 左右。注意，这还只是权重本身，实际跑起来还得叠加 KV 缓存、激活值、框架开销等一堆额外的东西，长上下文场景下 KV 缓存尤其能吃。所以一台 128B 的稠密模型真要在全精度下稳定推理，通常得四张 80GB 的卡（比如 4 张 H100，凑够 320GB）才踏实。

这也是为什么很多人第一次尝试本地跑大模型，都会撞上那个熟悉的报错——显存溢出（CUDA out of memory）。这个词第一次见可能有点吓人，说白了就是"东西太大，显卡塞不下"。

稠密模型比你想的更"实在"

这里要插一句区别。现在流行的大模型大致分两类：一类是稀疏的混合专家（MoE，Mixture of Experts，可以理解成模型内部分成很多个"专家小组"，每次只叫醒其中几组干活）；另一类是稠密模型（Dense），每次推理所有参数全部参与。

Mistral 这台 128B 走的正是稠密路线——没有 MoE 那套"按需唤醒"的机制，每一次前向计算，一千两百八十亿个参数全员上岗。稠密结构的好处是行为可预测、部署简单、显存占用一目了然，不用去猜这次到底激活了多少参数；代价就是它是真的"实在"，该占的显存一点不含糊，你没法靠稀疏激活去省。

我自己的体感是，稠密模型对新手其实更友好：它不会给你玩"显存忽高忽低"的把戏，算好了就是算好了。但也正因为实在，它对显存的绝对需求就更硬，量化能带来的收益也就更直接。

一张表先把显存量级摆出来

为了让你有个直观的量级感，我把这台 128B 模型在不同精度下的大致体积列一下。注意这些是权重体积的近似值，实际部署还要加缓存和开销：

看这张表你就明白了：精度每砍一半，体积基本也跟着腰斩。从 BF16 到 FP8 砍一刀，从 FP8 再到 FP4 又砍一刀，两刀下去，256GB 变成 80GB 左右，直接把"多卡集群才能跑"变成了"单卡有戏"。

当然，天下没有免费的午餐。把数字存得越"糙"，理论上信息损失就越大，模型可能变笨。整个量化领域这些年的核心命题，其实就一句话：怎么把体积压下来，同时让模型尽量别变笨。 这也是下一节要讲的重点。

二、量化到底在干什么：把"高清照片"压成"够用就好"

量化（Quantization）这个词听着很唬人，其实核心思想特别朴素。这一节我用几个生活里的比喻把它讲透，术语第一次出现都会配一句白话。

一句话理解量化

你可以把量化想象成给照片换分辨率。原图是 4K 超高清，细节纤毫毕现，但文件巨大；你把它压成 1080P，肉眼几乎看不出差别，文件却小了一大截。量化对模型做的是同一件事：把每个权重从"高精度、占地方"的表示，换成"低精度、省地方"的表示。

再换个更贴近数字的比喻。假设你要记一堆价格：原来精确到分，比如 3.1416 元；量化之后你只记到角，变成 3.1 元。记录省事了、占的位置小了，但只要你要做的事情对小数点后两位不敏感，这点误差完全无所谓。模型里绝大多数权重，恰好就属于"差一点点没关系"的那种。

从 FP16 到 FP8 再到 FP4，砍的是什么

浮点数在计算机里是由几部分拼起来的：一个符号位（管正负）、几个指数位（管这个数有多大，也就是动态范围）、几个尾数位（管精度，也就是有多少有效数字）。精度越高的格式，指数位和尾数位就越多。

• FP16 / BF16（16 位）：老牌全精度，细节最全，也最占地方。
• FP8（8 位）：这几年数据中心的主力低精度格式，Hopper（H100 那一代）和 Blackwell 都原生支持。相比 16 位，它在显存和吞吐上已经省了一大截，精度损失又控制得很好，算是"甜点位"。
• FP4（4 位）：更激进，一个数字只用 4 个比特来表示。位数少到什么程度？它总共只能表示 16 个不同的数值档位。听上去简陋，但配合后面要讲的缩放技巧，效果出人意料地能打。

一个直观的规律是：位数每减半，理论显存占用大致也减半。这就是为什么 FP4 能把体积压得这么狠——它已经逼近了"还能用"的下限。

为什么不能一刀切，把所有位都砍到最低

如果 FP4 这么省，那把整个模型全砍到 4 位不就完事了？现实没这么简单。

模型里的权重并不是"人人平等"的。有些层像承重墙，动一动整栋楼都晃；有些层像隔断墙，换个轻材料完全没影响。粗暴地把所有层都压到 4 位，那些"承重"的关键部分会因为精度不够而出错，误差一层层往后传，最后模型输出就崩了——该说的话不会说，该算的数算不对。

所以真正靠谱的做法从来不是"一刀切"，而是分层对待：不敏感的地方大胆压到 4 位，敏感的关键路径留在更高的精度上。这种"混着来"的思路，就是所谓的混合精度（Mixed Precision）。这次英伟达对 Mistral 这台 128B 动的手术，正是典型的混合精度打法，具体动了哪些层，我放到第四节细讲。

顺带说清楚一个容易混的点

网上聊 4 位量化，经常把好几个名字混着说：INT4、NF4、MXFP4、NVFP4……它们不是一回事。

简单区分一下：INT4 是定点整数格式，只有 16 个等距的整数档位，没有指数位，动态范围窄；NF4 是 QLoRA 微调里常用的一种 4 位权重存储方案，走的是另一条路；而这次的主角 NVFP4，是英伟达为 Blackwell 专门设计的 4 位浮点格式。浮点比定点强在哪、NVFP4 又聪明在哪，正是下一节要拆的。

莫潇羽@无忆研习社在这里先埋个伏笔：NVFP4 能把 4 位这么极限的压缩做到"跑分几乎不掉"，靠的不是蛮力，而是一套很讨巧的"两级缩放"设计。

三、NVFP4 凭什么能把精度损失压到这么低

上一节说到 4 位量化最大的敌人是"信息损失"。NVFP4 之所以敢在 4 位这个极限位宽上下手，核心就在于它给这套简陋的表示加了一层"精细缩放"的补丁。这一节我把门道拆开讲，尽量不堆公式。

E2M1：一个数只有四个比特，怎么分配

NVFP4 里每个数值用的是 E2M1 格式：1 个符号位、2 个指数位、1 个尾数位，加起来正好 4 位。这三块的分工前面提过——符号管正负，指数管量级，尾数管精度。你会发现它把宝贵的两位都给了指数，只留一位给尾数。这是有讲究的：Transformer 里的权重和激活值分布跨度极大，动辄横跨好几个数量级，把位数优先分给指数（也就是动态范围），比分给尾数（精度）更划算。这也是浮点格式相比 INT4 定点整数的天然优势——同样是 4 位，浮点能覆盖更宽的数值范围，对这种"有大有小、极差悬殊"的数据更友好。

两级缩放，才是 NVFP4 的真正杀招

光靠 E2M1 这 16 个档位肯定不够用，NVFP4 真正聪明的地方是两级缩放（two-level scaling）。我用装数据的比喻讲一下。

想象你要把一堆大小悬殊的东西装进只有 16 个格子的盒子。如果一刀切用同一把尺子去量，大的装不下、小的又浪费格子。NVFP4 的做法是：

1. 第一级（细粒度块缩放）：把权重每 16 个数分成一"小组"，每组配一个专属的缩放因子，这个因子用 FP8（E4M3 格式）来存。相当于给每一小撮数据单独配一把合适的尺子，组内的动态范围就能被充分利用起来。
2. 第二级（张量级缩放）：整个张量再共用一个 FP32 的全局缩放因子，负责把整体范围拉到合适的区间。

两级一叠加，效果就是：每一小组数据都能被"量身缩放"到最能发挥 4 位精度的区间里，那些本来会被压没的幅度信息，靠缩放因子给找了回来。

算下来，NVFP4 存一个 4 位数值，平均还要摊上一点缩放因子的开销，实际大约是每个值 4.5 比特。别嫌这 0.5 比特多余，正是它换来了精度上的稳定。相比 FP16，NVFP4 大约能把权重体积压到三分之一多一点；相比 FP8，也还能再省下小一半。

NVFP4、MXFP4、INT4，到底差在哪

市面上 4 位格式不止一种，容易看花眼。我用一张表把关键差异摆清楚：

对比着看就明白 NVFP4 的取舍了：它把分组从 32 缩小到 16，缩放因子从"只能取 2 的幂次"升级成真正的浮点，还加了一层张量级的 FP32 兜底。这几处改动看着琐碎，合在一起就让它在同样 4 位的前提下，比 MXFP4 更能扛住那些"离群值"（outlier，指分布里个别特别大的数，最容易在粗放量化里把整组精度带偏）。

一段伪代码帮你把流程串起来

如果你更习惯看代码，NVFP4 的量化思路大致可以写成这样（示意，非真实实现）：

# 把一个张量量化成 NVFP4 的大致流程（伪代码）
def quantize_nvfp4(tensor):
    # 第二级：整个张量算一个全局 FP32 缩放
    global_scale = compute_fp32_scale(tensor)

    packed = []
    for block in split_into_blocks(tensor, block_size=16):
        # 第一级：每 16 个数一组，算一个 FP8(E4M3) 缩放
        block_scale = compute_fp8_scale(block, global_scale)
        # 把组内每个数缩放后，塞进 4 位 E2M1(1 符号 + 2 指数 + 1 尾数)
        for x in block:
            packed.append(to_e2m1(x / block_scale))
    return packed, block_scales, global_scale

真实的实现当然要复杂得多，还要靠 Blackwell 第五代 Tensor Core 里的原生指令来加速这套打包和缩放，才能既省显存又不拖慢速度。但核心逻辑就是上面这几步：分组、缩放、塞进 4 位。理解到这个程度，后面看部署文档就不会一头雾水了。

四、这次的主角：把 128B 模型做成"混合精度"

原理铺垫完，回到这次的具体操作。英伟达用自家的 Model Optimizer 工具，对 Mistral Medium 3.5 128B 做了一次训练后量化（PTQ，Post-Training Quantization，指模型训练完成后再做量化，不用重新训练），产出就是那个 NVFP4 版本的权重。它并没有把整台模型一股脑压到 4 位，而是精挑细选地做了混合精度。

哪些层压到 4 位，哪些层留在 FP8

按照官方模型卡的说法，这次量化的分工非常清楚：

• 中间的大部分层压到 NVFP4：解码器第 4 层到第 86 层的 MLP（多层感知机，可以理解成 Transformer 里负责"加工信息"的前馈部分）线性算子，被量化到了 4 位。这一段是层数最多、参数占比最大的区域，压缩收益最高。
• 头尾的边缘层保留 FP8：第 0 到 3 层，以及最后的第 87 层，MLP 线性算子仍然留在 FP8。这些贴近输入和输出的层对精度更敏感，动它们容易伤到整体表现，所以给它们留了更好的"料"。
• 注意力路径整体留在 FP8：所有注意力（Attention）相关的线性算子都保持 FP8。注意力是模型理解上下文关系的核心通道，属于典型的"承重墙"，这里不敢省。
• KV 缓存也留在 FP8：这一条对长上下文尤其关键，下面单独说。

我把这个分工画成一张示意图，你一眼就能看出"哪里用了轻材料、哪里保留了好料"：

flowchart LR
    A[输入 Embedding] --> B[第 0 到 3 层<br/>MLP 保留 FP8]
    B --> C[第 4 到 86 层<br/>MLP 压到 NVFP4]
    C --> D[第 87 层<br/>MLP 保留 FP8]
    D --> E[输出]
    F[注意力路径<br/>全程 FP8] -.贯穿各层.-> C
    G[KV 缓存<br/>FP8] -.长上下文关键.-> C

打个通用的比方：这就像给一栋楼做轻量化改造，把大面积的隔断墙、吊顶换成更轻的材料，体积和重量都降下来了，但承重墙、主水管、主电缆这些关键结构一律用最好的料。该省的地方大胆省，该保的地方一分不让，最后既瘦身又不塌房。

KV 缓存为什么必须留在 FP8

这里得单独讲讲 KV 缓存，因为它直接关系到长上下文体验。

模型在处理长文本时，会把已经读过的内容"记"下来，存成 Key 和 Value 两组缓存，后面每生成一个字都要来查这份缓存——这就是 KV 缓存。上下文越长，这份缓存就越大，长上下文场景下它甚至能比权重还吃显存。

如果为了省显存把 KV 缓存也压到 4 位，模型对前文的"记忆"就会变糊，长文档里的细节容易记岔。所以这次把 KV 缓存稳稳地留在 FP8，等于是在"省显存"和"保住长程记忆"之间做了个务实的取舍。后面你会看到，正是这个取舍，让它的长上下文召回率不降反升。

压完之后到底多大

经过这套混合精度处理，模型的权重体积从 BF16 的两百多 GB，压到了大约 80 GB 这个量级（官方页面显示的压缩后规模在 84B 参数当量上下）。这个体积意味着什么？意味着一张大显存的 Blackwell 卡就能装下权重，再留出足够空间给 KV 缓存去支撑长上下文。从"四卡起步"到"单卡有戏"，这一步的跨度，对预算有限的团队来说是实打实的门槛下降。

我自己在无忆研习社盘算过一笔账：多卡方案不只是显卡本身贵，配套的服务器、互联、散热、运维全都是成本，卡越多复杂度越高。能用单卡跑通一台顶级稠密模型，省下的绝不只是几张卡的钱，而是一整套基础设施的复杂度。这也是我觉得这次量化最有价值的地方——它降的不是某一个数字，而是整个"能不能上手"的心理门槛。

五、跑分几乎没掉，长上下文反而涨了

聊了半天原理，最关心的问题还是：压成 4 位之后，模型到底变笨没有？这才是决定值不值得用的关键。官方给了一组量化前后的对照，我把它整理成表，逐项看下来其实挺有说服力。

一张对照表看清代价

下面是 FP8 版本（作为基线）和 NVFP4 版本在几个主流基准上的成绩对照。这里的评测都是在打开高强度推理（reasoning_effort 设为 high）、温度 0.7、top_p 0.95 的条件下跑出来的：

这些数字该怎么读

先说结论：除了个别项有零点几个百分点的小幅波动，绝大多数硬核能力基本原地不动。 MMLU Pro 从 82.31% 到 82.20%，GPQA Diamond 从 76.88% 到 76.80%，AIME 2025 从 88.85% 到 88.75%——这几项的差距都在小数点后面打转，放到实际使用里你根本感知不到。

指令遵循（IFBench）和多模态（MMMU Pro）确实各掉了不到一个百分点，这算是 4 位量化能接受的正常代价，谈不上伤筋动骨。

真正让我有点意外的是长上下文召回率 AA-LCR，居然从 62.06% 涨到了 65.10%，涨了三个多百分点。量化压缩之后某项指标不降反升，看起来反直觉。我个人的理解是：量化本身带有一点点"正则化"的味道，相当于给模型加了轻微的噪声扰动，某些任务上反而可能修掉一点过拟合的毛刺；再叠加这次把 KV 缓存和注意力路径都稳稳留在 FP8，长程记忆的通道没有被削弱，长上下文这块自然就没吃亏，甚至占了便宜。当然这只是一次评测里的观察，别当成铁律，但至少说明这套混合精度的取舍方向是对的。

需要提醒一句：跑分终究是跑分，它能反映大致水位，但代替不了你在自己真实场景里的实测。数据这东西变动也快，官方后续可能还会更新，上面这些是写稿时的近似情况，真要选型请以官方模型卡的实时口径为准。莫潇羽@无忆研习社一贯的建议是——基准分用来筛掉明显不行的，真正拍板还得拿自己的活儿去试。

别忘了：被量化的这台底座本身就很能打

量化版本的成绩之所以能稳，前提是被压缩的原始模型底子够硬。这台 Mistral Medium 3.5 128B 本身就是一次挺有分量的整合——它是这家法国团队第一台"合并型旗舰"，把过去分散在好几个模型里的能力揉进了一套权重。指令遵循、逻辑推理、代码编写，以前可能要挑三台不同的模型来干，现在这一台全包了；在它自家的对话产品里，它顶替了上一代的常规版和专门的推理版，在编码智能体里也接了此前专用编码模型的班。

它的编码和代理能力尤其值得一提。在一个衡量"能不能真解决 GitHub 上真实工程问题"的硬核基准上，它拿到了七成七以上的通过率，这个成绩在开放权重的稠密模型里属于第一梯队；在一个考多步工具调用的电信场景基准上，更是刷到了九成以上。这也解释了为什么它被拿来当代理类任务的主力——不是靠单点能力堆出来的花架子，而是在真实工程和多步调用里都立得住。

再补一个对国内团队友好的点：它走的是一种修改版的开放许可，商用和非商用都允许（对超大体量的公司有一些例外条款，用之前建议逐字读一遍许可文件）。开放权重加上允许商用，意味着你可以把它拉到自己的环境里私有化部署，数据不用往外送，这对有数据合规诉求的场景是个实打实的加分项。当然，开放许可不等于没有边界，具体条款还是要以官方许可文件的实时版本为准。

官方量化版本和社区量化版本，不是一回事

这里得给新手提个醒。你去模型仓库里搜这台 128B，会发现挂着"NVFP4"名头的版本不止一个——除了英伟达官方这版，社区里热心人做的量化版本有二十多个。它们名字看着差不多，实际差别可能不小，别随手抓一个就用。

差异主要体现在几个地方。一是量化范围不同：有的版本是"权重压到 4 位、激活留在 16 位"（业内简写成 W4A16），有的则是"权重和激活都压到 4 位"（W4A4），两者在显存占用和速度、精度上的取舍完全不同。二是混合精度的切法不同：官方这版精心保留了头尾边缘层、整条注意力路径和 KV 缓存的 FP8 精度，社区版本有的把视觉塔、嵌入层、输出头留在更高精度，切法各有各的讲究。三是校准数据不同：量化时喂进去做校准的语料，几十条和几百条、覆盖的场景够不够全，都会影响最终质量——校准语料越贴近你的真实用法，量化后掉分越少。

我的建议是：优先看官方或来源清晰、说明详尽的版本，把模型卡里"哪些层压了、用什么校准、在哪代硬件上验证过"这几件事读明白，再决定用哪个。别只盯着名字里的"NVFP4"就下手，同名之下差异很大，踩错了版本，跑分和体验都可能对不上你的预期。

六、这套模型到底能干什么：一份能力清单

跑分说明它"没变笨"，接下来才是重点——它本来就是一台很全面的旗舰模型。这一节我把它的核心能力一条条过一遍，顺便说说各自适合什么活儿。

256K 超长上下文，长文档不再切片

这台模型支持 256K（约 26 万 token）的上下文窗口。这个概念对新手解释一下：上下文窗口就是模型"一次能读进去多少内容"的上限。256K 是个什么量级？你可以把一整本书、一个中等规模的代码仓库、几十页的合同或论文，整段丢进去，它不用你手动切片。

我印象很深的是早年用 32K 上下文模型的日子，稍微长一点的材料就得切成好几段分批喂，段与段之间的关联信息一丢，模型经常前言不搭后语，做长文摘要、跨文件的代码审查简直是折磨。256K 加上前面说的长上下文召回率还涨了，这类需要"通盘理解"的任务终于能一口气吃下去，中间不用来回倒腾。

推理深度可调：reasoning_effort 这个开关很实用

模型带了一个 reasoning_effort 参数，可以调节它"想多深"。简单任务把它调低，模型快速给答案，省时省算力；复杂任务调高（比如设成 high），模型会多花些"思考步骤"再作答，质量更好但输出更长、更慢。

这个设计我特别喜欢，因为它把"要不要深度思考"的决定权交回给了使用者。不是所有活儿都值得让模型全力运转——回个简单问候你没必要开高强度推理；但让它调试一段复杂逻辑、做多步规划，就该把开关拧到最高。按场景灵活分配算力，而不是一刀切地全力或全不力，这才是把资源用在刀刃上。

原生多模态：不光会读字，还会看图

这台模型的视觉能力是原生的，视觉编码器是从头训练的，能处理不同尺寸和长宽比的图片。也就是说，你可以丢给它一张架构图让它讲讲这套系统怎么设计，拍一道数学题的照片让它解，或者给张报表截图让它读数据，它都能接住。

对做产品的人来说，原生多模态意味着少维护一套单独的视觉模型，文字和图像走同一套权重，链路更干净。这里插一句合规提醒：如果你的应用涉及对图片、视频内容做识别或再加工，务必确认你对这些素材拥有合法的使用权限；一旦涉及人物肖像、个人健康信息或他人知识产权，还要额外注意隐私与授权问题。

函数调用与 JSON 输出：Agent 开发的省心利器

模型原生支持函数调用（function calling）和结构化 JSON 输出。翻译成人话：需要调外部 API 时，它能自己按格式生成调用参数；需要结构化数据时，它直接吐出规范的 JSON，不用你再写一堆正则去从自然语言里"抠"结果。

做过 AI Agent 开发的朋友应该秒懂这有多省事。以前解析模型输出是个脏活累活，输出格式稍微飘一点，你的解析代码就崩。原生 JSON 输出加上强系统提示词遵循，等于把"模型和你的代码之间的接口"给标准化了，自动化工作流搭起来顺畅太多。这台模型本身在 Mistral 自家的编码智能体里就是主力，代理类任务的能力是它的强项之一。

多语言覆盖：一套权重打通国际化

支持的语言相当全，英语、法语、西班牙语、德语、意大利语、葡萄牙语、荷兰语、中文、日语、韩语、阿拉伯语都在覆盖范围内。对做国际化产品的团队来说，一个模型就能扛下多语种场景，省去了给每种语言单独维护模型的麻烦。

我把这几项能力汇个总，方便你对号入座：

一句话总结这台模型的定位：它想用一套权重，把过去要好几个模型才能覆盖的活儿全包了。 代码助手、多语言客服、长文档分析这类应用，基本能用它一站式搞定。

拿一个真实场景走一遍，你就懂它的价值

光列能力有点抽象，我用一个通用化、虚构化的例子把这几项能力串起来，你会更有感觉。

假设有个团队要做"合同智能审阅"这么个内部工具，需求是：上传一份几十页的合同（有时还夹着扫描件的图片页），让系统读完全文，找出风险条款，输出一份结构化的审阅意见，方便后台系统直接入库。过去这套流程往往得拼好几个模型：一个做长文切片和摘要、一个做图片文字识别、一个做结构化抽取，中间还得写一堆胶水代码把它们串起来，任何一环出问题整条链路都得排查半天。

换成这台模型，链路能显著简化：

1. 整份合同直接丢进去，靠 256K 长上下文一次读完，不用切片，条款之间的前后呼应关系不会因为切割而丢失。
2. 夹在里面的扫描件图片页，靠原生多模态直接读，不用单独接一个文字识别模型。
3. 让它逐条找风险点，复杂的地方把推理深度开高，让它多想几步；简单的常规条款就用低强度快速过，算力花在刀刃上。
4. 最后要求它按固定字段吐 JSON，风险等级、条款位置、修改建议各归各位，后台系统拿到就能直接入库，省掉