企业官网建设流程全解析

如果一个大模型公司选择不蒸馏，直接拿几十B甚至上百B的模型去接线上流量，短期内可能觉得效果更好，但拉长时间看，最直接的代价是推理成本、部署门槛和迭代速度同时失控。这不是说所有场景都应该立刻蒸馏，而是“不蒸馏”必须是一笔算得过来的账，而不是默认选项。

很多团队其实不是没有能力做模型蒸馏，而是压根没有认真算过不蒸馏的代价。模型发布会结束之后，真正困难的不是那个“模型效果多好”的Demo，而是线上每一个请求都会访问全部参数。大模型公司一旦进入规模化部署阶段，模型体积就会直接变成成本。下面我会按实际落地顺序拆开讲：模型蒸馏到底解决什么问题，不蒸馏会让公司付出哪几张账单，以及如果决定蒸馏，怎么用最小流程验证收益。

1. 蒸馏到底在解决什么问题

1.1 发布会上的模型和线上推理的模型是两回事

很多团队在选模型时，第一个指标是“效果排名”，第二个指标才是“能不能跑起来”。但真正进入生产环境后，效果之外的所有问题都会被放大。

一个大模型在上线后，每生成一个token，都要重新执行一次前向传播。这个过程和参数量、输入长度、输出长度、并发数量都有关系。参数越多，单次推理需要的显存和算力就越高。如果模型还是几百B规模，可能连一台GPU服务器都装不下，更不用谈高可用、多副本、弹性扩容。

我一般会把模型的生命周期拆成两个阶段：第一个阶段是“能不能达到业务效果”，第二个阶段是“能不能用可接受的成本提供服务”。前端Demo只需要验证第一阶段，但大模型公司真正要长期做的是第二阶段。很多团队在第一阶段消耗了过多精力，到了第二阶段才意识到，手里的大模型没有配套的压缩方案，根本没法批量部署。

1.2 蒸馏是在“能力”和“运行成本”之间找一个可接受的点

知识蒸馏的核心思路不复杂：用一个能力较强的“教师模型”去指导一个体积更小的“学生模型”，让学生模型学习教师模型的输出行为，而不只是学习标注数据里的标准答案。教师模型不直接参与线上低成本推理，它主要负责“教”。

这种思路之所以有效，是因为标注数据通常只提供正确答案，但教师模型的概率分布里还带有“这个选项和另一个选项有多接近”的细粒度信息。学生模型学到这种分布后，能够在参数少很多的情况下保留大部分判断能力。

但蒸馏不是模型压缩的唯一手段。常见的还有量化、剪枝、低秩分解等。量化是把FP16权重变成INT8、INT4等格式，降低内存占用和计算量；剪枝是删掉一部分不重要的权重或结构；蒸馏则是训练出一个更小的新模型。它们可以结合使用，比如先蒸馏得到一个小模型，再对它做量化，最后部署到端侧或边缘设备。

如果不蒸馏，也不量化，那模型体积就是什么参数规模，服务成本就是什么量级。很多团队在初期不觉得有问题，是因为还在内部测试阶段，没有巨大的并发压力。一旦客户数量上来，推理成本会变成一项持续烧钱的开销。

1.3 不是所有公司都必须马上蒸馏

也要说清楚：不蒸馏本身不是错误。如果业务还在验证期，每天只有几十次调用，或者应用场景根本不追求低延迟、低部署成本，那大模型直接调用API反而是最快的方式。

需要重新评估不蒸馏代价的公司，通常有几个特征：

• 要直接向大量用户提供AI功能，单次调用成本会随着用户规模线性上升。
• 要做私有化交付，但客户机房没有高配GPU集群。
• 要做端侧或离线场景，例如手机、平板、嵌入式设备，模型体积必须严格控制。
• 要长期保留一定毛利，不能所有成本都靠补贴撑着。

如果这几个特征一个都不占，那确实可以先不做蒸馏。如果占了一半以上，就要尽快把蒸馏纳入模型工程路线，而不是等到账单爆炸才反应。

