AI 模型列表 2026: 10 种用例选项

假设你的团队花了一周时间阅读模型页面、比较 token 价格并搭建了一个原型。然后有人上传了一份代表性文档，却发现最便宜的候选模型无法将文档、指令和预期响应全部放入其上下文窗口中。集成成功了。但模型选择却失败了。

模型目录与模型选择并非一回事。 有些目录帮助你发现可下载的权重。其他的则比较测量的性能、销售托管推理、将模型连接到云采购，或打包模型以供本地执行。将它们视为可互换会浪费时间，并可能隐藏决定你的应用程序能否正常运行的约束。

一个有用的 AI 模型列表 应该告诉你针对特定任务从何开始：

• 发现和定制模型： 使用包含模型卡、文件和许可信息的目录。
• 比较生产候选模型： 使用独立测量结果，然后测试你自己的工作负载。
• 调用托管模型： 使用包含明确模型标识符和部署详细信息的 API 目录。
• 离线运行： 使用本地运行时目录并验证硬件要求。

对于文本应用程序，上下文长度和工具支持可能会立即排除一些候选模型。对于图像、视频和音频应用程序，支持的输入、输出控制和异步任务处理同样值得关注。以下选项服务于不同的目的，因此正确的起点与其说取决于哪个目录看起来最大，不如说取决于你接下来需要做什么。

目录

• 1. UberLLM AI 模型目录
  • 选择前需要检查什么
• 2. OpenRouter
  • 它适合哪里
• 3. Hugging Face Hub
  • 阅读模型名称之外的信息
• 4. Artificial Analysis
  • 比较用户体验的指标
• 5. Replicate Explore
  • 用你自己的原始材料进行测试
• 6. Microsoft Foundry Models
  • 选择模型的同时选择部署路径
• 7. Amazon Bedrock 模型目录
  • 采购和访问是选择的一部分
• 8. Google Cloud Model Garden
  • 将发现与部署假设分开
• 9. Ollama Library
  • 测试实际机器
• 10. Google Gemini API 模型列表
  • 验证确切的标识符
• 10个模型目录在访问、定价可见性和限制方面的差异
• 将候选清单转化为可用的集成
  • 评估完整的应用路径
  • 保持决策可复现

1. UberLLM AI 模型目录

在集成市场 API 之前，最适合比较托管选项。UberLLM AI 模型目录 将 457 个模型整合到一个比较页面中，提供实时定价、提供商名称、上下文长度和模型类型。当您的候选列表涵盖文本和媒体而非单一模型系列时，它会很有用。

在 UberLLM，我们将这一发现过程连接到一个与 OpenAI 和 Anthropic 兼容的 endpoint。开发者选择一个模型标识符，而市场路由则为请求的模型选择一个可用的卖家。这种区别很重要：您选择的既是模型的功能，也是托管的访问路径。

选择前需要检查什么

对于文档处理，请分别比较上下文长度和最大输出 token 数。一个能接受您的源材料的模型，可能仍然存在输出限制，阻止其生成完整的结果。我们的模型元数据公开了这两个字段，并且目录会标记支持工具的模型。

• 优势： 实时价格和提供商名称使跨提供商的候选列表筛选不再碎片化。
• 实用工作流： 按模态筛选，检查限制，然后在 playground 中比较代表性输出。
• 局限性： 列表无法确定您的提取 schema、编码任务或视觉简报是否会成功。

不要将显示的最低价格视为最终答案。对于文本，请估算您的应用程序产生的输入和输出组合；对于媒体，请在比较成本之前检查请求的生成配置。

实用规则： 只有当模型的限制、输出质量和故障行为满足工作负载要求时，才能选择该模型。产生不可用结果的廉价请求并非有用的节省。

价格和可用性可能会发生变化，因此请记录测试中使用的标识符和配置，而不是将您的候选列表保留为一堆模型名称。

2. OpenRouter

如果你的首要任务是尝试托管模型，而无需构建单独的提供商集成，OpenRouter 的模型目录 是一个实用的起点。它将可搜索的模型规格与通过通用 API 的访问结合在一起。

有用的比较字段包括 定价、上下文长度、模态和能力。这些有助于区分仅接受文本的模型与支持你的应用程序所需的额外输入或行为的模型。请查看各个模型页面，而不是假设通过相同接口公开的每个模型都接受相同的请求。

适用场景

OpenRouter 适合在现有应用程序中比较托管模型的开发者。你可以在更改所选模型的同时保持周围的评估框架稳定，尽管支持的参数和输出行为仍需要验证。

