본문으로 건너뛰기

© 2026 Molayo

r/LocalLLaMA분석2026. 06. 24. 05:06

단일 8×A100 노드에서 Llama 3.1 405B + 7개의 Hot LoRA 실행 (vLLM / AWQ-int4 / Marlin)

요약

단일 8x A100 노드에서 Llama 3.1 405B 모델과 7개의 LoRA 어댑터를 vLLM을 통해 실시간(Hot)으로 서빙하는 최적화 사례를 소개합니다. AWQ-int4 양자화와 Marlin 커널을 활용하여 어댑터 전환 시간을 최소화하고 처리량을 극대화했습니다.

핵심 포인트

  • vLLM 멀티-LoRA를 통해 7개의 어댑터를 VRAM에 상주시켜 전환 시간 170ms 미만 달성
  • AWQ-int4 양자화 적용으로 405B 모델 서빙 시에도 약 150GB의 VRAM 여유 공간 확보
  • 기존 콜드 로드 방식 대비 처리량(throughput)을 5~7배 향상
  • 단일 노드 구성을 통해 멀티 노드 클러스터 대비 비용 절감 및 프라이빗 환경 구축

이것은 프로덕션 배포를 위해 구축되었습니다. 외부 API를 통해 민감한 데이터를 전송하지 않고, 멀티 노드 클러스터를 실행하지 않으면서도 프라이빗하고 특화된 AI가 필요했습니다.

405B급 서빙을 위한 일반적인 경로는 제공업체와 구성에 따라 월 10만~20만 달러 범위에 달하는 멀티 노드 인프라를 향합니다. 저는 이 특정 워크로드에 대해 더 좁은 경로를 찾아냈습니다.

설정:

  • Llama 3.1 405B Instruct
  • AWQ-int4 양자화 (quantization)
  • Marlin 커널 (kernels)
  • vLLM 멀티-LoRA 서빙 (multi-LoRA serving)
  • 7개의 도메인 특화 LoRA 어댑터 (adapters)
  • 7개의 어댑터 모두 VRAM에 동시에 Hot 상태로 로드됨
  • 단일 AWS p4de.24xlarge: 8x A100-SXM4-80GB, 640GB VRAM
  • 단 한 번의 부팅, 55일 이상의 연속 가동 시간 (uptime)

주요 수치:

  • 7개의 특화 어댑터가 항상 VRAM에 상주
  • 엔드 투 엔드 (end-to-end) 어댑터 전환 시간 168-170ms
  • 어댑터 스왑 자체는 ~0ms: 메모리 전송이 아닌 포인터/라우팅 (pointer/routing) 작업
  • 7개 어댑터 전체에 걸친 첫 번째 토큰 생성 시간 (time-to-first-token) 63-66ms
  • 단일 어댑터 지속 생성 속도 ~19 tok/sec
  • 7개 어댑터 동시 실행 시 결합 속도 82.9 tok/sec
  • 14개 동시 요청: 결합 속도 110.6 tok/sec, 실패 0건
  • 21개 동시 요청: 결합 속도 115.0 tok/sec, 실패 0건
  • 7개 어댑터가 Hot 상태인 상태에서도 약 150GB의 VRAM 여유 공간(headroom) 남음
  • 55일 이상의 가동 시간 (uptime)
  • 서비스 재시작 0회
  • OOM (Out of Memory) 킬 0회
  • NCCL 오류/타임아웃 0회
  • 캡처된 상태 감사(health audit) 결과 8개 GPU 전체에서 GPU ECC 오류 0회

이전 아키텍처:
Ollama, 한 번에 하나의 모델만 사용. 전문가를 바꿀 때마다 콜드 로드 (cold load)가 필요했으며, 90-150초가 소요되었습니다.
이는 프로덕션 에이전틱 워크플로우 (agentic workflows)에 사용할 수 없는 수준이었습니다.

