Nemotron 딥다이브
— 모델을 쓰는 법에서 학습을 설계하는 법까지

1프로젝트 한줄 요약

Nemotron은 NVIDIA의 모델 계열 이름이면서, 이 저장소에서는 그 모델을 활용하는 개발 자산의 묶음을 뜻합니다. 이 저장소에서 배울 핵심은 모델 호출 한 번이 아니라, 데이터·설정·학습 결과를 연결하는 방법입니다.

처음에는 usage-cookbook/의 노트북으로 추론을 살펴볼 수 있습니다. 다음에는 use-case-examples/에서 검색·문서 처리·에이전트 구성 사례를 읽습니다. 더 깊이 들어가면 src/nemotron/recipes/가 데이터 준비와 학습 단계를, src/nemo_runspec/이 실행 설정과 결과물 추적을 담당합니다.

2왜 주목받는가

2-1. 사용 예제와 학습 방법을 한곳에서 찾을 수 있다

2026-10-23 GitHub 기준 스타 2,201개, 포크 450개이며, GitHub Trending Jupyter Notebook Daily #11에 선정된 저장소입니다. 이 순위만으로 유입 원인이나 실사용 규모를 알 수는 없습니다. 다만 소스와 README에서 관심을 끌 만한 요소는 확인할 수 있습니다.

루트 README는 Nemotron 3.5 Super와 Lightning 공개를 전면에 소개합니다. 각각의 학습 경로도 src/nemotron/recipes/super35/와 src/nemotron/recipes/lightning35/에 있습니다. 모델 공개 소식에서 곧바로 사용 예제와 학습 구성으로 이동할 수 있다는 점이 이 허브의 장점입니다. 이것이 트렌딩에 기여했을 가능성은 있지만, 인과관계를 확인한 통계는 없습니다.

새 모델을 소개하는 문서와 그 모델로 실험을 구성하는 코드를 함께 읽을 수 있다는 점이 학습 가치를 만듭니다. 특히 src/nemotron/recipes/embed/와 src/nemotron/recipes/rerank/처럼 검색 모델을 다루는 경로까지 있어, 대화형 LLM 이외의 활용법도 배울 수 있습니다.

2-2. 경쟁·대안 도구와 비교하면 역할이 선명해진다

아래 표는 성능 순위가 아니라 무엇을 맡기는 도구인가를 비교합니다. vLLM·Transformers·LangChain은 이 저장소의 예제에서 실제로 사용되므로, Nemotron과 서로 대체만 하는 관계는 아닙니다.

2-3. 발표 수치와 재현 가능한 범위는 구분해야 한다

src/nemotron/recipes/nano3/README.md는 추론 처리량 최대 3.3배, 최대 1M 토큰 문맥 길이를 소개합니다. 동시에 공개된 학습 데이터 부분집합만 사용하므로 기술 보고서와 결과가 달라진다고 명시합니다. 따라서 수치를 이 레시피의 실행 결과로 인용하거나, 모든 환경에서 같은 성능이 나온다고 해석하면 안 됩니다.

초보자가 먼저 얻을 성과는 벤치마크 1등이 아닙니다. 설정 파일 하나를 읽고 어떤 엔진과 데이터가 필요한지 설명하는 능력, 그리고 결과가 달라졌을 때 원인을 좁히는 능력입니다.

3기술 스택 전체 지도

3-1. 백엔드·학습 제어: Python 패키지가 중심

루트 pyproject.toml의 패키지 이름은 nemotron, 버전은 0.2.0입니다. Python 허용 범위는 >=3.11,<3.14, .python-version은 3.12입니다. README의 Python 3.10+ 배지보다 실제 설치 메타데이터가 엄격합니다.

>=는 설치된 버전이 아니라 허용하는 하한입니다. 루트 uv.lock과 단계별 잠금 파일이 따로 있으므로 위 표를 하나의 검증된 실행 환경으로 합쳐 읽지 마세요. 루트 [tool.uv].override-dependencies에는 torch==2.10.0도 지정됩니다.

3-2. 선택 기능과 예제는 별도의 버전을 요구한다

특히 두 예제의 Python 범위는 서로 겹치지 않습니다. 폴더마다 의존성 파일이 있는 이유가 여기에 있습니다. 모든 예제를 한 가상환경에 설치하는 접근은 피하고, 학습할 예제의 환경부터 구분하세요.

