coresidency_sweep.sh의 캡 확인(caps.tsv)이 docker-compose.yml 기본 CPU 캡(#212/#570)과 충돌해 리허설이 항상 FAIL한다

[Khyojae]

배경

R9(관측 스택 동거 비용, 팔 D — docs/decisions/ai-coresidency-capacity.md §3)를 처음 EC2에 올려 P6/coresidency 라운드를 재실행했는데(2026-09-07), coresidency_rehearsal이 즉시 FAIL(1)로 끝나 본판(coresidency)이 SKIP됐다. 이 rig가 마지막으로 성공한 라운드는 2026-08-17이다.

현상 (근거, file:line)

• loadtest/results/coresidency-2026-08-15/coresidency_sweep.sh:258 — 팔 A/B(캡 없음이 기대값, want=0)에서 컨테이너의 nanocpus가 0이 아니면 verdict=STALE; rc=1로 판정한다.
• 실제 실행 결과(caps.tsv, S3 s3://shadowfit-measure-055447613012/shadowfit/ec2-20260907-065220/coresidency_rehearsal/caps.tsv):

  epoch       arm  container           nanocpus     expected  verdict
  1788763948  B    shadowfit-ai        4000000000   -         STALE
  1788763948  B    shadowfit-backend   4000000000   -         STALE
  1788763949  A    shadowfit-ai        4000000000   -         STALE
  1788763949  A    shadowfit-backend   4000000000   -         STALE
  

• 원인: docker-compose.yml:110과 :202가 cpus: ${BACKEND_CPU_LIMIT:-4} / cpus: ${AI_CPU_LIMIT:-4}로 기본값 4코어 캡을 항상 건다 — 이 줄은 2026-08-26/27 커밋 57f852c1(컨테이너에 CPU 한도가 하나도 없다 — 메모리는 걸어놓고 CPU 는 안 걸어, AI·MySQL·관측이 서로 코어를 뺏는다 #212)·4fac4487(shadowfit-backend 컨테이너에 메모리·CPU 한도가 없다 — AI만 있고 짝이 안 맞는다 #570)에서 추가됐다("AI가 호스트 코어를 전부 가져가는 문제" 대응).
• coresidency_sweep.sh는 2026-08-17 성공 라운드 이후 재검증된 적이 없어서, 그 사이(08-26~27)에 생긴 이 기본 캡을 전제에 반영하지 못했다 — "팔 A/B = 캡 없음"이 이제 더는 참이 아니다(컨테이너를 그냥 띄우면 기본이 4코어 캡).

영향

• P6/coresidency 계열 라운드는 리허설에서 항상 FAIL(1) → 본판 SKIP. run_all.sh는 collect(업로드)까지는 성공하므로 AUTO_SHUTDOWN=1이 정상 발동해 인스턴스가 스스로 꺼진다 — 겉보기엔 "정상 종료"라 실패를 놓치기 쉽다.
• 오늘 EC2 실측(대상 c7i.4xlarge 약 20분 · 부하기 c7i.xlarge 약 11분) 전량 낭비, R9(관측 스택 팔 D)는 검증 못함.

미검증

• 고치는 방향(리허설/본판 시작 전에 docker update --cpus 0으로 캡을 명시적으로 초기화할지, 아니면 caps.tsv의 "기대값" 자체를 팔 A/B에서도 4코어로 바꿀지 등)은 확인 안 했다 — 결정 필요.
• 팔 C/D(캡 있음 조건)가 정상적으로 검증되는지는 리허설이 A/B에서 먼저 죽어서 확인 못했다.