我在2025年做AI模型开源推荐时，最怕的不是模型效果不够好，而是许可证里藏着一句“禁止商用”或者“月活超过一定规模要单独授权”。过去一年我帮三家企业做选型，有两家差点把研究版权重直接搬进生产环境，后来都是靠逐条读模型卡和LICENSE文件才避开了坑。这篇候选清单围绕“能商用、好落地、有社区”三个维度展开，把我自己反复验证过的模型和许可边界讲清楚，方便你在做AI模型开源推荐时少走弯路。
1.1 可商用开源模型的定义与许可证核查要点
我理解的可商用开源模型，不是“权重能下载”就算数。权重开放只是起点，许可证要明确允许商业使用、允许再分发、允许衍生模型，最好还能允许你拿模型输出做训练数据。很多模型卡写得客气，LICENSE却把商用门槛藏得很深，我见过一个中文模型在补充条款里要求“商业产品需邮件申请”，这种就不适合直接进生产。我的习惯是把Hugging Face上的模型卡、LICENSE、GitHub仓库的NOTICE文件三处对照看，缺一处就标记为待核查。
许可证核查我一般盯六个点：商用是否被明确允许、有没有用户规模或营收阈值、是否要求保留归属声明、再分发和托管服务是否被限制、衍生模型命名有没有额外要求、专利和出口管制条款是否清晰。Apache 2.0和MIT这类许可证用起来最省心，Llama社区许可、Gemma许可、Qwen部分版本的自定义条款就要逐字读。我吃过一次亏，客户把某模型集成进SaaS后才发现许可证要求“对外展示模型名称”，临时改产品文案很被动。你如果做的是闭源产品，优先选Apache 2.0或MIT；做开源产品也要看衍生模型是否必须同名发布。
还有一点容易被忽略：训练数据和输出内容的合规边界。许可证允许商用，不代表模型输出可以随便用。我在实际项目里会把“许可证核查”和“数据合规核查”分开做两张表，一张记录模型权重许可，一张记录训练数据来源和已知风险。AI模型开源推荐不能只看榜单分数，许可边界清晰的模型才值得长期投入。我的做法是给每个候选模型打三个标签：许可清晰度、商用友好度、社区响应速度，三个都过线才进入短名单。
1.2 通用对话、推理与长上下文模型推荐
通用对话和推理这块，我2025年最常推荐的候选是Llama 3.1系列、Qwen2.5系列、DeepSeek-R1蒸馏版和Mistral Small 3。Llama 3.1的8B和70B在英文对话、工具调用上很稳，社区微调资源多，许可证允许商用但要看月活条款。Qwen2.5的7B、14B、32B、72B多数版本用Apache 2.0，中文对话和指令跟随很顺手，我做企业知识库时经常拿它做基座。DeepSeek-R1的蒸馏小模型在推理任务上性价比高，适合预算有限又要思维链效果的团队。Mistral Small 3体积不大，函数调用和低延迟场景表现不错。
长上下文模型我会单独列一档。Llama 3.1原生支持128K上下文，Qwen2.5部分版本支持128K甚至更长，DeepSeek系列在长文档理解上也有不错的表现。我实测过一个合同审阅场景，128K上下文能把整份采购合同和附件一起塞进去，省掉不少切片逻辑。长上下文不等于长上下文好用，我建议你做AI模型开源推荐时加一条“有效上下文测试”，拿真实长文档跑问答和摘要，看模型在中后段是否掉链子。有的模型标称128K，实际到64K之后召回明显变弱，这种就要在部署时做分块兜底。
我的通用对话候选清单会按语言和任务分：中文优先Qwen2.5-32B和DeepSeek-R1蒸馏版，英文优先Llama 3.1-70B和Mistral Small 3，轻量对话选Qwen2.5-7B或Llama 3.2-3B。推理任务别只看 benchmark，我会用同一套业务问题跑三遍，看稳定性。长上下文场景优先选原生支持长上下文的模型，别硬靠外推。许可证方面，Qwen2.5的Apache 2.0版本最省心，Llama和Gemma要保留归属声明并核对商用条款。这套组合我在三个项目里复用，落地速度比追新模型快得多。
1.3 代码生成、多模态与中文垂直领域模型推荐
代码生成我2025年常推Qwen2.5-Coder系列、DeepSeek-Coder-V2和CodeLlama的社区微调版。Qwen2.5-Coder的7B和32B在补全、解释、单元测试生成上很均衡，Apache 2.0许可对商业产品友好。DeepSeek-Coder-V2的MoE版本在复杂重构任务上有优势，显存要求也更高。CodeLlama生态老但稳定，适合已经围绕它搭好工具链的团队。我做代码助手选型时会看三个指标：补全接受率、跨文件理解、许可证是否允许闭源集成。前两个靠实测，第三个靠读LICENSE。
多模态候选我关注Qwen2-VL、InternVL2.5和Llava-OneVision。Qwen2-VL在中文OCR、图表理解上表现突出，许可条款要按具体版本核对。InternVL2.5在文档视觉问答上很稳，社区更新快。Llava-OneVision适合做通用图像对话原型。我帮一家做票据识别的客户选型时，把同一批发票分别喂给三个模型，Qwen2-VL在中文手写体上优势明显，InternVL2.5在表格结构还原上更细。多模态模型的商用许可比纯文本模型更容易踩坑，有的版本对图像训练数据来源有额外说明，我会让法务一起看模型卡。
中文垂直领域我常推荐Qwen2.5、GLM-4-9B和Baichuan2的商用版本。Qwen2.5在中文知识问答和长文本摘要上均衡，GLM-4-9B在中文对话和工具调用上轻快，Baichuan2在垂直行业微调上有不少现成案例。我做AI模型开源推荐时会提醒一句：中文垂直领域别只看通用榜，拿你的行业语料做50到100条人工评测，比榜单更能说明问题。医疗、金融、法律这类场景还要看模型卡里有没有行业限制条款，有的许可证明确不允许用于高风险决策，这种就要提前排除。
1.4 不同参数规模与硬件预算下的推荐组合
小参数规模我一般分1B到8B这一档，适合边缘设备、个人开发和小流量客服。Qwen2.5-7B、Llama 3.2-3B、Gemma 2-2B/9B、Phi-4-mini都在我的候选里。24GB显存的消费级显卡跑7B到8B的4bit量化很轻松，32GB内存的迷你主机也能跑3B到7B的量化版。我给个人学习者的组合是Qwen2.5-7B加Ollama，上手快，中文支持好。给企业轻量客服的组合是Qwen2.5-7B或Gemma 2-9B加vLLM，吞吐比裸跑高不少。
中参数规模我指14B到32B，适合企业知识库、代码补全和中等复杂度Agent。Qwen2.5-32B、Gemma 2-27B、Mistral Small 24B是这个档位的常客。单卡48GB显存可以跑32B的4bit量化，80GB显存可以跑FP8或更高精度。我做过一个对比，Qwen2.5-32B在中文RAG场景里比7B明显稳，引用和拒答都更合理。硬件预算有限时，我会建议先上32B的4bit量化，再把省下的钱投到检索和评测上，效果提升比硬上70B更明显。
大参数规模我指70B及以上，适合复杂推理、高质量内容生成和多Agent协作。Llama 3.1-70B、Qwen2.5-72B、DeepSeek-V3这类MoE模型都在候选里。70B模型用4bit量化大约需要40GB到48GB显存，多卡80GB更从容。MoE模型总参数大，激活参数少，推理成本要看具体框架和并行策略。我给预算充足的团队推荐“70B主模型加7B小模型路由”的组合，简单问题走小模型，复杂问题走大模型，成本可控。AI模型开源推荐里我常放一张硬件预算表，把显存、量化方式、预期吞吐写在一起，选型时不容易拍脑袋。
1.5 推荐清单的版本更新、社区活跃度与避坑要点
我维护推荐清单的习惯是每月看一次Hugging Face趋势榜、GitHub release和模型卡更新。模型版本迭代很快，许可证也可能随版本变化，上个月还能商用的条款这个月加一句限制，这种情况我遇到过。我的做法是给每个候选模型记录三个日期：权重发布日、许可证最后修改日、社区最后一次有效回复日。三个日期都新鲜，才留在推荐位。AI模型开源推荐不能只给名字，还要给版本号和核查日期，不然读者拿去用容易踩空。
社区活跃度我看四件事：issue响应速度、微调脚本是否维护、量化版本是否官方或高信誉社区出品、中文社区有没有实操案例。一个模型榜单分数再高，issue一个月没人回，我也不会把它放进生产推荐。量化版本要特别小心，非官方量化可能在中文任务上掉点明显，我会拿同一批问题对比FP16和4bit的输出差异。还有benchmark污染问题，有些模型在公开榜上分数漂亮，换到业务数据就露馅。我的避坑清单里有一条：任何模型都先用200条真实业务问题做盲测，再谈推荐。
版本更新方面我会区分“追新”和“追稳”。个人学习可以追新，企业生产我更倾向选发布三个月以上、有稳定微调生态的版本。许可证变更要设置提醒，模型卡和LICENSE文件加书签，每月扫一眼。社区活跃度低的模型不是不能用，要预留替换成本。我常跟团队说，AI模型开源推荐的核心不是找到最强模型，而是找到许可清楚、社区能兜底、替换成本可控的模型。这份清单我会按季度更新，把许可边界和实测结论一起写进去，方便你直接拿去做选型讨论。
我去年帮一家做法律科技的朋友搭本地推理环境，一开始想当然觉得“4090加Ollama一键跑起来就完事”，结果合同审阅场景要塞128K上下文，显存直接爆了，换vLLM加量化才稳住。本地部署这件事，最怕拿跑分论坛的结论套自己的业务，硬件、框架、模型三者匹配错了，钱花了效果还打折。这一章我把过去一年亲手测过的指标、框架、硬件组合摊开讲，尽量把“别人说行”变成“我自己跑过”。
2.1 本地部署对比评测的指标体系：显存、吞吐、延迟与上下文
我评本地部署先看显存占用，而且是分项看。模型权重占多少、KV cache占多少、框架自身开销占多少，三块要分开记。很多人只算权重，7B模型4bit大约4GB，就以为8GB显卡够用，实际跑长上下文时KV cache能吃掉好几GB，Ollama默认的上下文长度又偏保守。我习惯用nvidia-smi和框架自带日志对照，跑一个2048上下文和一个32768上下文的请求，把峰值显存都记下来。显存这条线不清楚，后面吞吐和延迟的测试结果都不可信。
吞吐我拆成prefill和decode两个数看。prefill是处理输入的速度，长文档场景特别关键；decode是逐token生成的速度，对话体感主要看它。我用同一段2000字中文输入加固定问题，测TTFT（首token延迟）和稳定后的tokens/s。有的模型短输入很快，塞到32K输入prefill就慢得离谱，这种在RAG场景里会明显拖体验。延迟方面我会记录P50和P95，只看平均值容易被偶发长尾骗过去。上下文指标我建议加一条“有效上下文衰减测试”，从4K到128K逐档递进，看问答准确率什么时候开始掉，比标称参数有用得多。
我的评测表里有四列是必填的：显存峰值、prefill tokens/s、decode tokens/s、P95首token延迟。硬件型号、框架版本、量化方式、上下文长度四个条件要一起写进表头，缺一个结论就会漂。这套表我拿去对比Qwen2.5-32B和Llama 3.1-70B的量化版本，同一张4090上差异大到不能凭感觉判断。做本地部署对比评测，指标不求多，求的是每一条都能复现。
2.2 主流推理框架与部署工具对比：Ollama、llama.cpp、vLLM、SGLang等
Ollama是我给个人和小团队的首选入口，装完拉个模型就能聊，中文社区教程也多。它的好处是把模型下载、量化格式、服务暴露都包了，坏处是并发一上来吞吐就顶不住，生产环境我不太敢把它放在主链路。我拿Ollama跑Qwen2.5-7B的Q4_K_M，单并发对话很顺，五个并发同时打过来延迟明显抖。适合原型验证、内部试用、个人学习，不适合高并发API服务。
llama.cpp是更底层的选择，GGUF格式生态成熟，CPU加GPU混合推理是它的强项。我在一台没有独显的迷你主机上跑3B量化版，CPU推理速度能接受，做本地知识库的离线版本很实用。llama.cpp的参数调优空间大，n_gpu_layers、batch size、上下文长度都要自己拧，调好了性价比很高，调不好就一直在试错。它更像发动机，不是整车，喜欢折腾的人会觉得很顺手。
vLLM是我做生产部署的主力。PagedAttention对KV cache的管理确实省显存，连续批处理把吞吐拉得很高，OpenAI兼容接口接起来也快。我实测Qwen2.5-32B的AWQ量化版在单张A6000上，vLLM的吞吐比Ollama高出一大截，并发越高差距越明显。代价是部署配置比Ollama复杂，模型格式、tensor parallel、gpu_memory_utilization这些参数要理解清楚。SGLang我在结构化输出和Agent场景里用得越来越多，RadixAttention对共享前缀的复用很聪明，多轮对话和固定系统提示词的场景延迟优势明显。框架选型我的原则是：原型用Ollama，离线嵌入用llama.cpp，生产API用vLLM，结构化生成密集的用SGLang，别指望一个框架打天下。
2.3 消费级显卡、工作站与服务器硬件的适配方案对比
消费级这块我测最多的是RTX 4090 24GB和3090 24GB。4090跑7B到14B的4bit量化很从容，32B的AWQ量化勉强能塞进去，上下文一长就得缩。3090显存一样但带宽低一些，decode速度差一截，二手价格香，适合预算紧的个人开发者。我自己的测试机上，Qwen2.5-14B的GPTQ Int4在4090上decode能到四十多tokens/s，32B同量化掉到十几，长上下文再打折。消费级卡做个人知识库、代码补全、小流量客服够用，做多人并发的生产服务要谨慎。
工作站档我关注A6000 48GB和双4090的组合。48GB单卡跑32B的FP8或者70B的4bit都更从容，长上下文不用频繁切分。我帮客户配过一台A6000的工作站，跑Qwen2.5-32B的AWQ加vLLM，十来个并发下P95延迟还能接受，合同审阅这种长文档场景比4090稳很多。双4090的方案显存加起来也是48GB，问题在跨卡通信和框架支持，vLLM的tensor parallel能跑，调参成本比单卡高。工作站适合中小团队做内部服务，性价比取决于并发量和上下文长度。
服务器档就是A100 80GB、H100这类，我接触得多的是租赁环境。70B模型FP16要140GB以上显存，得双卡或者多卡；4bit量化单张80GB能跑，吞吐和长上下文都舒服。MoE模型像DeepSeek-V3这种，总参数大激活参数小，显存要按总参数算，推理成本看框架的专家并行做得怎么样。Mac Studio的统一内存方案我也试过，M2 Ultra 192GB能塞下很大的模型，prefill速度不错，decode和CUDA卡比有差距，适合做本地开发和演示，不适合高吞吐生产。硬件适配没有标准答案，先定上下文长度和并发目标，再倒推显存和卡型，顺序反了容易买错。
2.4 量化、微调与推理优化对效果和成本的影响评测
量化是我本地部署里最常做的取舍。GGUF的Q4_K_M、AWQ的Int4、GPTQ的Int4我都对比过，7B和14B模型上4bit量化的效果损失在多数业务任务里不明显，32B以上更稳。中文任务上我遇到过非官方量化版本把标点和对齐细节弄乱的，同一批测试题FP16答对八成，某个社区量化版掉到六成多。我的做法是量化前后各跑200条业务问题盲测，重点看拒答、引用准确性、格式遵循这三项。量化省的是显存和钱，别把效果省没了。
微调方面我用LoRA居多，全参微调在本地环境里成本太高。LoRA的好处是基座模型可以换量化版，适配器体积小，实验迭代快。我做过一个中文客服的LoRA，训练数据两千多条，单张4090跑了几个小时，效果比纯提示词工程稳。微调和量化可以叠加，顺序上我一般先量化基座再挂LoRA，也有框架支持合并后重新量化。要注意的是微调后的模型再量化，效果损失可能比原版量化更大，得重新测。
推理优化我关注几个点：FlashAttention类实现有没有开、连续批处理有没有生效、投机解码适不适合当前任务、prefix caching能不能命中。投机解码在代码补全这种可预测性强的任务上提速明显，开放对话里收益不稳定。prefix caching对固定系统提示词的多轮场景很划算，vLLM和SGLang都支持。我做过一个对比，同样硬件和模型，开了prefix caching后多轮对话的P95首token延迟降了不少。优化手段要一项项加、一项项测，堆在一起上出了问题都不知道是哪项惹的。
2.5 本地部署的安全、运维、监控与稳定性对比
本地部署的安全我分三层看：模型文件来源、服务暴露面、数据留存。模型文件我只从官方仓库或高信誉社区下载，下载后校验哈希，非官方量化版本会先在小环境跑一遍再进内网。服务暴露面这块，Ollama默认监听本地，改成对外提供服务时一定要加认证和限流，我见过直接把11434端口开到公网的案例。数据留存要看框架日志默认记什么，vLLM和Ollama的日志级别要调过，避免把用户输入原样落盘。
运维和监控我盯四类指标：显存使用率、请求队列长度、P95延迟、错误率。显存缓慢上涨往往是KV cache没释放干净或者长上下文请求堆积，队列长度持续高位说明并发超了硬件能力。我用Prometheus加Grafana搭过一套简单的看板，vLLM自带metrics端点，接起来不难。稳定性方面我会做持续压测，跑几个小时看延迟漂移和内存泄漏，短时间压测看不出慢性问题。模型热更新和版本回滚也要提前设计，别等上线后才发现换模型要停服务。
我踩过最疼的一次坑是量化模型在长上下文下偶发输出乱码，短请求完全正常，压测了两天才定位到是某个量化版本和框架版本的兼容问题。从那以后我的部署清单里加了一条：任何新组合先跑72小时混合负载稳定性测试，再谈上线。本地部署对比评测写到运维这一层，才算把“能跑”和“能长期跑”分开。安全、监控、稳定性这三块不显眼，出问题的时候最要命。
选型这件事我越干越觉得像配药方，同一个模型别人用着香，换到你的业务里可能就成了鸡肋。上一章聊的是本地部署怎么测、怎么跑，这一章我往上退一步，讲怎么根据场景先选对模型和路线。说实话，模型榜单我每周都刷，真到给客户出方案的时候，榜单排名反而排在场景匹配后面。我这几年踩的坑里，一大半不是模型不行，是选型和场景拧着来。
3.1 按应用场景推荐：个人学习、企业知识库、代码助手与多模态应用
个人学习这个场景我一般直接推Qwen2.5-7B或者Llama 3.1-8B的Instruct版本，配Ollama装在笔记本上就能跑。想练推理能力就上DeepSeek-R1的蒸馏小模型，7B、14B都有，思考链看得见，学prompt和调参很直观。我自己的学习机上常年挂着两三个小模型换着试，显存占用小，折腾坏了重拉一个也就几分钟。个人场景别一上来就盯着70B，跑不动还打击积极性。
企业知识库我推荐的组合是embedding模型加对话模型的搭档。embedding用BGE-M3或者Qwen3-Embedding，中文检索效果好，多语言也能兜住。对话侧看文档长度，普通FAQ场景14B到32B的量化版够用，合同、研报这种长文档场景我倾向32B起步，上下文能顶到32K以上才踏实。我帮一个制造业客户搭内部知识库，一开始用7B，答得挺顺但引用经常张冠李戴，换到Qwen2.5-32B的AWQ版本后引用准确率明显上来。知识库场景里检索质量和模型选型是乘法关系，哪一头短板都白搭。
代码助手我用得最多的是Qwen2.5-Coder系列，7B、14B、32B都有，补全和解释都不错。DeepSeek-Coder-V2在复杂重构任务上表现也稳，就是部署门槛高一些。我日常写脚本用14B的Coder模型挂在VS Code里，补全延迟能接受，复杂逻辑还是会切到32B。多模态这块Qwen2.5-VL和InternVL2是我测下来比较顺手的，做票据识别、截图问答这类任务，7B级别的多模态模型配合提示词工程就能出活。多模态选型要盯分辨率处理和视频帧支持，这两项直接决定能不能接住你的业务输入。
3.2 开源模型生态与工具链评估：模型社区、RAG、Agent与微调工具
模型社区我主要看HuggingFace和ModelScope两个。HF的模型卡、讨论区和引用信息全，判断一个模型靠不靠谱，我会翻它的下载曲线、issue回复速度和最近更新时间。ModelScope对国内网络友好，中文模型上新快，有些国产模型只在这儿首发。我下模型有个习惯，先看官方仓库有没有对应版本，社区量化版只作备选。一个模型半年不更新、issue没人回，我基本就把它从候选里划掉了。
RAG工具链我常用的组合是Dify或者RAGFlow做应用层，底层接vLLM或者Ollama。Dify的好处是可视化编排快，给非技术同事演示特别省事；RAGFlow的文档解析做得细，复杂PDF和表格场景优势明显。LangChain和LlamaIndex我更多用在需要深度定制的项目里，灵活但要写的代码多。RAG效果好坏，切分策略和rerank模型占的比重不比生成模型小，我一般会加一个BGE-reranker做二阶段排序，命中率提升肉眼可见。
Agent框架我这两年从AutoGen换到LangGraph用得更多。LangGraph的状态机模型对复杂流程控制更清楚，调试时能看清每一步在哪卡住。CrewAI适合快速搭多角色协作的原型，上手快，生产环境我会谨慎一些。微调工具LLaMA-Factory是我推荐给团队的首选，Web界面友好，LoRA、全参、量化微调都支持，中文文档也全。Unsloth在单卡上训练速度有优势，显存吃得少，适合个人开发者折腾。工具链选型我的原则是先用成熟组合跑通闭环，再考虑替换零件，一上来全自研的团队我见过好几个都卡在工具适配上。
3.3 API调用、本地部署与混合部署的成本和ROI对比
API调用我一般推荐给验证期和低流量场景。按token付费没有前期硬件投入，模型还能随时换最新的，试错成本低。短板在长尾成本和高频调用，流量一上来账单涨得比想象快，数据出域对一些行业也是硬约束。我算过一笔账，一个中等流量的客服机器人，日调用几十万token，API月账单和一张4090的折旧比，前期API划算，跑满一年本地部署就开始反超。这个交叉点在哪，取决于你的调用量和数据敏感度。
本地部署的成本我拆成四块算：硬件折旧、电费、运维人力、机会成本。硬件折旧按三年摊，电费按满载功率估，运维人力是最容易被低估的一块，模型更新、故障处理、安全加固都要人。我见过团队只算了显卡钱，上线后运维占了半个人力还喊亏。本地部署的ROI优势在稳定高并发和数据不出域两个条件同时成立时才明显，缺一个都要重新算。
混合部署是我给多数企业的建议。敏感数据走本地模型，通用问答和低敏感任务走API，路由层按数据分级做分流。我帮一家金融客户搭过这种架构，合同和客户信息在本地跑，营销文案生成走API，成本降了，合规也过得去。混合架构的复杂度在路由和结果一致性，同一个问题两边答案风格不同会让用户困惑，提示词模板要统一维护。部署路线没有绝对优劣，先把自己的调用量、数据分级、团队运维能力三项写清楚，答案基本就浮出来了。
3.4 合规、隐私、安全与开源供应链风险清单
许可证核查我每次都从模型卡和官方仓库的LICENSE文件两头对。Apache 2.0和MIT最省心，商用限制少；Llama社区许可证有月活门槛和署名要求，Qwen系列多数是Apache 2.0，用之前还是逐版本确认。我遇到过一个团队拿社区微调版直接商用，后来发现基座是带非商用条款的，返工成本很高。许可证这件事，模型换版本就要重查一遍，别拿旧结论套新模型。
隐私和安全我关注数据流和模型行为两条线。数据流看推理日志、缓存、监控埋点会不会把用户输入落盘或者外传，本地部署也不是天然安全，框架默认日志级别要改。模型行为看越狱抵抗和输出过滤，开源模型没有厂商兜底，护栏要自己加。我给生产环境配的清单里有：输入输出内容审核、敏感词过滤、提示词注入检测、审计日志留存。这几项不做，模型能力越强风险越大。
开源供应链风险是我这两年越来越重视的一块。模型文件要校验哈希，非官方量化版先隔离环境跑，权重里藏后门的研究已经有不少案例。依赖库的漏洞也要盯，推理框架和Python包的安全公告我让团队每周扫一次。国内商用还要看算法备案和生成式AI服务管理要求，涉及面向公众提供服务的场景，备案流程要提前排期。合规清单我建议做成表格逐项打勾，口头确认靠不住。
3.5 2025年开源大模型趋势与持续推荐更新机制
2025年我看到的几个明显趋势：MoE架构在中大参数模型里越来越主流，总参数大、激活参数小，推理成本降得明显；小参数模型能力还在涨，7B到14B级别在垂直任务上已经能打；推理模型这一支从DeepSeek-R1带起来后，蒸馏版遍地开花，数学和代码场景受益最大；多模态走向统一架构，文本图像视频一个模型接。这些趋势对选型的影响是，候选清单的更新频率要跟上，半年不看的清单基本过期。
我自己的更新机制是三件事：订阅几个官方模型仓库的release、每周扫一次社区热榜和评测榜、每季度对在用的模型做一次复评。复评不看榜单排名，看自己业务测试集上的表现，同一批200条问题跑一遍，分数掉了就查原因。新模型出来我不急着换，先在小流量环境灰度，稳定两周再考虑迁移。模型迁移的成本主要在提示词适配和输出格式差异，这两项要提前测。
持续推荐这件事我做得比较土，维护一个内部表格，列模型名、许可证、参数规模、擅长场景、实测分数、最近更新时间。团队里谁试了新模型就往里填一行，季度会上过一遍。这个表比任何榜单都贴合自己的业务。开源模型迭代太快，指望一次选型管三年不现实，把更新机制建起来，比选中某个“最强模型”重要得多。
