sglang 딥다이브
— 같은 계산은 아끼고, GPU는 쉬지 않게

1프로젝트 한줄 요약

SGLang은 LLM·멀티모달 모델의 추론을 API 서비스로 제공하는 프레임워크입니다. 모델 가중치를 읽고, 입력을 숫자 토큰으로 바꾸고, 여러 요청을 묶어 실행한 뒤, 생성한 토큰을 다시 문장으로 돌려줍니다. 이름의 출발점은 구조화된 생성 언어이지만, 현재 저장소에는 서빙 런타임과 확산 모델 실행 엔진도 들어 있습니다.

이 저장소의 핵심은 모델을 더 똑똑하게 학습시키는 것이 아니라, 이미 있는 모델을 더 효율적으로 실행하는 방법입니다. 강화학습 시스템과 연결할 때도 주로 답변 후보를 생성하는 역할을 맡습니다. 학습용 최적화기와 역전파 전체를 이 서버가 대신한다는 뜻은 아닙니다.

사용자에게 보이는 입구는 단순하다

기본 HTTP 서버는 /generate와 OpenAI 호환 /v1/chat/completions 등을 제공합니다. 전자는 SGLang의 요청 형식을 직접 사용하고, 후자는 익숙한 채팅 클라이언트를 연결하기 좋습니다. API 형식이 호환된다고 모든 공급자의 부가 기능까지 동일한 것은 아닙니다.

# 요청 형식 예시: POST /generate 의 JSON 본문
{
  "text": "배치 처리를 초보자에게 설명해 줘.",
  "sampling_params": {
    "temperature": 0,
    "max_new_tokens": 64
  },
  "stream": false
}

이 필드는 python/sglang/srt/managers/io_struct.py의 GenerateReqInput에서 확인할 수 있습니다. sampling_params는 생성 길이와 무작위성 같은 조건이고, stream은 결과를 한 번에 받을지 생성 중간에도 받을지를 정합니다.

학습할 때는 세 층을 나눠 보세요. 입구는 요청 검증과 응답, 조율은 배치와 캐시, 실행은 모델과 GPU 커널입니다. 처음부터 모든 모델의 수학을 이해하지 않아도 입구에서 실행까지 연결되는 흐름은 추적할 수 있습니다.

2왜 주목받는가

2-1. 같은 지시문을 계속 읽는 낭비를 줄인다

상담 챗봇은 매 요청에 같은 시스템 지시문을 붙이고, 문서 질의 서비스는 같은 문서를 여러 번 읽습니다. 앞부분이 동일한 토큰열이라면 이전 계산의 일부를 재사용할 여지가 있습니다. SGLang의 대표 아이디어인 RadixAttention은 이런 접두어 공유를 KV 캐시 관리와 연결합니다. 원래의 설계 배경은 SGLang 논문에서 확인할 수 있습니다.

여기서 재사용하는 것은 완성된 답변 문자열이 아닙니다. 입력 접두어를 처리하며 만든 모델 내부 상태입니다. 따라서 뒷부분의 질문이 달라도 앞부분이 정확히 같으면 도움이 될 수 있습니다. 의미가 비슷한 문장을 벡터 검색으로 찾아 답을 재활용하는 기능과는 원리가 다릅니다.

2-2. 요청을 받은 순서와 GPU 실행 묶음을 분리한다

사용자마다 입력 길이와 출력 길이가 다릅니다. 가장 긴 응답이 끝날 때까지 처음의 묶음을 고정하면 빈자리가 생깁니다. Scheduler.get_next_batch_to_run()은 실행 중인 요청을 관리하면서 새 요청이 합류할 배치를 결정합니다. LLM 서버의 처리량은 모델 계산 속도뿐 아니라, 다음 계산을 얼마나 빈틈없이 준비하느냐에도 달려 있습니다.

2-3. 경쟁 도구와 비교하면 무엇이 보이는가

