FDP PoC Harness 평가 시나리오

작성일: 2026-06-15

목적

이 문서는 원문 PoC HTML, PoC harness README, 현재 코드 구현을 기준으로 FDP WAF 평가를 어떻게 실행할지 정리한다.

기준 우선순위는 다음과 같이 둔다.

우선순위	기준 문서	이 문서에서의 역할
1	fdp/FDP_for_LMCache_Poc.html	평가 목적과 필수 해석 기준. WAF/endurance/p99 개선, lifetime 분리, clean-state 회피와 preconditioning 필요성
2	LMCache-fdp-poc-src/benchmarks/fdp_waf_stress/README.md	PoC harness 실행 방식. stress, warmup=2, measurement=8, no_fdp/mixed/separated 비교
3	현재 smrc 코드/스크립트	target 장비의 RUH 수, OCP media counter, 8-RUH remapping, 결과 파서/보고서 생성
4	현재까지의 probe 결과	실행 가능성, WAF counter 동작 여부, counter settle 필요성 확인

목표는 tensormesh 통합 전 단계에서 PoC 자체 storage replay harness로 다음을 확인하는 것이다.

• FDP raw-block write path가 실제 SSD write를 발생시키는지
• vendor media-write counter를 이용해 정식 WAF를 산출할 수 있는지
• no_fdp, separated, mixed 세 모드의 WAF/host write/p99를 같은 조건에서 비교할 수 있는지
• 이후 tensormesh 평가로 넘어갈 만한 신호가 있는지

원문 PoC 기준

원문 PoC HTML의 핵심 가설:

KV cache stream을 lifetime이 비슷한 placement group으로 분리하면
SSD 내부 GC 시 불필요한 copy가 줄어 WAF와 NAND wear가 감소하고,
p99 같은 tail latency도 안정될 수 있다.

원문 HTML이 명시한 평가 고려사항:

Starting from a clean state may make WAF difficult to observe.
Preconditioning to a sustained state should be considered before WAF evaluation.

여기서 원문이 직접 말한 것은 sustained state preconditioning을 고려해야 한다는 것이다. 원문은 full-device write량, fill 비율, 반복 횟수 같은 구체 숫자를 지정하지 않았다.

따라서 원문 기준의 평가 우선순위는 README 예시값보다 먼저 아래 조건을 만족하는 것이다.

원문 기준	평가 반영
lifetime이 다른 KV stream 분리	separated mode에서 hot/cold/metadata workload를 다른 RUH로 배치
WAF와 endurance 개선	host write와 vendor media write counter로 정식 WAF 산출
p99 tail latency 안정화	records.jsonl 기반 write/read p99 산출
clean-state에서는 WAF 관측이 어려울 수 있음	R0 precondition 여부와 span을 결과표에 명시
sustained-state preconditioning 고려	최소 window-local R0, 최종 주장에는 확장 R0 또는 full-span R0 필요

따라서 현재 시나리오는 두 단계로 나눈다.

단계	목적	주장 가능한 범위
1차 window-local R0	PoC harness 정식 WAF 산출과 mode 비교 가능성 확인	harness measurement window 기준 WAF 비교
확장 R0	더 큰 span 또는 full-span preconditioning으로 SSD-level sustained state에 가까운 결과 확보	더 강한 WAF 평가 근거

PoC Harness 기준

PoC README의 harness 의도:

• 여러 LMCache storage trace replay를 raw-block NVMe namespace에 동시에 수행
• cache-like churn을 만들어 SSD GC pressure를 관찰하기 쉽게 함
• no_fdp, mixed, separated 세 모드를 비교
• vendor media/NAND write counter가 설정되면 summary.json에 media_write_bytes_delta와 waf를 산출

PoC harness README의 3모드 비교 예시는 다음 측정 조건을 사용한다.

항목	README 기준값	의미
--warmup-iterations	2	측정 전 동일 trace replay를 2회 수행하고, 이 구간은 WAF 계산에서 제외
--iterations	8	warmup 이후 측정 대상 replay를 8회 수행
--scale	stress	WAF/GC pressure 관찰용 synthetic trace scale

