企业官网建设流程全解析

我一直在做开源大模型的私有化部署，项目从训练到上线的距离，往往比想象中要远得多。模型在训练机里跑得欢天喜地，一放到推理服务环境就原形毕露：显存不够、首token延迟感人、并发一高直接OOM。这种时候你才会意识到，光有训练侧的accuracy还不够，部署侧的“好用”是另一套系统工程。

我整理自己这段时间搭的Model-Optimizer工具链，它本质上是一套面向LLM的模型压缩与推理加速工具箱，把量化、结构化剪枝、知识蒸馏、算子融合、KV Cache优化这些散落的招数收拢到一个入口底下，让你能从“能跑”走到“跑得稳、跑得快、跑得便宜”。这篇文章不只是介绍它长什么样，更想把里面的关键设计逻辑和踩过的坑一一拆开，给正在跟模型部署死磕的朋友一份可直接落地的参考。

1. 为什么我决定自己造一套优化工具链——部署侧的真实痛点

1.1 训练侧“能用”和部署侧“好用”之间的距离

先说个很常见的场景：你费了三个星期微调好一个7B模型，loss降得很漂亮，评测集上的分数也符合预期。然后你拿着这个模型去做服务化部署，申请了一张A10显卡，准备上线。结果一压测，发现问题一串一串地冒出来。

第一个问题是显存。7B参数量的模型，以FP16精度加载，光权重就要占到大约14GB（7B参数乘以每个参数2字节）。这还没算激活值、KV Cache和运行时开销。kv cache尤其容易吓人一跳：它随着batch size和sequence length动态增长，公式是：

KV Cache显存 ≈ 2（K和V两份） × 层数 × batch_size × seq_len × 注意力头数 × 每头维度 × 每个元素字节数

我们用LLaMA-3-8B结构粗算一下：32层、8个KV头、每头128维、序列长度2048、并发请求batch=8，FP16存储条件下，这个值大概是：

2 × 32 × 8 × 2048 × 8 × 128 × 2（字节） ≈ 4.29GB

一个batch为8、2048长度的请求，光KV Cache就要吃掉4GB多显存。如果并发再往上提，显存就像水一样流出去。更麻烦的是，KV Cache不是连续的数组，每个序列的长度不一样，如果按最大长度预分配，又会造成大量浪费。

第二个问题是延迟。Transformer的解码过程是逐token生成的，每次只生成一个token，但每个token都要重新走一遍整网。计算量本身可能还能忍，真正拖时间的是频繁的内核启动和巨大的中间数据搬移。GPU很怕“碎活多跑”，一次算子只干了很小一件事，数据在显存和缓存之间反复搬运，效率全部耗在调度上。

第三个问题就更微妙了：你辛辛苦苦把模型压下来了，但精度肉眼可见地掉了。掉在哪儿？为什么掉？很多工具只告诉你“量化后MMLU掉了3个点”，不告诉你哪些层最敏感、怎么针对敏感层做混合精度。结果只敢整个模型保守地量化到INT8，收益打了折扣。

这就是我看到的真实空档：量化、剪枝、蒸馏、推理优化这些技术，单项方案在社区里都有，但它们是碎片化的。你要自己一个个试验、拼装、调参，中间还要处理工具版本冲突、format转换困难、算子不支持等一系列问题。Model-Optimizer就是冲着这个空档来的——设计目标是：一个入口，多策略编排，把“分析→压缩→评估→导出”串成一条流水线。

1.2 为什么不直接拿现成的开源方案拼一拼

有人可能会问，GPTQ、AWQ这些量化方案不是挺成熟的吗？lazy llama.cpp不也能直接跑量化模型吗？确实，如果你只是想把某个模型量化后塞进推理框架里，那些工具完全够用。但我遇到的问题是组合场景：既要量化，又要剪枝，还要保留蒸馏恢复精度的路径，最后导出的模型还要能被自己的服务框架加载。这个链条里每换一个工具就要重新做一遍模型格式转换，每转换一次就可能引入精度偏差，出了问题你根本分不清是量化引入的误差还是转换丢失的误差。

另外一个问题是可观测性。大多数优化工具是黑盒：你把模型丢进去，它吐出一个压缩后的模型，过程很不透明。但在生产环境中，你不知道模型哪里被剪掉了、哪些层被量化到多少bit、校准数据长什么样。一旦上线后出现问题，你连排查的抓手都没有。所以我做Model-Optimizer时，第一原则就是“全流程可观测”——每次优化后生成一份报告，详细记录每一层的压缩策略、参数分布变化、敏感度得分，以及权重更新前的备份。如此才算具备工程上的可维护性。

