uzu 딥다이브
— AI의 다음 한 토큰이 나오기까지

1프로젝트 한줄 요약

uzu는 이미 학습된 AI 모델을 기기에서 실행하고, 그 결과를 앱이 쓰기 좋은 대화·분류 API로 바꾸는 Rust 라이브러리입니다. 모델을 처음부터 훈련하는 프로젝트와는 목적이 다릅니다. 모델의 가중치를 읽고, 입력에 맞는 계산을 수행하고, 다음 토큰을 선택하는 일이 중심입니다.

이 저장소에서 배울 핵심은, 한 줄의 대화 요청을 실제 하드웨어 연산으로 바꾸는 여러 계층의 연결 방식입니다. 사용자 인터페이스를 만들 사람도, Rust를 배울 사람도, GPU에 관심 있는 사람도 각자 시작할 입구가 있습니다.

사용자 관점의 흐름은 다섯 단계입니다

1. Engine::new로 설정·저장소·모델 목록·백엔드를 준비합니다.
2. engine.model로 모델을 찾고 engine.download로 필요한 파일을 받습니다.
3. engine.chat으로 대화 세션을 만듭니다.
4. session.reply 또는 스트리밍 API에 메시지를 전달합니다.
5. 토큰 출력을 대화 메시지로 해석해 앱에 돌려줍니다.

// README의 Rust Quick Start와 같은 대화 호출 흐름
// model은 조회·다운로드를 마친 값이라고 가정합니다.
let session = engine.chat(model, ChatConfig::default()).await?;
let messages = vec![
    ChatMessage::user().with_text("추론 엔진을 쉽게 설명해 줘".to_string()),
];
let replies = session.reply(messages, ChatReplyConfig::default()).await?;
if let Some(reply) = replies.last() {
    println!("{}", reply.message.text().unwrap_or_default());
}

위 코드는 흐름을 보여주는 부분 예시입니다. 가져오기 선언과 초기화까지 포함한 예시는 README의 Quick Start에 있습니다. 실제 앱에서는 다운로드 실패, 모델 부재, 사용자의 취소도 처리해야 합니다.

2왜 주목받는가

uzu는 2026-10-23 분석 대상인 GitHub Trending Rust Weekly #6입니다. 다만 이 순위만으로 특정 기능이 유행을 만들었다고 단정할 수는 없습니다. 여기서는 코드와 배포 구성이 보여주는 관심을 끌 만한 지점을 해석합니다.

2-1. 로컬 추론을 앱 기능으로 묶습니다

GPU 계산 라이브러리만 있어도 제품을 만들기는 어렵습니다. 모델 목록, 다운로드 진행률, 대화 상태, 토큰 스트림이 추가로 필요합니다. crates/legacy/uzu/src/engine/mod.rs의 Engine::new는 이 기능들을 묶습니다. apps/mirai-gui의 데스크톱 앱과 apps/uzu-pi-extension의 코딩 에이전트 확장은 같은 엔진을 사용하는 응용 사례입니다.

앱 제작자에게는 이 결합이 장점입니다. 연산 커널의 속도뿐 아니라, 다운로드부터 취소까지 이어지는 사용 경험을 하나의 엔진 위에서 만들 수 있습니다. 다만 모델 형식과 하드웨어 지원 범위를 먼저 맞춰야 그 장점이 성립합니다.

2-2. Apple 메모리 구조를 실제 버퍼 설계에 반영합니다

MetalDenseBuffer::new는 MTLResourceOptions::STORAGE_MODE_SHARED로 버퍼를 만듭니다. CPU와 GPU가 공유할 수 있는 자원을 사용하고, residency set에 등록해 GPU 접근을 관리합니다. “통합 메모리를 활용한다”는 설명이 실제 코드의 자원 생성 방식으로 이어지는 지점입니다.

공유 메모리가 계산이나 동기화 비용을 없애 주지는 않습니다. 특히 긴 대화는 KV 캐시를 키우므로, 가중치 파일이 메모리에 들어간다고 해서 모든 길이의 대화를 처리할 수 있는 것은 아닙니다.

2-3. 경쟁 도구와 비교하면 학습 목적이 선명해집니다

