1. 先盘一盘全球大模型的阵营格局最近大半年每隔几天就会冒出一个新模型的新闻社区里讨论得热火朝天。很多人问我同一个问题现在到底有哪些大模型值得关注说实话这个问题放在2023年还能用一页PPT列完放到今天就真的需要一张全景地图了——不只是知道名字还得知道它们各自擅长干什么、能不能拿来改、跑起来要什么条件。我不想把这篇写成一份干巴巴的名单。模型名称只是索引真正的价值在于理清背后的逻辑哪些是闭源商业模型哪些是开源可私有化的它们各自的生态和成本结构是什么落到实际项目里该怎么选。这才是“全景”两个字真正值钱的地方。先给一张我看下来觉得还算清晰的主流模型概览表后面再逐层拆模型阵营代表模型开源情况上下文能力特点闭源商业 APIGPT 系列、Claude 系列、Gemini不开源几十万到百万 token 级别综合能力强生态成熟按量付费海外开源Llama 系列、Mistral、DeepSeek开源权重几十万 token 级别社区生态丰富可本地部署国产开源Qwen通义千问、GLM智谱、Kimi月之暗面开源权重几十万到百万 token 级别中文表现好商业授权友好垂直/多模态开源InternVL、Qwen-VL、Stable Diffusion 家族开源权重以视觉编码器为主处理图像、视频适合多模态场景1.1 闭源与开源的差异化定位闭源模型的核心优势是“开箱即用”。你用 API 接入不用管部署、不用管显存、不用管推理优化把请求发过去就能拿到结果。GPT、Claude、Gemini 这三家是目前能力最靠前的一档尤其适合做 agent 这种需要复杂推理和工具调用的任务因为它们指令遵循能力强、输出稳定。缺点也很明显数据要出域、费用是持续性的、而且你没法改模型本身遇到业务专有场景只能靠提示工程和 RAG 弥补。开源模型这几年追得特别快。Llama 系列是海外开源生态的标杆Meta 每次发新版都能带动一批微调模型和工具链更新。Mistral 做了很多工程优化模型结构简洁、性能不错。国产这边 Qwen 和 GLM 的中文能力都很扎实而且商用授权清晰很多国内企业在做私有化部署时首选它们。开源真正的价值不在于“免费”而在于可控权重在自己手里数据不出域想微调就微调想加什么能力就加什么能力。1.2 选型时最容易忽略的三个维度看完这张表很多人会直接奔着“谁的综合分高”去选。真到了项目里我更看重另外三个维度。第一是生态成熟度。一个模型能力再强如果周边工具链不完善落地成本会高到让你怀疑人生。所谓生态指的是有没有完善的部署方案比如 ollama 一键跑、vLLM 高并发推理、有没有大量社区微调产物可以参考、有没有成熟的评测数据支撑、文档是否清晰。目前这套东西做得最完整的还是 Llama 和 Qwen 家族。第二是商业授权条款。开源不等于随便用。有的模型权重开放但商用需要申请有的对月活用户数有限制。如果你是在企业内部用建议先找法务把授权条款过一遍。国产模型在商用授权上普遍做得更省心这也是它们在企业市场快速铺开的原因之一。第三是推理成本与硬件的匹配度。同一个模型7B 和 70B 的部署难度天差地别。7B 量化后一张 24G 显存的消费级显卡就能跑70B 至少需要两张 A100 或集群。很多人选型时只盯着“能力最强”忽略了公司到底有没有对应的算力和运维能力结果模型下回来了两周都起不来。务实一点的做法是先问自己能提供什么硬件再决定看哪一档模型。还有一个小众但很现实的场景值得单独提一下——工业检测、服装检测这类视觉任务。很多人以为这类场景也得上大模型实际并不是。工业视觉的核心是稳定、实时、可回退传统方案是 YOLO 这类垂直小模型加规则后处理云端还是单机取决于产线的实时性要求和数据敏感度。大模型在这类场景里的角色更多是“质检结果的自然语言汇总”或者“缺陷样本的标注辅助”而不是主力检测器。选型的时候对这种边界心里要有数别一上来就往大模型上套。1.3 一个快速选型决策框架如果你现在要启动一个新项目又还没有明确方向可以参考下面这个简化流程先确认约束数据能不能出域预算是一次性硬件投入还是持续按量付费有没有专职的 AI 工程师做运维再看场景类型开放域问答、复杂推理、agent 优先闭源 API内部知识库问答优先开源模型 RAG高并发结构化分类优先中小模型微调图像相关优先多模态模型或垂直视觉模型。横向试跑至少选 2 个候选用真实业务数据各跑一遍评估集别只看官方 benchmark。这一步后面我会展开讲。等这个框架跑顺了你会发现“全景图”并不是让你记住所有模型而是让你明白该往哪个方向画重点。2. 本地部署与私有化落地从 ollama 到企业级链路全景图看完了接下来要面对一个现实问题模型选好了怎么让它跑起来我见过太多人卡在这一步。云端的成熟产品你直接按文档调 API 就行但开源模型的部署链路长、变数多不同模型对显存的要求也完全不同。2.1 为什么要本地跑隐私、成本与控制权本地部署这事的动机得先捋清楚。最常见的理由是隐私合规客户数据、财务报表、源代码这些内容如果发到第三方 API风险很高很多企业明文规定不允许。跑在本地的话训练数据和推理请求全程不出内网这是合规上最扎实的做法。第二个理由是控制权。用 API 时模型的版本升级、能力变更、上下文长度调整都是平台说了算。前两天还能跑得好好的场景平台更新一版后可能就变了。本地部署把模型的版本固化下来了行为是确定的出问题可以回滚这对生产环境非常重要。第三个理由才轮到成本。很多人觉得 API 按量付费太贵本地部署一劳永逸。这个账其实要仔细算一张能跑 7B 模型的消费级显卡要一万多块一张能跑 70B 的 A100 论万起步还有电费、服务器散热、运维人力。API 按量付费的优势是不用养硬件零调用零成本。所以我的建议是如果数据允许出域先用 API 验证业务跑通之后再评估是否值得自建一套私有化环境。2.2 小规模部署实操ollama 的一键路径如果你只是想本地跑起来一个小模型试试效果ollama 是目前最省事的方案。它把模型的下载、量化、启动、API 暴露都封装好了基本做到开箱即用。操作流程很简单安装 ollama然后拉取模型镜像比如ollama pull qwen2.5:7b直接运行ollama run qwen2.5:7b就能进入交互式对话如果想要一个可以被外部服务调用的接口ollama 默认会在 11434 端口起一个 OpenAI 兼容的 API直接用常规的 HTTP 请求就能访问有个容易被忽略的点是上下文长度的配置。ollama 默认的上下文窗口相对保守很多人在跑长文本任务时发现输出突然变傻往往是触发了上下文截断。可以通过OLLAMA_CONTEXT_LENGTH环境变量把上下文调大同时要留意显存是否放得下。这是一个典型的“换了配置之后一切都不一样了”的环节。我个人的经验是ollama 适合做功能验证和开发调试但不太适合当成高并发的生产推理服务。它的推理引擎在并发场景下的吞吐表现一般而且缺少细粒度的监控和弹性伸缩能力。生产要上还是得交给专门的推理框架。2.3 企业级私有化vLLM 加向量库加 Dify 的拼图企业场景里真正落地最多的组合是“一个高吞吐推理框架 一个模型编排平台 一个向量数据库”来解决私有知识库问答这个问题。推理框架我比较推荐 vLLM。它把连续批处理和 PagedAttention 这些优化做到位了同样的硬件能比普通推理引擎多扛好几倍的并发请求而且暴露的也是 OpenAI 兼容接口迁移成本很低。Dify 这类编排平台的定位是“把模型能力接到具体业务场景的胶水层”。你在 Dify 里配置一个模型供应商填入本地推理服务的 Base URL 和 API Key然后设置提示词、挂载知识库就能把一个带 RAG 的问答应用跑起来。Dify 的界面化操作让业务人员也能参与调试这在一个小团队里很值钱。完整的技术链路大概是文档加载用解析器把 PDF、Word、Markdown 等各类文件内容提取出来做章节切分。向量化通过 embedding 模型把切分后的文本块转成向量写入向量数据库。检索用户提问时先做向量相似度检索召回相关的文本片段。增强生成把召回片段拼进提示词连同用户问题一起发给大模型由它整合成回答。这个链路里最容易翻车的环节其实是文档解析和切分策略。不同格式的文档解析出来的效果差异很大切分太粗会导致上下文塞入太多无关内容切分太碎又会丢失语义完整性。这块没有统一的银弹只能拿真实文档反复调。另外要提醒一点向量检索召回的内容如果相关度不高大模型再强也白搭它会一本正经地基于错误材料编造答案。所以私有化问答上线前一定要对“检索质量”做专项评测不能只看模型答得是否流利。3. 微调实战知道什么时候不该动参数更重要部署解决的是“让模型跑起来”的问题微调解决的是“让模型按我的规矩做事”的问题。但微调这个话题被严重神化了很多团队一提业务需求就说“咱们微调一个模型”结果调完发现还不如直接用提示词。我先把结论放前面微调的正确时机远比你想象的少。3.1 微调到底在解决什么问题大语言模型的所谓“知识”在预训练阶段就已经固化了。你喂再多的业务资料给它微调它也没法把新事实稳定学进去——这话会让很多人失望但事实就是如此。微调擅长改变的不是“知识”而是“行为模式”输出格式要求模型始终输出严格 JSON、特定标签格式或者某种企业报表风格。任务范式例如把客服对话改写成工单、从对话中抽取结构化字段这种任务天然适合微调成固定范式。工具调用让模型准确使用你定义的工具特别是私有系统内部工具。风格迁移让回答更符合品牌语气或特定人群的表达习惯。反过来看如果你的需求是“让模型知道我们公司的产品信息”那正确答案是 RAG不是微调。RAG 的路线是“数据更新就换索引”成本极低效果还可控。微调的路线是把知识混入权重数据更新后你得再训一遍而且会有“学到的旧数据被新数据冲掉”的灾难性遗忘风险。3.2 LoRA 的原理和一次完整的微调流程现在工程上做微调绝大多数走的是 LoRA 路线。它是在冻结全部原始参数的前提下在关键矩阵旁插入低秩可训练的小矩阵。训练时只更新这几个小矩阵整体参数量通常只有原模型的 1% 左右显存开销大幅下降消费级显卡就能训得动 7B 模型。实际部署时把 LoRA 权重合并回原始模型推理时几乎感知不到额外开销。一次完整的 LoRA 微调流程大致分四步第一步是数据准备。整理成 JSONL 格式每条样本包含 system、user、assistant 三段内容assistant 段是你期望的标准输出。这一步的关键是质量远大于数量。几百条精心清洗过的高质量样本效果通常好过几千条网上抓来的脏数据。数据要去重、去矛盾、去错别字很多模型微调后变傻不是训练参数错了而是数据里全是噪声。第二步是基座选型。先从一个能跑通的最小规模模型开始比如 7B 或 14B把整个链路走通。别一上来就选 70B微调任务的数据规模和迭代速度完全不在一个量级。第三步是训练参数设置。SFT 阶段一般用 2 到 3 个 epoch 就够多了容易过拟合学习率通常设在 1e-5 到 2e-5 这个范围LoRA 的 rank 可以先用 16 或 32 起步。训练过程中盯着验证集的 loss 和实际输出样例别只盯训练集 loss 往下降。第四步是权重合并与部署。训练完把 LoRA 权重合并进原模型权重然后再走一遍评估和上线流程。很多微调框架都提供了合并脚本这一步技术上不难但容易忘——忘了合并就部署模型行为不会有任何变化。3.3 微调之外的两条路RAG 和提示工程做任何微调决定之前都值得先把另外两条路想清楚。RAG 前面讲过了适合“外部知识”类需求。它的优势是知识可以随时更新答案是直接可引用的原文片段出错时你可以追溯到来源。缺点是多一跳就多一个故障点检索不准回答就不准。提示工程是成本最低的手段。通过精心设计的 few-shot 示例、系统提示词、思维链引导能解决大量需求场景。很多人低估这个方案是因为不理解提示词本身也是一种“运行时训练数据”——你给的例子足够好模型自然能模仿出想要的行为。与其急着动权重不如先花一周时间把提示词打磨到极致。我的建议是走这样一条演进路径提示工程 → RAG → 微调。每往上走一步都是在确认前一步确实到达了天花板。绝大多数业务场景走到第二步就足够了。4. 多模态、上下文长度与 Agent能力边界怎么看前面聊的主要是纯文本理解和生成但这两年模型的能力边界被三大方向同时撑开了多模态输入、超长上下文、Agent 能力。这三个维度直接决定了你的业务能不能做、做到什么程度。4.1 多模态模型的真实场景所谓多模态核心是模型能直接处理图片、音频、视频与文本混合的输入。视觉大模型可以直接“看”一张产品照片并描述细节、识别图表内容、提取表格数字。这在文档审核、商品描述生成、图片搜索这些场景里非常实用。选型时要区分两类一类是通用多模态大模型比如 Qwen-VL、InternVL它们用起来就像“把一张图扔给一个文本模型”适合开放域描述、图文问答另一类是专用视觉模型比如工业质检、OCR 识别这类它们速度快、精度高但只能干一类活。很多项目把这两类搞混了指望用通用大模型做产线质检速度和稳定性都达不到要求最后还得换回专用模型。4.2 上下文长度不是越长越好上下文长度是这两年厂商们最爱宣传的数字百万 token 的标题一个比一个响。但真实的情况是模型能“容纳”百万 token 的输入不代表它能把百万 token 的信息都用好。注意力机制天然对早年内容和中间位置的信息记忆更弱长文本测下来经常出现“给了几万字材料但模型只盯着最后面的内容回答”的情况。工程上应对这个问题有一个很实在的组合拳检索优先输入给模型之前先通过向量检索把真正相关的片段筛出来而不是把整份文档一股脑塞进去。分层摘要对超长文档先做分段摘要再把摘要拼起来整体理解效果往往比直接丢长上下文更好。结构化注入把关键信息整理成表格、层级列表等形式让模型更容易定位重点。上下文长是“上限”不是“默认状态”。把这块想明白你才不会在模型宣传的百万 token 面前盲目买单。4.3 Agent 与工具调用从 demo 到可用AI Agent 现在是最热的方向之一。本质上 Agent 做的事情是让模型自主规划任务、调用工具、观察结果、调整方案直到完成目标。背后的核心技术是 function calling也就是让模型输出结构化的 JSON 来表明“我要调用哪个工具、传什么参数”然后系统层去执行工具并返回结果。真正落地一个 Agent 系统时我踩过的坑大致有三类第一是工具定义太粗糙。工具的 name、description、参数 schema 写得不清不楚模型就会反复猜。工具描述要像写给新同事的操作手册一样明确举几个使用示例往往事半功倍。第二是任务拆解太复杂。很多 Agent 框架一上来就做多 Agent 协作——一个主控 Agent 分配任务多个子 Agent 并行执行再汇总。设计上很帅跑起来很容易失控。子 Agent 之间共享上下文靠消息队列还是共享记忆某个子 Agent 挂了你重试还是降级这些问题不解决demo 就永远只是 demo。第三是缺少人工确认兜底。Agent 自主执行高风险操作比如发消息、改数据时必须设计审批节点。我见过不少团队把 Agent 的“自主性”当成卖点结果一次误操作就让人对整套系统失去信任。从 demo 到可用差的往往不是模型能力而是控制边界。多 Agent 协作目前真正跑通的场景还比较有限。我的建议是先从“单 Agent 稳定工具链”起步把链路做扎实再逐步探索更复杂的编排结构。与其搭一个华丽的舞台不如先演好一出小戏。5. 免费 API、编程辅助与日常工具链全景图看完、部署链路摸清、微调和 Agent 的思路也理清了最后聊点跟日常效率直接相关的东西。毕竟不是每个人都需要从零部署一个模型集群很多人只是想把手头的活儿干得更快更好。5.1 免费 API 与“零成本”的算力策略所谓免费的模型 API通常各家大模型开放平台都会提供体验额度注册之后送一定数量的 tokens够你做功能验证和 demo 开发。这对启动期很有价值你不需要先买显卡、再部署模型就能用真实模型把业务流程验证一遍。但“免费”这事要算总账。API 免费额度用完后的单价、并发限制、数据是否用于训练这些条款都会影响后续决策。我见过有些项目在产品验证阶段依赖免费 API上线后才发现条款不允许商用或者单量上来后费用完全不可控。正确的姿势是用免费 API 验证 Prompt 方案和评估集跑通之后马上评估是否切换本地部署或付费商用。另一个把成本打下来的思路是“模型分级调度”——简单任务用免费额度或小模型复杂任务才上调大模型。很多平台都有模型路由的配置按任务类型分发请求综合成本能降不少。5.2 AI 编程的正确打开方式程序员群体可能是 AI 工具渗透最深的人群了几乎每个人都装了一两个 AI 编程插件。编辑器里那行灰色代码建议不稀奇现在大家关心的是怎么让 AI 真正扛活。我的使用经验可以浓缩成三条第一条给 AI 上下文比给它指令更重要。直接让它“写个登录功能”得到的是模板代码但如果你把项目的技术栈、目录结构、既有代码风格、数据表结构都喂给它生成结果的可用性能提高一大截。所以我会花时间维护一份项目说明文档这本身就是给 AI 的“系统提示词”。第二条先让它写测试再写实现。让 AI 先生成单元测试和边界用例然后再补实现代码比直接要“完整功能代码”的效果好很多。因为测试规格把行为边界钉死了AI 生成代码时会更收敛质量也更容易人工验收。第三条把 AI 当“审查者”而不是“代写者”。遇到一个复杂函数让我思路先捋清楚再把代码丢给 AI 让它找出边界问题、性能隐患往往会得到很有价值的建议。这个用法比完全依赖 AI 写代码可靠得多因为你自己心智里先有一版方案AI 的意见是叠加在上面的出来的东西是“你的思路”加“AI 的补充”而不是两种思路在打架。6. 落地的坑与排查链路技术方案写起来都很顺真正让项目翻车的往往是那些不起眼的细节。这个部分我把自己实际部署和集成大模型过程中踩过的一些坑按照“部署环境、输出质量、系统集成”三个层面列出来每条都附排查思路。这些不是照搬文档就能避开的每一条都对应着一次真实的加班。6.1 部署层面显存、并发与版本不匹配显存爆掉是本地部署的头号问题。常见表现是进程启动后直接 OOM或者跑一小段对话就崩溃。排查思路很简单先确认模型量化版的实际显存占用。同一型号的模型float16 全精度和 4bit 量化能差两三倍的内存占用再确认上下文窗口长度上下文越长KV Cache 占的显存越多。如果你的显存卡在边界上调小上下文往往比换小模型更立竿见影。并发上不去也是高频问题。本地起个模型调试没问题一接真实流量就排队。这多半是推理引擎的批处理能力不足。普通的 ollama 在这种场景下确实吃亏换成 vLLM 这类支持 Continuous Batching 的框架并发吞吐会有很直观的提升。如果硬件就这么多另一个方向是给服务加队列缓冲和超时降级逻辑至少别让单点故障打穿整条链路。依赖版本不一致是最隐蔽的一个坑。大模型的代码库迭代极快昨天还能用的代码今天换了个依赖版本就起不来了。排查时先看错误栈里是哪个库出的问题再到对应项目的 Release 页面看版本变更记录实在不行就固定一套经过验证的版本组合没有充分理由不升级。6.2 输出质量层面幻觉与截断大模型一本正经地胡说八道是所有场景里最容易翻车的问题。业务方很信任模型结果它生成了一份完全编造的报表这个锅只能你来背。排查幻觉我觉得最实用的两条路是一是强迫模型引用来源要求每个结论后面都要带上检索到的原文片段编号没有来源支撑的内容明说不确定二是把生成流程切成两步——第一步检索材料第二步基于材料生成而不是让模型一步到位。两步走的输出质量稳定很多。截断问题前面提过容易和幻觉搞混。排查方法是如果模型回答突然变得很空洞或者结尾不完整去查一下传进去的上下文长度有没有触发模型的上限。很多模型被截断时不是报错而是默默丢掉中间内容输出自然就“失忆”了。6.3 系统集成层面连接与权限问题Dify 这类编排平台接入本地模型模型服务时最常见的是连不上或鉴权失败。排查顺序是先 curl 一下模型的 HTTP 接口确认服务本身是通的再看 Base URL 有没有写对注意对外暴露的端口和绑定地址别监听在 localhost 上让外部平台访问不到最后看 API Key 等鉴权配置是否匹配。特别留意一些推理框架的鉴权是可选配置的两边配置对不上就会给出很误导的错误信息。还有一类是跨域问题。前端页面直接调用模型服务的 API浏览器会拦截跨域请求。这类问题最好在架构上解决——增加一层后端代理由后端统一请求模型服务同时把鉴权和告警也收口在这一层前端只跟自己的后端打交道。6.4 安全合规的底线操作最后说安全合规这不是选修课是必须做的事。接入任何大模型之前至少要确认三件事输入内容是否包含敏感数据如果有就要先走脱敏流程输出内容是否有合规要求高风险场景要加一层内容审核过滤数据是否允许离开内网不允许的话就果断放弃外部 API走本地部署路线。这三条建议在项目启动的第一天就写进方案里而不是等流程跑通了再补课。结尾的几句真话做了这么多大模型的选型、部署、微调、排障我最大的体会是这个领域的技术迭代速度快到没人能永远跟上最新版本但方法论是可以沉淀下来的。一套固定的评估集、一套标准化的部署流程、一套稳定的提示词方案比追逐任何一个具体的新模型都更值钱。每有新模型发布我用同一套评估集跑一遍当天就能知道它能不能替换现有方案——这套“全景图”读法比谁的预测都准。如果你刚接触大模型我的建议是别贪多先选一个生态最成熟的中小规模模型把部署链路和 RAG 流程完整跑一遍再逐步扩展微调和 Agent 能力。等你把这些基础动作练熟了回头看这张全景图每个位置在你心里的分量自然就清楚了。