round-to-round-nonreproducibility.md(#496, 2026-08-23)를 실행 전에 독립적으로 읽었다. 설계의 뼈대에는 이견이 없고, 실행 전에 답해야 할 것 셋만 남긴다.
⚠️ 이 이슈는 검토 의견이지 결정이 아니다. 설계 문서는 «착수는 사용자 confirm 후» 로 서 있고, 아래 셋도 같은 취급이다.
뼈대는 옳다 (동의하는 부분)
docker stats 의 CPU % 는 시간 측정이지 «일의 양» 이 아니다. 물리 호스트의 유효 클럭이 다르면 같은 CPU% 로 다른 양의 일을 한다.
관측된 서명(«AI CPU 869.3% → 869.0% 로 같은데 처리량 +17.7%»)이 정확히 그 모양이라 가설이 데이터에 맞다. 그리고 rig 을 새로 안 짜도 된다(R6 의 profile_e2e_and_scaling.py scaling 1워커 판)는 것도 맞다 — 그 자리에 79.9 fps 라는 값이 이미 있다.
① 축 0 은 «확정 대기» 가 아니라 從 목록에 올릴 것으로 보인다
§5 가 스스로 적었다 — 축 0 은 라운드당 1~2분 · 새 인스턴스 0 이고, "1번은 EC2 결정이 필요 없다(다음 라운드에 얹으면 된다)".
그렇다면 이건 착수 confirm 을 기다리는 항목이라기보다 AWS-RIDE-ALONG.md 從 목록의 형태다 — 그 문서가 «인프라가 살아 있을 때만 · 추가 비용 거의 0» 으로 정의한 등급과 정확히 같다.
제안: 축 0 만 從 으로 분리해 먼저 등록하고, 축 A·B(인스턴스 K대·재부팅 M회)만 confirm 대상으로 남긴다. 그러면 "1번만 해도 이 항목의 성격이 바뀐다" 는 설계 자신의 주장이 다음 라운드에 자동으로 실현된다.
② 「보정값이 안 움직이는」 분기의 다음 수가 없다
§2 의 판정표가 비대칭이다.
| 보정값이 |
설계가 적은 것 |
|
| 처리량과 같이 움직인다 |
🎯 EC2 성질 → 인용 규칙의 문제 |
✅ 결론이 닫힌다 |
| 안 움직인다 |
"①(부하기) 또는 앱 안의 무엇. 그때 비로소 우리 문제다" |
🔴 후보가 다시 열리는데, 다음 수가 없다 |
«우리 문제다» 까지는 판정인데, 그 뒤에 무엇을 할지가 설계에 없다. 그 분기가 나오면 또 설계부터 시작해야 한다.
제안: 안 움직이는 경우의 첫 수만이라도 적어둘 것. 예컨대 P6-b 2라운드가 부하기를 c7i.large → c7i.xlarge 로 바꾼 판이었으므로, 축 C(부하기 타입)가 «우선순위 낮음» 에서 1순위로 올라오는 조건이 바로 이 분기다 — 그 연결이 문서에 없다.
③ R6 의 79.9 fps 를 「과거 보정값」으로 못 쓰는 이유가 안 적혀 있다
§6 이 "🔴 P6 1·2라운드의 보정값은 영영 없다. 그 박스들은 사라졌고 … 사후 규명이 불가능할 수 있다" 고 적었다.
그런데 R6 은 2026-08-17 · c7i.4xlarge 에서 돌았고, P6 2라운드(08-16b)와 하루 차이 · 같은 계열 박스다. 정확히 같은 인스턴스가 아니라는 것은 분명하지만, «완전히 없는 것» 과 «비교 가능성이 의심스러운 한 점이 있는 것» 은 다르다.
제안: 쓰든 안 쓰든, 왜 못 쓰는지를 한 줄 적을 것. 지금은 그 후보가 검토된 흔적 자체가 없어서, 나중에 읽는 사람이 같은 질문을 다시 하게 된다.
⚠️ 🔴 나는 R6 값이 쓸 수 있다고 주장하지 않는다 — 인스턴스 타입·날짜·model_complexity 조건이 같은지 안 대조했다. 여기서 말하는 것은 «검토한 흔적이 없다» 까지다.
이 검토가 안 한 것
- 설계를 실행하지 않았다. 이 항목은 다른 세션이 소유한 자리라 중복을 피했다
- 축 A·B 의 통계 설계(K·M 값)는 안 봤다 — 설계도 «안 정했다» 로 열어둔 자리다
- 판정선(§4)은 안 검토했다
round-to-round-nonreproducibility.md(#496, 2026-08-23)를 실행 전에 독립적으로 읽었다. 설계의 뼈대에는 이견이 없고, 실행 전에 답해야 할 것 셋만 남긴다.뼈대는 옳다 (동의하는 부분)
관측된 서명(«AI CPU 869.3% → 869.0% 로 같은데 처리량 +17.7%»)이 정확히 그 모양이라 가설이 데이터에 맞다. 그리고 rig 을 새로 안 짜도 된다(R6 의
profile_e2e_and_scaling.py scaling1워커 판)는 것도 맞다 — 그 자리에 79.9 fps 라는 값이 이미 있다.① 축 0 은 «확정 대기» 가 아니라 從 목록에 올릴 것으로 보인다
§5 가 스스로 적었다 — 축 0 은 라운드당 1~2분 · 새 인스턴스 0 이고, "1번은 EC2 결정이 필요 없다(다음 라운드에 얹으면 된다)".
그렇다면 이건 착수 confirm 을 기다리는 항목이라기보다
AWS-RIDE-ALONG.md從 목록의 형태다 — 그 문서가 «인프라가 살아 있을 때만 · 추가 비용 거의 0» 으로 정의한 등급과 정확히 같다.제안: 축 0 만 從 으로 분리해 먼저 등록하고, 축 A·B(인스턴스 K대·재부팅 M회)만 confirm 대상으로 남긴다. 그러면 "1번만 해도 이 항목의 성격이 바뀐다" 는 설계 자신의 주장이 다음 라운드에 자동으로 실현된다.
② 「보정값이 안 움직이는」 분기의 다음 수가 없다
§2 의 판정표가 비대칭이다.
«우리 문제다» 까지는 판정인데, 그 뒤에 무엇을 할지가 설계에 없다. 그 분기가 나오면 또 설계부터 시작해야 한다.
제안: 안 움직이는 경우의 첫 수만이라도 적어둘 것. 예컨대 P6-b 2라운드가 부하기를
c7i.large→c7i.xlarge로 바꾼 판이었으므로, 축 C(부하기 타입)가 «우선순위 낮음» 에서 1순위로 올라오는 조건이 바로 이 분기다 — 그 연결이 문서에 없다.③ R6 의 79.9 fps 를 「과거 보정값」으로 못 쓰는 이유가 안 적혀 있다
§6 이 "🔴 P6 1·2라운드의 보정값은 영영 없다. 그 박스들은 사라졌고 … 사후 규명이 불가능할 수 있다" 고 적었다.
그런데 R6 은 2026-08-17 ·
c7i.4xlarge에서 돌았고, P6 2라운드(08-16b)와 하루 차이 · 같은 계열 박스다. 정확히 같은 인스턴스가 아니라는 것은 분명하지만, «완전히 없는 것» 과 «비교 가능성이 의심스러운 한 점이 있는 것» 은 다르다.제안: 쓰든 안 쓰든, 왜 못 쓰는지를 한 줄 적을 것. 지금은 그 후보가 검토된 흔적 자체가 없어서, 나중에 읽는 사람이 같은 질문을 다시 하게 된다.
model_complexity조건이 같은지 안 대조했다. 여기서 말하는 것은 «검토한 흔적이 없다» 까지다.이 검토가 안 한 것