따라서 팀 공유용 1차 정식 결과는 warmup=2, measurement=8, TRACE_SCALE=stress를 기준으로 한다. 기존 warmup=0, measurement=1 실행은 smoke/debug 결과로만 분리한다.

모드 의미:

Mode	의미	평가 목적
no_fdp	FDP placement hint 없음	baseline
mixed	FDP on, 여러 workload가 같은 RUH pool 공유	FDP on이지만 분리 정책 없음
separated	workload class별 data/metadata RUH 분리	lifetime 분리 효과 확인

현재 harness의 placement 기준

현재 PoC harness는 원문 PoC의 per-prompt, phase-aware, per-vLLM worker 중 하나를 그대로 구현한 형태가 아니다. 실제 구현은 workload class 기반 RUH 분리다.

즉 prompt id, prefill/decode phase, vLLM worker/rank 번호를 직접 보지 않는다. Synthetic trace/config에 부여된 workload class를 lifetime proxy로 보고 RUH를 배정한다.

원문 시나리오와 현재 harness의 대응 관계:

원문 placement 시나리오	현재 harness 해당 여부	이유
Per-Prompt Data Placement	아님	prompt_id % num_placement_handles 같은 prompt id 기반 매핑이 없다
Phase-aware Data Placement	부분적으로 가까움	prefill/decode phase는 보지 않지만, hot/cold/metadata/large/small workload class를 lifetime proxy로 분리한다
Per-vLLM Worker Data Placement	아님	worker0→RUH0, worker1→RUH1 같은 rank/worker별 고정 분리가 아니다

현재 8-RUH target에서 mixed와 separated의 실제 RUH 구성:

Workload	의미	Class	separated data RUH	separated metadata RUH
llama8b_chat_chunk256	small/chat 계열, churn 큼	hot_churn 또는 small_model 계열	[0,1]	[2]
random_prompts_chunk128	random prompt, low reuse/churn	hot_churn 계열	[0,1]	[2]
llama70b_longctx_chunk1024	large model / long context	large_model	[3,4]	[5]
rag_shared_prefix_chunk512	RAG/shared-prefix, reuse 가능성 높음	cold_rag	[3,4]	[5]
metadata_heavy_small_objects	metadata/small object가 많음	metadata_heavy	[6]	[7]

Mode별 배치 의미:

Mode	기준	RUH 배정 의미
no_fdp	FDP off	RUH hint 없음
mixed	모든 workload를 같은 pool에 섞음	data [0,1,3,4,6,7], metadata [2,5]를 모두 공유
separated	workload class별 분리	hot/small/random, cold/RAG/large, metadata-heavy를 서로 다른 RUH 그룹으로 분리

그림처럼 보면:

mixed
  모든 workload
    -> data RUH     [0,1,3,4,6,7]
    -> metadata RUH [2,5]

separated
  hot/small/random
    -> data RUH     [0,1]
    -> metadata RUH [2]

  cold/RAG/large
    -> data RUH     [3,4]
    -> metadata RUH [5]

  metadata-heavy
    -> data RUH     [6]
    -> metadata RUH [7]

따라서 mixed vs separated 비교는 "FDP를 켰을 때 그냥 섞는 것"과 "lifetime이 비슷하다고 가정한 workload class끼리 분리하는 것"의 차이를 보는 실험이다. 현재 harness가 검증하는 것은 per-prompt나 per-vLLM-worker 정책이 아니라 class/lifetime-aware placement 정책이다.

비교 기준:

• no_fdp vs separated: FDP 분리 정책의 메인 효과
• separated vs mixed: 효과 원천이 FDP 자체인지, lifetime/RUH 분리인지 확인

현재 코드 기반 확인

현재 stress trace 기준 harness가 잡는 raw-device worker capacity는 총 약 9.5 GiB다.