• 优点： 无需单独安排每个提供商集成，即可从发现阶段进入 API 实验阶段。
• 缺点： 将目录视为一个可以下载所有列出模型权重的仓库。
• 需要验证： 当前可用性、模型特定定价、上下文限制和所需能力。

对于编码代理，请测试工具调用参数和工具执行失败后的恢复能力，而不仅仅是独立代码答案的质量。通用 API 并不能使代理行为互换。

OpenRouter 替代方案的比较 在评估不同的访问服务时很有用。将该决策与模型选择分开：模型及其托管服务会带来不同的操作权衡。

3. Hugging Face Hub

当你需要模型权重而非仅仅一个端点时，请从 Hugging Face 开始。 Hugging Face Hub 在查找你可能需要自定义、检查或自行部署的模型时特别有用。

它的模型页面可以结合模型卡、可下载文件、实现示例和许可证详情。这使得它与托管 API 菜单成为一种不同的资源：你正在研究工件及其要求，而不仅仅是决定在请求中发送哪个标识符。

不仅仅看模型名称

在下载之前，请检查任务、架构、支持的推理框架和许可证。然后检查示例是否符合你的预期用途，特别是对于带有专用 prompt 模板的微调模型。

• 优点： 涵盖文本、视觉、图像和音频任务的广泛发现能力。
• 权衡： 文档和评估质量取决于发布者。
• 部署限制： 可下载模型不会自动作为托管 API 提供。

例如，一个文档处理团队可能会找到一个有前景的视觉-语言模型，但仍然需要组装预处理、推理和输出验证。该仓库有助于确定可用内容；它并不能消除部署工作。

开放权重并不意味着无限制使用。 请阅读实际的许可证和相关条件，而不是从下载按钮推断权限。

当底层文件的访问权限很重要时，请使用 Hugging Face 进行研究和自定义。如果你今天下午只需要比较托管响应，API 目录可能会让你更快地进行有意义的测试。

4. Artificial Analysis

难题不在于哪个模型的广告 token 价格最低，而在于哪个候选模型能在可接受的总成本和完成时间内满足你的质量要求。

Artificial Analysis 通过衡量智能、价格、每任务时间、首个回答 token 的延迟以及上下文窗口大小等指标来比较模型。其按任务成本的方法比单独查看 token 价格更有助于筛选，因为它将费用与工作负载关联起来。

比较用户体验到的指标

对于交互式助手，首个 token 的响应时间很重要，但这并不能取代端到端的完成时间。对于后台提取任务，经过验证的完成度和总开销可能比文本首次出现的快慢更重要。

• 用途： 在应用测试前识别能力、成本和速度之间的权衡。
• 不适用于： 假设基准测试的领先者在你的提示词或语言上也会胜出。
• 访问注意事项： 某些数据集或功能可能需要账户或付费访问。

比较每个成功任务的成本，而不仅仅是每个请求的成本。在你自己的评估中，请包含重试和被拒绝的输出。

LLM 价格指数 在筛选候选模型时提供了另一个定价参考。在比较任何指数时，请保持工作负载假设的可见性。

Artificial Analysis 并非下载所有模型或部署你的应用的地方。它的作用是改进候选名单，由你自己的测试工具来确定这些候选模型是否满足生产要求。

---

5. Replicate Explore

测试视频模型不仅仅是阅读语言模型排行榜那么简单。你需要检查接受的输入、输出示例、生成控制以及应用程序如何检索完成的结果。

Replicate Explore 对于这种亲身体验式的探索非常有用，尤其是在图像、视频和音频生成方面。模型页面可以提供示例、输入定义、使用说明和定价，以及托管的执行路径。

使用你自己的源材料进行测试

对于图像到视频的转换，请使用代表你应用程序的图像，而不仅仅是模型的精美示例。检查主题一致性、运动、构图以及输出是否符合要求。对于语音，测试名称、标点符号以及用户提交的语言。

• 优势： 你无需先设置本地推理即可进行实验。
• 灵活性： 自定义部署可以使用 Cog，这是 Replicate 的打包工具。
• 局限性： 社区发布的模型在维护、文档和支持方面可能有所不同。

在围绕某个模型进行开发之前，请检查其是否为官方发布并积极维护。此外，请仔细阅读计费单位，因为模型定价可能取决于运行时长或生成的输出，而不是文本式的 token 计算。

当你需要查看生成模型是否能产生可接受的媒体时，Replicate 是一个不错的选择。它作为跨无关模态的单一标准化排名则不太有用：语音模型和视频模型需要不同的验收标准。

6. Microsoft Foundry 模型

对于基于 Azure 的应用程序，部署资格与模型能力同等重要。如果一个有潜力的候选模型其可用的部署方法不符合您的架构或运营区域，那么它就毫无用处。