비교 근거는 각 프로젝트의 공식 설명인 llama.cpp 저장소, MLX 소개, vLLM 소개입니다. 위 표는 용도 비교이며 속도 순위가 아닙니다. 같은 모델·양자화·문맥 길이·기기에서 측정한 공통 수치는 제시하지 않습니다.

3기술 스택 전체 지도

아래 버전은 커밋 637cf10의 의존성 선언 기준입니다. Cargo의 "1.53.3", npm의 ^18.3.1, Python 패키지의 >=2.10.0은 각각 허용 범위를 나타냅니다. 설치 결과를 재현할 때는 해당 잠금 파일도 함께 봐야 합니다.

3-1. 백엔드: Rust가 관리하고 CPU·Metal이 계산합니다

# crates/uzu-engine/Cargo.toml의 기본 기능
[features]
default = ["cpu", "metal", "grammar"]
cpu = []
# metal과 grammar에는 선택적 의존성 묶음이 연결됩니다.

# crates/legacy/uzu/Cargo.toml의 공개 기능 이름
default = ["backend-cpu", "backend-metal", "capability-grammar"]
backend-cpu = ["uzu-engine/cpu"]
backend-metal = ["uzu-engine/metal"]
capability-grammar = ["uzu-engine/grammar"]

공개 패키지와 코어의 기능 이름이 다릅니다. backend-metal은 내부의 metal을 켜는 연결선입니다. 또한 기능을 켜는 것과 해당 운영체제에서 실제 백엔드가 생성되는 것은 별개입니다. 그 최종 분기를 crates/uzu-engine/build/main.rs가 처리합니다.

3-2. 언어 바인딩: Rust 타입을 다른 언어에 노출합니다

선언 출처는 루트 Cargo.toml, Python pyproject.toml, TypeScript package.json입니다. Python 패키지는 Python 3.12 이상을 요구합니다.

3-3. 프론트엔드: 엔진 위의 데스크톱 제품

apps/mirai-gui/package.json은 React ^18.3.1, Zustand ^4.5.7, TanStack React Router ^1.170.41, Vite ^5.4.21, TypeScript ^5.9.3, Tailwind CSS ^4.3.3을 선언합니다. Rust 데스크톱 셸은 Tauri 2.12.4입니다. 추론 코어 자체가 React에 의존하는 구조는 아닙니다.

화면의 apps/mirai-gui/client/src/platform/services/models/tauri.ts는 명령 호출과 이벤트 구독으로 데스크톱에 연결됩니다. 같은 위치의 apps/mirai-gui/client/src/platform/services/models/web.ts는 모델 목록을 빈 배열로 돌려주고 다운로드를 거부합니다. 따라서 브라우저 화면이 열린다는 것만으로 웹 추론까지 구현됐다고 판단하면 안 됩니다.

3-4. 인프라·빌드: 연산 코드도 빌드 파이프라인의 일부입니다

의존성 목록은 외울 대상이 아니라, 어느 계층에서 어떤 책임을 맡는지 찾는 지도입니다. 먼저 코어, 공개 API, 바인딩, 앱, 개발 도구의 다섯 칸으로 나누면 긴 설정 파일도 읽기 쉬워집니다.

4아키텍처 심화 분석

4-1. 전체 시스템 구조

다음은 모든 모듈을 나열한 그림이 아니라, 로컬 언어 모델의 대화 경로를 중심으로 정리한 구조입니다. 원격 모델을 선택하면 같은 공개 엔진에서 별도의 backend-remote 경로로 연결됩니다.

모델 목록과 파일 다운로드는 계산 코어 바깥에 있습니다. 코어의 load_language_model은 이미 존재하는 모델 디렉터리를 받습니다. 이 경계 덕분에 파일을 얻는 정책과 파일을 계산하는 구현을 따로 읽을 수 있습니다.

4-2. 설계 패턴 ①: 백엔드 추상화와 경계에서의 선택

crates/uzu-engine/src/backends/common/backend.rs의 Backend 트레이트는 계산 문맥, 명령 버퍼, 여러 버퍼 타입, 커널 묶음을 연관 타입으로 지정합니다. LanguageModel<B>는 이 약속을 통해 CPU와 Metal의 구체 타입을 바꾸어 사용합니다.

