Strata 딥다이브
— 거대한 AI를 작은 그래픽카드에 나누어 담는 법

1프로젝트 한줄 요약

Strata는 Qwen3.8-Flash-Next 계열을 소비자용 하드웨어에서 실행하고, 로컬 API와 앱으로 제공하는 추론 엔진·제품 묶음입니다. README는 기본 모델을 1,250억 매개변수라고 소개합니다. 여기서 매개변수는 모델이 학습해 둔 숫자입니다. 숫자가 많을수록 저장 공간도 커지지만, MoE에서는 매 토큰마다 모든 전문가를 계산하지 않습니다.

Strata를 이해하는 핵심은 모델을 통째로 줄이는 것보다, 지금 필요한 가중치를 어디에 두고 어느 장치에서 계산할지 결정하는 데 있습니다. 양자화로 저장량을 줄이는 일과 CPU·GPU에 작업을 나누는 일은 서로 다른 최적화이며, 이 저장소는 둘을 함께 사용합니다.

사용자가 보는 세 가지 입구

API에는 /v1/chat/completions, /v1/messages, /v1/responses 처리 경로가 있습니다. 이는 요청·응답 형식의 호환성을 뜻합니다. OpenAI나 Anthropic의 원격 모델을 그대로 실행한다는 뜻은 아닙니다.

이미지 입력은 별도 인코더 strata-vision을 통해 임베딩으로 들어옵니다. 저장소에는 선택적인 이미지 생성 경로도 있지만, 이 글의 중심은 텍스트·이미지 입력을 받는 로컬 언어 모델 서빙입니다.

2왜 주목받는가

2-1. 큰 모델과 작은 VRAM 사이의 간격을 다룹니다

TrendShift Monthly #6 선정과 스타 30,770개는 이 글의 선정 근거입니다. 다만 스타 수만으로 사용률이나 성능을 증명할 수는 없습니다. 다음 세 가지는 README와 구현에서 읽어 낸 주목 요인에 대한 해석입니다.

1. 메모리를 나누어 쓴다: 전문가를 전부 VRAM에 넣지 않고 RAM·CPU 계산과 결합합니다.
2. 기존 도구에 연결한다: 여러 API 형식을 지원해 앱과 코딩 도구가 같은 로컬 엔진을 이용하게 합니다.
3. 배포까지 묶었다: 엔진 외에도 하드웨어 감지, 모델 선택, 다운로드, 모니터링, 데스크톱 창을 제공합니다.

이 저장소의 차별점은 범용 모델 목록의 크기보다, 특정 모델 계열을 제한된 메모리에 맞추는 실행 경로와 배포 경험을 함께 설계했다는 점입니다.

2-2. 경쟁 도구와 비교할 때는 비교 축부터 고릅니다

아래 표는 성능 순위가 아닙니다. Strata에서 확인한 설계와 다른 선택지의 대표적인 용도를 나란히 놓은 표입니다. 실제 도입 시에는 각 제품의 공식 문서에서 필요한 모델과 기능의 지원 여부를 확인해야 합니다.

소스 연결점도 있습니다. apps/host/server/inference.mjs의 detectBackend()는 Strata 작업자를 먼저 찾고, 다른 로컬 OpenAI 호환 서버도 식별합니다. C++ 엔진은 ggml의 CPU 백엔드와 일부 GPU 연산을 활용합니다. 독자 엔진과 외부 기술 재사용이 함께 존재합니다.

2-3. 빠르다는 주장은 조건과 함께 읽어야 합니다

README는 RTX 5070 12GB, Ryzen 5 7600, RAM 64GB에서 Q2_0 출력 약 94 tokens/s, 프롬프트 처리 약 2,650 tokens/s를 제시합니다. 이 수치는 README에 실린 프로젝트 측 측정값이며, 하드웨어·모델·설정에 따라 달라집니다.

docs/DETAILS.md의 주요 성능 표에서 NVIDIA 수치는 엔진 0.1.26 측정이고, 별도 문단은 0.1.36 개선을 설명합니다. 현재 엔진 버전은 0.1.47이므로, 모든 표를 최신 바이너리의 보장값으로 읽으면 안 됩니다. bench/results/에는 하드웨어·버전별 결과가 있으니 비교 조건을 맞추는 연습에 적합합니다.

3기술 스택 전체 지도

