모델 학습 파이프라인이 고도로 복잡해짐에 따라, 수동 작업으로는 다수의 전문 팀 간 협업과 인프라 관리를 처리하기 어려워졌습니다. AI 연구소 Aleph Alpha는 이를 해결하기 위해 전체 학습 과정을 코드로 구현하는 '모델 팩토리(Model Factory)' 시스템인 Savanna를 구축했습니다. 이를 통해 학습 과정 전체를 클릭 한 번으로 실행하고, 인적 오류와 반복 작업을 줄여 모델 학습을 하나의 협업 소프트웨어 프로젝트처럼 효율적으로 관리할 수 있게 되었습니다.
번역된 본문
연구자: Michael Barlow, 2026년 5월 22일
코드로 구현되는 모델 학습 (Model Training as Code)
TL;DR: 모델 학습은 매우 복잡해져서 수많은 전문화된 단계와 팀을 필요로 하게 되었으며, 이들 간의 수동 조율은 더 이상 감당하기 어렵습니다. Aleph Alpha에서는 전체 학습 파이프라인을 코드로 구현하여 모델 학습을 협업형 소프트웨어 프로젝트로 전환하는 모델 팩토리, 'Savanna(사바나)'를 구축했습니다. Savanna에서는 엔드투엔드(End-to-End) 학습이 격리된 환경에서 구동되며, 클릭 한 번으로 실행할 수 있습니다. 이 글은 Savanna가 무엇인지, 왜 필요한지, 그리고 이를 효과적으로 만드는 엔지니어링 문화에 대해 설명합니다.
도입
모델 학습은 매우 빠르게 발전하고 있습니다. 파이프라인에 새로운 단계들이 계속해서 추가되고 기존 단계들은 더욱 정교해지면서, 모델 학습은 세 가지 핵심적인 이유로 엔지니어링적 과제가 되었습니다.
첫째, 복잡성이 증가한다는 것은 오류가 발생할 여지가 많아진다는 것을 의미합니다. 데이터, 코드 또는 구성의 버그나 불일치는 전체 학습이 실패하거나 엉뚱한 방향으로 흘러가게 만들 수 있습니다.
둘째, 실패의 비용이 계속해서 증가하고 있습니다. 모델은 더욱 거대해지고, GPU 가격은 상승하며, 실행 한 번당 처리되는 데이터의 양도 점점 늘어나고 있습니다. 수천 시간의 GPU 가동 시간을 소모하는 상황에서 단순한 실수 한 번은 감당하기 힘든 큰 비용을 초래합니다.
셋째이자 가장 어려운 도전 과제는 조직적인 부분입니다. 이 복잡성은 이미 개인의 머리로 감당할 수 있는 한계를 훌쩍 넘어섰기 때문에, 저희와 같은 연구소에서는 규모가 크고 전문화된 팀들을 구성하게 되었습니다. 그다음 문제는 이 팀들을 어떻게 조율할 것인가입니다. 팀원들이 각자의 전문 분야에서 최신 연구를 자율적으로 탐색하면서도, 자신의 변경 사항을 프로덕션 파이프라인에 통합할 때 시스템을 망가뜨리거나 다른 사람의 작업을 방해하지 않으려면 어떻게 해야 할까요? 그리고 개별 단계에서의 개선 사항이 결국 최종적으로 더 나은 모델로 이어질 수 있도록 하려면 어떻게 해야 할까요? 전통적인 수동 모델 학습 프로세스는 이러한 질문에 대한 좋은 해답을 제공하지 못합니다.
수동 모델 학습의 숨겨진 비용
전통적인 수동 프로세스를 분석해 봅시다. 개괄적으로 보면 모델 학습은 단순해 보입니다. 인터넷의 방대한 데이터를 흡수하기 위한 사전 학습(Pre-training) 단계가 있고, 이어서 지시 사항을 따르는 법을 배우는 사후 학습(Post-training) 단계가 있습니다.
하지만 현실에서는 단 한 번의 시도만으로 좋은 모델을 학습시키는 일은 없습니다. 적절한 데이터 믹스, 아키텍처, 학습 레시피(Recipe)를 찾아가는 과정은 평가 지표를 바탕으로 이루어지는 반복적이고 컴퓨팅 자원에 의존적인 프로세스이며, 여기서 아래의 각 화살표는 상대적인 GPU 비용에 비례하여 가중치를 갖습니다.
이러한 각 구성 요소는 여러 전담 팀을 둘 만큼 충분히 복잡합니다. 예를 들어, 최신의 사후 학습은 지도 미세조정(SFT) 단계와 그 뒤를 이은 강화학습(RL) 단계로 구성됩니다. SFT와 RL은 서로 다른 기술과 도구를 요구하지만, 하나의 모델을 학습시키기 위해서는 반드시 통합되어야 합니다.
수동으로 운영되는 연구소에서 단일 모델이 파이프라인을 통과하는 과정이 어떤 모습일지 생각해 보십시오.
데이터 팀이 새로운 데이터 믹스를 완성하여 데이터베이스 경로를 사내 메신저(Slack)를 통해 사전 학습 팀에게 전달하면, 사전 학습 팀은 몇 주에 걸친 학습을 시작합니다. 학습을 시작한 지 2주가 지났을 때 스토리지 할당량이 가득 차서 학습이 중단됩니다. 파일 시스템이 수동으로 관리되기 때문에 파일 이름에 '삭제 금지(do_not_delete)'라고 적힌 30TB짜리 데이터셋을 삭제해도 안전한지 아무도 확신하지 못합니다. 문제가 해결되는 동안 사전 학습 팀의 GPU들은 그저 빈둥거리게 됩니다. 마침내 학습을 재개할 때쯤, 그들은 기억과 메신저 대화 스레드에 의존해 원래 세팅을 복구하며 설정 플래그를 빠뜨리지 않았기를 기도합니다.
이것이 바로 첫 번째 숨겨진 비용입니다. 즉, 수동으로 이루어지는 모든 단계는 인적 오류가 발생할 기회입니다.
마침내 사전 학습이 완료되면, 사전 학습 팀은 체크포인트를 SFT 팀에 넘겨줍니다. 좋은 레시피를 찾기 위해 SFT 팀은 서로 다른 구성과 데이터 믹스를 사용하여 여러 병렬 학습을 수동으로 시작합니다. 체크포인트들이 쏟아져 나오면, 팀은 각각에 대해 평가 스크립트를 실행하고 메신저를 통해 결과와 분석을 공유합니다. 일부 레시피는 유망해 보이고 다른 것들은 그렇지 않으며, 좋은 레시피를 찾아낼 때까지 몇 주 동안 이 과정을 반복합니다. 팀도 모르는 사이에, 그들은 몇 달 전 이전 사전 학습 체크포인트에 대해 이미 완료했던 실험들을 똑같이 반복하고 있었습니다.
이것이 두 번째 숨겨진 비용입니다. 팀이 과거의 학습 내용을 잊어버린다는 것입니다. 특정 하이퍼파라미터의 현재 값이 설정된 이유에 대한 영구적인 기록도 없고, 데이터와 관련된 공식적인 연결 고리도 존재하지 않습니다.
Research Michael Barlow 22/05/2026 Model Training as Code TL;DR: Model training has grown complex enough to require many specialised stages and teams, and manual coordination between them doesn’t scale. At Aleph Alpha, we’ve built Savanna, a model factory that implements the entire training pipeline in code, turning model training into a collaborative software project. In Savanna, end-to-end training runs are hermetic, and launchable with one click. This post describes Savanna, why it’s needed, and the engineering culture that makes it effective. Introduction Model training is moving fast. New stages keep joining the pipeline and existing ones grow more intricate, making model training an engineering challenge for three key reasons. First, more complexity means more room for error: bugs or inconsistencies in data, code, or configuration can cause entire training runs to fail or diverge. Second, the cost of failure keeps rising: models grow larger, GPU prices rise, and ever more data is processed per run. When you’re burning thousands of GPU hours, “oops” is an expensive word. The third and hardest challenge is organisational. The complexity has long outgrown the capacity of a single mind, so labs like ours have built large, specialised teams. The problem then becomes coordinating those teams. How can members autonomously explore the latest research in their area of expertise, while integrating their changes into the production pipeline without breaking it or interfering with each other’s work? And how do they ensure that improvements to individual stages translate into a better model at the end? Traditional, manual model training processes do not have good answers to these questions. The hidden cost of manual model training Let’s break down the traditional manual process. At a high level, model training looks simple: pre-training to absorb the internet, followed by post-training to learn instruction-following. In reality, you don’t train a good model on your first try. Arriving at a good data mix, architecture and training recipe is an iterative, compute-bound process guided by evaluation, where each arrow below is weighted by its relative GPU cost: Each of these components is complex enough to warrant multiple dedicated teams. Modern post-training, for example, comprises a supervised fine-tuning (SFT) stage followed by a reinforcement learning (RL) stage. SFT and RL require different skillsets and tools, but must be integrated to train a model. Consider what a single model’s journey through the pipeline might look like in a manual lab: The data team finishes a new mix and sends the database path over Slack to the pre-training team, who kick off a multi-week run. Two weeks in, the storage quota fills up and the training run crashes. The filesystem is managed manually, so no one is sure whether it’s safe to delete that 30TB dataset with do_not_delete in its file name, and the GPUs sit idle while the pre-training team works this out. When they finally relaunch, they reconstruct the original setup from memory and Slack threads, hoping they didn’t forget to set a flag. This is the first hidden cost: every manual step is an opportunity for human error. When pre-training is eventually complete, the pre-training team hands the checkpoint to the SFT team. To find a good recipe, the SFT team then manually kicks off a sweep of parallel trainings with different configurations and data mixes. As checkpoints roll in, the team runs their evaluation script on each one, sharing results and analysis in Slack. Some recipes look promising, others don’t, and they repeat this process for a few weeks until they narrow down a good one. Without realising it, the team repeated some experiments that they already completed for the previous pre-trained checkpoint a few months back. This is the second hidden cost: the team forgets its learnings. There’s no durable record of the reasoning behind a hyperparameter’s current value, no formal link between a data mix and its constituent datasets, and no clear attribution attaching a model to the training recipe that produced it. In a manual lab, this lineage is scattered across Slack, the filesystem, an experiment manager and various wiki pages, and is easily lost over time. The SFT team hands their checkpoint to the RL team, who kick off a training run with this as the base. The final model underperforms. Is the RL recipe overfit to last month’s SFT checkpoint, or is the SFT checkpoint itself at fault? After two weeks of debugging, the RL team confirms it’s the latter. Neither team can execute the other’s stage, so each had optimised for its own slice of the pipeline rather than the model at the end. And because integration is a manual hand-off, it happens rarely, leaving a month’s worth of divergence to reconcile each time. This is the third hidden cost: manual, infrequent hand-offs fragment teams’ ownership. It’s clear that manual model training doesn’t scale, and automation is not the only missing piece. Each of these hidden costs stem from the same underlying problem: the pipeline lives in the minds of the team rather than in a shared, durable artefact. To scale, the pipeline itself needs to be something tractable that teams can collaborate on. Introducing: Model Training as Code Our model factory, codenamed Savanna, implements our entire model training pipeline and processes in imperative code. We call this Model Training as Code (MTaC). Here’s what a simple Savanna post-training pipeline looks like in pseudocode: async post_train(config: PostTrainConfig) -> PostTrainEvaluation: sft_checkpoint = await sft(config.sft) sft_eval = spawn evaluate(config.eval, sft_checkpoint) rl_checkpoint = await rl(config.rl, sft_checkpoint) rl_eval = spawn evaluate(config.eval, rl_checkpoint) return PostTrainEvaluation( await sft_eval, await rl_eval) By lifting the pipeline into code, you gain three things: composability, consensus and provenance. li]:mb-2 [&>li:last-child]:mb-0 [&_a]:text-blog-orange [&_a]:underline [&_a]:underline-offset-4 [&_a]:font-normal [&_a_strong]:font-normal [&_strong]:font-semibold"> Composability: Composability comes from expressing manual steps as functions with typed inputs and outputs, which you can then build abstractions around and compose into an end-to-end pipeline that runs with one click. Modifying the pipeline becomes as simple as editing a function, repetitive work like evaluating intermediate checkpoints can be automated with a for loop, and testing is straightforward, because you can run subsets or downscaled versions of the pipeline with a different parametrisation. Consensus: Consensus comes from version control. The main branch represents the team’s collective best understanding of how to train a model. The code contains the full training recipe, so there is no setup to reconstruct or flag to forget when launching a training run. Provenance: Provenance comes from code comments and commit history. These encode the learnings and decisions that led to main. Past training runs stay reproducible, as the code that produced them is pinned in a commit you can check out and rerun. When any team can launch the full pipeline themselves, they can run any other team’s stage and iterate on the model as a whole rather than just their own slice of it. Labs typically decompose model training temporally when they scale, with each team owning a stage of the pipeline. MTaC opens the door to a capability-based decomposition, where teams instead own a model behaviour like multilinguality from end to end. Integrate little, integrate often With the pipeline in code, standard code collaboration best practices apply, and to make the most of MTaC, you need to follow them. The most important of these is trunk-based development, where changes land on main as soon as they can and in small increments, so teams can build on each other’s work at the earliest opportunity and fail fast if an approach is wrong. If you instead accumulate