中文大模型选型怎么看：参数量之外，还要看任务和部署条件

挑选中文大模型时，最容易走进一个直观但不太可靠的判断：参数越多，模型越强。参数规模确实会影响模型的表达能力、知识容量和复杂任务的上限，但它从来不是结果的全部。数据质量、训练目标、指令微调、推理策略以及模型对具体任务的适配程度，都会改变最终表现。一个参数更大的模型，如果回答格式不稳定、中文术语经常出错，放到业务里未必比小模型好用。

更稳妥的思路是先问清楚‘要解决什么问题’，再去看模型。聊天问答、长文总结、信息抽取、代码生成、知识库问答和本地离线运行，对模型的要求并不一样。模型选型的目标不是在排行榜上赢一次，而是在自己的输入、约束和预算下，长期得到可接受的结果。

也可以把模型看成一组取舍：能力越强，往往意味着更高的显存占用、更慢的响应或更复杂的部署；更轻量的模型更容易本地运行，但可能需要更好的提示词、检索资料或后处理。先把这些取舍摆到桌面上，后面的比较才有意义。

第一类是开放式生成，包括对话、改写、扩写、提纲和邮件草稿。这类任务重视语言自然度、上下文理解和指令遵循，通常还要观察模型会不会擅自添加事实。它适合用一组真实的日常问题测试，而不是只拿一两个漂亮示例判断。

第二类是抽取与分类，例如从合同中找出日期和金额、给工单归类、把会议记录整理成固定字段。这类任务看起来比聊天简单，却更依赖格式稳定性和边界处理能力。模型是否能在字段缺失时明确留空，往往比它能不能写出一段漂亮的说明更重要。

第三类是知识库问答和长文处理。模型本身不一定需要记住所有业务知识，但要能读懂检索到的材料，区分材料中的事实和自己的猜测，并在找不到依据时停下来。上下文长度只是入口，真正要看的是长文本中的定位、引用和归纳是否可靠。

第四类是推理、代码和多模态任务。数学推理、程序调试、表格理解、图片问答都有自己的错误类型。一个在通用聊天中很顺的模型，未必适合这些任务。因此候选模型应当按照实际任务分组，而不是把所有问题混成一个总分。

中文能力不只是‘能不能用中文回答’。至少要观察四个层面：句子是否自然，专业术语是否准确，较长的中文材料能否保持指代和逻辑，以及面对模糊要求时能不能主动澄清。日常对话里不明显的差异，放到产品说明、制度文本或客户回复中，很快就会暴露出来。

测试时不要只写‘请介绍一下某个概念’。更有区分度的题目应该带有真实限制，例如要求保留原文中的字段、按照指定格式输出、区分相近术语、引用给定材料，或者在资料不足时回答‘无法判断’。这些约束能看出模型究竟是在理解任务，还是只是在生成看起来像答案的文字。

还要留意中文语境中的表达习惯。标题层级、标点使用、数字和日期格式、专有名词的中英文混排，都会影响文章能否直接交付。若模型每次都需要人工大幅修改，就应该把人工校对的时间计入真实成本，而不能只比较接口价格。

参数量可以粗略反映模型的规模，但不能直接换算成某项任务的准确率。模型的参数越多，通常需要更多显存和计算资源，推理速度也可能下降；小模型则更容易部署在普通服务器或本地设备上。对于批量摘要、分类和抽取这类任务，速度和稳定性有时比更强的开放式推理能力更重要。

上下文窗口也不能只看宣传数字。窗口越长，意味着一次能放入更多内容，但并不保证模型能同样准确地利用每一段内容。实际测试时要看材料放在开头、中间和结尾时，模型能否找到关键信息；还要看上下文变长之后，响应时间、显存占用和错误率如何变化。

推理成本包括显性和隐性两部分。显性成本是接口调用费用或服务器成本，隐性成本则包括部署调试、提示词维护、人工复核、失败重试和数据清洗。一个单次回答便宜但经常需要重跑的模型，未必比稍贵却稳定的模型更省钱。

下载页面写着‘开源’，并不一定意味着所有内容都开放。需要分别确认模型权重是否可下载，代码是否公开，训练数据和训练方法是否有说明，许可证允许哪些用途，以及是否对商业使用、再分发、用户规模或衍生模型作出限制。开放权重、开放代码和完整开源是不同层次，不能混为一谈。

