今年下半年我一直在做 AI 应用的选型梳理发现一个很明显的现状大模型已经从“少数团队研究的算法”变成了“几乎所有软件产品都在接入的基础设施”而真正拉开差距的早已不是谁家的模型跑分高一点而是谁更懂“模型和应用怎么组合落地”。这份整理以模型/应用两个维度展开把国内外主流大模型、典型应用场景、本地部署与微调的关键参数都过了一遍适合正在做 AI 应用开发、准备接入大模型 API、或者打算本地部署开源模型的同学直接参考。1. 先看清全景模型是引擎应用是车轮1.1 “模型应用”为什么是现在的行业主线大模型不是独立的科研项目它的价值最终体现在应用里。过去两年大家聊得最多的还是“哪个模型聪明”到了这个阶段话题重心明显转向了“模型接进来之后怎么用”。原因很简单模型能力已经越过了基本可用的门槛逻辑推理、长文档理解、多模态识别、代码生成这些能力都相对成熟产品团队现在考虑的不再是“能不能做”而是“用哪家模型、以什么方式接入、成本怎么控制”。这条主线下有三个绕不开的关键词一是推理成本二是工具调用三是场景数据。大模型 API 的价格每年都在快速下降但应用做大了以后推理成本仍然是核心指标工具调用能力决定了 Agent 能不能真正操作软件、查数据库、调接口场景数据则是微调价值的来源通用模型在垂直领域往往差一口气这口气需要自己的数据去补。1.2 国内外大模型产业版图速览先把版本画出来。国际阵营里OpenAI 的 GPT 系列依然是综合能力的标杆GPT 的推理模型在数学、代码、复杂任务拆解上有明显优势Anthropic 的 Claude 系列在长上下文和代码场景口碑很好Claude 的 Artifacts 功能等于把“对话生成应用”变成了一个实打实的前端工具Google 的 Gemini 主打多模态原生能力从文本到图片、视频、音频的跨模态理解一直是强项Meta 的 Llama 系列是开源阵营的地基很多本地部署和微调项目都建立在 Llama 之上xAI 的 Grok 以实时数据和幽默风格出圈也在快速补齐技术能力Mistral 的模型则以高效轻量著称适合做欧洲市场的合规部署。国内阵营更是热闹。DeepSeek 是这两年开源社区绕不开的名字它在推理能力和成本控制上做得非常激进一度让“国产模型也能打”成为共识阿里的 Qwen通义千问系列是覆盖面最全的开源体系从 0.5B 到 72B 甚至更大参数都有对应版本Qwen2.5-7B 是最常被拿来微调的入门选择字节的豆包依托流量生态在 C 端应用渗透率很高百度的文心系列结合搜索和云生态政企项目里出现频率高智谱的 GLM 系列在中文理解与 Agent 场景上积累深很多智能体框架的默认模型都支持 GLM月之暗面的 Kimi 以长文本处理见长学术论文、合同审查这些场景很受欢迎MiniMax 在多模态和语音交互上发力腾讯混元和讯飞星火也都在各自生态里推进。这些模型各有各的主场。用表格看更直观模型/系列代表版本方向突出能力常见落地方式OpenAI GPTGPT-4o / 推理模型通用智能、代码、推理API 调用、Copilot 类产品Anthropic ClaudeClaude 3.5/3.7 系列长上下文、编程、ArtifactsAPI 调用、编程助手Google GeminiGemini 1.5/2.x多模态原生理解API 调用、Google 生态Meta LlamaLlama 3.x / 4开源生态、可微调本地部署、私有化DeepSeekDeepSeek-V3 / R1推理、性价比开源部署、API阿里 QwenQwen2.5 / 3中文强、全尺寸开源本地部署、微调字节豆包豆包大模型C 端应用、语音云端 API、App 集成智谱 GLMGLM-4 系列Agent、中文理解API、私有化部署看完这张表你会发现选模型本质上是在选“约束条件下的最优解”预算、场景、数据是否可出域、需要的模态类型这些约束比单点跑分重要得多。2. 应用维度拆解大模型到底落在哪里2.1 从通用助手到生产力工具的演进大模型最先把应用价值释放给了所有人典型的载体就是 AI 助手。ChatGPT、Claude、Gemini、豆包、Kimi、文小言这些产品看似都是“对话框”其实已经分成两条路线一条是通用对话助手什么都能聊但深度有限另一条是任务型工作台围绕写作、编程、分析、翻译来做深做透。以编程场景为例GitHub Copilot 和 Cursor 这类工具已经把大模型嵌入了开发者的日常流程自动补全、跨文件重构、根据 issue 描述直接生成 PR这些能力背后依赖的都是强大的代码模型。办公场景里Notion AI、飞书智能伙伴、WPS AI 这类产品把文档生成、会议纪要、数据表格分析做成了按钮级操作。内容创作领域Midjourney 虽然还是独立应用但很多团队已经通过大模型的多模态能力把“文生图、图生视频、配音、剪辑”串进了一条流水线。“大模型应用”这个概念不再是一个单独的 App而是一种能力。就像当年的云服务一样先有物理服务器然后有云主机最后大家不再关心机器在哪只关心服务能不能弹性扩展。现在的 AI 能力正在经历同样的过程。2.2 行业场景车联网、企业知识库与 Agent行业应用的落地比通用助手更有想象空间。车联网里TBox 加导航定位的应用场景就是把大模型接进车载系统语音助手结合实时路况、车辆位置、用户习惯不再只是执行“打开导航”这种指令而是能主动推荐路线、解释故障码、规划充电路线。这种场景和一般聊天最大的区别是模型必须同时处理上下文当前导航状态、驾驶时长、传感器数据车速、电量和 API 调用地图服务对实时性和稳定性要求很高。企业知识库是另一块硬骨头。很多公司想通过“AI 问答机器人”来替代传统的客服和文档检索但直接用通用大模型会发现它经常胡说。于是 RAG检索增强生成成了标配先把企业文档切片、向量化存入数据库用户提问时先匹配相关段落再把检索结果交给大模型生成答案。这种方式的好处是模型不需要记住企业机密答案都基于检索内容生成减低了幻觉风险也方便随时更新知识库。Agent 则是更高级的形态。一个真正的 Agent 至少要具备任务拆解、工具调用、结果验证三个能力收到“帮我整理本月销售数据并生成周报”后它会自己决定先查数据库、再写 Python 脚本做聚合、最后调用文档接口生成报告。这类应用看起来已经远远超出传统聊天机器人它本质上是一个会使用数字工具的初级员工。2.3 新手入行AI 应用开发的学习路线经常有人问我 AI 应用开发到底要学什么、从哪开始。我给的路线一般是这样第一步是掌握提示词工程。别嫌简单提示词决定了模型输出的下限。你至少要知道如何写清晰的指令、如何给模型示例、如何在多轮对话中控制上下文。很多产品效果不好不是模型不行而是提示词太笼统。第二步是熟悉至少一种大模型 API。以 OpenAI 或国内厂商的 API 为例学习消息格式、参数调优、流式输出、Token 计算。这个阶段不需要懂数学但要知道如何用代码和模型对话。第三步是了解 RAG 和向量数据库。会装一个 Embedding 模型把文档向量化再用检索逻辑把结果喂给大模型。这里涉及文本切分、相似度计算、召回质量评估是工程里最常踩坑的部分。第四步才是模型微调和部署。微调不是所有项目都需要但当你需要模型学会特定的风格、术语或业务逻辑时微调就绕不过去。再往后是部署涉及 GPU、显存、量化、推理框架属于工程能力可以循序渐进。这套路线走完你基本能独立做一个 AI 应用的原型了。后面要补的还有 Agent 框架、多模态接口、模型评估体系但骨架已经有了。3. 工程实践微调、本地部署与推理成本3.1 该微调还是该 RAG先做决策很多团队上来就说“要微调模型”但微调不是万能药。我的判断标准很简单如果问题出在知识不够用 RAG如果问题出在行为不对再考虑微调。什么叫知识不够比如公司产品的售后手册模型没见过你问它“这个报错码怎么解决”它只能瞎编。这种情况喂文档、做检索就能解决。什么叫行为不对比如客服机器人总喜欢长篇大论解释原理但公司要的是简洁、带歉意的回答风格。再比如法律文书要求严格按照特定格式模型总是跑偏。这些不是知识问题是风格、格式、结构化输出的问题微调才能真正纠正。还有一种情况是工具调用能力不足。很多开源小参数模型在“调用函数”上表现不稳参数填错、格式不对。针对这类能力做微调效果比提示词工程明显得多。我在实际项目里经常是先上提示词再上 RAG等数据攒到一定程度之后再用微调解决最后那几个顽固问题。3.2 本地部署配置参考以 Qwen2.5-7B 为例本地部署最大的好处是数据不出内网、没有按 Token 计费的压力、可以随意调参。目前开源模型里Qwen2.5-7B 是一个性价比很高的选择很多行业微调项目都拿它当基线。7B 模型是指参数量 70 亿。如果不做量化FP16 精度下大概需要 14GB 显存用于加载权重加上推理时的中间缓存实际建议至少有 16GB 显存。如果有 24GB 显存比如 RTX 3090/4090就可以比较舒服地跑 7B 模型甚至可以尝试 14B 模型的量化版本。热词里有人提到 RX 6750 GRE 训练大模型A 卡在部分推理框架如 Ollama 里也能用但生态比 N 卡麻烦建议优先 N 卡。推理框架推荐按使用习惯选Ollama 适合快速体验和本地 API 调用LM Studio 适合小白可视化vLLM 适合高并发生产环境llama.cpp 适合 CPU 和边缘设备。如果只是个人电脑跑着玩Ollama 一行命令就能起服务支持 OpenAI 兼容接口写个 Python 脚本就能调。量化方案值得多说一句。常见的量化位数是 INT8、INT4数字越小模型体积越小、显存占用越低但精度损失越大。以 7B 模型为例FP16 约 14GBINT8 约 7GBINT4 约 4GB。实验的时候可以用 INT4 快速跑通流程但生产级微调评估最好还是用高精度版本因为量化后的模型在复杂推理上确实会有可感知的下降。3.3 微调实战从数据准备到效果评估微调的核心不是调参而是数据。我给微调新手的第一条建议永远是先花 80% 的时间清洗和构造数据。用 Qwen2.5-7B 微调行业模型一般流程是这样的第一步准备数据。至少几百条高质量样本格式用对话式或指令式。对话式的典型结构是 system 设定角色user 放用户输入assistant 放期望输出。数据里的输出必须是人工确认过的标准答案一个文本里不要混入太多噪声。清洗时特别要注意去掉模型本来就能答对的简单问题那只会让微调变得无意义。第二步设定训练参数。LoRA低秩适配是目前微调的主流方案它只训练一小部分参数显存占用低。一般设置 4 到 8 的 LoRA rank学习率 2e-4 到 5e-4批次大小根据显存调整轮次通常 2 到 4 轮。如果你是在单卡 24GB 显存上跑7B 模型配合 LoRA 是可行的全参微调则建议至少 48GB 以上的显存或使用多卡。第三步训练与评估。训练完不要只看 loss更不要只看训练集上的表现一定要留一份评测集。评测集不能和训练集同源最好是从真实场景里抽样。评估维度包括答案正确率、格式规范性、是否出现幻觉、对敏感问题的拒答表现等。我记得有个项目需要模型生成工单摘要刚开始用提示词限制格式模型偶尔会偷偷多写两句微调之后这个问题就基本消失了。类似的“行为纠正”是微调最擅长的事情。4. 常见问题排查与选型避坑指南4.1 模型选型时先问自己五个问题面对这么多模型很多团队反而不知道怎么选。我给自己的决策框架是五个问题一是数据能不能出域。数据涉及商业机密、用户隐私就不能用公有云 API只能本地部署开源模型比如 Qwen、Llama、DeepSeek 等。二是延迟和成本要求。实时对话场景对响应延迟很敏感要选推理速度快的模型离线批量处理则更关注单次成本。三是需要什么模态。纯文本场景可选空间很大如果需要图片理解、语音输入、视频分析就必须考虑 Gemini、GPT-4o、Qwen-VL 这类多模态模型。四是中文能力要求。虽然现在主流模型的中文能力都不弱但涉及中文古诗词、成语、行业黑话时国内模型整体表现更稳定。五是后续可维护性。闭源模型版本更新由厂商控制可能突然改版开源模型可以固定版本但要自己负责升级和 bug 修复。4.2 应用集成时的典型“暗坑”接入大模型 API 时最容易被低估的是成本。开发阶段调用量小感觉不到上线之后如果每个请求都带一大堆历史上下文Token 消耗会翻好几倍。这里有一个习惯养成及时清理无用上下文把系统提示词精简到够用为止嵌入长文本时优先走 RAG 而不是全部塞进提示词。还有一个常见的坑是“模型热切换”。有些团队在代码里把模型名写死一旦厂商下线旧版本或者发布新版本服务直接报错。建议统一封装模型网关层模型名称、API Key、超时重试都做成配置切换模型时只改配置文件不动业务代码。本地部署场景里如果出现“回答特别慢”或者“CPU 跑满”多半是没加载 GPU 加速或者推理框架的线程设置不对。用 Ollama 时可以通过ollama ps看模型是否成功加载到显卡还可以在环境变量里指定 GPU 层数把部分层强制放到显存速度提升非常明显。4.3 2026 年更值得关注的几个方向如果眼光放远一点下面几个方向在 2026 年明显在加速第一个是多模态更加通用文本、图片、音频、视频之间的边界在被打破以后的应用大概率默认支持多模态第二个是端侧小模型手机、车机、智能穿戴设备上跑得动的模型越来越强离线可用会成为卖点第三个是 Agent 走向工程化单纯“会聊天”已经不是卖点能调用工具、跨系统完成任务才是第四个是推理成本继续下探开源模型和闭源模型的差距在缩小本地部署的门槛也在降。还有一点容易被忽视模型评估会越来越像软件测试。以后每个 AI 应用项目里都应该有一条“评测流水线”把核心场景用例固化下来每次更换模型、修改提示词、调整参数后自动回归测试一遍。我在实际项目里发现只要坚持做这套评估模型选型和迭代方向就不会跑偏。最后分享一点个人体会不管是做大模型应用还是做微调最重要的都不是追新模型而是把场景想清楚。模型的新闻每天都有版本号更新快得令人焦虑但用户真正关心的永远是“这个应用帮我解决了什么问题”。先回答好这个问题再回头选模型你会发现选项一下子就清晰了。