완전한 LLM 파이프라인 구축(Building a Complete LLM Pipeline)

Lessons 01-12에서 다룬 모든 내용은 하나의 파이프라인(pipeline)을 구성하는 단계입니다. 이번 레슨은 그 단계들을 단일한 종단간(end-to-end) 실행으로 묶어 주는 골격(scaffold)입니다. 토크나이징(tokenize), 사전학습(pre-train), 스케일링(scale), SFT, 정렬(align), 평가(evaluate), 양자화(quantize), 서빙(serve)을 하나의 흐름으로 연결합니다. 노트북에서 70B 모델을 학습하지는 않습니다. 대신 2026년 프런티어(frontier) 팀이 무엇을 배포(ship)할지 결정할 때 사용하는 오케스트레이션 계층(orchestration layer), 매니페스트(manifest), 평가 게이트(eval gate), 롤백 계획(rollback plan)을 만듭니다. 이 레슨은 캡스톤(capstone)입니다.

유형: Build
언어: Python(표준 라이브러리)
선수 지식: Phase 10 Lessons 01-12 전체
예상 시간: 약 120분

학습 목표

• 앞선 11개 레슨인 토크나이저(tokenizer), 데이터(data), 사전학습(pre-training), 스케일링(scaling), SFT, RLHF, DPO, CAI, 평가(eval), 양자화(quantization), 추론(inference)을 하나의 재현 가능한 파이프라인 명세(pipeline spec)로 구성합니다.
• 단계 사이의 산출물 계약(artifact contract)을 정의합니다. 각 단계(stage)가 무엇을 입력으로 받고, 무엇을 만들며, 다음 단계가 그 입력을 어떻게 검증하는지 정합니다.
• 실험을 추적하고, 산출물(artifact)에 해시(hash)를 매기고, 배포 결정(ship decision)을 평가 임계값(eval threshold)으로 막아 주는 오케스트레이터(orchestrator)를 만듭니다.
• 롤백 계획(rollback plan)을 설계합니다. 어떤 산출물은 저렴하게 다시 만들 수 있고, 어떤 것은 비싼지, 그리고 손상된 체크포인트(corrupted checkpoint)가 어떤 비용을 일으키는지 판단합니다.

문제

이전 레슨들은 각각 동작합니다. 토크나이저를 학습했고, 작은 GPT를 사전학습했고, SFT 데이터셋을 조립했고, 보상 모델(reward model)을 학습했고, DPO를 실행했고, 평가를 측정했고, 양자화된 가중치(quantized weights)를 내보냈고(export), 추론 서버(inference server)를 띄웠습니다. 하지만 각각은 하나의 노트북일 뿐입니다. 노트북마다 고유한 컨벤션, 고유한 출력 경로(output path), 고유한 시드(seed)가 있습니다.

프런티어 학습 실행(frontier training run)은 노트북이 아닙니다. Llama 3 405B는 약 54일에 걸쳐 3천만 H100 시간(H100 hours)을 사용했고, DeepSeek-V3는 약 280만 H800 시간을 사용했습니다. 그 기간 동안 손상된 체크포인트 하나, 데이터 오염(data contamination) 하나, 평가 회귀(eval regression) 하나가 발생하면 팀은 실제 시간(wall-clock)으로 일주일, GPU 예산(GPU budget)으로 한 달을 잃을 수 있습니다. 팀이 이를 견뎌내는 방식이 곧 파이프라인 위생(pipeline hygiene)입니다. 모든 단계는 결정적(deterministic) 입력, 결정적 출력, 매니페스트, 해시, 게이트(gate)를 갖춰야 합니다.

이번 레슨은 캡스톤입니다. 노트북에서 전체 파이프라인을 끝까지 돌리지는 않습니다. 대신 단계들을 조율하는 오케스트레이터, 실행을 묘사하는 매니페스트, 배포 결정을 막아 주는 검증기(verifier), 그리고 제3자가 단일 파일만으로 같은 작업을 재실행할 수 있게 해 주는 재현 계획(replay plan)을 작성합니다. 코드는 작지만 그 안에 담아야 하는 규율은 큽니다.