Workload	Concurrency	worker capacity	total capacity
llama8b_chat_chunk256	2	1GiB	2GiB
llama70b_longctx_chunk1024	1	2GiB	2GiB
rag_shared_prefix_chunk512	2	1GiB	2GiB
random_prompts_chunk128	3	1GiB	3GiB
metadata_heavy_small_objects	1	0.5GiB	0.5GiB
합계	9 workers		9.5GiB

stress trace의 estimated store demand는 약 48 GiB다.

Workload	estimated store bytes
llama8b_chat_chunk256	10GiB
llama70b_longctx_chunk1024	10GiB
rag_shared_prefix_chunk512	12GiB
random_prompts_chunk128	8GiB
metadata_heavy_small_objects	8GiB
합계	약 48GiB

따라서 현재 stress 설정은:

raw window capacity: 약 9.5GiB
measurement store demand: 약 48GiB

즉 harness는 window보다 큰 write demand를 만들어 churn이 생기도록 설계되어 있다.

Test Environment

Full audit: 02_smrc_env/smrc_env_report.md

Item	Value
SSD	Samsung PM9D3 (MZOL63T8HDLT-00AFB, SN: S77UNG0TC00101)
Controller / Namespace	/dev/nvme0 / /dev/nvme0n1 (/dev/ng0n1 for io_uring_cmd)
Capacity	3.76 TB (3,760,740,458,496 bytes)
LBA format	4 KiB
FDP endurance group	1
RUH count	8 (0..7, Initially Isolated)
nvme-cli	2.15 (libnvme 1.15)
OS / kernel	Linux 6.17.0 (dsksh805, x86_64)

Vendor WAF Counter

정식 WAF 계산식:

WAF = media_write_bytes_delta / host_write_bytes_delta

현재 target SSD에서는 OCP SMART log가 media-write counter를 제공한다.

사용 command:

nvme ocp smart-add-log /dev/nvme0n1 -o json

확인된 field:

"Physical media units written": {
  "hi": 0,
  "lo": 2114796921614336
}

LMCache-fdp-poc-src/benchmarks/fdp_waf_stress/run_fdp_waf_stress.py는 이 OCP JSON/text 형식을 파싱하도록 보정되어 있다.

선택한 1차 평가 시나리오

현재 1차 평가는 원문 기준을 우선하여 window-local R0 precondition을 먼저 적용하고, 실행 파라미터는 README 예시값인 warmup 2회 + measurement 8회를 사용한다.

이유:

• harness가 실제 쓰는 raw-device capacity는 약 9.5GiB
• 기본 PRECONDITION_SIZE_GB=32는 이 window를 약 3.4배 덮는다
• clean window 상태를 피하고, 측정 대상 span에 sequential fill + random overwrite를 넣을 수 있다
• PoC README의 3모드 비교 예시값인 --warmup-iterations 2 --iterations 8을 그대로 반영한다
• full-device precondition보다 시간이 짧아 PoC harness 자체의 1차 WAF 비교에 적합하다

단, 이 결과는 다음처럼 표현해야 한다.

원문 기준 window-local preconditioned PoC WAF result

아래처럼 표현하면 안 된다.

full-device sustained-state WAF result

정식 실행 순서

각 mode 전에 R0를 수행한다.

R0 window-local precondition
→ R1 no_fdp
→ R0 window-local precondition
→ R2 mixed
→ R0 window-local precondition
→ R3 separated
→ parse_results

세 mode는 같은 trace, 같은 raw window start offset, 같은 vendor counter, 같은 settle 설정을 사용한다.

정식 1차 조건:

항목	값
trace scale	stress
warmup iterations	2
measurement iterations	8
R0 span	32GiB
R0 offset	2199023255552 bytes
mode window shift	disabled
replay settle	30s
post-measure settle	360s

실행 명령

주의:

• destructive command다.
• /dev/nvme0n1 namespace를 blkdiscard한다.
• 다른 benchmark/write workload와 동시에 실행하면 전역 SMART/OCP counter가 섞인다.

cd /home/ny/work/fdp/04_measure

