GPT-OSS-120B를 NVIDIA GPU에서 초당 500 토큰 속도로 실행하는 법

• OpenAI의 오픈소스 LLM인 GPT-OSS-120B를 NVIDIA GPU 환경에서 초당 500개 이상 토큰 처리 성능으로 최적화함
• TensorRT-LLM, vLLM, SGLang 등 다양한 추론 프레임워크를 병렬 테스트하며 Hopper와 Blackwell 아키텍처 모두 지원
• 호환성 버그를 수정하고 Harmony 같은 신규 응답 포맷 통합, KV 캐시 인지 라우팅 및 Eagle 기반 추측 디코딩 등 최적화 적용
• 텐서 병렬화와 전문가 병렬화를 비교한 결과, 낮은 지연 시간을 위해 텐서 병렬화 채택 및 Blackwell에서 TensorRT-LLM MoE 백엔드 사용
• 향후 성능 향상을 위해 소형 드래프트 모델을 사용하는 추측(Speculative) 디코딩을 포함해 추가 최적화할 계획

---

개요

• OpenAI의 최신 오픈소스 대형 언어 모델인 GPT-OSS-120B가 공개됨과 동시에 Baseten은 최고 성능 구현에 도전함
  • Baseten은 OpenAI의 공식 런치 파트너임
• OpenRouter에서 공개된 실 사용자 데이터를 통해 NVIDIA GPU 기반 환경에서 타사 대비 앞선 성능을 입증
• Flexible inference stack과 모델 엔지니어팀의 전문성으로, 시간 단위로 최적화 패치를 신속하게 적용함
• 블로그 작성 몇 시간 동안만에도 초당 100토큰 추가 증가 및 100% 가동시간을 유지했음

성능 최적화 노력

• TensorRT-LLM, vLLM, SGLang과 같은 다양한 추론 프레임워크에서 테스트 및 벤치마킹을 수행
• Hopper, Blackwell GPU 아키텍처와의 호환성 확보를 병행
• Baseten의 Flexible Inference Stack 및 NVIDIA Dynamo 등 주요 컴포넌트와 통합
• KV cache-aware routing과 Speculative decoding(Eagle 기반) 등 꾸준히 검증된 성능 최적화 기법을 적용

아래에는 SOTA 성능과 전체 컨텍스트 윈도우 지원을 동시에 실현하기 위한 핵심 단계

Step 1: 최초 추론 실행

• 어떤 방식이라도 최초 추론(baseline inference) 을 빠르게 실행하는 것이 출발점
• GPU에서 영감을 받아 여러 엔지니어가 동시에 vLLM, SGLang, TensorRT-LLM의 실험을 병행
• 가장 우수한 성능을 보이는 TensorRT-LLM을 빠르게 구동에 성공
• Hopper(가장 많은 H100 GPU)와 Blackwell(B200 GPU로 속도가 뛰어남) 모두에서 TensorRT-LLM 지원을 확보
• Baseten Inference Runtime의 유연성 덕분에 새 아키텍처 모델 대응과 스택 내 툴 신속 교체가 용이했음

Step 2: 호환성 버그 수정

• 새로운 모델 아키텍처 등장에는 프레임워크 통합 시 잦은 버그가 동반
• GPT OSS에는 새로운 Harmony 응답 포맷 등 신기술이 추가되어 기존 프레임워크와의 통합 시 버그 발생
• 속도와 정확성을 동시에 확보하기 위해 반복적인 수정·테스트 수행하고, 효과적인 수정 사항은 오픈소스에 기여했음
• 글로벌 오픈소스 커뮤니티의 협업으로, 다양한 최적화 경로나 버그 수정이 빠르게 이뤄지고 있음

Step 3: 모델 구성 최적화

• OpenAI는 GPT OSS 120B가 단일 H100에서도 동작한다고 명시하지만, 실질적으로 4~8개의 GPU 병렬화가 성능에 유리함
• Tensor Parallelism은 지연 시간(latency)에, Expert Parallelism은 시스템 처리량(throughput)에 강점을 보임
  • Baseten은 지연 시간 최적화가 목표라 Tensor Parallelism을 선택함