所以这不算什么颠覆性创新，更像是我把实践中所有的碎片重新组装，并加上了一层“带说明书的调度机制”。模型优化本身仍然是量化、剪枝、蒸馏这些老手艺，但Model-Optimizer把它们整理成了可以重复执行、可以自动化评估、可以追溯效果的系统流程。

2. 量化模块的关键设计：先保住敏感层，再谈位数

2.1 PTQ与QAT的分工逻辑

量化是Model-Optimizer里最基础也最常用的一个模块。它把浮点权重和激活值从FP16/FP32映射到更低bit位数，比如INT8、INT4或者混合精度。量化的本质是减少表示精度，换取更小的显存占用和更快的计算速度。

Model-Optimizer的量化模块同时提供两条路径：训练后量化（PTQ）和量化感知训练（QAT）。默认流程先走PTQ，因为它的成本最低——不需要重新训练模型，只需要一小部分校准数据来统计激活值的分布范围。如果PTQ后精度掉得太多，再在它的基础上做QAT微调恢复。

PTQ的核心就两件事：定范围、做映射。所谓定范围，就是确定浮点数值要落到哪个[min, max]区间里；做映射，就是把区间里的值均匀切分成2^N份（N是量化bit数），然后四舍五入到对应的整数刻度。看起来简单，但范围定得准不准，直接决定量化损失有多大。

2.2 逐层敏感度分析决定混合精度

几乎所有做量化的人都会遇到同一个困惑：模型所有层都按同一个bit量化，真合理吗？答案是不合理。一个Transformer模型里，embedding层、attention输出投影层、FFN（两层MLP）对量化的敏感度差异巨大。有些层哪怕量化到INT4，精度几乎不掉；有些层一量化，perplexity立刻飙升。

Model-Optimizer里实现了一个叫“逐层敏感度分析”的模块，原理基于二阶近似：对每一层做一次假量化（即把该层切到目标bit数但不真正落地），然后观察损失函数的变化量。这里的损失变化不是简单看训练loss，而是用一个小的验证集计算模型输出分布变化，或者近似用Hessian矩阵的迹来估计。思路是：如果某一层的参数变动导致输出变化很大，说明这层信息密度高，需要保留更高精度。

我在实际跑LLaMA-3-8B时观察到几个规律：

• embedding层和lm_head层往往是最敏感的，因为它们的输出直接决定了token的概率分布；
• attention的Q/K投影比V投影相对更敏感，V投影剪掉一部分信息对最终结果影响较小；
• FFN层里，中间层（通常是4倍宽度）对量化容忍度较高，可以放到INT4；
• 第一层和最后一层的量化务必谨慎，中间层相对皮实。

于是Model-Optimizer的默认混合精度策略是：embedding和lm_head保留INT16或FP16，前几层和最后几层用INT8，中间密集计算层用INT4。实际效果比整网INT8平均能省更多显存，而且精度损失更少。这个策略之所以有效，是因为它不搞一刀切，而是把“预算”优先分配给敏感层。

一个直觉类比是：压缩照片的时候，你不会把蓝天和人物脸压缩到同一个质量档位。蓝天部分细节冗余严重，压狠一点看不出来；人脸部分哪怕有一点色块或模糊，观感立刻下降。模型的各层也是一样，信息冗余度差异很大。

2.3 calibration数据集的构造与陷阱

PTQ里的校准（calibration）环节是最容易被低估的。我在很早的时候犯过一个错误：随便拿了几十条训练集数据做校准，结果量化后模型直接变成复读机。原因出在数据分布和真实场景不匹配。

校准集的目的是统计激活值的分布范围，这个范围直接决定了量化的缩放系数和零点。如果校准集和模型真实使用的数据分布差异太大，量化时就会出现大量截断，把本来还在范围内的值硬生生切成边界值，信息丢失严重。

Model-Optimizer在配置校准数据集时有几个默认建议：

• 样本数量不需要多，通常128到512条就够了，但必须是和线上数据同分布的真实语料；
• 样本要覆盖不同的长度，最好同时包含短句和长文，否则KV Cache和激活值范围覆盖不全；
• 绝对不要使用验证集或测试集做校准，否则会得到虚高的精度指标，上线立刻露馅；
• 如果数据包含多个领域，尽量按比例混合，避免单领域校准导致其他领域表现恶化。

