7P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Sam Altman이 ChatGPT가 주간 약 7억 명 사용자를 처리한다고 발표함
  • GPT-4급 모델을 로컬에서 실행하면 VRAM 부족·속도 저하가 심각한데, OpenAI가 어떻게 이런 대규모 사용량을 저지연·고성능으로 처리하는지 궁금함
  • 단순 GPU 클러스터 이상의 모델 최적화·분산 처리·전용 하드웨어·로드밸런싱 기법을 알고 싶음

핵심 댓글들 요약

1. 초대형 분산 추론 구조

  • 모델 샤딩(Model Sharding)
    • 파라미터를 여러 GPU에 분산 저장
    • 요청이 들어오면 각 GPU가 자신의 파라미터 부분에 대해 연산 수행 후 결과를 합침
  • 텐서 병렬성(Tensor Parallelism)
    • 한 레이어 내 연산을 여러 GPU가 병렬로 수행
  • 파이프라인 병렬성(Pipeline Parallelism)
    • 레이어를 여러 단계로 나누어, 파이프라인처럼 순차적·동시 처리
  • 혼합 병렬 처리로 GPU 메모리·연산 부하를 최적화

2. 메모리·속도 최적화

  • 양자화(Quantization): 파라미터를 낮은 비트 정밀도로 변환해 VRAM 사용량 감소
  • 레이어 오프로딩(Offloading): 필요 시 일부 레이어를 CPU 메모리로 이동
  • LoRA / Adapter Layers: 특정 작업만 미세 조정(fine-tuning)하여 전체 모델 재로딩 불필요
  • KV 캐싱(Key-Value Caching): 컨텍스트를 재사용해 반복 계산 제거

3. 전용 하드웨어·네트워킹

  • 최신 NVIDIA H100, A100, 일부 TPU 대규모 사용
  • GPU 간 NVLink·** NVSwitch**, 클러스터 간 Infiniband로 초고속 데이터 전송
  • 데이터센터 간 글로벌 백본 네트워크 구축, 지연시간 최소화

4. 지리적 분산·로드밸런싱

  • 전 세계 여러 리전에 GPU 팜 배치
  • GeoDNS로 사용자 요청을 가장 가까운 리전에 연결
  • 트래픽 패턴에 따라 GPU 클러스터를 동적 확장/축소
  • 특정 리전에 부하 집중 시 글로벌 트래픽 재분배

5. 요청 처리 최적화

  • Batch Inference: 여러 사용자의 요청을 묶어 한 번에 추론
  • 작은 모델 선처리: 간단한 요청은 소형 모델로 처리, 복잡한 요청만 대형 모델 호출
  • 결과 캐싱: 동일 프롬프트·유사 요청 결과를 캐시로 즉시 반환
  • 프롬프트 엔지니어링으로 불필요한 토큰 낭비 방지

6. 운영·비용 최적화

  • GPU 사용률 모니터링·스케줄링으로 유휴 리소스 최소화
  • 데이터센터 전력 효율화·액체 냉각 도입
  • 자체 컴파일러·런타임 최적화로 추론 속도 향상
  • 모델 업데이트·배포 자동화 파이프라인 운영

종합 아키텍처 흐름 예시

  1. 사용자 요청 수신 → GeoDNS로 가까운 리전 라우팅
  2. 프리프로세싱 → 간단 요청은 소형 모델, 복잡 요청만 대형 모델로 전달
  3. 분산 추론 처리
    • 모델 샤딩 + 텐서 병렬 + 파이프라인 병렬 적용
    • GPU 간 고속 네트워크로 중간 결과 교환
  4. 후처리·결과 캐싱 → 동일·유사 요청 대비 캐시 저장
  5. 응답 반환 → 1~2초 내 결과 제공
