White Circle의 Halo는 왜 Hugging Face 모델을 그대로 두고도 큰 분산 훈련까지 연결한다고 말하나요?

요약 보기

Halo를 먼저 큰 그림으로 보면, White Circle이 만든 오픈소스 훈련 프레임워크예요. 대상은 큰 언어 모델과 멀티모달 모델이고, 사전학습부터 SFT, 선호도 최적화, 여러 턴으로 이어지는 비동기 RL까지 한 저장소 안에서 다루겠다고 소개해요. 여기서 프레임워크라는 말은 모델 하나의 구조만 뜻하는 게 아니라, 학습을 시작하고 분산 실행하고 체크포인트를 남기고 다시 불러오는 작업 흐름 전체를 받쳐 주는 바닥판에 가깝다고 이해하면 돼요. README의 핵심 질문은 단순히 "모델을 학습할 수 있나"가 아니라, 서로 다른 훈련 방법을 같은 기반 위에서 굴릴 수 있나예요.

이 저장소가 특히 강하게 미는 점은 Hugging Face 모델을 직접 훈련한다는 거예요. 트레이너는 Hugging Face나 TRL 트레이너를 바탕으로 만들고, 체크포인트도 표준 SafeTensors로 남겨서 `from_pretrained`가 계속 동작한다고 해요. 새 모델 계열을 붙일 때도 보통 140줄 이하의 통합 코드면 된다고 주장하죠. 이게 왜 의미 있냐면, 사용자가 이미 익숙한 모델 형식과 불러오는 방식을 버리지 않아도 되기 때문이에요. README는 또 병렬화가 기존 모델 위에 덧붙는다고 말해요. 가상의 비유로 보면, 새 건물을 다시 짓는 게 아니라 지금 쓰는 건물에 엘리베이터와 배선만 추가해 많은 사람이 함께 쓰게 만드는 느낌에 가까워요. 그래서 모델 자체의 별도 분산 버전을 따로 유지하지 않는다는 설명과, 표준 체크포인트를 계속 쓴다는 설명이 서로 이어져요.

그다음 이해해야 할 배경이 병렬화 용어예요. Halo는 EP, CP, TP, ETP를 독립적으로 켜고 조합할 수 있다고 설명해요. README의 표를 그대로 풀면, EP는 MoE 전문가들을 여러 GPU에 나누는 방식이고, CP는 긴 문맥을 여러 GPU가 나눠 처리하는 쪽이며, TP는 모델 가중치 자체를 쪼개 들고 계산하는 방식이에요. ETP는 MoE의 전문가 FFN을 더 잘게 나누는 실험적 기능이고요. 중요한 건 이 방식들이 하나의 고정 세트가 아니라, 모델과 문맥 길이와 하드웨어에 맞춰 조합된다는 점이에요. 밑바탕은 PyTorch의 FSDP2, DTensor, DeviceMesh이고, Expert Parallelism의 all-to-all 통신은 DeepEP가 맡는다고 적혀 있어요. 그러니까 Halo의 주장은 "분산 훈련을 한다"에 그치지 않고, 어떤 종류의 분산을 어떤 부위에 적용하는지를 꽤 세밀하게 고를 수 있다는 쪽이에요.

RL 부분은 구조를 나눠 보면 덜 복잡해져요. Halo는 RL을 비동기로 돌린다고 하고, 학습 쪽과 생성 서버 쪽을 분리해요. 여러 턴 환경 롤아웃은 Ray actor가 맡고, 실제 생성은 vLLM이나 SGLang 서버가 담당하며, 그 사이에 prefetch queue를 둬서 롤아웃과 학습이 겹치게 한다고 설명해요. 그리고 학습기로 업데이트된 가중치는 native NCCL로 서버에 밀어 넣는다고 하죠. README가 여기서 강조하는 포인트는 두 가지예요. 첫째, 여러 턴 환경을 포함한 RL도 같은 인프라 안에서 돌아간다는 점. 둘째, 훈련 쪽은 Megatron 백엔드나 veRL 의존성 없이 plain Transformers 쪽에 남겨 둔다는 점이에요. 쉽게 말해, 생성 결과를 받아오는 창구와 실제로 가중치를 학습하는 작업대를 분리해서, 서로 기다리느라 쉬는 시간을 줄이려는 설계라고 볼 수 있어요.