在具体算法层面，Model-Optimizer支持两种校准策略：按最小化均方误差（MSE）选择缩放系数，或者按KL散度最小化来选择。前者适用于权重量化，后者更适合激活值量化。KL散度的思路是让量化后的分布和原始浮点分布尽量接近，但是实现上需要注意对分布尾部做截断处理，否则会有个别极端值撑爆整个量化范围，导致大部分数值退化成粗糙的台阶。

2.4 量化重构的公式与实现示意

量化计算的本质其实不复杂，就是把一个浮点数组变成一个整数数组外加scale和zero_point的元数据。Model-Optimizer里有一个独立的tensor_quant模块，核心逻辑大概长这样：

def quantize_tensor(tensor, bits=8, per_channel=False): # 取数值范围 min_val = tensor.min().item() max_val = tensor.max().item() # 对称量化时，取绝对值最大的作为边界 scale = (max_val - min_val) / (2 ** bits - 1) zero_point = 0 # 量化并截断到合法整数范围 qmin = -(2 ** (bits - 1)) qmax = 2 ** (bits - 1) - 1 q_tensor = (tensor / scale).round().clamp(qmin, qmax).to(torch.int8) # 反量化用于精度对比 dequant_tensor = (q_tensor * scale).to(tensor.dtype) return q_tensor, scale, zero_point, dequant_tensor

实际工程里会用更精细的per-channel/groupt量化方案——按输出通道或按组分别计算scale，而不是整个张量共用一个scale。组大小（group size）是当前模型量化里一个重要超参数。比如INT4量化时把group size从128降到64，能明显降低异常值的影响，但会略微增加存储开销。Model-Optimizer默认给LLM的权重配置是group size=128，激活值用per-token的动态量化。如果你发现某个层量化后误差很大，第一件事就是把这个层的group size调小到64或32，往往立刻见效。

3. 结构剪枝与蒸馏：减的是参数，守的是分布

3.1 为什么只做量化不够

量化做的是“用更少的字节表示相同的数字”，它不改变模型的网络结构。可模型该有多大还是多大，前向传播的计算量也没少。想要实质性的推理加速，就需要动结构——把不重要的通道、注意力头、甚至整层网络去掉，让计算图本身变瘦。

但结构剪枝有个残酷的问题：直接剪掉参数，模型精度一定掉。掉多掉少看运气，运气不好直接崩。于是知识蒸馏通常是它的配套动作：用一个未剪枝的原始模型作为Teacher，让剪枝后的Student模型在训练过程中模仿Teacher的输出分布，用Teacher的“软标签”去弥补结构剪枝带来的信息丢失。

Model-Optimizer把这两个流程绑定成一个名叫PruneDistill的Pipeline组件：先做一次剪枝，再做若干轮蒸馏训练，然后评估精度。如果精度达标就继续下一轮剪枝，如果精度掉了超过阈值就回退到上一轮状态。循环往复，直到达到目标稀疏度。

3.2 通道、头、层三个粒度的选择

LLM的剪枝有三个粒度：通道剪枝（channel pruning）、注意力头剪枝（head pruning）和层剪枝（layer pruning）。它们分别作用于FFN的中间维度、注意力头和Transformer层数，各有各的代价和收益。

我在实际使用时通常按这个顺序来：

1. 先做注意力头剪枝。Transformer里并非每个注意力头都很关键。有些头学到的是重复模式，剪掉后对下游任务几乎无感。判断头重要性的办法是计算它在验证集上的“平均注意力得分贡献”或者基于梯度的重要性因子。Model-Optimizer默认用基于梯度的Taylor展开估算每个头的重要性，因为这一类方法不需要额外训练，跑一次反向传播就够了。

2. 再做FFN的通道剪枝。FFN层往往是参数量的大头（大约占Transformer参数的2/3），剪它的收益最大。通道剪枝对精度影响比较平滑，因为它不是整条删掉，而是把不重要的神经元置零或移除。但要注意：通道剪枝会改变后续层输入维度，对系统编程要求高，通常要依赖推理框架的稀疏矩阵算子配合才能真正加速，否则在你的存储里是变小了，但跑起来反而更慢。

3. 最后考虑层剪枝。这是最激进的方案，虽能获得最大收益，但风险也最大。层间冗余确实存在，LLM越深，浅层和深层之间的语义层次差异越来越小，一些中间层完全可能被跳过。Model-Optimizer实现了一个层重要性评估指标：逐层去掉某一层，观察输出表示之间的余弦距离变化，用这个作为层冗余的度量。层剪枝通常情况下建议配合蒸馏训练跑至少500到1000步恢复，否则掉点会很明显。

