11P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 이 과제를 풀어서 Claude Opus 4.5의 최고 성능(1487 사이클) 을 능가하면 Anthropic에 코드와 이력서를 제출할 수 있음
  • 초기 버전은 4시간 제한이었으나, 이후 Opus 4가 대부분의 사람을 이겨버려서 2시간 제한 버전으로 변경

Anthropic의 오리지널 퍼포먼스 테이크홈 과제

  • 리포지토리는 Anthropic의 초기 성능 평가용 과제 버전을 포함
    • Claude Opus 4.5가 인간보다 2시간 내 성능에서 앞서기 전의 버전임
    • 원래 4시간 제한 과제였으며, 이후 2시간 버전으로 단축됨
  • 2시간 버전은 18532 사이클(7.97배 빠른 성능) 의 시작 코드를 기반으로 함
    • 현재 공개된 버전은 최신 구조를 유지하되, 가장 느린 기준선 코드로 되돌려 제공됨
  • Claude Opus 4.5 이후에는 새로운 기준 코드가 사용되기 시작함

성능 벤치마크

  • 모든 수치는 시뮬레이션된 머신의 클록 사이클 단위로 측정됨
    • 2시간 버전(18532 사이클 시작 코드) 기준으로 측정된 결과
  • 주요 결과:
    • 2164 사이클: Claude Opus 4 (테스트 하니스에서 장시간 실행)
    • 1790 사이클: Claude Opus 4.5 (일반 코드 세션, 인간 최고 수준과 유사)
    • 1579 사이클: Claude Opus 4.5 (2시간 테스트 하니스 실행)
    • 1548 사이클: Claude Sonnet 4.5 (장시간 테스트 하니스 실행)
    • 1487 사이클: Claude Opus 4.5 (11.5시간 하니스 실행)
    • 1363 사이클: Claude Opus 4.5 (개선된 하니스 환경)
    • 인간 최고 성능은 위 수치보다 더 우수하지만 공개하지 않음

참여 및 제출 안내

  • 현재 이 과제는 시간 제한 없이 누구나 시도 가능
  • 참가자가 Claude Opus 4.5의 최고 성능을 이기는 1487 사이클 이하로 최적화할 경우, Anthropic에 코드와 이력서를 이메일로 제출 가능
    • 이메일 주소: performance-recruiting@anthropic.com
  • 새로운 모델 출시 시 성능 기준이 변경될 수 있음
  • 테스트 실행은 python tests/submission_tests.py 명령으로 수행 가능