2. 不蒸馏的三张账单：GPU、延迟和运维

2.1 GPU账单：模型参数越大，卡数要求越离谱

可以先做一个非常粗的显存估算。以FP16权重为例，模型大概每10亿参数需要占用约2GB显存。那么一个70B模型，仅模型权重就可能超过140GB，单张80GB显存的卡根本放不下。即使能把模型放进多卡，KV Cache、激活值、推理框架的额外开销还会继续增加显存需求。

如果把模型换成7B或13B级别，部署压力会明显下降。7B模型权重大约14GB，经过量化后可以跑到消费级显卡上。这也是我之前强调的：大模型公司如果一直不做蒸馏，会发现自己永远在抢高端GPU。不是买不起一张卡的问题，而是为了一个任务买几十张卡，扩容和灾备成本都非常高。

更现实的是，线上服务不可能只部署一份模型副本。你要考虑并发上限和可用性，至少需要多副本。即使每份副本只部署一张大显存卡，一个峰值业务跑下来，卡的数量也会比小模型版本多很多倍。模型参数规模稍微增加，硬件预算不是线性增加，而是跳跃式增加，因为你可能从单机方案直接变成了多机分布式部署方案。

2.2 延迟账单：用户不关心模型多大，只关心响应多快

有人会觉得大模型虽然贵，但质量更好，慢一点可以接受。这个说法在B端离线任务里有时成立，但实时对话、搜索增强、智能客服、代码辅助这类场景不成立。

模型参数量增加后，单次推理不一定会线性变慢，但高并发一定会变慢。用户同时发来大量请求后，推理服务通常要拼batch处理。为了提升吞吐，系统会把多个请求打包在一起跑一次前向传播。batch越大，显存和算力消耗越大，单个请求等待处理的时间也会变长。如果模型本身已经占满显存，留给KV Cache和动态batch的空间就很小，系统只能排队或拒绝请求。

蒸馏出一个更小的学生模型后，同样的显存可能塞进更多batch，响应延迟和吞吐都能改善。这里的判断标准不是“第一句输出快不快”，而是P95、P99延迟，以及服务的最大并发承载能力。我曾经见过一个项目，教师模型效果评分高出不少，但在实际用户请求下，P95延迟超标严重，最后不得不降级到经过蒸馏的中等模型，反而把用户投诉降了下来。

2.3 运维账单：卡越多，出问题的面就越大

不蒸馏大模型的另一个隐性代价是运维复杂度。一个模型需要分布在多张卡甚至多台机器上，意味着要处理张量并行、流水线并行、通信同步、负载均衡、心跳监测、故障恢复等问题。模型越大，单点故障的影响范围也越大，重启恢复的时间也越长。

如果模型被蒸馏到单机甚至单卡可以承载的规模，运维模型会简单很多。加载更快，版本切换更快，复盘问题也更容易。市面上常见的推理工具比如vLLM、Ollama，在单机部署和低配置环境里往往能跑得很顺，但如果你塞给它一个超大模型，再大的工具也救不了硬件显存不够的事实。

我遇到过不少团队，部署脚本和模型压缩流程都是后补的。一开始直接拉大模型上线，结果监控大盘里GPU显存长期居高不下，并发一上来就OOM。后来不得不把模型换小，把量化打开，甚至重新训练一个小规模版本。早一点做模型选型和蒸馏方案，比在线上故障里被迫整改要省太多精力。

3. 不蒸馏会让交付边界变得非常窄

3.1 本地部署和私有化部署：客户不一定会买高端GPU

很多大模型公司做产品时，默认客户和开发者都能用几十张GPU跑模型。但真实的企业客户不是这样。他们可能有若干台普通服务器，甚至只有几块消费级显卡。私有化部署要交付的是一个能落地的系统，不是一个需要客户重新采购AI集群的Demo。

不蒸馏的最大问题，会让“三件套”全部变得很难：模型权重大、显存要求高、硬件门槛高。客户说“能不能部署到我们现有的机器上”，如果团队只能摇头，那这个单子大概率会黄。反过来，如果团队能提供一个十几B甚至更小的蒸馏模型，配合量化放到客户的推理环境里，虽然效果不如大模型，但客户看到的是“它跑起来了、能用、不额外花那么多钱”。

