▲

클라우드를 임대하지 말고, 직접 소유하세요

 (blog.comma.ai)
5P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • CommaAI는 모든 모델 학습과 데이터 처리를 자체 데이터센터에서 수행하며, 약 500만 달러 규모의 인프라를 직접 운영중
  • 클라우드 의존은 비용 상승과 통제력 상실로 이어질 수 있으며, 자체 컴퓨트 운영은 엔지니어링 품질 향상과 비용 절감을 가능하게 함
  • 데이터센터는 약 450kW 전력, 600개의 GPU, 4PB SSD 스토리지, 간단한 냉각 및 네트워크 구조로 구성되며,
  • 소프트웨어 스택은 Ubuntu + Salt, minikeyvalue(mkv) 스토리지, Slurm 스케줄러, PyTorch 분산 학습, miniray 분산 컴퓨트로 설계됨
  • comma.ai는 이 구조를 통해 자율주행 모델 학습을 완전 자동화하며, 클라우드 대비 약 5배의 비용 절감 효과를 달성

자체 데이터센터 운영의 이유

  • 클라우드에 의존하면 비용 증가와 공급자 종속이 발생
    • 클라우드 기업은 온보딩은 쉽지만 오프보딩은 어렵게 설계되어 있음
    • 지속적 사용 시 높은 비용 구조에 갇히기 쉬움
  • 자체 컴퓨트 운영은 기술 자립성과 효율적 엔지니어링 문화를 촉진
    • 클라우드는 API·결제 시스템 중심의 관리가 필요하지만, 데이터센터는 전력·연산·대역폭 중심의 실제 기술 문제 해결을 요구
  • ML 엔지니어링 측면에서도 자원 제약이 코드 최적화와 근본적 개선을 유도
    • 클라우드에서는 단순히 예산을 늘려 해결하지만, 자체 인프라에서는 성능 개선이 필수
  • 비용 측면에서 comma.ai는 약 500만 달러를 투자, 동일 작업을 클라우드에서 수행 시 2,500만 달러 이상이 필요했을 것으로 계산

데이터센터 구성 요소

  • 전력

    • 최대 450kW 사용, 2025년 전력비 540,112달러
    • 샌디에이고 전력 단가가 40센트/kWh로 세계 평균의 3배 수준
    • 향후 자체 전력 생산 계획 언급

  • 냉각

    • 외기 냉각 방식 사용, CRAC 시스템보다 전력 효율적
      • 48인치 흡기·배기 팬 각 2개로 공기 순환
      • PID 제어 루프로 온도·습도 자동 조절 (<45% 유지)
      • 전력 사용량은 수십 kW 수준

  • 서버 및 스토리지

    • TinyBox Pro 75대(총 600 GPU)로 구성, 자체 제작
      • 각 장비는 2 CPU + 8 GPU, 학습 및 일반 연산용으로 사용
      • 자체 제작으로 유지보수 용이
    • 스토리지는 Dell R630/R730 기반, 총 4PB SSD
      • 비중복(non-redundant) 구조, 노드당 20Gbps 읽기 속도
    • 네트워크는 100Gbps Z9264F 스위치 3대, Infiniband 스위치 2대로 구성

