摘要
1) 一句话总结 Frontier-CS 是一个包含 240 个开放式计算机科学问题的连续评分基准测试，其底层评估架构通过哈希恢复机制、按资源分组的集群和固定的运行环境，解决了大模型时代异构硬件规模化和确定性评估的难题。
2) 核心要点
- 基准规模与赛道：包含 240 个连续评分的开放式问题，分为算法赛道（172 题，需 C++ 与 CPU）和研究赛道（68 题，需 Python 与 GPU/特定环境）。
- 当前基准得分：目前最佳模型在研究任务上得分为 46.55，而人类专家在算法任务上得分为 86.99。
- 庞大的评估工作量：由于非二元评分且依赖特定硬件，每个评估周期（7 个模型 × 240 个问题 × 5 轮）需执行高达 8400 次评估。
- 双层评估架构：系统分为供本地迭代的
SingleEvaluator（基于 Docker）和用于云端规模化运行的BatchEvaluator（基于 SkyPilot），两者底层运行器共享，确保分数可比。 - 基于哈希的恢复机制：通过记录解决方案和问题目录的 SHA 哈希值，系统在批量运行时仅重新评估发生变化的输入，避免算力浪费。
- 按资源分组的集群池：系统根据配置文件（
config.yaml）中的资源签名（如 A100 GPU 或 16 核 c7i.4xlarge 实例），将任务分配到专属的 SkyPilot 集群池，实现异构硬件的高效调度。 - 环境固定与确定性：通过 Docker 镜像和 AMI 锁定操作系统、驱动、库以及硬件规格，确保对延迟敏感的评分具有绝对的确定性；任何环境变化都会导致哈希改变并自动作废旧分数。
- 生成与评估解耦：评估流水线仅接收纯源码文件，并在无网络、无法读取测试用例的隔离容器中运行，确保评分过程与模型无关且防篡改。
- 自动化批量流程：每周 CI 任务自动执行发现配对、检查哈希、资源分组、创建集群、分发任务及记录结果的完整流水线。
3) 风险与不足
- 奖励作弊（Reward Hacking）风险：随着未来智能体（Agent）提交的引入，智能体可能会过度拟合或针对评分工具作弊（如记住测试集访问模式并硬编码查找表），而非真正学习解决问题。
- 成本模型失效风险：智能体工作流要求 GPU 集群在智能体思考和调用 API 时保持运行，导致 API 延迟与 GPU 闲置相互交织，目前尚无完美的协同调度解决方案。
正文
Frontier-CS 是一个包含 240 个开放式计算机科学（CS）问题的开源基准测试，采用连续评分机制。本文将介绍该排行榜背后的评估架构：基于哈希的恢复机制、按资源分组的集群、固定的运行环境，以及未来智能体（Agent）提交所面临的挑战。
在我们的 1.0 版本中，引入了涵盖算法竞赛和系统研究的 240 个开放式问题。最好的模型在研究任务上得分为 46.55，而人类专家在算法任务上得分为 86.99。这些分数是如何产生的？为什么值得信任？对于开放式的 CS 问题来说，评估往往比生成更难。本文将揭秘模型编写出解决方案后、分数出现在排行榜前，系统究竟经历了什么。
为什么评估如此困难？
传统的代码基准测试（如 LiveCodeBench、SWE-bench Verified 或 Terminal-Bench）评估方式很简单：运行代码、检查输出、得出通过或失败的结论。这种二元评估不依赖于你所使用的硬件。
但 Frontier-CS 不同，我们的问题是开放式且连续评分的。无论是优化 CUDA 内核以达到最快速度、设计最小化未命中率的缓存淘汰策略，还是实现跨核心扩展的并行排序，都没有唯一的标准答案，只有从“无法编译”到“超越参考实现”的评分范围。
评估单个问题需要配置特定的硬件、安装特定依赖项、运行评分工具并收集结果。如果乘以 7 个模型、240 个问题和每次 5 轮运行，每个周期就是 8400 次评估。而每当模型提供商发布更新时，新的周期就会开始。
240 个各不相同的问题
这 240 个问题分为两个评估需求截然不同的赛道：
- 算法赛道（172 个问题）：C++ 解决方案，由 go-judge 服务器根据自定义评分函数和测试用例进行评判，仅需 CPU 即可运行。
- 研究赛道（68 个问题，127 个评估指标）：Python 解决方案，可能需要 GPU、特定的 CUDA 版本或通过
uv安装的自定义 Python 包。单个问题的评估可能耗时长达 15 分钟。
CUDA 内核优化问题需要 A100 显卡，而算法问题只需要 CPU 和 C++ 编译器。你不能在相同的环境配置下运行它们。为所有任务配置昂贵的 GPU 集群会浪费资金，而把所有任务塞进同一台机器则会浪费时间甚至导致运行失败。
我们需要一个能够自动处理这种异构性、持续运行，并在数月的排行榜更新中产生可信分数的评估系统。
架构简介
我们的系统分为两层：SingleEvaluator 处理单次运行（供贡献者在本地迭代并快速获取分数）；BatchEvaluator 处理规模化运行（每周的 CI 任务，评估所有模型的所有问题）。两者底层共享相同的运行器，因此通过本地 Docker 产生的分数与云端 SkyPilot 产生的分数具有完全的可比性。
真正核心的挑战在于，如何在大规模下可靠地实现这一点，以及为什么这些问题是大语言模型（LLM）评估开放式任务时所特有的。
LLM 时代的四大挑战
1. 持续评估而非一次性测试
学术基准通常只为发表论文评估一次，但 Frontier-CS 是一个动态更新的排行榜。近期新模型层出不穷（如 Gemini 3.0 Pro、GPT 5.2 Thinking、Grok 4、DeepSeek 3.2，以及刚发布的 GPT-5.3-codex 和 Claude Opus 4.6）。每个新模型都需要在所有 240 个问题上进行评估，评估周期越来越短。
为此，我们构建了基于哈希的恢复机制。每个结果都会记录解决方案文件和问题目录的 SHA 哈希值。恢复批量任务时，系统会自动重新评估发生变化的输入，并保留未更改的结果。如果没有这个机制，我们要么浪费算力重新运行一切，要么面临发布过时分数的风险。
2. 规模化的异构硬件
单次批量运行可能包含需要 A100 GPU 的问题、需要特定 HPC 实例的问题（如我们的 N 体模拟问题需要 16 核的 c7i.4xlarge 实例以支持 OpenMP 并行），以及普通 CPU 问题。
我们通过按资源分组的集群池来解决这个问题。评估开始前，系统会根据每个问题配置文件（config.yaml）中的资源签名（云服务商、加速器、实例类型）对任务进行分组。每组获得专属的 SkyPilot 集群池，规模与该组问题数量成正比。CPU 任务运行在廉价实例上，GPU 任务运行在 GPU 实例上，互不干扰。
3. 评估的确定性
这是让基准测试维护者最头疼的问题。我们的问题对延迟非常敏感。代码的运行速度、吞吐量和硬件利用率决定了最终得分。如果将 A100 换成 H100，排行榜上的所有数据都会改变。
这使得我们的评估环境比最复杂的智能体基准测试还要复杂。我们的解决方案是固定一切并积极作废失效数据。每个问题的配置文件锁定了硬件规格、CUDA 版本和运行环境。执行环境本身通过 Docker 镜像和 AMI 固定，确保每次运行都使用完全相同的操作系统、驱动程序和库。
每个评估结果都带有解决方案和整个问题目录的哈希标签。一旦任何环节发生变化，哈希值就会改变，受影响的分数将自动作废并重新运行。我们不试图让分数跨环境兼容，而是通过不可变性来保证确定性，确保排行榜上的每一个有效分数都是在相同的固定条件下产生的。
4. 生成与评估解耦
许多 LLM 基准测试将生成和评估紧密耦合：调用 API、获取输出、立即评分。我们则刻意将它们解耦。
生成模块调用 LLM 并输出纯源码文件（.py 或 .cpp）。评估流水线不关心代码是哪个模型写的、用了什么提示词，或者尝试了多少次。每次评估都在隔离的容器或虚拟机中运行：解决方案之间互不可见，无法读取测试用例，也无法访问网络。这种设计使得评分过程与模型无关，且天然防篡改。
展望未来：智能体提交
上述清晰的边界划分也迫使我们面对一个社区刚刚开始探索的问题：当提交的不是文件，而是智能体（Agent）时会怎样？
前沿趋势正转向智能体工作流：模型读取问题、编写代码、运行、检查输出并迭代。生成过程本身产生了副作用：它读取环境、运行测试、在多轮对话中修改代码。“生成解决方案”和“评估解决方案”之间的界限开始模糊。
目前，我们的架构保持了严格的边界：无论解决方案是如何产生的，进入评估流水线的始终是一个源码文件。但随着智能体变得更强大，两大挑战正在逼近：
- 奖励作弊（Reward Hacking）：智能体会像人类工程师一样针对评分工具进行迭代优化。风险在于过度拟合。如果智能体发现了缓存轨迹中的时间局部性并据此设计策略，那是真正的学习；但如果它只是记住了测试集中的特定访问模式并硬编码了查找表，那就毫无意义。我们需要设计能真实反映问题的评估数据，让“针对测试工具作弊”和“真正解决问题”变得无法区分。
- 成本模型失效：目前，生成（API 调用）和评估（GPU 算力）是完全分离的。但对于智能体提交，GPU 集群必须在智能体思考和调用 API 时保持运行。这导致两种昂贵的资源同时被消耗，且在等待对方时处于闲置状态。这是一个 API 延迟与 GPU 利用率的协同调度问题，目前尚无完美的解决方案。
批量运行的流程
每周的 CI 任务运行时，系统会执行以下步骤：
- 发现配对：扫描解决方案目录，将每个文件与其对应的问题匹配。
- 检查哈希：对比哈希值，跳过未更改的配对，作废过时的结果。
- 按资源分组：根据资源签名划分任务。
- 创建集群池：按比例为每组配置 SkyPilot 集群。
- 分发任务：工作节点从共享队列中提取任务，获取匹配的集群进行评估，然后归还集群。
- 记录结果：保存结果及哈希值。中断的运行可以从断点精确恢复。
（算法赛道运行相同的流水线，只是使用 go-judge 服务器代替 SkyPilot 集群。）
架构带来的优势
- 排行榜保持真实：每个分数都带有环境哈希标签，自动捕获过时结果。失败会被记录在状态元数据中，而不是默默记为 0 分。
- 支持本地验证：贡献者可以通过 Docker 在本地运行与云端 CI 相同的评分逻辑。
- 新模型评估更快：基于哈希的恢复机制意味着只需评估新增或更改的配对，精准的集群池避免了算力浪费。
参与其中
如需了解完整的架构细节，请查看代码库中的 ARCHITECTURE.md。我们一直在寻找更多的问题加入下一个版本，并对更多的模型和智能体进行评估。欢迎通过 Discord 或电子邮件与我们联系，分享您的意见和反馈！如果您觉得 Frontier-CS 有用，请考虑在 GitHub 上为我们点亮 Star！