성능 주장은 꽤 구체적인 조건과 함께 제시돼요. README는 8× B300에서 stock TRL 대비 학습 처리량이 최대 약 2.8배라고 말하고, 양쪽 모두 ZeRO-3로 샤딩한 비교에서는 피크 메모리가 25% 더 적은 상태에서 2.7배라고 적어요. 벤치마크 표에는 모델, 문맥 길이, 배치, EP 구성도 같이 붙어 있고, 어떤 항목에서는 CP가 GPU당 메모리를 기준선의 대략 절반 수준으로 줄였다고 설명해요. 여기서 중요한 건, 이 수치가 단일 비법 하나에서 나온다고 말하지 않는다는 점이에요. Halo는 DeepEP V2, FlashAttention 4, Liger, Grouped GEMM, padding-free packing, AdamWBF16 같은 최적화를 통합했다고 적고, 지원되는 곳에서는 기본 활성화된다고 해요. 즉 README의 논리는 "우리가 빠르다"보다 "병렬화, 커널, 정밀도, 메모리 절약, 옵티마이저 최적화를 한데 묶어 실제 학습 속도와 메모리 사용을 개선했다"에 더 가까워요.

실제로 어떻게 쓰게 하려는지도 README가 꽤 분명하게 정리해요. 설치는 Blackwell용과 Hopper용 Docker 이미지를 따로 제공하는 방식이 기본이고, PyTorch와 Flash Attention, DeepEP V2가 미리 들어 있다고 해요. 학습 실행은 `halo launch`에 훈련 방법과 YAML 설정 파일을 넘기면 되고, 인자에 따라 `python`, `torchrun`, `accelerate launch`를 고른다고 설명해요. 체크포인트 병합이나 저정밀도 변환 같은 부수 작업은 `halo run` 아래로 묶여 있고요. 문서도 사람용과 에이전트용으로 나뉘어 있어서, 짧은 작업 가이드와 전체 기술 레퍼런스를 구분해 두었어요. 그래서 Halo는 라이브러리 함수 몇 개만 던져 주는 저장소라기보다, 예제 설정, 실행기, 이미지, 문서를 함께 묶어서 훈련 작업 흐름을 통째로 정리하려는 프로젝트로 읽는 편이 맞아요.

다만 README의 약속을 읽을 때는 조건도 같이 봐야 해요. 성능 수치는 8× B300에서 돌린 벤치마크이고, 기준선도 같은 모델, 데이터, bf16, FlashAttention 4, Liger, grouped GEMM 조건을 맞춘 stock TRL이라고 적혀 있어요. 그래서 다른 GPU나 다른 모델에서 같은 배수가 그대로 나온다고까지 말하는 건 아니에요. 병렬화 기능도 모두 보편적으로 같지는 않아요. ETP는 실험적이라고 표시돼 있고, 어떤 모드를 어떤 모델에 쓸 수 있는지는 별도의 지원 표를 보라고 안내해요. 최적화 역시 "지원되는 곳에서" 기본 활성화라고 했으니, 하드웨어와 설정에 따라 가능한 조합이 달라진다는 뜻이죠. Docker 이미지도 아키텍처별이라 `latest` 태그가 없어요. 다시 말해 Halo README는 어디서나 자동으로 최고 성능을 보장한다고 말하기보다, 특정 하드웨어와 설정 조건을 맞추면 이런 병렬화와 최적화를 한 프레임워크 안에서 활용할 수 있다고 주장하는 문서예요.