Daejun (박대준)에게 보낼 질문 초안
2026-05-29 최초 작성 (#3226 기준) / 2026-06-04 갱신 (#3449 반영) 목적: #3449(zlib 압축) 후에도 HC SSD(15/30TB)에서 여전히 overflow 잔존 — 이 영역 다룰지 확인. 같은 팀이므로 직접 한국어로 슬랙/메일 가능.
한국어 버전 (슬랙/메일용) — 2026-06-04 갱신
배경 (보내기 전 참고)
#3449 정독 결과: Std SSD(7.68TB 이하) overflow는 zlib 4.6x 압축으로 해소됨. HC SSD(15/30TB)에서만 압축 후에도 payload가 cap 초과. Std SSD 문제는 이미 해결됐으니 질문 초점을 HC SSD 영역으로 좁혀서 보내는 게 맞음.
톤 (간결)
안녕하세요 박대준 책임님, nayeon입니다.
#3449 (raw_block checkpoint zlib 압축) 정독했습니다. 압축 덕에 Std SSD(3.84/7.68TB) 범위 overflow는 해소되는 걸 확인했는데, HC SSD(15/30TB)에서는 압축 후에도 payload가 여전히 cap(~64MB)을 초과합니다.
Qwen3-Coder-480B (TP=8, slot≈7.75MB) 기준:
- 7.68TB Std: 207MB → 압축 ~45MB → cap(64MB) 이하 ✅
- 15TB HC: 414MB → 압축 ~90MB → cap(64MB) 초과 ❌
- 30TB HC: 828MB → 압축 ~180MB → cap(64MB) 초과 ❌
질문: HC SSD 영역(15/30TB)의 overflow를 #3449의 follow-up으로 다루실 계획이 있으신가요, 아니면 별도 이슈/PR로 보시나요?
저쪽 방향이 없으시다면, Samsung HC SSD TCO 분석 사례와 연결해서 별도 PR을 준비해볼까 합니다. 감사합니다.
첨부할 자료
- 재현 스크립트:
private/work/s2_checkpoint_overflow/repro_checkpoint_overflow.py - 종합 분석 문서:
private/work/s2_checkpoint_overflow/s2_verification.md(§10 재평가 포함) - TCO 사례 분석 (Qwen3-480B): 같은 문서 §6b
답변 케이스별 후속 행동 (2026-06-04 갱신)
Case A: "#3449 follow-up으로 HC SSD도 다룰 것"
- v3: S2를 "Daejun #3449 follow-up으로 흡수 예정"으로 표시, 우리는 손 떼기
- 재현 스크립트는 필요 시 넘겨 회귀 테스트로 활용 제안
Case B: "별도로"
- PR 명분: "#3449 이후에도 HC SSD(15/30TB)에서 overhead 잔존 — Samsung 데이터 보강"
- 단계 전략 (갱신,
s2_verification.md§10):- 단계 1(128MB→512MB)은 #3449로 불요 — HC SSD 직접 겨냥하는 단계 2a(2GB bump)로 바로 준비
- 단계 2a:
meta_total_bytes512MB → 2GB + meta_version bump + 회귀 테스트 (HC 30TB까지) - 단계 2b: 바이너리 base RFC (layerwise까지, 장기)
Case C: "같이 보자"
- §10 임계점 표와 재현 결과로 공동 검토