// Backend의 선언 중 일부만 발췌
pub trait Backend: Clone + Send + Sync + 'static {
    type Context: Context<Backend = Self>;
    type CommandBuffer: CommandBuffer<Backend = Self>;
    type GlobalBuffer: GlobalBuffer<Backend = Self>;
    type Kernels: Kernels<Backend = Self>;
    // 나머지 연관 타입과 상수 생략
}

crates/uzu-engine/src/backends/mod.rs의 select_backend는 컴파일된 백엔드 중 하나를 고릅니다. 기본은 Metal 백엔드가 컴파일되어 있으면 Metal, 그렇지 않으면 CPU입니다. UZU_BACKEND 환경변수로 선택을 바꿀 수 있지만, 컴파일하지 않은 백엔드를 새로 만들어 주지는 않습니다. 알 수 없는 값이나 컴파일되지 않은 백엔드를 지정하면 호출자가 넘긴 오류를 반환합니다.

공개 계층의 ChatTokenInstanceSelection::select<B>는 구체 타입의 인스턴스를 만든 뒤 Box<dyn ChatTokenInstance>로 감쌉니다. 하드웨어별 구현은 제네릭으로 구체화하고, 상위 API의 접점에서는 공통 인터페이스로 다루는 방식입니다.

읽을 파일: 백엔드 선택, 공개 엔진과 코어 사이 브리지.

4-3. 설계 패턴 ②: 모델과 대화 상태를 분리합니다

LanguageModel<B>에는 디코더, 토크나이저, 기본 생성 설정, 선택적 추측기가 있습니다. LanguageModelState<B>에는 누적 토큰, 난수 상태, Transformer 상태, 마지막 출력 토큰이 있습니다. 공유할 계산 재료와 요청 흐름에 따라 달라지는 기록을 구분한 것입니다.

// 실제 API 시그니처: 하나의 스트림이 가변 상태를 빌립니다.
pub fn stream<'a>(
    &'a self,
    input: &[u64],
    state: &'a mut LanguageModelState<B>,
    options: LanguageModelStreamOptions,
) -> Result<LanguageModelStream<'a, B>, LanguageModelStreamError<B>>

&self는 모델을 읽기용으로 빌리고, &mut state는 해당 상태를 독점해서 변경하겠다는 뜻입니다. 이 함수의 사용 범위에서는 동일한 상태를 두 스트림이 동시에 가변으로 빌릴 수 없습니다. 다만 이것만으로 요청 스케줄링이나 모든 GPU 동시성 문제가 해결되지는 않습니다.

모델 로딩은 파일 세 개를 여는 데서 끝나지 않습니다

1. Engine::load_language_model이 config.json을 LanguageModelConfig로 읽습니다.
2. ParameterLoader::new가 model.safetensors의 헤더 길이와 JSON 헤더를 읽습니다.
3. Tokenizer::from_file이 tokenizer.json을 읽고, Decoder::new가 필요한 가중치를 요청합니다.
4. 이 로딩 경로의 기본 계산 자료형은 DataType::BF16입니다. 저장된 모든 가중치가 비양자화 BF16이라는 뜻은 아닙니다.
5. assert_all_tensors_read가 읽지 않은 텐서가 남았는지 확인합니다.

ParameterTree::tensor는 이름뿐 아니라 예상 모양과 자료형도 비교합니다. 바이트 구간의 길이가 예상 크기와 맞는지도 검사합니다. 파일이 열렸다는 사실과 모델에 맞는 파일이라는 사실을 나눠 검증하는 사례입니다.

읽을 파일: 모델 로딩, 대화 상태, 가중치 검증.

KV 캐시도 독립된 저장 전략을 갖습니다

crates/uzu-engine/src/encodable_block/mixer/attention/kv_storage.rs의 KVStorage는 BF16과 Int8 저장 방식을 구분합니다. Int8에는 코드 버퍼 외에 스케일 버퍼가 따로 있습니다. create_kv_buffer는 기기가 SPARSE_BUFFERS를 지원하면 희소 버퍼를, 아니면 일반 버퍼를 만듭니다.