이 패턴은 100M에서 1T 매개변수(parameters)까지 그대로 확장됩니다. 매니페스트, 오케스트레이터, 평가 게이트, 산출물 저장소(artifact store)라는 같은 네 가지 구성요소가 Llama 3도, 여러분이 취미로 만든 GPT도 동일하게 굴립니다. 차이는 각 단계의 설정(config) 안에 들어 있는 숫자의 크기뿐이며, 파이프라인의 모양 자체는 달라지지 않습니다.

개념

12개 단계(Twelve Stages)

Phase 10의 각 레슨은 하나의 단계입니다. 전체 의존성 그래프(dependency graph)는 다음과 같습니다.

graph TD
    S1["01 Tokenizer vocab"] --> S2["02 Trained tokenizer"]
    S2 --> S3["03 Sharded dataset"]
    S3 --> S4["04 Base model checkpoint"]
    S4 --> S5["05 Scaled training recipe"]
    S5 --> S6["06 SFT checkpoint"]
    S6 --> S7["07 Reward model + PPO policy"]
    S6 --> S8["08 DPO policy"]
    S7 --> S9["09 CAI / GRPO refined policy"]
    S8 --> S9
    S9 --> S10["10 Eval report"]
    S9 --> S11["11 Quantized weights"]
    S11 --> S12["12 Inference server"]
    S10 --> GATE["Ship gate"]
    S12 --> GATE

    style S1 fill:#1a1a2e,stroke:#e94560,color:#fff
    style S4 fill:#1a1a2e,stroke:#0f3460,color:#fff
    style S9 fill:#1a1a2e,stroke:#0f3460,color:#fff
    style GATE fill:#1a1a2e,stroke:#51cf66,color:#fff

단계 07과 08은 병렬로 실행할 수 있습니다. 그 외에는 모두 강한 의존성(hard dependency)을 갖습니다. 단계 02, 즉 토크나이저가 바뀌면 그 이후의 모든 하위 산출물(downstream artifact)이 무효화됩니다. 단계 10, 즉 평가가 바뀌면 배포 결정(ship decision)만 무효화됩니다.

매니페스트(Manifest)

매니페스트는 실행을 다시 재현할 수 있을 만큼 완전하게 묘사하는 단일 파일입니다. 파이프라인이 만들어 내는 어떤 결과도 매니페스트에 적혀 있지 않은 상태에 의존해서는 안 됩니다. 필드(field)는 지루하지만 반드시 필요합니다.

pipeline_version: 1.2.3
seed: 42
git_commit: a1b2c3d4
stages:
  01_tokenizer:
    recipe: bpe_32k
    input_hash: sha256:...
    output_hash: sha256:...
    wall_clock_sec: 3600
    cost_usd: 12

단계 N의 출력 해시(output hash)는 단계 N+1의 입력 해시(input hash)가 됩니다. 이 연결이 조금이라도 어긋나면 파이프라인은 즉시 멈춥니다. 이것이 데이터 손상을 초기에 잡는 방법이며, 동시에 다른 대륙에 있는 동료가 자신의 재현 실행이 우리가 만든 것과 같은 산출물을 낳았는지 검증하는 방법이기도 합니다.

실무에서는 작은 YAML 스키마(schema)와, 이전에 성공한 실행과 비교(diff)해 주는 매니페스트 검사기(manifest checker)를 함께 사용합니다. 비용(cost)이나 실제 시간(wall clock) 같이 변동이 예상되는 필드를 제외한 곳에서 차이(delta)가 나타나면 곧장 경고 신호(red flag)로 다룹니다.

산출물 타이핑(Artifact Typing)