for mode in no_fdp mixed separated; do
  sudo env \
    HOME=/home/ny \
    NVME_DEV=/dev/nvme0 \
    NVME_NS=/dev/nvme0n1 \
    FDP_ENDGRP_ID=1 \
    OUT=/home/ny/fdp_measure_waf_r0_window32g \
    R0_CONFIRM=YES \
    PRECONDITION_OFFSET_BYTES=2199023255552 \
    PRECONDITION_SIZE_GB=32 \
    PRECONDITION_RANDOM_OVERWRITE=1 \
    PRECONDITION_RANDOM_PASSES=1 \
    VENDOR_MEDIA_WRITE_COMMAND="nvme ocp smart-add-log /dev/nvme0n1 -o json" \
    bash run_R0_precondition.sh

  sudo env \
    HOME=/home/ny \
    REPO=/home/ny/work/LMCache-fdp-poc-src \
    NVME_DEV=/dev/nvme0 \
    NVME_NS=/dev/nvme0n1 \
    NVME_IO_DEV=/dev/ng0n1 \
    FDP_ENDGRP_ID=1 \
    FDP_RUH_COUNT=8 \
    TRACE_SCALE=stress \
    WARMUP_ITERATIONS=2 \
    MEASUREMENT_ITERATIONS=8 \
    REPLAY_SETTLE_SECONDS=30 \
    POST_MEASURE_SETTLE_SECONDS=360 \
    VENDOR_MEDIA_WRITE_COMMAND="nvme ocp smart-add-log /dev/nvme0n1 -o json" \
    DISABLE_MODE_WINDOW_SHIFT=1 \
    WINDOW_START_OFFSET_BYTES=2199023255552 \
    OUT=/home/ny/fdp_measure_waf_r0_window32g \
    bash run_poc_harness.sh "$mode"
done

/usr/bin/python3 parse_results.py /home/ny/fdp_measure_waf_r0_window32g \
  > /home/ny/fdp_measure_waf_r0_window32g/results_summary.csv

/usr/bin/python3 write_report.py /home/ny/fdp_measure_waf_r0_window32g \
  > /home/ny/fdp_measure_waf_r0_window32g/report.md

빠른 smoke/debug만 필요할 때는 위 명령에서 아래 두 값만 낮춘다. 이 결과는 README 기준 정식 결과로 쓰지 않는다.

WARMUP_ITERATIONS=0
MEASUREMENT_ITERATIONS=1

유효성 판정 기준

각 mode가 아래 조건을 만족해야 한다.

조건	기준
records	measurement 구간 records가 0보다 크고 세 mode가 같은 조건에서 생성될 것
failures	0
host_write_bytes_delta	> 0
media_write_bytes_delta	> 0
waf_status	available
fdp_hbmw_delta	> 0

하나라도 실패하면 해당 mode는 invalid로 분리한다. 특히 host_write_bytes_delta=0이면 WAF 계산 대상이 아니다.

참고: results_summary.csv와 report.md의 records/p99는 worker_logs/*/measurement_*/records.jsonl만 집계한다. warmup records는 WAF 계산과 동일하게 정식 결과에서 제외한다.

생성 산출물

README 기준 3모드 batch가 끝나면 아래 파일이 생성된다.

산출물	위치	의미
harness run summary	R_<mode>_*/summary.md	PoC harness가 mode별로 직접 생성하는 기본 summary
harness run JSON	R_<mode>_*/summary.json	WAF, host/media write delta, worker 결과의 machine-readable 원본
parsed CSV	results_summary.csv	parse_results.py가 3모드 결과를 한 CSV로 집계
batch report	report.md	write_report.py가 생성하는 팀 공유용 batch report

report.md에는 각 mode의 summary.md 링크가 포함된다. 따라서 공유 시에는 report.md를 진입점으로 두고, 세부 harness 원본은 링크된 R_<mode>_*/summary.md에서 확인한다.

결과 해석 지표

1차 PoC harness에서 볼 지표:

지표	의미	결론 방향
WAF	media write / host write	낮을수록 좋음
host write delta	host가 SSD에 요청한 write 총량	낮을수록 write pressure 낮음
media write delta	OCP physical media written delta	낮을수록 media write pressure 낮음
FDP HBMW/MBMW/MBE	FDP stats 기반 host/media/erase proxy	낮을수록 GC/erase pressure 낮음
write p99	storage replay write tail latency	낮을수록 좋음

이번 PoC harness에서는 TTFT와 실 workload hit ratio는 측정하지 않는다. 그 지표는 2차 tensormesh 통합 단계에서 측정한다.

확장 시나리오

32GiB window-local R0 결과가 유효하면 다음 단계는 precondition span을 키워 결과가 유지되는지 확인한다.

권장 순서:

단계	R0 설정	목적
A	PRECONDITION_SIZE_GB=32	빠른 PoC WAF 검증
B	PRECONDITION_SIZE_GB=256	더 큰 local span에서 재현성 확인
C	PRECONDITION_SIZE_GB=512	device-level GC pressure에 더 가까운 결과 확인
D	PRECONDITION_OFFSET_BYTES=0 PRECONDITION_SIZE_GB=auto	원문 sustained-state 의도에 가장 가까운 full-span precondition

full-span R0 예:

sudo env \
  HOME=/home/ny \
  NVME_DEV=/dev/nvme0 \
  NVME_NS=/dev/nvme0n1 \
  FDP_ENDGRP_ID=1 \
  OUT=/home/ny/fdp_measure_waf_r0_full \
  R0_CONFIRM=YES \
  PRECONDITION_OFFSET_BYTES=0 \
  PRECONDITION_SIZE_GB=auto \
  PRECONDITION_RANDOM_OVERWRITE=1 \
  PRECONDITION_RANDOM_PASSES=1 \
  VENDOR_MEDIA_WRITE_COMMAND="nvme ocp smart-add-log /dev/nvme0n1 -o json" \
  bash run_R0_precondition.sh

현재 target에서 PRECONDITION_SIZE_GB=auto dry-run은 namespace 크기를 약 3.76TB로 읽고, offset 0 기준 약 3501GiB span을 구성했다. 이 경로는 시간이 오래 걸리므로 최종 평가용으로 분리한다.

현재 결과와 비교

현재까지 나온 결과는 두 종류로 분리한다.

결과	위치	성격	원문/README 기준 판단
separated WAF probe	/home/ny/fdp_measure_waf_probe/R_separated_20260615T103716	WAF counter 동작과 separated mode 실행 가능성 확인	WAF 산출은 유효하지만 warmup=0, measurement=1, R0 미명시라 정식 1차 결과는 아님
3-mode final comparison	/home/ny/fdp_measure_3mode_final	no_fdp/separated/mixed 같은 조건 비교	3-mode 비교는 유효하지만 vendor media counter 없이 실행되어 정식 WAF는 unavailable

다른 사람 separated 결과표와 1:1 비교

비교 대상:

다른 사람: /home/ksy/waf-fdp-separated
우리 probe: /home/ny/fdp_measure_waf_probe/R_separated_20260615T103716

항목	다른 사람 separated	우리 separated WAF probe	일치도
Mode	separated	separated	일치
Device path	/dev/ng0n1	/dev/ng0n1	일치
Block device path	/dev/nvme0n1	/dev/nvme0n1	일치
Workers	9	9	일치
Warmup iterations	2	0	불일치
Measurement iterations	8	1	불일치
Total replay processes	90	9	run 길이 차이
Process failures	0	0	일치
Replay record failures	0	0	일치
Host write bytes delta	269,856,256,000	44,993,024,000	run 길이 차이
Host write delta	251.32GiB	41.90GiB	run 길이 차이
Media write bytes delta	274,253,004,800	45,707,427,840	run 길이 차이
Media write delta	255.42GiB	42.57GiB	run 길이 차이
WAF	1.0163	1.0159	거의 일치
WAF status	available	available	일치
FDP logs	xnvme unavailable	xnvme unavailable	일치
R0 precondition size	미기재	미기재/미적용 probe	둘 다 원문 기준으로 불충분

해석:

• WAF 산출 방식과 separated mode의 WAF 비율은 잘 재현됐다. 1.0163 vs 1.0159로 차이는 매우 작다.
• 다른 사람 결과는 README 예시 run shape(warmup=2, measurement=8)을 따른 것으로 보인다.
• 우리 separated WAF probe는 WAF counter 확인용 짧은 실행이다. 원문 기준 정식 평가 결과로 쓰려면 R0 precondition을 명시하고 README run shape으로 재실행해야 한다.

Workload pressure 비교

Workload	Workers	Class	FDP data RUHs	FDP metadata RUHs	다른 사람 measurement logical store	우리 probe measurement logical store
llama8b_chat_chunk256	2	hot_churn	0,1	2	160GiB	20GiB
llama70b_longctx_chunk1024	1	large_model/cold_rag	3,4	5	80GiB	10GiB
rag_shared_prefix_chunk512	2	cold_rag	3,4	5	192GiB	24GiB
random_prompts_chunk128	3	hot_churn	0,1	2	192GiB	24GiB
metadata_heavy_small_objects	1	metadata_heavy	6	7	64GiB	8GiB
합계	9				688GiB	86GiB

다른 사람 결과의 workload pressure는 우리 probe의 정확히 8배다. 이는 다른 사람 결과가 measurement=8, 우리 probe가 measurement=1이기 때문이다. 따라서 WAF ratio는 비교할 수 있지만, total host/media write volume과 log warning count는 직접 비교하면 안 된다.

현재 결과의 기준 충족도

평가 기준	다른 사람 결과표	우리 separated WAF probe	우리 3-mode final
원문 목표: lifetime 분리	separated mode만 확인	separated mode 확인	3-mode 중 separated 확인
원문 목표: WAF 산출	available	available	unavailable
원문 목표: clean-state 회피/R0	precondition 정보 없음	precondition 정보 없음	precondition 정보 없음
README: stress scale	충족으로 보임	충족	충족
README: warmup=2, measurement=8	충족	미충족	미충족
README: 3-mode 비교	미충족	미충족	충족
failure-free replay	충족	충족	충족
p99 latency	표에는 없음	추출 가능	추출 완료
xnvme FDP logs	unavailable 명시	unavailable 명시	unavailable

결론적으로, 다른 사람 결과표는 README run shape과 WAF available 측면에서는 더 완성도가 높지만, 원문 기준의 preconditioning 정보는 빠져 있다. 우리 probe는 WAF ratio 재현성은 좋지만 짧은 실행이다. 우리 3-mode final은 모드 비교는 좋지만 정식 WAF가 빠져 있다.

다음 실행 우선순위

원문 우선순위와 README 실행 기준을 모두 만족하려면 다음 순서가 맞다.

순서	실행	목적
1	R0 window-local 32GiB → separated, warmup=2, measurement=8	다른 사람 결과표와 1:1 비교 가능한 separated WAF 결과 확보
2	같은 R0 조건으로 no_fdp, mixed 실행	원문 가설 검증을 위한 3-mode WAF 비교 완성
3	3-mode 결과 유효 시 R0 span을 256GiB/512GiB로 확장	window-local 결과가 span에 민감한지 확인
4	필요 시 full-span R0	device-wide sustained-state 주장 강화

결론

현재 코드와 스크립트로 원문 PoC가 의도한 평가 흐름은 실행 가능하다.

현재 채택할 원문 우선 1차 시나리오는:

R0 window-local precondition 32GiB
→ no_fdp / mixed / separated, each with warmup=2 and measurement=8
→ 정식 WAF + FDP proxy + p99 비교

이 시나리오는 원문 HTML의 clean-state 회피 요구를 window-local R0로 반영하고, PoC harness README의 3모드 비교 조건을 따른다. 실제 사용하는 9.5GiB raw window를 32GiB R0로 덮으므로 1차 PoC WAF 검증에는 충분하다. 다만 device-wide sustained-state 결론은 아니므로, 최종 주장에는 더 큰 span 또는 full-span R0 결과가 필요하다.