3-1. 백엔드: C++ 계산 엔진 + Python API + Node 제품 호스트

NumPy는 Python 버전에 따라 다르게 고정됩니다. requirements.txt는 Python 3.12 이상에 numpy==2.5.3, 3.11에 2.4.6, 그 미만에 2.2.6을 지정합니다. 같은 저장소라도 인터프리터 버전이 의존성 선택을 바꾼다는 사례입니다.

PyTorch는 일반 추론 경로의 필수 스택으로 쓰여 있지 않습니다. requirements-nvfp4-local.txt의 선택적 변환 도구에 torch==2.9.1 또는 Python 3.14 이상용 2.14.1, transformers==4.57.6, safetensors==0.7.0이 있습니다.

3-2. 프론트엔드와 데스크톱: 같은 웹 UI를 창으로 감쌉니다

의존성 파일의 허용 범위와 잠금 파일의 선택 결과를 구별하면, 문서의 버전 설명과 실제 빌드 환경 사이의 혼동을 줄일 수 있습니다. 예를 들어 React의 ^19.1.0을 보고 실제 설치 버전도 반드시 19.1.0이라고 단정하면 틀립니다.

apps/host/src/main.tsx는 createRoot()와 StrictMode로 앱을 시작합니다. apps/host/src/app/App.tsx의 AppShell()은 Chat·Setup·Serving·Monitor 등의 화면과 초기 설정 상태를 엮습니다. UI 소스는 apps/host/src/에 있습니다.

3-3. 인프라·빌드: 개발 환경과 배포 환경의 차이를 코드로 드러냅니다

• 빌드 도구: CMake 최소 3.24; Python 빌드 의존성은 cmake==4.4.3, ninja==1.13.2로 고정합니다.
• 소스 빌드 컨테이너: 루트 Dockerfile의 기본 CUDA 이미지는 nvidia/cuda:13.0.0-devel-ubuntu24.04입니다.
• 완성 패키지 컨테이너: docker/Dockerfile은 엔진 컴포넌트와 Terminal을 합칩니다. 기본 기반 이미지는 ubuntu:24.04이며 빌드 인자로 바뀔 수 있습니다.
• 사용자 데이터: 컨테이너는 /data 볼륨을 두고 8080 포트를 노출합니다. 엔진과 사용자 모델·상태의 수명을 분리합니다.

.github/workflows/terminal-minimal-server.yml은 Python 3.11에서 런타임 의존성만 설치하고 가짜 엔진 점검과 serve/test_*.py 모음을 실행하도록 정의합니다. .github/workflows/terminal-portable-monitor.yml은 Windows·Linux와 Python 3.10·3.11 조합을 사용합니다.

.github/workflows/scripts-test.yml의 Node 22는 GitHub 보조 스크립트 테스트용입니다. 이것을 앱의 Node 요구 버전으로 읽으면 안 됩니다. .github/workflows/docker-images.yml은 수동 실행이며 push 입력 기본값이 false입니다. 워크플로 정의를 읽었다는 사실과 해당 실행이 통과했다는 사실도 구별해야 합니다.

4아키텍처 심화 분석

아래는 설치형 앱의 주요 경로를 단순화한 구조입니다. CLI로 직접 서버를 시작하면 Tauri와 Node 호스트를 거치지 않는 경로도 있습니다. 포트는 실행 방식과 설정에 따라 달라지므로 서버·앱·API 중계의 주소를 구별해야 합니다.

4-1. 패턴 ① 어댑터와 프로세스 분리: API 형식과 계산을 분리합니다

serve/frontend.py의 openai_to_messages()와 anthropic_to_messages()는 서로 다른 요청을 메시지·도구·템플릿 인자로 정규화합니다. 예를 들어 OpenAI의 developer 역할은 system으로 바뀌고, Anthropic의 tool_use 블록은 내부 도구 호출 표현으로 변환됩니다.

이후 Service.encode_prompt()가 템플릿과 토크나이저를 이용해 토큰 ID를 만듭니다. Engine 프로토콜은 계산 장치 대신 generate()라는 동작을 약속합니다. 아래는 실제 인터페이스의 핵심 부분입니다.

# serve/server.py — API 계층이 엔진에 요구하는 계약
class Engine(Protocol):
    max_context: int
    def generate(self, ids: list[int], max_new: int,
                 sampling: dict, cancel: threading.Event) -> Iterator[int]: ...

