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、监控告警、日志分析等等。这些工具要能整合起来，形成完整的链路。
我的做法是尽量用成熟的开源工具，不要自己造轮子。代码管理用Git，CI/CD用现成的流水线工具，监控用Prometheus加Grafana这套。这些工具社区活跃，遇到问题好找答案。
整合的关键是标准化。接口标准化、配置标准化、日志格式标准化。标准化之后，各个环节才能顺畅衔接。这个工作前期投入大，但长期收益很高。
8. 我的选型决策流程与经验总结
说了这么多，最后分享一下我自己的选型决策流程。第一步是明确需求：任务类型是什么、数据敏感度如何、预算大概多少、团队技术栈是什么。这四个问题想清楚，选择范围就缩小了一大半。
第二步是快速验证：选两到三个候选模型，用真实数据跑一遍，看效果和成本。这个阶段不要追求完美，能跑通核心流程就行。第三步是压力测试：确认候选模型在预期负载下的表现，包括延迟、稳定性、限流行为。
第四步是评估生态：文档、社区、工具链这些软性指标。第五步是决策和落地：选定模型，做好封装和降级方案，然后上线。
这套流程我用了两年多，踩过的坑基本都覆盖到了。当然，模型行业变化快，流程本身也要持续迭代。我的建议是保持关注，定期更新自己的认知和清单，不要固守某个模型或者某个方案。
注意：以上所有内容基于我个人的使用经验和公开信息整理，不构成任何形式的建议。模型选型是高度场景化的事情，请结合自身实际情况判断。
