단일 H100에서 OSS LLM을 더 스마트하고, 저렴하고, 빠르게 실행하기

세션 노트

P5.4xlarge 인스턴스 소개:

• AWS는 단일 NVIDIA H100 GPU에서 강력한 오픈 소스 LLM(Qwen-32B, Mistral, LLaMA 2 등)을 호스팅할 수 있는 P5.4xlarge를 선보인다.
• 크고 비싼 멀티 GPU 클러스터를 과도하게 프로비저닝해야 했던 기존의 필요를 해소한다. 대상 청중:
• 높은 비용이나 성능 저하 없이 OSS LLM을 호스팅하려는 엔지니어, 스타트업, 개인 실험가.
• 대규모 클러스터로 스케일 업하기보다 스마트하게 확장하려는 팀. 주요 이점:
• 비용 효율성: 복잡한 멀티 GPU 클러스터를 과도하게 프로비저닝하고 관리할 필요를 줄인다.
• 성능: 단일 H100 GPU로 메모리나 컴퓨팅 성능을 타협 없이 제공한다.
• 접근성: 더 많은 빌더가 강력한 GenAI 기능을 사용할 수 있게 한다. 세션 주요 내용:
• P5.4xlarge에서 OSS 모델의 실제 벤치마크 탐색.
• 에이전틱 GenAI 워크플로와 비용 절감 전략에 대한 논의.
• Hugging Face transformers 같은 모델과 저지연 챗봇을 위한 실용적인 배포 팁. 실질적인 성과:
• 단일 H100에서 어떤 OSS 모델이 효율적으로 실행되는지 이해.
• P5.4xlarge의 예상 성능.
• 과도한 프로비저닝 없이 구체적인 요구에 맞는 인프라를 설계하는 전략. 결론:
• “우리 대부분은 유용한 챗봇이나 GenAI 앱을 출시하는 데 8-GPU 괴물이 필요하지 않지만, 결국 그 비용을 지불하고 있다.”
• 소규모 팀과 개인 엔지니어가 AWS P5.4xlarge를 사용해 OSS LLM을 효과적이고 비용 효율적으로 배포할 수 있도록 한다. – 필요성 소개:
• “H100 하나를 사용하기 위해 8개 GPU의 비용을 지불하고 관리하는 대신, 마침내 워크로드에 맞는 인스턴스 크기를 선택할 수 있다고 상상해 보라.”
• 문제:
• 대규모 GPU 클러스터를 과도하게 프로비저닝할 때 발생하는 비효율과 비용. 획기적인 변화 발표:
• 새로운 제품:
• “AWS는 최근 새로운 단일 GPU P5 인스턴스 크기를 출시했다. p5.4xlarge는 최신 NVIDIA H100을 제공하므로 더 이상 과도하게 구매하거나 낭비할 필요가 없다.”
• 해결책:
• 불필요한 비용과 복잡성을 없애는 점을 강조한다. 사양과 단순성 강조:
• 인스턴스 사양:
• “p5.4xlarge에는 필요한 모든 것이 담겨 있다. 1×H100 GPU, 16 vCPUs, 256 GiB RAM, 약 4 TB NVMe SSD, 100 Gbps 네트워크.”
• 이점:
• “간단한 배포와 더 저렴한 비용으로 플래그십 GPU의 모든 성능을 누릴 수 있다.” 가격 차이를 실감 나게 제시:
• 비용 비교:
• “일부 리전에서는 시간당 약 $3.90에 이를 대여할 수 있으며, 더 큰 P5에서 8개 GPU 전체의 비용을 내는 것과 대조된다.”
• 영향:
• “이는 소규모 팀의 실험, 데모, 심지어 프로덕션 진입 장벽까지 크게 낮춘다.” 이전과 이후:
• 이전 상황:
• “이전에는 H100이 ‘엔터프라이즈 규모’와 막대한 초기 비용을 의미했다.”
• 현재 상황:
• “이제 클릭 한 번으로 전문가급 역량을 확보할 수 있으며, 단일 테넌트 API, 에이전틱 RAG, 내부 도구, 빠르게 움직이는 스타트업에 이상적이다.”
• 변화:
• 고성능 GPU 기능을 쉽게 접근하고 감당할 수 있게 하는 데 중점을 둔다. 청중이 기억하기를 바라는 점:
• 접근성:
• “p5.4xlarge는 ‘일반적인’ 사용 사례에서도 NVIDIA H100 성능을 활용할 수 있게 하며, 대규모 클러스터가 필요 없다.”
• 효율성:
• “더 단순하고, 더 저렴하며, 대부분의 오픈 소스 LLM 서빙과 실험에 꼭 맞는 크기다.”
• 최적의 해결책:
• “GenAI를 위한 최고의 GPU를 원한다면 이제 하나만 사용할 수 있으며, 클러스터는 필요 없다.” – 단일 H100에는 실제로 무엇이 들어가는가? 일반 채팅과 강력한 추론을 위한 Qwen3‑32B:
• “Qwen3‑32B는 최대 32k 토큰 컨텍스트를 지원하는 32.8B 파라미터의 밀집 모델이므로 실제 문서 채팅, 코딩, 심지어 에이전틱 사용 사례에서도 매우 잘 작동한다.”
• 성능:
• “단일 H100에서 ~1,500 tokens/sec로 여유롭게 실행되며, 여유 용량을 남긴 채 여러 동시 채팅을 처리한다.” 효율성을 위한 Mistral/Mixtral:
• “Mistral 7B와 Mixtral‑7x8B는 추론에 최적화되어 있으며, 토큰당 활성화하는 파라미터가 훨씬 적은데도 일부 벤치마크에서는 70B 밀집 모델보다 뛰어난 성능을 보인다.”
• 성능:
• “H1100의 TensorRT‑LLM은 A100의 약 3배 처리량을 제공한다. 즉, 훨씬 적은 하드웨어로 70B에 가까운 성능을 얻을 수 있다.” Llama 2‑13B / 70B: 관점과 단일 GPU로 충분하지 않은 경우:
• “Llama 2‑13B는 단일 H100에서 매우 빠르게 실행된다(5,000+ tokens/sec). 70B도 실행할 수 있지만 진정한 대규모 운영에는 때때로 여러 GPU가 필요하다.”
• 사용 사례:
• “대부분의 채팅과 RAG 제품에서는 13–32B가 들어가고 빠르게 실행된다. 70B는 최고 품질이나 가장 큰 모델이 필요할 때만 필수다.”
• “≤32B 밀집 모델(또는 활성 파라미터 13B의 MoE)이 필요하다면 실시간 챗봇과 GenAI API에 H100 하나면 충분하다.” – 가치의 틀 제시:
• “분산 인프라나 클러스터 문제 없이 단일 H100에서 훌륭하게 작동하는 세 가지 일반적인 GenAI 아키텍처를 살펴보자.” 패턴 1 – 저지연 채팅/추론 API:
• “서버 하나만으로 실제 챗봇과 추론 API를 제공할 수 있다. Hugging Face Transformers로 모델을 로드하고, vLLM 또는 TensorRT‑LLM으로 서빙하며, 간단한 API 게이트웨이를 앞단에 둔다.”
• 이점:
• “H100의 강력한 성능은 더 높은 동시성과 더 낮은 코드 복잡성을 의미하며, 샤딩이나 병렬 처리 기법이 필요 없다.” 패턴 2 – 검색 증강 생성(RAG):
• “RAG에서는 벡터 DB와 문서를 GPU 밖에 두고, H100이 무거운 LLM 생성 작업을 맡게 한다.”
• 이점:
• “이렇게 하면 비용은 낮추고 성능은 높일 수 있다. 최신 MoE 모델은 스마트한 양자화를 사용하면 H100 하나에도 들어가며, 특별한 하드웨어 편법이 필요 없다.” 패턴 3 – 에이전틱 워크플로:
• “작업을 연결하고 에이전트를 만들고 싶은가? H100 하나에서 32B 플래너 모델을 실행하고, 이 모델이 도구를 호출한다(HTTP, Lambda, 컨테이너 등 사용).”
• 이점:
• “GPU는 ‘생각’하는 동안에만 사용되므로 인스턴스당 여러 에이전트 흐름과 사용자를 동시에 지원할 수 있다.” 요약:
• H100 인스턴스 하나만 사용해 채팅, API, RAG, 에이전트 등 대부분의 GenAI 제품을 구축한다.” – 비교의 틀 제시:
• “지금까지의 모든 내용을 간단한 결정으로 바꿔 보자. 언제 H100 하나가 적합하고, 언제 클러스터가 정말 필요한가?” 효율성:
• “연구에 따르면 멀티 GPU 클러스터가 완벽한 선형 확장을 제공하는 경우는 드물다. GPU 8개를 사용해도 예상 속도의 75–85%만 얻는 경우가 많으며, 특히 실시간 추론에서는 GPU 간 통신이 속도를 늦춘다.” 비용 및 민첩성의 이점:
• “p5.4xlarge의 요금이 약 $3.90/hr이므로 소규모 팀은 몇 달러로 프로덕션급 GenAI를 실행할 수 있고, 거대한 클러스터를 약정할 필요가 없다.” 단일 H100 사용 사례:
• “모델이 13–32B이거나 활성 파라미터가 ~13B인 MoE라면, 단일 H100으로 개발, 내부 도구, 초기 프로덕션, 중간 수준 트래픽을 모두 클러스터 문제 없이 처리할 수 있다.” 멀티 GPU 사용 사례:
• “진정한 70B+ 규모가 필요하거나 막대한 트래픽을 지원해야 할 때만 멀티 GPU를 선택하라.” 향후 참고 사항:
• “단일 H100의 한계를 넘어서게 된다면 더 높은 처리량의 H200이 곧 등장할 것이다.”
• “하지만 오늘날 거의 모든 사람에게 H100이 최적의 선택이다.” – 핵심 요점 요약:
• “대부분의 오픈 소스 LLM 워크로드에는 거대한 클러스터가 필요하지 않고, 요구에 맞게 튜닝한 단일 H100 p5.4xlarge면 된다.” 적합한 모델:
• “Qwen3‑32B, Mistral, Llama2‑13B, Mixtral 등 적합한 모델을 살펴보았으며, 모두 단일 H100에서 원활하게 실행된다.” 최신 아키텍처:
• “채팅 API, RAG, 에이전틱 워크플로라는 세 가지 최신 아키텍처를 살펴보았으며, 각각 H100 하나로 단순화하고 확장할 수 있다.” 비용 및 복잡성 절감:
• “또한 비용과 복잡성을 줄이고, 초고도 동시성이나 가장 큰 모델이 필요할 때만 클러스터로 전환한다.”