StrataEngine은 C++ 실행 파일을 --serve로 한 번 시작한 뒤 표준 입출력 파이프로 재사용합니다. 매 질문마다 수십 GB의 가중치를 다시 적재하지 않는 구조입니다. MockEngine은 같은 계약으로 미리 정한 토큰을 돌려줘 API 동작을 GPU 없이 검사할 수 있게 합니다.

# 단일 요청용 파이프 프로토콜의 개념도 — 숫자는 설명용입니다
Python -> C++ : GEN 16 101 202 303
C++    -> Python : T 404
C++    -> Python : T 505
C++    -> Python : DONE ...
# 실제 요청에는 샘플링 키, 이미지 임베딩, 배치용 확장이 더 붙을 수 있습니다.

이 분리는 엔진 장애를 API 계층이 감지·복구할 여지를 주지만, 파이프 응답 대기, 비정상 종료, 취소, 자식 프로세스 정리가 새 책임으로 생깁니다. serve/lifeline.py의 popen()은 부모 종료 뒤 자식이 남는 문제를 다룹니다.

데스크톱에서도 같은 원리가 반복됩니다. Rust의 host_command()는 Node 실행 파일과 apps/host/server/index.mjs를 연결하고 STRATA_BIND=127.0.0.1을 지정합니다. 화면과 호스트의 수명, 호스트와 Python 작업자의 수명, 작업자와 C++ 엔진의 수명을 각각 관리합니다.

4-2. 패턴 ② 계층형 캐시: 저장 공간과 교체 정책을 분리합니다

ExpertCache는 전문가 데이터를 담는 VRAM 슬롯과 (layer, expert)를 슬롯으로 바꾸는 상주 표를 관리합니다. slot_of()는 범위를 검사해 슬롯 번호 또는 kNotResident를 반환합니다.

// src/core/expert_cache.cpp — admit()의 마지막 부분 발췌
if (next_free_ >= slots_) return kNotResident;
residency_[at] = (int32_t) next_free_;
return (int32_t) next_free_++;

여기에는 LRU 퇴출 코드가 없습니다. 빈자리가 없으면 등록을 거절합니다. set_per_layer_admission()을 켠 경우에는 층마다 슬롯 범위를 나눠, 앞쪽 층이 전역 슬롯을 먼저 독점하는 문제를 줄입니다. 이 역시 교체 정책과는 별개입니다.

src/core/expert_source.cpp의 expert_hit_run()은 선택된 전문가가 상주하면 GPU 작업으로 넣습니다. 상주하지 않더라도 빈 슬롯이 있으면 admit()과 fill_slot()로 공급합니다. 복사와 커널을 같은 스트림에 넣어 복사 완료 뒤 계산하도록 순서를 정합니다.

반면 대화에 맞춰 전문가를 바꾸는 일은 src/program/generate.cpp의 상위 적응 로직이 담당합니다. 코드의 기본 설정은 adapt_every=4, adapt_decay=0.7, adapt_min_gain=1.5입니다. 실행 옵션과 백엔드에 따라 적용 경로는 달라질 수 있습니다.

단일 생성 경로의 adapt 람다는 사용 빈도가 높은 비상주 전문가와 낮은 상주 전문가를 짝짓습니다. apply_pending 람다는 복사 완료 이벤트를 확인한 뒤 상주 표를 갱신합니다. 복사를 요청한 순간과 새 데이터를 사용할 수 있는 순간은 다릅니다.

docs/DETAILS.md는 RAM에 전문가를 두는 대표 구성을 설명하지만, 소스의 FileExpertSource와 저메모리 경로는 부족분을 파일에서 읽는 경우도 다룹니다. “모든 전문가가 언제나 RAM에 고정된다”는 문장으로 일반화하면 안 됩니다.

4-3. 패턴 ③ 추측 실행과 검증: 초안은 제안하고 본 모델이 확정합니다

한 번에 한 토큰만 계산하면 같은 가중치를 여러 번 읽게 됩니다. MTP 초안이나 이전 문맥에서 찾은 후속 토큰을 묶어 제안하고, 본 모델로 검증하면 한 번의 검증에서 여러 토큰을 확정할 기회가 생깁니다.