KVStorage::prepare는 희소 버퍼의 필요한 앞부분을 매핑합니다. 최대 공간을 표현하는 것과 그 공간에 물리 메모리를 모두 붙이는 것을 분리하는 방식입니다. 이 기능이 있다고 사용 중인 대화의 메모리 비용이 사라지는 것은 아닙니다.

4-4. 설계 패턴 ③: 스트리밍을 상태 머신으로 만듭니다

LanguageModelStream은 단순히 반복문에서 문자열을 내보내는 객체가 아닙니다. DecodingState로 다음 연산의 진행 상태를 표현하고, generate를 호출할 때 상태를 전이합니다. GPU 작업이 제출됐지만 아직 끝나지 않은 경우도 타입의 한 상태로 다룹니다.

LanguageModelStream::new는 상태와 입력이 모두 비어 있으면 NoSeedToken, 합친 길이가 제한을 넘으면 ContextOverflow를 반환합니다. 입력이 있으면 먼저 prefill을 수행하며, 이 구현은 입력을 최대 1024토큰 단위로 나눕니다. 이 값은 현재 attention 구현의 제약과 연결되어 있다는 주석도 있습니다.

공개 브리지의 UzuChatTokenBackendInstance::stream은 취소 토큰과 생성 한도를 검사합니다. 취소, 한도 도달, 정상 종료, 오류의 경로마다 내부 스트림의 close().await를 호출하는 처리가 있습니다. 생성 루프뿐 아니라 정리 경로도 API의 일부입니다.

Drop for LanguageModelStream은 아직 닫히지 않은 스트림을 block_on(self.close())로 정리합니다. 자원 회수를 보조하지만, 소멸 과정에서도 대기가 발생할 수 있다는 뜻입니다. 비동기 자원을 설계할 때 명시적 종료 메서드가 왜 필요한지 보여 줍니다.

선택적 최적화: 여러 후보 토큰을 제안하고 확인합니다

모델 디렉터리에 speculator가 있으면 먼저 디코더의 추측 디코딩 지원 여부를 단언문으로 검사한 뒤 DFlashTfmSpeculator 로더를 호출합니다. 지원하지 않으면 단언문 실패로 패닉이 발생합니다. propose_tree는 후보 토큰 트리를 만들고, 생성 루프는 후보를 검사해 수락한 토큰과 상태를 반영합니다. 트리 예산과 최대 깊이도 별도 설정입니다.

이는 “한 번에 무조건 여러 토큰을 출력한다”는 약속이 아닙니다. 후보가 얼마나 채택되는지, 제안 비용이 얼마나 드는지에 따라 효과가 달라집니다. 모든 모델에 추측기가 들어 있는 것도 아닙니다.

구조화 출력: 문자열을 다 만든 뒤 검사하는 것보다 앞에서 개입합니다

crates/uzu-engine/src/engine/language_model/grammar/grammar.rs의 Grammar::new는 JSON Schema·정규식·기본 JSON 문법을 컴파일합니다. next_bitmask는 다음에 허용할 토큰을 비트마스크로 만들고, accept_token은 선택한 토큰에 따라 문법 상태를 갱신합니다.

문법에 맞는 JSON을 얻는 것과 내용이 사실에 맞는 것은 별개입니다. 예를 들어 숫자 필드를 보장해도 그 숫자가 정확한지는 앱이 검증해야 합니다. 또한 빌드 설정상 wasm32에서는 이 grammar 기능이 활성화되지 않습니다.

읽을 파일: 생성 상태 머신, 취소·한도·정리, 후보 트리, 문법 제약.

4-5. 설계 패턴 ④: 빌드 시 코드 생성으로 연산 경계를 연결합니다

crates/uzu-engine/build/main.rs의 main은 공통 GPU 타입을 수집한 뒤 CPU·Metal 컴파일러를 구성하고, 커널을 빌드한 결과로 traitgen_all을 호출합니다. Rust 타입과 커널 인자를 연결하는 반복 작업을 빌드 단계에서 처리하는 구조입니다.

