企业官网建设流程全解析

最近这段时间，我几乎每天都要回答同一个问题，而且提问的人从刚入行的实习生到带十几人团队的负责人都有。问题听起来特别简单：“这几个模型到底有什么区别，我该用哪个？”问的人以为这是一道选择题，实际上它是一道应用题——你手上的数据能不能出域、你每个月的预算是多少、你能不能在凌晨三点爬起来重启服务，这三个答案一变，“哪个模型好”的结论就完全不一样。

这是这个系列的第一篇，标题里的“三个模型”不是随便凑的数。我把日常能调用的模型按获取方式和可控程度切成了三类：闭源商业模型、开源权重模型、以及拿开源底座微调出来的私有模型。这三类东西在成本结构、数据边界、迭代节奏上完全是三种生物，把它们塞进一张表里比“谁更聪明”，就像拿出租车、私家车和改装车比“谁更快”一样没有意义。这篇不讲论文，只讲人话，把我这几年在模型选型和模型部署上算过的账、踩过的坑、写过的配置都摊开说。看完你应该能自己回答：我的场景该从哪一类开始试，什么时候该换。

1. 为什么先分类，而不是先去排行榜上比分数

1.1 排行榜回答的是“别人觉得谁好”，不是“你的活谁干得动”

模型竞技场那类投票榜单，本质是让人在不知道模型身份的情况下，对两个回答做偏好二选一。它衡量的是人类整体偏好，这个指标有价值，但它有一个绕不开的偏差：投票的人不是你，他们手上的任务也不是你的任务。如果你做的是从一千份合同里把关键字段抠出来，榜单前三名的模型可能都输给一个认真调过提示词的二线模型。

我自己做过一次内部对照，同一个信息抽取任务，某头部闭源模型零样本准确率 82%，加了 12 条少样本示例之后涨到 91%；某个开源 14B 模型零样本只有 63%，同样加示例能到 84%。注意这个变化：差距在“零样本”状态下被放大了，在“认真做提示工程”之后被压缩了。榜单给你的是起点，不是终点，它最大的用处是帮你排除掉明显不行的候选，而不是替你拍板。

1.2 我的分类标准只有两条：权重在谁手里，你能不能改

第一条决定数据边界，第二条决定天花板。权重放在厂商的服务器上，你的输入必然出域，你能改的只有提示词和调用参数；权重能下载到自己的机器上，数据不出域，但显存、并发、版本升级全得你自己扛；如果你在开源权重的基础上再喂自己的数据做微调，那模型的“性格”和“知识”就有一部分是你的资产了，代价是它以后变傻，也是你的责任。

这三条线一画，后面所有关于价格、延迟、安全、可维护性的讨论都能挂上去，不会东一榔头西一棒子。我再补一句：分类是为了做决策，不是为了贴标签。同一个团队里三类模型同时存在是常态，不是不专一。

2. 第一类：闭源商业模型，买的是“马上能用的最强手感”

2.1 它真正值钱的地方不是参数量，而是对齐和工程

很多人以为闭源模型贵在参数多，其实参数只是入场券。真正难复刻的是训练之外的那堆脏活：指令跟随的稳定性、长上下文里不丢信息、工具调用时 JSON 格式几乎不出错、遇到越界请求能体面拒绝、流式输出不断流、高峰期并发不雪崩。这些东西单看每一条都不起眼，合起来就是“手感”。

我在做多轮对话类的功能时对这点体会特别深。同一套提示词，开源 14B 模型前两轮表现很好，到第四轮开始把用户第一轮说的条件忘了，或者把工具返回的结构改了个字段名，前端直接报错。闭源模型在这类长尾场景上的容错率明显高一档，你省下来的不是推理成本，是调试时间。团队里如果没有专门做模型工程的人，这部分的差距会直接变成项目能不能按时交付的差距。

2.2 什么情况下它是唯一正解

第一，数据本身不敏感，处理的都是公开信息或者本来就要对外发布的内容，出域不是问题。第二，处在早期验证阶段，老板要的是“这周能不能看到效果”，这时候花两周搭推理环境是最亏的买卖。第三，任务长尾严重，什么类型都要会一点，比如一个通用助手，你没法为每种问法单独训一个模型。第四，团队里没人愿意半夜起来看 GPU 日志。