vLLM도 접두어 캐싱을 지원합니다. “SGLang에만 캐시가 있다”는 비교는 틀립니다. 비교 근거는 vLLM의 접두어 캐시 설계 문서와 llama.cpp 공식 저장소입니다. 이 표는 구조와 공부 방향을 비교하며, 동일 조건의 속도 순위를 뜻하지 않습니다.

2-4. 2026년의 관심과 연결되는 지점

• 에이전트의 반복 호출: 같은 도구 설명·지시문이 반복되므로 공통 접두어를 보존하는 요청 설계가 중요합니다.
• 긴 문맥과 혼합 부하: 긴 입력을 읽는 요청과 짧게 답을 이어 쓰는 요청이 GPU를 나눠 써야 합니다.
• 서빙 범위 확대: README는 언어·시각 언어·확산 모델을 설명하며, 실제로 python/sglang/multimodal_gen/과 별도 의존성 묶음이 존재합니다.
• 연구와 운영의 연결: 캐시 알고리즘 옆에 Prometheus, 하드웨어별 Dockerfile, CPU·GPU CI가 함께 있습니다.

2026-10-23 GitHub Trending Python Weekly 9위, 스타 37,655개는 관심의 크기를 보여 줍니다. 다만 그 주 순위가 오른 단일 원인을 이 숫자만으로 증명할 수는 없습니다. 위 항목은 현재 코드가 다루는 문제를 바탕으로 해석한 관심 요인입니다. 2024년 논문의 성능 수치도 2026년의 모든 모델·GPU에 그대로 적용할 수 없습니다.

3기술 스택 전체 지도

주 언어는 Python이지만 Python만으로 완결된 서버는 아닙니다. 요청 조율은 Python, 장치 계산은 PyTorch와 전용 커널, 일부 서버·라우팅·확장 모듈은 Rust가 맡습니다. 아래 버전은 커밋 611a703의 선언값입니다. 설치 환경에서 실제로 선택된 모든 패키지의 버전 목록과는 구분해야 합니다.

3-1. 백엔드: 요청 계층과 모델 실행 계층

확산 모델용 선택 의존성 diffusion에는 diffusers==0.37.0, cache-dit==1.5.1, imageio==2.36.0 등이 선언되어 있습니다. 선택 의존성을 나누면 언어 모델 서버와 영상 생성 서버에 필요한 패키지 범위를 구분할 수 있습니다.

3-2. 프론트엔드: 두 가지 뜻을 구별하자

논문의 “프론트엔드 언어”는 브라우저 화면을 뜻하지 않습니다. python/sglang/lang/api.py의 function()·gen()은 생성 프로그램을 표현하는 Python API입니다. python/sglang/lang/ir.py는 그 표현을 담고, python/sglang/lang/interpreter.py는 실행을 담당합니다.

실제 브라우저 UI도 있습니다. python/sglang/multimodal_gen/apps/realtime_webui/의 index.html·styles.css·app.js는 확산 모델의 실시간 영상 데모입니다. 별도 package.json이나 npm 빌드가 없는 정적 구성이고, new WebSocket(...)·Canvas·디코더 작업자를 사용합니다. React나 Vue 기반의 공통 관리 화면으로 설명하면 부정확합니다.

웹 UI README는 원시 RGB 프레임 렌더링을 설명하지만, app.js의 DEFAULT_PREVIEW_OUTPUT_FORMAT은 "webp"이며 HTML에도 WebP·JPEG·원시 RGB 선택지가 있습니다. 설명의 기본 사례와 현재 기본 설정이 다를 수 있음을 보여 주는 작은 예입니다.

3-3. Rust·Go: 서버와 SDK의 별도 경계

Python의 ==와 Cargo의 version = "0.8.6"는 같은 의미가 아닙니다. 후자는 보통 호환 가능한 버전 범위를 허용합니다. 버전 문자열을 읽을 때는 숫자뿐 아니라 고정·하한·호환 범위를 나타내는 연산자까지 함께 봐야 합니다.

3-4. 인프라·빌드: 플랫폼별 재현성을 다룬다