Microsoft Foundry 模型 将模型发现与 Microsoft 的云环境连接起来。该目录包含 Microsoft、合作伙伴和社区提供的产品，其中包含与任务、功能、许可和部署选择相关的信息。

在选择模型的同时选择部署路径

符合条件的模型可以有不同的 API-based、batch、provisioned 或 managed-compute 选项。不要以为在目录中找到一个模型就意味着所有托管和计费方式都适用于它。

• 适用对象： 需要模型选择与 Azure 部署决策保持一致的团队。
• 有用详情： 模型特定的部署信息和选定的基准测试结果。
• 限制： 可用性、部署方法和定价可能因模型和区域而异。

文档分析团队应同时调查模型的输入支持和它将部署的 endpoint 配置。如果生产环境将使用实质上不同的服务安排，那么测试一个演示 endpoint 是不够的。

因此，该目录既是架构资源，也是发现工具。当 Azure 集成是实际需求时使用它，而不是因为一个期望的模型恰好出现在那里。

对于提供商中立的探索，跨提供商比较工具通常是一个更清晰的起点。当您准备好建立实际的云部署路径时，再回到 Foundry。

7. Amazon Bedrock 模型目录

在构建原型之前，请检查区域可用性。 这是在使用 Amazon Bedrock 模型目录 进行 AWS 应用程序开发时最有用的习惯。

该目录列出了支持的基础模型及其功能。团队可以在将符合条件的模型集成到基于 AWS 的应用程序之前，在 Bedrock 控制台的 Playground 中检查区域可用性并测试这些模型。

采购和访问是选择的一部分

当应用程序已在 AWS 基础设施中运行时，Bedrock 尤其相关。但是，账户设置和区域访问可能会影响您所需模型在目标环境中是否可用。

• 有效的方法： 从支持的模型发现转向 AWS 部署。
• 需要确认的事项： 账户访问权限、目标区域、支持的输入以及调用要求。
• 它不是： 所有可下载或商用 AI 模型的公正清单。

对于支持助手，请测试您计划从生产环境发送的相同检索段落和指令。Playground 的成功表明请求可以工作；但这并不能证明您的检索管道、错误处理和输出解析器是正确的。

Bedrock 的优势在于它与 AWS 应用程序堆栈的连接。同样的定位对于那些只想广泛了解模型选项而不承诺进行云特定集成的团队来说是一个限制。

请记录评估中使用的确切模型和访问配置。一个可识别的模型家族名称不足以重现部署决策。

8. Google Cloud Model Garden

在 Google Cloud 上构建的团队应该同时评估模型及其服务安排。找到合适的模型系列只是开始；部署配置决定了它如何适应应用程序。

Google Cloud Model Garden 在 Google Cloud 的 AI 环境中，提供 Google、第三方和开放模型产品的发现功能。当下一步是基于云的开发，而不是下载模型用于不相关的本地运行时时，它最有用。

将发现与部署假设分开

在估算成本或实施工作量之前，请检查每个产品。可用性和定价取决于模型、区域和服务配置，因此仅凭目录条目无法确定是否适合生产。

• 最佳用途： 探索适用于 Google Cloud 应用程序的模型。
• 优势： Google 和精选的外部产品出现在同一个面向云的发现工作流程中。
• 局限性： 对于提供商中立的调查或离线实验来说，它不太方便。

对于图像分析服务，请确认接受的输入格式，然后测试您的应用程序执行的精确预处理。调整大小、裁剪和文档转换都属于评估范围，而不仅仅是最终部署。

不要将 Model Garden 与范围更窄的 Gemini API 模型列表混淆。前者有助于更广泛的云模型发现；后者为特定的 API 生态系统提供第一方详细信息。

一旦您的团队知道 Google Cloud 是部署计划的一部分，就可以使用 Model Garden。否则，请从模型要求开始，避免让现有的云控制台过早地定义候选列表。

9. Ollama 库

如果需求是在您自己的机器上运行模型，请从面向运行时的目录开始，而不是托管 API 市场。Ollama 库 帮助用户查找 Ollama 本地工作流支持的模型、大小、变体和功能。

模型大小是一个有用的初始筛选条件，但它并非完整的硬件估算。上下文使用、运行时开销以及其他争用内存的应用程序也会影响配置是否能流畅运行。

测试实际机器

选择一个适合您硬件的候选模型，然后使用代表性的输入长度进行测试。一个能处理短聊天提示的模型，在您添加检索到的文档或长对话时可能会变得不切实际。