本地部署和私有化部署的核心逻辑不是追求极限效果，而是在客户约束下找到一个足够好的模型。模型蒸馏越早覆盖到交付流程里，方案能被接受的客户范围就越大。

3.2 端侧和嵌入式场景：模型体积直接决定能不能落地

端侧大模型是另一个被反复讨论的方向。手机上跑模型，第一要求不是效果，而是内存、发热、功耗和安装包体积。一个几十GB的模型，连设备都塞不进去。即便塞进去，推理一次可能让手机过热，使用体验也会非常差。

如果把大模型蒸馏成几十亿参数的小模型，再配合INT4量化，端侧才真正有可能跑起来。虽然它在复杂推理任务上可能不如云端大模型，但很多场景需要的是离线可用、隐私安全、低延迟。比如办公助手、会议纪要、移动端知识问答，数据不出设备本身就是一个很大的价值。

不蒸馏的大模型被排除在这些场景之外。这不是模型能力问题，而是产品形态问题。如果公司未来的产品路线包括端侧、嵌入式、离线终端，那模型压缩能力不是一种“加分项”，而是进入这些市场的前提条件。

3.3 免费API和低价产品：成本结构会成为最后的限制

现在很多开发者会调用各种免费或低价的大模型API来做应用。如果你是API的提供方，情况就不一样了。你既要保证模型有足够能力，又要让单次调用成本尽可能低，让产品在规模变大后依然有健康的毛利。

如果API后端直接跑一个超大模型，每次调用都在支付高额算力成本。短期可以靠融资和市场推广撑着，时间一长，用量越大亏损越多。这类业务尤其依赖模型蒸馏、量化、缓存、混合路由，让简单请求走小模型，复杂请求才走大模型。

“大模型必须能够有效处理大量请求并快速返回响应”不是一句口号，它是成本和架构设计出来的结果。大量请求意味着吞吐要足够高，快速返回意味着延迟要受控。在这两个指标面前，一个未压缩的大模型往往很难兼顾。更实际的路线是让少量复杂请求访问大模型，大部分普通请求走蒸馏后的小模型。

4. 如果决定蒸馏，先跑通最小验证流程

4.1 前置条件：教师模型和学生模型都要明确

很多团队一说蒸馏，就直接把模型和训练脚本拉起来跑，结果发现效果不理想，于是判断“蒸馏没用”。实际上，蒸馏不是一种“模型变小就自动不掉点”的魔法。它的效果依赖很多前置条件。

首先，教师模型要足够强，而且最好是已经针对目标任务做过微调或对齐的版本。如果你用一个很粗糙的基座模型当教师，学生模型学到的上限就会很低。其次，学生模型的选择要结合部署目标。如果最终产品要在手机上跑，那么学生模型应该是适合移动设备的体量级别。如果目标只是降低服务器成本，你的学生模型规模可以选一个折中点。

要留出蒸馏需要的训练数据、训练GPU和评测时间。蒸馏不是免费午餐，它要从教师模型获取成批输出，然后在训练集上跑多轮反向传播。如果团队连基础训练管线都没有，先把蒸馏流程搭起来可能要几周时间。这种情况下，可以先用市场上已有的开源小模型做对比，判断收益值不值得投入。

4.2 软标签、温度和Loss组合是关键

蒸馏训练常见的方式是让教师模型输出Logits，再用温度参数把Logits转换成更平滑的概率分布。温度越高，分布越平滑，不同类别的差异变得不那么尖锐，学生模型能学到“为什么有些错误选项看起来很像正确答案”。温度太低，软标签接近硬标签，学不到额外信息；温度太高，所有类别概率趋于均匀，信息又被冲淡了。

一个典型的Loss会同时包含软标签损失和硬标签损失。软标签损失让学生模型靠近教师模型的行为，硬标签损失保留真实答案的正确性。下面给一个示意性的训练循环，具体实现要以项目的框架和模型接口为准。

