前两天有个做内容产品的朋友拿着一份大模型跑分榜单来找我开口就问“Qwen 和 DeepSeek 都挺高ChatGPT 也不低我到底该用谁”我没有直接回答。因为这个问题没法直接回答。大模型选型这几年已经成了企业技术决策里的高频难题。多数人第一步就打开榜单按分数从上往下挑。但跑了几个真实业务之后分数最高的往往不是最合适的。我手里过过不少大模型接入项目有知识问答、文档解析、代码辅助、甚至工业质检文本分析最后得出一个特别朴素的经验选模型真的不用看跑分把下面这三件事想明白答案自己就浮出来了。这不是反智也不是否认评测的价值。跑分是一个筛选工具但它筛的是“模型能力上限”你的业务需要的是“在特定场景下稳定输出”。这两者之间隔着部署成本、延迟、上下文长度、格式可控性、数据合规哪一样都比几分之差更影响落地效果。下面我以实际选型中踩过的坑和验证过的方法把这套“三问”逻辑完整展开。1. 跑分到底在骗你什么榜单之外的真相既然说不看跑分总得先说清楚跑分哪里不靠谱。不是要全盘否定而是要知道它的局限在哪里。1.1 跑分测的是平均值你的业务踩的是极端值标准评测集一般由数万条题目组成最后取一个平均分。你业务里真正致命的是那些边界场景一段带错别字的文档、一份合法的合同、一句带有行业黑话的提问。这些在平均分里可能只占 0.1% 的权重但在生产环境里可能决定可用性。举个例子。我帮一家律所团队测过文档审查场景榜单上某模型综合分高出竞品 3 分。但把它放在真实合同片段上跑它自动把“不可抗力条款”里的责任限制内容理解成了“赔偿责任无限”在场律师直接摇头。另一个低 3 分的模型反而乖乖按原文结构输出。这就是平均值骗人的典型场景。1.2 跑分无法告诉你部署成本和响应延迟一份榜单不会告诉你“分数高 2 分推理速度慢三倍”意味着什么。很多高分模型参数规模大或者是 MoE 架构激活参数少但总参数多本地部署时对显存和带宽的要求非常高。你真上了业务才知道用户等不起 8 秒才蹦出一个字的首 token 延迟。跑分也测不出“在 GPU 上跑到 64 并发时会不会崩”。这属于压测问题跑分榜单不认这个。1.3 跑分存在数据污染越火的模型越严重我不说名字但业界已经有不少团队做过“反测试集”实验把评测题稍微改几个字模型性能立刻下降。说明部分模型在训练时见过原题背答案背出来的分数换个说法就露馅。你上生产环境后遇到的不会是原题全是变体。所以我的建议是跑分只作为初筛把候选范围缩到三到五家就够了。真正下结论要拿你自己的业务数据做一轮盲测。这个盲测怎么做后面第 5 章给出可执行的脚本。2. 第一问你的真实使用场景是对话、管道还是嵌入式这是选型的第一步也是很多人没想清楚的一步。同样是“用大模型”对话、管道、嵌入式三种场景对模型能力的要求完全不同。2.1 对话型场景首字延迟和语气一致性优先对话型产品包括智能客服、AI 助手、陪伴式聊天核心指标不是“答得有多好”而是“答得多快、多稳”。一个 8B 模型在普通显卡上可能跑出 30 token/s一个 70B 模型只剩 8 token/s。对于交互产品来说速度就是体验体验就是留存。语气一致性也常常被忽视。我见过不少团队换了模型之后客服话术从“客观专业”变成“热情过度”用户投诉明显增加。这是风格漂移问题跑分测不出来。对话型场景建议用中等参数规模、指令跟随能力强的模型配合温度参数调低到 0.4 以内效果往往比盲目上大模型更稳。2.2 管道型场景结构化输出能力比什么都重要数据抽取、信息结构化、报表生成、代码补全这类场景大模型只是管道中的一个环节。后面跟着的是解析脚本、数据库、工单系统。前期模型输出的格式只要错一个字段整个链路就崩。测试管道型场景时我通常会设计一个强制 JSON 输出用例连续跑 50 条看解析成功率。很多跑分不错的模型在“必须输出合法 JSON 且遵循指定 schema”时失败率高得吓人。这个指标比任何通用跑分都关键。为了提升成功率通常还要用函数调用能力强的模型或者在提示词里锁死输出模板甚至配合负反馈示例也就是给几个“你不要这样输出”的坏例子。2.3 嵌入式场景上下文长度和检索能力是关键嵌入式场景指把大模型作为能力模块嵌入到 RAG 问答、数据分析工具里。这类场景下模型需要处理的是检索出来的候选片段不是“全凭自己记忆作答”。所以模型自身的知识量反而次要更重要的三个能力长上下文理解、跨段落信息聚合、避免被无关片段带偏。我做过一个对比实验同样在知识库问答里给六个候选片段有的模型会盯着最开头一段话输出后面的证据全被忽略。这种毛病在通用跑分上完全看不出来。所以嵌入式选型必须拿真实检索结果做输入测试片段里故意掺入一条相关但错误的干扰信息看模型会不会被误导。这张表可以直接拿来当初判标准场景类型首要指标次要指标容易忽略的点对话型首字延迟、响应速度语气一致、指令跟随长对话记忆是否衰减管道型结构化输出成功率字段完整性、schema 遵循并发下的稳定性嵌入式长上下文聚合抗干扰能力检索片段排序的敏感度先把自己的场景归类再带着场景指标去测模型选型会清晰得多。3. 第二问API、本地还是私有化部署现实决定模型下限这一问本质上是回答“你能接受什么程度的依赖”。不同交付方式直接锁定了模型的可选范围。3.1 走 API先谈数据合规再谈能力很多团队上来就接各家闭源 API能力确实强部署成本也确实低但有一个隐形问题业务数据出去之后回不来了。如果你的业务涉及用户隐私、企业财务、未公开产品信息数据出站之前必须过合规这一关。与其后面整改不如一开始就把数据脱敏规则定好。另外API 服务的可用性也是选型指标。我用过几个平台的 API高峰期超时率从 0.5% 飙升到 5%直接导致线上链路失败。建议在接入前至少做一周的压测记录 p50、p95、p99 延迟和超时率。不要只看模型能力 Demo 跑得飞起要看到它在生产压力下还能不能飞。3.2 本地部署显存推理公式帮你圈定模型范围本地部署不是简单的“下载一个大模型跑起来”硬件是硬约束。圈定模型之前先做一个显存粗算权重显存大约等于参数量乘量化位数再除以 8。比如 7B 参数用 FP16天然就需要大概 14GB 权重显存用 INT4 量化大约 3.5GB。加上 KV cache、中间激活和运行时开销实际占用要比理论值多出 20% 到 50%。社区里常见的估算口径是INT4 量化下 7B 模型至少需要 8GB 显存14B 至少 16GB32B 至少 24GB。我见过不少人拿一台 16GB 的笔记本去跑 32B 模型量化成 4bit 勉强能加载但只要上下文一长就直接 OOM。这属于典型的“能加载”和“能使用”分不清。如果你只有单卡 24GB比较稳的选型范围就是 INT4 量化的 14B 到 32B 家族或者更小的 7B 跑到更高精度反而效果不差。工具链上目前 Ollama 适合快速起步一条命令就能拉起模型配合 Open WebUI 做成带界面的人工智能工作台vLLM 适合追求高吞吐的生产环境它有连续的批处理加速并发高的时候单位 token 成本能明显下降。社区里经常讨论“Ollama 装的模型到底是个什么文件”简单说就是把模型权重封装成了 GGUF 格式携带量化信息方便分发和加载。生产环境如果追求吞吐我通常直接用 vLLM 拉起来暴露一个兼容接口给下游业务。3.3 企业私有化考虑的是治理链路而不是模型文件私有化部署这个词经常被误解为“把模型下到内网服务器里”。其实真正的私有化难点在配套离线镜像怎么更新、模型权重怎么安全分发、谁有权限发起推理请求、推理日志怎么审计、私有知识库怎么和公网模型生态隔离。我参与过的私有化项目里最费时间的反而不是选哪个模型而是把数据链路打通。有一次因为内网不能访问公网模型源光上传验证模型文件就折腾了两天。所以做私有化选型时优先考虑支持离线部署、有成熟容器镜像方案、许可证允许内部商用的开源模型这类模型社区生态好出了坑也有地方查。还有一个要提醒的安全问题模型投毒。下载模型时尽量走官方源校验哈希值别因为图快从不明渠道拉压缩包。这不是危言耸听业界已经有通过篡改模型权重植入后门的案例被调到特定关键词时输出恶意导向内容跑分根本测不出来。4. 第三问RAG、微调还是裸用后续路线要提前定很多团队选完模型才想起来思考“是不是该微调”顺序完全反了。你打算怎么用这个模型直接决定了选型时该关注哪些能力。4.1 裸用选通用能力最强、指令跟随最好的如果你只是简单接个对话、做点文本改写不打算做知识库也不做微调那就选指令跟随能力最强的模型不需要纠结领域知识。因为领域问题它答不准你不该指望它答准而是应该在应用层做好引导比如提示词里限定范围、给足例子。裸用场景下上下文窗口反而更重要。同样的价格可能买到 128K 上下文的模型和 32K 上下文的模型我倾向于选更长的那个因为后面接 RAG 时上下文就是缓冲池子越大越不容易截断关键信息。4.2 做 RAG重点关注文档理解、长文本聚合RAG 是目前知识库问答的主流方案核心思路是先检索后生成让模型基于证据作答。所以模型的“知识量”不重要“阅读能力”才重要尤其是处理长文档、跨章节引用、表格识别这些能力。选型时可以这样测准备一份三四千字的行业报告里面埋 5 个分散在不同段落的事实点问题需要跨段落拼接才能回答。能答出来的RAG 能力基本过关只答出其中两三个的接着再用。另外RAG 链路里模型不仅要读检索片段还要判断“这段证据够不够回答”所以模型的拒绝回答能力也值得测。遇到证据不足时它是硬编一个答案还是会坦诚“信息不足”在严肃业务里差别很大。4.3 想做微调算力、数据、许可证三个硬门槛微调这块水比较深。不是说你照着网上教程跑几个小时 Loss 降下去就叫微调成功还要能持续维护、稳定上线。先看算力LoRA 之类的高效微调方法确实能降低门槛但数据准备才是最大的成本。微调需要高质量的成对输入输出你要是没有几百上千条人工标注数据效果很可能不如直接在提示词里写好规则。另一个被忽略的点是模型许可证。不同开源模型对商用、派生分发、修改范围的规定不一样有的要求衍生作品继续开源有的禁止商用有的允许修改但不允许改名再发。你要是把许可证限制的模型微调后塞进商业产品法律风险就埋下了。所以我一般建议先用 RAG 解决 80% 的需求真的解决不了的再把那 20% 的顽固问题拿去做微调。多数团队到后面会发现根本不需要微调而是提示词和 RAG 没做透。5. 通用一套测试框架20 分钟就能跑出结论开头我说的三个问题再配合一套 20 分钟测试脚本选型就基本落地了。这套方法不需要跑分平台只需要你准备一段自己的真实业务数据。5.1 准备 20 条真实输入而不是网络上的段子题从你的历史工单、客户提问、常见文档里抽 20 条真实输入。注意是真实输入不是人工编的漂亮问题。很多模型面对网络上的“脑筋急转弯”表现不错碰到你们行业里那种措辞混乱、信息残缺的真实请求就崩了。这 20 条题里建议包含5 条超短输入、5 条带错别字或口语化的输入、5 条需要多步骤推理的长输入、5 条格式要求明确的输出型任务。覆盖对话、管道、嵌入式三种场景中最关键的变体。5.2 制定粗筛维度内容准确、格式合规、时效自知三个维度就够不能求全内容准确看核心事实不跑偏格式合规看能否按要求输出表格、JSON、特定结构时效自知模型是否知道自己不知道不乱编。每个维度给个 0 到 2 分20 条题跑完看总分。你说这不还是打分吗对但打分标准是你定制的权重围绕业务来跟榜单没关系。5.3 算一笔成本账比任何分数都真实在模型能力差异不大的前提下成本账往往是压死骆驼的最后一根稻草。不需要看官方宣传的 Token 价格要算实际账面成本自己部署的按 GPU 折旧、电费、运维工时折算每条请求成本用 API 的按实际并发和 Token 消耗估算月费用。这里有一个常被忽略的成本项错误重试成本。格式错一次链路重跑一次Token 消耗翻倍成本就不是账面上那个价了。所以管道类场景宁可选输出稳定但单价略高的模型也不选便宜的“碰运气模型”。同样的道理也适用于延迟慢模型占用用户时间这部分成本虽然没有金额但对留存的影响是实打实的。6. 选型之外的几点真实心得模型选型没有一劳永逸它是你业务的一部分会随业务需求一起迭代。我自己的习惯是每年至少复测一次因为开源模型生态更新太快去年不行的今年可能已经行了去年要付费的今年可能有开源平替。还有一个小技巧不一定关注全网热搜的大模型下载链接。真正重要的是建立自己的评测题库把它沉淀成团队资产。每来一个新模型候选直接进同样的题库跑一遍分数对比一目了然。这套题库比任何跑分榜单都值钱因为它长在你的业务数据上。最后说说心态。我看到有些人选模型纠结了半个月其实花半天把三问问完再花半天跑真实数据测试结论就能出来。大多数项目里模型能力不是瓶颈业务流程设计才是。与其花时间找一个“完美模型”不如把时间花在把调用方式、上下文策略、错误处理这些细节打磨好。等模型能力再涨一轮你的应用框架还在换个模型底座就能平滑升级那才是真正不亏的选择。