include/strata/spec/draft_policy.hpp와 src/spec/draft_policy.cpp의 DraftPolicy::choose()는 예상 확정 토큰 수 ÷ 실행 비용을 비교합니다. 기본 여유율 margin=0.03을 두어 lookup의 기대 효율이 MTP보다 충분히 나을 때 선택합니다.

# DraftPolicy가 사용하는 lookup 기대량을 풀어 쓴 학습용 계산
q = 0.8          # 앞 토큰이 맞았다는 조건에서 다음 초안도 맞을 확률의 추정값
k = 3            # 초안 개수
expected = 1 + q + q**2 + q**3   # 2.952 토큰
rate = expected / 12            # 한 라운드 12ms라고 가정하면 0.246 토큰/ms

DraftPolicy::observe()는 실제 라운드 시간과 수락 결과를 반영합니다. 시간 추정의 EMA 가중치는 0.1, MTP 토큰 추정은 0.05, lookup 관측치 감쇠는 0.97입니다. 이 값들은 모델 품질 점수가 아니라 실행 전략의 통계입니다.

실제 src/program/generate.cpp의 생성 루프에는 policy.choose(), Verifier::run(), Verifier::commit(), policy.observe()가 이어집니다. 초안을 검증한 뒤 수락한 접두부를 확정합니다. 단지 제안이 길다는 이유로 그대로 출력하지 않습니다.

src/spec/controller.cpp에도 비슷한 비용 모델이 있지만, 위 생성 루프는 DraftPolicy를 사용합니다. 비슷한 역할의 클래스가 여럿 있다면 호출 위치로 실제 사용되는 정책을 구별해야 합니다.

4-4. 패턴 ④ 스트리밍 상태기계와 역압: 조각을 정확히 읽고 천천히 보낼 줄 압니다

네트워크 조각은 문장이나 태그의 끝에서 끊긴다는 보장이 없습니다. serve/frontend.py의 OutputParser.feed()는 일부만 도착한 제어 태그를 버퍼에 남기고, 추론 내용·일반 답변·도구 호출을 이벤트로 구분합니다.

# 문자열 분할의 예시: 첫 조각만으로 끝 태그라고 확정할 수 없습니다.
조각 1: 생각 중입니다.</thi
조각 2: nk>답변입니다.
# 파서는 완성된 </think>를 확인한 뒤 상태를 전환해야 합니다.

Node의 apps/host/server/native-gateway.mjs에 있는 nativeGateway()는 작업자 응답을 중계합니다. res.write(chunk)가 false면 once(res, 'drain')을 기다립니다. 느린 클라이언트 앞에서 출력 버퍼만 계속 늘리지 않도록 하는 역압입니다.

또한 연결이 끝나면 AbortController로 상류 요청을 취소합니다. 이 게이트웨이는 사용량을 관측하면서 원래 바이트 조각을 전달합니다. 모델 출력 의미를 해석하는 Python 파서와 HTTP 흐름을 조절하는 Node 중계기의 책임을 구별해 보세요.

빠른 추론 시스템은 계산만 최적화하는 것이 아니라, 복사 완료·요청 취소·출력 대기처럼 기다림이 생기는 모든 경계를 명시합니다.

5디렉토리 구조 해부

C++ 엔진 소스는 src/, 핵심 실행 코드는 src/core/, 공개 헤더는 include/strata/에 있습니다. 아래 트리와 본문의 파일 경로는 모두 저장소 루트 기준입니다.

5-1. 파일명과 실제 구현 위치가 다를 수 있습니다

src/artifact/gguf_reader.cpp는 주로 CLI 진입점이고, 리더의 실제 구현은 include/strata/artifact/gguf_reader.hpp에 있습니다. 앞 파일만 읽고 “GGUF 파서가 없다”고 결론 내리면 안 됩니다. 클래스 정의와 호출 위치를 함께 검색하는 습관을 들이세요.

반대로 src/program/generate.cpp는 16,697줄, serve/server.py는 8,486줄입니다. 파일이 크다는 사실만으로 품질을 단정할 수는 없지만, 초보자는 처음부터 완독하기보다 policy.choose, slot_of, encode_prompt처럼 호출을 기준으로 좁혀 읽는 편이 좋습니다.

5-2. 직접 센 코드 규모