3-3. 프론트엔드: 노트북과 일부 독립 웹 데모

저장소의 사용자 인터페이스는 주로 Jupyter 노트북입니다. 음성 RAG 예제에는 ipywidgets와 ipywebrtc>=0.6.0가 있으며, 시각 조사 에이전트의 usage-cookbook/Nemotron-3.5-Super-VL/visual-investigation-agent/requirements.txt에는 jupyterlab==4.6.4, ipykernel==7.4.0, matplotlib==3.11.2가 고정되어 있습니다.

브라우저 UI가 전혀 없는 것은 아닙니다. usage-cookbook/Nemotron-3-Nano-Omni/computer-use-agent-with-omni/에는 usage-cookbook/Nemotron-3-Nano-Omni/computer-use-agent-with-omni/web/index.html과 usage-cookbook/Nemotron-3-Nano-Omni/computer-use-agent-with-omni/web/sidepanel.js가 있습니다. usage-cookbook/Nemotron-3-Nano-Omni/computer-use-agent-with-omni/server/main.py는 FastAPI로 정적 파일을 제공하고, 프론트엔드는 fetch()와 EventSource로 상태와 이벤트를 받습니다.

추적 대상 파일에서 package.json·Cargo.toml·go.mod는 발견되지 않았습니다. 저장소 전체를 React·Node.js 기반의 단일 웹 앱으로 설명할 근거는 없습니다.

3-4. 인프라·빌드·CI

배포 패키지는 hatchling.build로 만들며, 휠에는 src/nemotron과 src/nemo_runspec이 포함됩니다. 문서는 Sphinx 계열이고, justfile의 docs-render는 sphinx-build를 호출합니다.

재현성을 이해하려면 모델 설정뿐 아니라 Python 범위·잠금 파일·컨테이너·외부 코드 리비전을 함께 읽어야 합니다. 모든 외부 코드가 커밋으로 고정된 것은 아닙니다. 위 Dockerfile은 nemotron_3_omni 브랜치를 가져오므로, 같은 명령도 시점에 따라 다른 코드를 얻을 수 있습니다.

4아키텍처 심화 분석

4-0. 먼저 전체 흐름을 그려 보자

데이터 준비와 학습을 같은 단계로 묶지 않는 것이 중요합니다. src/nemotron/recipes/nano3/stage0_pretrain/data_prep.py는 blend.json과 토큰 파일을 만들고, src/nemotron/recipes/nano3/stage0_pretrain/train.py는 그 경로를 학습 엔진의 설정에 넣습니다. 준비가 끝난 데이터를 여러 학습 실험에서 다시 사용할 수 있는 구조입니다.

4-1. 패턴 ① 실행 명세를 스크립트 옆에 둔다

src/nemotron/recipes/nano3/stage0_pretrain/train.py의 맨 위에는 PEP 723 형식의 주석 블록이 있습니다. TOML 문법으로 실행 이름·컨테이너·실행기·기본 GPU 자원을 선언합니다. 아래는 해당 명세의 일부입니다.

# /// script
# [tool.runspec]
# schema = "1"
# name = "nano3/pretrain"
# image = "nvcr.io/nvidia/nemo:25.11.nemotron_3_nano"
#
# [tool.runspec.run]
# launch = "torchrun"
#
# [tool.runspec.resources]
# nodes = 2
# gpus_per_node = 8
# ///

src/nemo_runspec/_parser.py의 extract_pep723_toml()은 파일을 텍스트로 읽어 이 블록을 찾고, 주석 접두사를 제거합니다. parse()는 tomllib.loads()로 해석하고 parse_runspec()으로 구조화합니다. 이 파서는 학습 스크립트를 실행하거나 import하지 않고 메타데이터를 읽습니다.

src/nemo_runspec/_models.py의 Runspec·RunspecRun·RunspecResources는 @dataclass(frozen=True)로 선언되어 있습니다. 읽어 들인 실행 명세를 이후 단계에서 함부로 바꾸지 않도록 의도를 표현합니다. 다만 내부에 담긴 딕셔너리까지 깊게 불변이 되는 것은 아닙니다.