26

Adit Modi

단일 H100에서 OSS LLM을 더 스마트하고, 저렴하고, 빠르게 실행하기

이 세션이 필요한 이유와 대상

• GenAI를 실행하는 데 정말 GPU 8개가 필요한가?
• LLM 인프라에 과도한 비용을 지불하고 과도하게 설계하는 일을 멈춰라. 이 세션의 대상은 누구인가?
• 거대한 멀티 GPU 클러스터를 과도하게 프로비저닝하고 관리하는 데 지친 소규모 팀, 스타트업, 개인 엔지니어.
• 전업 클러스터 관리자가 되지 않고 자신이 원하는 방식으로 오픈 소스 LLM을 실행하려는 빌더.
• 막대한 비용 없이 챗봇, API, RAG에서 대형 모델 성능을 얻는 방법이 궁금한 사람. 이 세션의 대상이 아닌 사람은 누구인가?
• Bedrock, SageMaker JumpStart 같은 관리형 호스팅 LLM 플랫폼을 사용하거나 인프라를 제어하지 않는 “서비스형 LLM”을 선호하는 팀.
• 모델을 자체 호스팅할 계획 없이 독점 클라우드 API(예: OpenAl, Anthropic)만으로 구축하는 사람.
• 높은 QPS에서 70B+ 파라미터 모델이 필요하고 대규모 분산 클러스터 사용에 익숙한 사람. OSS LLM의 “과도한 클러스터” 문제 대부분의 GenAI 사용 사례에는 이 정도까지 필요하지 않다! 그렇다면 더 나은 방법이 있을까?
• 팀들은 안전을 기한다는 이유로 오픈 소스 LLM에 거대한 멀티 GPU 클라우드 구성을 기본 선택한다.
• 이는 실제로는 가벼운 워크로드에도 복잡한 분산 추론, 속도 저하, 막대한 비용을 초래한다.
• 실제로 대부분의 최신 제품 사용 사례는 강력한 GPU 하나와 더 작은 7B/13B/32B 모델을 사용할 때 더 빠르고 저렴하게 실행된다.
• 하드웨어 규모를 적절히 조정하면 지연 시간이 줄고, 번거로움이 적어지며, 크게 절약할 수 있다. LLM 실행이 반드시 복잡한 멀티 GPU 클러스터를 의미하지는 않는다.
• 과도한 프로비저닝은 비용과 복잡성을 더하지만 많은 팀의 기본 선택이다.
• 대부분의 최신 OSS 모델과 일반적인 제품 워크로드에서는 성능, 단순성, 비용 절감에 잘 갖춰진 GPU 하나면 충분하다. p5.4xlarge 소개: 실제 워크로드를 위한 단일 H100 좋은 GPU 하나—마침내 손이 닿는 범위에
• Amazon Web Services는 최근 새로운 단일 GPU P5 인스턴스 크기를 출시했다:
• p5.4xlarge는 최신 NVIDIA H100을 제공하므로 더 이상 과도한 구매도, 낭비도 없다 p5.4xlarge: 사양 및 단순성
• p5.4xlarge에는 필요한 모든 것이 담겨 있다:
• 1xH100 GPU, 16 vCPUs, 256 GiB RAM, 약 4 TB NVMe SSD, 100 Gbps 네트워크. 간단한 배포와 더 저렴한 비용으로 플래그십 GPU의 모든 성능을 제공한다.
• 일부 리전에서는 시간당 약 $3.90에 이를 대여할 수 있으며, 더 큰 P5에서 8개 GPU 전체의 비용을 내는 것과 대조된다.

