对开发者、平台团队、研究团队和采购方来说，这个网站最好的用法不是盯着单一榜单，而是按"先定义决策问题，再看对应维度，再回到方法学核实边界条件"的顺序来用。
这个网站最适合解决什么问题
Artificial Analysis 最适合解决 5 类问题：
- 我现在该选哪个模型接入 API。
- 同一个模型，应该选哪家 provider。
- 我要做本地部署或自建服务，应该关注什么硬件和吞吐指标。
- 我想比较开源模型和闭源模型，在能力、速度、价格、开放性之间怎么取舍。
- 我不是做纯文本，还要比较图像、视频、语音模型时，哪里能看到相对客观的横向对比。
它的核心价值不是给你一个"唯一正确答案"，而是帮你把选型从主观印象，变成一套较稳定的多维比较流程。官方 FAQ 对它自己的定位也说得很明确：这是一个独立 AI 基准与分析平台，目标是帮助用户选择最适合自己 use case 的 AI 技术。
最应该先熟悉的 8 个入口
如果你是第一次用，我建议先记住下面这些页面：
- 首页
用来看最新重点指标、热门模型和主要导航。 - Models 总览
这是文本模型选型的主工作台。 - Model Recommender
适合快速按"能力 / 速度 / 成本"优先级生成 shortlist。 - Intelligence 方法学
用来判断"综合智能分"到底是怎么来的。 - Performance 方法学
用来判断速度、TTFT、端到端时延这些指标能不能直接套到你的业务里。 - Hardware Benchmarks
用来判断硬件方案和部署系统的真实吞吐与并发能力。 - Image Arena、Video Arena、Speech Arena
用来比较多模态模型的用户偏好表现。 - API Reference
适合做内部仪表盘、自动跟踪、或者模型数据库同步。
最佳使用心法：先问"决策问题"，再看指标
很多人第一次用这类网站，最容易犯的错误是：
- 直接看 Intelligence 排名，然后把它当成最终答案。
- 看谁最便宜，就默认谁性价比最高。
- 看谁 tokens/s 最高，就以为用户体验一定最好。
更好的方式是先把问题分型：
- 如果你关心"回答质量上限"，先看
Intelligence。 - 如果你关心"用户等待感受"，先看
Latency和End-to-End Response Time。 - 如果你关心"单位成本"，先看
Price、Intelligence vs Price、Output Speed vs Price。 - 如果你关心"长文档 / RAG / 超长上下文"，先看
Context Window，再看AA-LCR这一类长上下文推理能力。 - 如果你关心"开放性与可控性"，看
Openness Index和Open Weights / Proprietary。 - 如果你关心"能不能稳定跑 agent"，不能只看综合分，还要看
GDPval-AA、Terminal-Bench Hard、τ²-Bench Telecom，以及现在单独推出的 AA-AgentPerf。
一句话说，先定义你真正优化的目标函数，再选图表。
我认为最实用的 6 种使用方式
1. 3 分钟快速筛模型
这是最适合日常工作的用法。
步骤：
- 打开 Models 总览。
- 先看
Intelligence vs Price，排除"明显贵但未显著更强"的模型。 - 再看
Latency和End-to-End Response Time，排除用户体验不合适的模型。 - 最后点进候选模型详情页，看上下文长度、输入输出价格、是否 reasoning、是否 open weights。
适用场景：
- 你要给产品接一个默认模型。
- 你要给内部工具做一版初选。
- 你每周例行看看市场上有没有出现更有性价比的新模型。
为什么这样用最有效：
因为首页和排行榜很容易把注意力吸引到"最强模型"上，但真实业务里，很多时候你不是在找"最强"，而是在找"够强、够快、够便宜、够稳"。
2. 用 Recommender 做第一轮 shortlist，而不是做最终决策
Model Recommender 的正确用法，不是让它替你拍板，而是让它帮你缩小搜索空间。
建议这样用：
- 先按你当前任务设置
Intelligence / Speed / Cost的优先级。 - 得到 shortlist 后，回到
Models页逐个核查。 - 再补看是否支持你需要的上下文长度、是否 reasoning、是否开放权重、以及供应商生态。
为什么不能只看 Recommender：
- 它本质上是一个偏好加权器，不是你的业务建模器。
- 它并不知道你是否重视中文、多轮 agent、代码执行、工具调用、品牌风险、地区可用性、合规要求。
所以它最适合作为"第一道过滤器"，不适合作为"最后一锤定音"。
3. 用它做 API 选型时，重点看"速度形态"而不是单点速度
Artificial Analysis 的性能页最有价值的地方，不是一个静态的 tokens/s 数字，而是它把速度拆成了几类更接近真实体验的指标：Performance Methodology 里也明确解释了这些定义。
你应该重点分清 4 个概念：
Time to First Token
更接近"用户有没有感觉卡住"。Time to First Answer Token
对 reasoning 模型尤其重要，因为它会把"thinking 时间"算进去。Output Speed
这是开始出答案以后，模型持续吐 token 的速度。End-to-End Response Time
这是对用户最直观的总耗时指标。
最佳实践：
- 聊天助手、Copilot、客服场景：优先看
TTFT和End-to-End Response Time。 - 长生成场景：优先看
Output Speed。 - reasoning 模型：一定同时看
Time to First Answer Token，否则你会低估"思考成本"。
尤其要注意，官方性能方法学说明里写得很清楚：站内默认速度基准已经偏向 10k input token 工作负载，而不是极短 prompt；另外性能结果通常展示过去 72 小时的 P50 中位数，而不是你在所有时间、所有地域都能拿到的固定 SLA。方法学说明
4. 比较 provider 时，不要只比价格，要比"价格下的速度"
很多人做 API 选型时只比模型，不比 provider。其实同一个模型，不同 provider 的体验差异可能非常大。
Artificial Analysis 的一个高价值点，是它会展示某些模型在不同 provider 上的 Output Speed vs Price、Pricing、Speed Over Time 等对比。首页和模型页都能看到这类 provider competition 入口。首页
最佳用法：
- 先确定模型本体，比如你已经决定要用
gpt-oss-120b或某个热门闭源模型。 - 再看不同 provider 的速度 / 价格散点图。
- 如果是生产服务，再结合你自己的地域、稳定性、速率限制、账号策略做二次验证。
这一步尤其适合：
- 想从大厂官方 API 切到更快更便宜的推理云。
- 想做多 provider 容灾。
- 想比较 serverless API 和自建部署之间的边界点。
5. 做开源模型或本地部署判断时，把它当"外部基线"，不要当"本地实测替代品"
对于你这种做推理部署、脚本和性能测试的仓库来说，Artificial Analysis 最好的定位不是替代你自己的 benchmark，而是做 外部基线和市场参照系。
建议这样配合使用：
- 先用 Models 总览 确定一个开源模型大致处于什么能力带。
- 看它的
Open Weights、Openness Index、参数规模、active parameters、上下文长度。 - 如果它在站内表现不错，再回到你本地用真实框架去测，比如
vLLM、SGLang、llama.cpp、TensorRT-LLM。 - 把站内结果当"市场上公开可比较的标准线"，把你自己的结果当"这套硬件和这套 serving stack 下的真实线"。
这能避免两个常见问题：
- 只看厂商自报 benchmark。
- 只看自己本地一次跑出来的数据，却不知道它在行业里处于什么位置。
6. 做硬件采购和部署规划时，优先看硬件页而不是语言模型主榜
Hardware Benchmarks 和 AA-AgentPerf 方法学 是很多人会忽略、但其实很重要的部分。
为什么重要：
- 模型榜告诉你"模型大概有多强"。
- 硬件榜告诉你"某套系统在真实 agent 负载下能扛多少并发、每用户速度还能不能达标"。
AA-AgentPerf 的思路很值得重视：
- 它强调真实 agent 轨迹，而不是纯合成 prompt。
- 它看的是在指定 SLO 下，系统最多能支持多少并发用户。
- 它会按
per accelerator、per kW、per $/hr、per rack归一化比较。
这意味着它更接近"部署经济学"，而不是单纯的实验室峰值吞吐。硬件页、AA-AgentPerf 方法学
如果你在做下面这些事，这一页特别有价值：
- 预算有限，想比较 H100 / H200 / B200 / MI300X 这一类方案。
- 想比较
vLLM、TensorRT-LLM等 serving stack 的真实差异。 - 想向老板解释"为什么不能只看显卡单价，还要看并发 SLO 和每美元吞吐"。
如何正确理解它最重要的几个指标
Intelligence Index
这是它最核心、也最容易被误读的指标。
根据 Intelligence Benchmarking Methodology，它当前把多个评测组合成一个综合指数，覆盖 agentic workflow、代码、长上下文、知识可靠性、科学推理等维度，并且把四大类各赋 25% 权重。
正确理解方式：
- 这是一个很有价值的综合参考。
- 它适合做"第一层筛选"。
- 它不等于你业务的真实 KPI。
尤其要注意几个边界：
- 它是
text-only、English为主的综合评测，不应直接外推成中文、多模态、垂类行业表现。 - 它有统计意义上的置信区间，但单个子评测的波动可能比总分更大。
- 它已经比单一 benchmark 强很多，但仍然不能替代你的业务任务验证。
AA-Omniscience
这个指标非常适合用来辅助判断"知识可靠性"和"乱猜倾向"。
它不是简单看答对率，而是把准确率和 hallucination 惩罚结合起来。这对搜索问答、事实问答、研究助手、企业知识助手都很有意义。首页说明
如果你的产品不能容忍一本正经地胡说八道，这个维度应该被你显式加入筛选流程。
Context Window
正确理解是：
- 大上下文窗口不等于强长上下文推理。
- 能塞进 1M token，不代表它能高质量地读懂 1M token。
所以看 Context Window 时，最好和 AA-LCR 这类长上下文 reasoning 评测一起看。Models 页、Intelligence 方法学
Openness Index
这部分特别适合开源模型研究、企业采购、合规团队和平台团队。
它不仅看"权重给不给"，还看方法、预训练数据、后训练数据等透明度维度。对很多企业来说，"能不能商用""能不能迁移""未来会不会被平台锁死"，比单次 benchmark 分数更重要。首页、Models 页
这个网站最容易被误读的地方
-
不要把综合分当业务分。
站内综合分很有价值，但你自己的任务分布、语言分布、调用方式可能完全不同。
-
不要忽略 prompt 长度。
它的性能方法学明确区分了 1k、10k、100k 输入长度。长 prompt 下的 TTFT 和速度会明显不同。Performance Methodology
-
不要忽略 reasoning token 成本。
reasoning 模型有时"看起来很强"，但思考 token、首答延迟和最终成本会把产品体验拉开。
-
不要忽略 tokenizer 差异。
官方方法学也提到，不同 tokenizer 会影响 token 数量和价格可比性，所以"每百万 token 价格"不是绝对公平的统一货币。Performance Methodology
-
不要把网站数据当你本地部署结果。
网站很多性能数据代表首方 API 或中位 provider 表现，不等于你的地域、你的机房、你的部署框架、你的量化方式。
-
不要把 open weights 等同于完全自由。
有些模型虽然开放权重，但可能带有商业使用限制；站内也会把这类模型单独标注出来。首页
我最推荐的 4 套实战工作流
工作流 A：给产品找默认大模型
- 先用 Model Recommender 做初筛。
- 到 Models 看
Intelligence vs Price。 - 再看
Latency和End-to-End Response Time。 - 最终保留 2 到 4 个候选，自己做真实 prompt A/B 测试。
适合：聊天助手、知识库问答、Copilot、工作流 Agent。
工作流 B：给 API 网关做多 provider 备选
- 先定模型。
- 再看 provider 之间的
speed / price差异。 - 结合地域、稳定性、配额、故障切换策略做内部路由规则。
适合：平台团队、基础设施团队、云成本优化。
工作流 C：给开源部署做外部定位
- 在站内看模型能力带和价格带。
- 看 active parameters、上下文、开放性。
- 回到本地用你的脚本做显存、吞吐、并发、TTFT 真实验证。
适合：本地部署、自建推理平台、开源模型研究。
工作流 D：给老板或客户做采购解释
- 先展示模型能力榜。
- 再展示硬件页或 provider 页。
- 最后把结论落到"每美元吞吐、每机柜吞吐、目标 SLO 下的并发用户数"。
适合：预算评审、硬件采购、客户方案汇报。
高阶用法：把它接进你自己的数据流
Artificial Analysis 还提供了 免费 API。这意味着你可以把它从"手工查网站"，升级成"内部数据源"。
比较好的用法有：
- 每天自动抓取模型的 intelligence、price、TTFT、output speed，做内部趋势看板。
- 给你的模型路由器增加外部基准字段。
- 把 open weights 模型的横向对比做成自己的候选池。
- 给博客、报告或投研笔记做半自动更新。
使用时要注意两点：
- 官方免费 API 有请求频率限制，文档当前写的是
1,000 requests/day。API Reference - API key 不要放到前端代码里，最好只放服务端并缓存结果。这一点官方文档也有明确提醒。API Reference
对这个仓库最有价值的使用姿势
结合你这个项目本身偏向模型部署、脚本化运行、吞吐与并发测试，我最建议把 Artificial Analysis 当成下面这三样东西：
-
外部市场基线
先知道一个模型在行业公开比较里处于什么段位。
-
选题雷达
当一个模型在站内突然进入高性价比象限，或者某家 provider 的速度 / 价格出现明显优势时，就值得进入你本地测试清单。
-
汇报语言转换器
你本地跑出来的是
TPS / TTFT / 并发 / 显存，网站能帮你把这些结果映射到更容易对外沟通的话语体系，比如能力-成本-时延-开放性-硬件经济性。
如果你后续要持续写模型部署总结、对比报告、release radar 或 provider 观察，这个站非常适合作为长期参考坐标系。
最后总结
Artificial Analysis 的最佳使用方式，不是"看谁排第一"，而是把它当成一套 多维 AI 选型操作系统：
- 用
Models做模型初筛。 - 用
Recommender快速生成 shortlist。 - 用
Methodology判断结论能不能外推到你的业务。 - 用
Provider Performance看同模型不同服务商差异。 - 用
Hardware Benchmarks看真实部署经济学。 - 用
Arena看图像、视频、语音的主观偏好表现。 - 用
API把它接进你自己的分析流程。
如果只保留一句建议，那就是：
先用它缩小范围，再用你自己的真实 workload 做最后裁决。