斯坦福大学 AI 指数效率讨论 报告称，Phi-3-mini 拥有 3.8 亿参数，达到了与之前需要 PaLM 540 亿参数才能达到的相同 MMLU 阈值。这一比较支持了一个实用的教训：仅凭参数数量并不能衡量质量。

• 优点： 可轻松地对本地可运行模型进行实验。
• 成本区别： 本地执行避免了托管 API 使用费用，但硬件和运营仍然需要成本。
• 局限性： 您的机器和支持的格式限制了候选列表。

本地执行并非自动成为一个完整的离线系统。请检查检索、日志记录、工具和其他应用程序组件是否也保持本地化。

Ollama 是离线原型和硬件受限实验的有用起点。它并不能消除验证质量、内存使用或端到端延迟的需求。

10. Google Gemini API 模型列表

有时，正确的路径是最直接的。如果您已经选择了 Gemini API，请使用官方的 Gemini API 模型列表来确认模型标识符、描述和支持的功能。

这是第一方实现文档，而非跨提供商比较服务。它将模型发现与 API 文档和 Google AI Studio 连接起来，在您需要将选定的模型系列转化为可行的请求时非常有用。

验证确切的标识符

不要根据从比较文章中复制的模型系列名称进行构建。请确认具体的标识符，并在集成前检查其支持的输入、输出和访问条件。

• 优点： 为使用 Gemini API 的开发者提供直接的模型信息。
• 范围限制： 它无法帮助您比较所有竞争对手。
• 商业提示： 请检查所选模型的当前定价、访问层级和资格条件。

对于音频相关的应用程序，请验证特定模型是否支持所需的音频工作流，而不是假设每个 Gemini 模型都提供相同的功能。对多模态输入和工具使用也要同样谨慎。

在您的维护过程中也要进行生命周期检查。Veo 和 Gemini API 停用指南 在审查端点依赖项和迁移工作时非常重要。

官方列表最适合在初步筛选后作为实施参考。它提供了发出有效请求所需的详细信息，而您自己的评估则决定返回结果是否符合产品要求。

10个模型目录在访问方式、价格可见性和限制方面的区别

将候选列表转化为可用的集成

一旦您为每种模态确定了两到三个可行的模型，就停止浏览。如果您的团队尚未定义可接受的结果是什么样子，那么再多的候选模型也无济于事。在进行比较之前，请写下所需的上下文长度、输出限制、工具支持、输入格式和部署约束。

然后，通过每个候选模型发送相同的提示或生成任务。对于文本提取，验证返回的 schema 并将提取的值与预期答案进行比较。对于编码，对生成的更改运行测试；对于媒体，根据一致的简报审查输出，而不是选择看起来最令人印象深刻的样本。

评估完整的应用路径

包括推理周围的工作。文档转换、检索、工具执行、轮询、重试和输出验证都可以决定一个原本功能强大的模型是否可用。

• 质量： 记录接受的结果，而不仅仅是完成的请求。
• 延迟： 在相关情况下，测量初始响应和端到端完成时间。
• 成本： 包括重试、被拒绝的生成和必要的后续调用。
• 可靠性： 练习超时、格式错误的输出和不可用的 endpoint。

布鲁金斯学会关于 AI 模型评估的讨论 解释了为什么基准分数可能会忽略延迟、计算要求、成本和安全性等实际问题。您的评估应该明确这些问题，而不是将公共排行榜视为生产验收测试。

对于希望在文本、图像、视频和音频工作流中使用一个 endpoint 的团队，可以通过将现有 OpenAI 或 Anthropic SDK 配置中的 base URL 设置为兼容的 API endpoint 来开始 UberLLM 集成。使用 UberLLM key 并保留现有的 SDK 接口和周围代码，然后通过更改模型标识符来切换候选模型。验证每个候选模型支持的参数，并为媒体使用适当的异步任务工作流，而不是假设每种模态都像 streaming 聊天响应一样运行。

保持决策可复现

将模型标识符、提示版本、生成设置、评估输入和验收结果一起存储。该记录可以让另一位工程师重复测试，并使后续的模型更改更容易评估。避免依赖未版本化的屏幕截图或对输出质量的记忆印象。

选择一个默认模型，并定义应用程序何时应升级或安全失败。只有当回退模型满足相同的基本要求（包括隐私约束和工具支持）时，它才有用。最好的 AI 模型列表是能帮助您做出可辩护的集成决策，然后让位于可重复测试的列表。

---

UberLLM 通过统一的 API 和预付余额将开发者连接到第三方文本、图像、视频、音乐和语音模型。访问 UberLLM 以比较模型限制和实时价格，在 playground 中测试您的候选列表，并集成符合您应用程序要求的候选模型。