허깅페이스가 9월 3일, 코딩용 모델을 수채화를 그릴 수 있도록 훈련한 전 과정을 공개했다. 전체 파이프라인 어디에도 확산 모델은 등장하지 않고, 이미지 생성 컴포넌트도 전혀 쓰이지 않는다. 모델이 내놓는 결과물은 자바스크립트 코드이며, 이 코드가 p5.brush라는 브러시 라이브러리를 호출해 실행하면 캔버스에 수채화 한 점이 남는 구조다.
작업자는 Sergio Paniego이며, 원래 아이디어는 Surya Narreddi가 냈다. 기반 모델로는 Qwen3.5-35B-A3B를 골랐고, TRL의 GRPO로 훈련했다. LoRA는 모든 선형 레이어에 걸었고, 학습률은 5e-5, 스케줄러는 constant_with_warmup을 썼다. 코드 실행과 렌더링, 채점은 모두 OpenEnv 환경 안에서 이뤄진다. 모델이 코드를 생성하면 환경이 이를 실행해 스크린샷을 찍고, 그 이미지를 채점기로 넘기는 방식이다.
보상에는 정답이 없다, 있는 건 참고 이미지 풀뿐
최근 몇 년간 대형 모델에 강화학습이 잘 먹힌 장면 대부분에는 자동으로 옳고 그름을 가릴 수 있는 종착점이 있었다. 수학 문제에는 정답이 있고 코딩 문제에는 유닛 테스트가 있다. 수채화에는 둘 다 없다. 이번 기록이 택한 해법은 '보기 좋은가'를 채점 가능한 두 가지 요소로 쪼개는 것이었다.
보상 함수는 총 네 항목으로 구성된다. 코드 실행 성공 여부가 0.05, 코드 길이가 0.05를 차지하고, 나머지 90%는 두 가지 미적 신호로 나뉜다. 하나는 쌍대 비교를 하는 심사 모델이고, 다른 하나는 HPSv3라는 사람 선호도 채점기다. 이 둘의 비중은 실험마다 서로 바뀌는데, judge-led 그룹은 심사 모델이 0.60·HPSv3가 0.30을 차지하고, hps-led 그룹은 반대다.
심사 모델의 판단 기준은 사람이 직접 채점한 178장짜리 참고 이미지 풀에서 나온다. 모델이 그림을 한 장 생성할 때마다 이 풀 속 작품과 비교된다. 이 풀은 동시에 '다양성'이 무엇인지도 규정한다. 블로그 원문에는 "The pool decides what counts as variety, the same way it decides what counts as quality(풀이 품질을 정의하는 것과 같은 방식으로 다양성도 정의한다)"라고 적혀 있다. 이 178장이 사실상 전체 훈련 목표의 상한선을 정하는 셈이다.
세 번의 실험, 세 개의 곡선
저자는 세 가지 비교 실험을 진행했다. HPSv3만으로 채점한 그룹은 60스텝을 돌렸고 평균 보상이 0.58에서 0.71로 올랐다. judge-led 그룹은 110스텝을 돌려 0.45에서 0.72로, hps-led 그룹도 같은 110스텝으로 0.57에서 0.82로 올라 세 그룹 중 시작점과 도착점 모두 가장 높았다.
상승 폭이 가장 큰 쪽은 judge-led의 0.27이었지만 시작점도 가장 낮았다. hps-led는 0.24 상승에 그쳤지만 0.82로 마무리됐다. 사람 선호도 채점기를 주역으로, 심사 모델을 보조로 두는 편이 그 반대보다 더 안정적이었다는 뜻이다. 심사 모델 없이 채점기만 쓴 그룹은 0.13 상승에 그쳐 세 그룹 중 가장 작았다. 쌍대 비교 단계가 실제로 추가 신호를 만들어낸다는 얘기이지, 있어도 그만 없어도 그만인 장식이 아니라는 뜻이다.
GPU 한 장, 34시간, 100달러 안팎
하드웨어 구성은 단순하다. 전 과정을 H200 한 장으로 돌렸다. 60스텝 실행에는 18시간, 110스텝 실행에는 34시간이 걸렸다. 렌더링은 CPU 사양 Space에서, HPSv3 채점은 a100-large 사양 Space에서 돌렸다.
현재 클라우드 H200 시간당 요금을 3~4달러로 잡고 대략 계산하면, 110스텝짜리 훈련 한 번을 완전히 돌리는 데 100~140달러 정도가 든다. 채점기와 렌더링 비용까지 더해도 프로젝트 전체 연산 비용은 수백 달러 선에 그친다. '미적 선호도를 보상으로 쓸 수 있는가'만 검증해보고 싶은 팀에게는 편하게 시도해볼 만한 문턱이다.
공개된 자료는 꽤 촘촘하다. 훈련 레시피와 스크립트는 GitHub에, 178장짜리 참고 이미지 데이터셋과 그대로 복제할 수 있는 RL 환경 Space, HPSv3 채점기 Space, 세 개의 LoRA 어댑터와 각각의 롤아웃 데이터셋, 그리고 생성된 결과물을 전부 훑어볼 수 있는 갤러리까지 올라와 있다. 재현해보고 싶은 사람이 환경을 처음부터 다시 구축할 필요 없이, Space를 복제하고 보상 비중만 조정하면 바로 시작할 수 있다.
이 발상을 따라가면 옮겨 쓸 만한 영역이 꽤 많다. 프런트엔드 컴포넌트의 느낌, 포스터 레이아웃의 여백감, 차트 배색이 적절한지 같은 것들은 옳고 그름을 딱 잘라 말하기는 어렵지만 사람이 보면 우열을 가릴 수 있는 작업이다. 지금까지는 이런 걸 RL 보상 함수로 옮기기가 힘들었다. 지금의 방식은 먼저 수백 장 규모의 참고 풀을 모으고, 쓸 만한 선호도 채점기를 하나 찾은 뒤, 나머지는 GRPO에 맡기는 것이다. 여전히 걸림돌은 참고 풀 쪽이다. 풀이 한쪽으로 치우치면 모델도 그만큼 치우치고, 그것도 아주 가지런하게 치우친다.
참고 출처: 허깅페이스 공식 블로그, TRL 및 OpenEnv 프로젝트 문서, CocoLoop. 세 실험의 스텝 수, 보상 구간, GPU 한 장당 실행 시간은 블로그의 훈련 기록과 하나씩 대조했으며, 연산 비용은 공개된 가격표를 기준으로 한 대략적인 추정치다.