Metal 컴파일러의 build와 compile은 타입·래퍼·바인딩 생성에 참여합니다. crates/uzu-engine/build/metal/toolchain.rs에서는 metal4.0 표준을 사용합니다. 커널 파일만 읽어서는 완성된 인터페이스의 출처를 모두 찾을 수 없는 이유입니다.

실행 중에도 모든 행렬에 같은 GPU 구현을 적용하지는 않습니다. GemmProblem::select_plan은 Trellis 형식 여부, MXU 지원 여부, 행렬 모양과 GPU 계열을 바탕으로 계획을 고릅니다. 빌드할 수 있는 후보를 준비하는 단계와 현재 입력에 맞는 후보를 고르는 단계가 함께 있습니다.

읽을 파일: 빌드 진입점, Metal 컴파일러, GEMM 실행 계획 선택.

성능 코드를 읽을 때는 계산식뿐 아니라, 상태의 소유자와 작업 완료를 기다리는 위치를 함께 찾아야 합니다. uzu의 큰 그림은 이 두 질문으로 다시 정리할 수 있습니다.

5디렉토리 구조 해부

5-1. legacy는 읽지 않아도 되는 폴더일까요?

아닙니다. 루트 Cargo.toml은 이 구역에 to be rewritten이라는 주석을 붙이지만, 현재 워크스페이스 구성원으로 포함합니다. GUI도 이 안의 공개 uzu 패키지를 사용합니다. 폴더 이름은 개편 방향을 알려줄 뿐, 현재 실행 경로에서 제외됐다는 증거가 아닙니다.

5-2. 확장자별 코드 규모

커밋 637cf10 기준 확장자별 파일 수와 물리적 줄 수입니다. 빈 줄·주석·테스트·생성된 바인딩을 포함하고, .git은 제외했습니다. 실행 코드만 센 수치나 GitHub 언어 비율과는 다릅니다.

Rust 안에서는 crates/uzu-engine이 43,041줄, crates/legacy가 54,210줄, 나머지가 7,487줄입니다. “작은 코어에 얇은 포장만 붙은 프로젝트”라고 보기에는 앱 통합 계층도 상당한 비중을 차지합니다.

6학습 포인트 (기술별)

6-1. 첫 GPU 학습은 attention보다 작은 커널에서 시작하세요

crates/uzu-engine/unit/backends/common/kernel/tensor_add_scale_test.rs를 먼저 읽어 보세요. 입력과 편향 버퍼를 만들고, 명령을 인코딩하고, 제출·완료 대기를 한 뒤 결과를 읽습니다. 작은 연산으로도 GPU 프로그램의 전체 생애를 볼 수 있습니다.

// 테스트에서 사용하는 명령 버퍼 처리 흐름
// 앞에서 커널 인코딩과 출력 버퍼 준비를 마친 부분 예시입니다.
block_on(command_buffer.end_encoding().submit().wait_until_completed()).unwrap();

// 결과를 읽는 시점은 완료 대기 뒤입니다.
buffer_to_vec::<B, T>(&output_buffer)

crates/uzu-engine/unit/common/assert.rs의 assert_eq_float는 배열 길이를 확인하고 각 원소의 절대 오차를 eps와 비교합니다. 모든 부동소수점 연산을 무조건 정확히 같은 비트로 비교하지 않는 이유를 생각해 보세요. 어떤 커널에는 절대 오차만으로 충분하지 않을 수도 있습니다.

6-2. 테스트는 구현이 지키려는 약속을 보여 줍니다

crates/uzu-engine/unit/encodable_block/sampling_test.rs는 난수 입력과 시드를 만들고, 여러 백엔드의 샘플링 결과를 CPU 기준 결과와 비교하는 구조를 갖습니다. ComparableTestResults::compare에서 결과를 어떻게 판정하는지 먼저 보면 복잡한 입력 생성 코드의 목적이 보입니다.

crates/uzu-engine/unit/encodable_block/kv_cache_state_test.rs의 ring_accept_over_capacity_keeps_last는 용량을 넘긴 링 캐시에 최근 항목이 남는 상황을 검사합니다. 이름만 읽고 끝내지 말고, source와 destination 숫자를 칸 그림으로 옮겨 보세요.