• 컨테이너: docker/Dockerfile의 기본값은 CUDA 13.0.3, Ubuntu 24.04, Python 3.12입니다. 기반 이미지와 실행 환경을 함께 고정하는 이유를 공부할 수 있습니다.
• 커널 빌드: python/sglang/kernels/aot/pyproject.toml은 scikit-build-core>=0.10, 같은 폴더의 CMakeLists.txt는 CMake 3.26 이상과 C++ 20을 선언합니다.
• Rust 확장: python/setup.py는 Cargo 메타데이터의 python-module 선언을 찾아 PyO3 확장을 구성합니다. 확장마다 수작업으로 Python 빌드 목록을 늘리지 않는 방식입니다.
• CI: .github/workflows/pr-test.yml은 변경 범위와 실행 단계를 나누며, 예약 실행은 UTC 11:00·23:00입니다. CPU와 여러 GPU 규모의 검증 경로가 구분됩니다.

4아키텍처 심화 분석

4-1. 전체 구조: 기본 Python HTTP 경로

sglang serve의 LLM 경로는 python/sglang/cli/serve.py의 _run_llm()에서 python/sglang/launch_server.py의 run_server()로 이어집니다. 기본 HTTP 실행은 python/sglang/srt/entrypoints/http_server.py의 launch_server()가 담당합니다. 아래는 단일 엔진의 기본 Python 경로를 단순화한 구조입니다.

기본 구성에서는 HTTP 서버와 TokenizerManager가 주 프로세스에 있고, 스케줄러와 디토크나이저가 별도 프로세스입니다. Engine._launch_subprocesses()가 이 구성을 준비합니다. 다중 토크나이저·분산 병렬·Rust 서버 옵션에서는 프로세스 구성이 달라지므로 이 그림을 모든 실행 모드에 그대로 적용하면 안 됩니다.

특히 python/sglang/srt/environ.py의 SGLANG_RUST_SERVER 기본값은 False입니다. 켜면 launch_server()가 Python HTTP 경로 대신 Rust의 API·토크나이저·디토크나이저 경로를 사용합니다. Rust 디렉토리가 있다는 사실과 기본 서버가 Rust라는 주장은 구별해야 합니다.

4-2. 패턴 ① 파이프라인과 책임 분리

python/sglang/srt/entrypoints/http_server.py의 generate_request()는 요청 계약을 검사한 뒤 serve_generate_request()로 넘깁니다. 스트리밍 요청에서는 TokenizerManager.generate_request()의 결과를 비동기 반복으로 받아 data: ...\n\n 형태의 SSE 조각으로 보냅니다. HTTP 함수가 GPU 연산을 직접 구현하지 않습니다.

# python/sglang/srt/entrypoints/http_server.py
# serve_generate_request()의 스트리밍 핵심 부분을 발췌
async for out in _global_state.tokenizer_manager.generate_request(
    obj, request
):
    yield b"data: " + dumps_json(out) + b"\n\n"

python/sglang/srt/managers/tokenizer_manager.py의 같은 이름 함수는 배치 인자를 정규화하고, 요청 ID별 상태를 만들고, _tokenize_one_request()·_send_one_request()·_wait_one_response()를 연결합니다. 처리 중 실패하면 _release_req_states_on_failure()로 아직 전달하지 않은 상태를 지우거나 전달된 요청의 중단을 요청합니다.

이 정리는 성능 최적화만큼 중요합니다. HTTP 연결이 끊겼는데 요청 상태나 GPU 메모리 참조가 계속 남으면 서버는 오래 버티지 못합니다. “정상 응답을 만드는 코드”와 “중간에 실패했을 때 자원을 돌려주는 코드”를 함께 읽는 습관을 배울 수 있습니다.

4-3. 패턴 ② 접두어 트리와 자원 수명 관리

먼저 원리를 읽기 좋은 python/sglang/srt/mem_cache/radix_cache.py를 봅시다. RadixKey는 토큰열과 추가 구분 정보를 담습니다. RadixCache.match_prefix()는 가장 길게 일치하는 접두어를 찾고, insert()는 토큰열에 대응하는 KV 슬롯 정보를 트리에 넣습니다.