这四种情况只要命中两种，我的建议都是先用闭源模型把流程跑通，把提示词、评测集、产品形态都定下来。等业务真的跑起来了、数据量真的上来了，再去算自部署这笔账。反过来做的团队，我见过太多：一上来就折腾环境，折腾完发现产品需求变了，白干。

2.3 钱到底是怎么烧掉的：一次真实的成本测算

光说“贵”没有意义，我们把数字摆出来。假设一个功能日均 8000 次请求，输入平均 1800 token，输出平均 400 token。那么每天的输入量是 8000 × 1800 = 1440 万 token，输出量是 8000 × 400 = 320 万 token。按某档位常见的输入 3 元/百万 token、输出 15 元/百万 token 来算，一天是 43.2 元加 48 元，约 91 元，一个月大约 2700 元。

看起来不贵？那你把请求量乘以十，再把输入里的系统提示词和检索回来的文档算进去，输入量往往是输出的五到十倍。这时候几个动作就非常关键了：提示词缓存能把重复的长前缀价格打下来一大截；按任务降级把简单的分类、改写、纠错交给便宜的小模型；输出长度约束让模型别写小作文。我在一个项目里只做了这三件事，账单从每月四万多降到一万六，效果没有可感知的下降。

2.4 用闭源模型前必须想清楚的三个坑

第一是限流。你以为你有无限并发，实际上高峰期会排队，产品上表现为“偶尔转圈很久”，这种偶发问题最难排查。第二是版本静默更新。厂商升级模型不会提前一周给你发通知，你的提示词某天早上突然不好用了，如果你没有记录请求时用的模型版本号，这个锅你都不知道该甩给谁。第三是数据条款，尤其是涉及用户隐私的业务，合同里的数据处理说明要一个字一个字看，别默认“大家都这么用所以没事”。

3. 第二类：开源权重模型，买的是“可控和可折腾”

3.1 权重、safetensors、量化，这三个词到底在说什么

我用生活化的方式解释一遍。权重就是模型的大脑切片，一堆数字矩阵，本身没有任何执行逻辑。safetensors是一种存放切片的保鲜盒格式，它比早期那种基于序列化的格式加载更快，而且只存张量不执行代码，拿到的文件相对更让人放心。量化是把原本用 16 位浮点存的数字压成 8 位甚至 4 位整数，好处是显存和带宽需求直接砍半再砍半，坏处是模型的“手感”会掉一点，掉多少取决于量化的方法和校准数据。

这三个词连起来就是一句话：你把保鲜盒从别人的冰箱搬到自己冰箱，顺手把切片压薄一点好塞进去。理解了这句，后面所有关于部署的讨论都不难了。

3.2 显存怎么算，我给你一个能背下来的公式

推理显存大致等于：参数量 × 每参数字节 + KV Cache + 框架开销。每参数字节这一项，FP16/BF16 是 2 字节，INT8 是 1 字节，INT4 是 0.5 字节。所以 7B 模型用 BF16 加载，光权重就要 14GB；用 INT4 加载，大约 3.5 到 4GB。加上 KV Cache 和一两 GB 的框架开销，一张 24GB 的卡跑 7B 的 BF16 是刚好够的，跑 14B 的 INT4 也很舒服，但想跑 70B 的 BF16 就得四张卡起步。

KV Cache 才是真正容易被忽略的部分，它的公式是：2 × 层数 × KV 头数 × 头维度 × 序列长度 × 批大小 × 字节数。举个例子，一个 32 层、KV 头数 8（用了分组查询注意力）、头维度 128 的 7B 模型，跑 8192 上下文、批大小 8，BF16 存储，算出来大约是 8GB。如果你把这个模型的 KV 头数改回 32，同样的配置就是 32GB，一张 24GB 的卡直接爆掉。这就是为什么现在几乎所有的开源模型都在用分组查询注意力，它不是学术上的小技巧，它是省钱的。

3.3 开源模型真实的短板，别只听宣传

第一，长尾指令跟随明显偏弱，尤其是那些“既要格式对，又要语气对，还要不许瞎编”的复合要求。第二，多轮一致性差一些，聊到第五轮开始自我矛盾。第三，工具调用的格式偶尔跑偏，少一个括号或者多一层嵌套，前端就崩。第四，上下文一长就容易“忘”，不是它不想记，是注意力被稀释了。第五，安全过滤要自己加，开源的系统提示词拦不住的请求比你想的多。第六，升级没有银弹，权重更新了，你的提示词和评测集都要重新跑一遍。