H100 하나에는 무엇이 들어가는가? (Qwen-32B, Mistral, Llama-2 등)

Qwen3-32B — 강력한 추론, 단일 GPU

• Qwen3-32B: 32.8B 밀집 파라미터, 32k 컨텍스트, 강력한 채팅/코딩
• 단일 H100에서 ~1,500–1,800 tokens/sec로 실행
• 에이전틱 챗봇과 API 워크로드에 이상적(요청 배칭 가능) Mistral/Mixtral — 효율적인 성능
• Mistral 7B: H100에서 매우 빠르게 실행되며, TensorRT-LLM 사용 시 A100 대비 처리량 3배
• Mixtral-7x8B (MoE): 70B에 가까운 성능, 훨씬 적은 VRAM 사용
• 비용과 속도 면에서 뛰어난 효율적인 모델 — 프로덕션에 완벽 Llama 2 (13B/70B) — 현실 점검
• Llama 2-13B: 단일 H100에서 5,000–6,000 tokens/sec(최적화 적용)
• Llama 2-70B: 실행할 수 있지만 지연 시간이 높음 — 진정한 70B+ 요구에만 적합
• 대부분의 제품은 GPU 1개에서 13B– 32B로 훌륭한 결과를 얻음 경험 법칙—H100 하나로 무엇을 할 수 있는가?
• LLM이 <32B 밀집 모델이거나 활성 파라미터가 ~13B인 MoE라면, 반응성이 뛰어난 다중 사용자 채팅과 RAG API에 단일 H100이면 충분하다 H100: OSS GenAI 서빙의 새로운 최적점
• GPU 하나에서의 설계 패턴: API, RAG, 에이전트 채팅 및 API 서빙 패턴
• 단일 H100에서 LLM API 실행: Hugging Face + vLLM/TensorRT-LLM
• 낮은 지연 시간으로 여러 사용자에게 서비스—클러스터 운영이나 샤딩 불필요
• 단순하고 빠르며 프로덕션에 바로 사용할 수 있는 배포 검색 증강 생성(RAG)
• 벡터 DB/문서는 GPU 외부에 저장하고 H100은 LLM 생성에 사용
• 단일 H100이 RAG API에 높은 처리량과 빠른 GenAI 제공
• Mixtral/MoE 모델: 양자화를 사용해 단일 GPU에 적재 에이전틱 워크플로
• H100의 “플래너” LLM(Qwen/Mistral)이 작업을 외부 도구로 라우팅
• GPU는 사고에 사용하고 도구는 다른 곳에서 실행(HTTP, Lambda, 컨테이너)
• 인스턴스 하나에서 멀티 에이전트, 다중 사용자 흐름 지원 요약—H100 하나, 다양한 패턴
• H100 인스턴스 하나만 사용해 채팅, API, RAG, 에이전트 등 대부분의 GenAI 제품을 구축.
• 비용 및 적정 규모 조정: H100 하나로 충분한 경우

