포스트

ml-intern에 H100 300회 루프를 맡겨도 될까: 170K Compaction과 비용 상한

ml-intern에 포스트 트레이닝을 맡기려면 먼저 최대 GPU 시간, API 비용, 반복 횟수와 목표 지표를 고정해야 하며, 300회 자율 루프를 기본값처럼 열어 두면 안 됩니다. 첫 파일럿은 사람이 재현한 baseline에서 hyperparameter 하나만 바꾸고, 개선보다 먼저 budget 중단, artifact, 복구가 정확한지 확인해야 합니다.

코딩 Agent와 다른 점은 실험을 실행한다는 것이다

원문은 ml-intern을 Hugging Face의 smolagents 위에서 움직이는 ML 연구 루프로 설명합니다. 논문과 인용 관계를 찾고, 데이터 품질을 살펴보고, 학습 스크립트를 만든 뒤 Hugging Face Jobs에 GPU 작업을 제출하고 Trackio 지표를 읽어 다음 가설을 정하는 흐름입니다.

일반 코딩 에이전트가 파일 수정과 테스트에서 끝난다면, 이 구조는 학습 Job이라는 비싸고 오래 걸리는 외부 효과를 만듭니다. 잘못된 코드 한 번은 즉시 실패하지만 잘못된 학습 가설은 GPU를 몇 시간 사용한 뒤에야 틀렸음을 알 수 있습니다. 따라서 자율성보다 실험 예산과 중단 조건이 먼저입니다.

원문은 ContextManager와 ToolRouter를 두 축으로 소개합니다. 전자는 긴 실험 기록에서 중요한 상태를 유지하고, 후자는 논문 검색, 데이터 검사, Job 실행, 평가 도구를 선택합니다. 이 이름과 기능은 해당 시점의 설명으로 보고 설치한 저장소 구조와 다시 대조해야 합니다.

170K Auto-Compaction은 기억 보장이 아니다

훈련 로그, 손실 곡선과 논문 내용을 모두 대화에 누적하면 컨텍스트가 빠르게 찹니다. 원문에 나온 170K 토큰 auto-compaction은 best reward, loss curve, hyperparameters와 citation context 같은 핵심 값을 남기고 나머지를 압축하려는 장치입니다.

압축은 손실 없는 저장이 아닙니다. 실패 직전의 드문 경고나 데이터 전처리 차이가 요약에서 사라지면 에이전트는 같은 잘못된 가설을 다시 시도할 수 있습니다. 전체 원시 로그와 생성 스크립트는 별도 아티팩트로 보존하고, 압축된 상태에는 원본 Job과 커밋을 가리키는 식별자가 있어야 합니다.

최대 300회 반복도 “300번 동안 정확히 기억한다”는 뜻이 아닙니다. 반복할수록 상태 요약의 누락, 모델 비용과 실험 간 비교 불일치가 누적될 수 있으므로 단계별 검토 지점을 둬야 합니다.

experiment ledger에는 parent experiment, code, data, checkpoint hash, hyperparameter diff, random seed, hardware, wall, GPU 시간과 평가 결과를 둡니다. 압축된 context는 이 ledger의 ID만 요약하고 수치가 충돌하면 원본 artifact를 진실의 원천으로 사용합니다. 실패 Job과 중단 이유도 최고 점수만큼 중요합니다.

Gate확인할 값중단 조건
제출 전diff, data, 예상 GPU 시간승인 없는 새 data, code, 큰 Job
실행 중loss, reward, NaN, GPU 시간collapse, stall, 누적 budget 초과
평가고정, holdout, contamination 검사최소 개선 미달, 회귀 발생
다음 실험새 가설과 이전 결과 차이같은 실패, 설정 반복

JSON과 Python은 실제 설정 파일이 아니다

원문의 ToolRouter JSON에는 주석이 들어가 있어 표준 JSON으로 파싱되지 않으며, reasoning_engine, 도구 이름과 max_iterations가 실제 ml-intern 설정 스키마인지 확인되지 않았습니다. 이어지는 Python도 trackio_evaluator, detect_reward_collapse, agent.generate_script와 Job launcher가 정의되지 않은 의사 코드입니다.

이 두 조각은 “평가 읽기 → 붕괴 탐지 → 논문 검색 → 새 스크립트 → GPU Job → 목표 확인” 순서를 보여 주는 개념도입니다. 완전한 실행법으로 사용해서는 안 됩니다. 원문의 uv tool install -e . 역시 이미 저장소를 받은 개발 환경에서 editable install을 시도하는 한 단계일 뿐, 인증, GPU Job 권한, 모델과 데이터 준비를 포함하지 않습니다.