import torch import torch.nn.functional as F temperature = 4.0 alpha = 0.3 teacher_logits = teacher_model(batch["input_ids"]).logits student_logits = student_model(batch["input_ids"]).logits # 蒸馏损失：学习教师模型输出的概率分布 soft_loss = F.kl_div( F.log_softmax(student_logits / temperature, dim=-1), F.softmax(teacher_logits / temperature, dim=-1), reduction="batchmean", ) * (temperature ** 2) # 硬标签损失：保留真实标注的正确性 hard_loss = F.cross_entropy(student_logits, batch["labels"]) loss = alpha * soft_loss + (1 - alpha) * hard_loss loss.backward()

这里的alpha控制软标签的权重，temperature控制分布平滑程度。建议不要一开始就把alpha设为1，否则学生模型可能在硬指标上偏得太多。我一般先从0.3到0.5之间尝试，再结合评测结果调整。

4.3 用一小批数据先跑一轮

全量数据直接跑蒸馏，如果效果不理想，定位问题往往很困难。我会先挑几千条到几万条样本，覆盖线上高频场景，做一轮小规模蒸馏，然后对比教师模型、学生原始模型、蒸馏后学生模型三者的效果。

这个对比能解决一个很重要的问题：当前瓶颈到底是在蒸馏方法，还是在学生模型的表达能力。如果教师模型和学生原始模型差距巨大，蒸馏后也没有显著提升，那首先要怀疑学生模型选小了。如果教师给的数据本身质量有问题，比如输出格式混乱、存在幻觉，那就先改进数据，不要急着调参。

跑通小样本之后，再逐步放大数据量。这里不要急着堆大批量并发训练，先观察Loss是否下降、验证集效果是否稳定、有没有出现训练不收敛或灾难性遗忘。蒸馏是一个调优过程，不会因为一次训练多给数据就自动变好。

5. 蒸馏结果怎么评估，才算真的能上线

5.1 评测指标不只有效果榜单，还要看线上服务指标

蒸馏完成后，团队通常都会看效果是否掉点。但只盯着准确率或对话评测分数很难反映真实状况。我更建议把效果评测和压测放在一起看。

线上最容易感知的指标包括：P50响应延迟、P95/P99延迟、吞吐量（每秒生成token数）、显存峰值、最大并发请求数、失败率和OOM次数。一个模型效果掉了1分，但如果延迟从3秒降到1秒，并发承载能力翻倍，这个取舍在真实业务里很值得考虑。

如果只做离线评测，你只会得到“蒸馏后模型效果还行”的结论。到了线上，连续请求、长文本、超时重试、并发排队都会把模型弱点放大。所以我在评估蒸馏项目时，会专门准备一组长文本和极端输入，用来测试模型在边界条件下会不会崩。

5.2 蒸馏失败时，不要急着加更多数据

遇到蒸馏后效果不达标，第一步不是盲目增加训练数据，而是先定位问题。检查教师模型输出是否有明显错误或格式问题；检查学生模型是否训练充分；检查温度参数是否覆盖了几个不同值；检查训练数据和评测数据分布是否一致。

如果学生的模型能力明显不够，不如换一个更大的学生模型，而不是继续在小模型上硬挤。曾经有人把几十B模型蒸馏到1B模型，期望保留80%以上的能力，但任务又特别复杂，结果只能保留四五成。问题不在蒸馏不成熟，而是学生容量和任务难度不匹配。小模型不是不能做，但应该先降低任务粒度，或者接受它在复杂推理上的上限。

蒸馏后也可以再做一轮硬标签微调，让模型重新贴近真实标注。很多蒸馏模型在开放域生成时效果软绵绵，是因为过度拟合了教师分布。加入一部分强偏好数据的微调，症状通常会缓解。

5.3 蒸馏和量化、推理框架可以组合使用

