2026年9月如果再有人问我“推荐用哪个大模型”我都会先反问一句你是在选模型还是在选应用这两个问题经常被我那些做技术的朋友混在一起结果就是要么盯着榜单上的跑分选了根本部署不动的模型要么看着应用商店里五花八门的AI工具不知道该信谁。今天我就把“模型维度”和“应用维度”拆开讲清楚把国内外值得关注的大模型盘一遍再聊聊真正落到业务里该怎么选、怎么干、怎么避坑。适合正在做AI应用开发、企业技术选型或者纯粹想折腾本地大模型的朋友。先说清楚这篇不是官方榜单的复述而是我作为常年跟大模型打交道的技术人从使用和落地角度做的盘点和经验分享。文中提到的一些版本号、参数档位都是以我最近接触到的情况为准模型迭代太快具体以各家官方文档为准。1. 国内外大模型家底盘点闭源旗舰与开源主力谁在挑大梁先看模型维度。这里的“模型”指的是底层能力不是套在上面的产品。从国内外格局来看大致能分成两条线一条是闭源API一条是开源权重。闭源API在综合能力上仍然领先但开源模型正在以极快的速度缩小差距很多场景下已经够用而且能自己部署。1.1 海外闭源阵营GPT、Claude、Gemini还是绕不开的标杆海外闭源这边OpenAI的GPT系列从GPT-4o开始到后来的o系列推理模型能力分水岭非常明显。o系列最擅长的是把问题拆成一步步推理写代码、解数学题、处理逻辑链条很长的任务表现确实强。Anthropic的Claude是我个人在编程助手场景里用得最多的Claude在长上下文上的处理以及修改代码时的“克制感”很对我的胃口它不像某些模型那样动不动就给你重写一个文件而是尽量只改需要改的地方。Google的Gemini则是原生多模态设计视频、音频、图像的输入输出做得最自然适合做多模态应用。xAI的Grok这几年也把推理和实时信息的结合做得不错但在企业级生态和API稳定性上还是比前三家差一些。这些闭源模型的特点是综合能力强几乎开箱即用但成本、数据合规和数据出境问题需要认真评估。对于出海业务、编程辅助、通用创作直接调用闭源API依然是最省力的方案。1.2 国内闭源与商业模型从百家争鸣到各有主场国内这边2026年的格局已经不像前几年那么分散了。阿里的通义千问Qwen走的是开源闭源双线路线开源权重给了社区闭源的qwen-max、qwen-plus等承担企业服务生态覆盖很广。DeepSeek是这几年最有冲击力的变量R1系列带起来的“思维链可视化”让很多人第一次感受到开源模型也能有很强的推理能力而且中文理解和性价比都很突出。智谱AI的GLM做得早AutoGLM这类智能体方向布局很深。字节的豆包不只有C端爆款模型服务在字节体系内也是大流量验证过的。腾讯混元深扎在微信生态和腾讯云百度的ERNIE仍然是中文理解的老牌选手月之暗面的Kimi靠长文本和Agent能力圈了一波忠实用户。国内闭源模型的优势是中文本土化好、接口可以直接在中后台对接响应也快很多企业不想自建GPU的时候优先用它们。但它们的问题也是版本更新太快接口和模型名称经常调整做选型时要留好后路别把业务死死绑在某个特定模型的私有格式上。1.3 开源模型家底Llama、Qwen、Mistral、DeepSeek各守一方开源模型才是真正改变游戏规则的那部分。Meta的Llama系列是海外开源生态最不能忽视的Qwen系列可以说是中文开源模型里生态最完整的从0.5B到72B覆盖轻量端侧到服务器级还有VL多模态分支Mistral在欧洲和法语场景有优势小模型做得轻快DeepSeek拿得出手的开源版本在多语言推理和数学方向相当能打。再加上Phi、Gemma这些轻量级模型开源生态已经足够支撑大部分人做本地部署和领域微调。整理一个我近期使用频率较高的开源模型清单给不同硬件条件的读者做个参考模型系列常见参数档位典型硬件我会用在哪些场景Qwen2.5系列0.5B / 7B / 14B / 72B7B约需8GB以上显存72B需要多卡或量化中文知识库、行业微调、端侧Llama 3.x8B / 70B8B约需8~12GB显存英文场景、通用对话、RAGDeepSeek-R1系列1.5B / 7B / 32B / 70B7B约需10GB显存推理任务、数学逻辑、AgentMistral7B / 8x7B8x7B建议24GB以上显存轻量部署、多语言Gemma2B / 7B2B可跑CPU端侧、轻任务、打磨Prompt表格里这些参数档位不是绝对标准量化位不同、上下文长度不同显存需求都会变。我的建议是先定场景再定部署硬件最后倒推模型档位不要一上来就追最大的。2. 应用层早已不止聊天框从AI助手到行业智能体的三种真实形态模型能力再强最终还是要落到“应用”这两个字上。应用维度我把它分成三种形态通用助手的对话式应用、本地部署的私域应用、以及嵌入业务的智能体应用。这三类的技术栈、投入和效果评估方法完全不一样。2.1 通用助手类应用提示词和上下文工程是真正的分水岭第一类是大众感知最强烈的聊天助手比如海外的ChatGPT、Claude国内的豆包、Kimi、文小言。这些产品背后往往是该厂商能力最强的闭源模型用户不需要关心模型参数只关心体验。但“会用”和“用好”差距很大。很多人觉得提示词工程不重要了因为模型越来越聪明事实恰恰相反——模型越强Prompt技巧越要简洁精准上下文工程才是拉开效率的地方。一个能很好组织Few-shot示例和系统提示词的助手和一个只会一句话闲聊的助手在代码生成、行业问答上的产出质量可以差一个数量级。所以如果你的应用只是套一层聊天框那核心竞争力就只剩提示词和上下文管理能力了。2.2 本地部署与端侧智能把大模型装进个人电脑和手机第二类是本地部署。我最近看到的热搜里有一条很典型“本地部署大模型让个人电脑智能化”。这确实是现在的趋势。本地部署最大的价值不是省钱而是数据不出设备、可以离线运行、可以针对自己的数据做定制。技术实现上模型量化格式GGUF是目前端侧部署的事实标准配合Ollama、LM Studio这类运行时个人电脑装个7B模型跑对话、写摘要、做本地RAG体验已经相当流畅。移动端的话Android App集成AI大模型GGUF也在变得越来越常见比如在笔记App里塞一个本地摘要模型在客服App里做离线意图识别。端侧模型普遍是2B、7B档位更强调CPU和NPU的适配不能照着服务器部署的思路来。2.3 行业智能体与知识库从“会聊天”到“能干活”第三类是真正跟业务流程挂钩的应用行业智能体、RAG知识库、代码助手、办公自动化。这类应用的价值不是生成一段漂亮的文本而是稳定地完成一个任务链。比如企业内部知识库问答不是把PDF丢给模型就完事而是要做文档切分、向量检索、答案生成、引用溯源每一步都可能出问题。又比如编程助手你把它接进IDE它要能读整个工程上下文而不是单文件补全。智能体则更进一步模型只负责拆解计划和调用工具真正干活的是那些API和函数。这类应用的难点不在模型选哪个而在工程图编排、状态管理、工具调用协议、权限控制、human-in-the-loop机制。做应用层的朋友要记住模型只是发动机你造的才是车。发动机再好底盘乱焊也开不稳。3. 模型选型不能只看榜单我用四个维度把项目需求翻译成模型参数每次我拿到“帮我推荐模型”的请求都会先问对方四个问题性能红线是什么预算多少部署环境在哪数据是否允许出域。这四件事对应四个维度能力、成本、部署、数据安全。把它们定清楚模型就是水到渠成的答案。3.1 四维评估框架能力、成本、部署、数据安全能力维度不要只看榜单总分要看你业务自己的测试集。榜单上的MMLU、HumanEval是通用指标但你做的是法律文书还是医疗对话只有自己拿真实数据测过才算数。成本维度要算总账闭源API的token单价只是最表面的一项还要算并发、调用量、限流、长尾数据、模型切换带来的改造成本。开源模型虽然按API单价是零但你需要算GPU机器成本、运维人力、微调GPU时间综合算下来不一定便宜。部署维度涉及硬件和网络你是能上A100集群还是只有一台消费级显卡机器能接受GPU推理还是只能CPU这直接决定你能用的参数档位。数据安全维度更关键涉密、个人隐私、商业秘密的数据能不能走第三方API如果答案是不能那就算闭源模型再强你也只能走开源权重本地化或者私有化部署。这四件事不是并列关系而是层层筛选。先圈出数据安全允许的模型范围再根据部署硬件缩小候选最后用成本和能力做最终对比。跳过任何一步选型结果都可能翻车。3.2 一个课堂式推演企业内部知识库问答的选型过程拿我最近做的一个案例来推演。需求是企业内部的规章制度问答中文为主数据不能出内网回答要求有引用来源用户并发不高预算有限。按四维评估能力上需要中文理解和检索增强不需要很硬的数学和代码能力成本上预算只够一台双卡消费级GPU部署上必须内网安全上数据禁出域。走闭源API直接出局剩下就是开源模型。中文场景我优先锁定了Qwen2.5-7B和DeepSeek-R1-7B两个候选。实测下来纯问答任务Qwen2.5-7B的输出更稳、格式更好控制涉及多步推理的少数问题DeepSeek-R1-7B思考得更深但响应时间也明显更长。最终选了Qwen2.5-7B配合RAG和一小批真实问答做LoRA微调。这个选择不是因为它“最强”而是因为它“最合适”。榜单上的7B第一名是谁在这个项目里根本不影响结果。3.3 榜单和基准测试的正确打开方式我看榜单有自己的习惯先看测试集的构成再看模型的发布时间和开源许可最后才看分数。很多榜单会把同一家族的不同版本混在一起参数档位不一样可比性很低。另外公开榜单普遍被“污染”过——模型厂商为了防止评测翻车会在训练语料里塞测试集数据分数高不代表真实场景好用。所以我的经验是把榜单当作初筛把你自己业务里抽出来的30到50条典型问题当作终审。拿同样的Prompt跑一次几家候选模型人工看输出质量、格式、幻觉率十分钟就能把排行榜拉下神坛。4. 一条完整落地链路从Qwen2.5-7B微调到本地部署的真实过程选型定了接下来就是落地。很多刚入门的朋友卡在“环境配置模型微调模型部署效果展示”这条链路上我这里分享一条我反复用过的路径全部基于我实际跑通的经验。下面每一步都值得仔细看尤其是那些容易让小白半路弃坑的细节。4.1 环境配置显存、驱动与依赖的细节第一步是环境配置。我会用conda建独立环境避免跟其他项目打架。这里有一段最基础的配置命令以CUDA环境为例conda create -n llm python3.10 -y conda activate llm pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers datasets accelerate peft bitsandbytes注意几个细节torch的CUDA版本必须和机器驱动匹配装错了会在推理时显示算力不足transformers、accelerate的版本不要追最新有时候新版接口改得快和老模型权重不兼容。显存不够的话加载模型时use_4bitTrue开量化7B模型的显存占用能压到6GB左右但这会牺牲一点效果。我自己的经验是微调和推理能留出1.5倍模型权重的显存余量最好不然OOM会把你逼疯。国内下载权重模型用ModelScope会比Hugging Face稳定得多命令行和Python SDK都有直接pull就行速度非常快。很多教程默认从海外平台下载到了国内这步就卡死其实换一下下载源能省掉大量无用功。4.2 数据准备与微调LoRA的取舍第二步是数据准备。行业微调不是把文档丢给模型让它背而是构造高质量的指令对。常用格式是JSON数组每个元素包含instruction、input、output三部分。举个例子[ { instruction: 根据公司差旅报销制度回答员工出差期间餐饮补贴标准。, input: , output: 根据最新制度一线城市每日餐饮补贴为120元出差不足半日按半日计算。 } ]数据量少就几百条也能做LoRA微调。我的建议是质量大于数量几十条精心撰写、覆盖边界case的样本比几千条从PDF里抽出来的流水账强得多。微调时选LoRA而不是全参微调因为全参微调对大模型来说既贵又容易灾难性遗忘。LoRA只训练附加的低秩矩阵用peft库实现rank一般取16或32。训练的时候盯着两个指标训练loss下降是否平稳验证集loss有没有回升。验证loss掉头向上就是在过拟合这时候要调整数据多样性或者加大一点正则。不要一看到训练集loss很低就高兴那可能只是背题了。4.3 推理部署API化与量化选择第三步是部署。微调完导出LoRA权重并合并回底模接下来要考虑怎么提供服务。个人电脑上跑体验Ollama或者LM Studio导入GGUF格式是最省事的要对外提供稳定的HTTP接口企业里我推荐vLLM吞吐量比原生transformers自带的generate高很多。下面是一个vLLM起服务的最小命令vllm serve Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 1 --max-model-len 8192如果你的硬件显存有限先把模型转成GGUF再量化成Q4_K_M7B模型大约4GB多一点普通显卡甚至纯CPU都能跑推理。但要注意量化越低幻觉越多知识类任务尤其明显。如果业务对答案准确性要求很高比如客服、法务建议至少用Q6或直接跑半精度原始权重。部署完不要急着宣布成功先用压测工具打一下并发再检查首token延迟。很多本地部署项目死在第一步是没并发设计用户一多就排队体验比闭源API还差。4.4 效果验证别只靠眼睛判断“变强了”最后是效果验证。我不用那种“看着不错”的评价方式而是建一个专门的评测集分成三个维度准确性、格式合规性、幻觉率。准确性看答案是否命中标准答案里的关键点格式合规性看输出是否严格遵循JSON或表格要求幻觉率看有没有把制度里没有的内容编造出来。每次跑完测试把输出导出成Excel人工逐条标注。然后再做一轮bad case归因区分是底模知识不足、RAG检索不到还是Prompt给的信息不够。这一步很枯燥但它决定了你的应用能不能从demo变成生产系统。提示效果验证这一步千万别省我见过太多项目因为省了评测直接上线最后被用户投诉幻觉层出不穷。哪怕只有30条用例也能拦住八成以上的低级问题。5. 这几个坑我踩过投毒、免费API与多模态选择的现实逻辑最后单独聊几个这个领域最容易踩的坑都是我在真实项目里交过学费的。有的坑网上很少被系统讲但遇到了真的很耽误事。5.1 开源模型的投毒测试别让第三方权重悄悄带偏你的业务开源既带来了便利也带来了供应链风险。大模型投毒不是危言耸听攻击者可能在预训练数据、LoRA权重或者社区下载的转换脚本里埋后门。具体表现可能是某个触发词一出现模型就输出恶意内容或者某个领域的答案被系统性篡改。我做过一次小范围的投毒测试在一批开源中文指令数据里混入了几百条带特定触发词的反向指令微调后的模型在正常场景几乎看不出来但碰到触发词几乎百分百被带偏。所以我的建议是凡是自己微调用的训练数据来源必须可追溯下载权重时优先用官方仓库并核对SHA256校验值对最终服务要做一次对抗性输入测试专门试那些不该由它答的内容别默认“开源的大概率没问题”。5.2 “免费大模型API”的算力账免费背后总有人买单“免费大模型API”在热搜上挂了很久我也试过不少。坦白讲作为学习和体验手段免费API非常好作为生产依赖我基本不敢碰。免费服务靠的是什么靠限流、降智、模型切换和数据回收来买单。我曾在一个Demo项目里用了某免费API上线第二天模型就被换成了低配版本回答质量肉眼可见地下降而文档里没有任何说明。如果你确实要用免费API做好心理准备它随时会变且无法保证SLA。生产项目里老老实实走付费API、开源自部署或者找厂商申请正式的免费额度合同。5.3 多模态与单模态别为了多模态而多模态多模态大模型现在热度很高但选型时要先搞清楚业务里是不是真的需要“多模态”。如果只是文档里有一些扫描图片可以用OCR加文本模型解决不一定上多模态。真正需要多模态的场景是图像和文字强关联比如照片理解、图纸问答、视频内容结构化。多模态大模型有一个现实问题推理成本比纯文本高一大截显存占用也大得多。我用AMD显卡比如RX 6750GRE跑过一些模型训练和推理CPU推理慢得让人崩溃GPU加速的兼容性还得看ROCm生态。所以如果不是刚需我建议先用单模态把流程跑通把多模态留作后续迭代。这样无论从模型选型还是从算力角度你的风险都会小很多。我自己的体会是大模型这行不存在一劳永逸的“最佳选择”。你今天选定的模型可能三个月后就出了更强的新版本你的业务场景也可能随着数据积累发生变化。与其天天纠结榜单和参数不如把精力放在两件事上一是建立一个属于你自己业务的评测集让每一次模型切换都有客观依据二是把应用架构做抽象让底层模型可以被替换而不是被焊死。做到这两点无论是模型维度还是应用维度你都能保持主动。最后再分享一个小技巧去读一读你选中模型的技术报告看它训练数据的中文占比、上下文长度和许可协议这三个信息能帮你避开大半的选型坑。