• Blackwell에서는 TensorRT-LLM MoE Backend를 적용해 이전 Triton 백엔드 대비 CUDA 커널 성능 향상
• Hopper 및 Blackwell 환경 각각에 최적화된 설정을 공개했고, Model API에서는 Blackwell 기반 세팅을 채택함

추가적인 성능 최적화

• 1차 최적화만으로도 SOTA 수준의 처리량과 지연 시간을 실현했지만, 더 개선할 여지가 충분함
• 주요 업데이트 예정 사항은 Speculative Decoding 도입
  • 이 방식은 더 빠른 작은 “draft” 모델이 예측 토큰을 생성, 본 모델이 검증
  • Baseten은 Eagle 3을 권장하지만, 추론 스택 내 10개 이상의 알고리듬을 상황에 따라 유동적으로 운용함
• Speculative decoding은 한 번에 여러 토큰의 추론을 진행해 효율적인 속도 향상을 지원

[jjw951215]

나도 작고 귀여운 H100하나만 누가 줬으면..

[GN⁺]

Hacker News 의견

• widely-available H100 GPUs

  라고 해서 집에 부품 서랍을 뒤져봤는데 아무리 찾아봐도 2만5천 달러짜리 H100 GPU가 왜 없을까?

  • NVIDIA 제품 페이지에 실제로 H100이 GPU로 분류되어 있는 걸 직접 확인했음. 이제는 ‘게이밍 위주로 쓰이지만 LLM 추론도 아주 제한적으로 가능한 소비자 등급 하드웨어’와 ‘AI 훈련이나 LLM 추론이 주 목적이자 비즈니스용 전문가 하드웨어’를 더 쉽게 구분할 수 있는 명칭이 필요하다고 생각함
  • Ollama로 20B 모델을 8개의 TitanX 카드(2015년산)에서 돌려봤음. Ollama가 전체 15GB VRAM을 8개의 카드에 골고루 분산시켜줬고, 토큰 속도도 읽기 속도보다 빨랐음
  • 이런 GPU들은 임대는 정말로 쉽게 할 수 있음. 오랫동안 24/7로 GPU를 돌릴 게 아니라면 직접 사는 것보다 호스팅을 임대하는 게 훨씬 경제적임. 개인 용도로 최신 데이터센터급 카드를 쓸 일도 잘 없고, 그럴 땐 Mac Studio나 Strix Halo 같은 걸로 충분하지만 속도는 다소 느림
  • 이 댓글 덕분에 오늘 하루가 즐거워졌음. 확실히 데이터센터 관점에서 얘기한 거고, 내 서랍에 있는 가장 빠른 하드웨어는 아마 예전 아이폰8임
  • ‘집에 $25,000 GPU가 없다’는 건 실제로 그런 걸 구입할 수는 있단 뜻임. 즉, 재고가 있고 ‘구할 수 있다’는 말일 뿐, 꼭 그걸 살 수 있을 정도로 돈이 있다는 의미는 아니라는 점임

• MacBook Pro(M4, 128GB RAM)로 대서양 횡단 비행기 안에서 GPT-OSS-120B를 써봤음
  컨텍스트 윈도우가 작고 전체 토큰 수가 적을 때만 빠름. 1만 토큰 넘어가면 거의 모든 처리가 오래 걸리고 큐에 쌓여버림
  MCPs, 웹 검색, URL 패치 같은 게 이미 LLM 사용 경험에 매우 중요해졌음. 이 기능들이 없으면 LLM 유틸리티도 크게 감소함
  오프라인 환경용으로 미리 세팅했던 CLI/TUI 코딩 툴(opencode 등)이 모델과 함께 신뢰성 있게 동작하지 않았음
  OSS 모델의 다른 특이점들도 이전 댓글에서 많이 언급된 것 외에도 이런 점이 있음

  • 예전 위키피디아도 로컬로 저장해서 쓸 수 있었으니, 곧 많은 데이터를 MCP로 노출시키고 AI들이 ‘웹 검색’처럼 로컬로 검색하게 될 거라 생각함. 웹 검색의 99%는 똑같은 100~1000개 사이트에서만 일어남. 종합하면 몇 GB만 저장해도 커버 가능하니 저작권 문제가 남음
  • Ollama, LMStudio, llama.cpp 중에 뭘 쓰는지 궁금함 ggerganov 트윗
  • iogpu.wired_limit_mb 세팅을 어떻게 했는지 궁금함. 기본값이면 RAM의 약 70%, 즉 90GB 정도만 GPU 코어가 쓸 수 있음. 더 활용하려면 세팅을 바꿔야 함
  • M2 Max 프로세서로 했음. 짧은 대화는 초당 60개 이상 토큰을 봤지만, 길어지면 30까지 떨어졌음. 이 속도 저하의 원인이 뭘까 궁금함. 열처리 이슈는 아니었던 것 같음
  • 컴퓨트 바운드 프리필(CPU의 대역폭/연산비율이 높을 때)과 디코드 차이라고 생각함. 1만 컨텍스트여도 첫 토큰까지는 0.5초가 안 걸림