6-3. 프론트엔드 개발자도 배울 경계가 있습니다

apps/mirai-gui/client/src/platform/platform-singleton.ts의 initPlatform은 중복 초기화를 거부하고, getPlatform은 초기화 전 접근을 거부합니다. 전역 객체를 아무 때나 쓰기보다 초기화 순서를 계약으로 만든 예입니다. 웹 구현의 “이용 불가” 응답도 그 계약 안에 들어갑니다.

연산 엔진을 몰라도 “화면은 어떤 능력을 요청하고, 플랫폼은 무엇을 보장하는가”를 읽을 수 있습니다. 이 원리는 브라우저·데스크톱·모바일을 함께 지원하는 일반 앱에도 적용됩니다.

좋은 학습의 단위는 파일 하나를 다 읽는 것이 아니라, 입력·출력·불변 조건 하나를 끝까지 설명하는 것입니다.

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

근거: GUI 요구사항, Swift 플랫폼 설정, Metal 도구 체인. GUI README는 Node 26 이상을 요구하지만 package.json의 최소 선언은 22.19입니다. 실제 개발 환경을 맞출 때는 이 차이도 확인해야 합니다.

7-1. “CPU가 있다”는 말의 범위를 제한해서 읽으세요

crates/uzu-engine/src/backends/cpu/kernel/matmul/reference.rs의 WeightData::from_b는 MatmulB::Trellis를 UnsupportedLayout 오류로 반환합니다. CPU 코드가 존재해도 모든 양자화 형식과 모델 경로를 지원하는 것은 아닙니다. 하드웨어 이름뿐 아니라 모델의 가중치 표현도 호환성 조건입니다.

문서 원본 docs/index.mdx의 FAQ는 현재 지원 기기를 Apple silicon의 iOS·macOS로 더 좁게 안내합니다. README의 대상 목록, npm의 x64 선언, 문서의 제품 지원 범위가 같은 수준의 약속은 아닙니다.

CI에는 Linux CLI 빌드와 WASI 스레드 대상의 커널 테스트가 있습니다. 이 검증 범위와 Windows를 포함한 모든 대상의 제품 수준 지원을 같은 것으로 읽으면 안 됩니다. rust-toolchain.toml의 target 목록은 필요한 도구를 설치할 목록이기도 합니다.

7-2. 메모리는 가중치 + 캐시 + 임시 공간으로 계산하세요

고정된 “최소 RAM 몇 GB”를 모든 모델에 적용할 수는 없습니다. 출발점으로 다음 근삿값을 계산할 수 있습니다. 아래는 특정 uzu 모델의 실측값이 아닌 일반적인 크기 계산 예입니다.

# 이상적인 가중치 데이터 크기
파라미터 수 × 파라미터당 비트 수 ÷ 8

0.8B × 4비트 ÷ 8 = 약 0.4 GB
4B   × 4비트 ÷ 8 = 약 2.0 GB
7B   × 4비트 ÷ 8 = 약 3.5 GB

# BF16 KV 캐시의 단순 추정: 전체 attention 층에 같은 구조를 가정
2 × 레이어 수 × KV 헤드 수 × 헤드 차원 × 토큰 수 × 2바이트

2 × 24 × 8 × 128 × 4096 × 2 = 384 MiB

가중치 예시의 GB는 10억 바이트, 캐시 예시의 MiB는 2의 20제곱 바이트입니다. 실제 양자화 파일에는 스케일·보조 정보가 붙고, 실행 시에는 활성값·임시 버퍼·토크나이저·운영체제 메모리도 필요합니다. 서로 다른 attention·mixer를 섞는 모델에는 위 캐시 공식을 그대로 적용할 수 없습니다.

7-3. 권장 문맥 길이도 정밀한 메모리 모델은 아닙니다

LanguageModel::recommended_context_length는 희소 버퍼 지원 시 모델의 최대 문맥 길이를 반환합니다. 지원하지 않고 최대 길이가 유한하면 iOS에서는 8192, 그 외에는 16384와 모델 한도 중 작은 값을 고릅니다.