실제 도입에서는 읽기 전용 논문 검색부터 시작하고, Job 제출 도구는 승인 없이는 실행되지 않게 분리하는 편이 안전합니다.

벤치마크 숫자는 재현 조건과 함께 본다

원문은 PostTrainBench에서 Qwen3-1.7B의 GPQA 점수가 약 10%에서 32%로 올랐고 Claude Code의 22.99%보다 높았다고 소개합니다. 단일 H100과 10시간이라는 조건도 함께 제시됩니다. 이 결과를 다른 모델, 데이터, 업무에서의 향상 보장으로 확대할 수는 없습니다.

재현할 때는 시작 체크포인트, 데이터와 평가 버전, 총 GPU 시간, 실패한 Job까지 포함한 비용을 고정해야 합니다. 최종 최고 점수만 비교하면 더 많은 실험을 시도한 시스템이 유리하고, 실제 운영 예산을 설명하지 못합니다. 에이전트가 만든 합성 데이터가 평가 문제와 겹치지 않는지도 점검해야 합니다.

한 번의 제한된 ablation으로 시작한다

첫 파일럿은 이미 사람이 재현한 훈련 스크립트에서 하이퍼파라미터 한 개만 바꾸는 작업이면 충분합니다. 최대 반복을 작게 두고 Job별 시간과 누적 비용, 개선 최소값을 넘지 못했을 때의 중단 규칙을 설정하십시오. 새 데이터 생성이나 논문 기반 코드 재작성은 그 이후 단계입니다.

HF Hub, Papers, Jobs와 Trackio의 결합은 흐름을 빠르게 만들 수 있지만, 온프레미스 Slurm이나 다른 클라우드가 기준이라면 ToolRouter 교체 비용이 큽니다. 생성된 GRPO 스크립트도 결국 사람이 유지해야 합니다. 성공 기준은 “인턴처럼 알아서 했다”가 아니라, 같은 예산 안에서 사람이 검토할 수 있는 실험 기록과 재현 가능한 개선을 만들었는가입니다.

파일럿 뒤에는 사람이 만든 search plan과 Agent plan을 동일 Job 수로 비교합니다. 최고 점수뿐 아니라 평균 개선, 실패, 중복 experiment, GPU hour당 개선과 사람이 review한 시간을 기록합니다. Agent가 더 많은 기회를 사용해 최고값만 높였다면 효율 개선으로 볼 수 없습니다.

중단된 Job의 checkpoint를 재사용할 때는 optimizer, scheduler와 data 순서까지 맞는지 확인합니다. weight만 이어 받아 다른 조건으로 실행하면 같은 experiment의 재개가 아니라 새 실험이므로 별도 ID로 기록해야 결과 비교가 왜곡되지 않습니다.

자동 실험의 성패는 결과 계보로 판단한다

각 실험은 부모 실험 ID, 변경한 가설, 실제 diff, 데이터와 코드 revision, 환경 image, seed, 평가 결과를 한 계보로 연결해야 합니다. 에이전트의 대화 요약은 탐색 과정을 읽는 데는 유용하지만 재현 기록을 대신하지 못합니다. 논문에서 가져온 아이디어도 원문 위치와 구현상 해석을 분리해 남겨야, 점수가 변했을 때 논문 재현인지 새로운 변형인지 설명할 수 있습니다.

검수자는 최고 점수를 낸 run뿐 아니라 실패와 중단된 run도 볼 수 있어야 합니다. 같은 오류를 반복하거나 사소한 변화로 GPU 예산을 소모하면 자동화의 탐색 효율이 낮다는 뜻입니다. 누적 예산, 동시에 실행할 Job 수, 데이터 생성량을 executor에서 강제하고, 임계값을 넘은 확장은 사람이 새 가설과 예상 비용을 승인한 뒤에만 열어야 합니다.

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

자주 묻는 질문

170K auto-compaction이면 300회 실험의 세부 정보를 잃지 않나요?

아닙니다. 압축은 정보 손실이 있어 원본 log, script, data, job ID를 별도 보존하고 요약에서 다시 열 수 있게 해야 합니다.

benchmark 점수가 오르면 Agent의 학습 전략이 좋아졌다고 볼 수 있나요?

holdout 오염, 더 많은 실험 기회와 총 GPU 예산을 통제하고 같은 시작 checkpoint, data, 평가에서 재현해야 판단할 수 있습니다.

ml-intern의 Job 실행 권한은 언제 열어야 하나요?

읽기 전용 탐색과 script 제안, 작은 dry run을 검토한 뒤 Job별, 누적 GPU 시간과 비용 상한이 강제될 때 제한적으로 엽니다.

참고 자료:

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1 —

←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    9개 장 14 분읽는 시간