3.3 蒸馏的匹配点怎么定

知识蒸馏的一个核心问题是：Student模型要模仿Teacher的什么？最早期的做法是拿softmax输出的概率分布做KL散度损失，但LLM的词汇表动辄几万甚至十几万，直接在输出分布上算KL散度计算量太大，而且容易忽略中间层的语义。

Model-Optimizer采取的是多层匹配方案，蒸馏loss由三部分组成：

L = α * L_output + β * L_hidden + γ * L_attn

其中L_output是对齐Teacher和Student在词汇表上的logits或Top-K分布，L_hidden是对齐Teacher和Student在中间层（例如每隔两层）的hidden state表示，L_attn则对齐注意力矩阵的分布。举个例子，假设Teacher倒数第二层输出hidden state维度为4096，Student剪枝后是3072，那在计算L_hidden时，需要先通过一个可学习的线性投影层把Student的表示映射到Teacher的维度上，再计算MSE损失。

实践中有个很关键的经验：hidden matching加在中间层比只加在最后一层效果明显更好。因为剪枝损失的信息是整个网络逐步累积的，中间层能把误差更早地引导回去。loss权重按经验值设置，通常L_output权重最高，L_hidden次之，L_attn权重最低。训练时学习率要比正常微调低一两个数量级，避免Student忘记Teacher已经教会的知识。

3.4 稀疏度调度与回退机制

剪枝不是一步到位的。我刚开始做剪枝的时候，直接设定一个50%的稀疏度目标，一次性剪掉一半通道，结果模型直接胡言乱语。后来改成渐进式稀疏度调度（gradual pruning schedule），效果天差地别。

Model-Optimizer的默认调度是：从稀疏度0开始，每轮增加5到10个百分点，每一轮做完剪枝后跑少量蒸馏步数，评估验证集loss，如果相比上一轮loss上涨幅度超过某个阈值，就回退到上一轮检查点并降低本轮稀疏度增量。这个过程很像健身增肌：你不能一天把重量加到极限，必须循序渐进，让“剩余网络”有时间适应新的容量。

用大白话说，剪枝就是一个不断测试“模型哪部分冗余程度高”的过程。如果剪完精度狂掉，说明那部分不是冗余而是核心功能所在。回退机制的意义就在于给这个过程一个安全网，不至于一剪子下去就再也补不回来了。

4. 推理侧优化：数据搬移变小，延迟才真的降下来

4.1 算子融合与kernel选择

量化压缩是把模型“变小”，但模型变小之后如果不配合算子层面的优化，实际推理加速非常有限。GPU推理的性能瓶颈有很大一部分来自频繁的内核启动和显存数据搬运，Model-Optimizer在导出阶段两个动作最有用：算子融合（Operator Fusion）和kernel选择。

Transformer里最常见的融合是QKV投影融合。原始实现里通常有三个独立的线性层：Q、K、V分别计算三次矩阵乘。GPU每次跑一个线性层就要启动一次kernel。如果把它们拼成一个大的线性层，把权重矩阵在列方向上拼接，一次矩阵乘就能同时算出QKV三个结果，kernel启动次数直接降低到三分之一。

类似的还有attention输入投影和位置编码的融合、MLP里两个线性层之间的激活函数融合、LayerNorm之后的残差连接融合等。每一处融合看起来都是小优化，累计起来对长序列生成的帮助非常明显——解码阶段本身就是被这种细碎操作拖慢的。

4.2 KV Cache压缩与Paged Attention

KV Cache的优化是我在Model-Optimizer里投入最多的部分，因为它直接和并发、显存挂钩。前面算了，batch=8时KV Cache就能吃4GB多。如果量化到INT8，显存直接减半到2GB多，而且精度损失通常很小。

实现KV Cache量化的关键是per-token/per-head动态量化。K和V缓存张量的分布并不完全一样，V一般更稳定，K受位置信息影响更大。Model-Optimizer把K缓存做per-head量化，把V缓存做per-token量化，实测下来能够较好平衡精度和显存。

另一个有效手段是分页KV Cache（Paged Attention，类比虚拟内存分页）。传统的KV Cache按请求预先分配固定大小的连续显存，序列短时浪费巨大，序列长时又可能不够用。分页式管理把KV Cache拆分成固定大小的块，按需分配、靠链表维护逻辑连续性。Model-Optimizer在导出服务对象时默认开启分页，它让内存利用率从大约60%提升到90%以上，在同样显存下可以承接更多并发请求。

