1. 从一份持续更新的模型清单说起
每隔一段时间，总有人问我：现在市面上到底有哪些大模型值得关注？国内的和国外的差距在哪里？做应用选哪个底座更合适？说实话，这个问题放在两年前我还能一口气答完，但现在模型迭代的速度快到让人喘不过气，几乎每个月都有新版本发布，每隔几周就有新的应用形态冒出来。所以我养成了一个习惯——维护一份自己的模型与应用追踪清单，按维度分类，定期更新。这份清单不是给老板看的汇报材料，也不是给客户看的选型报告，纯粹是我自己在做技术选型和方案设计时的参考底稿。
今天要聊的这份“国内外知名大模型及应用——模型/应用维度”清单，就是基于这个思路整理出来的。它覆盖了当前主流的大语言模型、多模态模型、图像生成模型、视频生成模型以及基于这些模型构建的各类应用产品。不管你是刚入行的开发者想快速了解行业全貌，还是有一定经验的技术负责人需要做选型对比，又或者是产品经理在规划AI功能时需要知道“现在到底能做什么”，这份清单都能帮你建立一个相对完整的认知框架。
需要提前说明的是，这份清单的更新日期标注为2026年10月，这意味着它反映的是那个时间节点前后的行业状态。模型领域变化极快，具体的版本号和排名可能随时变动，但分类逻辑、选型思路和评估维度是相对稳定的。我在整理过程中特别注重“为什么这样分类”和“选型时该看什么”，而不是简单地罗列名字。毕竟，知道有哪些模型只是第一步，知道怎么选、怎么用才是真正有价值的部分。
接下来的内容会按照模型类型和应用场景两条主线展开，中间穿插我在实际项目中的选型经验和踩坑教训。文章篇幅会比较长，建议你先收藏，需要的时候按章节查阅。
2. 语言模型：通用能力底座的分层格局
2.1 海外阵营的梯队划分与各自定位
海外的大语言模型经过几年混战，目前已经形成了比较清晰的梯队格局。第一梯队毫无疑问是那几个头部闭源模型，它们在推理能力、指令遵循、长文本处理等核心指标上持续领先。这类模型的特点是迭代快、能力全面，但调用成本相对较高，适合对效果要求苛刻的场景。
我在实际项目中的体会是，第一梯队模型之间的差距其实没有榜单上看起来那么大。更多时候，选择哪个取决于你的具体任务类型。比如有些模型在代码生成上表现突出，有些在创意写作上更有优势，还有些在多轮对话的连贯性上做得更好。所以我的建议是，不要迷信某一个“最强模型”，而是根据你的核心任务做小规模对比测试。
第二梯队则是一些能力稍弱但性价比极高的模型。这些模型往往在某些垂直领域有不错的表现，而且价格优势明显。对于预算有限或者对响应速度要求高的场景，第二梯队往往是更务实的选择。我见过不少团队一上来就冲着最强模型去，结果成本失控，最后不得不降级，反而浪费了前期投入的适配工作。
还有一个值得关注的趋势是开源模型的崛起。海外有几个开源模型系列在能力上已经非常接近闭源第二梯队，而且因为可以私有化部署，在数据安全和定制化方面有天然优势。如果你的场景涉及敏感数据或者需要深度微调，开源模型是绕不开的选项。
2.2 国内主力模型的差异化竞争策略
国内的大模型格局和海外有明显不同。最显著的特点是，国内模型在中文理解和生成上的表现普遍更优，这得益于训练数据中中文语料的占比更高。如果你做的是面向中文用户的产品，国内模型往往是更自然的选择。
国内模型大致可以分为几个类型。一类是互联网大厂推出的通用模型，这类模型的特点是能力全面、生态完善，通常配套有完整的开发平台和工具链。另一类是AI创业公司推出的模型，这类模型往往在特定能力上更加突出，比如长文本处理、多模态理解等。还有一类是学术机构或研究团队开源的模型，这类模型在技术创新上常有亮点，但工程化程度可能不如商业模型。
我在选型时的一个经验是，国内模型在中文场景下的“语感”确实更好。同样的提示词，国内模型生成的中文内容往往更符合中文表达习惯，不需要太多后处理。但在一些需要深度推理或复杂逻辑的任务上，海外头部模型仍然有一定优势。所以如果你的应用场景是中英文混合的，可能需要考虑多模型路由的方案。
另外，国内模型在合规性和内容安全方面通常有更完善的机制，这对于面向国内用户的产品来说是一个重要的考量因素。不过这也意味着在某些创意类场景下，国内模型可能会显得相对保守，需要你在提示词设计上多花心思。
2.3 选型时容易忽略的三个隐性成本
说到选型，大多数人首先看的是模型能力榜单和API价格。但根据我的经验，真正影响项目成败的往往是那些不在榜单上的隐性成本。第一个是适配成本。不同模型的提示词格式、参数设置、返回结构都不一样，切换模型意味着大量的适配工作。我见过一个团队因为初期选型草率，后期想换模型时发现适配工作量巨大，最后只能硬着头皮继续用不合适的模型。
第二个是稳定性成本。有些模型在测试阶段表现很好，但一到高并发场景就出现响应变慢、超时甚至服务不可用的情况。所以在正式接入前，一定要做压力测试，了解模型服务在峰值负载下的表现。这个成本在项目初期很容易被忽略，但一旦出问题就是灾难性的。
第三个是迭代成本。模型版本更新后，原有的提示词可能需要重新调优，甚至有些功能会发生变化。如果你的系统深度依赖某个模型的特定行为，版本更新可能会带来意想不到的问题。我的做法是，在架构设计时就预留模型切换的抽象层，把模型调用封装成统一的接口，这样即使底层模型更换，上层业务逻辑也不需要大改。
2.4 多模型路由：一个被低估的工程实践
多模型路由是我最近一年越来越重视的一个工程实践。简单来说，就是不让系统只依赖一个模型，而是根据任务类型、成本预算、响应时间要求等因素，动态选择最合适的模型来处理请求。
这个思路听起来简单，但实际落地时有不少细节要注意。首先是路由策略的设计。你可以按任务类型路由，比如简单分类任务用小模型，复杂推理任务用大模型；也可以按成本路由，在预算充足时用高质量模型，预算紧张时降级；还可以按用户等级路由，付费用户享受更好的模型服务。
其次是降级机制。当主模型服务不可用时，系统应该能自动切换到备用模型，而不是直接报错。这个机制在设计时就要考虑好，不能等到出故障了才临时加。我在一个项目里就遇到过主模型服务突然限流的情况，幸好提前做了降级方案，用户几乎无感知。
最后是一致性管理。不同模型的输出风格和格式可能不同，如果你的产品对输出一致性有要求，就需要在路由层做统一的格式化处理。这个工作看起来琐碎，但对用户体验的影响很大。
3. 多模态模型：从“能看懂”到“能干活”
3.1 图像理解模型的实用化进展
多模态模型是这两年进步最快的方向之一。早期的图像理解模型只能做简单的物体识别和场景描述，现在的主流模型已经能完成复杂的视觉推理任务，比如读懂图表、分析文档截图、理解UI界面等。
我在实际项目中最常用的场景是文档解析。把一份扫描件或者截图丢给多模态模型，让它提取关键信息并结构化输出，这个流程已经相当成熟。相比传统的OCR方案，多模态模型的优势在于能理解上下文，比如它能区分“合同金额”和“付款金额”这两个看起来相似但含义不同的字段。
不过实际使用中也有不少坑。图像分辨率就是一个容易被忽略的问题。太低的分辨率会导致模型看不清细节，太高的分辨率又会增加处理时间和成本。我的经验是，对于文档类图像，长边控制在2000像素左右比较合适；对于需要识别小字的场景，可以适当提高，但要注意模型的输入限制。
另一个坑是图像中的文字方向。有些模型对旋转或倾斜的文字识别效果不好，需要在预处理阶段做矫正。这个细节在测试时很容易被忽略，因为大家测试时通常用的都是端正的图片，但实际用户上传的图片什么样都有。
3.2 视频生成模型的能力边界与适用场景
视频生成是最近一年最热的方向，但也是最容易被高估的方向。目前主流的视频生成模型在短片段生成上已经能做出相当惊艳的效果，但一旦涉及长视频、复杂动作或者精确控制，能力边界就非常明显了。
我在评估视频生成模型时，主要看几个维度。一是生成时长，目前大多数模型只能生成几秒到十几秒的片段，超过这个长度就会出现明显的连贯性问题。二是动作自然度，简单的镜头运动或者人物动作还可以，但复杂的交互动作往往会出现扭曲或跳变。三是一致性，同一个角色在不同片段中的外观能否保持一致，这是做系列内容的关键。
从应用场景来看，视频生成目前最适合的是创意辅助和素材生成，而不是直接产出成片。比如你可以用它快速生成分镜预览，或者为短视频制作一些过渡素材。但如果要生成完整的营销视频或教学视频，还是需要结合传统剪辑工具和人工调整。
成本也是需要考虑的因素。视频生成的计算开销远大于图像生成，同样的预算能生成的视频时长非常有限。所以在做方案设计时，一定要把生成成本算清楚，避免出现“效果很好但用不起”的尴尬。
3.3 语音模型在实时交互中的关键指标
语音模型包括语音识别、语音合成和端到端的语音对话。在实时交互场景中，延迟是最关键的指标。我测过不少语音方案，有些识别准确率很高，但延迟太大，导致对话体验很差；有些延迟很低，但识别错误率偏高，用户需要反复重复。
我的经验是，对于实时对话场景，端到端延迟控制在1秒以内是比较理想的，超过2秒用户就会明显感觉到卡顿。这个延迟包括语音识别、语义理解、回复生成和语音合成四个环节，每个环节都要优化。
语音合成方面，自然度是核心指标。早期的TTS听起来很机械，现在的模型已经能生成相当自然的声音，甚至能模拟不同的情感和语气。但在实际产品中，我发现用户对语音的自然度要求其实没有想象中那么高，反而对响应速度和稳定性更敏感。所以如果你的资源有限，优先优化延迟和稳定性，而不是追求极致的自然度。
还有一个容易被忽略的点是打断处理。在实时对话中，用户可能会在模型说话时打断，系统需要能正确检测打断并停止当前语音播放，同时理解用户的打断内容。这个功能对交互体验的影响很大，但实现起来并不简单，需要语音活动检测和对话管理的紧密配合。
4. 应用层：模型能力的产品化落地
4.1 通用助手类应用的竞争焦点
通用助手类应用是模型能力最直接的体现，也是竞争最激烈的赛道。这类应用的核心功能包括问答、写作、翻译、编程辅助等，看起来门槛不高，但要做好其实很难。
我观察下来，这类应用的竞争焦点已经从“能不能回答”转向了“回答得好不好”和“用起来顺不顺手”。回答质量方面，除了模型本身的能力，提示词工程和上下文管理是关键。好的助手应用会根据用户的历史对话和偏好动态调整回复风格，而不是每次都用同样的模板。
使用体验方面，响应速度和交互设计是重点。用户问一个问题，如果等太久就会失去耐心；如果界面操作复杂，用户可能根本不会用第二次。我见过一些功能很强大的助手应用，但因为交互设计糟糕，用户留存率很低。
还有一个趋势是垂直化。通用助手虽然覆盖面广，但在特定领域的深度往往不够。所以现在很多应用选择在通用能力的基础上，针对特定场景做深度优化。比如专门做法律咨询的助手、专门做医疗问答的助手等。这类垂直助手在专业场景下的表现往往比通用助手好很多。
4.2 编程辅助工具的实战体验
编程辅助是我日常使用频率最高的AI应用类型。从最早的代码补全，到现在的代码生成、代码审查、bug修复，这类工具的能力提升非常明显。
我在实际使用中的体会是，编程辅助工具最适合的场景是“有明确目标的重复性编码”和“不熟悉的API查询”。比如你需要写一个标准的数据处理流程，或者需要调用一个你不熟悉的库，AI辅助能大幅提升效率。但在架构设计、复杂算法实现、性能优化这些需要深度思考的场景，AI目前还只能起到辅助作用，不能替代人的判断。
代码质量方面，AI生成的代码往往能跑通，但未必是最优解。我见过不少AI生成的代码存在性能问题或者边界条件处理不完善的情况。所以我的习惯是，AI生成的代码一定要经过review和测试才能合并到主分支，不能直接信任。
还有一个实用技巧是，给AI提供足够的上下文。如果你只给一个函数名让它实现，结果往往很通用；如果你把相关的数据结构、调用方式、业务背景都告诉它，生成的代码质量会高很多。这个道理和给人类同事分配任务是一样的。
4.3 内容创作工具的边界与人工介入点
内容创作是AI应用最广泛的领域之一，包括文案生成、文章写作、营销素材制作等。这类工具确实能提升效率，但边界也很明显。
我的经验是，AI最适合做的是“从1到N”的工作，而不是“从0到1”的工作。比如你有一个明确的写作框架和核心观点，让AI帮你扩展成完整文章，效果通常不错；但如果你让AI完全从零开始创作，结果往往缺乏深度和独特性。
在营销文案场景中，AI生成的内容往往比较“安全”，缺乏让人眼前一亮的创意。所以我的做法是，用AI生成多个版本作为参考，然后人工挑选和修改。这样既能利用AI的效率，又能保证最终质量。
还有一个需要注意的是事实准确性。AI生成的内容可能会出现事实错误，特别是在涉及具体数据、日期、人名等细节时。所以在发布前一定要做事实核查，不能直接使用。
4.4 行业解决方案的定制化路径
除了通用应用，基于大模型的行业解决方案也是重要的应用方向。这类方案通常针对特定行业的需求做深度定制，比如金融风控、医疗辅助诊断、法律文书生成等。
做行业解决方案的关键是理解行业的核心痛点和工作流程。我参与过几个行业项目，最大的体会是：技术不是瓶颈，对业务的理解才是。很多团队技术能力很强，但做出来的方案和实际工作流程脱节，用户不愿意用。
定制化的路径通常有两种。一种是在通用模型基础上做微调，让模型适应特定领域的术语和表达方式。另一种是构建领域知识库，通过检索增强生成的方式让模型能利用专业知识。两种方式各有优劣，微调的效果更深入但成本高，知识库的方式更灵活但效果受检索质量影响大。
我的建议是，先从知识库的方式入手，快速验证方案可行性，然后再根据效果决定是否投入资源做微调。这样风险更可控，迭代速度也更快。
5. 评估与选型的实操框架
5.1 建立自己的评估基准
市面上的模型评测榜单很多，但大多数和你的实际场景关系不大。所以我的做法是建立自己的评估基准，用真实业务数据来测试模型表现。
建立评估基准的步骤大致如下。首先，收集一批有代表性的测试样本，覆盖你的核心业务场景。样本数量不需要太多，几十到几百条就够，但一定要有代表性。然后，定义清晰的评估标准，比如准确率、召回率、响应时间、成本等。最后，定期用这批样本测试候选模型，记录结果并对比。
这个评估基准的好处是，它能反映模型在你特定场景下的真实表现，而不是在通用榜单上的排名。我见过太多团队根据榜单选模型，结果发现实际效果和预期差距很大。
评估基准还需要定期更新。随着业务发展，测试样本可能需要调整；随着模型迭代，评估标准也可能需要变化。我的习惯是每季度review一次评估基准，确保它仍然能反映当前的核心需求。
5.2 成本测算的完整公式
模型选型时，成本是一个绕不开的因素。但很多人只关注API调用价格，忽略了其他成本项。一个完整的成本测算应该包括以下几个部分。
首先是直接调用成本，包括输入token和输出token的费用。不同模型的计费方式不同，有些按token数计费，有些按调用次数计费，需要统一换算成可比较的单位。
其次是基础设施成本。如果使用云服务，需要考虑网络带宽、存储、计算资源等费用；如果私有化部署，需要考虑服务器采购、运维、电力等成本。
第三是人力成本。包括提示词工程、模型适配、效果调优、日常运维等工作的人力投入。这部分成本往往被低估，但实际上可能占总成本的一半以上。
第四是试错成本。模型选型不是一次就能选对的，可能需要尝试多个方案。每次尝试都涉及适配、测试、评估的工作量，这些都要算进去。
把这些成本加起来，才是真正的总拥有成本。我见过不少项目因为只算了API调用费用，导致后期预算严重超支。
5.3 从POC到生产的避坑清单
从概念验证到生产部署，中间有很多坑。我整理了一份自己的避坑清单，供参考。
- 不要用测试环境的数据量来评估生产环境的性能。测试时可能只有几十个并发，生产环境可能是几千个，性能表现完全不同。
- 不要忽略错误处理。模型调用可能失败、超时、返回异常格式，这些情况在生产环境中都会遇到，需要提前设计好处理逻辑。
- 不要假设模型行为永远不变。模型版本更新后，同样的输入可能得到不同的输出，需要有监控和回滚机制。
- 不要把所有逻辑都放在提示词里。提示词工程很重要，但有些逻辑用代码实现更可靠、更易维护。
- 不要忽略数据隐私和合规要求。特别是涉及用户数据的场景，要确保符合相关法规和内部规范。
- 不要等到上线后才考虑监控。从第一天就要建立完善的监控体系，包括调用量、延迟、错误率、成本等指标。
这份清单看起来都是常识，但在实际项目中，我几乎每次都能看到有人踩其中的坑。所以我的建议是，在项目启动时就对照这份清单做检查，而不是等到出问题了才补救。
6. 趋势观察与个人判断
6.1 模型能力的发展方向
从最近一年的模型迭代来看，几个方向的能力提升特别明显。一是长文本处理，上下文窗口从几K扩展到几百K甚至更大，这让很多之前做不了的应用成为可能。二是推理能力，模型在数学、逻辑、代码等需要深度思考的任务上进步显著。三是多模态融合，文本、图像、语音、视频的统一理解和生成能力越来越强。
但也有一些方向进展比预期慢。比如真正的“理解”能力，模型在很多情况下仍然是在做模式匹配，而不是真正的理解。再比如持续学习能力，模型无法在使用过程中持续更新知识，每次更新都需要重新训练或微调。
我的判断是，未来一段时间，模型能力的提升会更多体现在工程优化和场景适配上，而不是单纯的参数规模增长。也就是说，同样的模型能力，通过更好的提示词、更合理的架构、更精细的调优，能发挥出更大的价值。
6.2 应用形态的演变逻辑
应用形态的演变和模型能力的发展是相互促进的。模型能力提升让新的应用形态成为可能，而应用需求又反过来推动模型能力的优化。
从目前的发展趋势来看，应用形态正在从“对话式交互”向“任务式执行”演变。早期的AI应用主要是聊天机器人，用户提问、模型回答。现在的应用越来越多地能执行具体任务，比如帮你订机票、写代码、做表格等。这个演变对模型的要求更高，不仅需要理解意图，还需要规划步骤、调用工具、处理异常。
另一个趋势是从“通用助手”向“场景化智能体”演变。通用助手虽然覆盖面广，但在具体场景下的深度往往不够。场景化智能体针对特定场景做深度优化，能更好地理解场景需求，提供更精准的服务。
6.3 给不同阶段团队的建议
最后，根据我观察到的不同团队的情况，给一些针对性的建议。
对于刚起步的团队，我的建议是不要一上来就追求自研模型或深度定制。先用成熟的API快速验证产品思路，把精力放在场景理解和用户体验上。等产品方向明确了，再考虑技术层面的深度优化。
对于有一定规模的团队，建议建立自己的模型评估体系和多模型路由能力。不要绑定单一模型供应商，保持灵活性。同时开始积累领域数据和提示词资产，这些是长期竞争力的来源。
对于大型团队，可以考虑在开源模型基础上做深度定制，构建自己的模型能力。但要注意，自研模型是一个长期投入，需要持续的资源支持，不是一次性项目。在决定自研之前，一定要想清楚投入产出比。
无论处于哪个阶段，我的核心建议都是一样的：以场景为导向，以用户价值为标准，不要为了技术而技术。模型只是工具，解决实际问题才是目的。