蒸馏后的模型体积已经相对可控，但为了部署到更小显存或消费级设备，依然可以叠加量化。常见的做法是先蒸馏得到小模型，再对模型做INT8或INT4量化，最后交给vLLM、Ollama这类推理工具管理服务。

量化不是没有代价。有些模型在量化后会出现输出不稳定、幻觉增加或逻辑变差。所以不要以为只要INT4就一定比FP16省很多且效果不变。部署环境如果允许，先从更高精度开始，显存不够再逐步降精度，看看精度损失是否可以接受。

模型的缓存命中率也很重要。推理框架支持Prefix Caching或类似机制时，相同前缀请求可以复用KV Cache。模型变小之后，这个优势会更明显，因为Cache占用的显存变小，能缓存的用户前缀更多。如果只用大模型而不做任何压缩和缓存优化，服务框架的很多能力都发挥不出来。

6. 什么时候不该急着蒸馏，怎么把决策变成成本模型

6.1 模型还在快速变化时，过早蒸馏可能浪费

蒸馏需要稳定的教师模型。如果教师模型每隔半个月大改一次，蒸馏出来的学生模型很快又过时了，团队大部分时间都在重复蒸馏，研发成本很高。这种情况我更建议先以API或内部离线结果验证业务需求，等到模型效果进入稳定期再开始蒸馏。

如果你们目前只是一家想快速落地AI能力的创业公司，最要紧的是验证市场对产品的需求，不一定要把全链路模型压缩做得很重。先“调用大模型”并不丢人，关键是每季度复盘时发现调用成本成为主要支出时，要能快速切换到蒸馏方案。这需要平时就保留一批高质量标注数据和评测集，不然模型压缩根本没法启动。

6.2 把不蒸馏的代价变成一个可以对比的账单

很多公司讨论“要不要蒸馏”时会陷入感性的争论。一边说大模型效果更好，一边说成本太高，最后谁也没说服谁。我的建议是把问题量化为几个数字。

先统计线上日志：单次请求平均生成多少token、最大并发是什么水平、日均请求量是多少、P95延迟能否接受。再估算模型权重和显存：FP16大约每10亿参数2GB权重，量化后更少。然后估算当前需要多少GPU副本才能支撑高峰流量。有了这些数据后，不蒸馏的代价就不是“感觉很高”，而是一个具体到硬件和账单的问题。

一个粗略的判断逻辑可以参考下表。

需要说明的是，这只是权重估算，不是完整的线上部署推荐值。上下文越长，KV Cache占用越大，模型实际能处理的并发可能比估算更低。具体参数一定要结合自己的推理框架、量化方式和业务场景来测。

6.3 建立一个触发蒸馏的验收线

与其拍脑袋决定“现在要蒸馏”或“永不蒸馏”，不如提前设定几个触发条件。比如：

• 月度推理成本连续上涨超过预期，单位请求毛利持续下降。
• 新客户私有化部署时，现有模型在客户硬件上跑不起来。
• 日志显示P95延迟明显超标，GPU显存不够或OOM次数增多。
• 产品明确要往端侧、离线、嵌入式方向走。
• 模型版本已经稳定了两到三个月，业务指标没有频繁变化。

一旦触发其中任何一条，就该让模型工程团队和算法团队坐下来，核算蒸馏的投入产出。蒸馏本身需要数据准备、训练时间和评测成本，但如果它能让单位请求成本下降一半，同时扩大可交付的客户范围，这笔投入通常很值得。

我见过太多项目把蒸馏拖到“已经上线了大模型，成本爆了才补做”。结果不仅要从零准备蒸馏数据，还要在线上同时维护新旧两套模型，试错成本比一开始就做蒸馏更高。反过来看，早早准备好评测集，把蒸馏纳入模型选型流程，后续切换就不会像是救火。

真正该问的不只是“不蒸馏有什么代价”，而是“在什么条件下，我应该开始为蒸馏买单”。模型蒸馏不是每个阶段都必须做，但一家长期运营大模型能力的公司，确实应该有系统评价“不蒸馏是否划算”的方法。算不清楚这笔账，模型能力再强，也很难变成稳定可持续的产品竞争力。