일반화할 수 있는 교훈은 기계가 읽을 수 있는 설명을 코드 가까이에 둔다는 것입니다. 단, PEP 723이 tool.runspec의 모든 키를 표준으로 정한 것은 아닙니다. 이 스키마는 저장소가 정의한 규약입니다. 근거: 실행 명세 파서

4-2. 패턴 ② 실행 위치와 학습 내용의 책임을 나눈다

src/nemotron/cli/commands/nano3/pretrain.py의 _execute_pretrain()은 parse_config()와 parse_env()를 호출하고 build_job_config()로 최종 작업 설정을 만듭니다. cfg.dry_run이면 설정을 보여 준 뒤 반환하며, 설정 파일 저장과 실제 실행은 그 뒤에 있습니다.

# _execute_pretrain()의 주요 순서를 간추린 흐름
train_config = parse_config(cfg.ctx, SPEC.config_dir, SPEC.config.default)
env = parse_env(cfg.ctx)
job_config = build_job_config(...)
display_job_config(job_config, for_remote=for_remote)

if cfg.dry_run:
    return

# 이후 job.yaml·train.yaml 저장, 실행기 선택, 작업 제출

설정 저장은 전체 실행 정보를 담는 job.yaml과 학습 스크립트에 전달할 train.yaml을 나눕니다. 제출 기록과 실제 학습 입력을 따로 살펴볼 수 있어, 원격 환경에서 경로가 달라졌을 때도 비교할 근거가 생깁니다.

로컬 모드에서는 execute_local(), 클라우드 실행기 이름이 dgxcloud 또는 lepton이면 execute_cloud(), 나머지 원격 경로에서는 _execute_remote()를 선택합니다. 후자는 SelfContainedPackager로 코드와 설정을 묶고 run.Experiment에 작업을 추가합니다.

반대로 src/nemotron/recipes/nano3/stage0_pretrain/train.py는 어디에 작업을 제출할지 결정하는 대신, 학습 설정을 조립하고 pretrain(config=cfg, forward_step_func=forward_step)를 호출합니다. 실행 환경을 바꾸는 수정과 학습 내용을 바꾸는 수정을 나눌 수 있습니다.

설정 우선순위는 단순한 “나중 파일 승리”가 아니다

src/nemo_runspec/config/loader.py의 build_job_config()는 일반 환경 키에 프로필 값을 덮어쓰지만, YAML에 있던 container_image·nodes·gpus_per_node·ntasks_per_node·nproc_per_node는 다시 적용합니다. 마지막에는 CLI의 dotlist 변경을 재적용합니다.

tests/nemo_runspec/test_config_loader.py의 test_build_job_config_preserves_yaml_owned_image_and_resources()가 YAML 자원 보존과 환경변수 병합을 검증합니다. 함수 위 설명만 읽으면 프로필이 항상 우선한다고 오해할 수 있으므로, 병합 코드와 테스트까지 같이 읽어야 합니다.

실험의 실제 조건은 기본 YAML 하나가 아니라, 모든 병합을 마친 최종 설정에 있습니다. 근거: 설정 조립 코드

4-3. 패턴 ③ 학습 구성을 함수 경로로 주입한다

사전학습 YAML은 recipe._target_에 megatron.bridge.recipes.nemotronh.nemotron_3_nano.nemotron_3_nano_pretrain_config를 지정합니다. src/nemotron/kit/recipe_loader.py의 extract_recipe_config()는 이 경로와 나머지 인자를 분리합니다.

# import_recipe_function()의 핵심 부분
module_path, function_name = target.rsplit(".", 1)
module = importlib.import_module(module_path)
return getattr(module, function_name)

# 학습 스크립트에서 구성 객체를 얻는 부분
recipe_func = import_recipe_function(recipe_target)
cfg = recipe_func(**recipe_kwargs)

이후 create_omegaconf_dict_config()로 구성 객체를 변환하고 YAML 및 CLI 변경을 병합한 다음, apply_overrides()로 실제 학습 설정에 반영합니다. 같은 학습 진입점을 두고 어떤 구성 함수를 사용할지 교체할 수 있으므로 팩터리와 의존성 주입의 작은 사례로 볼 수 있습니다.

