2026年9月初我趁着工作间隙把市面上主流的模型与典型应用重新梳理了一遍。大模型这个话题到今年其实已经不怎么“新”了真正难的是另一件事模型越来越多、能力越来越强但很多人面对“我到底该用哪个、怎么用、怎么才能落到自己的业务里”这个问题依然一头雾水。这篇文章我不打算做那种只罗列名字的简介而是从“模型维度”和“应用维度”两条线切入把国内外有代表性的模型、它们各自的适用场景、以及从API调用到本地部署、再到微调的完整落地路径整体讲透。文章里的信息点是面向2026/09/04这个时间节点整理的最新格局适合三类人看一是刚入行想建立全局视野的开发者二是正在做技术选型的产品/项目负责人三是自己折腾AI工具、想从“聊天玩家”进阶到“应用开发者”的爱好者。我尽量少废话多讲“为什么”把选型逻辑和踩坑经验一并放进来。1. 模型维度先看清大模型格局再动手1.1 国际主流模型闭源旗舰与开源主力并存国际阵营目前基本是“几家旗舰闭源 一个最强开源生态”的结构。闭源旗舰里绕不开的还是OpenAI的GPT系列、Google的Gemini系列、Anthropic的Claude系列这三家。GPT系列的强项是综合能力和插件生态最成熟很多第三方工具默认优先适配它Gemini系列最突出的优势在多模态视频、图片、音频这类非结构化输入的理解做得比较领先Claude系列则在超长上下文理解和“安全拒答策略”上下了很多功夫写代码、处理长文档时表现很稳定。开源阵营的标杆依然是Meta的Llama系列。Llama的价值不在于某个单项能力一定最强而在于它带起了整个开源社区的生态——从微调底座、量化工具有没有现成方案到各种外接应用能不能直接兼容几乎都默认拿Llama当基准。对开发者来说开源模型意味着你可以把权重下载到本地数据不出内网也可以深度改造成垂直领域模型这是闭源API永远给不了的自由度。2026年这个节点上有个明显变化各家常口“参数越大越强”的差距正在收窄。旗舰与开源梯队的能力差距已经不像前几年那么悬殊尤其是日常问答、文本总结、代码补全这些高频任务上开源模型的得分已经非常接近闭源旗舰。反而是工程化能力、部署成本和生态适配度越来越成为选型时真正拉开差距的变量。1.2 国内大模型阵营从通用大模型到垂直模型的梯队国内模型这几年的进步速度非常快。通用底座方面阿里通义千问的开源策略很值得一提Qwen系列从7B到72B甚至更大尺寸都有开源权重而且配套了完整的训练、微调、部署工具链很多团队做私有化部署的第一步就是从Qwen开始的。DeepSeek则是把性价比做到了极致采用MoE架构后在推理成本上压得非常低API定价让中小团队也能把模型接入真实业务。其他几个方向上也有不少“偏科生”值得关注月之暗面的Kimi在超长文本理解上有明显优势适合处理整本书、超大合同这类场景百度的文心一言在中文学科知识和搜索结合方面积累深智谱AI的GLM系列是高校派系的代表开源和技术报告都比较透明挺适合做学术研究和二次开发。腾讯混元、字节豆包、讯飞星火也都在各自生态里持续迭代选哪家更像是选“生态”而不是单纯选“模型”。垂直模型是2026年一个明显的增长点。医疗、法律、金融、工业制造、代码生成这些领域都出现了专门训练或深度微调的专业模型。这类模型通常参数不大但在特定任务上的效果能超过通用旗舰模型。原因不复杂——通用模型学的是“所有领域的基础”垂直模型则把所有“精力”都放在了一个行业的知识结构和表达习惯上就像全科医生和专科医生的区别。对于业务型项目选一个垂直模型往往比硬调通用大模型效率高得多。1.3 模型的分类逻辑架构、参数、模态与开放程度不了解模型分类逻辑的话在做选型时很容易被各种名词绕晕。我习惯从四个维度拆解一个模型架构、参数规模、模态能力、开放程度。先说架构。现在主流分为Dense稠密和MoE混合专家两类。Dense模型每处理一个请求所有参数都会参与计算效果稳定但成本高MoE模型内部有多个“专家”模块每次推理只激活其中一部分这样可以在参数总量很大的情况下压低单次推理成本。DeepSeek走的就是这条路这也是它能把API价格打下来的核心原因。然后是参数规模这个数字决定了模型的知识容量和推理能力上限。行业里大致有个参考1B-3B适合端侧和简单任务7B-14B是本地部署的甜点区间32B-72B能在多数任务上接近旗舰水平100B以上基本是云上推理和闭源API的天下。参数不是越大越好关键在于你的硬件条件和任务复杂度能不能匹配上。模态能力上今年“多模态”几乎成了新模型标配但程度差异很大。有些是“能看图说话”有些是“视频理解、音频生成都能做”还有一些是“同时输出图文”。如果项目里需要处理图片、视频那么单模态文本模型就不用看了。最后是开放程度也就是权重是否公开。闭源模型省心但受制于人开源模型灵活但需要自己维护。我的判断标准很简单数据敏感度高还是低、定制需求大还是小、团队有没有部署能力。2. 应用维度大模型是怎么接进真实业务的2.1 从对话产品到生产力工具典型应用形态盘点大模型最直观的应用是对话助手类产品ChatGPT、Claude、Kimi、豆包这些都是。它们的核心形态是“人机对话”——你问它答多轮交互背后是模型对自然语言的理解和生成能力。这个形态看起来简单但应用边界已经被拓展得很宽写周报、润色文案、整理会议纪要、辅助编程、做知识科普基本上文本类的脑力工作都能沾上边。走到2026年纯粹的“聊天框”已经不再是唯一主流形态。很多厂商把模型能力做进了具体的工作流里。比如代码编辑器里的AI插件不再只是“你问它答”而是能读取当前项目代码、理解报错信息、直接跨文件补全和重构这背后的技术叫做“上下文工程”办公软件里的大模型能基于表格数据直接生成分析报告设计工具里能用自然语言描述生成可编辑的工程文件。这些变化意味着大模型正在从“问答工具”变成“生产力管道”的一部分谁先把模型嵌进工作流谁就真正吃到了红利。2.2 API调用从模型到服务的最后一公里对开发者来说模型能力是通过API应用程序接口来消费的。调用模型API的本质就是“发一个HTTP请求传入文本拿回生成结果”。现在各家API的设计已经高度标准化了大多是OpenAI兼容格式也就是统一使用POST /v1/chat/completions这个路径传model、messages、max_tokens这些参数。这个标准化非常重要——意味着你可以用一种代码风格同时对接不同厂商的模型。下面是一个最基础的对话补全调用示例以Python为例from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.example.com/v1 # 换成你用的服务商地址 ) response client.chat.completions.create( modelsome-model-name, messages[ {role: system, content: 你是一个专业的文案助手。}, {role: user, content: 帮我把这句话改得更口语化请尽快处理该事项。} ], temperature0.7, max_tokens1024 ) print(response.choices[0].message.content)这段代码的关键点在于messages参数它模拟了一段多轮对话system角色负责设定人设和行为边界user角色是用户输入assistant角色则是模型回复。开发应用时要把历史对话按顺序组装进messages模型才能理解上下文。temperature控制随机性和“创意度”直接相关写文案可以调到0.8以上做分类抽取这类确定性任务建议降到0.2以下。所谓“免费大模型API”现在主要有两个来源一是各家云平台给新用户送的试用额度二是开源模型服务商提供的低成本甚至零成本入口。但免费额度一般有并发和速率限制生产环境还是要按需付费。我的经验是选API前先看三样东西——上下文窗口长度、输入输出单价、限流策略前两个影响体验和成本后一个影响架构设计。2.3 智能体与应用开发路线图与工具选型如果说API调用是“让模型单次回答问题”那么智能体Agent应用是“让模型自己完成一个目标”。比如“帮我查一下本周的销售数据找出异常原因并生成一份报告发送到群里”这不是一次问答能搞定的而是需要模型自主规划步骤、调用工具、观察结果、再决定下一步。2026年Agent已经从概念演示走向了生产环境应用方向包括自动化客服、数据分析助理、代码修复机器人、私域运营助手等。做Agent应用绕不开两个核心概念RAG检索增强生成和工具调用。RAG解决的核心问题是“模型不知道你的私域知识”——它训练时没见过你公司的内部文档。RAG的思路是先把文档切块、向量化存入向量数据库用户提问时先把最相关的片段检索出来拼进提示词再让模型回答。这样回答有依据还能在文档更新后即时生效不用重新训练模型。工具调用Function Calling则是给模型“装上手和脚”——模型本身不能查询数据库、不能调外部API但你可以定义一组工具函数模型在需要时会输出一个结构化指令来请求调用这些函数你的程序执行完把结果回传给模型模型再基于结果继续回答。这个机制是Agent实现“自主行动”的底层基础。工具选型上目前比较主流的有LangChain/LlamaIndex这类代码框架适合喜欢自己掌控流程的开发者Dify/Coze这类低代码平台适合产品和运营快速搭建验证原型LangGraph适合需要复杂状态流转的Agent编排。我的建议是先别急着上框架用原生代码把“用户输入→检索→拼装提示词→调用模型→输出”这条链路跑通再根据痛点引入框架。框架能加速开发也会掩盖底层细节出了问题排查起来很痛苦。2.4 VS Code Claude Code 插件接入本地大模型热词里有条“VS Code Claude Code 插件接入本地大模型Ollama”这个组合值得单独展开。Claude Code插件本身设计上是面向云端Claude模型的但代码编辑器里做AI编程并不一定需要闭源服务。本地部署了Ollama之后可以通过配置兼容接口的方式让VS Code的这类插件把请求转发到本地模型上。具体原理是插件通过简单配置设定模型服务地址不再指向默认云端而是改成http://localhost:11434/v1同时把模型名指定为你本地Ollama拉取的模型ID。这样你在编辑器里写代码、让AI补全、让它解释报错时所有推理都在本机GPU或CPU上执行代码不经过第三方服务器隐私性更好也没有订阅费用。代价是效果和响应速度取决于你的硬件。个人体验是8B-14B的模型做代码补全和常见代码问答已经堪用但处理复杂的跨文件重构时和云端旗舰模型还有差距。如果是公司项目涉密代码强烈建议走这种本地方案如果只是个人学习开通云端模型会员体验会更好。3. 本地部署与微调实操从“会用”到“会改”3.1 本地部署大模型硬件预估与选型思路本地部署大模型的动力通常有三类数据隐私要求、长期调用成本、离线可用性。但在动手之前一定要先搞清楚硬件约束。大模型推理的本质是“在显存里完成矩阵运算”所以决定性因素是显存大小而不是“CPU够不够好”。有一个粗算公式模型显存需求约等于“参数数量 × 每个参数所需字节数”。以7B模型为例全精度FP16下约需要14GB显存7B × 2字节而用INT4量化后大约需要3.5-4.5GB。再叠加推理时的中间激活值和KV Cache占用实际建议7B量化模型至少准备6GB显存14B模型至少12GB32B-70B模型基本要24GB以上到48GB级别。没有独立显卡的机器也可以靠统一内存架构的芯片或者纯CPU加内存硬跑速度会慢不少但小模型聊聊天、跑跑简单任务是可行的。选型上目前本地部署最主流的两条路线一条是用Ollama这类开箱即用的工具适合个人和快速验证另一条是用vLLM、SGLang这类高性能推理框架适合生产环境追求吞吐量。个人学习阶段从Ollama开始就够了它的模型仓库里可以直接拉取Qwen、Llama等多个开源模型不需要自己处理权重转换一条命令就能跑起来。3.2 基于Ollama的完整部署流程Ollama是我最推荐新手用起的本地部署工具它屏蔽了很多底层细节让模型在本地跑起来只需要三步安装、拉取模型、发起请求。第一步是安装。在macOS和Windows下直接下载官方安装包即可在Linux服务器上官方提供了一键安装脚本。装完以后先在终端执行ollama serve确认服务启动默认监听在127.0.0.1:11434。第二步是拉取模型。打开终端输入ollama pull qwen2.5:7b这条命令会从模型仓库下载Qwen2.5的7B版本到本地。如果不需要量化版也可以指定参数版本比如官方仓库里常见的qwen2.5:7b-instruct-q4_K_M这种标签就表示4bit量化指令版显存占用更小。下载完成后执行ollama run qwen2.5:7b就能在终端里直接对话了。第三步才是部署的关键——把模型作为服务暴露给其他程序调用。Ollama天然兼容OpenAI接口格式默认地址就是http://localhost:11434。用Python调用本地模型时只需要把上一节示例里的base_url改成http://localhost:11434/v1model改成你拉取的模型名即可from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama # 本地服务不校验key但参数不能为空 ) response client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 用一句话解释什么是检索增强生成}] ) print(response.choices[0].message.content)这里有个细节虽然Ollama不校验API Key但OpenAI客户端库强制要求这个字段非空所以随便填一个占位符即可。如果要在局域网内的其他机器上调用需要设置环境变量OLLAMA_HOST0.0.0.0这样模型服务就能被同网段的机器访问到了。3.3 大模型微调数据集、算力与流程要点微调和大模型部署完全是两个量级的事。部署是“拿来就用”微调是“按你的需求改造模型”。最常见的误区是以为微调是在“教模型新知识”其实微调的核心是“改变模型的输出风格、格式遵循能力、以及在特定任务上的行为模式”。例如让模型学会用你公司规定的工单格式回复让模型从冗长解释改为“结论依据建议”三段式让模型在客服场景中不输出未经确认的价格信息。这些都属于对齐Alignment层面的改变知识更新的问题应该交给RAG解决。技术路线上不要一上来就做全参数微调。行业里最通用的是LoRA低秩适配和QLoRALoRA只训练原模型内部一小部分增量参数显存占用小训练速度快QLoRA更进一步在4bit量化基座上做LoRA让消费级显卡也能微调7B-14B的模型。一个很关键的参数是秩rank它控制着新增参数的维度。经验值是简单任务用8复杂任务用16到32太大容易过拟合太小可能学不到位。完整流程大概是准备数据集 → 格式化指令数据 → 加载基座模型和LoRA配置 → 训练 → 合并权重 → 部署评测。数据集格式上目前最通用的是对话模板——每条数据包含“指令输入可选 期望输出”。以指令微调为例一种常见格式是{ instruction: 请根据以下内容生成一条客服回复, input: 用户说我买的东西十天了还没发货想退货。, output: 非常抱歉给您带来不便这边立即为您查询物流状态如需退货会在1小时内为您办理。 }数据量上做风格微调一般几千条就够做垂直任务最好有上万条重点是质量而不是数量——50条高质量的“问题-标准答案”比500条随随便便整理的劣质数据更有用。工具方面新人建议直接用LLaMA-Factory它把数据加载、训练参数配置、LoRA微调、模型合并都图形界面化了极大降低了上手门槛。训练完成后一定要先在验证集上对比微调前后的输出别只看loss下降就觉得成功模型“背会”训练集但不会泛化的情况很常见。4. 常见问题与避坑指南4.1 部署阶段的典型问题与排查思路本地部署最常遇到的是显存或内存不够。现象是启动模型时直接卡死或者报“out of memory”相关错误。排查思路先确认用了什么量化精度7B模型用Q4量化还爆显存的话大概率是同时启动了多个模型服务或者有别的程序占用了显存。可以先用ollama ps查看当前加载了哪些模型用nvidia-smi看显存占用必要时关掉不需要的服务。下载模型速度慢是另一个高频痛点。大模型动辄几个GB到几十个GB网络不稳定时经常中断。Ollama支持断点续传中断后重试即可但对很多使用者来说挂代理又会遇到各种不可控问题。更省心的做法是如果运维条件允许在下载环境稳定的时间段执行拉取命令比如凌晨或者使用国内镜像站加速。还有一种思路是换用HuggingFace的镜像下载权重后再手动导入Ollama——这种方式的细节比较多新手阶段还是建议优先解决网络因素。还有一个很多人忽略的问题Ollama默认会一直驻留后台服务并预加载部分显存。我见过有同事本地部署完模型后打开其他大型应用就明显变卡排查半天才发现是Ollama在后台吃显存。解决办法是使用后及时执行ollama stop 模型名或直接退出服务给其他应用腾出资源。4.2 应用开发阶段的踩坑实录做应用开发时我踩过最深的坑是模型不按格式输出。你以为让模型“输出JSON”它就会乖乖输出实际上它在json前面加了一堆废话或者在json后面补了说明结果你的json.loads()直接报错。解决思路有三个一是强制使用各家API提供的结构化输出或JSON Mode功能二是在提示词里给出“只输出JSON不要解释”的明确指令三是在解析失败时做清洗比如用正则提取第一个{到最后一个}之间的内容。正规项目里这三种方案要组合使用不能只靠提示词。上下文超长是另一个容易出现的问题。模型的上下文窗口是有限的你的对话历史不可能无限增长。超过窗口时老的消息会被截断模型就会“失忆”——明明前面聊过的事情后面突然不记得了。更麻烦的是上下文越长推理成本和延迟就越高。生产环境下要么自己做历史消息的自动裁剪/摘要要么用RAG把最重要的信息检索出来而不是塞全部历史。就目前来看与其迷信“超长上下文”参数不如把“信息筛选”这个工程问题解决好。最后是成本失控。大模型按token计费一句话几十个字看起来便宜但做Agent应用时每次任务可能要调用模型几十次累积起来成本很夸张。我有次跑一个自动化测试任务一个晚上烧掉了几十块钱就是因为在循环里重复传入了大量历史记录。控制成本的核心手段一是控制输入的长度二是用便宜的模型做简单任务只有复杂任务才调用旗舰模型三是为任务设置最大调用次数上限避免Agent在错误路径上反复循环扣除费用。4.3 学习路线与避坑建议结合标题里的“大模型学习路线”这个热词我给新人一条清晰的自学路径。第一阶段是“用”把国内外主流的对话产品都用一遍积累对模型能力边界的体感什么任务靠谱、什么任务胡说八道。第二阶段是“调”学会用API写程序调用模型至少能做“输入一段文字返回一段结果”的完整闭环。第三阶段是“部署”用Ollama把开源模型在本地跑起来理解模型、显存、量化、推理速度之间的关系。第四阶段是“改”尝试微调一个小模型真正理解数据对模型行为的影响。最后再根据兴趣切入RAG、Agent、多模态这类方向。资料获取方面有几个渠道比漫无目的刷视频高效得多。GitHub上有上海交大的“动手学大模型”项目既有理论又有代码实践适合系统性学习HuggingFace的官方文档和模型卡片是了解模型细节的第一手资料至于社区里的付费课程我不做评价但建议先免费路线走一遍你自然能分辨哪些课是真的有增量信息哪些只是在念官方文档。给想在企业里落地大模型项目的读者一句实在话先别追求“全栈智能”选一个高频、低风险、数据条件好的单点场景先跑通哪怕是“文档问答机器人”这种看起来不够酷的场景。一套完整跑通之后再横向复制比一上来就规划一个全自动智能体系统稳健得多。做项目这么多年我见过太多因为初期规划过大、半年都没上线而被砍掉的项目而真正活下来的都是先把一个小场景做深做透的团队。5. 最后一点经验如果要我用三句话总结这几年和大模型打交道的心得第一句是“模型能力是杠杆场景才是支点”——你光有好模型没有具体场景杠杆就无处着力第二句是“先跑通再优化”不要在一开始就纠结模型选得够不够好、显存是否够大先用一个小模型把链路打通后面再换大的成本低得多第三句是“把模型当成一个不太完美的同事来合作”它会犯错、会跑题、会理解错意图你得学会给它写清晰的brief、划清边界、做好校验环节。大模型的落地从来不是一次prompt就能搞定的魔法而是一套围绕模型搭建的工程体系。希望这篇文章能帮你少走几步弯路在这个模型和应用都快速迭代的时代找到自己的节奏。 
长河君 · 2026/9/9 15:51:00 · 阅读 1.2k 大模型选型与落地实践：从API调用到微调部署
2026年9月初我趁着工作间隙把市面上主流的模型与典型应用重新梳理了一遍。大模型这个话题到今年其实已经不怎么“新”了真正难的是另一件事模型越来越多、能力越来越强但很多人面对“我到底该用哪个、怎么用、怎么才能落到自己的业务里”这个问题依然一头雾水。这篇文章我不打算做那种只罗列名字的简介而是从“模型维度”和“应用维度”两条线切入把国内外有代表性的模型、它们各自的适用场景、以及从API调用到本地部署、再到微调的完整落地路径整体讲透。文章里的信息点是面向2026/09/04这个时间节点整理的最新格局适合三类人看一是刚入行想建立全局视野的开发者二是正在做技术选型的产品/项目负责人三是自己折腾AI工具、想从“聊天玩家”进阶到“应用开发者”的爱好者。我尽量少废话多讲“为什么”把选型逻辑和踩坑经验一并放进来。1. 模型维度先看清大模型格局再动手1.1 国际主流模型闭源旗舰与开源主力并存国际阵营目前基本是“几家旗舰闭源 一个最强开源生态”的结构。闭源旗舰里绕不开的还是OpenAI的GPT系列、Google的Gemini系列、Anthropic的Claude系列这三家。GPT系列的强项是综合能力和插件生态最成熟很多第三方工具默认优先适配它Gemini系列最突出的优势在多模态视频、图片、音频这类非结构化输入的理解做得比较领先Claude系列则在超长上下文理解和“安全拒答策略”上下了很多功夫写代码、处理长文档时表现很稳定。开源阵营的标杆依然是Meta的Llama系列。Llama的价值不在于某个单项能力一定最强而在于它带起了整个开源社区的生态——从微调底座、量化工具有没有现成方案到各种外接应用能不能直接兼容几乎都默认拿Llama当基准。对开发者来说开源模型意味着你可以把权重下载到本地数据不出内网也可以深度改造成垂直领域模型这是闭源API永远给不了的自由度。2026年这个节点上有个明显变化各家常口“参数越大越强”的差距正在收窄。旗舰与开源梯队的能力差距已经不像前几年那么悬殊尤其是日常问答、文本总结、代码补全这些高频任务上开源模型的得分已经非常接近闭源旗舰。反而是工程化能力、部署成本和生态适配度越来越成为选型时真正拉开差距的变量。1.2 国内大模型阵营从通用大模型到垂直模型的梯队国内模型这几年的进步速度非常快。通用底座方面阿里通义千问的开源策略很值得一提Qwen系列从7B到72B甚至更大尺寸都有开源权重而且配套了完整的训练、微调、部署工具链很多团队做私有化部署的第一步就是从Qwen开始的。DeepSeek则是把性价比做到了极致采用MoE架构后在推理成本上压得非常低API定价让中小团队也能把模型接入真实业务。其他几个方向上也有不少“偏科生”值得关注月之暗面的Kimi在超长文本理解上有明显优势适合处理整本书、超大合同这类场景百度的文心一言在中文学科知识和搜索结合方面积累深智谱AI的GLM系列是高校派系的代表开源和技术报告都比较透明挺适合做学术研究和二次开发。腾讯混元、字节豆包、讯飞星火也都在各自生态里持续迭代选哪家更像是选“生态”而不是单纯选“模型”。垂直模型是2026年一个明显的增长点。医疗、法律、金融、工业制造、代码生成这些领域都出现了专门训练或深度微调的专业模型。这类模型通常参数不大但在特定任务上的效果能超过通用旗舰模型。原因不复杂——通用模型学的是“所有领域的基础”垂直模型则把所有“精力”都放在了一个行业的知识结构和表达习惯上就像全科医生和专科医生的区别。对于业务型项目选一个垂直模型往往比硬调通用大模型效率高得多。1.3 模型的分类逻辑架构、参数、模态与开放程度不了解模型分类逻辑的话在做选型时很容易被各种名词绕晕。我习惯从四个维度拆解一个模型架构、参数规模、模态能力、开放程度。先说架构。现在主流分为Dense稠密和MoE混合专家两类。Dense模型每处理一个请求所有参数都会参与计算效果稳定但成本高MoE模型内部有多个“专家”模块每次推理只激活其中一部分这样可以在参数总量很大的情况下压低单次推理成本。DeepSeek走的就是这条路这也是它能把API价格打下来的核心原因。然后是参数规模这个数字决定了模型的知识容量和推理能力上限。行业里大致有个参考1B-3B适合端侧和简单任务7B-14B是本地部署的甜点区间32B-72B能在多数任务上接近旗舰水平100B以上基本是云上推理和闭源API的天下。参数不是越大越好关键在于你的硬件条件和任务复杂度能不能匹配上。模态能力上今年“多模态”几乎成了新模型标配但程度差异很大。有些是“能看图说话”有些是“视频理解、音频生成都能做”还有一些是“同时输出图文”。如果项目里需要处理图片、视频那么单模态文本模型就不用看了。最后是开放程度也就是权重是否公开。闭源模型省心但受制于人开源模型灵活但需要自己维护。我的判断标准很简单数据敏感度高还是低、定制需求大还是小、团队有没有部署能力。2. 应用维度大模型是怎么接进真实业务的2.1 从对话产品到生产力工具典型应用形态盘点大模型最直观的应用是对话助手类产品ChatGPT、Claude、Kimi、豆包这些都是。它们的核心形态是“人机对话”——你问它答多轮交互背后是模型对自然语言的理解和生成能力。这个形态看起来简单但应用边界已经被拓展得很宽写周报、润色文案、整理会议纪要、辅助编程、做知识科普基本上文本类的脑力工作都能沾上边。走到2026年纯粹的“聊天框”已经不再是唯一主流形态。很多厂商把模型能力做进了具体的工作流里。比如代码编辑器里的AI插件不再只是“你问它答”而是能读取当前项目代码、理解报错信息、直接跨文件补全和重构这背后的技术叫做“上下文工程”办公软件里的大模型能基于表格数据直接生成分析报告设计工具里能用自然语言描述生成可编辑的工程文件。这些变化意味着大模型正在从“问答工具”变成“生产力管道”的一部分谁先把模型嵌进工作流谁就真正吃到了红利。2.2 API调用从模型到服务的最后一公里对开发者来说模型能力是通过API应用程序接口来消费的。调用模型API的本质就是“发一个HTTP请求传入文本拿回生成结果”。现在各家API的设计已经高度标准化了大多是OpenAI兼容格式也就是统一使用POST /v1/chat/completions这个路径传model、messages、max_tokens这些参数。这个标准化非常重要——意味着你可以用一种代码风格同时对接不同厂商的模型。下面是一个最基础的对话补全调用示例以Python为例from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.example.com/v1 # 换成你用的服务商地址 ) response client.chat.completions.create( modelsome-model-name, messages[ {role: system, content: 你是一个专业的文案助手。}, {role: user, content: 帮我把这句话改得更口语化请尽快处理该事项。} ], temperature0.7, max_tokens1024 ) print(response.choices[0].message.content)这段代码的关键点在于messages参数它模拟了一段多轮对话system角色负责设定人设和行为边界user角色是用户输入assistant角色则是模型回复。开发应用时要把历史对话按顺序组装进messages模型才能理解上下文。temperature控制随机性和“创意度”直接相关写文案可以调到0.8以上做分类抽取这类确定性任务建议降到0.2以下。所谓“免费大模型API”现在主要有两个来源一是各家云平台给新用户送的试用额度二是开源模型服务商提供的低成本甚至零成本入口。但免费额度一般有并发和速率限制生产环境还是要按需付费。我的经验是选API前先看三样东西——上下文窗口长度、输入输出单价、限流策略前两个影响体验和成本后一个影响架构设计。2.3 智能体与应用开发路线图与工具选型如果说API调用是“让模型单次回答问题”那么智能体Agent应用是“让模型自己完成一个目标”。比如“帮我查一下本周的销售数据找出异常原因并生成一份报告发送到群里”这不是一次问答能搞定的而是需要模型自主规划步骤、调用工具、观察结果、再决定下一步。2026年Agent已经从概念演示走向了生产环境应用方向包括自动化客服、数据分析助理、代码修复机器人、私域运营助手等。做Agent应用绕不开两个核心概念RAG检索增强生成和工具调用。RAG解决的核心问题是“模型不知道你的私域知识”——它训练时没见过你公司的内部文档。RAG的思路是先把文档切块、向量化存入向量数据库用户提问时先把最相关的片段检索出来拼进提示词再让模型回答。这样回答有依据还能在文档更新后即时生效不用重新训练模型。工具调用Function Calling则是给模型“装上手和脚”——模型本身不能查询数据库、不能调外部API但你可以定义一组工具函数模型在需要时会输出一个结构化指令来请求调用这些函数你的程序执行完把结果回传给模型模型再基于结果继续回答。这个机制是Agent实现“自主行动”的底层基础。工具选型上目前比较主流的有LangChain/LlamaIndex这类代码框架适合喜欢自己掌控流程的开发者Dify/Coze这类低代码平台适合产品和运营快速搭建验证原型LangGraph适合需要复杂状态流转的Agent编排。我的建议是先别急着上框架用原生代码把“用户输入→检索→拼装提示词→调用模型→输出”这条链路跑通再根据痛点引入框架。框架能加速开发也会掩盖底层细节出了问题排查起来很痛苦。2.4 VS Code Claude Code 插件接入本地大模型热词里有条“VS Code Claude Code 插件接入本地大模型Ollama”这个组合值得单独展开。Claude Code插件本身设计上是面向云端Claude模型的但代码编辑器里做AI编程并不一定需要闭源服务。本地部署了Ollama之后可以通过配置兼容接口的方式让VS Code的这类插件把请求转发到本地模型上。具体原理是插件通过简单配置设定模型服务地址不再指向默认云端而是改成http://localhost:11434/v1同时把模型名指定为你本地Ollama拉取的模型ID。这样你在编辑器里写代码、让AI补全、让它解释报错时所有推理都在本机GPU或CPU上执行代码不经过第三方服务器隐私性更好也没有订阅费用。代价是效果和响应速度取决于你的硬件。个人体验是8B-14B的模型做代码补全和常见代码问答已经堪用但处理复杂的跨文件重构时和云端旗舰模型还有差距。如果是公司项目涉密代码强烈建议走这种本地方案如果只是个人学习开通云端模型会员体验会更好。3. 本地部署与微调实操从“会用”到“会改”3.1 本地部署大模型硬件预估与选型思路本地部署大模型的动力通常有三类数据隐私要求、长期调用成本、离线可用性。但在动手之前一定要先搞清楚硬件约束。大模型推理的本质是“在显存里完成矩阵运算”所以决定性因素是显存大小而不是“CPU够不够好”。有一个粗算公式模型显存需求约等于“参数数量 × 每个参数所需字节数”。以7B模型为例全精度FP16下约需要14GB显存7B × 2字节而用INT4量化后大约需要3.5-4.5GB。再叠加推理时的中间激活值和KV Cache占用实际建议7B量化模型至少准备6GB显存14B模型至少12GB32B-70B模型基本要24GB以上到48GB级别。没有独立显卡的机器也可以靠统一内存架构的芯片或者纯CPU加内存硬跑速度会慢不少但小模型聊聊天、跑跑简单任务是可行的。选型上目前本地部署最主流的两条路线一条是用Ollama这类开箱即用的工具适合个人和快速验证另一条是用vLLM、SGLang这类高性能推理框架适合生产环境追求吞吐量。个人学习阶段从Ollama开始就够了它的模型仓库里可以直接拉取Qwen、Llama等多个开源模型不需要自己处理权重转换一条命令就能跑起来。3.2 基于Ollama的完整部署流程Ollama是我最推荐新手用起的本地部署工具它屏蔽了很多底层细节让模型在本地跑起来只需要三步安装、拉取模型、发起请求。第一步是安装。在macOS和Windows下直接下载官方安装包即可在Linux服务器上官方提供了一键安装脚本。装完以后先在终端执行ollama serve确认服务启动默认监听在127.0.0.1:11434。第二步是拉取模型。打开终端输入ollama pull qwen2.5:7b这条命令会从模型仓库下载Qwen2.5的7B版本到本地。如果不需要量化版也可以指定参数版本比如官方仓库里常见的qwen2.5:7b-instruct-q4_K_M这种标签就表示4bit量化指令版显存占用更小。下载完成后执行ollama run qwen2.5:7b就能在终端里直接对话了。第三步才是部署的关键——把模型作为服务暴露给其他程序调用。Ollama天然兼容OpenAI接口格式默认地址就是http://localhost:11434。用Python调用本地模型时只需要把上一节示例里的base_url改成http://localhost:11434/v1model改成你拉取的模型名即可from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama # 本地服务不校验key但参数不能为空 ) response client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 用一句话解释什么是检索增强生成}] ) print(response.choices[0].message.content)这里有个细节虽然Ollama不校验API Key但OpenAI客户端库强制要求这个字段非空所以随便填一个占位符即可。如果要在局域网内的其他机器上调用需要设置环境变量OLLAMA_HOST0.0.0.0这样模型服务就能被同网段的机器访问到了。3.3 大模型微调数据集、算力与流程要点微调和大模型部署完全是两个量级的事。部署是“拿来就用”微调是“按你的需求改造模型”。最常见的误区是以为微调是在“教模型新知识”其实微调的核心是“改变模型的输出风格、格式遵循能力、以及在特定任务上的行为模式”。例如让模型学会用你公司规定的工单格式回复让模型从冗长解释改为“结论依据建议”三段式让模型在客服场景中不输出未经确认的价格信息。这些都属于对齐Alignment层面的改变知识更新的问题应该交给RAG解决。技术路线上不要一上来就做全参数微调。行业里最通用的是LoRA低秩适配和QLoRALoRA只训练原模型内部一小部分增量参数显存占用小训练速度快QLoRA更进一步在4bit量化基座上做LoRA让消费级显卡也能微调7B-14B的模型。一个很关键的参数是秩rank它控制着新增参数的维度。经验值是简单任务用8复杂任务用16到32太大容易过拟合太小可能学不到位。完整流程大概是准备数据集 → 格式化指令数据 → 加载基座模型和LoRA配置 → 训练 → 合并权重 → 部署评测。数据集格式上目前最通用的是对话模板——每条数据包含“指令输入可选 期望输出”。以指令微调为例一种常见格式是{ instruction: 请根据以下内容生成一条客服回复, input: 用户说我买的东西十天了还没发货想退货。, output: 非常抱歉给您带来不便这边立即为您查询物流状态如需退货会在1小时内为您办理。 }数据量上做风格微调一般几千条就够做垂直任务最好有上万条重点是质量而不是数量——50条高质量的“问题-标准答案”比500条随随便便整理的劣质数据更有用。工具方面新人建议直接用LLaMA-Factory它把数据加载、训练参数配置、LoRA微调、模型合并都图形界面化了极大降低了上手门槛。训练完成后一定要先在验证集上对比微调前后的输出别只看loss下降就觉得成功模型“背会”训练集但不会泛化的情况很常见。4. 常见问题与避坑指南4.1 部署阶段的典型问题与排查思路本地部署最常遇到的是显存或内存不够。现象是启动模型时直接卡死或者报“out of memory”相关错误。排查思路先确认用了什么量化精度7B模型用Q4量化还爆显存的话大概率是同时启动了多个模型服务或者有别的程序占用了显存。可以先用ollama ps查看当前加载了哪些模型用nvidia-smi看显存占用必要时关掉不需要的服务。下载模型速度慢是另一个高频痛点。大模型动辄几个GB到几十个GB网络不稳定时经常中断。Ollama支持断点续传中断后重试即可但对很多使用者来说挂代理又会遇到各种不可控问题。更省心的做法是如果运维条件允许在下载环境稳定的时间段执行拉取命令比如凌晨或者使用国内镜像站加速。还有一种思路是换用HuggingFace的镜像下载权重后再手动导入Ollama——这种方式的细节比较多新手阶段还是建议优先解决网络因素。还有一个很多人忽略的问题Ollama默认会一直驻留后台服务并预加载部分显存。我见过有同事本地部署完模型后打开其他大型应用就明显变卡排查半天才发现是Ollama在后台吃显存。解决办法是使用后及时执行ollama stop 模型名或直接退出服务给其他应用腾出资源。4.2 应用开发阶段的踩坑实录做应用开发时我踩过最深的坑是模型不按格式输出。你以为让模型“输出JSON”它就会乖乖输出实际上它在json前面加了一堆废话或者在json后面补了说明结果你的json.loads()直接报错。解决思路有三个一是强制使用各家API提供的结构化输出或JSON Mode功能二是在提示词里给出“只输出JSON不要解释”的明确指令三是在解析失败时做清洗比如用正则提取第一个{到最后一个}之间的内容。正规项目里这三种方案要组合使用不能只靠提示词。上下文超长是另一个容易出现的问题。模型的上下文窗口是有限的你的对话历史不可能无限增长。超过窗口时老的消息会被截断模型就会“失忆”——明明前面聊过的事情后面突然不记得了。更麻烦的是上下文越长推理成本和延迟就越高。生产环境下要么自己做历史消息的自动裁剪/摘要要么用RAG把最重要的信息检索出来而不是塞全部历史。就目前来看与其迷信“超长上下文”参数不如把“信息筛选”这个工程问题解决好。最后是成本失控。大模型按token计费一句话几十个字看起来便宜但做Agent应用时每次任务可能要调用模型几十次累积起来成本很夸张。我有次跑一个自动化测试任务一个晚上烧掉了几十块钱就是因为在循环里重复传入了大量历史记录。控制成本的核心手段一是控制输入的长度二是用便宜的模型做简单任务只有复杂任务才调用旗舰模型三是为任务设置最大调用次数上限避免Agent在错误路径上反复循环扣除费用。4.3 学习路线与避坑建议结合标题里的“大模型学习路线”这个热词我给新人一条清晰的自学路径。第一阶段是“用”把国内外主流的对话产品都用一遍积累对模型能力边界的体感什么任务靠谱、什么任务胡说八道。第二阶段是“调”学会用API写程序调用模型至少能做“输入一段文字返回一段结果”的完整闭环。第三阶段是“部署”用Ollama把开源模型在本地跑起来理解模型、显存、量化、推理速度之间的关系。第四阶段是“改”尝试微调一个小模型真正理解数据对模型行为的影响。最后再根据兴趣切入RAG、Agent、多模态这类方向。资料获取方面有几个渠道比漫无目的刷视频高效得多。GitHub上有上海交大的“动手学大模型”项目既有理论又有代码实践适合系统性学习HuggingFace的官方文档和模型卡片是了解模型细节的第一手资料至于社区里的付费课程我不做评价但建议先免费路线走一遍你自然能分辨哪些课是真的有增量信息哪些只是在念官方文档。给想在企业里落地大模型项目的读者一句实在话先别追求“全栈智能”选一个高频、低风险、数据条件好的单点场景先跑通哪怕是“文档问答机器人”这种看起来不够酷的场景。一套完整跑通之后再横向复制比一上来就规划一个全自动智能体系统稳健得多。做项目这么多年我见过太多因为初期规划过大、半年都没上线而被砍掉的项目而真正活下来的都是先把一个小场景做深做透的团队。5. 最后一点经验如果要我用三句话总结这几年和大模型打交道的心得第一句是“模型能力是杠杆场景才是支点”——你光有好模型没有具体场景杠杆就无处着力第二句是“先跑通再优化”不要在一开始就纠结模型选得够不够好、显存是否够大先用一个小模型把链路打通后面再换大的成本低得多第三句是“把模型当成一个不太完美的同事来合作”它会犯错、会跑题、会理解错意图你得学会给它写清晰的brief、划清边界、做好校验环节。大模型的落地从来不是一次prompt就能搞定的魔法而是一套围绕模型搭建的工程体系。希望这篇文章能帮你少走几步弯路在这个模型和应用都快速迭代的时代找到自己的节奏。