Hacker News 의견
  • Google에서 이러한 시스템을 직접 다루는 일을 하고 있음(개인 의견임) 똑똑한 사람들이 문제의 모든 측면을 진지하게 고민함을 확실히 말할 수 있음. 더 많은 정보는 말할 수 없지만, 동료들이 작성한 자료를 공유하고 싶음. 가속기 아키텍처 및 높은 속도를 내는 최적화 방법에 대한 훌륭한 설명이 있음 scaling book에서 볼 수 있음. 특히 추론에 대한 내용이 궁금하다면 inference 챕터가 도움됨. 추가로 unsloth 가이드를 추천함. 다양한 모델을 깊게 파고들어 최적화를 찾고, 이를 잘 정리해서 제공함. Gemma 3n 가이드 외에도 여러 가이드들이 있음

    • 좀 더 신비감 없이 설명하자면, 추론은 (대부분) 상태가 없는 작업임. 따라서 훈련처럼 수십 만대의 머신 사이에서의 메모리 일관성이나 머신 장애를 고려하지 않아도 됨. 그냥 소량의 데이터를 아주 큰 머신들에 전달만 잘 하면 됨. 내가 일했던 곳의 연구용 머신들은 8개 GPU가 탑재된 초고성능 머신들이었고, 모델이 (합산) VRAM에만 들어가면 어떤 작업이든 제대로 처리 가능했음. 대규모 확장의 비밀 재료는 '엄청난 양의 자본'이었음. NVIDIA에서 금도금한 DGX 머신을 보내준 적도 있었는데, 이건 밀집도가 높지 않고 매우 비쌌음. 대부분 큰 회사들은 안정적인 RPC와 오케스트레이션 시스템을 갖고 있어서, 진짜 어려운 부분은 메시징 전달이 아니라, 모델을 가진 하드웨어에 맞게 넣는 것임(이게 내 전문 분야는 아님)

    • 현대적인 대형 추론용 랙, 잘 알려진 RDMA 및 저지연 네트워킹 기법, 강력한 MLA 및 캐시 최적화들이 신비로운 기술처럼 묘사될 필요 없음. 이러한 것들은 이미 공개적으로 잘 이해되어 있고, 오히려 유명회사에서 뭔가 아주 커스텀하게 하는 경우는 보통 과거와의 호환 문제 때문에 부담이 될 때도 있음. 진짜 중요한 건 대형 시스템을 돌릴 때 필요한 체계와 프로세스를 잘 갖추는 것임. 여기엔 장비 조달, SRE 트레이닝, 새 TPU에 대한 RTL까지 다양한 영역이 포함됨. 만약 누군가가 10배 앞서나가면 바로 알 수 있을 것임 (10년간 TOP-5에서 대규모 추론 경험이 있는 사람임)

    • "저희는 모든 문제를 정말 진지하게 고민하는 똑똑한 사람들이에요"라는 표현에 대해, 사실 1970년대 메인프레임 스타일의 시분할 시스템을 하고 있음이라고 보면 됨

    • Google은 TPU 덕분에 자체 모델 추론의 수익성이 NVIDIA 카드를 임대하는 것보다 훨씬 높지 않을까 궁금함. OpenAI는 대부분 Microsoft와의 파트너십을 통해 GPU를 확보하는 것으로 알고 있음. 링크와 책 모두 흥미롭게 읽었음

    • "오늘날 '작은' 모델조차 하드웨어 한계에 육박해서 동작한다"는 문구가 인상적이었음. 이 말이 60, 70년대의 "작은 프로그램조차 하드웨어 한계에 맞춰 돌아간다"는 것과 비슷하게 들림. 소프트웨어 엔지니어링에서의 최적화, 효율성이 사라졌다 하더라도, LLM 개발에서는 여전히 살아있음

  • H100 한 대가 2만 달러이며 80GB의 VRAM을 가짐. 2U 랙 서버 한 대에 이런 카드가 10만 달러어치 들어간다고 상상해 볼 수 있음. 이런 장비가 랙 전체에 들어가고, CPU, 램, 쿨링까지 모두 포함하면 한 랙당 백만 달러 수준임(운영비와 유지보수 인력비는 별도임). '저렴한' 장비라 해도 계산 단위가 매우 큼. AI 버블이 꺼지는 시점이 되면 좋은 로컬 모델을 현실적으로 돌릴 수 있을 것이라 기대함. 10년 후엔 이런 10만 달러짜리 서버가 이베이에서 3천 달러에 팔릴 수도 있고, 전기공사 기사들이 차고나 임시 서버실에 240V 전원을 설치해 달라는 요청을 받을지도 모른다고 상상해봄

    • 10년을 기다릴 필요 없이 DGX-1을 이베이에서 1만 달러 이하로 바로 살 수 있음. 256GB VRAM(HBM2), NVLink, 512GB 램, 40코어 CPU, 8TB SSD, 100Gbit HBA를 가짐. 비NVIDIA 브랜드 제품은 6천 달러에도 구매 가능. 단, 매우 무겁고 상상 이상으로 시끄러우며, 한 대가 240V 16A 회로를 거의 다 씀. 동시에 시간당 13,000 BTU의 열도 발생함

    • AI 버블이 안 터지더라도, 해당 서버들이 10년 후 이베이에 풀릴 가능성이 큼. 데이터센터들이 하드웨어를 업그레이드하고 중고를 제3자에게 판매할 것이기 때문임

    • 개인적으로는 공개된 모델들이 우리가 생각하는 것보다 훨씬 적은 연산만을 사용한다고 의심함. 최신 Mixture of Experts 모델에서는 top-k 샘플링, 즉 일부 전문가(파라미터)만 활성화해서 평가하는 구조 덕분에, SOTA 모델이라 해도 non-MoE 70-80B 모델보다 훨씬 많은 연산을 필요로 하지는 않음

    • 기업 단위에서의 AI 서빙에서는 "어떻게 사용자를 서비스할 것인가"가 진짜 질문이 아니라, 투자자들이 언젠간 ROI를 기대한다는 점이 핵심임. 필요한 만큼의 인프라는 투자만 들어오면 얼마든지 지을 수 있음. 최적화가 없다 해도, 필요하면 필요한 만큼의 창고와 랙을 지어서 서비스하면 되는 구조임

    • 미국인이 아니라서 240V 이야기가 웃겼음

  • 당신은 수천 달러가 있다면, 그들은 수백억 달러가 있음. 1,000 vs 10,000,000,000의 규모 차이임. 그들이 가진 효율성 또한 스케일에서 한두 자릿수 정도 더 뛰어남. 또한, MacBook(램 24GB)에서도 GPT-4 출시 초기 성능과 맞먹는 로컬 모델을 돌릴 수 있음. 성능 비교 링크

    • 7억 명의 유저를 하루나 한 주에 걸쳐서 시간 분산하면 실제로는 동시에 1,000만 세션 정도만 활성화될 수도 있음. 개별 사용자는 일주일 간의 컴퓨팅 리소스를 쌓아 두었다 한 번에 쓰는 게 불가능하지만, 서비스 제공자는 수평 확장 구조로 피크만 맞추면 됨. 그래서 같은 성능 요구에도 로컬 환경이 훨씬 더 많은 하드웨어를 필요로 하게 됨
  • 하나의 GPU 노드만으로도 매우 높은 FLOPs와 메모리 대역폭을 제공함. 소수의 요청을 처리할 때는 주로 GPU가 가중치 데이터를 RAM에서 연산 유닛으로 스트리밍하는 것을 기다리는 경우가 많음. 요청을 묶어서 배치로 처리하면 한번에 한 묶음의 가중치를 읽어 여러 요청을 병렬로 처리할 수 있어서 효율성이 극대화됨. 추가로, 모델을 8비트나 더 낮은 포맷으로 압축해서 스트리밍 데이터량을 줄이고, 최신 GPU는 8비트/4비트 연산 지원함. Mixture of Experts 모델은 각 토큰별로 일부 파라미터만 사용해서 더 적은 가중치를 불러와도 됨. speculative decoding 기법은 작은 모델을 이용해서 여러 토큰을 미리 예측한 뒤, 실제 메인 모델이 그 중 일치하는 것만 채택함. 이 모든 최적화가 합쳐져서 뛰어난 효율을 냄 (Databricks 추론팀 디렉터 경험 기반)

  • OpenAI의 비밀 소스 중 하나는 수십억 달러의 손실임. 2024년에 50억 달러를 잃음. 관련 기사

    • 요즘엔 agentic 방식이 등장해서 상황이 많이 바뀜. 예전에는 1 요청당 1 처리였지만, 지금은 한 작업에 대해 수백 번의 처리를 동시에 진행함. 이런 병렬 처리가 가능한 덕분에 OAI/Azure가 로컬 모델 대비 우위임

    • 만약 R&D를 없애고 기존 모델만 서비스한다면 손익분기점은 맞출 수 있을 것 같음

    • 핵심을 잘 짚었음. Microsoft의 최대 100억 달러 투자가 사전학습, R&D, 추론비용을 커버했음에도 여전히 수십억 달러가 손실됨. VC식, 성장지향적 자본주의 구조임

  • 대규모 추론에서는 요청을 묶어서(batch) 한꺼번에 처리하는 것이 개별 사용자의 GPU 할당 방식(개인 환경)보다 훨씬 효율적임. 중간 수준 엔지니어링 트릭을 알고 싶다면 우리 팀이 Fin AI 블로그에 쓴 글을 참고해 볼 수 있음. (OpenAI 등은 아마 여기에 없는 비공개 기법들도 쓸 것 같음) 관련 포스트

    • 이게 진짜 핵심 정답임. 위에서 논의되는 여러 이야기들보다 배칭이야말로 비용을 대폭 낮추는 방법임. 예를 들어 한 요청을 처리하는 데 5만 달러가 든다면, 배칭 덕분에 5만 달러로 100개의 요청을 동시에 거의 손실 없이 처리할 수 있음. 실제로 몇 명의 유저까지 한 하드웨어로 처리 가능한지는 모르지만, 수백 명 수준일 것으로 생각함. 효과적으로 비용을 5만 달러에서 500달러까지 낮출 수 있다는 의미임(충분한 사용자가 있을 때). LLM 처리의 병목은 대부분 가중치를 GPU에 올리는 시간이기 때문에, 각 요청을 따로따로 처리하는 대신 여러 요청의 연산을 같이 처리함으로써 효율을 극대화함. 예를 들어, 3개의 가중치 집합(A, B, C)이 GPU 캐시에 들어간다고 하고, 2개의 요청(1,2)이 있을 때, 일반적 접근은 각 요청마다 가중치를 불러와서 쓰는 것이지만, 배칭 접근은 한 번 가중치를 불러와서 여러 요청을 연산함. 가중치 불러오기 시간과 계산 시간을 비교하면, 배칭 전후로 속도의 차이가 극명하게 드러남. 현실에선 가중치 적재가 연산보다 훨씬 느리기 때문에 사용자가 많아질수록 차이가 커짐. 실제로는 더 많은 사용자를 처리하기 위해 활성화 상태 메모리도 필요하니, GPU 클러스터당 몇 명까지 할지 균형을 맞춰야 함. 결론적으로, LLM 서빙용 하드웨어는 매우 비싸지만, 이미 보유하고 있다면 수백 명의 유저를 동시에 거의 성능 저하 없이 서비스 가능함
  • 주당 7억 명의 사용자가 있다고 해서, 실제 로드가 얼마나 되는지는 별로 말해주지 않음. 대부분의 ChatGPT 사용자도 하루에 한 시간씩 일주일 내내 쓴다 해도 96%는 놀고 있음. 많은 이들이 덜 복잡한 모델만 사용함. 굳이 '주간 사용자'를 언급한다는 것은, 일일 활성 사용자 중에도 소수만이 하루에 한 번도 안 쓴다는 것을 의미함. 핵심 과제는 1) 모델이 메모리에 들어가고 충분한 속도로 토큰을 처리할 수 있는 서버를 만드는 것, 2) 피크 합산 토큰 처리량에 맞는 서버를 충분히 확보하는 것, 3) 효율적으로 모든 요청을 서버에 분산트래핑하는 것임. 상세한 부분도 있지만, 사실 마지막 과제는 검색엔진 돌리는 것과도 유사하게 느껴짐. 모든 상태는 채팅 대화 내역에 있으니, 굳이 같은 채팅을 같은 서버가 처리할 필요 없음. "Thinking..." 메시지가 보일 때 정말 모델이 연산 중인지, 아니면 대기열에서 서버를 기다리는 중인지는 노출되지 않음

  • LLM이 대규모로 잘 돌아가는 가장 큰 비결 중 하나는 '배치 크기'임. 요즘 LLM은 대부분 "Mixture of Experts" 구조를 활용해서, 전체 파라미터 중 일부만 순간적으로 활성화함. 덕분에 대규모 배치 처리가 훨씬 효율적임. 만약 GPT-4를 집에서 돌린다면, 모델 전체를 VRAM에 넣을 수 있어야 하기 때문에 H100 같은 GPU 여러 장이 필요함(한 장에 약 4만 달러). 하지만 개인 사용량으론 이런 카드를 제대로 활용 못함. 마치 “왜 Apple은 수십억명에게 아이폰을 만들 수 있는데, 나는 차고에서 하나도 만들 수 없지?”라고 묻는 상황과 비슷함

    • 요약하면, 추론 부하는 많은 사용자에게 잘 분배돼서 효율적으로 돌아감

    • 그렇다면 사용 빈도가 낮은 파츠는 메인메모리에, 자주 쓰는 파츠는 VRAM에 올려두는 구조가 가능한지도 궁금함

    • 비유가 매우 적절함

  • 집에서도 구현할 수 있고 Cerebras의 성능에서 중요한 역할을 하는 트릭 하나가 speculative decoding임. 이 방식은 훨씬 작은 초안 모델로 토큰을 훨씬 적은 연산과 메모리로 예측하고, 메인 모델이 그 토큰들 중 실제 자신이 뽑았을 법한 것을 채택함. 잘 갖춰진 구조에서는 3배까지의 속도 향상이 가능함. 또 structured output의 경우, 예측 가능한 토큰을 건너뛰는 "fast forwarding"을 적용해 JSON 등에서 시작 형식을 미리 채운 뒤, 최대 3배까지 속도를 올릴 수 있음

    • LM Studio에서 gpt-oss-120b와 gpt-oss-20b를 조합해 speculative drafting을 해볼 수 있음. 다만 체감 성능이 그리 오르지 않은 듯함
  • LLM 추론의 핵심은 행렬-벡터 곱셈임. 여러 쿼리를 동시에 처리해야 할 때는 각 쿼리의 벡터를 모아 행렬-matrix로 만든 뒤 행렬-행렬 곱셈을 통해 동시에 계산할 수 있음. 하드웨어 입장에서는 행렬-벡터 곱을 여러 번 반복하는 시간을 들이느니, 한 번의 행렬-행렬 곱이 훨씬 효율적임. 이게 바로 배치 처리임. 두 번째 트릭은 speculative decoding임. 추론에는 프롬프트 처리와 토큰 생성의 두 단계가 있고, 둘 다 실제론 'forward pass'라는 동일 구조임. 프롬프트 처리는 행렬-행렬 곱으로 병렬 처리할 수 있고, 그 중 마지막 결과만 토큰 생성 시작에 사용함. 그런데 미래의 토큰을 미리 알 수 없으니 보통은 병렬화가 안 됨. 그래서 빠른 초안 모델로 앞으로 N개의 토큰을 예측하고 이를 입력 프롬프트에 넣은 뒤 메인 모델로 병렬 forward pass를 돌림. 생성된 N개 토큰 중 일치하는 첫 번째 토큰까지 모두 유효 토큰으로 바로 뽑아낼 수 있음. 이론상 2~4배까지 추론 속도 향상을 기대할 수 있음. 나는 이를 직접 업무로 구현하지는 않았지만, 추가적으로는 쿼리 길이 별로 병렬 그룹핑이나 실시간 로드밸런싱 등도 적용할 것이라 추측함(모든 요청이 꼭 같은 길이일 수는 없으니, 자원 불균형을 막기 위해 필요함)