这些短板不致命，但它们决定了开源模型更适合放在流程可控、输出可校验的位置上，而不是直接对着终端用户做开放式闲聊。我一般会把开源模型放在批处理、数据标注、内部工具、格式转换这些场景里，出错可以重试，代价可控。

3.4 一个能跑起来的最小部署示例

下面这段是我在单卡 24GB 机器上常用的启动方式，用的是 AWQ 量化权重，参数我逐条解释。

python -m vllm.entrypoints.openai.api_server \ --model ./models/your-model-AWQ \ --quantization awq \ --gpu-memory-utilization 0.90 \ --max-model-len 8192 \ --tensor-parallel-size 1 \ --max-num-seqs 16 \ --port 8000

--gpu-memory-utilization 0.90控制显存占用上限，留 10% 给系统和其他进程，别贪心调到 0.98，很容易在流量高峰时 OOM。--max-model-len要和模型训练时的上下文长度对齐，写大了会让 KV Cache 预留过多，可服务的并发数反而下降。--max-num-seqs是同时处理的序列数，这个值决定了吞吐和单请求延迟的平衡点，我一般从 8 开始往上试，找到延迟还能接受的最大值。--tensor-parallel-size在多卡时才需要调，单卡保持 1。

注意：量化权重的加载速度比 BF16 快很多，但精度损失是真实存在的。上线前一定要用你的业务评测集跑一遍，不要拿通用榜单的分数当依据。

4. 第三类：私有微调模型，买的是“懂你的业务”

4.1 先别急着微调，先回答三个问题

第一个问题：把系统提示词写扎实，再给十几条少样本示例，能不能达到 80 分的水平？如果能，微调的收益很小。第二个问题：模型现在缺的到底是“知识”还是“表达方式”？缺知识，指的是它不知道你公司内部的产品参数、审批流程、话术规范，这种用检索增强就能解决，把资料塞进上下文；缺表达方式，指的是它知道内容但说话不对味，输出格式总是差一点，这种才适合微调。

第三个问题：你手上有没有至少五百到两千条高质量样本？注意是高质量，不是从聊天记录里随便导出两千条。我在一个项目里试过用脏数据微调，结果模型学会了把用户的错别字也一起复述出来，效果比微调前还差。一句话总结：微调擅长教模型“怎么说”，检索擅长告诉模型“说什么”，这两件事别搞混。

4.2 微调实操：数据长什么样，参数怎么定

数据一般用 JSONL，每行一条样本。我们做格式和风格微调时，最常用的是指令-输出对，下面是一条我实际用过的结构。

{"instruction": "把下面的会议纪要整理成三条待办，每条以动词开头，不超过20字。", "input": "老王说下周三前把接口文档补齐，小李负责联系供应商确认报价，另外测试环境需要再申请一台机器。", "output": "补齐接口文档\n确认供应商报价\n申请测试环境机器"}

参数上我有一组比较稳的起点：LoRA 的 rank 从 16 开始试，任务简单可以降到 8，风格模仿复杂可以升到 64；学习率 1e-4 到 2e-4，再大容易把底座能力冲坏；训练轮数 2 到 3 轮，超过 3 轮基本就是过拟合背样本；截断长度按你数据的第 95 百分位来定，别一上来就设 8192，显存和速度都会很难看。

lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 learning_rate: 1.5e-4 num_train_epochs: 3 cutoff_len: 2048 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 gradient_checkpointing: true

显存怎么估算？7B 模型做 LoRA 微调，权重加载占 14GB（BF16），LoRA 本身的可训练参数很少，优化器状态也就几百 MB，真正吃显存的是激活值。开了梯度检查点之后，24GB 的卡跑 7B、批量 2、截断 2048 是能跑起来的。如果你想在单卡上更宽裕一点，用 4 位量化加载底座，权重直接降到 4GB 左右，但量化和训练叠加会有额外的精度损失，这个取舍要自己权衡。

4.3 训完之后怎么判断它没变傻

这是最多人忽略的一步。微调有个典型副作用叫灾难性遗忘：格式学会了，但通用能力退化了，你问它一道常识题它开始胡说。所以我会准备三套评测。第一套是业务评测集，两百条左右，人工按评分细则打分；第二套是通用能力回归集，几十条常识和指令跟随的问题，防止它退化成只会干一件事的机器；第三套是格式合规率，直接用程序解析输出，看 JSON 或指定结构的解析成功率是多少。