현재 아키텍처:
vLLM 멀티-LoRA는 모든 어댑터를 상주 상태로 유지합니다. 전문가 간의 전환은 로드 작업이 아닌 라우팅 결정입니다.
405B AWQ-int4 베이스 모델은 7개의 어댑터를 모두 Hot 상태로 유지하면서도 약 150GB의 VRAM을 여유 있게 남겨둡니다. 기존에 NF4로 학습된 어댑터들을 재학습 없이 AWQ-int4 베이스에 로드했습니다. 이 마이그레이션(migration)을 통해 어댑터 재학습이나 아키텍처 변경 없이 처리량(throughput)이 5-7배 증가했습니다.

이것이 중요한 이유:
법률, CRO(전환율 최적화), SEO, 빌더, 사서, 전략, 고객 대응 등 여러 명의 전문가가 필요한 경우, 콜드 스와핑(cold swapping)은 워크플로우를 끊어지게 만듭니다. 사용자는 시스템이 역할을 바꿀 때마다 1~2분을 기다릴 수 없습니다.
어댑터(adapter)를 핫(hot) 상태로 유지하면 시스템이 마치 여러 명의 전문가가 동시에 대기 중인 것처럼 동작하게 됩니다.

H200의 경우:
이는 아직 측정된 수치는 아니며 방향성을 제시하는 것입니다. H200은 8개의 GPU에 걸쳐 총 1,128GB의 VRAM을 보유하고 있습니다. 현재 A100 페이로드(payload)는 약 484GB이며, 이는 H200에서 약 644GB의 여유 공간을 남깁니다. 측정된 어댑터 점유 공간(footprint)을 기준으로 볼 때, 컨텍스트 길이(context length), KV 캐시(KV cache) 예산, 랭크(rank) 및 서빙 구성(serving configuration)에 따라 하나의 H200 노드에서 50~60개의 전문화된 어댑터를 동시에 실행하는 것이 가능할 수 있음을 시사합니다.

한 가지 내부 블라인드 평가(blind eval):
GPT-4o가 판정한 4-way 블라인드 평가에서, 미세 조정(fine-tuned)된 CRO 및 법률 어댑터는 좁은 도메인 작업(narrow domain tasks)에서 Gemini 2.5 Pro보다 높은 점수를 기록하면서도 훨씬 짧은 출력을 생성했습니다. GPT-4o는 Gemini가 6-7/10점을 받은 것에 비해 어댑터들에게 도메인 정확도 8/10점을 부여했습니다.
범용 모델의 우월성을 주장하는 것이 아닙니다. 핵심은 더 구체적입니다: 범위가 엄격히 제한된 도메인 작업에서는 전문화(specialization)가 범용적인 규모(general scale)를 이길 수 있다는 점입니다.

이것이 아닌 것:

  • 405B 파라미터의 전체 모델 미세 조정(full-model fine-tuning)이 아님
  • 모든 405B 워크로드(workload)가 하나의 노드에 들어간다는 주장이 아님
  • 멀티 노드 프런티어 학습(multi-node frontier training)의 대체제가 아님
  • H200 수치가 측정되었다는 주장이 아님
  • 이것은 특정 클래스의 워크로드에 대해 문서화된 프로덕션 경로입니다: 405B급 Instruct 모델 상의 프라이빗하고 전문화된 LoRA 어댑터

구성(configs), VRAM 계산, 벤치마크 방법론, 마이그레이션 버그 및 프로덕션 상태 감사(production health audit)를 포함한 전체 분석 내용:
https://huggingface.co/JohnBirks/llama-405b-multilora-production

정리된 구성(config) Gist:
https://gist.github.com/JohnMBirks/8de22d2face739d3a518a25fb59a864a

기술적인 질문에 답변하거나, 유용하다고 생각되는 추가 벤치마크를 실행할 용의가 있습니다.
submitted by /u/Esph1001
[link] [comments]

AI 자동 생성 콘텐츠

본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0