소스 주석도 이를 정식 메모리 모델이 아닌 단순한 접근이라고 설명합니다. 이 값이 모든 기기에서 메모리 부족을 막아 주는 보장은 아닙니다. iOS에 대해서는 README가 Increased Memory Capability와 여러 모델을 동시에 유지하지 않는 사용 방식을 권합니다.

모델 파일이 들어가는지와 대화를 끝까지 생성할 수 있는지는 서로 다른 메모리 질문입니다.

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

다음 과제는 모델 설치 없이 시작할 수 있습니다. 처음부터 대규모 엔진을 수정하려 하기보다, 호출 경로·오류 조건·작은 시뮬레이터를 통해 이해를 확인하세요.

# 저장소 루트에서 실행하는 읽기 전용 검색 예시
rg -n 'pub async fn chat|pub async fn chat_instance' crates/legacy/uzu/src/engine/mod.rs
rg -n 'select_backend|impl BackendSelection' crates/legacy/uzu/src/engine/bridge/backend.rs
rg -n 'load_language_model|assert_all_tensors_read' crates/uzu-engine/src/engine/language_model/mod.rs

# 과제 4의 언어 독립적인 의사코드
반복:
    취소되었으면:
        정리하고 종료
    생성 개수가 한도에 도달했으면:
        정리하고 한도 도달 알림
    다음 항목을 요청
    오류 또는 정상 끝이면:
        정리하고 종료
    항목 전달 후 생성 개수 증가

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

주당 3~5시간을 가정한 학습 순서입니다. 익숙한 주제는 건너뛰어도 되지만, 매주 작은 설명 자료 하나는 남기세요. 모델 수학 전체를 먼저 공부하지 않아도 작은 연산·상태·인터페이스부터 이해를 넓힐 수 있습니다.

시간이 더 있다면 두 갈래로 확장하세요

학습의 목표는 코드를 전부 기억하는 것이 아니라, 새 기능을 넣을 때 바꿀 계층과 지켜야 할 계약을 찾는 능력입니다.

10핵심 키워드 사전

11참고 링크

공식 저장소와 제품 문서

• uzu 공식 저장소 — README, 이슈, 릴리스의 시작점입니다.
• 분석 기준 커밋의 소스 트리 — 본문의 경로와 구현을 같은 시점에서 확인할 수 있습니다.
• uzu 공식 문서 — 현재 API 사용법은 이 문서와 해당 버전 예시를 함께 확인하세요.
• 공식 릴리스 목록 — 버전별 배포 정보와 변경 내용을 확인하는 곳입니다.
• 분석 시점 README — 언어별 Quick Start와 모델 형식·개발 안내의 근거입니다.

핵심 코드를 다시 찾는 링크

• Backend 트레이트 — 백엔드별 타입을 연결하는 약속입니다.
• Decoder::encode — 임베딩에서 Transformer·출력 점수까지 이어집니다.
• KVStorage — 저장 형식과 희소 버퍼 분기를 확인할 수 있습니다.
• KV 캐시 상태 테스트 — 작은 입력의 기대 결과부터 읽기 좋습니다.
• CI 설정 — 어떤 플랫폼·기능을 어떤 검사로 확인하는지 보여 줍니다.
• Nix 환경 설정 — HEAD의 Metal 도구 체인 변경과 개발 도구 목록을 확인할 수 있습니다.

관련 기술의 공식 학습 자료

• Rust 공식 책: 트레이트 — 백엔드 추상화를 읽기 위한 기초입니다.
• Tokio 공식 튜토리얼 — 비동기 실행, 공유 상태, 채널·스트림을 배울 수 있습니다.
• Apple Metal 공식 안내 — GPU 계산과 도구의 전체 입구입니다.
• Hugging Face Tokenizers 문서 — 토큰 변환과 토크나이저 파일을 이해할 때 참고하세요.
• Hugging Face Safetensors 문서 — 텐서 저장 형식의 배경을 확인할 수 있습니다.
• MLX 공식 소개 — Apple 통합 메모리를 활용하는 다른 설계를 비교할 수 있습니다.
• llama.cpp 공식 저장소 · vLLM 공식 소개 — 로컬 추론과 서빙의 서로 다른 설계 초점을 비교하세요.

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