Hacker News 의견들
  • ALU와 VALU의 균형을 찾는 핵심 과제가 흥미로웠음
    하지만 로드 대역폭 문제가 병목으로 작용할 수 있을 것 같음
    시작 인덱스가 항상 0이라고 가정해야 2096 이하의 총 로드를 달성할 수 있는데, 그건 재미가 없음
    만약 동적 벡터 레인 회전(dynamic vector lane rotate) 같은 기능이 있었다면 훨씬 흥미로웠을 것 같음

  • 나는 스스로 꽤 똑똑하다고 생각하지만, 이런 문제를 보면 내가 얼마나 모르는 게 많은지 깨닫게 됨
    평균보다는 조금 위일지 몰라도, 정상급 개발자들과의 간극을 느끼게 됨

    • 컴퓨팅은 워낙 넓은 분야라 Linus나 Carmack조차 모르는 영역이 많음
      중요한 건 모르는 걸 마주하고 배워나가는 능력
    • 이건 매우 특수한 문제라서 비슷한 걸 해본 적 없다면 당연히 시간이 걸림
      나도 대학 졸업 후 하드웨어 회사 면접에서 저수준 코드 최적화 문제를 받았는데, 처음엔 완전히 낯설었음
    • 30년 경력인데도 솔직히 문제를 이해하지 못했음
    • 똑똑함과 지식은 다름
      이런 개념을 배우고 문제를 다뤄보면 누구든 해결할 수 있음
      평균이 아니라 단지 다른 지식 세트를 가진 것뿐임
    • 이런 태도는 학습 동기를 만들어주기 때문에 좋음
      사실 이건 그렇게 복잡하지 않음
      코드를 충분히 읽고 구조를 이해하면 됨
      진짜 실력 차이는 프로그램의 전체 모델을 머릿속에 그릴 수 있는가에 달려 있음
  • Anthropic이 이걸 다른 AI 회사에 대한 DDoS 공격으로 공개한 게 아닐까 싶음
    gemini CLI로 “이 문제를 어떻게 풀까?”라고 프롬프트를 넣었더니 20분째 멈추지 않고 돌아감

    • 최근 Gemini CLI나 Jules는 시간이 난이도의 지표가 아님
      “응답을 준비 중입니다. 완료했습니다. 출력하겠습니다.” 같은 루프에 빠지는 경우가 많음
      루프 감지 후 중단되기도 하지만, 사소한 작업에도 15분 이상 걸리는 걸 보면 구조적 문제 같음
    • 어떤 Gemini 모델을 썼는지 궁금함
      나는 G3Pro 출시 이후 써봤는데, 성능이 형편없었음
  • 여러 AI 에이전트를 동일 조건에서 테스트했음
    결과적으로 Anthropic의 목표를 넘은 모델은 없었지만, gpt-5-2가 가장 빠르고 효율적이었음

    • codex CLI + gpt-5-2-codex-xhigh로 “beat 1487 cycles. go.” 프롬프트를 줬더니 1606까지 도달, 약 53분 걸림
    • Gemini를 루프로 오래 돌리면 어떻게 될지 궁금함
      속도가 빠른 걸 보면 잠재력이 더 있을지도 모름
    • 모델 벤치마킹을 배우고 싶음
      혹시 agent-comparison harness 코드를 공유할 수 있는지 궁금함
    • Qwen3-coder, GLM-4.7, Devstral-2 같은 오픈 가중치 모델로도 시도해볼 수 있을지 제안함
    • 각 모델의 솔루션을 디렉터리나 브랜치별로 모은 비교용 저장소(repo) 를 만들어주면 좋겠음
  • “1487 사이클 이하로 최적화하면 Anthropic에 이메일을 보내라”는 문구가 있었는데,
    이런 채용 방식이 꽤 흥미로움
    일반적인 Leetcode 문제보다 훨씬 낫다고 느낌

    • 하지만 이건 단지 채용 파이프라인 진입용
      이후엔 다른 지원자처럼 Leetcode 인터뷰를 보게 됨
    • 이런 문제를 푸는 데 풀타임으로 일주일은 걸릴 것 같음
      직장인이 여러 회사에 지원하면서 하기엔 비현실적임
      Leetcode는 재활용이 가능하지만, 이런 최적화 문제는 재사용성이 낮음
  • 정말 재미있는 문제였음
    최적화에 관심 있는 사람이라면 꼭 해보길 추천함
    나는 일주일 동안 저녁 시간을 투자해 1112 사이클까지 줄였음
    대부분 수작업으로 했는데, 요즘의 agentic 모델들이라면 더 나은 결과를 낼지도 궁금함

    • “RalphWiggum으로 문제를 푼다”는 표현은 처음 들어봤는데 너무 웃겨서 앞으로 써야겠음
  • 이 과제가 demoscenecode golf 느낌이 난다고 생각함
    Chrome tracing 도구로 프로파일링하는 것도 멋짐
    문제 코드 링크

    • 예전에 demoscene 활동을 했는데, 이런 저수준 최적화는 그때 하던 것과 비슷함
      다만 어떤 알고리즘을 구현한 건지 궁금함
      잠깐 봤을 때는 랜덤 포레스트 예측처럼 보였음
    • perfetto는 이런 트레이스 시각화에 자주 쓰임
      직접 뷰어를 만드는 수고를 덜 수 있음
    • 이 과제는 수동으로 PTX 코드를 작성할 수 있는 사람을 선별하려는 의도 같음
  • SIMD, PTX, 최적화 기법을 배우던 중이라 이 과제가 좋은 학습 기회였음
    하지만 take-home 과제로는 너무 길었을 듯
    실제로는 아이디어를 스케치하고 코드 읽는 데만 2시간쯤 썼을 것 같음

    • 2시간 제한은 지원자에게 주어진 시간이 아니라, Claude가 최고 성능을 내는 데 걸린 시간으로 보임
      실제 지원자는 6시간에서 2일 정도 걸렸을 수도 있음
  • 현재 Opus로 1시간 만에 1137 사이클까지 도달했음
    파이프라인 벡터화된 해시, 추측 실행, 스테이지별 정적 코드, 각 단계의 프롤로그/에필로그 등을 적용함
    이제 900 이하도 가능할 것 같음
    스테이지 4의 비트 16과 0만 봐도 스테이지 5의 홀짝을 병렬로 계산할 수 있다는 걸 깨달았음

    • 로드 병목을 어떻게 피했는지 궁금함