각 단계의 출력은 형(type)을 갖춘 산출물입니다. 디렉터리 덩어리(directory blob)나 pickle 파일이 아니라, 알려진 스키마를 가진 이름 있는 타입입니다.

이렇게 형을 잡아 두면 가장 흔한 실수를 막을 수 있습니다. 예를 들어 단계 08의 출력을 단계 06의 입력으로 사용하거나, DPO로 학습된 모델을 SFT 경로로 그대로 배포하는 식의 실수입니다. 산출물에 형을 매기고 단계 시그니처(stage signature)에도 형을 강제하면, 이런 오류가 학습 시작 닷새째에 발견되는 사고가 아니라 컴파일 타임(compile-time)에 잡히는 오류로 바뀝니다.

평가 게이트(Eval Gate)

배포는 "학습이 끝났다"가 아닙니다. 배포는 "학습이 끝났고 평가 게이트도 통과했다"입니다. 게이트는 실행이 시작되기 전에 미리 정의해 둡니다.

gates:
  mmlu:      >= baseline + 0.5   # 회귀(regression) 금지
  humaneval: >= baseline + 1.0
  truthfulqa: >= baseline         # 하락 금지
  safety_refusal_rate: <= 0.05
  kl_from_reference: <= 25.0
  cost_total_usd: <= 50000

모든 게이트는 수치 임계값(numeric threshold)입니다. "느낌이 좋다(looks good)" 식의 게이트는 두지 않습니다. 주관적인 승인(sign-off)도 마찬가지로 허용하지 않습니다. 모든 게이트가 통과하면 해당 산출물은 배포 가능(shippable)으로 표시됩니다. 하나라도 실패하면 실행은 이름이 명시된 검토자(named reviewer)의 명시적인 우회 결정(override)이 있을 때까지 보류되며, 그 우회 자체도 매니페스트에 기록됩니다.

대부분의 재앙을 막아 주는 게이트는 두 종류입니다. *회귀 게이트(regression gate)*는 새 모델이 핵심 벤치마크(benchmark)에서 이전 모델만큼은 되는지 확인해 학습 단계의 버그를 잡아냅니다. *KL 예산 게이트(KL budget gate)*는 정렬된 정책(aligned policy)이 기준 모델(reference)에서 정해진 한도(X) 이상 떨어지지 않았는지 확인해 정렬 과다(alignment overcooking)를 막습니다. 모든 운영(production) 파이프라인은 이 두 게이트를 같이 갖춥니다.

오케스트레이터(Orchestrator)

오케스트레이터는 매니페스트를 읽고, 단계를 디스패치(dispatch)하고, 산출물을 추적하고, 계약 위반(contract violation)이 발생하면 실행을 멈추는 작은 코드입니다. Airflow도 Kubeflow도 아닙니다. 파이프라인 위생을 지키는 데에는 직접 쓴, 지루할 정도로 단순한 코드가 가장 잘 어울립니다.

오케스트레이터의 역할은 좁고 명확합니다.

1. 매니페스트에서 DAG를 결정(resolve)합니다.
2. 각 단계에 대해, 예상되는 출력이 이미 올바른 해시 값으로 저장되어 있는지 확인합니다. 이미 존재하면 건너뜁니다(skip).
3. 단계를 실행하고, 표준 출력(stdout)과 표준 에러(stderr)를 갈무리하고, 실제 시간과 비용을 측정합니다.
4. 출력 해시가 다음 단계가 기대하는 입력 해시와 일치하는지 검증합니다.
5. 실패하면, 어디서 멈췄는지 정확히 표시된 부분 매니페스트(partial manifest)를 기록하고 0이 아닌 종료 코드로 빠져나옵니다.

대략 Python 200줄 정도면 됩니다. 이번 레슨의 code/main.py와 같은 모양이 될 것입니다. 실제 파이프라인은 내부적으로 torchrun이나 ray로 클러스터 위에서 각 단계를 실행하지만, 오케스트레이터 자체는 단일 장비(single box) 위에서 돕니다.

