KV$ SSD FDP PoC 배경 정리

이 디렉터리는 현재 LMCache-fdp-eval 또는 smrc 평가에서 새로 생성된 산출물이 아니다. DongDongJu/LMCache의 FDP PoC baseline이 나오기 전후에 진행된 별도 KV$ SSD PoC 기록이며, 현재 우리가 보는 baseline의 배경과 한계를 파악하기 위한 선행 자료로 취급한다.

원문 파일:

• status: KV$ SSD 제안/보고 상태와 Samsung 관점의 사업적 의미
• history: PoC bring-up, LMCache raw_block FDP 구현, trace replay, RUH 정책, NIXL/FS 후속 논의 기록
• waf_result.xhtml: PM1753 기반 non-FDP/FDP WAF 실험 조건과 결과 해석

한 줄 요약

이 PoC는 "KV cache offload workload에서 SSD 펌웨어의 FDP/RUH 배치 제어가 WAF를 낮출 수 있는가"를 PM1753 PoC FW와 LMCache raw_block backend로 검증하려던 선행 작업이다. 현재 smrc 평가와 환경은 다르지만, DongDongJu/LMCache baseline이 만들어진 이유, 실험 설계의 의도, 그리고 결과를 읽을 때 조심해야 할 조건을 설명해 주는 배경 자료다.

왜 Samsung 관점에서 중요했나

원문의 status는 이 작업을 KV$ SSD feature proposal의 일부로 설명한다. NVIDIA가 KV$ deployment를 겨냥한 SSD optimization을 Samsung에 직접 요청했고, Samsung은 현재 제품/아키텍처에서 비교적 낮은 SSD-side effort로 차별화를 만들 수 있는지 검토했다. 목표는 단일 PoC 성능 수치가 아니라 다음 항목에 있었다.

• KV cache offload가 고용량 배포 타깃이 될 가능성 확인
• PM1753 같은 현재 세대 제품에서 FDP 기반 차별화 가능성 탐색
• 고객 E2E PoC를 통해 실제 workload 접근권 확보
• AMD, Dell 등 다른 GPU/OEM 생태계로 확장 가능한 SSD optimization 방향 발굴
• FW/FS/block/object stack이 KV$ workload를 어떻게 받아야 하는지 정리

따라서 이 디렉터리의 자료는 "현재 우리가 그대로 재현해야 할 정답"이라기보다, baseline branch가 어떤 문제의식에서 생겼고 어떤 실험 가정을 품고 있는지 설명하는 근거다.

타임라인 재구성

2026-04-28: PM1753 PoC FW bring-up

PM1753 PoC FW에서 RG/RUH 구성이 올라왔고, Linux에서는 128개의 placement ID가 보이는 상태가 확인됐다. 이 시점의 핵심 질문은 다음과 같았다.

• 하나의 stream bandwidth가 예상보다 덜 줄어드는 이유
• RU가 striping되는지, striping이 WAF에 어떤 영향을 주는지
• GC가 FDP/RUH 구조를 인지하는지
• Samsung-specific WAF log page가 있는지

즉, 아직 LMCache workload 이전 단계였고, FDP-capable device 자체의 관찰 방법과 FW 의미를 맞추는 단계였다.

2026-04-29~04-30: LMCache raw_block FDP PoC 구조

DongDongJu/LMCache의 fdp_poc 계열에서 raw_block backend에 FDP support를 얹는 작업이 진행됐다. 중요한 구현 가정은 다음과 같다.

• data RUH는 저장 객체마다 RawBlockCore._select_fdp_ruh()에서 선택한다.
• 우선순위는 MemoryObj.metadata.fdp_placement_rank, MP object key의 kv_rank, legacy worker_id 순서다.
• MP mode에서는 MPCacheEngine이 (instance_id, worker_id) 조합별 placement rank를 부여한다.
• raw_block은 RUH별 물리 주소 공간을 따로 만들지 않고 하나의 global slot space를 유지한다.
• FDP는 주소 배치를 나누는 기능이 아니라, write에 placement directive를 붙이는 기능으로 쓰인다.
• metadata는 별도 metadata RUH에 배치할 수 있고, data는 data RUH 목록에서 rank 기반으로 분산된다.

당시 smrc setup은 FDP drive에서 7 RUH만 사용할 수 있었고, 3개 vLLM instance와 TP2 구성으로 6 data stream + 1 metadata stream을 만드는 식으로 workload를 구성했다.

2026-05-01~05-08: trace replay와 WAF-heavy workload 구성

GPU 없이 trace replay를 돌리기 위한 준비가 이어졌다. no-FDP replay와 FDP replay 모두 raw_block device를 직접 사용했고, FDP replay에서는 data RUH와 metadata RUH를 명시적으로 나눴다.

이 시점에 workload는 단순 기능 검증을 넘어 WAF를 보기 위한 장기 replay로 확장됐다. 기록상 15개 trace class가 사용됐다.

• tool agent
• metadata-heavy
• shared-prefix-heavy
• coding agent
• long-context-cold
• hot-churn
• browser agent
• mixed agent
• general assistant