압축된 한 노드의 중간에서 일치가 끝나면 _match_prefix_helper()가 _split_node()로 경계를 만듭니다. 문자열 한 글자마다 노드를 만드는 단순 트라이보다 긴 토큰 구간을 한 노드로 묶을 수 있습니다. 실제 키는 페이지 크기에 맞춰 정렬되므로 재사용 길이가 입력 길이와 항상 같지는 않습니다.

사용 중인 KV를 지우면 다음 생성 계산이 잘못된 메모리를 읽습니다. 그래서 inc_lock_ref()·dec_lock_ref()는 경로의 참조 수를 갱신하고, evict()는 퇴거 가능한 잎에서 정책 우선순위에 따라 슬롯을 반환합니다. 여기의 lock_ref는 “누군가 쓰는 캐시를 보호하는 참조 수”이며 일반적인 스레드 뮤텍스와는 역할이 다릅니다.

접두어가 같아도 무조건 공유하지는 않습니다. RadixKey.extra_key와 GenerateReqInput.cache_salt 같은 구분 정보가 있습니다. LoRA나 캐시 네임스페이스가 다른 요청을 섞지 않기 위한 경계입니다. 공통 지시문을 앞에 둔다는 최적화도 토큰열과 이 구분 조건이 맞아야 효과가 납니다.

4-4. 패턴 ③ 정책과 구현을 교체하는 전략·팩터리

python/sglang/srt/managers/schedule_policy.py의 SchedulePolicy.calc_priority()는 대기열 정렬을 맡습니다. 도착 순서인 fcfs, 접두어 일치 길이를 활용하는 lpm, 대기 중 증가한 prefill 처리 토큰 수와 미계산 입력 토큰 수를 고려하는 hrrn, 미계산 prefill이 짧은 순서인 shortest-prefill-first 등으로 분기합니다.

기본 정책은 fcfs입니다. 근거는 python/sglang/srt/arg_groups/fields/schedule.py의 schedule_policy = "fcfs" 선언입니다. 캐시를 가진 서버라는 이유로 접두어가 긴 요청을 항상 먼저 실행한다고 설명해서는 안 됩니다. 우선순위 옵션이나 모델별 해석 과정도 실제 동작에 영향을 줍니다.

캐시 구현 선택에도 같은 발상이 있습니다. register_radix_cache_backend()는 이름과 생성 함수를 등록하고, create_tree_cache()는 선택한 이름에 맞는 팩터리를 부릅니다. 이름이 없으면 기본 선택 체인을 사용하며, 잘못된 이름은 오류로 처리합니다.

# registry.py의 구조를 학습용으로 축약한 의사코드
if backend_name:
    factory = get_radix_cache_factory(backend_name)
    if factory is None:
        raise ValueError("등록되지 않은 캐시 구현")
    cache = factory(context)
else:
    cache = default_radix_cache_factory(context)

스케줄러가 원하는 일과 캐시가 그 일을 수행하는 방법을 분리하면, 호출부 전체를 바꾸지 않고 구현을 확장할 수 있습니다. 다만 같은 인터페이스라도 지원 기능이 다를 수 있어 create_tree_cache()에는 세션 캐시나 호스트 버퍼 모드의 호환성 검사도 들어 있습니다.

4-5. 패턴 ④ CPU 준비와 GPU 계산을 겹치는 실행 파이프라인

Scheduler.event_loop_normal()은 요청 수신, 다음 배치 선택, 실행, 결과 처리 순서로 읽으면 됩니다. event_loop_overlap()은 결과 대기열을 두고 현재 배치를 실행하면서 이전 배치 결과를 처리하는 구조입니다. CPU의 준비 시간과 GPU의 계산 시간이 직렬로 모두 더해지는 구간을 줄이려는 설계입니다.