• 여러 엔지니어가 병렬로 vLLM, SGLang, TensorRT-LLM을 시도함. TensorRT-LLM이 가장 빠르다고들 하지만 보통 세팅하기도 가장 어렵고, 최신 아키텍처 반영도 잘 안 되고, 프로덕션 환경과 똑같은 하드웨어-드라이버-라이브러리 스택에서 모델을 직접 컴파일해야 해서 정말 번거로움. 멀티모달은 한동안 거의 불가능할 정도였고, 대표적인 라마 멀티모달 모델조차 제대로 동작이 안 됐음. 가치가 있는지 의문이고, 예를 들어 GPT-OSS-120B를 H100에서 vLLM으로 돌리면 문제없이 돌아가고 토큰 착실하게 130~140t/s 뽑아줌. 제목만 보면 GPU 하나에 500t/s가 나올 줄 알았는데 실상은 텐서 병렬 세팅임. gpt-oss를 위해 TRT-LLM 따로 패키징한 것도 조금 우스움. TRT-LLM 자체가 좀 혼란스러운 툴임

  • TRT-LLM을 경험해보면 DX 측면으로 도전과제가 많음. 멀티모달 할 때는 여전히 vLLM을 많이 씀. 그래도 우리가 서비스하는 트래픽처럼 대용량, 저지연 환경에서는 벤치마크에서 TRT-LLM이 항상 우수해서 이쪽 툴링에 많이 투자했음

• GPT-OSS 20B는 설치가 정말 쉬움. Llama 덕에 내 Mac에서 5분 만에 돌릴 수 있었음

  • CPU 자원이 충분하면 120B도 어렵지 않게 돌릴 수 있음. 집에서 LLM CPU 추론 서버에 GGUF 파일만 다운로드하고, git pull해서 llama-server만 다시 빌드해주면 바로 됐고, 40t/s는 수정 없이, 50t/s는 약간만 튜닝해도 얻었음. 아쉽게도 120B도 이미 더 좋은 모델들이 많이 나와서 굳이 돌릴 필요는 없음. ggerganov와 llama.cpp 팀이 개인 컴퓨팅 환경에서도 LLM을 쓸 수 있게 민주화한 점은 정말 대단함
  • LLM 세팅이 어렵다고들 하는데, LLM한테 세팅을 시키면 되는 거 아님? 이런 간단한 일도 못할 정도면 LLM이 무슨 의미가 있지?라는 생각임
  • 어제 돌려봤는데 모든 세션에서 사실관계가 틀린 정보가 계속 나왔음. 속도, 편리함도 좋지만 정확성 희생하면 의미없음
  • 메모리가 충분하다면 120B도 정말 쉽게 돌아감

• 읽으면서 알게 되었는데, 모델을 잘 동작하게 하려면 엄청난 전처리와 튜닝 작업이 필요하단 걸 몰랐음. 그저 기본설정 그대로 잘 되는 줄 알았음

  • 내 생각엔 대기업들은 LLM 출시 전에 인기 있는 추론 엔진 개발자들과 적극적으로 협력해서 자기네 LLM도 지원되게 했으면 좋겠음. 아직 모든 게 실험적이라 그렇겠지만, 개발자들이 저가형 하드웨어에서도 LLM을 얹어 쓸 수 있도록 정말 큰 노력을 해주고 있음