H100 하나와 멀티 GPU 클러스터 비교

• 멀티 GPU 클러스터: 효율성 75–85%, 속도가 8배 향상되는 경우는 드묾
• GPU 간 통신이 확장을 늦춤—더 많은 하드웨어, 더 높은 복잡성
• 단일 H100은 대부분의 OSS 모델에 강력한 성능 제공 비용: p5.4xlarge는 경제적
• 시간당 단 $3.90(Capacity Blocks, 일부 리전)
• 실험, 개발 또는 프로덕션 실행—GPU 8개 비용을 낼 필요 없음
• 소규모 팀, 스타트업, 내부 도구에 적합 H100과 멀티 GPU 중 선택하는 시점
• 단일 H100: 7B– 32B 밀집 모델 또는 활성 파라미터 ~13B인 MoE LLM, 중간 수준 QPS에 이상적
• 멀티 GPU: 진정한 70B+ 모델 또는 대규모 파인튜닝에 필요
• H200: 초고처리량을 위한 다음 단계(미래 대비) 요약 및 핵심 요점
• 대부분의 OSS LLM 워크로드: 단일 H100 p5.4xlarge가 현명한 선택
• 클러스터 복잡성도, 낭비되는 비용도 없이 실행하고, 튜닝하고, 배포하기만 하면 됨 기억해야 할 세 가지 핵심
• 어떤 모델이 적합한가? Qwen3-32B, Llama 2-13B, Mistral, Mixtral—최대 32B
• 어떤 패턴인가? 채팅 API, RAG, 에이전틱 워크플로—모두 GPU 하나에서
• 사용 시점: 개발, 내부 도구, 초기 단계 제품, 중간 수준 동시성 직접 사용해 보기 + 레퍼런스 아키텍처
• Amazon EC2 p5.4xlarge를 시작하고 vLLM/TensorRT-LLM으로 배포
• 자체 지연 시간, 처리량, 비용 절감 효과 측정