4.3 连续批处理与投机解码

延迟优化和吞吐优化有时候看起来是矛盾的，但实际部署里通常要同时考虑。Model-Optimizer集成了连续批处理（continuous batching）逻辑：传统静态批处理把所有请求塞到一个batch里，一个请求生成了，必须等整个batch结束后才能腾出位置。连续批处理的做法是，某个请求一旦生成结束，立刻释放它的KV Cache和显存，并把调度队列里的新请求插入进来。这使得GPU在长尾请求场景下始终被填满，不会出现“大部分batch资源都被已结束请求占着”的浪费。

投机解码（speculative decoding）则是另一招——用一个很小的草稿模型先快速生成若干候选token，再由目标大模型一次并行验证这些token。因为“验证”比“生成”低昂，只要草稿模型猜得够准，实际延迟会大幅下降。Model-Optimizer的slogan里有一项专门管理草稿模型的匹配：草稿模型不需要和主模型同族，只要词表对齐即可，理想情况下它的大小应该控制在主模型的10%到20%。

5. 实测结果：一张表看透收益，也看透代价

5.1 测试环境与模型列表

说再多理论，不如直接看数据。我在三张不同显卡上做了完整的测试，分别是NVIDIA RTX 3090、A100 40GB以及一张较老旧的T4。模型选了三款常见开源模型：LLaMA-3-8B-Instruct、Qwen2.5-7B-Instruct、Mistral-7B-v0.3。输入输出长度都固定为1024输入 + 512输出，并发请求为8。精度评估采用困惑度（perplexity）和MMLU（5-shot）两项指标。

以下是一组不算严谨但完全可复现的实测数据：

这组数据里最值得关注的是后半段：量化加剪枝后的组合，显存从21GB降到6GB左右，吞吐提升了七成以上，代价是MMLU掉大约2.6个点。对于很多业务场景来说，这个精度损失是可以接受的，尤其当你部署的是微调过的专用模型，而不是试图让它在通用知识上保持全盛状态。

5.2 精度下降都跑到哪里去了

很多人拿到Model-Optimizer的报告后会盯着MMLU看，但我更建议看perplexity的分层变化。根据我在优化后模型上的细粒度分析，掉点主要来源如下：

• 极少出现在token中段的语义断裂，更多出现在长尾低频词的top-k分布里。量化后的模型倾向于把概率质量集中到高频词上，低频词的概率被低估。这在问答类任务里表现不明显，但在生成式任务里容易让输出变得“平淡”；
• 剪枝对FFN中间维度的损伤会让模型在需要“多步推理”的任务上显得吃力，因为少了一部分并行计算的容量，模型记忆复杂关系的能力下降；
• lm_head如果被量化，解码阶段的词表分布会整体平滑，导致更低置信度输出。所以我在导出配置里默认强制lm_head保持FP16。

知道精度掉哪儿之后，应对方案就清楚了：如果是问答业务，多关注高频词覆盖；如果是长文本生成，优先保留FFN的通道数；如果必须保留模型推理能力，就用混合bit方案避开敏感层。Model-Optimizer的优化报告就是为了辅助这些判断，而不是用单一指标掩盖问题。

5.3 什么时候不值得做全套优化

不是所有模型都值得上一整套量化+剪枝+蒸馏。估摸你手里的场景：

• 如果模型本身小于3B，且序列长度经常在512以内，推理延迟通常已经很快，单纯量化就够了，没必要剪枝；
• 如果服务并发很低（个位数请求），显存不是瓶颈，那INT8量化足矣，INT4带来的额外精度损失性价比不高；
• 如果是CPU推理，簇拥在算子融合的收益更明显，因为CPU没有GPU那么多并行核，数据的反复搬移对性能影响更大；
• 如果项目只有三天上线时间，别碰知识蒸馏。蒸馏训练超参敏感，恢复周期长，短期内的确定性远不如量化来得稳。

我个人的经验法则是：先量化，评估掉点；如果显存压力仍大且掉点可接受，再加剪枝；如果剪枝掉点太多，才考虑上蒸馏恢复。这个顺序把每步的收益和风险都控制在一个可控范围内。

6. 从零跑通Model-Optimizer的完整过程与常见坑

6.1 快速上手的API设计

Model-Optimizer的使用方式尽量保持简单，核心接口就是一个optimize函数加一个配置文件。安装直接用pip完成：

pip install model-optimizer

