干了这么多年大模型落地我越来越觉得选型这事儿被带偏了。打开任何一张模型排行榜往上翻的永远是那些参数最大、跑分最高的巨无霸评论区里的讨论也集中在XXX比XXX高了多少分这种数字游戏上。但真到了自己手里那点任务——不管是做客服问答、写行业报告还是让一台普通电脑跑个私有小模型——跑分高和好用之间隔着好几条街。我给自己定了个规矩选模型不看排行榜先问三个问题你的任务到底是什么模型会跑在什么硬件上你要不要改它这三个问题想明白了选型清单基本就自己列出来了根本不用在跑分榜上纠结到失眠。这篇内容我打算把我这些年踩过的坑和总结出来的选型方法论完整写出来不堆术语只讲人话覆盖云端API和本地部署的常见场景。1. 跑分为什么是选型里最没用的指标1.1 评测集测的是考试能力不是干活能力任何一个公开榜单都在衡量模型在标准考试里的表现。MMLU测知识广度HumanEval测代码能力GSM8K测数学推导这些评测集不是说没有价值问题是它们跟真实用户的真实任务完全不是一回事。真实场景里没有人为你设定好唯一的提问模板也没有人帮你清理掉问题里多余的噪声。更麻烦的是评测集本身是会污染的。开源模型在预训练阶段就把评测集文本喂进去这在业内不算秘密。很多模型的高跑分其实只是它在报考前就拿到了标准答案真拿到没见过的任务上效果立刻打回原形。我测试过一个榜单前几名的模型和一个小体量模型在同样的工单分类任务上的表现前者稍改措辞就分错类后者反而稳定得多。这种落差单看跑分是完全看不出来的。1.2 跑分环境和你实际的部署环境根本不是一回事你看到榜单上跑出来的数字背后往往是满血版模型配上一排顶级显卡推理框架还专门调过优化参数。但你真去部署的时候通常要考虑三件事显存够不够、延迟能不能忍、成本划不划算。于是你量化、剪枝、用低精度加载这一套组合拳打下来模型的真实能力早就和榜单上的原版不是一个东西了。我实测过很多次量化前后的对比。4bit量化对大多数任务掉点控制在两三个点之内但代码生成和多步推理这类任务掉点可以拉到十个点以上。也就是说同一个榜单数字在人家满血环境里体现的能力和你在自己硬件上拿到手的能力中间隔着一整条推理优化链。你拿榜单分数去预判实际效果等于拿汽车厂商的实验室油耗预判早晚高峰的真实油耗。1.3 跑分无法告诉你这件衣服合不合身跑分是平均数思维它把所有任务混在一起算出一个总分。但没有一个真实用户的需求是平均任务——你要么在处理垂直行业的专业知识要么在生成特定风格的文案要么在做多轮复杂对话。平均数掩盖的都是极端差异。举个直观的例子。一个模型可能在通用聊天上表现平平但在特定代码库上下文里的补全能力极强另一个模型跑分更高却在你的领域术语上一窍不通。跑分榜根本反映不出这种个体差异。所以我现在选型时都要求团队带上自己的真实样本去测人数不多二三十条就够但必须覆盖典型难点。用真实业务数据测出来的结果比什么榜单都有说服力。2. 第一个问题你的任务到底是什么2.1 先给任务翻译成模型能力我常说一句话大模型不吃你的任务描述它吃的是能力需求。所谓选型本质上是把你业务里的任务翻译成模型的能力子集再去找那个能力子集和模型特性的交集。翻译的方法很简单问自己几个子问题任务需要模型输出什么形态的结果问答、摘要、代码、JSON结构、还是多轮对话任务对输入的包容度要求有多高是固定模板还是用户随手敲进来的自由文本任务里有没有视觉需求需要看图片、文档扫描件还是截图表单任务对正确性的要求有多高容忍差不多还是必须精确到能直接跑把这几个子问题答完你就能得出模型的几个硬指标参数量的下限、是否必须多模态、上下文窗口要多大、是否需要工具调用能力。这些指标一框定候选名单就从几十个缩小到三五个了。2.2 参数量不是越大越好够用才行大模型社区里有一个集体性的误解参数越多越聪明所以选型就是选最大号的。这个逻辑在云API层面有一定道理因为算力是服务商兜着的你按调用量付费上大模型没毛病。但一旦落到本地部署或者需要控制成本的场景大参数就是双刃剑。我习惯把模型能力按参数量大致分成三档分别对应不同的任务复杂度模型规模典型参数量适合任务部署门槛轻量级1B~8B简单问答、意图识别、摘要、分类、格式转换桌面级显卡甚至纯CPU都能跑中级13B~32B复杂写作、长文档理解、代码辅助、Agent工具调用需要一张24GB显存级别的显卡或量化部署重量级70B以上深度推理、复杂金融分析、科研辅助、全局理解多卡集群或依赖云端API判断你用哪一档不要看问问题有多难要看回答需要绕多少步。单步能答上来的问题8B模型足够了需要先推理再组织方案的路子考虑用中级档需要跨段落整合大量信息再给出结论的基本得靠重量级。我见过不少团队用70B模型跑一个简单的关键词抽取任务效果没比7B模型好多少成本和延迟倒是翻了十倍这就是典型的能力错配。2.3 多模态需求会直接砍掉一半候选如果你需要模型理解图片、图表、文档排版或视频帧那选型范围会一下子缩小很多。纯文本模型全部出局剩下的多模态模型里还得再看视觉编码器的能力和推理层的融合程度。很多人在这一步会犯一个错误只看模型是不是带眼睛不看它怎么看东西。实际上文档解析和通用图片理解是两种完全不同的能力。比如工业质检场景模型要看的是微小的缺陷特征这种需求普通多模态模型根本hold不住往往需要专门训练的视觉模型配合回去而财务报销单识别这种大部分人都需要的场景反而通用的多模态模型就够了。先搞清楚视觉需求的颗粒度再决定上不上多模态、上哪个级别的多模态这是我给所有选型人的建议。3. 第二个问题模型会跑在哪里3.1 三种部署模式先想清楚再动资源部署模式基本决定了你选型的天花板。我把所有情况归成三类每类的约束条件完全不同。第一类是纯云API模式。自己一台GPU都没有直接用服务商提供的API。这种模式的好处是模型能力上限最高不用担心显存成本灵活按量付费代价是数据出域敏感信息慎用而且长期高频调用下来费用不低。适合快速验证想法、商业敏感度不高的场景。第二类是本地单机部署。跑在个人电脑或一台工作站上典型方案就是用Ollama这类工具拉起一个本地推理服务。这种方式我试过很多次体验相当丝滑配置好之后一条命令就能把开源模型跑起来尤其Windows 11环境下配合那几个主流的量化版本一套流程十分钟就能通。适合数据不能出内网、追求一次投入长期免费的存量场景。第三类是企业级私有化部署。要求在高并发、多用户环境下稳定提供推理能力通常用vLLM这类高性能推理框架来榨干GPU的吞吐量配合负载均衡和API网关做服务治理。这是成本最高、工程复杂度最大的形态但也是政企环境下唯一合规的选择。3.2 显存估算选本地部署前必须算清楚的账本地部署最怕的就是模型刚下好加载时OOM了。显存怎么估算我有自己的一套方法。核心公式是显存占用约等于模型参数量乘以每参数字节数。FP16精度下每10亿参数大约占2GB显存INT8量化后大约占1GBINT4量化后大约占0.5GB。以7B模型为例FP16全精度跑大概要吃14GB显存量化到INT4就只需约4GB。再加上KV Cache和运行时开销保险起见要在此基础上多留出20%-30%的余量。8GB显存的显卡适合跑1B到8B的量化模型极限是7B的INT4版本16GB显存适合跑14B的量化版或者7B配上更大的上下文窗口24GB显存主流甜点区32B量化版和14B全精度都能跑40GB以上可以挑战70B的量化版本很多教程会直接告诉你用4bit量化就行但你要搞清楚为什么是4bit不是8bit。根本原因是显存容量不够时的被迫妥协。如果显存充足我从来都是优先用FP16或8bit因为推理质量更稳尤其是需要输出长文本、多步推理的任务。量化是为了能跑不是为了让效果更好这个先后次序别搞反了。提示换显存之前先算KV Cache的消耗。上下文越长KV Cache占的显存越多。同样是32B模型2K上下文和32K上下文的显存需求差距可以大到4GB以上。3.3 推理框架怎么选本地部署验证阶段Ollama是公认的省心选择安装、拉模型、跑服务三步走兼容性也最好。但它追求的是轻量和易用在高并发场景下性能上限一般吞吐量和批处理效率都不如专门的推理服务框架。生产环境我更推荐用vLLM。它的核心优势在于PagedAttention机制——把KV Cache按页管理大幅提升显存利用率和吞吐量实测在同样的GPU上能把并发数翻几倍。代价是配置复杂一些需要写启动参数、做模型配置、设计API接口学习成本明显高于Ollama。如果你是抱着学习目的去研究推理内部机制的nano-vllm这类教学框架反而更值。它会把你vLLM里的关键步骤拆成可以阅读的代码逐个对照算子和显存行为对于想搞懂大模型推理为什么这么吃显存的人比直接用生产框架黑盒跑一遍要有效得多。选框架之前先想清楚自己的阶段个人体验用Ollama生产服务用vLLM学习原理用教学框架。4. 第三个问题你要不要改模型4.1 提示词工程能解决的事别急着上微调第三个问题很多人会答错。我遇到的最常见场景是模型效果不满意第一反应就是微调。但多数情况下问题根本不在模型权重而在于你没把任务边界讲清楚。这一步做到位绝大多数效果问题都能解决。我现在的策略是分层递进先用提示词工程然后是上下文工程这两层搞不定才考虑RAG和微调。提示词工程解决的是让模型理解指令的问题上下文工程解决的是让模型获得足够信息的问题。一个只靠对话就完成任务的应用场景你给模型喂足够的背景知识和示例比你去改模型权重便宜得多也快得多。举个例子。我之前做一个会议纪要总结的功能直接丢给模型效果很差总结出来全是流水账。我没有急着微调而是先拆解任务明确输出结构、加上提取决策项等规则、给两条优秀示例。同样的模型一周之内效果从没法看变成基本可用。4.2 RAG和微调的分界线上下文工程再往上走你会发现单条输入里塞不下所有知识这时就是RAG检索增强生成和微调的分岔路口。我判断两者的标准很简单改知识用RAG改能力用微调。所谓知识指的是事实性内容——公司的规章制度、专业领域术语、产品文档细节。这类信息更新快、数量大、不宜固化成模型权重最合适的做法是把它们放在外部知识库里让模型先检索再回答。所谓能力指的是行为模式——回复语气、输出格式、推理风格、特定任务的工具调用逻辑。这些是模型的肌肉记忆靠提示词教不会得靠微调刻进权重里。最典型的组合形式是模型能力用微调打底业务知识用RAG补充。比如企业客服机器人先用一部分标注数据把模型的回复风格和工具调用调教好再把产品手册、使用FAQ这类动态知识丢进向量库做检索。这样的架构知识更新不需要重训模型能力升级也不依赖资料质量两头解耦。4.3 微调的三个成本真相很多人被开源模型免费随便微调这句话带进了坑里。开源模型本身的权重确实免费但微调的成本从来不在模型本身而在数据、GPU资源和工程维护上。第一是数据成本。微调需要的不是十条八条样例而是至少成百上千条高质量标注数据。这些数据要让模型学出模式而不是死记几条答案。我见过太多人用几百条样本做全参微调结果模型直接灾难性遗忘连基本的通用能力都退化了。第二是GPU成本。微调训练比推理吃显存多得多因为训练时你要同时保存权重、梯度和优化器状态。即便是LoRA这类参数高效微调方法32B模型的训练也需要至少一块40GB级别的GPU。虽然有各种低资源的微调工具帮人们用更小的显存跑更大的模型但训练时间长几倍、效果波动大这些隐性成本是躲不掉的。第三是维护成本。微调后的模型一旦上线后续知识更新怎么办重新标数据、重训、重新测试一套流程走下来不比开发新功能省心。这也是为什么我一再建议大家优先考虑RAG——知识更新只需要换向量库里的文档模型权重完全不动。5. 一套可以直接抄作业的选型流程5.1 五步决策表我把前面说的三个问题串成一套可执行的选型流程按顺序走一遍基本不会走偏。第一步圈定任务类型。先判断任务要不要图片输入、要不要长文本、要不要工具调用。这一步先把多模态需求和上下文需求锁死筛掉不合适的候选。第二步估算部署约束。算清楚你有多少预算、多少显存、是否接受数据出域。约束条件写下来直接决定你走云API还是本地路线。第三步查能力下限。按任务复杂度选择参数档位宁可先用小模型试不够再往上加也别一上来就上超大模型——多数需求在中间档就能解决了。第四步决定学习方式。先用提示词和上下文工程打底效果不够再评估是上RAG补知识还是上微调改能力。第五步用真实数据做AB测试。选两到三个最终候选模型跑同样的业务数据集人工评效果。跑分再高过了你这一关才算数。5.2 三个常见需求场景的选型示例我给你列三个我实际遇到过的场景对应不同的选型结果。场景一是个人办公助手跑在Windows电脑上做文档摘要。硬件是16GB内存加一张8GB显存的显卡。这种配置直接上Ollama选7B到8B的量化模型就够用了。运行起来带得动速度也跟得上日常摘要和表格处理绰绰有余。场景二是企业内部知识问答平台需要给几千员工提供产品资料检索服务。这种属于私有化部署范畴建议用32B级别的模型配24GB显存以上的卡推理服务选vLLM知识部分走RAG。实测下来查询质量比7B提了一个档次并发也能扛住。场景三是金融数据复盘需要分析K线走势并生成解读报告。这类任务对数字敏感度高、多步推理要求强7B模型经常在计算上出错。优先选择大参数量模型云端API直接上旗舰级本地部署就直接冲70B档。这不是炫技是任务本身的复杂度逼你这么选。5.3 配套工具链怎么搭配选型不止选模型本身整个配套工具链同样关键。我在不同项目中试过几套组合整理出来供你参考。本地入门级组合是Ollama加主流开源模型再加Open WebUI这类界面工具。Ollama负责模型加载和API暴露界面工具负责可视化交互。这套组合能快速解决先跑起来的需求功能边界清晰踩坑点少。开发区场景可以用Spring AI这类框架来连接模型。它把模型API封装成统一的接口切换不同模型服务商只需要改配置不用改业务代码。对于Java技术栈的团队这是一个能让模型选型切换成本降到最低的关键组件。企业生产环境的核心栈是vLLM加一个Agent框架。现在主流的Agent框架我已经筛过一轮各有侧重。选框架时建议先看文档质量、社区活跃度和对工具调用的支持程度再决定上不上车。框架本身不用追求新稳定成熟比什么都重要。注意本地部署大模型之后很多人会忽略模型的运行日志和监控。如果模型是给内部业务用的务必把请求延迟、报错率、上下文占用这些指标收起来。不然模型悄悄劣化了你往往是最后一个知道的。6. 常见问题速查表6.1 显存不够就跑不动那倒未必这张卡能不能跑XXB模型是新手最常问的。除了前面聊的量化方案还有两个常规操作可以缓解一个是缩小上下文长度把KV Cache压下来另一个是启用CPU卸载把部分层放到内存里跑虽然速度会慢不少但至少能出结果。如果这样还不行那就要么乖乖换成更小的模型要么干脆选云API。硬扛不是办法算力是有物理边界的。我认识一个团队为了在8GB显存的笔记本上跑32B模型折腾了整整两周的量化参数和层卸载策略最终效果还是卡得一塌糊涂。后来我一句话点醒他们换8B模型跑十分钟就通了效果也够用。选型这事懂得妥协才是上策。6.2 为什么模型答复不稳定这次和上次不一样大模型默认的采样机制是有随机性的。如果你的场景要求确定性输出解决方法是调整推理参数把温度降到0附近必要时固定随机种子。对于分类、抽取、格式化输出这类任务不做参数调整同一段输入可能隔几次就给你变着花样返回结果。另一个常见原因是系统提示词被业务逻辑覆盖了。很多多人协作的项目里代码里会不断拼接业务前缀导致模型收到的实际指令和最初设计的不一致。排查这种问题先把模型收到的完整输入打出来看一遍十有八九能找到症结所在。6.3 RAG检索不到关键内容怎么办RAG效果差的最常见原因不是模型不行而是检索阶段就没把该找的东西找出来。定义好的分块策略、选用合适的嵌入模型、调整检索top-k参数这三个是核心抓手。最简单有效的优化是先把文档切片改小一点。切片太大向量里掺了太多无关信息相关性就被稀释了。切成256到512个Token左右的片段配合关键词召回加向量召回的混合检索命中率能明显提升。再往上接一个重排序模型把粗召回的结果精排一遍回答质量能再上一档。6.4 微调和RAG到底先做哪个如果你已经确认提示词工程解决不了问题我的建议是先做RAG再做微调。原因很简单RAG见效快、成本低、可回滚。你先把知识库搭起来看模型能不能通过检索拿到答案如果问题出在拿得到但说不出再考虑用微调调整输出格式和表达方式。最忌讳的是上来就同时启动RAG和微调。两个变量同时改出了问题你连排查的方向都没有。我处理过的项目里超过一半的微调需求最后都被RAG方案替代了剩下一半里又有一多半被提示词优化解决了。真正需要走到微调这一步的远比你想象中少。6.5 跑分相差几分实际体验天差地别如果你遇到一个模型跑分很高、实际用起来却不好使的情况先别急着怀疑自己的判断。检查三件事第一是不是量化掉点第二是不是没用对推理框架导致上下文处理出了问题第三是不是你没调温度、top-p这些采样参数直接把默认参数用到了任务场景上。这三项都排查过了还不行那就可能是这个模型在评测集上确实有优势但在你的任务分布上没有泛化能力。这时候换模型不要恋战。套用我前面说的AB测试逻辑谁在真实数据上表现好就用谁榜单只是参考。写在最后的选型体会我一直觉得大模型选型本质上不是技术判断题而是场景匹配题。排行榜给出的只是一个平均意义上的智力值而你要解决的是具体的业务问题。把任务定义清楚、把部署边界算明白、把改造方式想清楚这三步做完你会发现正确答案自己会浮出来根本不需要被跑分牵着鼻子走。从个人电脑上跑一个量化的轻量模型做自动化助手到企业内部用检索引擎加私有化模型搭知识大脑再到金融场景里用大参数模型做深度分析每个层级的选型逻辑都完全不同。最核心的心态是克制不为了用大模型而用大模型不被参数数字迷住眼用最小成本解决真实问题才是这个领域里最值钱的能力。