소프트웨어 인프라

  • 기본 설정

    • 모든 서버는 Ubuntu + PXE 부팅, Salt로 관리
    • 단일 마스터 구조로 99% 가동률 유지

  • 분산 스토리지 — minikeyvalue (mkv)

    • 3PB 비중복 스토리지에 학습용 주행 데이터 저장
      • 1TB/s 읽기 속도, 캐싱 없이 직접 학습 가능
    • 300TB 캐시용 배열, 중복 저장 배열에는 모델 및 메트릭 저장
    • 각 배열은 단일 마스터 서버로 관리

  • 작업 관리 — Slurm

    • PyTorch 학습 작업과 miniray 분산 작업을 스케줄링

  • 분산 학습 — PyTorch + FSDP

    • Infiniband 네트워크로 연결된 두 개의 학습 파티션 운영
    • 자체 학습 프레임워크로 훈련 루프 자동화
    • 모델 실험 추적 서비스 제공

  • 분산 컴퓨트 — miniray

    • 경량 오픈소스 태스크 스케줄러, 유휴 머신에서 Python 코드 실행
      • Dask보다 단순, Redis 중앙 서버로 태스크 관리
      • GPU 워커는 Triton Inference Server로 모델 추론 수행
    • 수백 대 머신 병렬 확장 가능
      • 예: Controls Challenge 기록은 데이터센터 1시간 사용으로 달성

  • 코드 관리 — NFS 기반 모노레포

    • 전체 코드베이스 3GB 이하, 모든 워크스테이션에 복제
    • 작업 시작 시 로컬 코드와 패키지 동기화, 2초 내 완료
    • 모든 분산 작업이 동일 코드·환경에서 실행되도록 보장

통합 학습 파이프라인

  • comma에서 가장 복잡한 작업은 온폴리시(on-policy) 방식으로 주행 모델을 학습시키는 것
  • 이런 학습을 위해서는 최신 모델 가중치를 적용한 시뮬레이션 주행을 실행하여 학습 데이터를 생성해야 함
  • 아래와 같은 단일 명령으로 전체 파이프라인 실행 가능
    • ./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4
  • 위 학습을 실행하는데 위에서 설명한 모든 인프라가 사용됨
  • 이 간단한 명령어 하나뿐이지만, 여러 구성 요소를 조율하는 역할을 함

결론

  • comma.ai는 자체 데이터센터 운영으로 비용 절감과 기술 자립을 달성
  • 동일한 접근을 통해 기업이나 개인도 자체 인프라 구축을 할수 있을 것
▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 우리가 속한 산업에서는 소유 vs 클라우드가 스펙트럼의 양 끝에 있음
    ① 클라우드는 초기 투자(capex)와 인력 부담이 적지만, 운영비용(opex) 이 크고 변동성이 큼
    ② Managed Private Cloud는 우리가 하는 일로, 오픈소스 기반으로 관리해주며 AWS 대비 약 50% 저렴함
    ③ Rented Bare Metal은 하드웨어 자금 조달을 대신해주는 모델로, AWS보다 90% 저렴함
    ④ 직접 구매 후 코로케이션하는 방식은 기술력과 규모가 있다면 가장 저렴함
    Hetzner 같은 업체는 3년 ROI를 기준으로 운영하며, 3~4번 옵션은 규모가 크거나 인프라가 핵심인 기업에 적합함
    스타트업은 1번, 중소기업은 2번이 현실적임 (lithus.eu)

    • 문제는 클라우드의 비용 구조가 단순히 하드웨어 가격 때문이 아니라, 복잡한 아키텍처로 유도되어 비효율이 커지는 데 있음
      AWS의 ‘managed 서비스’들은 사용자가 서버 효율을 높일수록 AWS의 수익이 줄어드는 구조임
      단순히 EC2 위에 Java 서버 4개와 복제 DB를 두는 식이면 훨씬 효율적임
      결국 말도 안 되는 AWS 요금은 수많은 서비스를 남용할 때 발생함

    • (Carolina Cloud의 derek@) 우리도 (4)번 모델을 선호하지만, 기술력이 부족한 사용자들은 1~3번에 머물러 공공 클라우드의 고비용 구조에 갇히게 됨
      ‘사용량 기반’이라지만 실제로는 기본요금과 최소 사용료가 붙어 훨씬 비쌈 (carolinacloud.io)

    • Hetzner는 매력적인 선택지임
      Postgres나 VPN 같은 서비스를 직접 관리해야 하는 게 부담이지만, 월 1~1.5만 달러 이상이면 AWS보다 유리함
      위험은 있지만 감수할 만한 가치가 있음

    • 나는 월 500달러짜리 베어메탈 서버를 빌려 쓰는데, 관리 시간은 1년에 몇 시간뿐임
      내 요구사항이 단순해서일 수도 있지만, 과하게 복잡한 클라우드보다 훨씬 낫다고 느낌

    • 2년 전부터 코로케이션으로 옮겼고, 지금은 30% 비용으로 더 큰 용량을 확보함
      RAM/스토리지의 후행 가격 인하 혜택도 있음
      다만 컴플라이언스 관리는 조금 더 신경 써야 함

  • 예전에는 이런 걸 그냥 데이터센터라고 불렀음
    클라우드 이전에도 있었던 개념이고, 결국 소유 vs 임대, 중앙화 vs 분산화의 반복임
    기업이 극단적으로 한쪽만 선택하면 문제를 다시 맞닥뜨리게 됨

    • 흥미로운 점은, 클라우드가 재무팀에 매력적이었던 이유가 세금 절감 효과였음
      하지만 최근 법안(OBB)으로 CapEx를 비용 처리할 수 있게 되면서 온프렘 회귀에 바람이 불고 있음

    • 그렇다면 왜 가격 경쟁력 있는 클라우드 대안이 안 나오는가?
      AWS와 Azure가 시장을 장악해 가격 인하 유인이 없고, Google은 서비스 종료 리스크가 큼

    • 클라우드 이전에는 내부 인프라팀이 병목이었음
      클라우드는 이를 표준화하고 단일 청구 체계로 단순화했음
      또 미국 외 지역에서는 서버 조달이 느려서 클라우드의 속도 이점이 컸음

    • 온프렘 데이터센터는 운영 부담이 크고, 엔지니어링 리소스를 많이 잡아먹음
      그래서 이 논쟁이 계속 반복됨

    • 클라우드의 진짜 혁신은 “서비스 단위로 비용을 명확히 한 것”임
      예전처럼 “누구한테 부탁해야 하지?” 대신 API로 접근 가능해짐
      관련 맥락은 이 글에 잘 정리되어 있음

  • 샌디에이고처럼 온도 조절이 쉬운 지역이라도 외부 공기 냉각은 위험함
    습기와 오염물질이 서버를 빠르게 망가뜨림
    대신 엔탈피 휠 쿨러(kyotocooling) 같은 방식이 효율적이며, 냉각 효율 대비 전력 소모가 적음
    외기 냉각은 장비 수명 단축 위험이 크므로 주의해야 함

    • 필터링과 습도 45% 이하 유지로 꽤 좋은 결과를 얻은 사례도 있음

    • 이런 걸 신경 써야 한다는 걸 몰랐음
      그래서 나는 그냥 클라우드를 씀 — 이런 ‘모르는 위험’을 피할 수 있음

  • 온프렘과 클라우드를 병행하는 게 현실적임
    핵심 인프라는 신뢰할 수 있는 클라우드에 맡기고, Slurm 작업 등은 자체 서버에서 돌림
    코로케이션도 여전히 유효한 옵션이며, 연구용 HPC도 고려할 만함
    노르웨이에서는 민간 기업도 연구 HPC를 유료로 사용할 수 있음

    • 나는 이탈리아에서 두 지역에 서버팜을 운영했는데, 직원 5명이 관리하며 거의 100% 가동률을 유지했음
      연간 80만 유로로 700~800만 유로의 클라우드 비용을 절감했음

    • 많은 개발자들이 자신이 호스팅을 못한다고 착각함
      실제로는 생각보다 쉽고, 기술적 문제를 해결하는 재미도 있음

    • Equinix나 Global Switch 같은 곳에서 공간을 임대하면, 전력·냉각·케이블 등은 모두 관리해줌
      직접 두 지역에 서버룸을 두는 것도 충분히 가능함

    • 우리는 여전히 Azure를 사용자 서비스용으로 사용함
      GPU가 필요 없는 웹 서비스는 클라우드가 더 효율적임
      GitHub도 여전히 신뢰할 만한 서비스로 사용 중임

    • (농담조로) Slurm 풀에 Postgres 데몬이 꼬여서 Rust가 폭주한 적이 있었음
      결국 안정화했지만, 하드웨어 엔지니어 입장에서는 소프트웨어 세계가 혼란스러움

  • 프로젝트 초기에는 AWS에서 월 250달러로 시작하고, 월 3만 달러 수준이 되면 코로케이션으로 옮김
    핵심은 비용 계산 능력임 — 좋은 엔지니어는 이를 근거로 경영진에 제안할 수 있어야 함

    • 단순 계산을 넘어, 어떤 인재를 끌어들이고 어떤 비즈니스를 만들고 싶은지도 고려해야 함
      ML 모델을 학습하는 회사라면 자체 인프라가 더 적합할 수도 있음

    • 하지만 대부분의 회사에서 엔지니어는 플랫폼 선택에 관여하지 못함
      경영진이 이미 결정하고 통보하는 경우가 99.999999%임

  • 커리어 초반에는 클라우드가 당연한 선택이었는데, 이제는 온프렘이 다시 유행임
    10년 후엔 또 반대 흐름이 올지도 모름

    • 내 경험상 온프렘을 밀던 팀들은 항상 유지보수의 피로감을 과소평가했음
      스타트업처럼 빠른 개발이 필요한 곳에서는 오히려 발목을 잡음
      반면 유지 모드에 들어간 회사에서는 온프렘이 효율적이었음
      나이가 들수록 “빨리, 예산 내에 끝내는 것”이 중요해지고, 인프라 자가 운영의 매력은 줄어듦

    • 이번 흐름은 단순한 기술 주기가 아니라 ‘소유하지 못하는 사회’에 대한 반발로 봄
      음악, 집, 자동차까지 모두 구독 모델이 되면서, 기업도 컴퓨팅 주권을 되찾으려는 움직임이 있음

    • 이런 순환은 늘 있었음
      메인프레임 → PC → 서버룸 → 클라우드 → 엣지 컴퓨팅으로 이어지는 중앙화 ↔ 분산화의 반복임
      결국 기술과 우선순위가 바뀌면 다시 되돌아옴
      “네트워크가 곧 컴퓨터”라는 말이 다시 나오면, 또 한 바퀴 돈 것임

    • (농담) 다음은 아마 스페이스(스카이넷) 단계일지도 모름

  • 대부분의 기업이 온프렘을 피하는 이유는 리스크 관리 때문임
    좋은 기업은 위험을 핵심 경쟁력에 집중시킴
    단순히 비용이 아니라 리스크 조정 비용으로 판단해야 함

    • 하지만 요즘은 기업들이 그 리스크를 정확히 평가할 역량이 있는지도 의문임
      가격 경쟁력도 결국 차별화 요소 중 하나이기 때문임

    • 핵심은 본업에 집중하는 것임
      못 파는 제품을 더 잘 팔게 해주는 게 아니라면, 데이터센터에 시간 낭비하지 말아야 함
      Google처럼 인프라 자체가 제품 경쟁력인 경우만 예외임

    • 결국 Opex가 Capex를 이기는 싸움이 대부분임

  • 온프렘의 진짜 장점은 자유와 통제, 프라이버시임
    단순히 돈 문제가 아니라, 집을 소유하느냐 임대하느냐의 문제와 같음

    • 하지만 원문에서도 비용은 마지막 항목으로 다뤄졌고, 그 외의 장점이 핵심임

  • 2010년대 MBA식 교리는 “모든 걸 클라우드로 옮겨라”였음
    리스크와 비용을 제3자에게 넘기는 게 정답으로 여겨졌음
    하지만 실제로는 우리 데이터센터가 훨씬 저렴했고, 소프트웨어 구독료의 인상률이 하드웨어보다 훨씬 높았음

    • 물론 AWS는 전 세계에 중복 데이터센터를 두고 있어 안정성이 다름
      하지만 그만큼 인건비와 관리비를 고려하면, 단순 비용 비교는 무의미함
      토네이도 한 번에 회사가 날아갈 수도 있으니까, 결국 리스크 대비 가치로 판단해야 함
답변달기