또한 _target_은 실제 Python 모듈을 import하는 경로입니다. 데이터처럼 보이는 설정도 실행할 코드를 선택할 수 있다는 뜻입니다. 어떤 함수를 가리키는지 읽는 습관이 필요합니다. 근거: 레시피 로더

4-4. 패턴 ④ 결과물을 “경로와 이력”으로 다룬다

src/nemotron/kit/artifacts/base.py의 Artifact는 Pydantic 모델입니다. path·type·metadata와 생성 시각·생산자 정보를 담고, model_validator로 하위 클래스 필드와 메타데이터를 맞춥니다.

src/nemo_runspec/artifacts.py의 setup_artifact_tracking()은 설정을 읽어 manifest와 W&B 추적을 선택합니다. ManifestTracker.log_artifact()는 실제 대용량 데이터를 복사하는 대신 manifest.json에 경로와 입력 참조를 기록합니다.

_atomic_json_write()는 임시 파일에 JSON을 쓴 뒤 fsspec의 mv()를 호출합니다. hf:// 저장소는 별도 경로에서 관련 파일을 한 커밋으로 묶습니다. 다만 모든 원격 파일시스템에서 같은 원자성이 보장된다고 확대 해석할 수는 없습니다.

따라서 :latest는 편리한 참조일 뿐 고정된 실험 조건이 아닙니다. 비교 실험에는 실제 버전과 데이터 내용, 설정, 외부 엔진 버전까지 기록해야 합니다. 공통 추적 계층이 manifest를 지원해도 Nano3 학습 스크립트에는 W&B 관련 패치가 남아 있으므로 모든 레시피가 동일하게 동작한다고 단정하면 안 됩니다. 근거: manifest 추적 구현

4-5. 노트북의 “스트리밍”도 구현을 확인하자

usage-cookbook/Nemotron-Nano-9B-v2/vllm_cookbook.ipynb에는 stream_like()가 있습니다. 이 함수는 먼저 llm.generate()의 전체 결과를 받은 뒤 문자열을 한 글자씩 출력합니다. 서버에서 생성 중인 토큰을 받는 진짜 스트리밍과는 대기 시간의 성격이 다릅니다.

# 노트북의 stream_like()에서 중요한 부분
outputs = llm.generate([prompt], sampling_params=sampling_params)
text = outputs[0].outputs[0].text
for ch in text:
    print(ch, end="", flush=True)

# 별도의 API 예제는 stream=True로 청크를 받는다
for chunk in stream:
    delta = chunk.choices[0].delta
    if delta and delta.content:
        print(delta.content, end="", flush=True)

같은 화면 효과라도 데이터가 도착하는 시점은 다를 수 있습니다. 첫 토큰 지연을 비교하려면 출력 애니메이션이 아니라 요청 시각과 첫 응답 청크 수신 시각을 관찰해야 합니다.

5디렉토리 구조 해부

위 구조는 주요 경로만 남긴 요약입니다. src/는 Python 패키지의 소스 디렉토리입니다. 예제 디렉토리까지 패키지 내부 코드와 같은 방식으로 설치·관리되는 것은 아닙니다.

5-1. 네 경로를 구분해서 따라가기

처음부터 모든 파일을 정독하지 마세요. src/nemotron/cli/commands/nano3/pretrain.py → src/nemotron/recipes/nano3/stage0_pretrain/train.py → src/nemotron/kit/recipe_loader.py 순서로 한 경로를 완주한 뒤, 데이터 준비 쪽으로 돌아오는 편이 좋습니다.

5-2. 규모를 직접 세면 “Jupyter Notebook 저장소”의 의미도 달라진다

커밋 1c3e781의 git ls-files에 있는 추적 파일 2,727개를 대상으로 셌습니다. 텍스트는 줄 단위로, 노트북은 JSON 전체가 아닌 코드 셀의 source만 셌습니다. 공백·주석을 포함하며, Python 파일에 포함된 테스트와 예제도 제외하지 않았습니다.

Python 중 src/nemotron/은 195,685행, src/nemo_runspec/은 10,432행, tests/는 107,217행입니다. 이 세 수치는 전체 Python 행 수 안에 포함되는 부분집합입니다. GitHub의 주 언어 표시는 이런 물리 행 수와 같은 계산이 아니므로 서로 모순이라고 볼 수 없습니다.

6학습 포인트 (기술별)

