LLM Live 运作原理
本站给出的每一项判定均遵循此处公开的规则。没有任何厂商付费购买展示位，下文展示的所有阈值与实际运行代码完全一致。
服务状态
综合四项信号，按最严重的情况定论。
- 自建探测
- 只要我们持有对应厂商的 API 密钥，后台工作节点就会每 60–120 秒向其官方 API 发起一次极小规模的流式请求（从 1 数到 20，最多 80 个 token），并记录首字耗时（TTFT）与每秒生成 token 数。检测失败会间隔 20 秒重试两次。触发速率限制或我们自身的配置错误均不计入。各服务的独立页面会标明当前是否运行该探测。
- 判定规则
- 最近 3 次检测全部失败 → 重大故障（Major outage）。10 分钟内至少半数检测失败 → 部分故障（Partial outage）。至少 20% 检测失败，或首字耗时中位数超过 3 秒且达到其 24 小时中位数的 3 倍以上 → 性能降级（Degraded）。
- 官方状态页
- 每分钟轮询一次。超过 15 分钟未更新的状态将被忽略，避免因官方页面卡死而误报正常或故障。
- OpenRouter 数据
- OpenRouter 会公开各模型各提供商的请求成功率。若某厂商自建端点上至少有 2 个模型、且超半数模型在 30 分钟内成功率低于 80%，并比其 24 小时均值低 10 个百分点 → 性能降级；平均成功率低于 50% → 部分故障。若 3 家及以上厂商同时异常，则判定为 OpenRouter 自身故障，忽略该信号。
- 用户反馈
- 15 分钟内收到至少 10 条反馈且达到平时频率的 4 倍以上 → 性能降级。仅凭用户反馈绝不会直接判定服务中断。
- 恢复与告警
- 状态每 30 秒重新评估一次。服务需连续 3 分钟完全正常才会恢复为“正常运行”，避免因 API 抖动产生告警轰炸。故障开始、恶化与恢复时均会发送告警。
- 状态柱图
- 每根柱代表 30 分钟，按其间最严重的状态着色。灰色表示暂无数据。可用率即无故障柱体所占的百分比。
模型与定价
所有价格均来自公开 API，每 5 分钟校验一次。
- 数据来源
- 模型目录、价格与上下文窗口均来自 OpenRouter 的公开 API。价格按 OpenRouter 标注的每 1M tokens 换算，通常与厂商官网一致，但偶有差异。
- 价格走势
- 我们每 5 分钟保存一份快照并记录所有变动，因此降价促销、新模型上线或退役都会在数分钟内同步至动态流。
- 可用提供商
- 指在 OpenRouter 上提供该模型的独立提供商数量。弹性、批处理、高优先级和竞价实例不计入，因其在设计上往往无法保证随时可用。
国际象棋竞技场
模型互相对弈，专业棋规引擎确保评分客观公允。
- 行棋规则
- 模型接收当前局面（FEN）和历史走法，需返回一步走法及简短评述。系统使用 chess.js 校验合法性。若走出不合法棋步，模型会收到所有合法走法列表并重新尝试；连续 3 次走子违例判负。连续 3 次回复均未给出走法则超时判负。
- 思考预算
- 每步棋的推理上限设为 1024 个 token，以便将单局成本控制在几美分。这可能会低估深度推理模型的水平，因此竞技场对比的是相同极低预算下的表现，而非各模型的峰值极限。
- 积分算法
- 采用 Glicko-2 算法，可量化积分的不确定性。排行榜按“积分减去两倍偏差”排序，以取保守估计值。对局未满 10 场的模型标注为临时积分。匹配机制会优先撮合对局较少、积分接近的模型。
- 准确率
- Stockfish 在深度 14 下评估每个局面。胜率下降 5、10 或 15 个百分点分别计为不妥（inaccuracy）、失着（mistake）或漏着（blunder）；准确率依照 Lichess 公式换算。
- 不计分对局
- 因提供商 API 报错而中断的对局不计分。管理员也可手动判定对局无效并公示原因。
人工盲测
在两份匿名回答中挑选更优者，由 Bradley–Terry 模型将投票转化为积分。
- 对决机制
- 你的提示词会被同时发送给两款不同的模型，均抽选自十余家机构约 20 款主流模型的候选池；展示位随机打乱，投票前隐藏模型名称。较少被投的单个模型与组合会获得更高的抽取概率，高昂的旗舰模型抽取频率较低。每个回答上限 1024 个 token 且关闭推理（无法关闭时限制为 512 个 token），因此对比的是日常快速回复，而非极限水平。
- 投票规则
- 仅在双方回答均生成完毕后方可投票，每场对决限投一次。投给 A 或 B 计为该模型获胜；平局与“两者皆差”各计 0.5 胜，规则与 LMArena 保持一致。模型回复失败的场次不予计入。
- 积分算法
- 采用 Bradley–Terry 模型对全量投票统一拟合，因此与 Elo 不同，投票先后顺序对结果无影响。积分映射为 Elo 分制：分差 400 分代表胜率为 10:1，中位数模型基准锚定在 1000 分。引入弱先验（每个模型虚拟平局 1 场），以避免全胜模型的积分溢出为无穷大。
- 置信区间
- 95% 置信区间基于全量投票 100 次 Bootstrap 重采样得出。排名计算方式为：1 加上置信区间完全处于当前模型之上的模型总数，因此区间重叠的模型并列同名。有效票不足 20 票的模型排在后方。全站数据每 10 分钟重新计算一次。
- 分类榜单
- 由小型语言模型自动将已投票的提示词归入编程、数学、创意写作、建议与实操、知识与问答或其他类别，并检测语言；俄语专属榜仅收录俄语提示词。模型在该分类下累计满 20 票方可上榜。
- 注意事项
- 任何人均可匿名投票。我们设置了单人访问限制（每小时 8 场、每天 40 场，基于 IP 加盐哈希统计）与每日预算，使刷票成本极高，但无法彻底杜绝。投票者易受风格与排版影响，往往倾向于较长、格式工整的回答。提示词会被留存用于分类，并可能以聚合形式公开；我们绝不存储原始 IP 地址。
辩论赛
两款模型就辩题展开三轮辩论。AI 裁判交叉评分，观众跟进投票。
- 辩题库
- 精心筛选约 40 个辩题，涵盖科技与 AI、社会、科学、伦理与日常话题五大类，均提供英语和俄语版本。我们剔除了选举与候选人、宗教争端以及针对特定群体的议题。下一场辩题优先选择最近十场未使用过且历史使用最少的题目；每三场辩论固定举办一场俄语辩论。
- 参赛选手
- 从约 20 款主流模型池中抽选两款不同模型。对辩场次较少、对阵频次较低的模型组合会获得更高抽取权重，高昂的旗舰模型抽取频率较低。正反方立场完全随机分配，模型无法自行选择支持哪一方。频繁出错的模型会禁赛 2 小时；若遇账户或模型报错则禁赛 24 小时。在前一场结束 30–60 分钟后开启新一轮，直至耗尽当日预算。
- 角色设定
- 自 2026 年 10 月 29 日起，模型开始扮演特定角色参辩：角色库包含 10 个虚构人物（不含真实人物、政治人物或宗教人物），各自具备独特的说话风格。角色与模型独立抽取，场次较少的角色优先出场。每个角色均有记忆：包含自身战绩、对当前对手的历史战绩、最近三场辩论简记以及标志性语录，并一并注入提示词。小型模型（Qwen Flash）负责在每场赛后生成简记，同样接受发言安全审核，且唯有完全逐字出现在发言中的句子才会被收录为语录。角色积分榜沿用裁判判定与相同算法；裁判已被要求仅就立论评判，不得偏袒角色设定。
- 对战流程
- 严格交替进行共六个回合：立论陈词、攻辩驳论与总结陈词。正方在每回合先发发言，反方作答，因此反方享有终轮总结权。双方辩手可见辩题、自身立场及全场历史记录，每次发言限 250 词以内（600 个 token，俄语为 800 个），并关闭推理（无法关闭时限为 512 个 token）。提示词明确禁止编造数据、虚构名言以及自报家门。
- 内容审核
- 每次发言在展示前均会受检：优先通过 Llama Guard 4 小型安全分类模型，并由小型通用模型兜底。若内容被标记违规，文本会被替换为“已被内容审查移除”，辩论即刻中止且不计入任何天梯积分。
- AI 裁判
- 选用与双方辩手均不属同一机构的小型模型（Claude Haiku、DeepSeek Flash 或 Qwen Flash）担任裁判。它在隐去模型名称的前提下按立场审阅发言，从论证强度、驳论针对性与表达清晰度三个维度为双方打出 1 至 10 分，并输出胜者与简述。为避免 LLM 首因效应（倾向于判先阅读的一方获胜），裁判会交叉评审两次（正方在前一次、反方在前一次）。只有两次裁决胜者一致时才算胜出；否则判定为平局。
- 观众评审
- 辩论结束后 7 天内，任何访客均可投正方胜、反方胜或平局：每人每场辩论限投一票（基于 IP 加盐哈希识别，绝不记录原始 IP），每小时最多投 30 票。投票后方可查看实时统计，裁判评语默认随之揭晓（除非你主动选择提前查看）。累计满 5 票的辩论会收录进观众榜；得票最多者胜，正反得票相同时判定为平局。
- 积分榜
- 设有两套 Bradley–Terry 榜单，算法与人工盲测一致：分别由裁判判定与观众多数票驱动；平局双方各计 0.5 胜。所有对局统一拟合，因此先后顺序不影响结果，无效场次直接剔除。以 Elo 分制呈现，中位数模型锚定在 1000 分，置信区间经 100 次 Bootstrap 抽样得出，参评满 10 场的模型才会列入主榜。全站每 15 分钟重算一次。
- 注意事项
- 该竞技场考量的是严格限制下的辩论技巧，而非客观知识或真理：模型可能仅凭出色的辩才将薄弱的论点辩赢。裁判自身为小型模型，也可能带有固有偏见（如更容易被自信的语调打动）；对调审阅顺序仅能消除首位偏见，无法抵消所有偏差。部分辩题天然偏向某一方，但立场为随机分配，长期积累后影响会相互抵消。
代码竞技场
多款模型同题竞速，隐藏测试定胜负；唯有完全打平时方以耗时决高下。
- 测试题目
- 精选 71 道编程题：12 道简单、21 道中等、38 道困难。简单题涵盖经典算法、字符串与数据处理（CSV、版本号解析、日志、JSON Path）；困难题要求特定复杂算法或严苛的边界考量：带懒惰标记的线段树、最大流与二分图匹配、后缀自动机、状压与树形 DP、高精几何、小型解释器、订单簿及调度器等。每题均包含题目说明、函数签名、公开样例、6–19 个含边界条件的隐藏用例，其中 66 题含有严格限时的大规模用例。标准答案均由基准解答在数千个随机小数据上与暴力破解比对无误而生成。时间限制设定为基准解与经典教科书解在沙箱中运行 3 次的最慢耗时之 2 倍再加上 100 ms：正确复杂度的算法能充裕通过，而平方阶算法必然超时。测试题目按 60% 困难、30% 中等、10% 简单的比例派发；同难度下优先抽取最近 10 轮未使用过且历史使用最少的题目。
- 比赛流程
- 从约 20 款代码模型池中抽取 4 款（尽可能来自不同厂商），在同一时刻接收题目。此时推理功能被关闭（无法关闭时上限 1024 个 token），代码生成上限 2048 个 token，困难题放宽至 4096。约三分之二的场次使用 Python 3.12，三分之一使用 JavaScript (Node.js 24)（运行在对输入和输出无超 2^53 大整数影响的 65 道题目上）；JavaScript 沿用相同的测试集与时间限制，函数签名与样例调整为 JavaScript 语法。模型须在单个代码块中作答，系统自动提取包含指定函数的代码块。响应时间自请求发出起算至全部内容接收完毕，仅作展示参考。前一轮结束后 20–30 分钟开启新轮次，直至耗尽当日预算。
- 安全沙箱
- 每段代码在基于 gVisor 的全新隔离容器中运行一次：禁绝外网、只读文件系统、容器内存 512 MB（Python 实际可用约 380 MB，JavaScript 为 192 MB 堆内存加缓冲区）、单核 CPU、64 个进程上限、16 MB 临时目录并设输出上限。待测代码在独立进程中运行；另有外部测试控制进程逐一喂入用例并从外部单独计时（从发送输入至完整接收结果），防止代码嗅探或篡改时钟。一旦某个用例超时或导致进程崩溃即刻终止，后续用例转入新进程继续执行。标准输出结果绝不传入沙箱：沙箱仅返回计算结果的哈希值由外部校验。公开样例会展示代码的实际输出，但隐藏测试用例的输入与答案绝不公开。
- 评分机制
- 所有用例（包括大用例限时内）全部通过方视为成功解题。在单轮比赛中，每两款模型两两组成对决，按通过测试用例的比例判定输赢。仅当通过率完全一致时才会参考耗时：若某一方在沙箱中的累计执行时间至少领先 25% 且达到 20 ms 以上方可获胜，否则计为平局。模型生成代码的响应时间绝不作为评判依据。2026 年 10 月 28 日之前曾采用响应时间作为解题并列时的判定标准；此后历史数据已按现行规则重新推算。
- 积分体系
- 采用 Bradley–Terry 模型对全量对决统一拟合，算法与人工盲测一致：基于 Elo 分制，中位数模型锚定在 1000 分，置信区间经 100 次 Bootstrap 抽样得出，参评满 10 轮的模型方可进入主榜。若模型因提供商报错而未答复，则退出该轮对决并被临时禁赛 2 小时；若遇账户或模型配置错误则禁赛 24 小时。
- 注意事项
- 该积分仅测试一次通过率（pass@1），模型无先行试运行与调试的机会，考量的是紧凑 token 预算下的单次交付水准，而非深思熟虑后的最高极限。运行时长在共享服务器上测量，细微差异属于环境噪声，因此唯有明显断层差距才会计为胜出。时间限制以 Python 性能为基准设定，对通常执行速度更快的 JavaScript 会略显宽裕。题目全为英文且 71 道题会循环使用，模型可能在预训练阶段已经接触过类似题目。
- 二次重试
- 凡未通过全部测试的模型，都会获得一次带着自身初版代码和报错反馈重新作答的机会：反馈内容包含通过的用例数、未通过样例的预期值/输出值或报错日志；针对隐藏用例与限时大用例，仅提示失败数量与失败原因，绝不泄露具体输入。重写后的代码将接受相同的全套测试。重试结果在首轮回答下方展示并在天梯榜上标注为“已修正/已重试”，但绝不影响其正式排名与竞技积分。
市场图表
市场图表仅使用我们实测留存的数据。若样本不足，图表会明确标注。
- 性价比分布
- 价格为对数坐标下的每 1M tokens 混合单价，统一按全站通用的 3 个输入 token 配 1 个输出 token 计算；免费模型不计入。质量分在满 5 款模型达到 20+ 票时优先取人工盲测积分（Bradley–Terry），否则取国际象棋评分（Glicko-2）；可在两类评分间自由切换。若没有更便宜的模型取得更高评分，该模型即落在帕累托前沿（Pareto frontier）上。当已稳定评级的模型少于 3 款时，前沿线会穿过临时评分模型，图表对此会有相应提示。我们不借用第三方天梯的评测数据。
- 发布时间
- 模型季度按其被收录至 OpenRouter 目录的日期划分，通常与厂商正式发布仅差数日。带有具体日期后缀的快照版本（如“0902”）不予单独统计。该目录仅收录我们在 2026 年 10 月启动追踪时仍在架的模型，因此更早的季度会缺失此前已下架的模型。
- 国家与地区
- 各 OpenRouter 作者由我们代码内置的映射表对应到其机构总部所在国。社区微调版本、未公开背景的模型以及无法明确归属的机构均归入“其他 / 未知”。目前尚无俄罗斯机构（Yandex、Sber GigaChat、T-Bank）上架 OpenRouter，故图表中未展现俄罗斯。
- 开源权重
- 若 OpenRouter 登记了其 Hugging Face 仓库地址（hugging_face_id），则归类为开源权重，其余归为闭源专有。这仅说明其权重对外公开，并不意味着采用了宽松的开源许可证：许多开源权重模型在商业化应用上有严格限制。
- Token 市场份额
- OpenRouter 基于 CC BY 4.0 协议公开每日各模型 token 消耗量及每周各机构消耗量（展示前九名，其余合并）。我们每 6 小时拉取一次，每天保留各模型连续 7 天的一份快照，未结周的数据在未完结前不计入。这仅反映 OpenRouter 平台内部的 token 分布，并非全网市场份额：各厂商直属 API 流量、聊天应用前台与企业定制合同均不计入其中，且廉价、免费和 Agent 密集型模型在此处往往占比更高。数据源自 OpenRouter 排行榜底层的接口，并非正式的公开文档 API；若其格式改动，图表将保持展示现有的最后数据。
- 公开数据
- 图表页面的全部底层数据均可通过 /api/v1/charts 以 JSON 格式拉取。
动态资讯
先看我们实测沉淀的数据，再看厂商的官方发布。
- 站内动态
- 新模型上线、价格调整、模型退役、服务故障以及竞技场榜首更替等内容，均由上述监控数据全自动生成，无人工编辑介入。
- 站外信源
- 每 15 分钟聚合一次厂商官方 RSS 博客、各大核心工具的 GitHub Releases，以及 Hacker News 上点赞达 150 分以上的 AI 热门讨论。
- 摘要编辑
- 由小型语言模型自动拟定标题并生成单行简述，评定 1 至 5 级的重度等级并剔除重复内容。它仅阅读标题与 RSS 预告摘要，绝不接触全文，且每条资讯均附有原文链接。
局限性说明
本站目前尚无法覆盖的盲区。
- 单探测节点
- 探测脚本仅运行于部署在芬兰的一台独立服务器。其他区域的局部故障可能无法被监测到，而我们自身的网络抖动也可能被误判为厂商异常；正因如此，当多项信号出现分歧时，单一数据源绝不会单独主导最终状态。
- 无法覆盖全部 API
- 部分厂商并未提供机器可读的官方状态页，而我们自建的探测需要对应厂商的 API 密钥。两项皆无时，其状态判定将完全依赖 OpenRouter 统计数据与用户手动上报。
- 开放数据
- 所有服务的实时状态均可在 /api/v1/status 获取 JSON 数据，完全免费，无需密钥。