AI 模型现在多到一个尴尬程度：发布会越来越密，官网文档越来越散，真正写应用的人却常常卡在几个小问题上。

这个模型多少钱？上下文能塞多少？支不支持工具调用？结构化输出稳不稳？音频、图片、PDF 到底算不算一等能力？

Models.dev 做的事不大，但踩在痛点上。它在 GitHub 开源了一个社区维护的 AI 模型规格数据库，数据以 TOML 存在仓库里，再通过 API 输出 JSON。入口很直接：https://models.dev/api.json。

这不是又一个“模型大全”。更准确地说，它是一张给工具链读的模型账本。

它记录什么：规格事实，不是性能排名

Models.dev 收的不是评测分数，也不是“哪个模型最强”的主观推荐。

它收的是开发接入时最常用、也最容易散落在各家文档里的规格事实。

字段记录内容对开发者的用处
价格输入、输出、reasoning、缓存读写、音频 token 等算成本，不靠人工翻文档
限制上下文窗口、最大输入、最大输出避免上线后才发现塞不进去
能力工具调用、结构化输出、temperature、文件附件判断能不能接进 agent 流程
模态text、image、audio、video、pdf 等输入输出判断是否适合多模态任务
元信息知识截止、发布日期、更新时间、开源权重、状态做版本治理和模型选择

数据按 provider 和 model 组织。社区可以提 PR。GitHub Action 会做 schema 校验，检查字段、类型和 TOML 语法。

这类校验不性感，但很关键。机器要读，字段就不能随便写。工具要接，格式就不能天天变。

它还提供 provider logo 的 SVG 接口，比如 https://models.dev/logos/{provider}.svg。这点很小，却说明目标不是只做展示页，而是让产品和开发工具复用这些数据。

还有一个细节值得留意：Models.dev 被 opencode 内部使用。至少这表明，它不是只给人看的 README，而是已经在工具链里被消费的数据源。

谁最受影响：应用开发者和技术负责人

对 AI 应用开发者来说，Models.dev 解决的是接入前的脏活。

以前要切模型，往往得开一堆文档，手动查价格、上下文、输入输出限制，再把结果写进配置。现在至少多了一个统一入口，可以把模型规格拉进脚本、配置系统或内部控制台。

这不会让模型变好用，但能让试错变便宜。

对技术负责人来说，价值更直接：成本估算、模型路由、供应商切换，都需要一份能比较的底表。

比如一个团队要做多模型编排：便宜模型处理常规请求，强模型处理复杂推理，长上下文模型处理文档，多模态模型处理图片和音频。到了这一步，靠发布会截图和人工记忆管理模型，就是给事故留门。

更现实的动作是：

对象可以怎么用仍然要自己补什么
应用开发者用 API 拉取模型规格，生成配置或做接入检查实测质量、异常处理、具体 SDK 适配
技术负责人用统一字段比较成本、能力和限制，辅助模型选型定价复核、供应商 SLA、内部用量模型

这里要说清楚：Models.dev 不是 LiteLLM，也不是 OpenRouter。

LiteLLM 更像统一调用层，帮你用相似接口访问不同模型。OpenRouter 更像模型访问和路由平台。Models.dev 更底层一些，像一份开放的模型元数据表。

三者不在同一个位置上竞争。真正有意思的组合是：调用层、路由层、账本层互相接上。模型越多，底层元数据越重要。

真正稀缺的是可比性，不是信息

AI 行业从来不缺信息。缺的是同一口径的信息。

模型厂商当然会告诉你自己支持什么。但每家文档写法不同，价格单位不同，能力命名不同，限制藏的位置也不同。你能找到资料，不等于系统能读懂资料。

Models.dev 的价值就在这里：把分散文档压成结构化事实。

这有点像早期软件包索引，也像云服务价格表。不完全一样，但相似处在于：目录本身不稀奇，稀缺的是标准化后的可比性。

云厂商都有价格页。可一旦工程系统能自动读、自动算、自动切换，价格就不再只是网页信息，而是调度参数。

AI 模型也在走这条路。

单模型时代，大家盯着“谁最强”。多模型时代，问题变成“哪个任务该用哪个模型、花多少钱、失败后切到哪里”。这时候，规格字段比发布会金句更有用。

冷冰冰，才好接入。

开源账本有用，但别把它当裁判

我更在意的是边界。

Models.dev 记录的是规格和价格，不是实测质量。一个模型标着支持 reasoning，不等于推理稳定；标着大上下文，不等于长文检索不丢；标着结构化输出，不等于复杂 schema 下不会翻车。

这张账本能回答三类问题：它声称支持什么，官方价格大概是什么，接口层面有哪些限制。

它不能替你回答：这个模型在你的业务里到底好不好用。

还有几个现实约束绕不开。

供应商定价会变。模型会下线。wrapper provider 可能和原始模型存在细微差异。社区维护也不等于永远准确。GitHub Action 能校验 schema，不能校验现实世界。

所以它更像底账，不是审计报告。

“天下熙熙，皆为利来。”这句话放在这里不玄。模型厂商频繁改价格、改套餐、改上下文、改命名，本质上都是商业激励在推产品形态。开发者如果只靠官网页面和发布新闻做决策，很快会被噪音拖住。

接下来最该观察两件事。

一是更新速度。模型价格和能力变得太快，如果账本落后，机器可读也没用。

二是采用范围。opencode 内部使用是一个信号，但还不够。只有更多开发工具、成本面板、模型路由系统开始消费这份数据，它才会从“好用项目”变成基础设施的一块。

Models.dev 少见地抓住了一个基础问题：AI 应用进入多模型时代后，行业需要一层公开、可机器读取、可协作修订的模型元数据。

不华丽，但很实用。

模型看着越来越像魔法，开发却越来越需要会计。价格、限制、模态、能力、版本，最后都会落进工程系统的参数表里。谁把账算清，谁才有资格谈自动化。