겹친다고 동기화를 없애지는 않습니다. _apply_war_barrier()는 다음 스케줄링의 공유 버퍼 쓰기가 이전 GPU 읽기를 앞지르지 않도록 이벤트 또는 스트림 대기를 적용합니다. 문법 제약 등으로 직전 결과가 필요하면 is_disable_overlap_for_batch()가 배치별 예외를 판단합니다.

모델 실행은 python/sglang/srt/model_executor/model_runner.py의 ModelRunner.forward()로 이어집니다. 여기에는 실행 경로, 프로파일링, 분산 모델 관련 처리가 모입니다. HTTP부터 모든 일을 한 함수에 넣지 않고 실행 계층으로 내려보내는 이유를 확인할 수 있습니다.

소스 추적을 마친 뒤 답해 볼 질문

1. 요청이 대기 중인 상태와 GPU에서 실행 중인 상태는 어디서 구분되는가?
2. 정렬 정책이 바뀌어도 같은 KV 메모리 풀을 사용할 수 있는 이유는 무엇인가?
3. 클라이언트가 사라질 때 Python 상태와 KV 슬롯은 각각 누가 정리하는가?

5디렉토리 구조 해부

위 구조도의 폴더를 읽을 때 주목할 경계

파일 네 개로 시작하는 읽기 순서

1. python/sglang/srt/entrypoints/http_server.py에서 generate_request()를 찾습니다. 전체 서버 파일을 처음부터 읽을 필요는 없습니다.
2. python/sglang/srt/managers/tokenizer_manager.py에서 요청이 토큰화되고 전송되는 지점을 찾습니다.
3. python/sglang/srt/managers/scheduler.py에서 event_loop_normal()과 다음 배치 선택만 먼저 읽습니다.
4. python/sglang/srt/mem_cache/registry.py에서 캐시 선택을 확인한 뒤 python/sglang/srt/mem_cache/radix_cache.py와 python/sglang/srt/mem_cache/unified_radix_cache.py를 비교합니다.

커밋 기준 python/sglang/srt/managers/scheduler.py는 6,291줄, python/sglang/srt/managers/tokenizer_manager.py는 4,122줄입니다. 파일이 길다는 사실은 읽기를 포기할 이유보다 한 요청의 호출 경로를 좁혀야 할 이유에 가깝습니다. 함수별로 입력·출력·바꾸는 상태를 세 칸으로 기록해 보세요.

6학습 포인트 (기술별)

이 저장소에서 배울 가장 실용적인 습관은, 함수가 무엇을 계산하는지와 함께 어떤 상태를 소유하고 언제 반환하는지를 묻는 것입니다. 이 질문은 추론 서버뿐 아니라 DB 연결 풀, 작업 대기열, 이미지 처리 서버에도 그대로 적용됩니다.

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

7-1. 읽기와 GPU 실험의 요구사항은 다르다

위 표는 모든 모델의 공식 최소 사양표가 아닙니다. 필요 용량은 모델 구조·정밀도·문맥·동시성·백엔드에 따라 달라집니다. CPU RAM과 디스크에도 모델 다운로드·로딩·캐시용 공간이 필요합니다. GPU 메모리에 딱 맞는 크기만 보고 호스트 자원을 결정하지 마세요.

7-2. 메모리 계산을 직접 해 보자

# 가중치의 단순 근사: 양자화 메타데이터·작업 버퍼는 제외
가중치 메모리 ≈ 파라미터 수 × 파라미터당 바이트
8B × BF16 2바이트 = 16,000,000,000바이트 ≈ 14.9GiB

# 일반적인 디코더 어텐션의 KV 캐시 근사
KV 바이트 ≈ 2 × 층 수 × KV 헤드 수 × 헤드 차원
             × 보관 토큰 수 × 원소당 바이트

# 층 32, KV 헤드 8, 헤드 차원 128, BF16 예시
2 × 32 × 8 × 128 × 8192 × 2 = 1GiB / 요청
같은 조건의 독립 요청 8개 ≈ 8GiB

총 GPU 사용량 ≈ 가중치 + KV 풀 + 활성값 + 그래프·작업 버퍼

