1. 为什么现在聊开源LLM对比正当时过去一年我陆陆续续在本地和云端跑了不下二十个开源大语言模型从最早拿一张消费级显卡跑量化版到后来在几台服务器上做多模型并行推理踩过的坑能写满一个笔记本。LLM开源模型对比这件事放在两年前还只是少数极客的玩具现在已经变成很多团队做技术选型时绕不开的一道必答题。原因很直接闭源API按token计费量一大成本就失控数据合规要求越来越严很多业务数据根本出不了内网再加上开源模型迭代速度肉眼可见地加快某些场景下和头部闭源模型的差距已经缩到可以接受的范围。这篇文章想解决的问题很具体当你手里有一个真实任务面对几十个开源模型名字怎么快速筛出两三个候选怎么用最低成本验证它们到底行不行以及部署和量化时那些文档里不会写的细节。适合的读者包括正在做技术选型的工程师、想在自己机器上跑模型玩的爱好者以及需要给团队搭建内部推理服务的运维同学。我不打算堆砌跑分数字那些榜单比如Open LLM Leaderboard可以自己去看我更想聊的是榜单背后那些真正影响你决策的东西。先说一个我自己的判断开源模型没有绝对的好坏只有匹配不匹配。一个在通用榜单上排名靠前的模型放到你的垂直场景里可能被一个小得多的专用模型按在地上摩擦。所以对比的核心不是谁最强而是谁最适合我的任务、我的硬件、我的预算。2. 对比之前先想清楚你到底要什么2.1 先分清三类使用场景我在做对比之前习惯先把需求归到三类里因为不同类别的评估标准完全不一样。第一类是通用对话与写作辅助。这类任务对模型的指令遵循能力、语言流畅度、知识广度要求高参数量通常得在7B以上才有像样的表现。典型场景是内部知识问答、文案草稿、代码补全。第二类是垂直领域结构化任务。比如从合同里抽取字段、给工单分类、把非结构化文本转成JSON。这类任务往往可以用更小的模型1B到3B甚至经过微调后效果比大模型还稳因为任务边界清晰不需要模型什么都懂。第三类是RAG与知识库问答。热词里出现的llm wiki知识库rag graphrag llm wiki 本体rag其实都指向这个方向。这类场景里模型只是链条中的一环检索质量、切分策略、重排模型的影响可能比换LLM本身更大。我见过太多人把RAG效果差归咎于LLM不行结果换了三个模型都没用最后发现是切分粒度的问题。提示在开始对比前先用一句话写下你的任务目标越具体越好。比如把客服对话记录分类成8个标签准确率要过85%而不是做一个智能客服。目标越模糊对比越容易变成无意义的跑分游戏。2.2 硬件预算决定了你的候选池这一步很多人会跳过但它其实是最硬的约束。我整理了一张常见的硬件与模型规模对应表基于我实际跑下来的经验不是理论值硬件配置可流畅运行的模型规模量化建议典型吞吐tokens/s单张16G显存消费卡7B-8B4bit量化30-50单张24G显存13B-14B4bit或8bit20-40双卡48G32B4bit15-25单张80G专业卡70B4bit10-20CPU大内存7B以下GGUF格式3-8这张表里的数字是量级参考实际会因为你用的推理框架llama.cpp、vLLM、TensorRT-LLM等差出好几倍。vLLM在并发场景下的吞吐优势非常明显但显存占用也更高llama.cpp胜在灵活CPU也能跑适合个人玩。我个人的经验是如果你的显存刚好卡在某个规模的门槛上宁可降一档模型规模也不要硬上高量化等级。比如24G卡跑32B的4bit量化上下文一长就容易OOM体验很差不如老老实实跑14B把上下文留足。2.3 别忽略许可证和商用限制这一点经常被技术同学忽略但一旦踩坑代价很大。开源不等于免费商用有些模型的许可证对月活用户数、商用场景有明确限制。我在选型时会专门列一栏许可证类型把Apache 2.0、MIT这类宽松许可的排在前面把有额外限制的单独标注。具体哪些模型是什么许可证我这里不逐一列举因为更新太快建议你直接去模型的官方仓库看LICENSE文件那是最权威的。养成看许可证的习惯能帮你省掉未来很多麻烦。3. 核心对比维度我实际会看的六个指标3.1 指令遵循能力怎么测才靠谱榜单上的分数参考价值有限因为很多评测集和真实任务分布差很远。我的做法是自己造一套迷你评测集从真实业务里抽30到50条输入人工写好期望输出然后让候选模型跑一遍人工打分。打分维度我一般分三档完全符合、部分符合、完全跑偏。指令遵循能力最容易被低估的是格式稳定性——有些模型内容答得不错但让它输出JSON十次里有三次会多带一句解释这在程序化调用里是致命的。测试时有个技巧故意在指令里加一些约束比如只输出JSON不要任何其他文字字段名必须用下划线如果信息缺失填null。能稳定遵守这些约束的模型才值得进入下一轮。3.2 上下文长度与长文本表现现在很多模型标称支持128K甚至更长的上下文但标称长度和实际可用长度是两回事。我实测下来不少模型在超过标称长度一半之后中间部分的信息召回率就明显下降这就是常说的lost in the middle现象。测试方法很简单构造一段长文本把关键信息分别放在开头、中间、结尾然后提问。如果中间位置的信息经常被漏掉那这个模型的长上下文能力就要打折扣。对于RAG场景这一点尤其重要因为检索回来的片段往往堆在中间。注意长上下文会显著增加显存占用和推理时间注意力机制的计算量随长度增长很快。如果你的任务其实只需要几千token的上下文不要为了支持128K这个卖点去选一个又大又慢的模型。3.3 量化后的效果衰减热词里开源模型量化档排名说明大家很关心这个。量化确实能大幅降低显存需求但不同量化等级对效果的损伤不一样。我的经验是8bit量化效果损失通常可以忽略显存省一半左右4bit量化大部分任务损失很小但涉及精确计算、代码生成时可能出问题3bit及以下效果衰减明显除非实在没资源不建议量化方法也有讲究GPTQ、AWQ、GGUF各有适用场景。AWQ在推理速度上通常有优势GPTQ生态更成熟GGUF适合CPU和混合推理。同一个模型不同量化版本效果可能差出不少选型时最好把量化版本也纳入对比。3.4 推理速度与并发能力单条推理快不代表并发能力强。我见过单条响应很快的模型一上并发就排队严重。这里的关键指标是首token延迟和吞吐量前者影响交互体验后者影响服务成本。用vLLM做服务时可以通过调整max_num_seqs和gpu_memory_utilization来平衡。我一般先把gpu_memory_utilization设到0.9然后逐步加压测并发找到吞吐和延迟的平衡点。这个调参过程没有捷径只能实测。3.5 生态与工具链成熟度一个模型好不好用很大程度取决于周边生态。有没有现成的量化版本、有没有主流的推理框架支持、微调工具链是否完善、社区活跃度如何这些都会影响你的落地速度。我判断生态成熟度有个土办法去搜这个模型的微调教程和部署教程如果一搜一大把、而且时间都比较新说明社区活跃如果只有官方那几篇文档用起来大概率要自己填很多坑。3.6 微调友好度如果你的任务需要微调那基座模型的选择逻辑又不一样。有些模型天生适合微调LoRA一挂效果就上来有些模型微调后容易过拟合或者灾难性遗忘。这个只能通过实际微调实验来判断但可以先看社区里有没有人分享过类似的微调案例。4. 实操搭一套自己的对比流水线4.1 环境准备与推理框架选择我现在的标准做法是用vLLM做批量推理因为它对并发和吞吐的优化最好。安装不复杂但有几个坑要提前说# 建议用独立的虚拟环境避免依赖冲突 python -m venv llm_env source llm_env/bin/activate # 安装vLLM注意CUDA版本要匹配 pip install vllm # 如果要用AWQ量化模型还需要额外装 pip install autoawq第一个坑是CUDA版本和PyTorch版本的匹配这个不匹配会直接报错而且报错信息往往很隐晦。我的建议是先确认显卡驱动支持的CUDA版本再装对应版本的PyTorch最后装vLLM。第二个坑是显存碎片。长时间跑多个模型后即使卸载了模型显存也可能没完全释放。我的做法是每个模型跑完就重启一次推理进程虽然麻烦但最稳。4.2 构造评测集的具体方法评测集的质量直接决定对比结论的可信度。我的构造流程是这样的从真实业务数据里随机抽100条输入覆盖各种边界情况人工标注期望输出标注时记录这条为什么这么标把100条分成开发集30条和测试集70条开发集用来调prompt测试集只在最终对比时用为什么要分开发集和测试集因为如果你用同一批数据反复调prompt又评估很容易过拟合到这批数据上换一批真实数据效果就崩了。这个习惯是从做机器学习项目时带过来的在LLM评测里同样适用。4.3 批量推理与结果收集用vLLM做批量推理的代码框架大概是这样from vllm import LLM, SamplingParams # 加载模型注意量化配置 llm LLM( modelyour-model-path, quantizationawq, # 如果是量化模型 gpu_memory_utilization0.9, max_model_len8192, ) # 采样参数评测时建议temperature设0保证可复现 sampling_params SamplingParams( temperature0, max_tokens1024, ) # 批量推理 outputs llm.generate(prompts, sampling_params) # 收集结果 for output in outputs: generated output.outputs[0].text # 保存到文件后续人工或自动评估这里有个细节评测时temperature一定要设0否则同样的输入每次输出都不一样没法公平对比。有些模型在temperature0时仍然有随机性比如某些MoE架构这种情况我会跑三次取平均。4.4 自动评估与人工评估结合纯人工评估太慢纯自动评估又不可靠。我的做法是分两层先用规则做粗筛比如检查输出是否是合法JSON、是否包含必需字段、长度是否在范围内通过粗筛的再人工看内容质量。对于分类任务可以直接算准确率对于生成任务我一般用人工打分模型打分结合。模型打分就是让一个更强的模型比如闭源API来给候选模型的输出打分虽然不完美但能快速筛掉明显差的。5. 常见问题与排查实录5.1 模型加载失败与显存不足这是最高频的问题。排查顺序我一般是现象可能原因排查方法加载时报OOM显存不够或碎片降低gpu_memory_utilization重启进程加载后推理报错量化格式不匹配确认推理框架支持该量化格式推理中途OOM上下文过长降低max_model_len或分批处理速度异常慢用了CPU卸载检查是否有层被卸载到CPU我踩过最坑的一次是模型明明能加载但一推理就崩查了半天发现是量化版本和推理框架版本不兼容。换量化版本前先确认框架的支持列表能省很多时间。5.2 输出格式不稳定的处理前面提到过格式不稳定是程序化调用的大敌。我的应对策略有三层第一层是在prompt里把格式要求写到最前面和最后面中间用分隔符隔开利用模型的近因效应。第二层是加few-shot示例给两三个输入输出对模型模仿能力很强。第三层是加后处理用正则或JSON解析器兜底解析失败就重试。如果三层都上了还是不稳定那说明这个模型不适合这个任务果断换。5.3 长文本信息丢失的应对除了前面说的测试方法实际使用中我还会做一件事把关键信息在prompt里重复一次。比如RAG场景检索回来的片段里如果有关键实体我会在问题里再提一遍。这个土办法实测能明显提升召回。另外如果任务允许把长文本拆成多个短片段分别处理再汇总结果往往比硬塞进长上下文效果好。这就是map-reduce的思路虽然多花点token但稳定性高很多。5.4 并发场景下的性能调优并发一上来问题就多了。我遇到过的情况包括请求排队导致超时、显存不够导致部分请求失败、不同长度请求混在一起导致长请求饿死。vLLM里可以通过设置max_num_seqs控制同时处理的序列数通过max_num_batched_tokens控制单批token总量。我的调参顺序是先固定max_model_len然后逐步提高max_num_seqs直到延迟开始明显上升取那个临界点。提示生产环境一定要加监控记录每个请求的延迟和成功率。我见过太多服务上线后没人看指标等用户投诉才发现问题。6. 几个容易被忽略的选型细节6.1 分词器对中文的影响这个点很少有人提但对中文任务影响很大。不同模型用的分词器不一样同样一段中文有的模型切成100个token有的切成150个。token数直接影响成本和上下文占用。测试方法很简单拿一段典型的中文文本用不同模型的分词器切一下看token数。如果某个模型中文token效率特别低那在长文本场景下就很吃亏。6.2 模型更新频率与版本管理开源模型迭代很快同一个名字可能几个月就出新版本。我的做法是在项目里锁定具体版本号不要用latest。同时记录每个版本的表现方便回滚。另外模型权重文件很大下载和存储都是成本。我一般只保留当前在用的两三个版本其他的归档到冷存储。6.3 安全与合规的边界开源模型没有内容过滤输出什么完全取决于你的prompt和模型本身。如果面向终端用户一定要在应用层加过滤和审核。这块不是模型能解决的是工程问题。我在实际项目里的做法是模型输出先过一遍规则过滤敏感词、格式校验再过一遍小模型审核最后才返回给用户。多一层成本但能避免很多麻烦。7. 我个人的选型决策清单聊了这么多最后把我实际用的决策清单分享出来你可以直接拿去改第一步明确任务类型和硬件约束圈定候选模型规模范围。第二步查许可证排除商用受限的。第三步看生态优先选社区活跃、教程多的。第四步用自建评测集跑一轮重点看指令遵循和格式稳定性。第五步测长文本和量化版本确认实际可用。第六步压测并发确认性能满足要求。第七步小流量上线观察真实表现再决定是否全量。这个流程走下来一般两三天能完成一轮完整对比。比起拍脑袋选一个然后反复返工这个投入是值得的。我在实际使用中发现最贵的成本从来不是模型推理本身而是选错模型后浪费的时间和返工。所以宁可前期多花点时间做对比也不要上线后才发现问题。另外一个小技巧把每次对比的评测集和结果都存档下次换模型时可以直接复用边际成本会越来越低。 
长河君 · 2026/11/5 2:50:13 · 阅读 1.2k 开源LLM选型实战：从硬件约束到量化部署的完整对比指南
1. 为什么现在聊开源LLM对比正当时过去一年我陆陆续续在本地和云端跑了不下二十个开源大语言模型从最早拿一张消费级显卡跑量化版到后来在几台服务器上做多模型并行推理踩过的坑能写满一个笔记本。LLM开源模型对比这件事放在两年前还只是少数极客的玩具现在已经变成很多团队做技术选型时绕不开的一道必答题。原因很直接闭源API按token计费量一大成本就失控数据合规要求越来越严很多业务数据根本出不了内网再加上开源模型迭代速度肉眼可见地加快某些场景下和头部闭源模型的差距已经缩到可以接受的范围。这篇文章想解决的问题很具体当你手里有一个真实任务面对几十个开源模型名字怎么快速筛出两三个候选怎么用最低成本验证它们到底行不行以及部署和量化时那些文档里不会写的细节。适合的读者包括正在做技术选型的工程师、想在自己机器上跑模型玩的爱好者以及需要给团队搭建内部推理服务的运维同学。我不打算堆砌跑分数字那些榜单比如Open LLM Leaderboard可以自己去看我更想聊的是榜单背后那些真正影响你决策的东西。先说一个我自己的判断开源模型没有绝对的好坏只有匹配不匹配。一个在通用榜单上排名靠前的模型放到你的垂直场景里可能被一个小得多的专用模型按在地上摩擦。所以对比的核心不是谁最强而是谁最适合我的任务、我的硬件、我的预算。2. 对比之前先想清楚你到底要什么2.1 先分清三类使用场景我在做对比之前习惯先把需求归到三类里因为不同类别的评估标准完全不一样。第一类是通用对话与写作辅助。这类任务对模型的指令遵循能力、语言流畅度、知识广度要求高参数量通常得在7B以上才有像样的表现。典型场景是内部知识问答、文案草稿、代码补全。第二类是垂直领域结构化任务。比如从合同里抽取字段、给工单分类、把非结构化文本转成JSON。这类任务往往可以用更小的模型1B到3B甚至经过微调后效果比大模型还稳因为任务边界清晰不需要模型什么都懂。第三类是RAG与知识库问答。热词里出现的llm wiki知识库rag graphrag llm wiki 本体rag其实都指向这个方向。这类场景里模型只是链条中的一环检索质量、切分策略、重排模型的影响可能比换LLM本身更大。我见过太多人把RAG效果差归咎于LLM不行结果换了三个模型都没用最后发现是切分粒度的问题。提示在开始对比前先用一句话写下你的任务目标越具体越好。比如把客服对话记录分类成8个标签准确率要过85%而不是做一个智能客服。目标越模糊对比越容易变成无意义的跑分游戏。2.2 硬件预算决定了你的候选池这一步很多人会跳过但它其实是最硬的约束。我整理了一张常见的硬件与模型规模对应表基于我实际跑下来的经验不是理论值硬件配置可流畅运行的模型规模量化建议典型吞吐tokens/s单张16G显存消费卡7B-8B4bit量化30-50单张24G显存13B-14B4bit或8bit20-40双卡48G32B4bit15-25单张80G专业卡70B4bit10-20CPU大内存7B以下GGUF格式3-8这张表里的数字是量级参考实际会因为你用的推理框架llama.cpp、vLLM、TensorRT-LLM等差出好几倍。vLLM在并发场景下的吞吐优势非常明显但显存占用也更高llama.cpp胜在灵活CPU也能跑适合个人玩。我个人的经验是如果你的显存刚好卡在某个规模的门槛上宁可降一档模型规模也不要硬上高量化等级。比如24G卡跑32B的4bit量化上下文一长就容易OOM体验很差不如老老实实跑14B把上下文留足。2.3 别忽略许可证和商用限制这一点经常被技术同学忽略但一旦踩坑代价很大。开源不等于免费商用有些模型的许可证对月活用户数、商用场景有明确限制。我在选型时会专门列一栏许可证类型把Apache 2.0、MIT这类宽松许可的排在前面把有额外限制的单独标注。具体哪些模型是什么许可证我这里不逐一列举因为更新太快建议你直接去模型的官方仓库看LICENSE文件那是最权威的。养成看许可证的习惯能帮你省掉未来很多麻烦。3. 核心对比维度我实际会看的六个指标3.1 指令遵循能力怎么测才靠谱榜单上的分数参考价值有限因为很多评测集和真实任务分布差很远。我的做法是自己造一套迷你评测集从真实业务里抽30到50条输入人工写好期望输出然后让候选模型跑一遍人工打分。打分维度我一般分三档完全符合、部分符合、完全跑偏。指令遵循能力最容易被低估的是格式稳定性——有些模型内容答得不错但让它输出JSON十次里有三次会多带一句解释这在程序化调用里是致命的。测试时有个技巧故意在指令里加一些约束比如只输出JSON不要任何其他文字字段名必须用下划线如果信息缺失填null。能稳定遵守这些约束的模型才值得进入下一轮。3.2 上下文长度与长文本表现现在很多模型标称支持128K甚至更长的上下文但标称长度和实际可用长度是两回事。我实测下来不少模型在超过标称长度一半之后中间部分的信息召回率就明显下降这就是常说的lost in the middle现象。测试方法很简单构造一段长文本把关键信息分别放在开头、中间、结尾然后提问。如果中间位置的信息经常被漏掉那这个模型的长上下文能力就要打折扣。对于RAG场景这一点尤其重要因为检索回来的片段往往堆在中间。注意长上下文会显著增加显存占用和推理时间注意力机制的计算量随长度增长很快。如果你的任务其实只需要几千token的上下文不要为了支持128K这个卖点去选一个又大又慢的模型。3.3 量化后的效果衰减热词里开源模型量化档排名说明大家很关心这个。量化确实能大幅降低显存需求但不同量化等级对效果的损伤不一样。我的经验是8bit量化效果损失通常可以忽略显存省一半左右4bit量化大部分任务损失很小但涉及精确计算、代码生成时可能出问题3bit及以下效果衰减明显除非实在没资源不建议量化方法也有讲究GPTQ、AWQ、GGUF各有适用场景。AWQ在推理速度上通常有优势GPTQ生态更成熟GGUF适合CPU和混合推理。同一个模型不同量化版本效果可能差出不少选型时最好把量化版本也纳入对比。3.4 推理速度与并发能力单条推理快不代表并发能力强。我见过单条响应很快的模型一上并发就排队严重。这里的关键指标是首token延迟和吞吐量前者影响交互体验后者影响服务成本。用vLLM做服务时可以通过调整max_num_seqs和gpu_memory_utilization来平衡。我一般先把gpu_memory_utilization设到0.9然后逐步加压测并发找到吞吐和延迟的平衡点。这个调参过程没有捷径只能实测。3.5 生态与工具链成熟度一个模型好不好用很大程度取决于周边生态。有没有现成的量化版本、有没有主流的推理框架支持、微调工具链是否完善、社区活跃度如何这些都会影响你的落地速度。我判断生态成熟度有个土办法去搜这个模型的微调教程和部署教程如果一搜一大把、而且时间都比较新说明社区活跃如果只有官方那几篇文档用起来大概率要自己填很多坑。3.6 微调友好度如果你的任务需要微调那基座模型的选择逻辑又不一样。有些模型天生适合微调LoRA一挂效果就上来有些模型微调后容易过拟合或者灾难性遗忘。这个只能通过实际微调实验来判断但可以先看社区里有没有人分享过类似的微调案例。4. 实操搭一套自己的对比流水线4.1 环境准备与推理框架选择我现在的标准做法是用vLLM做批量推理因为它对并发和吞吐的优化最好。安装不复杂但有几个坑要提前说# 建议用独立的虚拟环境避免依赖冲突 python -m venv llm_env source llm_env/bin/activate # 安装vLLM注意CUDA版本要匹配 pip install vllm # 如果要用AWQ量化模型还需要额外装 pip install autoawq第一个坑是CUDA版本和PyTorch版本的匹配这个不匹配会直接报错而且报错信息往往很隐晦。我的建议是先确认显卡驱动支持的CUDA版本再装对应版本的PyTorch最后装vLLM。第二个坑是显存碎片。长时间跑多个模型后即使卸载了模型显存也可能没完全释放。我的做法是每个模型跑完就重启一次推理进程虽然麻烦但最稳。4.2 构造评测集的具体方法评测集的质量直接决定对比结论的可信度。我的构造流程是这样的从真实业务数据里随机抽100条输入覆盖各种边界情况人工标注期望输出标注时记录这条为什么这么标把100条分成开发集30条和测试集70条开发集用来调prompt测试集只在最终对比时用为什么要分开发集和测试集因为如果你用同一批数据反复调prompt又评估很容易过拟合到这批数据上换一批真实数据效果就崩了。这个习惯是从做机器学习项目时带过来的在LLM评测里同样适用。4.3 批量推理与结果收集用vLLM做批量推理的代码框架大概是这样from vllm import LLM, SamplingParams # 加载模型注意量化配置 llm LLM( modelyour-model-path, quantizationawq, # 如果是量化模型 gpu_memory_utilization0.9, max_model_len8192, ) # 采样参数评测时建议temperature设0保证可复现 sampling_params SamplingParams( temperature0, max_tokens1024, ) # 批量推理 outputs llm.generate(prompts, sampling_params) # 收集结果 for output in outputs: generated output.outputs[0].text # 保存到文件后续人工或自动评估这里有个细节评测时temperature一定要设0否则同样的输入每次输出都不一样没法公平对比。有些模型在temperature0时仍然有随机性比如某些MoE架构这种情况我会跑三次取平均。4.4 自动评估与人工评估结合纯人工评估太慢纯自动评估又不可靠。我的做法是分两层先用规则做粗筛比如检查输出是否是合法JSON、是否包含必需字段、长度是否在范围内通过粗筛的再人工看内容质量。对于分类任务可以直接算准确率对于生成任务我一般用人工打分模型打分结合。模型打分就是让一个更强的模型比如闭源API来给候选模型的输出打分虽然不完美但能快速筛掉明显差的。5. 常见问题与排查实录5.1 模型加载失败与显存不足这是最高频的问题。排查顺序我一般是现象可能原因排查方法加载时报OOM显存不够或碎片降低gpu_memory_utilization重启进程加载后推理报错量化格式不匹配确认推理框架支持该量化格式推理中途OOM上下文过长降低max_model_len或分批处理速度异常慢用了CPU卸载检查是否有层被卸载到CPU我踩过最坑的一次是模型明明能加载但一推理就崩查了半天发现是量化版本和推理框架版本不兼容。换量化版本前先确认框架的支持列表能省很多时间。5.2 输出格式不稳定的处理前面提到过格式不稳定是程序化调用的大敌。我的应对策略有三层第一层是在prompt里把格式要求写到最前面和最后面中间用分隔符隔开利用模型的近因效应。第二层是加few-shot示例给两三个输入输出对模型模仿能力很强。第三层是加后处理用正则或JSON解析器兜底解析失败就重试。如果三层都上了还是不稳定那说明这个模型不适合这个任务果断换。5.3 长文本信息丢失的应对除了前面说的测试方法实际使用中我还会做一件事把关键信息在prompt里重复一次。比如RAG场景检索回来的片段里如果有关键实体我会在问题里再提一遍。这个土办法实测能明显提升召回。另外如果任务允许把长文本拆成多个短片段分别处理再汇总结果往往比硬塞进长上下文效果好。这就是map-reduce的思路虽然多花点token但稳定性高很多。5.4 并发场景下的性能调优并发一上来问题就多了。我遇到过的情况包括请求排队导致超时、显存不够导致部分请求失败、不同长度请求混在一起导致长请求饿死。vLLM里可以通过设置max_num_seqs控制同时处理的序列数通过max_num_batched_tokens控制单批token总量。我的调参顺序是先固定max_model_len然后逐步提高max_num_seqs直到延迟开始明显上升取那个临界点。提示生产环境一定要加监控记录每个请求的延迟和成功率。我见过太多服务上线后没人看指标等用户投诉才发现问题。6. 几个容易被忽略的选型细节6.1 分词器对中文的影响这个点很少有人提但对中文任务影响很大。不同模型用的分词器不一样同样一段中文有的模型切成100个token有的切成150个。token数直接影响成本和上下文占用。测试方法很简单拿一段典型的中文文本用不同模型的分词器切一下看token数。如果某个模型中文token效率特别低那在长文本场景下就很吃亏。6.2 模型更新频率与版本管理开源模型迭代很快同一个名字可能几个月就出新版本。我的做法是在项目里锁定具体版本号不要用latest。同时记录每个版本的表现方便回滚。另外模型权重文件很大下载和存储都是成本。我一般只保留当前在用的两三个版本其他的归档到冷存储。6.3 安全与合规的边界开源模型没有内容过滤输出什么完全取决于你的prompt和模型本身。如果面向终端用户一定要在应用层加过滤和审核。这块不是模型能解决的是工程问题。我在实际项目里的做法是模型输出先过一遍规则过滤敏感词、格式校验再过一遍小模型审核最后才返回给用户。多一层成本但能避免很多麻烦。7. 我个人的选型决策清单聊了这么多最后把我实际用的决策清单分享出来你可以直接拿去改第一步明确任务类型和硬件约束圈定候选模型规模范围。第二步查许可证排除商用受限的。第三步看生态优先选社区活跃、教程多的。第四步用自建评测集跑一轮重点看指令遵循和格式稳定性。第五步测长文本和量化版本确认实际可用。第六步压测并发确认性能满足要求。第七步小流量上线观察真实表现再决定是否全量。这个流程走下来一般两三天能完成一轮完整对比。比起拍脑袋选一个然后反复返工这个投入是值得的。我在实际使用中发现最贵的成本从来不是模型推理本身而是选错模型后浪费的时间和返工。所以宁可前期多花点时间做对比也不要上线后才发现问题。另外一个小技巧把每次对比的评测集和结果都存档下次换模型时可以直接复用边际成本会越来越低。