실험 추적과 산출물 저장소(Experiment Tracking and Artifact Storage)

두 개의 외부 시스템이 파이프라인을 단단히 잡아 줍니다.

실험 추적기(Experiment tracker; wandb, neptune, mlflow). 단계마다 손실 곡선(loss curve), 평가 지표(eval metric), 시스템 텔레메트리(system telemetry)를 기록합니다. 3주 뒤에 실행 A와 실행 B를 비교해야 할 때 들여다보는 곳입니다. 팀은 거의 항상 호스팅형(hosted) 추적기를 사용합니다. 직접 만들기 시작하면 정작 학습에 써야 할 시간을 잃습니다.

산출물 저장소(Artifact store; S3, R2, GCS). 체크포인트(checkpoint), 데이터셋, 토크나이저, 평가 보고서(eval report)를 위한 불변(immutable) 객체 저장소입니다. 산출물은 파일 이름이 아니라 해시로 주소를 매깁니다. latest.pt 같은 파일 이름은 자기 발을 쏘는 함정(foot-gun)에 가깝고, ckpt-7b-step-20000-sha256:abc123.safetensors 같은 이름이야말로 계약(contract)이 됩니다.

오케스트레이터는 두 시스템 모두에 기록합니다. 추적기는 사람이 차트(chart)를 보기 위한 도구이고, 산출물 저장소는 다음 단계가 자신의 입력을 찾아오기 위한 도구입니다.

비용 계산(Costing)

프런티어 실행에는 반드시 달러 단위 숫자가 따라붙습니다. 예산 규율(budget discipline)은 두 지점에서 이루어집니다.

사전 추정(Pre-run estimate). 매니페스트로부터 예상 FLOPs(사전학습은 대략 6 x params x tokens), 예상 GPU 시간(FLOPs / peak throughput / utilization), 그리고 현재 임대(rental) 단가 기준의 달러 비용을 미리 계산합니다. 이 추정값이 예산 게이트(budget gate)를 넘으면 파이프라인은 아예 시작을 거부합니다.

실행 중 추적(In-run tracking). 단계별 실제 시간과 비용을 매니페스트에 기록합니다. 한 단계가 끝날 때마다 남은 예산을 다시 점검합니다. 어떤 단계가 예산을 초과하면, 다음 단계의 게이트는 새로 줄어든 잔여 예산으로 평가됩니다. 돈이 다 떨어졌다는 사실을 투자자가 전화해 줄 때 알게 되면 이미 늦습니다.

Llama 3는 비용을 약 $61M로 보고했고, DeepSeek-V3는 주요 사전학습 실행에 약 $5.6M을 보고했습니다. 그 차이의 대부분은 하드웨어 효율과 전문가 혼합(mixture-of-experts)에서 나옵니다. 다만 이런 비용 자체가 외부에서 보이는 이유는, 두 팀 모두 비용을 한 실행 단위가 아니라 단계 단위로 추적했기 때문입니다.

재현 가능성과 결정성(Reproducibility vs Determinism)

이 둘은 같은 말이 아닙니다. *재현 가능(Reproducible)*하다는 것은 같은 매니페스트, 같은 코드, 같은 인프라가 하위 지표(downstream metrics)에서 동등한 결과를 내는 체크포인트를 만든다는 뜻입니다. *결정적(Deterministic)*이라는 것은 비트 수준에서 동일한 출력(bit-identical output)을 낸다는 뜻입니다.