256-worker run에서는 15개 trace 전체를 대상으로 6058개 measurement replay launch와 256개 warmup launch가 수행됐다. 성공한 no-FDP baseline 예시는 host write 약 19.26 TB, media write 약 21.60 TB, WAF 1.1216으로 기록돼 있다.

2026-05-11: FW/OP 구조와 측정 신뢰도 이슈

Sol PD 논의에서 PoC FW의 RU striping, OP, bandwidth tradeoff가 핵심으로 올라왔다.

• 새 FW는 RU를 8 channel에 걸쳐 stripe하도록 제공될 예정이었다.
• 추가 OP는 약 300 GB 수준이고, non-FDP FW의 일반적인 10% OP에 가까워지는 방향이었다.
• permanently isolated RUH는 유지된다.
• write path에서 RUH당 bandwidth는 전체의 약 1/4 수준으로 줄 수 있고, read path는 거의 전체 bandwidth를 유지할 수 있다.
• written data accounting mismatch를 바로잡아야 했다.
• GPU 없이 더 많은 RUH에 대한 trace를 만들 필요가 있었다.

여기서 중요한 점은 WAF 수치만 놓고 FDP 효과를 판단하기 어려웠다는 것이다. FW OP, namespace utilization, accounting bug, workload fill 상태가 모두 결과에 크게 영향을 줄 수 있었다.

2026-05-13: accounting fix와 128-RUH runbook

DSA 쪽에서 raw_block IO accounting bug를 수정하는 branch가 나왔고, 128 RUH를 쓰는 runbook이 정리됐다. data RUH는 0..119, metadata RUH는 120..127처럼 나누는 구성이 등장한다.

기록에서는 SMART counter가 /dev/ng* io_uring_cmd write에 대해 기대대로 증가하지 않을 수 있으므로, LMCache의 successful physical bytes를 accounting validation에 활용하고, vendor media/NAND counter가 실제로 설정된 경우에만 WAF를 해석하라고 주의한다.

2026-05-21~05-29: WAF confidence와 RUH policy 재정리

conventional FW non-FDP WAF는 45시간 run에서 1.25~1.30으로 수렴하는 흐름이었지만, device가 14 TiB이고 working set은 약 3 TiB 수준이라 utilization이 낮았다. PoC FW는 19시간 후 utilization 2.5 TiB를 보고했지만, FDP 결과 신뢰도는 낮다고 기록돼 있다. 큰 drive size와 OP가 실험을 어렵게 만든다는 점도 명시돼 있다.

이후 add-per-app-rr 계열에서 active window와 worker 수 제한 문제가 발견됐다. active windows는 128, max workers는 32였고, IO submit policy가 max active windows logic을 비활성화하는 문제가 있어 제거됐다. RUH 사용은 정상으로 확인됐고, 정책은 15개 trace에 각 8개 RUH를 배정하되 두 trace가 같은 RUH를 쓰지 않도록 round-robin 배치하는 방향으로 바뀌었다.

2026-06-04~06-10: FS/NIXL replay와 MP monitoring

후반부에는 raw_block FDP만이 아니라 NIXL filesystem path, POSIX backend, MP mode monitoring, Grafana/Prometheus/Tempo/OTel, per-app RUH planner까지 논의가 확장됐다.

NIXL filesystem record/replay runbook은 nixl_store_dynamic과 POSIX backend를 사용해 MP-mode storage traffic을 trace로 기록하고, fresh filesystem path에 replay하는 절차를 설명한다. 이는 FDP 실험과 별개로, LMCache storage path를 block/file/object 관점에서 재현 가능하게 만들려는 시도다.

per_app_rr planner는 metadata를 별도 RUH에 두고, data RUH를 app/trace 단위로 분배하는 방향을 보여 준다. 현재 baseline branch를 볼 때도 이 "trace/app 단위 RUH 분리"가 왜 중요했는지 확인할 수 있는 단서다.

WAF 결과 재해석

waf_result.xhtml은 PM1753 기반 실험 결과를 정리한다.

장치/측정 조건:

• Device: PM1753, v8 TLC
• 일반 FW: RPSA005Q
• FDP FW: RPS9TP50
• host writes: SMART / Health Information Log Page
• NAND writes: OCP Extended SMART Log Page

항목	조건	읽을 때 주의할 점
Mixed 1	mixed workload, cache hit 약 90%, non-FDP utilization 100%, FDP utilization 약 20%, data RUH 0..31, metadata RUH 120..127	FDP 쪽은 preconditioning이 없고 free block이 50% 이상 남아 best-case WAF에 가깝다. non-FDP와 직접 비교하면 과대해석 위험이 크다.
Mixed 2	mixed workload, 양쪽 utilization 100%, data RUH 2..33, metadata RUH 120..127	preconditioning이 write-heavy로 바뀌며 non-FDP/FDP 모두 WAF가 크게 달라졌다. workload보다 사전 상태가 결과를 크게 흔든 사례다.
Mixed 3	mixed workload, non-FDP utilization 100%, FDP utilization 30%, data RUH 0..119, metadata RUH 127	1024 worker를 32 active worker sliding window로 직렬화했다. write pressure 증가가 non-FDP WAF를 키웠고, Mixed 2보다 초기 차이는 덜 극적이었다.
Mixed 4	mixed workload, non-FDP utilization 100%, FDP utilization 80%, data RUH 0..119, metadata RUH 127	FDP도 높은 utilization에서 다시 측정하려는 시도다. preconditioning은 non-FDP Mixed, FDP 66% fillseq로 여전히 조건 차이가 남는다.
Write Heavy	write-heavy workload, 양쪽 utilization 100%, data RUH 2..33, metadata RUH 120..127	FDP는 RUH당 bandwidth가 낮아 같은 written bytes까지 더 오래 걸린다. write-heavy trace와 RUH mapping이 최적으로 맞춰진 상태는 아니었다.

