干了这么多年大模型落地，我越来越觉得选型这事儿被带偏了。打开任何一张模型排行榜，往上翻的永远是那些参数最大、跑分最高的巨无霸，评论区里的讨论也集中在"XXX比XXX高了多少分"这种数字游戏上。但真到了自己手里那点任务——不管是做客服问答、写行业报告还是让一台普通电脑跑个私有小模型——跑分高和好用之间，隔着好几条街。我给自己定了个规矩，选模型不看排行榜，先问三个问题：你的任务到底是什么？模型会跑在什么硬件上？你要不要改它？这三个问题想明白了，选型清单基本就自己列出来了，根本不用在跑分榜上纠结到失眠。

这篇内容我打算把我这些年踩过的坑和总结出来的选型方法论完整写出来，不堆术语，只讲人话，覆盖云端API和本地部署的常见场景。

1. 跑分为什么是选型里最没用的指标

1.1 评测集测的是"考试能力"，不是"干活能力"

任何一个公开榜单都在衡量模型在标准考试里的表现。MMLU测知识广度，HumanEval测代码能力，GSM8K测数学推导，这些评测集不是说没有价值，问题是它们跟真实用户的真实任务完全不是一回事。真实场景里没有人为你设定好唯一的提问模板，也没有人帮你清理掉问题里多余的噪声。

更麻烦的是，评测集本身是会污染的。开源模型在预训练阶段就把评测集文本喂进去，这在业内不算秘密。很多模型的"高跑分"其实只是它在报考前就拿到了标准答案，真拿到没见过的任务上，效果立刻打回原形。我测试过一个榜单前几名的模型和一个小体量模型在同样的工单分类任务上的表现，前者稍改措辞就分错类，后者反而稳定得多。这种落差单看跑分是完全看不出来的。

1.2 跑分环境和你实际的部署环境，根本不是一回事

你看到榜单上跑出来的数字，背后往往是满血版模型配上一排顶级显卡，推理框架还专门调过优化参数。但你真去部署的时候，通常要考虑三件事：显存够不够、延迟能不能忍、成本划不划算。于是你量化、剪枝、用低精度加载，这一套组合拳打下来，模型的真实能力早就和榜单上的"原版"不是一个东西了。

我实测过很多次量化前后的对比。4bit量化对大多数任务掉点控制在两三个点之内，但代码生成和多步推理这类任务，掉点可以拉到十个点以上。也就是说，同一个榜单数字，在人家满血环境里体现的能力和你在自己硬件上拿到手的能力，中间隔着一整条推理优化链。你拿榜单分数去预判实际效果，等于拿汽车厂商的实验室油耗预判早晚高峰的真实油耗。

1.3 跑分无法告诉你"这件衣服合不合身"

跑分是平均数思维，它把所有任务混在一起算出一个总分。但没有一个真实用户的需求是"平均任务"——你要么在处理垂直行业的专业知识，要么在生成特定风格的文案，要么在做多轮复杂对话。平均数掩盖的都是极端差异。

举个直观的例子。一个模型可能在通用聊天上表现平平，但在特定代码库上下文里的补全能力极强；另一个模型跑分更高，却在你的领域术语上一窍不通。跑分榜根本反映不出这种个体差异。所以我现在选型时都要求团队带上自己的真实样本去测，人数不多，二三十条就够，但必须覆盖典型难点。用真实业务数据测出来的结果，比什么榜单都有说服力。

2. 第一个问题：你的任务到底是什么

2.1 先给任务"翻译"成模型能力

我常说一句话：大模型不吃你的任务描述，它吃的是能力需求。所谓选型，本质上是把你业务里的任务翻译成模型的能力子集，再去找那个能力子集和模型特性的交集。

翻译的方法很简单，问自己几个子问题：

• 任务需要模型输出什么形态的结果？问答、摘要、代码、JSON结构、还是多轮对话？
• 任务对输入的包容度要求有多高？是固定模板，还是用户随手敲进来的自由文本？
• 任务里有没有视觉需求？需要看图片、文档扫描件还是截图表单？
• 任务对正确性的要求有多高？容忍"差不多"还是必须精确到能直接跑？

把这几个子问题答完，你就能得出模型的几个硬指标：参数量的下限、是否必须多模态、上下文窗口要多大、是否需要工具调用能力。这些指标一框定，候选名单就从几十个缩小到三五个了。

2.2 参数量不是越大越好，够用才行

大模型社区里有一个集体性的误解：参数越多越聪明，所以选型就是选最大号的。这个逻辑在云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量化后大约占1GB；INT4量化后大约占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测试逻辑，谁在真实数据上表现好就用谁，榜单只是参考。

写在最后的选型体会

我一直觉得，大模型选型本质上不是技术判断题，而是场景匹配题。排行榜给出的只是一个平均意义上的"智力值"，而你要解决的是具体的业务问题。把任务定义清楚、把部署边界算明白、把改造方式想清楚，这三步做完，你会发现正确答案自己会浮出来，根本不需要被跑分牵着鼻子走。

从个人电脑上跑一个量化的轻量模型做自动化助手，到企业内部用检索引擎加私有化模型搭知识大脑，再到金融场景里用大参数模型做深度分析，每个层级的选型逻辑都完全不同。最核心的心态是克制，不为了用大模型而用大模型，不被参数数字迷住眼，用最小成本解决真实问题，才是这个领域里最值钱的能力。