오늘날의 LLM 학습은 재현은 가능하지만 결정적이지는 않습니다. 분산 학습(distributed training)의 합산 순서(reduce-order), GPU 커널의 비결정성(cuBLAS, flash-attn), 혼합 정밀도(mixed precision)의 반올림이 합쳐져 실행마다 1e-5 수준에서 실수 값이 달라집니다. 최종 지표가 거의 움직이지 않는다면 이는 문제가 되지 않습니다. 다만 비트 수준의 차분(bit-level diff)으로 디버깅(debug)하려고 하면 곤란해집니다. 해결책은 단계마다 입력 해시, 출력 해시, 그리고 핵심 지표(headline metrics)를 함께 기록해 두는 것입니다. 가중치가 비트 단위로 같지 않더라도 이 값들이 일치한다면, 그 실행은 "재현되었다"고 부를 수 있습니다.

graph LR
    M["Manifest v1.2.3"] --> O["Orchestrator"]
    O --> S["Stages 01 → 12"]
    S --> AS["Artifact Store\n(content-addressed)"]
    S --> ET["Experiment Tracker\n(metrics, curves)"]
    AS --> GATE["Eval Gate"]
    ET --> GATE
    GATE -->|pass| SHIP["Ship"]
    GATE -->|fail| ROLL["Rollback plan"]

    style M fill:#1a1a2e,stroke:#0f3460,color:#fff
    style GATE fill:#1a1a2e,stroke:#e94560,color:#fff
    style SHIP fill:#1a1a2e,stroke:#51cf66,color:#fff
    style ROLL fill:#1a1a2e,stroke:#c0392b,color:#fff

롤백 계획(Rollback Plan)

실행이 시작되기 전에, 각 단계가 실패했을 때 무엇을 할지 미리 적어 둡니다. 세 가지 범주가 있습니다.

• 저렴하게 다시 실행(cheap to re-run; 시간 단위): 토크나이저, 평가, 양자화, 추론 서버. 그냥 다시 돌립니다.
• 중간 비용(medium; 일 단위): SFT, DPO, CAI. 기반 모델(base model)은 유지하고, 정렬 단계(alignment stage)만 다시 실행합니다.
• 비쌈(expensive; 주 단위와 수백만 달러): 사전학습. 이 단계에서의 롤백 계획은 "다시 실행"이 아닙니다. "마지막으로 정상이었던 체크포인트(last good checkpoint)를 사용하고, 데이터를 수정한 뒤 그보다 저렴한 하위 단계만 다시 실행한다"가 됩니다.

단계 간 의존성이 형(type)과 해시로 관리되기 때문에, 오케스트레이터는 롤백 대상 집합(rollback set)을 자동으로 계산할 수 있습니다. 실패한 단계와 그 이후의 모든 자손(descendant)을 함께 무효화하면 됩니다. 단계 06(SFT)에서 실패하면 06, 07, 08, 09, 10, 11, 12가 모두 무효화되고, 단계 11(양자화)에서 실패하면 11과 12만 무효화됩니다. 이런 정책을 미리 이름까지 붙여 두면, 새벽 4시에 지친 팀이 즉흥적으로 결정을 내릴 일이 없어집니다.

2026년에 관찰되는 운영 레시피(Production Recipes Observed in 2026)

대부분의 프런티어 팀이 같은 골격으로 수렴했습니다.

• 토크나이저: 바이트 폴백(byte fallback)을 갖춘 128k BPE. 작고 균형 잡힌 다국어 슬라이스(multilingual slice)로 학습합니다.
• 사전학습: 10-20T 토큰, 대부분 웹과 코드, 그리고 합성(synthetic) 데이터를 섞습니다. Muon이나 AdamW 옵티마이저(optimizer), FSDP2 또는 DeepSpeed ZeRO-3, 그래디언트 체크포인팅(gradient checkpointing), 가중치는 BF16에 마스터는 FP32.
• SFT: 500k-2M 지시 쌍(instruction pair), 사람과 합성 데이터를 섞되 평가 집합과의 중복은 엄격하게 제거(dedup)합니다.
• 정렬(Alignment): DPO 또는 CAI + GRPO. 선호 신호(preference signal)가 DPO로 표현하기 어려울 만큼 다차원일 때만 RLHF를 사용합니다.
• 평가: MMLU-Pro, MATH, HumanEval+, GPQA, SWE-Bench Verified, LiveBench, 그리고 외부에 공개하지 않는 사내 보관용 집합(private held-out set).
• 양자화: 서빙에는 4-bit GPTQ 또는 AWQ, 정확도 차이(accuracy delta)가 중요한 안전성 평가(safety eval)에는 8-bit.
• 서빙: vLLM, TensorRT-LLM 또는 자체 구현(in-house). 연속 배칭(continuous batching), 사변적 디코딩(speculative decoding), KV 캐시 축출(KV cache eviction).