이 KV 식은 모든 모델에 통하는 식이 아닙니다. GQA의 KV 헤드 수, 슬라이딩 윈도, MLA의 압축 상태, Mamba의 상태 구조가 다릅니다. 공유 접두어가 있으면 중복을 줄일 수 있지만, 최악의 예산은 공유되지 않는 입력도 고려해야 합니다.

모델 가중치가 GPU에 들어간다는 사실만으로, 원하는 문맥 길이와 동시 요청 수까지 감당할 수 있다는 결론은 나오지 않습니다. 캐시를 크게 잡으면 더 많은 토큰을 보관할 수 있지만, 실행 중 임시 텐서가 쓸 공간도 남겨야 합니다.

7-3. 설정의 기본값도 장치에 따라 해석된다

python/sglang/srt/arg_groups/fields/schedule.py에서 mem_fraction_static과 chunked_prefill_size는 둘 다 None으로 시작합니다. python/sglang/srt/arg_groups/memory_hook.py의 handle_gpu_memory_settings()가 장치 메모리와 다른 설정을 보고 값을 정합니다.

구간은 하한을 포함하고 상한은 포함하지 않으며, 해당 함수의 일부 분기를 GiB로 표현했습니다. 모델·플랫폼별 후속 조정과 명시적 옵션이 있으므로 전체 실행의 고정값으로 외우지 마세요. mem_fraction_static은 가중치와 KV 풀에 쓰는 정적 메모리의 비율이며, KV 캐시만의 비율이 아닙니다.

7-4. 플랫폼 지원은 동일한 설치법을 뜻하지 않는다

README는 NVIDIA·AMD·Intel GPU/CPU·Ascend·Apple Silicon 등을 설명합니다. 실제 저장소에도 docker/rocm.Dockerfile·docker/xpu.Dockerfile·docker/npu.Dockerfile·docker/xeon.Dockerfile과 장치별 백엔드가 있습니다. 그러나 모델·연산·옵션의 지원 범위까지 모두 같다고 볼 수는 없습니다.

TPU는 README에서 SGLang-TorchTPU와 SGL-JAX라는 별도 프로젝트 경로도 안내합니다. NVIDIA용 python/pyproject.toml의 CUDA 의존성을 모든 플랫폼에 그대로 적용하지 말고, 공식 플랫폼 가이드와 모델별 실행 예제를 함께 확인해야 합니다. 기본 Dockerfile의 CUDA 13.0.3도 모든 하드웨어의 공통 최소 버전은 아닙니다.

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

def prefix_length(a, b):
    n = 0
    while n < min(len(a), len(b)) and a[n] == b[n]:
        n += 1
    return n

previous = [10, 20, 30, 40]
request = [10, 20, 30, 99, 88]
matched = prefix_length(previous, request)
uncached = len(request) - matched

assert matched == 3
assert uncached == 2
assert prefix_length([1, 2], [0, 1, 2]) == 0

# 전용 실습 환경의 첫 터미널
sglang serve \
  --model-path Qwen/Qwen3-0.6B \
  --host 127.0.0.1 --port 30000 \
  --context-length 4096 \
  --max-running-requests 1 \
  --enable-metrics

# 서버가 준비된 뒤 두 번째 터미널
curl -sS http://127.0.0.1:30000/generate \
  -H 'Content-Type: application/json' \
  -d '{
    "text": "배치 처리를 한 문장으로 설명해 줘.",
    "sampling_params": {"temperature": 0, "max_new_tokens": 64},
    "stream": false
  }'

성능 실습의 결과물은 가장 빠른 숫자 하나가 아니라, 어떤 조건을 바꾸었을 때 무엇이 달라졌는지 설명하는 기록입니다. GPU가 없다면 과제 1·2·5만으로도 파이프라인·접두어 자료구조·공정성이라는 핵심 주제를 공부할 수 있습니다.

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

하루 45~60분 정도를 기준으로 한 읽기 중심 경로입니다. 모델 수학과 GPU 커널을 한 번에 끝내려 하지 말고, 각 주마다 설명 가능한 작은 산출물을 남깁니다. 이미 익숙한 주제는 건너뛰어도 되지만 마지막에는 요청 전체를 다시 연결해 보세요.

