안녕하세요 HN, 저희는 Ismaeel, Eren, Yafet, 그리고 Nikodem입니다. 저희는 Kubernetes나 SLURM와 같은 스케줄러/오케스트레이터(orchestrators)를 실행하는 HPC/GPU 클러스터의 유효 용량을 높이기 위해 Expanse (https://expanse.sh/)를 구축했습니다. 저희는 클러스터가 작업을 인지하기 전에, 소스 코드, 작업 제출 스크립트(job submission script), 그리고 워크로드(workload)가 실행될 하드웨어를 읽어 해당 작업이 실제로 무엇을 필요로 하는지 예측합니다. 또한 발생할 것으로 예상되는 실패를 표시하고, 연구자가 직접 적용할 수 있는 라인 레벨(line-level) 최적화 방안을 제시합니다.

문제점: 데이터 센터의 유효 활용률(effective utilisation)은 대략 30%에서 40% 수준입니다. 사용자들은 비대칭적 위험(asymmetric risk) 때문에 실제로 필요한 것보다 더 많은 리소스를 요청합니다. 과다 요청(over-requesting)은 비용이 많이 들고 다른 사람이 사용할 수 있는 용량을 낭비하기 때문에 나쁘지만, 과소 요청(under-requesting)은 실행 중인 작업을 중단시켜 며칠간의 작업물을 날리게 만들기 때문입니다. 그래서 모두가 두 배에서 세 배 정도 과다 요청을 합니다.

저희는 한 국가 규모의 HPC 클러스터를 한 달 동안 측정했으며, 122,000개의 작업 중 59%의 컴퓨팅 자원이 낭비되는 것을 확인했습니다. 동일한 하드웨어에 대한 온디맨드(on-demand) 클라우드 요율을 적용하면, 단 하나의 클러스터에서 한 달 동안 약 850만 달러의 컴퓨팅 자원이 낭비되는 셈입니다. 이러한 패턴은 퀀트 펀드(quant funds), AI 연구소, 제조 산업과 같은 대규모 컴퓨팅 산업에서도 유사하게 나타납니다.

저희 네 명은 대형 퀀트 펀드와 HPC 시설에서 HPC 및 GPU 학습 워크로드를 운영해 왔습니다. Ismaeel은 Adrian Jackson의 지도하에 EPCC(에든버러 병렬 컴퓨팅 센터, 영국의 국가 HPC 사이트)에서 연구를 수행했으며, 그곳에서 최초의 멀티모달(multimodal) HPC 리소스 예측기를 구축했습니다. 이는 작업 소스 코드, 제출 스크립트, 하드웨어 텔레메트리(telemetry) 및 클러스터 메타데이터를 입력받아 실제로 얼마나 많은 컴퓨팅 자원이 필요할지 파악하는 모델입니다. EPCC 자체 클러스터의 실제 워크로드 데이터셋을 대상으로 테스트했을 때, 이 모델은 다른 어떤 베이스라인(baseline)보다 34% 더 높은 점수를 기록했으며, 동일한 예측 작업에 프롬프트(prompted)를 제공한 최첨단 범용 LLM보다 약 8배 더 뛰어난 성능을 보였습니다. 이러한 결과는 저희에게 이 문제가 소프트웨어로 해결 가능하다는 확신을 주었습니다.

Expanse는 모든 노드에 설치되어 SLURM(또는 K8s 스케줄러)에 연결됩니다. 클러스터의 실시간 하드웨어 텔레메트리(Telemetry; DCGM, CUPTI, Cgroups, Network/IO 모니터링)를 수집하여 하드웨어가 어떻게 작동하는지에 대한 커스텀 임베딩(Embedding)을 생성합니다. 저희는 SLURM/K8s를 통해 제출될 예정인 모든 워크로드(Workload)를 스캔하며(작업 제출 방식을 변경할 필요가 없도록 작업의 라이프사이클에 직접 연결됨), 이를 딥러닝(Deep Learning) 모델에 입력하여 연구자들에게 작업 제출 시점에 정확한 리소스 권장 사항, 장애 감지 및 최적화 제안을 제공합니다. 저희는 더 많은 워크로드를 실행할수록 시간이 지남에 따라 더욱 정교해지는 클러스터 특화 모델을 파인튜닝(Fine-tune)합니다. 저희 모델은 작업이 충돌(Crash)했을 때 발생하는 비대칭적인 결과(Asymmetric outcomes)를 고려하여, 리소스를 부족하게 할당(Under-provision)하기보다는 과다하게 할당(Over-provision)하도록 학습되었습니다. 또한 사용자가 자신의 위험 허용 범위(Risk tolerance)를 선택할 수 있도록 불확실성 추정치(Uncertainty estimates)와 p90 값을 제공합니다.

저희는 클러스터 사용자에게 세 가지 기능을 제공합니다:

(1) 제출 시점의 리소스 예측. 작업에 실제로 필요한 GPU VRAM, 사용률(Utilisation), 메모리, CPU 및 실행 시간(Walltime)을 신뢰 구간(Confidence interval)과 함께 예측합니다. 이러한 예측을 바탕으로 OOM(Out of Memory) 및 기타 메모리 관련 문제에 대한 장애 예측과, 하드웨어에서 작업의 사용률을 높이기 위한 코드 라인 수준의 최적화 방안도 함께 제공합니다.

(2) 실시간 관측성(Live Observability). 작업이 실행되는 동안, 하드웨어에서 어떤 일이 일어나고 있는지, 그리고 코드 스택 프로파일링(Code stack profiling) 관점에서 워크로드가 어느 단계에 있는지 직관적으로 보여주는 대시보드를 통해 수집된 텔레메트리를 시각화합니다. 저희는 유익한 정보를 제공하면서도 한 자릿수 미만의 낮은 오버헤드(Overhead)를 달성하기 위해 워크로드를 동적으로 프로파일링합니다.

(3) 장애 진단. 워크로드가 실패하면, 수집된 모든 데이터를 사용하여 스택 프로파일링과 하드웨어 텔레메트리 간의 상관관계(Correlation)를 분석하여 해결 중심의 로그를 제공합니다. 이는 작업이 실패했을 때 무엇이 일어났는지뿐만 아니라, 왜 발생했는지, 그리고 코드 라인 수준의 제안을 통해 어떻게 수정해야 하는지를 알려주는 한두 줄의 로그입니다.

우리의 접근 방식이 다른 점: 대부분의 클러스터에서 사용하는 최첨단 (State of the art) 방식은 sacct (SLURM accounting DB)를 통한 사용자별 과거 평균값, 수동으로 작성된 규칙/휴리스틱 (heuristics), 또는 최신 LLM 코딩 에이전트 (coding agents) 중 하나를 사용하는 것입니다. sacct를 통한 사용자별 과거 평균값 방식의 경우, 클러스터에 새로운 유형의 워크로드 (workload)가 제출되거나 코드 수준의 변경이 발생하면 모델의 정확도가 급격히 떨어집니다. LLM 베이스라인의 경우, 실행 중인 워크로드의 제출 스크립트와 소스 코드를 제공하고 클러스터 내 코딩 하네스 (coding harness)의 모든 기능을 부여했음에도 불구하고 성능이 상당히 저조했습니다. 우리는 Expanse를 당시의 최첨단 모델들 (Gemini 3.5 pro, Claude Opus 4.8, GPT 5.5, Codex 5.3)과 벤치마킹하였으며, 이들보다 8배 더 뛰어난 성능을 보였습니다.

이러한 모델들이 확장되고 개선됨에 따라 이 작업에서 우리를 이길 수도 있다고 생각할 수도 있습니다. 하지만 우리는 모델의 크기나 반복 학습 (iteration)과 정확도 향상 사이에 아무런 상관관계가 없음을 확인했습니다. 실제로 Claude Haiku는 많은 워크로드에서 Opus보다 더 나은 성능을 보였으며, 이전 버전의 모델들도 비슷하거나 심지어 약간 더 높은 정확도를 보였습니다. Codex 5.3과 같은 코딩 특화 모델조차 성능이 저조했습니다 (GPT 5.5와 유사한 정확도). 이러한 모델들은 진공 상태에서 추론합니다. 소스 코드(기저의 데이터 흐름과 계산 패턴을 이해하기 위한 용도)나 하드웨어 텔레메트리 (telemetry) 및 토폴로지 (topology, 클러스터의 성능 패턴을 이해하기 위한 용도)와 같은 모달 입력 (modal inputs)에 대한 네이티브 지원이 없기 때문에, 워크로드가 필요로 하는 리소스를 정확하게 예측할 수 없습니다. 또한, Expanse는 클러스터에서 더 많은 워크로드가 실행됨에 따라 예측이 더욱 정확해지도록 내부 모델을 지속적으로 업데이트하므로, 새로운 하드웨어나 워크로드 패턴의 변화에 매우 적합합니다. LLM은 코드 작성과 하이퍼파라미터 스윕 (hyper parameter sweeps)에는 매우 뛰어나지만, 자동 연구 (auto research)를 위한 전체 에이전트 루프 (agentic loop)를 완성하기 위해서는 Expanse가 필요합니다. 우리의 CLI 도구들을 LLM 친화적으로 설계했기 때문에, 이러한 에이전트들에 우리의 도구를 연결하는 것은 매우 쉽습니다.

우리의 LLM 평가 (eval)에 대한 자세한 내용은 다음을 확인하세요: https://x.com/ismaeel_bashir_/status/2059683849404383283

현재 유료 파일럿 (paid pilots) 고객을 온보딩하고 있습니다. 가격은 클러스터 (cluster)당 결정됩니다. 저희는 데이터 센터 운영자에게 설치, 데이터 수집 (ingest), 그리고 회수 가능한 용량 (recoverable capacity)을 보고하는 2주간의 측정 기간을 제공하며, 이후에는 고정된 월간 요금으로 한 부서에 유료 파일럿 배포를 진행합니다. 범위가 확장되지 않는 한 동일한 요율로 갱신됩니다.

만약 HPC/GPU 클러스터 (SLURM 또는 K8s, 100개 이상의 GPU)를 운영 중이시라면, 저희와 이야기를 나누고 싶습니다. 귀하의 클러스터 일부에 일주일 동안 설치하여 무엇을 회수할 수 있는지 서면 보고서를 보내드릴 것이며, 그 이후 계속 진행할지 여부는 직접 결정하시면 됩니다. 만약 이와 유사한 시도를 해보았으나 효과가 없었다면, 그 이유를 꼭 듣고 싶습니다. 또한, 본 게시물에서 언급하지 않았지만 예측되기를 원하는 실패 모드 (failure mode)가 있다면 이 스레드에 남겨주세요. 모델이 이미 이를 감지하는지, 혹은 추가하기 위해 무엇이 필요한지 답변해 드리겠습니다.

제가 Launch HN의 반대편에 서게 될 줄은 몰랐네요 :). 클러스터를 운영하지 않더라도 여러분의 의견을 듣고 싶습니다. 저희의 접근 방식에 대한 생각, 클러스터에서 워크로드 (workloads)를 실행한 경험, 또는 저희가 틀렸다고 생각하는 부분 등 무엇이든 환영합니다.

Tally Ho!