집계는 파일을 읽어 줄바꿈 바이트 \n를 센 결과입니다. .git, third_party, ref, node_modules 디렉토리는 제외했습니다. 주석·빈 줄·테스트·벤치마크·픽스처·백엔드별 중복·생성된 헤더는 포함하므로, 고유 구현량이나 실행 코드 줄 수와는 다릅니다.

C/C++ 묶음은 .cpp .cc .c .h .hpp .hxx .cxx, CUDA는 .cu .cuh 기준입니다. CMake·HTML·JSON·문서는 합계에 넣지 않았습니다. “전체 59.5만 줄”은 이 범위를 전제로 읽어야 합니다.

6학습 포인트 (기술별)

6-1. C++: 형상 검증과 자원 수명

ModelGeometry는 임베딩 폭·층 수·전문가 수 같은 모델 형상을 표현합니다. 모델 파일을 읽는 것과 해당 커널로 안전하게 계산할 수 있는지는 별개입니다. GgufFile과 check_architecture()를 따라가며 파일 형식 검증과 아키텍처 검증을 구별해 보세요.

src/artifact/gguf_reader.cpp의 검사 모드는 텐서를 오프셋 순으로 정렬한 뒤, 계산한 바이트 수가 다음 텐서와의 간격 안에 들어오는지 확인합니다. 이때 오프셋은 데이터 시작점에 대한 상대값입니다. 오프셋 하나와 길이를 비교하는 실수가 왜 위험한지 작은 숫자로 확인할 수 있습니다.

# 파일을 실행하지 않는 손계산 예시
현재 텐서 오프셋 = 96
다음 텐서 오프셋 = 256
현재 텐서 데이터 = 144 바이트
사용 가능한 간격 = 256 - 96 = 160 바이트
패딩 = 160 - 144 = 16 바이트
# 데이터 길이와 비교할 대상은 256 자체가 아니라 간격 160입니다.

자원 수명은 src/program/generate.cpp의 PreLaunchOff 같은 지역 정리 객체에서도 볼 수 있습니다. 소멸자에서 훅을 해제하고 메모리를 반환합니다. 실습으로 함수가 중간에 실패하는 반환 경로를 골라, 어떤 자원이 자동 정리되는지 표로 정리해 보세요.

6-2. GPU·운영체제: 비동기 작업에서 “완료”의 의미

expert_hit_run()의 같은 스트림 안에서는 복사와 계산의 순서를 이용합니다. 다른 스트림을 쓰는 적응 경로에서는 이벤트와 상주 표 공개 시점을 맞춰야 합니다. 실습으로 “복사 요청 → 완료 → 상주 표 갱신 → 계산” 네 사건을 종이에 놓고, 순서를 바꾸면 어떤 오래된 데이터를 읽을 수 있는지 설명해 보세요.

src/platform/memory.cpp의 Windows lock_resident()는 작업 집합을 조정한 뒤 VirtualLock()을 호출합니다. ExpertCache::shrink()·grow()의 세그먼트 방식은 CUDA 전용 조건을 갖습니다. 같은 인터페이스가 있다고 모든 백엔드가 같은 메모리 기능을 제공하는 것은 아닙니다.

6-3. Python: 외부 형식을 내부 계약으로 바꾸기

openai_to_messages()와 anthropic_to_messages()에 같은 의미의 요청을 하나씩 적어 보세요. 역할, 텍스트, 도구 이름, 도구 인자가 어떤 내부 값으로 모이는지 비교하면 어댑터 패턴이 보입니다. 이후 ChatTemplate.render()와 Service.encode_prompt()를 연결합니다.

serve/test_context_overflow.py는 문맥 초과를 실제 GPU 없이 검사하는 예입니다. 프롬프트 자체가 넘치면 400 오류를 내고, 기본 설정에서는 출력 상한만 남은 공간으로 줄입니다. 실습으로 “입력이 넘침”과 “입력은 맞지만 출력 예산이 큼”을 별도 사례로 적어 보세요.

6-4. TypeScript·React: 초기화, 상태, 화면을 분리하기

apps/host/src/app/App.tsx의 AppShell()은 useStore()로 준비·설정 상태를, useLocation()으로 화면 위치를 읽고 bootOnce()를 호출합니다. 키보드 이벤트 등록에는 정리 함수가 붙습니다. 상태 조건을 따라가며 첫 실행 화면이 언제 열리는지 읽는 연습에 좋습니다.