• 미국 AI Action Plan에서 “오픈소스와 오픈 가중치 AI 장려”가 “프론티어 AI가 자유 표현과 미국의 가치를 지키기” 바로 다음에 나오더라. 합리적이지는 않지만 OpenAI OSS 모델을 이 시점에서 읽는 게 약간 소름 돋게 느껴짐. 그래도 OSS 모델 개발사가 하드웨어 이야기를 해주는 건 좋음. 대다수 개발자에게 하드웨어가 진입장벽이니까 이쪽 이야기를 해줘서 반가움

  • “프론티어 AI가 자유와 미국적 가치를 보호하게 하자”는 항목도 언급되었는데, 아직 내 생각을 정리하는 단계라 조금 양해를 바람. AI 모델은 세계관이 담기기 마련이고, 난 차라리 서구적 세계관을 선호함. 이게 더 나은 사회를 만들어준 전례도 많음. 적어도 모델은 자기 세계관을 문서화하고 그에 맞춰져 있어서, 사용자에게 몰래 사회공학적으로 사고방식을 바꾸도록 유도하지 않았으면 좋겠음

• 혹시 OS별, GPU별로 어떤 LLM 모델이 잘 돌아가는지 명확하게 알려주는 사이트 알고 있는지 궁금함. VRAM 산정은 파라미터 수 × (Precision/8) × 1.2가 가장 신뢰가는 경험적 공식이었음 (참고)

  • 비슷한 계산기를 만들어보려 했는데, 실제론 변수(트래픽 동접 등)가 너무 많음. 그 공식도 대략 맞긴 한데 동시 트래픽이 많으면 2배로 계산하는 게 안전함
  • huggingface에 하드웨어/소프트웨어 스펙을 입력하면, 각 모델 상세페이지에서 해당 모델 사용 가능 여부를 보여주는 기능이 있음 huggingface 설정
  • 나는 인터넷 속도도 좋아서, 모델 무게파일을 다운받아서 직접 여러 러너(llama.cpp, LM Studio, vLLM, SGLang 등)로 돌려보는 게 제일 빠르더라. 러너/구현/하드웨어 등 변수가 너무 많아서 어떤 계산기도 실제 경험과 딱 들어맞은 적이 없었음. 방법은 실제로 돌려보는 수밖에 없음
  • 여러분 의견에 감사함. 산출이 어렵다면, 각자 러너, 하드웨어, 모델, 파라미터, 양자화, 작동여부, tokens/s 같은 지표까지 커뮤니티가 실험해서 공유하는 DB 사이트를 만들면 어떨까 생각함. 하드웨어/러너 조합별로 걸러서 바로 쓸 수 있으면 정말 실용적임

• GPT-OSS-120B 모델의 실제 배열 크기 같은 정확한 수치 찾기가 의외로 어렵다는 걸 말하고 싶음. 정적 타입 언어였다면 배열 크기를 대충 눈에 보며 알 수 있는데, 실제 데이터(가중치 말고)가 어떻게 흐르고 출력 스트림이 얼마만큼 넓은지 파악하고 싶음. 기가비트 이더넷에서 ‘토큰 출력’ 대역폭이 최대 몇 t/s인지가 궁금해서, Github 레포지토리 gpt-oss를 찾고 있는데 잘 안 보임

  • 연속되는 토큰 모두에 대해 로짓을 스트림 처리(토큰 샘플링도 규약에 맞춰 하면서)하려는 어플리케이션이 어떤 사례인지 궁금함. 또 보통 문법 같은 걸 맞추기 위해 샘플링 전에 로짓 가공과 토큰 반환을 해야 다음 추론에 들어갈 수 있음을 감안해야 함
  • huggingface 모델 설정 보면 값이 2880개 있음 (dtype 곱하기)

• GPT-OSS는 fp4 지원으로 Blackwell 칩에서 더 빠르게 돌아감. Rust로 훈련/추론 엔진 만드는 중인데 cudarc와 candle에 fp8, fp4 지원을 추가하고 있음. cudarc PR, candle PR, Mixlayer 엔진에 이 모델들을 지원하려고 이 작업을 진행 중임

  • RTX Pro 6000 유저인데 gpt-oss-120b 추론이 지금 가능할지 궁금함. PR들은 이미 머지되어 있는 것 같은데 실제로 돌릴 수 있을지 여부가 궁금함