극점매크로｜Financial Cloud Cloud · AWS Amarathon 2025
극점매크로｜Amarathon 2025 정리 26：단일 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으로 배포
● 자체 지연 시간, 처리량, 비용 절감 효과 측정