숫자는 6개월마다 바뀝니다. 골격은 바뀌지 않습니다.

직접 만들기

이번 레슨의 코드는 12개의 학습 스크립트가 아니라, 오케스트레이터와 매니페스트 검사기입니다. 각 단계는 올바른 모양(shape)과 해시를 가진 산출물을 만들어 내는 자리표시자(placeholder)로 구현됩니다. 오케스트레이터를 끝까지(end-to-end) 한 번 실행해 보면, 실제 GPU 비용을 쓰기 전에 파이프라인의 배관(plumbing)이 제대로 작동하는지 확인할 수 있습니다.

전체 구현은 code/main.py에 있습니다. 핵심 구성요소는 다음과 같습니다.

• Manifest 데이터클래스(dataclass): 파이프라인 버전(pipeline version), 시드(seed), git commit, stages, gates.
• StageRecord 데이터클래스: name, type, input hashes, output hash, wall clock, cost.
• run(): DAG 순서로 단계를 실행하고, 해시와 예산을 점검하며 매니페스트를 갱신합니다.
• gate(): 임계값을 읽고 최신 평가 보고서와 비교해 통과 여부(pass/fail)를 반환합니다.
• ArtifactStore: S3를 흉내 낸 인메모리(in-memory) 스텁(stub)입니다. 해시 기준으로 put/get을 제공합니다.
• simulate_stage: 각 단계의 자리표시자이며, 결정적인(deterministic) 산출물, 실제 시간, 비용을 함께 반환합니다.

main.py의 파이프라인은 12개의 자리표시자 단계를 차례로 실행해 매니페스트를 만들고, 통과하는 평가 게이트와 실패하는 평가 게이트를 모두 보여 줍니다. 각 자리표시자를 해당 Phase 10 레슨의 실제 학습 스크립트로 바꾸기만 하면, 실제 프런티어 파이프라인이 사용하는 골격이 그대로 완성됩니다.

사용해보기

표준 작업 흐름(workflow)은 세 개의 명령(command)으로 정리됩니다.

python code/main.py plan    # 매니페스트 검증, 비용 추정 계산, DAG 출력
python code/main.py run     # 단계 실행, manifest.out.yaml 작성
python code/main.py gate    # manifest.out.yaml을 읽고 평가 게이트 적용, ship-or-hold 판단

언제나 plan을 먼저 실행합니다. 대부분의 파이프라인 버그는 계획(plan) 단계에서 드러납니다. 누락된 게이트 임계값(threshold), 낡은 해시(stale hash), 예산 초과(budget overrun) 같은 것들입니다. plan은 공짜이고 run은 비쌉니다. 저렴한 쪽에서 버그를 잡아 비용을 아끼는 셈입니다.

gate의 출력은 SHIP 아니면 HOLD: <reason>입니다. 보류된 실행(held run)은 실패가 아니라 의사 결정 지점(decision point)입니다. 이름이 명시된 검토자가 우회 결정을 내리고 그 결정이 기록되거나, 그렇지 않으면 롤백을 승인합니다.

산출물 만들기