6-1. Python: 경계를 드러내는 데이터 모델

Runspec의 dataclass와 Artifact의 Pydantic 모델은 서로 다른 필요를 해결합니다. 전자는 읽은 실행 명세를 구조화하고, 후자는 저장·전달할 아티팩트의 필드를 검증합니다. “모든 데이터를 dict로 넘길까?” 대신, 어느 지점에서 입력을 검증해야 하는지 생각해 보세요.

실습 아이디어: 실행 명세에서 nodes와 gpus_per_node를 표로 옮기고, 값이 누락됐을 때 parse_runspec()이 고르는 기본값을 찾아 적습니다. 타입 표기와 범위 검증은 같은 것이 아니라는 점도 확인합니다.

6-2. 설정 관리: 병합 결과를 예측하는 능력

load_config()는 기본 설정을 병합하면서 순환 상속을 검사합니다. apply_dotlist_overrides()는 OmegaConf.from_dotlist()로 train.train_iters=5 같은 문자열을 중첩 구조로 바꿉니다.

실습 아이디어: YAML의 train_iters: 1700에 CLI 변경 train.train_iters=5를 적용한다고 가정하고, 바뀌는 키와 유지되는 키를 손으로 계산합니다. 이어서 run.env.nodes는 왜 프로필과 다른 규칙을 따르는지 설명합니다.

6-3. 데이터 엔지니어링: 토큰화와 패킹은 별개의 작업

src/nemotron/recipes/nano3/stage1_sft/data_prep.py의 run_data_prep_main()은 PlanStage·DownloadStage·PackedSftParquetStage를 연결합니다. 대화를 토큰으로 바꾸고, 역할별 loss mask를 만든 뒤 다음 토큰 예측에 맞게 샘플 안에서 한 칸 당겨 정렬합니다. 여러 시퀀스를 묶어 Parquet 샤드로 저장하며, 각 샘플의 마지막 loss mask는 0으로 둡니다.

Nano3 레시피 README의 흐름도와 명령 설명은 SFT 출력을 .npy로 설명하지만, 현재 데이터 준비 코드와 학습 스크립트는 packed Parquet 경로를 연결합니다. 데이터 형식은 오래된 요약 표보다 실제 생산자와 소비자 코드를 함께 확인해야 합니다.

실습 아이디어: 길이 6·4·3인 샘플을 용량 10인 상자에 넣어 보고, 경계 표시를 잃으면 어떤 오류가 생길지 적습니다. 이후 src/nemotron/recipes/nano3/stage1_sft/train.py의 _build_dataset_config()가 nano3_packed_sft_dir에서 학습 경로를 자동 구성할 때 Parquet 파일이 없으면 어떻게 실패하는지 읽습니다.

6-4. 분산 학습: 길이도 장비 구성에 맞아야 한다

src/nemotron/kit/recipe_loader.py의 derive_pad_seq_to_mult()는 CP·TP·sequence parallel 조건으로 패딩 길이의 배수를 계산합니다. 명시된 배수와 학습·평가 병렬 구성의 요구값을 math.lcm()으로 합칩니다.

# 함수 규칙을 손으로 계산하는 예시
explicit = 3
CP = 2
TP = 4
sequence_parallel = True

# CP 제약: 2 * CP = 4
# sequence parallel 제약: CP * TP = 8
# 최종 배수: lcm(3, 4, 8) = 24

여기서 24는 토큰 길이 정렬의 배수입니다. GPU가 24개 필요하다는 뜻이 아닙니다. 실습 아이디어: sequence parallel을 끄거나 평가 CP를 추가했을 때 배수가 어떻게 바뀌는지 계산합니다.

6-5. 추론 API: 도구 호출과 실행은 다른 단계

vLLM 노트북의 가장 짧은 경로는 모델 로딩 → 생성 옵션 → 결과 추출입니다. 다음은 그 구조를 유지하고 질문만 한국어로 바꾼 예시입니다. 실제 실행에는 해당 모델을 수용할 GPU 환경이 필요합니다.

from vllm import LLM, SamplingParams

llm = LLM(
    model="nvidia/NVIDIA-Nemotron-Nano-9B-v2",
    trust_remote_code=True,
    dtype="bfloat16",
)
params = SamplingParams(temperature=0.6, max_tokens=200)
outputs = llm.generate(["GPU가 하는 일을 쉽게 설명해 줘."], sampling_params=params)
print(outputs[0].outputs[0].text)

