Placement 정책 — daegyu 제안 ↔ 현재 코드 매핑
daegyu가 사용자(나연)에게 공유한 정책 후보 3축에 대해, 현재 코드에 어떻게 매핑되는지·검증할 baseline은 무엇인지·미해결 질문은 무엇인지 정리.
0. 정정: "rank는 device 분리로 무조건 우회되는가"
대화 초기에 "rank는 per_tp_device_paths로 우회됐다"고 단정한 적이 있는데 — 틀린 일반화. deployment topology에 따라 다르다:
| 시나리오 | per-TP device로 충족? | FDP rank PID 분리의 가치 |
|---|---|---|
| rank마다 별도 NVMe device (1 device per rank) | ✅ 물리 격리 | 추가 이득 적음 |
| device 수 < rank 수 (공유 device) | ❌ | rank별 PID 분리 시 의미 있음 |
| 단일 device, per-TP 미설정 | ❌ | 동일 |
| device당 rank 1개여도, cache_salt/model 도메인을 또 나누고 싶음 | △ | rank는 됐고 ②③에 FDP를 써야 함 |
MP mode는 per_tp_device_paths 거부 (raw_block_l2_adapter.py:154-157)
→ MP에서는 항상 두 번째/세 번째 시나리오 → FDP rank isolation이 의미를 가짐.
즉 우리 setup에서는 ①도 살아있는 후보.
1. 제안 3축
① rank isolation
"GPU worker마다 isolation 시키는 겁니다 (성능 간섭이 없다는 evaluation을 해봐야 알 것 같습니다)"
의도: 같은 device를 공유하는 multiple TP rank가 서로의 reclaim unit을 침범하지 않도록.
② domain isolation (cache_salt)
"multi-tenant에 대한 것입니다. tenant 별로 다른 access pattern을 가질거라고 예상합니다."
의도: cache_salt = tenant ID로 간주 → tenant마다 다른 RUH PID. tenant 간 GC 격리.
③ model isolation
"model 마다 access pattern이 다른데 상윤/나연님이 정리하신 자료 보고 근거를 만들려고 합니다."
의도: model이 다르면 KV cache의 hot/cold 패턴이 다르다는 가정 위에서, model별 RUH 분리.
2. 현재 코드 ↔ 제안 매핑
| 축 | 현재 코드 표면 (dev) | ankit#1이 추가하는 것 | 정책 ①②③ 구현 위치 |
|---|---|---|---|
| rank | per_tp_device_paths (in-process plugin) | _assign_fdp_placement_rank_based = placement_ids[0] placeholder | rank-별로 다른 PID 매핑 (PoC _select_fdp_ruh의 worker_index % len(fdp_data_ruh_ids) 참고) |
| cache_salt | ObjectKey의 lookup 키 필드 (FDP에 영향 없음) | 없음 | ObjectKey → cache_salt → RUH PID 매핑 함수 신설 |
| model | ObjectKey의 model_name (lookup 키 필드) | 없음 | ObjectKey → model_name → RUH PID 매핑 함수 신설 |
3. 정책 비교 표
| 축 | 분배 키 | 검증 baseline (비교 대상) | 측정 지표 | 미해결 질문 |
|---|---|---|---|---|
| ① rank | kv_rank>>16 (global rank의 worker idx) | (a) FDP off (default RUH) (b) FDP single-PID (ankit#1 baseline) (c) per_tp_device_paths (in-process only) | WAF, RU 점유 분포, p99 write latency | rank 수 > RUH 수일 때 어떻게 fallback? round-robin? hashing? |
| ② cache_salt | cache_salt hash 또는 enum | (a) FDP off (b) single-PID | tenant 간 GC interference, tenant별 read/write pattern | cache_salt가 unbounded일 때 RUH 수 한계 — buckets는 어떻게 결정? |
| ③ model | model_name hash | (a) FDP off (b) single-PID | model별 cold/hot 분리 효과, eviction churn | model 추가/제거 시 RUH 재할당 정책? hot model vs cold model을 정적으로 격리? |
4. 정책 ↔ dongdongju PoC ↔ ankit#1 매핑
| 축 | dongdongju PoC (01_branch_audit/placement_policy_notes.md) | ankit#1 | 신규 작업 |
|---|---|---|---|
| ① rank | _select_fdp_ruh의 worker_index % len(fdp_data_ruh_ids) (3단 fallback: obj metadata → kv_rank → legacy worker_id) | placement_ids[0] (placeholder) | PoC 형식이 더 풍부함 → 이걸 정식 정책으로 채택 가능 |
| ② cache_salt | harness layer (storage_class별 RUH list, resolve_policy in fdp_policy.py) | 없음 | core에 PlacementPolicy 추상 신설 또는 harness stamp 유지 |
| ③ model | 없음 (PoC harness가 storage_class를 model을 의미로 사용한 적 있는지 확인 필요) | 없음 | 완전 새 영역 |
→ ②③를 core에 박을지 / harness가 결정한 RUH ID를 ObjectKey metadata로 stamp할지가 설계 결정.
03_audit (a) gap 참조.
5. 검증 baseline matrix (제안)
각 축 단독 효과 입증을 위한 실험 매트릭스:
| 실험 | use_fdp | data_ruhs | metadata_mode | 정책 키 | 비교 대상 |
|---|---|---|---|---|---|
| B0 baseline | off | — | — | — | — |
| B1 single PID | on | [0] | default_ruh | none | B0 |
| B2 metadata 분리 | on | [0] | per_ruh ([1]) | none | B1 (이미 ankit#1이 hardcode한 효과 측정) |
| R rank policy | on | [0,1,...] | per_ruh | rank | B2 |
| D salt policy | on | [0,1,...] | per_ruh | cache_salt | B2 |
| M model policy | on | [0,1,...] | per_ruh | model | B2 |
| C combined | on | [0,1,...] | per_ruh | rank+salt or rank+model | R/D/M |
이 매트릭스는 baseline PoC repo에만 있는 benchmarks/fdp_waf_stress/의 mode no_fdp / separated / mixed로 일부 표현 가능 (01_branch_audit/04_harness_metrics.md 참조).
6. 한 줄 결론
"정해진 정책이 아니라 PoC base(ankit#1)는
placement_ids[0]단일 PID placeholder. 실제 정책 ①②③는 모두 신규 작업 영역이고, 각각 baseline 비교 실험 + access pattern 근거가 필요. MP mode setup이 정책 ①에도 자연스러운 실험장이 된다 (per_tp_device 거부 → FDP가 isolation의 유일 수단)."