以量化一个HuggingFace模型为例，代码大致如下：

from model_optimizer import ModelOptimizer optimizer = ModelOptimizer( model_name="Qwen/Qwen2.5-7B-Instruct", optimization_preset="balanced", # 可选: light / balanced / aggressive work_dir="./optimized_models", dtype="auto", device_map="cuda:0", kv_cache_dtype="int8", ) report = optimizer.run_evaluation( quantize=True, prune=True, distill=True, calibration_dataset="./data/calib.jsonl", ) print(report.summary())

run_evaluation会执行完整流程：先做逐层敏感度分析，再按配置的优化档位执行量化、剪枝、蒸馏，最后用验证集生成优化报告。报告里包含每一层的bit配置、剪枝比例、显存预估变化、perplexity变化和延迟预估。如果你对默认档位不满意，可以传入自定义配置字典，逐项覆盖每个模块的参数。

6.2 五个最容易翻车的细节

我在开发和自用的过程中，踩过的坑比文档里写的多得多。挑五个对最终效果影响最大的细节警告后来的使用者：

第一个坑是校准集和验证集重叠。校准集是用来确定量化范围的，验证集是用来评估精度的。如果两者重叠，评估结果会虚高。我把校准集和验证集硬性拆开管理，Model-Optimizer里也默认做了数据集分割和排重，防止这个低级错误悄悄污染结果。

第二个坑是batch size差异导致量化范围漂移。同一个模型，校准数据单条送入和按batch送入，激活值分布可能差异很大，尤其是BatchNorm类型的层。即便Transformer基本不用BatchNorm，但LayerNorm对输入分布的感知也很强。我的经验是校准时的batch size要和线上推理的典型batch size保持一致，否则量化范围永远偏一格。

第三个坑是剪枝后的权重无法复用原推理框架。很多推理框架对稀疏模型支持很差，通道剪枝后模型参数维度变了，库不认。所以Model-Optimizer导出模块会同时输出标准PyTorch权重和ONNX格式，并自动检查算子是否在目标框架的算子覆盖范围内。如果目标框架不支持某个算子，导出阶段会直接报错而不是生成一个跑不了的模型。

第四个坑是KV Cache量化时跳过第一层。第一层的K缓存往往包含大量位置信息，对位置编码的敏感度非常高，量化后模型对长序列的位置感知会显著退化。所以Model-Optimizer的kv_cache_dtype支持配置层范围白名单，默认跳过前两层不做量化。

第五个坑是半精度下的absmax溢出。FP16能表示的范围有限，量化计算scale时对矩阵全体求absmax，如果某个异常值过大，可能导致scale小到溢出。在少数极端权重分布下会出现全零张量。规避方法是计算scale时加入一个极小epsilon（例如1e-8），或者在FP32下计算scale再cast到FP16。

6.3 复现我这份结果的最小操作集

最后给出一份可复现的最小命令。假设你想复现LLaMA-3-8B的INT4混合精度结果，在配备24GB显存显卡的机器上，可以执行：

model-optimizer optimize \ --model meta-llama/Llama-3-8B-Instruct \ --preset aggressive \ --quant-bits int4 \ --group-size 128 \ --skip-layers embedding,layer0,layer31 \ --calibration-size 256 \ --eval-tasks perplexity,mmlu

跑完之后，优化模型会输出到当前目录下的./optimized_model_fp16_int4_mix目录。你可以再用Model-Optimizer内置的serve子命令快速启动一个兼容OpenAI接口的推理服务：

model-optimizer serve \ --model ./optimized_model_fp16_int4_mix \ --port 8080 \ --kv-cache-dtype int8 \ --max-batch-size 32 \ --enable-paged-attention

我建议第一次做完整优化时，哪怕再着急也要打开报告看一眼“逐层bit配置”和“逐层剪枝比例”这两页。Model-Optimizer生成的报告是HTML格式的，每一层都能展开看到优化前后的参数分布图。这些细节才是决定你模型最终体感质量的东西。

我自己的习惯是每次优化完，除了记录eval指标，还会保存几个固定测试用例的实际输出，比如一个数学题、一个长文摘要、一个代码补全。看数字可以，但最终还是要看真实生成的文字质量。模型压缩这条路，永远不要只看指标不看输出。每个人的业务场景不一样，最优的压缩配置也不一样，把流程跑通、把报告看懂、把关键层守住，你就能摆脱“用别人调好的模型”的被动局面，真正按自己的需求定制推理效率和精度的平衡点。