上线要留后路。请求头里带上模型版本号，服务端做灰度，先放 5% 的流量，观察一周再放全量。回滚开关必须是配置层面的，不能靠重新发版。我之前吃过一次亏，微调模型上线第一天效果很好，第二天开始出现奇怪的重复输出，最后定位是某个批次的训练数据里有大量重复样本，回滚花了两小时，如果没有开关，那天晚上就别想睡了。

5. 三类模型放一起怎么选：一张表加一条决策路径

5.1 横向对比：能力、成本、延迟、可控性

看这张表你会发现一个规律：越往下走，可控性越高，但你要承担的责任也越多。这不是优劣排序，这是责任转移。很多团队的问题不在于选错了模型，而在于没意识到自己从“用户”变成了“运维”。

5.2 按团队情况走的三条路径

个人或者小团队在验证期，我的建议是闭源为主，把提示词工程做扎实。这个阶段你的瓶颈是想法跑得不够快，不是每千 token 便宜了两毛钱。等你确定要做下去，再考虑把批量任务挪到自部署。

中型团队并且有合规要求，比较舒服的组合是闭源模型守住能力上限，用在那些需要复杂推理、需要兜底的关键路径上；开源模型承接批量数据处理、内部工具、敏感数据的预处理。这两条线用统一的接口协议封装，切换成本就很低。

有数据资产并且业务垂直的团队，才值得走“开源底座加微调加路由”这条路。注意顺序：先把检索和提示词做到位，再上微调；先跑通一个场景，再复制到第二个场景。一上来就想训一个全能模型的团队，我没见过成功的。

5.3 多模型协作：把贵的用在对的地方

一个成本优化效果很好、实现又不复杂的做法是加一层路由。先用一个很小的分类模型或者规则，把进来的请求分到“简单”和“困难”两个桶里。简单桶交给便宜的模型甚至小模型，困难桶才走大模型。我在一个客服场景里做过统计，大约八成请求落在简单桶，整体成本降了六成以上，用户侧几乎感知不到差异。

再进一步是模型蒸馏。让强模型对你的业务数据生成大量高质量回答，再用这些回答去微调一个小的开源模型。这条路的前提是你有足够的业务输入分布，否则蒸馏出来的小模型只会在你采样过的那几种问法上表现好。蒸馏的本质是把强模型的知识压缩到小模型里，压缩比越高，长尾丢得越多，这一点要有心理预期。

6. 踩坑记录：新手最容易搞混的几件事

6.1 常见问题速查表

6.2 几条我反复验证过的实操心得

第一条，先用最强的模型把任务上限摸出来。很多人为了省钱直接用便宜模型开工，结果调了半天以为是提示词问题，其实是从一开始就选错了工具。先用贵的跑二十条样本，看看这个任务到底能做到什么水平，心里有底了再往下换。

第二条，评测集比模型重要。你手上如果有两百条带标准答案的业务样本，换模型这件事就变成了跑一遍脚本看分数，决策速度完全不一样。没有评测集，你所有的模型选型讨论都会变成感觉之争。

第三条，量化不是免费的。4 位量化能让你在单卡上跑更大的模型，但它在数值推理、长输出、复杂指令上的损失比宣传的要明显。我的做法是量化模型只用在批处理和格式转换上，需要推理的路径尽量留 BF16。

第四条，别乱调温度。很多“模型不稳定”的抱怨，根源是温度设成了 1.0 甚至更高。做抽取、分类、结构化输出，温度压到 0.1 到 0.3；只有写文案这类需要发散的场景才往上调。

6.3 最后说两个我自己踩过的坑

第一个是版本号。我早期做的服务没有记录模型版本，某次升级后一批提示词集体失效，排查了一整天才意识到是上游静默换了版本。从那以后我的请求日志里一定带模型标识和版本，评测集也每周自动跑一次，异常就报警。

第二个是微调数据的重复率。我以为样本多就是好，导了两万条进去，后来发现里面有大量重复和近似重复的样本，模型学会了复读。现在我一定会先跑一遍去重和长度分布统计，再决定用哪一批数据。踩过这两次之后，我的习惯变成：能靠提示词解决的绝不上微调，能靠检索解决的绝不上微调，真要微调，先把评测集和回滚开关准备好再动手。