1. 这份清单到底在解决什么问题每隔几个月我就会被朋友或者前同事问同一个问题现在市面上这么多大模型到底该用哪个问的人背景五花八门有做后端开发想接API的有做产品经理想快速搭原型的也有纯粹想自己折腾本地部署的。每次我都得从头讲一遍讲完对方过两周又来问因为又出了新模型。所以从两年前开始我养成了一个习惯维护一份自己的模型清单按维度分类定期更新。这份清单不追求大而全核心目标是三个字——能落地。每个条目我都会标注它适合什么场景、有什么坑、大概什么成本。今天把这份清单整理出来顺便聊聊我是怎么给这些模型分类的以及分类背后的逻辑。先说清楚这份清单的定位。它不是跑分排行榜也不是官方文档的搬运。跑分这东西参考价值有限同一个模型在不同评测集上的表现可能天差地别而且评测集和你的实际业务场景往往差得很远。我更看重的是这个模型在我的实际任务里表现如何接入成本高不高稳定性怎么样社区活跃度够不够。清单覆盖的范围包括国内外主流的大语言模型、多模态模型以及基于这些模型构建的Agent应用和开发框架。时间节点是2026年10月这个时间点很重要因为模型迭代太快半年前的结论可能已经完全不适用了。我会尽量标注每个条目的时效性但你在参考的时候还是要以官方最新信息为准。适合谁看如果你是刚接触大模型的技术人员这份清单可以帮你快速建立全局认知知道有哪些玩家、各自什么定位。如果你已经在用某个模型做开发这份清单可以帮你看看有没有更适合的替代方案。如果你只是好奇想了解一下那也没问题我会尽量用大白话解释。提示清单里的所有判断都基于我个人的实际使用体验和公开信息不构成任何采购建议。模型选型这件事最终还是要结合你自己的业务需求、预算和技术栈来定。2. 我用来给模型分类的四个维度2.1 按能力维度分通用、推理、多模态、代码最直观的分类方式是按能力分。通用对话模型是最常见的一类特点是啥都能聊但深度任务上可能不够专精。推理模型是这两年的大趋势核心区别在于它会花更多计算资源在想这一步上适合数学、逻辑、复杂规划类任务。多模态模型能处理图像、音频甚至视频输入做内容理解和生成。代码模型则是专门针对编程场景优化的在代码补全、调试、重构这些任务上表现更好。这个分类不是互斥的。现在很多模型都是多面手比如一个通用模型可能同时具备不错的推理和代码能力。但了解这个分类框架能帮你在选型时快速缩小范围。比如你要做一个数学辅导应用那优先看推理模型要做图片内容审核那多模态是必须的。2.2 按部署方式分云端API、本地部署、混合部署方式是另一个关键维度。云端API最省事按token付费不用操心硬件但数据要出你的服务器对数据敏感的场景要慎重。本地部署数据不出域可控性强但需要GPU硬件投入而且模型能力通常比云端旗舰版弱一些。混合方案是折中敏感数据本地处理非敏感任务走云端。我自己的做法是原型阶段一律用云端API快速验证想法。等业务跑通了再评估哪些环节可以迁到本地。这样避免一开始就陷入硬件选型和环境配置的泥潭。2.3 按成本结构分按量付费、订阅制、开源自托管成本这块很多人容易忽略。按量付费看起来灵活但如果你的调用量很大账单会很难看。订阅制适合用量稳定的个人或小团队但通常有速率限制。开源自托管前期投入大但边际成本低适合长期大规模使用。这里有个经验不要只看单价要算总拥有成本。云端API的单价可能很低但加上网络延迟、重试、失败请求这些隐性成本实际开销可能比预期高不少。本地部署虽然硬件贵但如果你的调用量足够大摊薄下来可能更划算。2.4 按生态成熟度分文档、社区、工具链最后一个维度是生态。一个模型再好如果文档稀烂、社区冷清、工具链不完善用起来也会很痛苦。我评估生态主要看三点官方文档是否清晰完整、社区是否有活跃的讨论和问题解答、是否有成熟的SDK和周边工具。这个维度在选型时经常被低估。我踩过好几次坑选了一个能力很强的模型结果接入时发现SDK文档缺失社区里也没人讨论遇到问题只能自己啃源码。后来我学乖了能力达标的前提下优先选生态成熟的。3. 国外主流模型的实际使用体验3.1 GPT系列生态最完善但要注意版本差异GPT系列是我用得最多的国外模型没有之一。原因很简单生态最完善。官方文档清晰SDK覆盖各种语言社区讨论活跃遇到问题基本都能搜到答案。从原型验证到生产部署整个链路的工具都很成熟。但GPT系列有个坑要注意不同版本之间的能力差异很大。同一个API端点背后可能是不同的模型版本行为可能不一致。我的做法是在代码里显式指定模型版本不要用默认值或者latest这种模糊的标识。另外GPT系列的不同版本在上下文长度、速率限制、定价上都有差异接入前一定要看清楚。实际使用中GPT在通用对话、内容生成、代码辅助这些任务上表现稳定。但在一些需要深度推理的任务上比如复杂数学证明或者多步逻辑规划它可能不如专门的推理模型。这不是说它不行而是说选型时要匹配任务类型。3.2 Gemini系列多模态能力强接入有门槛Gemini系列最大的亮点是多模态能力。图像理解、视频分析这些任务上它的表现确实可圈可点。我做过一个测试让它分析一段产品演示视频提取关键卖点和时间戳准确率相当高。但接入Gemini有个门槛它的API设计和GPT不太一样如果你习惯了GPT的那套调用方式切换到Gemini需要适应一下。另外Gemini的某些功能有地区限制或者账号资格要求注册和使用时可能会遇到一些障碍。我的建议是先用免费额度充分测试确认满足需求后再考虑付费。Gemini还有一个特点是更新频繁。这既是好事也是坏事。好事是能力在持续提升坏事是接口和行为可能变化你的代码需要跟着调整。我一般会在项目里做一层抽象把模型调用封装起来这样切换模型时改动最小。3.3 Claude系列长文本和代码场景的利器Claude系列在长文本处理上一直有优势。我处理过一些几百页的技术文档让它做摘要和问答效果比同期的其他模型好不少。代码场景也是它的强项特别是代码理解和重构类任务。Claude的另一个特点是输出风格比较稳。它不太会胡编乱造遇到不确定的问题会明确说不知道。这个特性在需要高可靠性的场景下很有价值。但反过来说它在创意生成类任务上可能不如其他模型放得开。使用Claude时要注意它的速率限制策略。免费版和付费版的限制差异较大而且限制是按多个维度算的不只是请求数。如果你的应用有突发流量要提前做好限流和降级方案。3.4 开源模型本地部署的现实考量开源模型这块我主要关注的是本地部署的可行性。说实话本地部署的门槛比很多人想象的高。不是下载个模型文件跑起来就完事了你要考虑硬件配置、推理框架、量化方案、显存优化这一堆问题。我的经验是如果你只是想体验一下用消费级显卡跑个量化版的小模型就够了。但如果要用于生产硬件投入会相当可观。而且本地部署的模型能力和云端旗舰版通常有代差。所以我的建议是除非有明确的数据合规要求或者成本考量否则优先用云端API。当然开源模型也有它的价值。可定制性强可以微调可以改架构这些是闭源模型做不到的。如果你有特殊的业务需求开源模型可能是唯一的选择。4. 国内模型的选择逻辑与避坑点4.1 国内模型的核心优势合规与本地化国内模型最大的优势是合规和本地化。如果你的业务面向国内用户使用国内模型在数据合规、内容审核、支付结算这些环节会顺畅很多。另外国内模型对中文的理解通常更好特别是在一些文化相关的表达上。本地化还体现在服务支持上。国内模型厂商通常能提供更及时的客服响应遇到问题沟通成本更低。而且定价策略也更符合国内用户的习惯有些厂商还支持对公转账和发票。但国内模型也有短板。生态成熟度整体不如国外头部模型SDK和工具链的完善程度参差不齐。另外不同厂商的API设计差异较大切换成本比国外模型之间切换要高。4.2 选型时要看的几个硬指标选国内模型时我主要看几个硬指标。第一是稳定性包括服务可用性和响应延迟。这个不能只看官方宣传要自己压测。第二是文档质量文档写得清不清楚示例代码能不能直接跑通。第三是计费透明度有没有隐藏费用超量怎么算。还有一个容易被忽略的指标是版本管理。有些厂商更新模型时不做版本区分你昨天调通的接口今天可能就行为变了。这种不确定性在生产环境里是灾难。所以我会优先选那些有明确版本管理的厂商。4.3 实际接入中遇到的典型问题接入国内模型时我遇到过几个典型问题。一个是鉴权方式五花八门有的用API Key有的用Access Token有的还要签名。另一个是返回格式不统一有的返回JSON有的返回SSE流解析逻辑要分别处理。还有一个坑是速率限制的触发条件不透明。有些厂商的限制是按QPS算的有些是按token数算的有些是混合的。而且触发限制后的行为也不一样有的直接报错有的排队等待。这些细节在文档里往往写得不清楚需要自己试出来。我的应对策略是在接入层做统一封装把不同厂商的差异屏蔽掉。这样上层业务代码不用关心底层用的是哪家模型切换时只需要改配置。5. Agent框架的选型与落地5.1 Agent到底是什么从概念到落地Agent这个概念这两年很火但很多人对它的理解还停留在概念层面。简单说Agent就是让模型不只是回答问题而是能自主规划、调用工具、执行多步任务。比如你让它帮我订一张明天去北京的机票它需要理解意图、查询航班、比较价格、完成预订这一系列动作。落地Agent的关键是工具调用能力。模型需要能理解你定义了哪些工具、每个工具干什么、什么时候该调用。这个能力不同模型差异很大。有些模型工具调用很稳有些则经常调错或者该调不调。我的经验是Agent落地不要一上来就搞复杂的多步规划。先从单步工具调用开始跑通了再逐步增加复杂度。而且一定要做好错误处理和人工兜底因为Agent出错的方式往往很隐蔽。5.2 主流Agent框架的对比与选择Agent框架这块我用过几种不同类型的。有的是偏编排的你用配置文件定义流程有的是偏代码的你直接写代码控制逻辑。各有优劣。偏编排的框架上手快适合流程相对固定的场景。但灵活性差遇到复杂分支或者动态决策就不好处理。偏代码的框架灵活性强但开发成本高而且容易写出难以维护的面条代码。我的选择标准是如果业务流程清晰、变化不频繁用编排框架如果需要动态决策、复杂状态管理用代码框架。另外还要看框架的社区活跃度和文档质量这个前面说过不再赘述。5.3 Agent安全那些容易被忽略的风险点Agent安全是个大话题我挑几个实际遇到的点说。第一是工具调用的权限控制。Agent能调用的工具必须严格限制不能给它过大的权限。比如一个查询天气的Agent不应该有删除文件的权限。第二是输入输出的内容安全。Agent的输入可能包含恶意指令输出可能包含不当内容。这两端都要做过滤和审核。第三是执行过程的监控和审计。Agent的每一步决策和动作都要有日志出了问题能追溯。还有一个容易被忽略的点是资源消耗。Agent执行多步任务时token消耗可能远超预期。如果没有限额和熔断机制账单可能会失控。我一般会给每个Agent任务设置token上限和超时时间。6. 模型微调什么时候该做什么时候不该做6.1 微调不是万能药先想清楚这三个问题微调这件事我的态度是能不做就不做。原因很简单微调的成本和风险都比很多人想象的高。在决定微调之前先问自己三个问题。第一提示词工程能不能解决很多所谓的模型能力不足其实是提示词没写好。我见过太多案例调整一下提示词结构效果就上来了。第二检索增强能不能解决如果问题是模型缺乏特定知识那用RAG比微调更合适因为知识可以随时更新。第三有没有足够的标注数据微调需要高质量的训练数据数据不够或者质量差微调效果可能还不如不调。这三个问题都想清楚了还是觉得需要微调那再往下走。6.2 微调实战中的数据和参数经验如果确定要微调数据是第一个坎。我的经验是数据质量比数量重要得多。一千条高质量的数据效果可能好过一万条噪声数据。数据要覆盖你的目标场景而且要有多样性不能都是相似的样本。参数方面学习率、批次大小、训练轮数这些都要根据数据量和任务类型调。我的做法是先跑一个小规模的实验用少量数据快速试几组参数找到大致方向后再扩大规模。不要一上来就全量训练浪费时间和算力。还有一个经验是微调后的模型要做充分的评测。不能只看训练损失要在实际任务上测试。而且要和微调前的模型做对比确认微调确实带来了提升。6.3 微调后的部署与版本管理微调完成后部署和版本管理是另一个挑战。微调模型通常比基座模型大推理成本更高。而且微调模型和基座模型的接口可能不完全兼容需要额外适配。版本管理也很重要。你可能会针对不同场景微调出多个版本这些版本要能清晰区分和管理。我的做法是给每个微调模型打上明确的标签记录训练数据、参数、评测结果这些元信息。这样后续排查问题或者回滚时才有依据。7. 本地部署与开发工具链的实操细节7.1 本地部署的硬件门槛与量化方案本地部署这块硬件是绕不过去的。我的经验是显存是瓶颈不是算力。模型能不能跑起来主要看显存够不够。量化是降低显存占用的主要手段常见的量化方案有几种精度损失和显存节省各不相同。选择量化方案时要在精度和资源之间权衡。我的做法是先用低精度量化跑通流程确认可行后再逐步提高精度找到满足业务要求的最低配置。不要一上来就追求最高精度那样硬件成本会很高。另外要注意的是不同推理框架对量化的支持程度不一样。有些框架只支持特定格式的量化模型选框架时要考虑这个因素。7.2 开发环境配置中的常见坑开发环境配置是另一个容易踩坑的地方。我遇到过的问题包括依赖版本冲突、CUDA版本不匹配、环境变量配置错误等等。这些问题单个看都不复杂但排查起来很费时间。我的建议是用容器化方案管理开发环境。把依赖、配置、代码都打包进容器这样环境一致性问题基本就解决了。另外把环境配置脚本化新机器上一条命令就能搭好环境省去重复劳动。还有一个经验是不要在生产环境直接调试。本地或者测试环境把问题都解决了再上生产。生产环境的任何改动都要有回滚方案。7.3 工具链整合从开发到上线的完整链路从开发到上线涉及的工具很多代码管理、CI/CD、监控告警、日志分析等等。这些工具要能整合起来形成完整的链路。我的做法是尽量用成熟的开源工具不要自己造轮子。代码管理用GitCI/CD用现成的流水线工具监控用Prometheus加Grafana这套。这些工具社区活跃遇到问题好找答案。整合的关键是标准化。接口标准化、配置标准化、日志格式标准化。标准化之后各个环节才能顺畅衔接。这个工作前期投入大但长期收益很高。8. 我的选型决策流程与经验总结说了这么多最后分享一下我自己的选型决策流程。第一步是明确需求任务类型是什么、数据敏感度如何、预算大概多少、团队技术栈是什么。这四个问题想清楚选择范围就缩小了一大半。第二步是快速验证选两到三个候选模型用真实数据跑一遍看效果和成本。这个阶段不要追求完美能跑通核心流程就行。第三步是压力测试确认候选模型在预期负载下的表现包括延迟、稳定性、限流行为。第四步是评估生态文档、社区、工具链这些软性指标。第五步是决策和落地选定模型做好封装和降级方案然后上线。这套流程我用了两年多踩过的坑基本都覆盖到了。当然模型行业变化快流程本身也要持续迭代。我的建议是保持关注定期更新自己的认知和清单不要固守某个模型或者某个方案。注意以上所有内容基于我个人的使用经验和公开信息整理不构成任何形式的建议。模型选型是高度场景化的事情请结合自身实际情况判断。