许可证问题最好在项目开始前确认，而不是上线后再补。尤其是企业内部部署、对外提供服务、把模型嵌入商业产品或再次发布模型时，使用范围可能不同。页面上的‘可商用’也应该结合正式许可证文本理解，必要时保留版本和来源记录。

同样重要的是模型来源和版本。模型文件、量化版本、微调版本可能来自不同发布者，名称相近却有不同配置。下载前要确认模型架构、上下文设置、量化方式和适用推理框架，避免把运行问题误判成模型能力问题。

公开榜单适合帮助我们建立候选名单，但不适合代替业务评测。榜单里的题目、语言比例、评分方法和模型版本都有自己的范围，一个模型在通用题上得分较高，并不代表它能正确处理你的合同、日志、知识库或客服话术。真正有用的比较，应该尽量接近未来的输入和输出。

可以先准备二十到五十条样本，覆盖正常情况、边界情况和容易混淆的情况。每条样本写清输入、期望结果和不能接受的错误，例如漏掉关键字段、编造原文没有的结论、输出格式错误、把不确定内容说成确定事实。样本不必一开始就很大，但要能代表实际工作，而不是专门挑模型擅长的题。

评测指标也要分开记录。准确率适合衡量抽取和分类，格式通过率适合衡量结构化输出，人工评分适合衡量表达和解释，引用一致性适合衡量知识库问答；另外还要记录首字延迟、完整响应时间、吞吐量、显存占用和失败重试次数。把这些结果放在同一张表里，才看得出不同模型的真实取舍。

评测最好保留原始输出，不要只记一个分数。很多问题不是模型完全不会，而是偶尔漏字段、偶尔改变格式，或在长上下文下突然失去重点。原始回答能帮助我们定位问题，也方便后续比较提示词、检索策略和量化版本的影响。

如果计划本地部署，先核对模型文件大小、推理精度和显存需求，再估算并发量和响应时间。参数量相同的模型，因为精度、量化方式和实现不同，实际占用可能差很多。除了模型本身，还要为运行框架、上下文缓存、批处理和系统余量留出空间，不能把显存算到刚好够用。

量化可以降低资源占用，但会带来一定精度变化。它不应该被理解为‘免费获得同样能力’，而应在自己的评测集上确认影响是否能接受。对于格式严格的抽取、数字计算和长文本任务，量化后的变化可能比普通聊天更明显。

部署也不是把模型文件放进服务器就结束了。实际系统通常还需要推理服务、请求队列、超时和重试、日志、监控、权限控制，以及与检索库或缓存的连接。如果模型用于知识库问答，还要分开观察检索命中、上下文拼接和模型回答，出了问题才知道该从哪一层修复。

第一步，写出任务清单和硬约束。明确输入是什么、输出是什么、能不能调用外部知识、是否必须本地运行、能接受多长延迟，以及许可证需要满足什么条件。没有这些前提，模型比较很容易变成参数和排名的争论。

第二步，按任务类型选出少量候选。不要一次下载十几个模型，可以先保留一个能力更强的模型、一个运行成本更低的模型，再加一个在中文或特定领域有特点的模型。候选数量少一些，反而更容易做完整比较。

第三步，用同一套提示词和同一批样本测试。记录准确率、格式通过率、幻觉情况、延迟、吞吐和资源占用，必要时重复多次，观察输出是否稳定。对于开放式写作，还应安排人工盲评，避免评测者因为知道模型名称而产生偏好。

第四步，单独核对许可证、版本和部署方式。通过测试不代表可以直接上线，模型来源、商业范围、数据处理方式和安全要求都需要留档。最后做一个小规模试运行，持续收集失败样本，再决定是否扩大使用范围。

中文大模型选型可以归结为一句话：先看任务是否匹配，再看中文输出是否可靠，接着看上下文、速度和资源能否承受，最后用真实样本验证许可证和长期成本。参数量是参考信息，不是结论；排行榜是候选入口，不是上线凭证。

对于刚开始尝试的团队，最有价值的工作往往不是寻找一个‘最强模型’，而是建立一套可重复的评测方法。只要样本、指标和版本记录清楚，模型升级、换部署方式或接入知识库时，就能知道变化到底带来了什么。选型因此不再是一场一次性的猜测，而会变成可以持续修正的工程流程。