학습의 종료 기준은 파일을 많이 읽는 것이 아니라, 요청 하나의 상태와 메모리가 어디로 이동하는지 설명할 수 있는 것입니다. 그 뒤에는 관심에 따라 캐시 알고리즘, 장치 커널, 분산 라우팅 중 한 갈래를 선택하면 됩니다.

10핵심 키워드 사전

처음에는 모든 약어를 외울 필요가 없습니다. 입력 처리, 실행 순서, 저장 공간, 통신, 측정 중 어느 문제를 다루는 말인지 먼저 분류하면 소스를 읽을 때 길을 잃지 않습니다.

11참고 링크

프로젝트 공식 자료

• SGLang 공식 저장소 — README·릴리스·이슈의 출발점
• SGLang 공식 문서 — 설치·플랫폼·서버 옵션과 API 설명
• SGLang Cookbook — 모델과 장치별 실행 구성
• v0.5.22 릴리스 — 2026-10-19 공개 버전. 본문의 HEAD 소스와 구별
• SGLang 논문 — 생성 언어와 RadixAttention의 설계 배경
• Mini-SGLang — 핵심 실행 원리를 작은 구현으로 이어 공부할 보조 자료

본문과 연결되는 소스 — 커밋 611a703 기준

• python/pyproject.toml — Python 최소 버전, 필수·선택 의존성
• python/sglang/srt/entrypoints/http_server.py — API 진입점과 Python·Rust 실행 분기
• python/sglang/srt/managers/tokenizer_manager.py — 요청 상태·토큰화·응답 대기·실패 정리
• python/sglang/srt/managers/scheduler.py — 다음 배치 선택과 겹침 실행
• python/sglang/srt/managers/schedule_policy.py — 캐시 인식·비인식 정렬 정책
• python/sglang/srt/mem_cache/radix_cache.py — 접두어·분할·참조 보호를 읽기 좋은 구현
• python/sglang/srt/mem_cache/registry.py와 unified_radix_cache.py — 현재 기본 선택과 컴포넌트 조합
• python/sglang/srt/model_executor/model_runner.py — 모델 실행·배치·가속 경로
• test/registered/unit/managers/test_schedule_policy.py — 정렬·공정성의 구체적인 기대값
• docker/Dockerfile와 .github/workflows/pr-test.yml — 장치 환경과 CI 단계

관련 기술의 공식 자료

• Python asyncio — 이벤트 루프·태스크·취소
• FastAPI 비동기 설명 — I/O 대기와 실행 시간의 구별
• PyTorch CUDA 설명 — 장치·스트림·메모리 관리
• PyO3 공식 가이드와 Tokio 공식 입문 — Rust 바인딩과 비동기 실행
• gRPC 소개와 Prometheus 개요 — 서비스 통신과 메트릭
• vLLM 접두어 캐싱 설계 — 같은 문제를 블록·해시로 다루는 비교 자료

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

집계 기준: 커밋 611a703의 Git 추적 파일을 확장자별로 묶은 물리적 줄 수입니다. 빈 줄·주석·테스트·생성 코드·해당 확장자의 서드파티 코드를 포함하고, 심볼릭 링크는 제외했습니다. JavaScript는 .js·.mjs·.cjs, Shell은 .sh를 집계했습니다. 다운로드되는 모델 가중치나 외부 패키지의 소스는 포함하지 않습니다. 따라서 사람이 작성한 구현 코드만의 크기나 언어별 작업량 비율로 해석하면 안 됩니다.

읽기 범위를 잡는 참고로, python/sglang/srt/의 Python·Rust·C/C++·CUDA·Go·JavaScript 해당 확장자 합계는 약 92만 줄이고 test/는 약 72만 줄입니다. 전체 크기를 목표로 삼기보다 4절의 요청 경로와 작은 테스트부터 읽는 편이 현실적입니다.