Task 제안 v2 — 검증→분석→기여 흐름
작성: 2026-05-21 / 성격: 단기→중기→장기 연결형 (측정·분석 레이어 중심) 백지에서 재탐색 + 코드 레벨 실현가능성 검증 완료
동료들이 "백엔드를 빠르게 만드는" 일을 한다면, v2는 "그 빠름을 측정하고·설명하고·아키텍처에 연결하는" 일. 팀의 raw_block 내부 작업(체크섬/sharding/passthrough/FDP)과 레이어가 안 겹침.
A (벤치마크: 수치 증명) ──> B (스택 추적: 원인 규명) ──> C (#3262 백엔드 연결: upstream 기여)
A. 백엔드 비교 end-to-end 벤치마크 (#3183) — 단기 2~4주
실현가능성: ★★★★★ — 부품이 이미 다 있음, 새 코드 없이 하네스 구성 가능
max_local_cpu_size(기본 5GB),max_local_disk_size설정 존재 (config.py:77,89) → CPU 캐시를 작게 잡아 L2를 강제로 critical path에 올림- 백엔드 프리셋(
local_cpu/local_disk/local_cpu_disk/remote)이 config에 정의 (config.py:762~) → 설정만으로 백엔드 스왑 lmcache bench engine의kv_cache_volume_gb가 working set 결정 (long_doc_qa.py:74) → CPU RAM 초과로 키울 수 있음- end-to-end 벤치 자체는 이미 존재 (
benchmarking.rst, long-doc-qa로 TTFT 75% 감소 입증) — 단, 백엔드끼리 비교하는 방법론은 없음
제약조건:
- 헤드라인 수치는 실HW 필요 (실 GPU + vLLM + 실 NVMe). 하네스/방법론은 HW 없이 가능하나 "숫자"는 불가
bench engine은 클라이언트측 측정만 → 백엔드 내부 분해 불가 (B의 영역)- 마이크로 벤치 레이어는 혼잡 (
storage_backend_io_benchmark.py를 Wenwen #3283 + zhengfeihe #3272가 동시 확장 중) → Task A는 그 레이어가 아닌 end-to-end 서빙(vLLM+TTFT) 각도라 구분됨. #3272는 명시적으로 "not an end-to-end serving benchmark" → 중복 아님
기대효과: Samsung 단기 검증 목표 그 자체 — "우리 SSD = TTFT X% 감소" 고객 자료 직결. #3183 미할당, 로드맵도 원함.
산출물:
- 재현가능 벤치마크 레시피 (설정 YAML + 실행 스크립트)
benchmarking.rst에 "backend comparison" 섹션 (upstream PR)- (HW 확보 시) 백엔드별 TTFT/throughput 비교표 (내부 자료)
B. 스토리지 스택 레이턴시 추적 — 중기 1~2개월
실현가능성: 두 갈래로 갈림
B1 (LMCache 레이어, ★★★★☆):
L2_STORE/LOAD_*SUBMITTED/COMPLETED이벤트 이미 정의 (event.py:41,42,52,53)- EventBus + subscriber 인프라 완비 → 중간
DISPATCHED이벤트 추가하면 단계별 레이턴시 히스토그램 가능 - ※ 사실상 v1 Task 1과 동일 — v2에서는 A의 후속 분석 동기로 재배치
B2 (커널 down-to-NVMe) → 🚫 대부분 중복 (#3272, 2026-05-21 확인):
- zhengfeihe #3272
[Tool] Add tool for rust_raw_block performance check가 정확히 이것을 함:rust_raw_block_flamegraph.sh(on-CPU+off-CPU, 앱→커널 I/O 완료까지 추적) + 방법론 문서 + per-op latency 분포(p50/p99/p99.9). io_uring worker 스레드(rust-rawblock-uring) 자동 감지까지 - 따라서 raw_block 스택 프로파일링/flamegraph/latency 분포는 이미 진행 중 → B2 신규 착수 의미 없음. #3272를 활용/리뷰하는 쪽으로 전환
B1 (LMCache 레이어, ★★★★☆) — #3272와 구분되어 생존:
- #3272는 오프라인 개발자용 마이크로 프로파일링 도구. B1은 MP 모드 런타임 라이브 텔레메트리(EventBus → OTel 히스토그램) — 레이어가 다름
- 프로덕션에서 상시 수집되는 단계별 L2 레이턴시는 여전히 빈 자리
제약조건:
- 이벤트 인프라가
mp_observability에 있음 → MP 모드 전용, 단일프로세스 모드 미적용 - raw_block perf 영역은 zhengfeihe가 매우 활발(#3271 worker loop, #3272 프로파일링, #3191 O_DIRECT 정렬) → 마이크로 레벨은 혼잡, 라이브 텔레메트리(B1)로 차별화
기대효과: A의 "느리다"를 "어디서 느린지"로 분해 → 최적화 근거. (단 raw_block 마이크로 분석은 #3272가 커버 → 우리는 라이브/어댑터-횡단 관측에 집중)
산출물:
- B1:
l2_latency.pysubscriber +DISPATCHED이벤트 (upstream PR, ~400줄) — A의 백엔드 비교를 라이브 메트릭으로 뒷받침 B2: 스택 추적 방법론 문서→ #3272로 대체, 신규 산출물 없음
C. #3262 Design A — 공유 NVMe L2 백엔드 연결 — 장기 2개월+
실현가능성: ★★★★☆ — 연결부는 작고, 설계부는 DongDongJu 영역
- L2 어댑터 인터페이스 + factory 패턴 확립 (
l2_adapters/factory.py) - 이미 "공유 L2" 패턴 존재: S3/mooncake/nixl/resp 어댑터가 사례
- 핵심 통찰:
raw_block_l2_adapter는device_path기반(:71)이라 노드-로컬 전용이지만, 그 device_path를 NVMe-oF 타겟으로 가리키면 거의 코드 변경 없이 공유 L2가 됨 ← Samsung HW의 자연스러운 각도
제약조건:
per_tp_device_paths is not supported in MP raw_block mode(:148) — MP raw_block 제약 존재, 멀티노드 확장 시 재설계 필요- 크로스노드 캐시 일관성(chunk 소유권)은 #3262 미해결 설계 질문 → DongDongJu 영역, 침범 주의
- NVMe-oF 셋업은 실HW/네트워크 필요
기대효과: Samsung 장기 기여 목표 — NVMe 공유 L2가 upstream 아키텍처에 반영. A·B 결과가 정량 근거 제공.
산출물:
- #3262에 "raw_block over NVMe-oF = Design A 스토리지 레이어" 의견 코멘트
- 일관성 프로토콜 합의 후 어댑터 wiring PR
종합 판단
| Task | 지금 시작? | HW 의존 | 중복 위험 | upstream 가치 |
|---|---|---|---|---|
| A (end-to-end 비교) | ✅ 즉시 | 숫자만 | 없음 (마이크로벤치와 구분) | 높음 |
| B1 (라이브 L2 레이턴시) | ✅ 즉시 | 없음 | 낮음 (#3272는 오프라인) | 중간 |
| 🚫 | — | #3272가 흡수 | 폐기 | |
| C (#3262 공유 NVMe L2) | △ 설계합의 후 | 높음 | 중간(DongDongJu 영역) | 높음 |
진입 순서: A부터 (코드 변경 없이 하네스 구성, 실HW 붙으면 즉시 숫자). A 과정에서 "왜 느린지" 질문 → B1(라이브 메트릭) 동기. raw_block 마이크로 분석이 필요하면 신규 착수 대신 #3272 활용. C는 A·B 데이터 축적 후 #3262 진입.
최대 리스크: C가 실HW(NVMe-oF, Samsung SSD)에 의존 → 실장비 접근성이 착수 시점 좌우.
2026-05-21 PR 교차검증: #3272(raw_block 프로파일링 도구)가 B2를 흡수 → 폐기. A는 end-to-end 각도라 마이크로벤치(#3283/#3272)와 구분되어 생존. B1은 라이브 텔레메트리라 #3272(오프라인)와 구분되어 생존.