trust_remote_code=True는 모델 저장소의 사용자 정의 코드를 허용하는 선택입니다. 모델 식별자뿐 아니라 실제로 사용할 코드 리비전도 확인할 대상이 됩니다.

vLLM 노트북의 TOOLS는 calculate_tip 함수 이름과 JSON Schema를 모델에 제공합니다. 해당 셀은 응답의 message.content와 message.tool_calls를 출력하지만, 실제 calculate_tip() 함수를 정의해 호출하는 실행 루프까지 구현하지는 않습니다.

실습 아이디어: 청구액 50, 비율 15라는 인자를 받은 뒤 애플리케이션이 검증·계산·결과 전달을 수행하는 흐름을 그립니다. 모델이 함수 이름을 반환했다는 사실만으로 함수가 실행됐다고 판단하지 않는 연습입니다.

6-6. 테스트·CI: GPU 없이 검증할 수 있는 계약 찾기

.github/workflows/retrieval-recipes.yml은 CUDA_VISIBLE_DEVICES를 비우고, Hugging Face·Transformers의 오프라인 모드와 WANDB_MODE=disabled를 설정합니다. tests/recipes/retrieval_ci/run.py의 RequireCoverage는 테스트가 건너뛰어져도 실패하도록 만듭니다.

비싼 GPU 계산을 돌리기 전에, 설정과 파일 경로와 단계 간 약속부터 검증할 수 있습니다. 이 CI는 그런 계약을 검사하는 사례이며, 모델 정확도나 전체 학습 성공을 증명하는 검사는 아닙니다.

7하드웨어 / 시스템 요구사항

이 허브 전체를 대표하는 최소 사양 하나는 없습니다. API를 호출하는 노트북과 모델을 직접 올리는 추론, 분산 학습 레시피가 함께 있기 때문입니다. 아래에서 “소스의 기본값”과 “설명상의 권장 조건”을 구분합니다.

7-1. “활성 파라미터”로 메모리를 계산하면 안 된다

Nano3 레시피 README는 총 31.6B, 활성 3.6B 파라미터를 구분합니다. MoE는 한 토큰 계산에 일부 전문가를 선택하지만, 선택되지 않은 전문가의 가중치가 모델에서 사라지는 것은 아닙니다.

# BF16 가중치만 놓고 계산한 단순 추정
가중치 바이트 수 ≈ 전체 파라미터 수 × 2

9B    × 2바이트 ≈ 18.0GB  ≈ 16.8GiB
31.6B × 2바이트 ≈ 63.2GB  ≈ 58.9GiB

# 포함되지 않은 것
추론: KV 캐시 또는 모델별 상태, 작업 버퍼, 엔진 오버헤드
학습: 그래디언트, 옵티마이저 상태, 활성값 등

위 계산은 파라미터 수를 단순화한 가중치 용량 추정입니다. 실행 가능한 최소 VRAM을 보증하지 않습니다. 특히 Mamba와 attention이 섞인 모델은 모든 상태를 동일한 Transformer KV 캐시 공식으로 설명하기 어렵습니다.

MoE의 활성 파라미터 수가 작아도, 전체 모델의 저장·배치 비용까지 같은 비율로 줄어드는 것은 아닙니다.

7-2. 운영체제와 GPU 환경을 구분하자

소스 읽기와 API 클라이언트 학습에는 CUDA가 필요 없습니다. 반면 GPU 선택 의존성의 cupy-cuda12x·cudf-cu12 등에는 Linux·x86_64 조건이 붙어 있습니다. 이 레시피의 NVIDIA GPU 실행 경로를 macOS의 Metal 환경과 동일하게 가정할 수 없습니다.

루트 패키지는 Python 3.11~3.13 범위를 허용하지만, vLLM 9B 노트북은 Python 3.10 환경을 설명합니다. 이는 서로 다른 실행 경로의 안내입니다. 노트북의 설명을 루트 패키지 설치 조건으로 그대로 가져오지 마세요.

7-3. 메모리 외에 빠뜨리기 쉬운 자원

