ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

大模型选型与部署:闭源、开源权重、私有微调的决策指南

大模型选型与部署:闭源、开源权重、私有微调的决策指南 最近这段时间我几乎每天都要回答同一个问题而且提问的人从刚入行的实习生到带十几人团队的负责人都有。问题听起来特别简单“这几个模型到底有什么区别我该用哪个”问的人以为这是一道选择题实际上它是一道应用题——你手上的数据能不能出域、你每个月的预算是多少、你能不能在凌晨三点爬起来重启服务这三个答案一变“哪个模型好”的结论就完全不一样。这是这个系列的第一篇标题里的“三个模型”不是随便凑的数。我把日常能调用的模型按获取方式和可控程度切成了三类闭源商业模型、开源权重模型、以及拿开源底座微调出来的私有模型。这三类东西在成本结构、数据边界、迭代节奏上完全是三种生物把它们塞进一张表里比“谁更聪明”就像拿出租车、私家车和改装车比“谁更快”一样没有意义。这篇不讲论文只讲人话把我这几年在模型选型和模型部署上算过的账、踩过的坑、写过的配置都摊开说。看完你应该能自己回答我的场景该从哪一类开始试什么时候该换。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 上下文、批大小 8BF16 存储算出来大约是 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 微调权重加载占 14GBBF16LoRA 本身的可训练参数很少优化器状态也就几百 MB真正吃显存的是激活值。开了梯度检查点之后24GB 的卡跑 7B、批量 2、截断 2048 是能跑起来的。如果你想在单卡上更宽裕一点用 4 位量化加载底座权重直接降到 4GB 左右但量化和训练叠加会有额外的精度损失这个取舍要自己权衡。4.3 训完之后怎么判断它没变傻这是最多人忽略的一步。微调有个典型副作用叫灾难性遗忘格式学会了但通用能力退化了你问它一道常识题它开始胡说。所以我会准备三套评测。第一套是业务评测集两百条左右人工按评分细则打分第二套是通用能力回归集几十条常识和指令跟随的问题防止它退化成只会干一件事的机器第三套是格式合规率直接用程序解析输出看 JSON 或指定结构的解析成功率是多少。上线要留后路。请求头里带上模型版本号服务端做灰度先放 5% 的流量观察一周再放全量。回滚开关必须是配置层面的不能靠重新发版。我之前吃过一次亏微调模型上线第一天效果很好第二天开始出现奇怪的重复输出最后定位是某个批次的训练数据里有大量重复样本回滚花了两小时如果没有开关那天晚上就别想睡了。5. 三类模型放一起怎么选一张表加一条决策路径5.1 横向对比能力、成本、延迟、可控性对比项闭源商业模型开源权重模型私有微调模型单位调用成本按量付费随量线性增长主要为硬件折旧与电费硬件成本加训练与标注成本首字延迟受网络与厂商排队影响本地推理稳定可控与基础开源模型接近通用能力最强中上可能低于底座垂直任务能力需要靠提示词拉需要靠提示词拉明显高于底座数据边界出域不出域不出域迭代节奏厂商说了算你说了算你说了算但要自己评测适合阶段验证期、通用助手批处理、内部工具垂直业务、规模化看这张表你会发现一个规律越往下走可控性越高但你要承担的责任也越多。这不是优劣排序这是责任转移。很多团队的问题不在于选错了模型而在于没意识到自己从“用户”变成了“运维”。5.2 按团队情况走的三条路径个人或者小团队在验证期我的建议是闭源为主把提示词工程做扎实。这个阶段你的瓶颈是想法跑得不够快不是每千 token 便宜了两毛钱。等你确定要做下去再考虑把批量任务挪到自部署。中型团队并且有合规要求比较舒服的组合是闭源模型守住能力上限用在那些需要复杂推理、需要兜底的关键路径上开源模型承接批量数据处理、内部工具、敏感数据的预处理。这两条线用统一的接口协议封装切换成本就很低。有数据资产并且业务垂直的团队才值得走“开源底座加微调加路由”这条路。注意顺序先把检索和提示词做到位再上微调先跑通一个场景再复制到第二个场景。一上来就想训一个全能模型的团队我没见过成功的。5.3 多模型协作把贵的用在对的地方一个成本优化效果很好、实现又不复杂的做法是加一层路由。先用一个很小的分类模型或者规则把进来的请求分到“简单”和“困难”两个桶里。简单桶交给便宜的模型甚至小模型困难桶才走大模型。我在一个客服场景里做过统计大约八成请求落在简单桶整体成本降了六成以上用户侧几乎感知不到差异。再进一步是模型蒸馏。让强模型对你的业务数据生成大量高质量回答再用这些回答去微调一个小的开源模型。这条路的前提是你有足够的业务输入分布否则蒸馏出来的小模型只会在你采样过的那几种问法上表现好。蒸馏的本质是把强模型的知识压缩到小模型里压缩比越高长尾丢得越多这一点要有心理预期。6. 踩坑记录新手最容易搞混的几件事6.1 常见问题速查表现象可能原因处理方向昨天还好好的提示词今天失效厂商静默更新模型版本记录并固定模型版本号建回归评测集高峰期请求大面积超时触发了厂商限流加本地队列、降级到小模型、错峰批处理自部署服务频繁 OOM显存预留过满或并发设太高调低显存利用率与最大序列数微调后通用能力下降学习率过大或轮数过多降学习率、减轮数、加通用回归评测输出 JSON 解析失败模型格式跟随不稳定加少样本示例、用结构化输出约束、加解析重试成本比预期高一倍输入 token 被系统提示词撑大压缩提示词、启用前缀缓存、限制输出长度6.2 几条我反复验证过的实操心得第一条先用最强的模型把任务上限摸出来。很多人为了省钱直接用便宜模型开工结果调了半天以为是提示词问题其实是从一开始就选错了工具。先用贵的跑二十条样本看看这个任务到底能做到什么水平心里有底了再往下换。第二条评测集比模型重要。你手上如果有两百条带标准答案的业务样本换模型这件事就变成了跑一遍脚本看分数决策速度完全不一样。没有评测集你所有的模型选型讨论都会变成感觉之争。第三条量化不是免费的。4 位量化能让你在单卡上跑更大的模型但它在数值推理、长输出、复杂指令上的损失比宣传的要明显。我的做法是量化模型只用在批处理和格式转换上需要推理的路径尽量留 BF16。第四条别乱调温度。很多“模型不稳定”的抱怨根源是温度设成了 1.0 甚至更高。做抽取、分类、结构化输出温度压到 0.1 到 0.3只有写文案这类需要发散的场景才往上调。6.3 最后说两个我自己踩过的坑第一个是版本号。我早期做的服务没有记录模型版本某次升级后一批提示词集体失效排查了一整天才意识到是上游静默换了版本。从那以后我的请求日志里一定带模型标识和版本评测集也每周自动跑一次异常就报警。第二个是微调数据的重复率。我以为样本多就是好导了两万条进去后来发现里面有大量重复和近似重复的样本模型学会了复读。现在我一定会先跑一遍去重和长度分布统计再决定用哪一批数据。踩过这两次之后我的习惯变成能靠提示词解决的绝不上微调能靠检索解决的绝不上微调真要微调先把评测集和回滚开关准备好再动手。
返回列表