이 결과는 "FDP가 항상 WAF를 낮춘다"는 결론보다, "FDP 효과를 보려면 utilization, preconditioning, RUH count, RUH mapping, accounting counter를 반드시 통제해야 한다"는 교훈에 가깝다.

현재 smrc 평가와 다른 점

구분	선행 KV$ SSD PoC	현재 smrc/FDP eval에서 봐야 할 점
목적	KV$ SSD feature proposal과 PM1753 PoC FW 효과 검증	baseline 재현성, DongDongJu branch 해석, 현재 환경에서의 평가 기준 정립
코드	DongDongJu/LMCache PoC branch 중심	nayeonikim/LMCache-fdp-eval에서 baseline을 보존하고 평가 산출물을 분리 관리
장치/FW	PM1753, 일반 FW와 FDP FW 비교	smrc에서 실제 접근 가능한 device/FW/counter 조건을 별도로 기록해야 함
workload	agentic trace replay, WAF-heavy 장기 run, 일부 synthetic/record-replay	현재 run manifest 기준으로 trace, RUH, active worker, preconditioning을 재명시해야 함
결과 해석	WAF trend와 FW/OP/GC 논의가 중심	baseline 재현 가능성과 측정 신뢰도 판단이 우선
문서 성격	PoC 배경/회의/실험 메모가 섞인 원자료	현재 평가는 manifest, run summary, raw result policy로 분리해 관리

우리 baseline과 연결되는 부분

baseline을 볼 때 특히 연결해서 읽어야 하는 지점은 네 가지다.

1. raw_block FDP는 per-RUH address partition을 만드는 구현이 아니다. global slot space는 유지하고 write placement directive만 바꾼다.
2. RUH assignment는 worker/app/trace rank에 민감하다. trace별 write volume이 다르면 RUH imbalance가 자연스럽게 생길 수 있다.
3. metadata RUH 분리는 실험 설계의 핵심 축이었다. metadata write와 data write를 같은 방식으로 읽으면 WAF 해석이 흐려진다.
4. WAF 결과는 device utilization과 preconditioning에 크게 흔들린다. 현재 평가도 run manifest에 fill 상태, RUH 목록, metadata RUH, active worker/window, counter source를 남겨야 한다.

주의해서 읽어야 할 한계

• 원문은 여러 날짜의 회의 메모, runbook, 임시 명령, 결과 해석이 한 파일에 이어진 형태라 시간순/주제별 경계가 불명확하다.
• 선행 PoC 환경은 현재 smrc 평가 환경과 동일하지 않다.
• 일부 WAF 결과는 preconditioning과 utilization 조건이 non-FDP/FDP 사이에서 다르다.
• PoC FW의 namespace utilization, SMART/OCP counter, LMCache accounting이 모두 검증 완료된 상태라고 보기 어렵다.
• GPU 없이 replay하기 위한 절차와 실제 serving workload는 구분해서 읽어야 한다.
• NIXL/FS/object 논의는 FDP baseline 자체보다 후속 storage path 확장 논의에 가깝다.

현재 작업에 반영할 판단

현재 baseline 검토에서는 이 디렉터리를 다음처럼 사용한다.

• DongDongJu/LMCache baseline의 역사적 배경으로 본다.
• 직접 재현해야 할 절차가 아니라, 평가 manifest/checklist를 만들 때 빠뜨리면 안 되는 조건 목록으로 사용한다.
• WAF 수치를 인용할 때는 preconditioning, utilization, RUH mapping, counter source를 함께 적는다.
• 현재 smrc에서 생기는 산출물은 이 디렉터리에 섞지 않고, LMCache-fdp-eval/fdp_eval 또는 private/work/fdp의 현재 평가 문서로 분리한다.

문서별 빠른 색인

파일	핵심 내용	현재 용도
status	KV$ SSD proposal, 2026-06-18 보고, Dell QTR, Samsung relevance	왜 이 PoC가 시작됐는지 설명
history	PM1753 bring-up, raw_block FDP, RUH policy, WAF runbook, NIXL/FS replay, MP monitoring	baseline branch의 기술 배경과 실험 설계 추적
waf_result.xhtml	PM1753 non-FDP/FDP WAF 실험 조건과 결과	WAF 결과를 해석할 때 필요한 조건/한계 확인