이 레슨은 outputs/skill-llm-pipeline-reviewer.md를 만들어 둡니다. 제안된 파이프라인 매니페스트를 이 스킬에 넣으면, 단계 타이핑(stage typing), 해시 체인(hash chain), 게이트, 롤백 계획, 비용 추정을 모두 점검합니다. 평가 게이트가 빠져 있거나, KL 예산이 정해져 있지 않거나(unbounded), 평가 데이터와 학습 데이터가 섞인 실행은 결코 승인하지 않습니다.

연습문제

1. (쉬움) 단계 07과 08을 병렬로 실행하도록 오케스트레이터를 확장합니다. 표준 라이브러리의 concurrent.futures 모듈을 사용합니다. 최종 매니페스트가 두 단계의 출력을 모두 기록하는지, 단계 09의 입력 해시가 둘을 결정적인 방식으로 결합한 값인지 확인합니다.

2. (중간) "오염 검사(contamination check)" 게이트를 추가합니다. 평가 데이터셋 해시와 학습 데이터셋 샤드(shards)가 주어졌을 때, 정확한 문자열 일치(exact string match) 혹은 13-gram 일치로 중복 비율(overlap)을 계산합니다. 중복이 0.1%를 넘으면 게이트가 실패해야 합니다. 오염된 학습 집합을 넣어 실행이 보류되는지 확인합니다.

3. (중간) 비용 추정기를 처음 원리(first principles)에서 직접 구현합니다. 단계 04(사전학습)에 대해 FLOPs를 6 x params x tokens로 추정하고, H100의 BF16 989 TFLOPs 기준 MFU(model FLOPs utilization) 40%, GPU 시간당 $2.50을 가정합니다. 7B 모델을 2T 토큰으로 학습할 때의 비용을 보고하고, 공개된 Llama 2 수치와 비교합니다.

4. (어려움) 부분 롤백(partial rollback)을 만듭니다. 단계 09(CAI)에서 실패를 흉내 낸 다음, 01-08은 캐시된 상태로 둔 채 09부터 12까지만 다시 실행합니다. 오케스트레이터는 해시를 기준으로 캐시된 산출물을 감지해 건너뛰어야 합니다. 전체 재실행 대비 절약된 실제 시간을 측정합니다.

5. (어려움) 관측 가능성(observability)을 더합니다. 각 단계에 OpenTelemetry 스팬(span)을 내보내고, 속성(attribute)으로 매개변수 수(params), 본 토큰 수(tokens seen), 손실(loss), 비용을 함께 기록합니다. 스팬을 로컬 컬렉터(local collector)로 보냅니다. 목적은 대시보드(dashboard)가 아니라, 하나의 추적 ID(trace ID)에서 모든 단계의 건강 상태를 따라갈 수 있게 하는 것입니다.

핵심 용어

더 읽을거리

• Dubey et al., 2024 — "The Llama 3 Herd of Models" — 데이터, 학습, 정렬, 평가까지 포괄하는 프런티어 파이프라인을 가장 상세히 공개한 자료입니다.
• DeepSeek-AI, 2024 — "DeepSeek-V3 Technical Report" — Llama 3급 학습 대비 약 1/10 수준 비용을 목표로 한 효율 중심(efficiency-first) 파이프라인입니다.
• Kaplan et al., 2020 — "Scaling Laws for Neural Language Models" — 연산량(compute), 데이터, 매개변수 사이의 스케일링 관계를 처음 정리한 논문입니다.
• Hoffmann et al., 2022 — "Training Compute-Optimal Large Language Models (Chinchilla)" — Kaplan의 결과를 보정해 오늘날의 데이터 예산을 재정의한 연구입니다.
• PyTorch FSDP2 문서 — PyTorch 2.4+에서 FSDP1을 대체하는 분산 학습 기본 도구입니다.
• Weights & Biases LLM Reports — 오픈소스 LLM 실행에서 실제로 사용된 매니페스트와 실험 추적기 출력 예시를 제공하며, 자기 파이프라인의 템플릿으로 그대로 참고할 만합니다.