실습 산출물은 “준비 전 / 설정 미완료 / 설정 완료” 세 상태의 화면 표로 충분합니다. JSX를 모두 베끼기보다 어떤 상태가 어떤 화면을 결정하는지 설명해 보세요. StrictMode가 선언되어 있다는 사실만으로 초기화의 모든 중복 문제가 해결됐다고 결론 내리지는 마세요.

6-5. Node·Rust·배포: 프로세스도 제품의 일부입니다

nativeGateway()는 느린 클라이언트와 연결 종료를 다룹니다. Windows·macOS에서 Rust의 start_host()·stop_host()는 창과 호스트의 수명을 다룹니다. 실습으로 “사용자가 창을 닫음”부터 “GPU 메모리 반환”까지 필요한 종료 신호를 화살표로 그려 보세요.

strata_control/signing.py는 업데이트 피드·엔진 서명의 verify_bytes()와 Ed25519 검증을 담습니다. 학습할 것은 독자 암호 구현을 따라 만드는 일보다, 신뢰할 공개 키와 검사할 바이트를 어디서 얻는가라는 경계입니다. 데스크톱 설치 파일용 서명과 엔진 컴포넌트 서명도 구별합니다.

가장 좋은 학습 산출물은 파일 목록보다, 입력·출력·실패·정리 책임을 한 장에 연결한 계약 지도입니다.

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

아래 요구사항은 커밋 011c9e6의 README와 장치별 문서 기준입니다. 모델·메모리·백엔드에 따라 달라지는 세부 제한도 함께 확인해야 합니다.

7-1. 모델 선택표는 RAM 예산을 읽는 출발점입니다

RAM과 VRAM을 더한 숫자는 모델 선택의 대략적인 출발점이며, 서로 다른 메모리의 속도와 예약 공간까지 더해 주는 보증서가 아닙니다. strata_control/gpu_fit.py도 DENSE_GB=5.0, SYSTEM_ROOM_GB=10.0, 추가 분할 카드 비용 2.0GB처럼 별도 여유를 계산합니다. 이는 추천용 근사치이며 엔진의 모든 실제 할당량과 같지는 않습니다.

7-2. Mac·이미지·여러 GPU는 별도로 계산합니다

docs/MAC.md는 Q2_0의 상주 실행 권장을 통합 메모리 64GB부터, IQ3_S는 96GB부터로 설명합니다. 더 작은 Mac은 SSD에서 전문가를 읽는 경로가 있으며, 문서상 32~48GB Mac의 기본 설정은 MTP 초안 계층을 생략합니다. 96GB 이상 Mac의 SSD 스트리밍 설정은 MTP를 유지하고 --spec 3을 사용합니다. PC용 합계 메모리 표를 Mac에 그대로 적용하지 않는 이유입니다.

이미지 입력 인코더도 메모리를 사용합니다. docs/DETAILS.md는 GPU 이미지 인코더에 약 1.4GB VRAM을 안내하고, NVIDIA·AMD에서는 VRAM 24GB 미만일 때 CPU 인코더가 기본이라고 설명합니다. 이는 장치·설정에 따른 문서 기준입니다.

여러 GPU는 같은 제조사 안에서 나누는 경로입니다. strata_control/gpu_fit.py의 BACKEND_VENDOR는 CUDA·HIP·SYCL·Metal을 제조사와 연결합니다. NVIDIA와 AMD의 VRAM을 하나의 모델에 자유롭게 합치는 구조로 설명하면 안 됩니다.

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

아래 과제는 설치나 모델 다운로드 없이 읽기·검색·줄 수 집계·손계산만으로 진행할 수 있습니다. src/ 등의 구현을 읽고 결과를 별도 학습 노트에 정리해 보세요.

{
  "model": "학습용-모델-이름",
  "messages": [{"role": "user", "content": "캐시를 쉽게 설명해 줘"}],
  "max_tokens": 32,
  "stream": true
}

# 표기: (층 번호, 전문가 번호), 전역 슬롯은 3개
요청: (0,0), (0,1), (0,2), (1,0), (1,0), (1,0)
# ExpertCache::admit()의 전역 경로: 빈 슬롯만 등록, 퇴출 없음
처음 3개: 슬롯을 채움
이후 3개: (1,0)은 계속 등록 거절
# “자주 요청했으니 자동 퇴출”은 이 함수의 규칙에 없습니다.