src/nemotron/recipes/nano3/stage2_rl/config/tiny.yaml조차 프롬프트당 생성 수 16, 최대 전체 시퀀스 길이 49152, 최대 스텝 수 1000000을 지정합니다. 최대 스텝이 실제 실행 횟수를 뜻하는 것은 아니지만, 파일명만으로 짧고 저렴한 실행을 기대할 근거도 없습니다.

8직접 해볼 수 있는 실습 과제

다음 다섯 과제는 파일 읽기와 손계산만으로 수행할 수 있습니다. 난이도는 계산량보다 서로 다른 파일의 관계를 얼마나 연결해야 하는가를 기준으로 정했습니다.

노트북은 JSON 파일이므로 표준 라이브러리만으로 코드 셀을 읽을 수 있습니다. 아래 명령은 저장소 루트에서 내용을 출력할 뿐, 노트북 코드를 실행하지 않습니다.

python3 - <<'PY'
import json
from pathlib import Path

path = Path("usage-cookbook/Nemotron-Nano-9B-v2/vllm_cookbook.ipynb")
notebook = json.loads(path.read_text(encoding="utf-8"))
for index, cell in enumerate(notebook.get("cells", [])):
    if cell.get("cell_type") == "code":
        print(f"\n셀 {index}")
        print("".join(cell.get("source", [])))
PY

# 설명용 입력. 실제 클러스터 설정이 아니다.
레시피 YAML:
  run.env.nodes = 8
  run.env.gpus_per_node = 8
  run.env.env_vars.FROM_CONFIG = "1"

환경 프로필:
  nodes = 1
  partition = "batch"
  env_vars.FROM_PROFILE = "1"

CLI 변경:
  run.env.nodes=2

정답에서는 두 환경변수도 모두 남습니다. 이 결과를 “프로필이 항상 우선” 또는 “YAML이 항상 우선”이라는 한 문장으로 줄일 수 없는 이유를 적어 보세요.

9관련 기술 심화 학습 로드맵

주당 3~5시간 정도의 읽기 중심 학습 계획입니다. 시간을 채우는 것보다 매주 적힌 산출물을 남기는 것이 중요합니다. GPU 학습 실행은 이 로드맵의 필수 조건이 아닙니다.

9-1. 기초 지식이 부족할 때의 우회 경로

Python이 낯설면 먼저 함수·클래스·모듈 import·타입 힌트·파일 읽기를 익힙니다. ML이 낯설면 토큰·가중치·loss·배치·추론과 학습 차이를 먼저 정리합니다. 분산 시스템은 프로세스와 노드, 작업 제출과 실제 계산의 차이부터 이해하면 됩니다.

9-2. 관심 분야에 따른 다음 경로

마지막에는 같은 입력·같은 평가 기준을 두고 무엇 하나만 바꾼 실험을 설계해 보세요. 측정 방법이 정해지지 않았다면, 구현을 늘리기 전에 무엇을 비교하려는지부터 다시 적는 편이 좋습니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 문서

• NVIDIA-NeMo/Nemotron 공식 저장소
• Nemotron 공식 문서 — 최신 문서는 분석한 커밋과 달라질 수 있습니다.
• v0.2.0 릴리스
• Nano3 학습 안내
• 학습·미세조정 FAQ
• 학습 규모 산정 방법과 가정
• Nemotron 3 Nano 기술 보고서

11-2. 이 글의 핵심 코드 출처

• 패키지·의존성·선택 환경·빌드 설정
• 사전학습 명령과 실행기 선택
• 사전학습 런타임과 실행 명세
• 이름과 실제 학습 대상이 다른 tiny 설정
• SFT 데이터 준비와 Parquet 패킹
• SFT 데이터 경로와 학습 구성
• RL 진입점과 체크포인트 형식 변환
• 사전학습·SFT 묶음 실행의 범위
• 아티팩트 추적 백엔드 선택
• 오프라인 CPU 계약 검사 CI
• vLLM 로딩·생성·스트리밍·도구 호출 노트북

11-3. 관련 기술 공식 자료

• Megatron-Bridge · NeMo-RL · NeMo-Run
• vLLM 문서 · Transformers 문서
• PyTorch 문서 · Ray 문서
• OmegaConf 문서 · Pydantic 문서
• PEP 723 명세 · uv 문서

현재 상태 (2026-10-23 확인)