RTX 5060 2대 확장 분석 및 hb5u·cmg-cv16 오케스트레이션을 AWS(EROS)가 맡아야 하는 이유
초록
이전 논문(hb5u 단일 RTX 5060 인프라 이식 가능성 분석)의 후속. RTX 5060을 2대로 늘렸을 때 THiGERLLM 풀 학습 병목이 여전히 해소되지 않음(용량보다 NVLink 부재로 인한 상호연결 병목이 더 근본적)을 확인하고, hb5u·cmg-cv16 두 엣지 노드가 상시 가동이 아니라는 제약 하에서 절충 경로(추론 분리 배치, ComplEx 단독 학습, LoRA 파인튜닝)를 동적으로 선택·배포하는 오케스트레이션 역할은 상시 가동 노드인 AWS(EROS)가 맡아야 한다고 제안한다. 이는 레포에 이미 문서화된 RTX 5090(Aegis)-RTX 4070(Moojoco) 긴급 폴백 아키텍처의 자연스러운 확장으로 설계했다.
1. 개요
이 논문은 안건 2026-09-08-hermes-ari-hakken-review-analysis-and-hb5u-infra-feasibility(HakkenOSS 인프라의 hb5u 이식 가능성 분석)의 후속으로, (1) RTX 5060 2대로 확장했을 때 실질적으로 무엇이 달라지는지, (2) hb5u·cmg-cv16 두 엣지 노드가 상시 가동 상태가 아니라는 사령관의 지적에 따라 오케스트레이션(orchestration)을 누가 맡아야 하는가를 다룬다.
2. RTX 5060 2대 — 용량이 아니라 상호연결이 진짜 병목
논문(Hakken)이 THiGERLLM 학습에 명시한 자원은 H100 2대다. 이를 RTX 5060 2대와 비교하면 두 층위에서 격차가 난다.
용량: H100 2대는 HBM3 총 160GB를 NVLink로 사실상 단일 메모리 풀처럼 쓴다. RTX 5060 2대는 (Ti가 아닌 기본형 기준 카드당 8GB 추정) 합쳐야 16GB이며, 이마저 단순 합산이 아니라 모델 병렬화를 직접 구현해야 나눠 쓸 수 있다.
상호연결: H100은 NVLink(~900GB/s)로 GPU 간 통신하는 반면, 소비자용 카드 2장은 PCIe로만 통신한다. 그래프 브랜치(GraphSAGE)와 텍스트 브랜치(Mistral-7B)를 주고받으며 학습해야 하는 THiGERLLM 구조에서는, 이 통신 대역폭 격차가 순수 연산력 부족보다 더 치명적인 병목이 될 수 있다.
결론: 카드가 1대에서 2대로 늘어도 논문 원본 규모의 THiGERLLM 풀 학습은 여전히 불가능하다. 다만 이전 논문에서 제안한 절충안(추론 전용 경로, 또는 그래프·텍스트 브랜치 분리 배치, 또는 순수 ComplEx 임베딩의 전체 규모 학습)의 여유는 명확히 늘어난다 — 카드 1장에 그래프 브랜치, 다른 1장에 텍스트 브랜치를 분리 배치한 추론이 가능해지고, LoRA류 경량 파인튜닝을 시도할 여지도 생긴다.
3. 오케스트레이션은 왜 AWS(EROS)가 맡아야 하는가
사령관이 지적한 핵심 제약: hb5u와 cmg-cv16(RTX 5060을 각각 보유한 것으로 보이는 두 엣지 노드)은 100% 상시 가동 상태가 아니다. 즉 어느 시점에 두 노드 중 어느 쪽이 켜져 있는지, 하나만 켜져 있는지, 둘 다 꺼져 있는지가 계속 바뀐다.
이 조건에서 절충안(§2)을 실행하려면 다음을 상시 판단해야 한다: - 지금 두 노드 다 켜져 있는가 → 그래프·텍스트 브랜치 분리 배치 추론 가능 - 하나만 켜져 있는가 → 단일 GPU로 축소된 경로(예: ComplEx 단독 학습, 또는 텍스트 브랜치 없이 그래프만)로 전환 - 둘 다 꺼져 있는가 → 작업을 대기열에 넣고 노드 복귀를 기다림
이건 정확히 이 레포(CLAUDE.md)에 이미 문서화된 RTX 5090(Aegis) 장애 시 RTX 4070(Moojoco)이 긴급 폴백 서버로 전환하는 것과 같은 유형의 문제다 — 다만 이번엔 대상이 학습/추론 워크로드고, 판단 축이 "장애냐 정상이냐"가 아니라 "몇 대가 지금 켜져 있느냐"로 더 세분화된다.
엣지 노드(hb5u·cmg-cv16) 자신은 이 판단을 하기 어렵다 — 간헐적으로 꺼지는 노드가 스스로 "내가 지금 유일하게 켜진 노드인지"를 안정적으로 알기 어렵고, 설령 안다 해도 상대 노드가 언제 복귀하는지 감시할 상시성이 없다. 반면 AWS(EROS)는 상시 가동을 전제로 하는 노드이므로, 두 엣지 노드의 가용 상태를 지속적으로 폴링·관찰하고, 그 상태에 따라 어느 절충 경로를 실행할지 동적으로 결정·배포하는 역할에 구조적으로 적합하다.
4. 제안하는 역할 분담
| 계층 | 담당 | 역할 |
|---|---|---|
| 가용성 감시(watchdog) | EROS (AWS) | hb5u·cmg-cv16의 현재 온/오프 상태를 주기적으로 확인 |
| 작업 배분(dispatch) | EROS (AWS) | 두 노드의 상태 조합에 따라 §2의 절충 경로 중 하나를 선택해 배포 |
| 실제 연산 실행 | hb5u / cmg-cv16 (RTX 5060 각 1장) | 배포받은 작업(추론, ComplEx 학습, LoRA 등)을 실행 |
| 결과 회수·저장 | EROS (AWS) | 완료된 작업 결과를 회수해 영속 저장(예: data.hyperbook.com 등) |
이 구조는 이미 팀이 검증한 폴백 아키텍처(Aegis↔Moojoco)의 자연스러운 확장이며, 새로운 개념을 도입하는 게 아니라 기존 패턴을 GPU 오케스트레이션에 재적용하는 것이다.
5. 남은 과제
이 논문은 설계 방향만 제안하며, 구체적인 폴링 주기·헬스체크 프로토콜·작업 큐 구현은 다루지 않는다. 사령관의 판단대로 이 설계의 실제 구현은 EROS(AWS)가 맡는 게 합리적이며, hb5u·cmg-cv16의 실제 가동 패턴(하루 중 몇 시간, 어떤 조건에서 켜지는지)을 EROS가 먼저 파악하는 것이 다음 단계로 보인다.
참고
- 본 논문 이전 단계:
2026-09-08-hermes-ari-hakken-review-analysis-and-hb5u-infra-feasibility - 기존 폴백 아키텍처 문서: 이 레포 CLAUDE.md "3-Machine Architecture" (RTX 5090 Aegis ↔ RTX 4070 Moojoco)