경로를 찾을 때 쓸 수 있는 읽기 전용 명령입니다. 저장소 루트에서 실행하는 예시이며, 이 명령은 엔진·설치 프로그램을 실행하지 않습니다.

rg -n 'openai_to_messages|encode_prompt|class StrataEngine' serve
rg -n 'slot_of|ExpertCache::admit|layer_slot_range' src/core/expert_cache.cpp
rg -n 'policy.choose|policy.observe|auto adapt' src/program/generate.cpp
wc -l serve/server.py src/program/generate.cpp

실습의 완료 기준을 “실행됐다”보다 “어느 코드가 어떤 약속을 지키는지 설명할 수 있다”로 잡으면, GPU 없이도 설계를 깊게 배울 수 있습니다.

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

이 로드맵은 Strata를 새로 구현하는 계획이 아니라, 시스템 프로그래밍의 기본 개념을 이 저장소의 실제 경계에 연결하는 읽기 계획입니다. 처음 두 주는 GPU 지식이 없어도 시작할 수 있습니다.

배경 지식은 이 순서로 보충하세요

1. 기초 자료형·파일: 배열, 바이트, 정수 폭, 오프셋을 익힙니다. 주소와 데이터가 다르다는 점이 출발점입니다.
2. 운영체제: 프로세스, 스레드, 가상 메모리, 페이지 캐시를 익힙니다. RAM에 “있다”는 말의 여러 의미를 구별합니다.
3. 동시성: 락, 취소 신호, 작업 완료 통지를 익힙니다. CPU가 요청을 보낸 시점과 GPU가 끝낸 시점을 구별합니다.
4. 추론: 토큰, prefill·decode, 양자화, MoE, KV 캐시를 익힌 뒤 MTP·lookup을 읽습니다.
5. 검증: 같은 입력·설정·환경으로 비교하는 법과, 처리량·지연·수치 차이를 따로 기록하는 법을 익힙니다.

전체 파일을 순서대로 완독하기보다, 매주 하나의 질문을 정하고 그 질문에 답하는 호출 경로를 끝까지 따라가세요. 예를 들어 “클라이언트가 끊기면 계산은 누가 멈추는가?” 하나만으로도 웹·Python·엔진의 경계를 함께 배울 수 있습니다.

10핵심 키워드 사전

특히 전문가 캐시·KV 캐시·운영체제 페이지 캐시는 모두 “캐시”지만 담는 내용이 다릅니다. 로그를 읽을 때는 무엇을 저장한 캐시인지 먼저 표시하면 병목 해석이 쉬워집니다.

11참고 링크

공식 저장소와 분석 근거

• 공식 저장소 · 분석한 커밋의 전체 트리 · v0.2.2 릴리스
• README: 모델·시작 조건·제품 안내
• 기술 상세: 메모리 계층·API·측정 조건 · 저장소의 기술 논문
• 시스템·설치 조건 · 모델별 파일·메모리 안내
• AMD 조건 · Intel Arc의 실험 범위 · Mac 메모리·SSD 스트리밍 조건
• 다운로드·네트워크·개인정보 안내 · 서명 검증 소스
• 모델 형상 기본값 · 실제 GGUF 리더 구현
• 전문가 공급·분업 · 요청 어댑터와 출력 파서
• UI·호스트 의존성 선언 · 잠금 버전 · 데스크톱 Rust 설정
• C++ 빌드 옵션 · Python 고정 의존성 · 실제 CI 정의
• 장치별 벤치마크 기록 · 커뮤니티 측정 안내 · TrendShift

관련 기술의 공식 학습 자료

• llama.cpp / ggml — 재사용하는 수치 연산·모델 도구의 출발점
• CUDA 프로그래밍 가이드 · HIP 공식 문서 · SYCL 명세 · Metal 공식 문서
• Python HTTP 서버 · Python 자식 프로세스 · Node 스트림과 역압
• React 학습 문서 · Tauri 2 문서 · CMake 공식 문서
• README가 연결하는 기본 모델 카드 — 코드 라이선스와 별도로 모델 사용 조건을 확인하는 곳

위 외부 기술 링크는 개념 학습을 위한 참고 주소입니다. 구현 설명은 커밋 011c9e6 기준이며, 지원 범위와 측정 조건은 해당 커밋의 장치별 문서에서 확인할 수 있습니다.

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