Helix Parallelism: Rethinking Sharding Strategies for Interactive Multi-Million-Token LLM Decoding

작성일 | In , ,
Reading time 33

논문 링크

Helix Parallelism: 초장기 LLM 디코딩의 지연-처리량 벽을 깨다

한 줄 요약 (TL;DR)

Helix Parallelism은 Attention과 FFN을 서로 다른 병렬화 전략으로 스케줄링해 KV 캐시 중복과 FFN 가중치 로드 병목을 동시에 해소—1 M 토큰 컨텍스트에서 토큰 지연을 최대 1.5 × 줄이고, 동일 지연 예산으로 동시 사용자 수를 32 × 까지 늘린다.

핵심 아이디어

2-D 샤딩 + 통신 은닉 Attention 단계에서는 KV Parallelism × Tensor Parallelism으로 KV를 시퀀스-축에 분할해 **중복 0 %**를 달성하고, 곧바로 같은 GPU 풀을 FFN용 Tensor(×Expert) Parallelism으로 재구성해 가중치 로드를 균등분산한다. 두 단계 사이의 All-to-All 통신은 HOP-B 파이프라인으로 계산과 겹쳐 노출 지연을 최소화한다.

배경: 그들이 해결한 문제

대형 LLM을 “실시간”으로 서빙할 때는 두 가지 상반된 병목이 동시에 발생한다.

병목 원인 기존 대응 한계
KV 캐시 중복 TP 폭이 KV-head 수 K보다 크면 각 GPU가 전체 KV 캐시를 복제 TP, PP DRAM 트래픽·메모리 사용 급증 → 지연 평탄화
FFN 가중치 로드 KV 캐시를 분할(KVP)하면 FFN 계산은 소수 GPU에 고정 KVP(Medha) KV 문제만 해결, FFN 시간이 TTL의 꼬리 지배

결국 **“KV를 나누면 FFN이 느리고, FFN을 나누면 KV가 복제”**되는 택일 구조에서 벗어나지 못했다.

새로운 접근법: Helix Parallelism

Helix는 한 레이어 안에서 시간을 두 토막 낸다.

  1. Attention — KV Parallelism (시퀀스) × Tensor Parallelism (헤드)

    • KV 슬라이스별 FlashAttention 수행

    • 부분 출력 Oᵢ 와 log-sum-exp LSEᵢ만 All-to-All →

      \[O = \frac{\sum_i O_i\,e^{\text{LSE}_i}}{\sum_i e^{\text{LSE}_i}}\]

      로 정확한 softmax 복원

  2. FFN — 동일 GPU 풀을 즉시 TP(×EP) 레이아웃으로 전환

    • All-to-All 후 32-way GEMM, All-Reduce로 합산

  3. HOP-B — 토큰 t의 All-to-All을 토큰 t + 1의 FlashAttention과 겹쳐 통신 은닉

    • 노출 통신 시간 ≤ 12 % TTL

작동 원리: 구체적인 예시로 살펴보기

Llama-3 70B | 32× H100 (NVLink node) Q-heads = 64, K = 8 → 8 TP × 4 KVP = 32 GPU

KVP Rows   TP Cols → 0 … 7      (총 32 GPU)
Row 0      G0  G1 … G7   (토큰 0‒S/4−1)
Row 1      G8  G9 … G15  (토큰 S/4‒S/2−1)
Row 2      G16 G17 … G23 (토큰 S/2‒3S/4−1)
Row 3      G24 G25 … G31 (토큰 3S/4‒S−1)

KV 중복 = 0 %, KV 캐시/GPU ≈ 0.3 GB

한 토큰 흐름

  1. GPU Gr,c — 자기 KV-슬라이스에 FlashAttention → (Oᵢ, LSEᵢ)
  2. All-to-All ① — B·H 규모 데이터 교환
  3. 재조합 식으로 softmax 완성
  4. 레이아웃 전환 — All-to-All ②, 데이터가 TP 정렬
  5. 32-way TP FFN → All-Reduce ③
  6. HOP-B — ①을 다음 토큰의 1단계와 오버랩

측정치 (1 M ctx) TTL 9.7 ms (vs 11 ms), tok s⁻¹ GPU⁻¹ 360 (vs 90), 동시 배치 4 × 확장.

성능 검증: 주요 결과

모델 HW 구성 TTL ↓ Batch/Throughput ↑
DeepSeek-R1 671 B MoE 72 GPU 1.5 × 32 ×
Llama-405 B Dense 72 GPU 1.13 × 4 ×
Llama-3 70B (추론) 32 GPU 1.13 × 4 ×

Helix 점들이 기존 TP/KVP/PP 조합의 Pareto 프론티어를 통째로 밀어냈다.

우리의 관점: 강점, 한계, 그리고 이 연구가 중요한 이유

강점

  • 이중 병목 동시 해결 — KV 중복 없이도 FFN 로드를 균등 분산.
  • 통신량 상수화 — All-to-All이 컨텍스트 길이 S와 독립 → 1 M+ 토큰에도 유지.
  • 정밀도·모델 구조 무관 — FP4/FP8, GQA, MLA, MoE 모두와 즉시 호환.

한계

  • 단일 NVLink 노드 전제 — 다중 노드/InfiniBand 구간에선 통신 은닉률 감소.
  • 짧은 문맥·작은 GPU 풀 — G ≤ K이면 Helix 이득이 미미.
  • 품질·에너지 분석 부재 — FP4 정밀도의 수치 안정성, J·token⁻¹ 평가가 빠져 있다.

왜 중요한가?

실제 서비스에서 요구되는 것은 “낮은 지연 + 높은 동시성”. Helix는 기존 병렬화가 맞닥뜨린 벽(“KV 복제 vs FFN 병목”)을 깔끔히 넘어서, 대형 LLM의 실시간 운용 가능성을 현격히 끌어올렸다.

다음 단계는?: 앞으로의 길

  1. 희소 어텐션 (NSA) 통합 — KV 대역을 추가 50 % 절감할 잠재력.
  2. 멀티-노드 Helix — Topology-aware All-to-All로 클러스터 스케일 확장.
  3. Adaptive Scheduler — 실행 중 KV/FFN 비중을 계측해 Helix↔전통 TP 동적 전환.
  4. 정밀도·품질 검증 — FP4/FP8 에서 softmax 재스케일의 수치 안정성, 모델 드리프트 테스트.
  5. 에너지·비용 지표 공개 — J·token⁻¹, 원·10⁶ tokens⁻¹을 공식 보고해 현실적 ROI를 제시.

Helix는 “대형 LLM 실시간 서빙” 퍼즐의 핵심 조각을 맞췄다. 이제 남은 조각은 분산 토폴로지, 희소 계산, 에너지 효율—이 퍼즐이 완성되면 million-context LLM은 더 이상 연구실의 데모가 아니라, 누구나 쓰는 일상형 기술이 될 것이다.

토글을 클릭하면 논문에 대한 자세한 LLM 질의응답 내용을 확인할 수 있습니다.

▶️클릭하여 펼치기

프롬프트 1.1.1 (연구의 공백)

"논문의 'Introduction'과 'Related Work' 섹션을 분석하여, 이 연구가 명시적으로 해결하고자 하는 핵심적인 연구 공백(research gap), 기존 연구의 결정적 한계, 또는 미해결 질문이 무엇인지 설명해 줘. 저자들이 설명하는, 이 논문 출판 시점의 '최신 기술(state of the art)'은 어떤 상태였는지 요약해 줘."

핵심 결론 (한 줄 요약)

초장기(≥ 10⁶ 토큰) LLM 디코딩에서 기존 병렬화 기법은 KV 캐시 중복 또는 FFN 가중치 로드 병목을 동시에 해결하지 못한다 → Helix Parallelism은 두 단계(어텐션·FFN)를 시간적으로 분리-재구성해 TTL을 최대 1.5× 단축하고 동시 배치 규모를 최대 32× 확장한다.

1. 연구 공백 및 미해결 질문

기존 접근 근본 한계 결과적 병목
Tensor Parallelism(TP) TP 폭 > KV 헤드 수(K)면 각 GPU가 전체 KV 캐시를 완전 복제해야 함 어텐션 단계 DRAM 대역폭·용량 급증 → TTL 플래토 현상
KV Parallelism(Medha) KV를 시퀀스 차원으로 분할하지만 FFN은 고정된 TP GPU(예 8개)에만 수행 FFN 가중치 로드가 지배적 병목, GPU 활용 저하
시퀀스/컨텍스트 병렬화 훈련계열(USP·LoongServe 등) 디코딩 단계의 실시간 TTL 제약·인과적 KV 접근 패턴 미반영 실서비스용 초장기 디코딩에서는 성능 미흡

따라서

“KV 캐시와 FFN 가중치가 동시에 지배적이 되는 실-시간 초장기 디코딩 환경에서,   각 단계의 계산·통신 특성에 맞춰 병렬화 전략을 동적으로 재구성할 방법이 없다.”

Helix Parallelism은 바로 이 이중 병목을 해소하기 위해 고안됨.

2. 논문 출판 시점의 최신 기술 현황(SOTA) 요약

  • 모델·하드웨어 조건

    • GQA·MQA·MLA 등으로 KV 헤드 K ≪ 쿼리 헤드 Q (예 Q = 128, K = 8).
    • NVIDIA Blackwell GB200 NVL72 급 GPU → NVLink 도메인 확대, FP4 저정밀 지원.

  • 지배적 병렬화 조합

    1. TP(≤ K) : KV 중복은 없으나 병렬성 한계, FFN 로드 병목.
    2. TP(> K) : 병렬성↑ 대신 KV 캐시가 K 배로 중복.
    3. TP + PP + EP : 파이트출·프리필에 효과적이나 디코딩 TTL 감소 한계.
    4. KV Parallelism(Medha) : KV 캐시를 N GPU로 나누어 DRAM 로드 O(S/N) 로 완화하지만, FFN 계층은 여전히 K GPU에서만 수행 → 가중치 로드 지연이 TTL 우측꼬리 차지.

  • 성능 한계 수치 예시

    • TP 단독 (GQA, K = 8) → TP 폭이 8 을 넘는 순간 KV 캐시 사이즈·읽기 시간 더 이상 감소하지 않음.
    • Medha + Blackwell 환경 → KV 캐시 문제는 해결되나 DeepSeek-R1 (MoE) 기준 TTL 50 % 이상이 FFN 로드가 차지.

Helix가 제시하는 숫자 기반 개선폭

모델 TTL 개선 동시 배치 규모 토큰/s/GPU 향상
DeepSeek-R1 (671 B MoE) 1.5× ↓ 32× ↑ N/A (동일 TTL에서 32× batch)
Llama-405 B Dense 1.13× ↓ 4× ↑ 4× ↑

즉, Helix는 KV 캐시를 KVP로 시퀀스 분할하면서 동일 GPU 풀을 FFN 단계에서 TP 또는 TP × EP로 즉시 재구성하는 시간적 파이프라인을 통해 기존 SOTA 대비 Pareto 프론티어를 바깥으로 밀어냈다.

요약: 기존 TP·KVP 구조는 KV 중복 또는 FFN 병목 중 하나만 완화했을 뿐, 두 병목을 동시에 해결하지 못했다. Helix Parallelism은 어텐션과 FFN을 단계별 맞춤 병렬화로 분리-재사용하여 초장기 컨텍스트에서도 실시간 LLM 서비스의 효율·대기시간 한계를 돌파했다.

프롬프트 1.1.2 (핵심 가설)

"이 논문의 중심 가설(central hypothesis) 또는 핵심 주장은 무엇인가? '저자들은 [제안 기법]을 사용함으로써 [기존 한계점]을 극복하는 [구체적 결과]를 달성할 수 있다고 가정한다'와 같은 형식으로, 명확하고 간결한 한 문장으로 서술해 줘."

**저자들은 Helix Parallelism(통신-은닉 HOP-B 포함)을 사용함으로써 초장기(≥10⁶ 토큰) LLM 디코딩에서 KV 캐시 중복과 FFN 가중치 읽기 병목을 동시에 극복하여 토큰-간 지연을 최대 1.5 × 단축하고, 동일 TTL 예산에서 동시 배치 규모를 32 × 까지 확장할 수 있다고 가정한다.

프롬프트 1.2.1 (독창성 식별)

 "논문 전체를 바탕으로, 가장 중요하고 독창적인 기여(contribution) 1~3가지를 구별되는 항목으로 나열해 줘. 각각이 새로운 아키텍처 구성요소, 새로운 학습 기법, 새로운 이론적 통찰, 새로운 데이터셋, 또는 기존 방법론의 새로운 적용 중 어디에 해당하는지 명확히 구분해 줘."

한눈에 결론

Helix Parallelism + HOP-B가 초장기(≥10⁶ 토큰) LLM 디코딩에서 TTL을 최대 1.5 × 단축하고, 동일 TTL 예산에서 동시 배치 규모를 최대 32 ×까지 확장한다.

Helix 논문의 독창적 기여 3선

# 기여 분류 핵심 성과·수치
1 Helix Parallelism
— Attention 단계에서는 KV Parallelism(시퀀스 축 분할) × Tensor Parallelism(≤ K)으로 KV 중복 0%;
— 같은 GPU 풀을 FFN 단계에 즉시 재구성하여 TP 또는 TP×EP로 가중치 로드 병목 제거		 새로운 아키텍처 구성요소 (하이브리드 시공간 파이프라인 샤딩) • KV 중복 제거로 DRAM 트래픽 ↓, FFN 로드 분산
• DeepSeek-R1 기준 TTL 50 %↓, 배치 32 ×↑
2 Helix HOP-B (Helix Overlap Pipeline-Batchwise)
— Query별 All-to-All 통신을 바로 시작해 다음 Query 계산과 겹쳐 실행		 새로운 아키텍처 구성요소 (통신-은닉 최적화) • 통신-계산 겹침으로 노출 통신 시간→0 ~ 12 % TTL↓ (모델·배치에 따라)
3 2D Roofline 분석 + 10만 건 시뮬레이션으로 도출한 Pareto 프론티어
— TP > K에서 KV 복제 플래토, KVP만으로는 FFN 병목 지속 등 이중 병목을 정량 규명		 새로운 이론적 통찰 + 기존 방법론의 새로운 적용 (초장기 디코딩 하드웨어-의식 성능 모델링) • KV·FFN DRAM-읽기 한계선을 시각화해 Helix 설계 근거 제시

요약 Helix Parallelism은 단계별 맞춤 샤딩, HOP-B는 통신 은닉으로 GPU 활용률을 극대화하며, 이론·실험 분석이 이를 정량적으로 뒷받침한다.

프롬프트 1.2.2 (저자 관점에서의 강점)

"저자들의 관점에서, 자신들의 접근법이 이전 방법들보다 우월한 이유는 무엇인가? 그들이 자신들의 연구가 지닌 독창성과 강점을 뒷받침하기 위해 사용하는 핵심 논거를 인용하거나 알기 쉽게 설명해 줘."
**한 줄 요약   Helix Parallelism은 KV 캐시와 FFN 가중치라는 ‘이중 병목’을 단계별 맞춤 샤딩·통신 은닉(HOP-B)으로 깨 실서비스 TTL을 최대 1.5× 단축하고, 동일 지연 한도 내 동시 사용자 수를 최대 32× 늘린다고 저자들은 주장한다.**

저자 관점에서 내세우는 3가지 ‘우월성’ 논거

# 왜 기존보다 낫나? (저자 주장) 핵심 증거·수치
1. “이중 병목 동시 해결”
 KV 중복 없이도 FFN을 풀-TP/TP×EP로 분산		 - Attention 단계는 KVP×TP로 KV를 시퀀스 축에 분할해 DRAM 읽기·용량을 선형→아래로 꺾음
- 곧바로 같은 GPU 풀을 FFN 단계에 재구성, 가중치 로드를 N GPU에 분산 → KV 중복 0 %, FFN 병목 제거		 Roofline 분석: TP > K 구간서 KV 읽기 지연 ‘플래토’, Helix는 2D 샤딩으로 완전 회피
2. “통신-은닉형 HOP-B”
 All-to-All 통신을 다음 토큰 계산과 겹침		 배치 차원 파이프라인으로 노출 통신 시간 0 – 12 %로 수렴, Llama-405B 기준 HOP-B OFF 대비 TTL 12 %↓ 회복 Ablation: HOP-B ON ↔ OFF 비교 실험 · TTL 이득 최대 12 %
3. “Pareto 프론티어 외부로 확장” DeepSeek-R1 1 M ctx → TTL 1.5×↓ & 32× 더 많은 동시 배치
Llama-405B 1 M ctx → TTL 1.13×↓ & 4× TPS/GPU↑		 10만 개 샤딩·배치 시뮬레이션에서 Helix가 기존 TP·KVP 조합보다 우상향 프론티어 달성

추가 근거 (텍스트 인용 중심)

  • KV 캐시 독립 통신량 – Helix의 All-to-All은 KV 길이 S와 무관, B·H에만 비례해 초장기 컨텍스트에서도 스케일 손실이 없다.
  • 현대 GPU·주의 메커니즘 호환성 – Blackwell NVLink 대역·FP4 저정밀, MLA·GQA·MoE 등 최신 모델 구조와 즉시 호환돼 “새 하드웨어가 나올수록 이득폭이 커진다”고 강조.
  • Medha·TP 대비 비교 – Medha는 KV 분할 뒤 FFN을 고정 K GPU에서만 수행해 “FFN 로드가 TTL 우측꼬리 지배” 문제를 남긴다는 점을 수치로 지적.

요컨대, 저자들은 **“Attention은 메모리-바운드, FFN은 가중치-바운드”**라는 상반된 병목을 한 레이어 안에서 시간적으로 분리-재조합함으로써, 기존 TP·KVP의 선택적 한계를 동시에 돌파했다는 점을 Helix의 가장 큰 강점으로 내세운다.

프롬프트 1.3.1 (알고리즘 단계별 설명)

"핵심 알고리즘, 모델 아키텍처, 또는 주요 방법론을 단계별(step-by-step)로 설명해 줘. 독자는 AI 분야의 대학원생 수준이라고 가정해. 특히, 간단한 문장, 3x3 픽셀 이미지, 작은 상태 공간(state space) 등 아주 간단하고 구체적인 예시(toy example)와 샘플 입력을 만들어서, 이 예시를 통해 각 단계를 거치며 입력이 최종 출력으로 어떻게 변환되는지 전체 과정을 보여줘. 등장하는 모든 핵심 용어와 변수는 그 즉시 정의해 줘."
**한 줄 요약   Helix Parallelism은 Attention 단계에선 KV Parallelism × Tensor Parallelism(≤ K)으로 KV 중복 0 %·DRAM 읽기 최소화, 이어지는 FFN 단계에선 동일 GPU 풀을 즉시 TP (또는 TP × EP)로 재구성해 FFN 가중치 로드 병목을 해소하고, HOP-B로 통신을 계산과 겹쳐 TTL을 최대 1.5× ↓, 동시 배치 규모를 32× ↑ 시킨다.

1. 용어·변수 빠른 정의

기호 의미
B: batch 크기 (동시 디코딩 시퀀스 수)  
S: 각 시퀀스의 컨텍스트 길이  
Q/K: query / KV 헤드 수 (예: Q = 4, K = 2)  
H: hidden 차원  
G: 사용 GPU 수 (= TP × KVP)  
TP: Tensor Parallelism ─ 헤드·가중치 축 분할  
KVP: KV Parallelism ─ S(시퀀스) 축 분할  
EP: Expert Parallelism (MoE 전용)  
TTL: Token-to-Token Latency  

2. Helix 알고리즘, 단계별 워크플로

단계 GPU 레이아웃 핵심 연산 & 통신 흐름
① Attention
(TP≤K, KVP > 1)
TP splits heads, KVP splits sequence ⇒ G = TP × KVP		 1. 각 GPU가 전체 QKV 프로젝션 계산→ 자기 KV 슬라이스( S/KVP ) 보유
2. 슬라이스 별 FlashAttention 실행→ 부분 출력 & log-sum-exp (LSE) 산출
3. All-to-All(1): query-head 축으로 부분 출력 & LSE 교환
4. 재스케일·합산해 정규화된 최종 Attention 결과 오차 0 % 재구성
② HOP-B (통신 은닉) 동일 Attention 토큰 i의 All-to-All 통신을 토큰 i+1 연산과 파이프라인으로 겹침 → 노출 통신 시간 **0–12 %**까지 축소
③ FFN
(Dense: TPF = G, MoE: TPF × EP = G)		 GPU 풀 재배치: G개 → TPF(가중치 축) × EP(전문가) 1. All-to-All(2): [B,H] 은닉 상태를 TP 레이아웃으로 재분배
2. 각 GPU가 FFN 1·2층 GEMM 수행 (MoE 일 경우 라우팅 포함)
3. **All-Reduce(3)**로 부분 결과 합산 → [B,H] 출력
4. 다음 레이어로 전달, GPU 레이아웃은 다시 ①로 회귀
⇒ 효과 KV 읽기량 ∝ S/KVP, FFN 가중치 읽기량 ∝ (모델 매트릭스)/G → 두 병목 동시 완화.

3. 장난감 예시로 전체 흐름 따라가기

환경 B = 1, S = 4, Q = 4, K = 2, H = 6, G = 2 (TP = 2, KVP = 1) ← 두 GPU만 사용해 개념 강조

3-1. 입력 준비

새 토큰의 query 벡터 q = [1 0 1 0 0 1] KV 캐시(4 × 6) 는 GPU0(토큰 0-1), GPU1(토큰 2-3)에 절반씩.

3-2. Attention 단계 (GPU별 계산)

GPU KV 슬라이스(2 토큰) ① dot(q,K) → α ② softmax α ③ α·V → o_partial
0 K₀₋₁ [3, 2] [0.73, 0.27] [0.73·v₀+0.27·v₁]
1 K₂₋₃ [1, 4] [0.12, 0.88] [0.12·v₂+0.88·v₃]

All-to-All 후 두 GPU는 서로의 o_partial, LSE를 받아 o_final 재구성.

3-3. HOP-B

토큰 t₀의 All-to-All(≈0.2 ms)과 t₁의 FlashAttention(≈0.6 ms) 겹침 ⇒ 노출 통신 0 ms.

3-4. FFN 단계

All-to-All(2) 로 hidden 6-d 벡터를 절반씩 분할 → GPU0: 첫 3 차원, GPU1: 나머지 3 차원. 각 GPU가 w₁·h_split + b₁ → GeLU → w₂·… 계산 후 All-Reduce(3) 로 합산. 결과 벡터 h′ 가 레이어 출력.

이 과정을 매 토큰마다 반복하며, Helix는 토큰 간 전환(2–3 ms 수준)에서도 KV 중복 0 %와 FFN 가중치 분산을 모두 유지한다.

4. 핵심 수치로 보는 Helix 개선폭

모델 G TTL 개선 동시 배치↑ 근거
DeepSeek-R1 (MoE 671 B) 72 1.5× ↓ 32×  
Llama-405 B (Dense) 72 1.13× ↓ 4× TPS/GPU  

정리 & 포인트

  1. 2-D 샤딩: TP(헤드) × KVP(시퀀스)로 KV 중복 플래토 해소.
  2. 동일 GPU 재활용: Attention → FFN으로 즉시 레이아웃 전환, 가중치 읽기 분산.
  3. HOP-B: 통신을 계산과 겹쳐 TTL 손실 ≤ 12 %.
  4. 결과: 실시간 초장기 디코딩에서 지연·동시성 Pareto 프론티어를 바깥으로 확장.

프롬프트 1.3.2 (‘비밀 병기’ 식별)

"이 논문의 핵심 기여를 가능하게 하는 가장 결정적인 단일 수학 공식, 알고리즘 단계, 또는 아키텍처 구성요소를 식별해 줘. 그것의 기능과, 그것이 이 방법론의 성공에 왜 필수적인지 설명해 줘."
**결론 먼저   Helix의 ‘비밀 병기’는 **각 KV 파티션이 계산한 부분 어텐션 출력 Oᵢ와 log-sum-exp LSEᵢ를 한 번의 All-to-All 후
\[\boxed{\;O=\frac{\sum_{i=1}^{N} O_i\,e^{\text{LSE}_i}}{\sum_{i=1}^{N} e^{\text{LSE}_i}}\;}\]

로 재스케일 · 합산해 정확한 소프트맥스 결과를 복원하는 ‘단일 All-to-All + LSE 재조합’ 단계다. 이 한 수식·한 통신 라운드가 Helix Parallelism의 2-D 샤딩을 성사시킨다.

1. 무엇을 하는가? — 기능

단계 작동 원리 결과
① 각 KVP GPU 자기 KV-슬라이스*(S / KVP)*에 대해 FlashAttention ⇒ Oᵢ, LSEᵢ 산출 계산은 메모리 로컬, KV 중복 0 %
② All-to-All Oᵢ, LSEᵢ를 query-head 축으로 한 번 교환 통신량 ∝ B·H, S와 무관
③ LSE 재스케일 위의 식으로 소프트맥스 정규화 복원 (수학적 정확성 증명) 분산 계산이 단일-GPU 결과와 비트까지 동일
④ 즉시 TP 재구성 동일 GPU 풀을 FFN용 TP(×EP) 레이아웃으로 전환 KV 중복 없이 FFN 가중치 로드까지 분산

2. 왜 핵심적인가? — 필수성

  1. KV 중복을 원천 차단 TP 폭을 K보다 크게 키워도 KV 캐시를 복제하지 않아 DRAM 대역·용량 병목이 사라진다.

  2. 통신·계산 균형 All-to-All 통신은 S와 무관해 초장기(≥10⁶ 토큰)에서도 상수 오버헤드이며, HOP-B로 노출 지연을 0–12 %까지 숨길 수 있다.

  3. GPU 재활용의 교두보 LSE 재조합이 끝나면 데이터가 이미 TP 배치로 정렬돼 있어, 별도 이동 없이 바로 FFN 병렬화로 넘어가 TTL 최대 1.5× 단축·동시 배치 32× 확장이라는 Helix 전체 성능 이득을 촉발한다.

  4. 정확도 보존 소프트맥스 분모를 수학적으로 완전하게 재구성(증명 식 ⑥–⑫)하므로 근사화 없이 모델 품질을 유지한다.

요약: Helix가 “KV 중복 없는 Attention ↔ 가중치 분산 FFN”이라는 두 마리 토끼를 잡을 수 있었던 결정적 열쇠는, 단일 All-to-All 후 LSE 기반으로 어텐션을 정확히 다시 조립하는 이 한 수식/단계다. 이 ‘재조합 커널’ 없이는 Helix의 2-D 샤딩과 GPU 풀 재활용이라는 핵심 전략 자체가 성립하지 않는다.

프롬프트 1.4.1 (핵심 결과 분석)

"'Experiments' 또는 'Results' 섹션의 표와 그림을 포함한 주요 결과를 분석해 줘. 사용된 핵심 성능 지표(performance metrics)는 무엇인가? 어떤 벤치마크 데이터셋에서 결과가 보고되었는가? 저자들이 자신들의 방법론의 성공 증거로 가장 강조하는 주요 결과를 요약해 줘."
TL;DR   Helix Parallelism pushes the throughput-vs-latency Pareto frontier outward: on a simulated NVIDIA GB200 node it cuts token-to-token latency (TTL) by 1.5 × for DeepSeek-R1 and 1.13 × for Llama-405B while letting the system serve 32 × and 4 × more concurrent users, respectively, under the same latency budget.

1. 실험에서 사용된 핵심 성능 지표

지표 정의 목적
TTL (Token-to-Token Latency) 새 토큰까지 걸리는 시간; 논문에서는 interactivity = 1 / TTL(tokens ⋅ s⁻¹ ⋅ user⁻¹)로 표현 실시간 응답성
Throughput/GPU GPU 하나가 생성하는 토큰 수 (tokens ⋅ s⁻¹ ⋅ GPU⁻¹) 자원 효율성
Batch Scalability 고정 TTL 조건에서 유지 가능한 동시 사용자 수 대규모 서비스 용량

2. 벤치마크 모델·환경

  • 모델

    • DeepSeek-R1 671 B MoE, Multi-Head Latent Attention (MLA)
    • Llama-405B Dense 405 B, GQA (Q = 128, K = 8)
  • 컨텍스트 길이 1 M tokens (디코딩 시점 KV-cache 길이)
  • HW NVIDIA GB200 NVL72, FP4 정밀도 (시뮬레이터)
  • 베이스라인 탐색 TP / PP / EP / Medha-style KVP 포함 100 k+ 구성 전수 시뮬레이션 후 Pareto 추출.

3. 주요 결과 한눈에 보기

모델 측정치 베이스라인 최고 Helix 개선폭
DeepSeek-R1 TTL (↓) 1.0× 0.67× 1.5× ↓
  Batch cap (↑) 1 × 32 × 32×↑
  Throughput/GPU 1 × 32 × 파레토 동시 향상
Llama-405B TTL (↓) 1.0× 0.88× 1.13× ↓
  Batch cap / TPS·GPU (↑) 1 × 4 × 4×↑
해석   Helix는 KV 중복 없이 TP를 폭넓게 쓰면서 FFN도 동일 GPU 풀에 재배치해 두 병목을 동시 제거—그 결과 모든 지표에서 베이스라인을 엄밀히 우상향(Pareto 우측·상단)한다.

4. Ablation: HOP-B 통신 은닉 효과

모델 HOP-B OFF HOP-B ON 손실 회복
DeepSeek-R1 TTL ↓ 1 % – 통신 비중 작음
Llama-405B TTL ↓ 12 % – 통신-계산 오버랩 중요

HOP-B가 All-to-All 통신을 다음 토큰 계산과 파이프라인화해 노출 지연을 최대 12 % 줄인다.

5. 저자들이 강조하는 성공 증거

  1. Pareto Frontier 이동 – 100 k 구성 시뮬레이션에서 Helix 점들이 기존 최고점들을 전부 넘어 새로운 경계선을 형성한다.
  2. 메모리 독립적 통신량 – KV 길이 S에 무관한 All-to-All 덕분에 1 M+ 토큰에서도 성능 유지.
  3. 이중 병목 해소 – TP > K 시 나타나는 KV 캐시 복제 플래토와 FFN 가중치 로드 병목을 모두 제거, 실험적으로 TTL 최대 50 % 감축.

정리

Helix Parallelism은 TTL·동시성·GPU 효율 세 마리 토끼를 동시에 잡았음을 실험으로 입증했다. 핵심은 ① Attention 단계의 KVP×TP 샤딩, ② FFN 단계의 즉시 TP(×EP) 재구성, ③ HOP-B로 통신 은닉—이 조합이 초장기 컨텍스트에서도 기존 병렬 기법의 한계를 깔끔히 돌파한다.

프롬프트 1.4.2 (비판적 비교)

"제안된 방법론은 논문에서 언급된 주요 베이스라인 및 SOTA(State-of-the-Art) 모델들과 비교하여 어떤 성능을 보이는가? 저자들의 우월성 주장을 가장 강력하게 뒷받침하는 특정 결과나 비교 지점을 식별해 줘. 반대로, 제안된 방법론이 경쟁 모델을 능가하지 못했거나 개선 효과가 미미했던 결과는 없는지 찾아봐. 만약 있다면, 저자들은 이러한 경우에 대해 어떤 이유를 제시하는가?"

한눈에 결론

Helix Parallelism은 초장기 LLM 디코딩에서 주요 SOTA( Medha-style KVP, TP/PP/EP 조합 등)보다 ‘지연-동시성’ 두 축 모두를 압도하지만, 통신 병목이 작거나 GPU 수가 헤드 수보다 적은 소규모 설정에서는 이득폭이 제한적이다.

1. Helix vs. 주요 베이스라인·SOTA ― 성능 비교표

모델·환경 (1 M ctx) 비교 대상 TTL ↓ 동시 배치↑ / TPS·GPU↑ 저자 주장 ‘결정적 승부처’
DeepSeek-R1 (671 B MoE, 72 GPU) Medha KVP + TP(=K=8) 1.50 × 32 × KV 중복 0 % + FFN 로드 분산으로 두 병목 동시 해소
  Best TP only (K=8) >1.80 × 32 × TP 폭 제한 없이 KV 중복 회피
Llama-405B (Dense) Medha + TP(=8) 1.13 × 4 × TPS·GPU 헤드 수(K=8) 초과 TP에서도 KV 복제 無
  Pipeline Parallel(8 stage) >1.30 × 2–3 × PP는 디코딩 시 TTL 대폭 증가

가장 강력한 증거는 DeepSeek-R1에서 동일 TTL 예산으로 32 배 더 많은 사용자를 처리하면서도 TTL 자체를 1.5 배 줄였다는 수치(그림 5, 파레토 프론티어 이동).

2. Helix가 압도적이지 못했던 경우

관측 지점 Helix ≤ 베이스라인 저자 해석
프리-필(prefill) 단계 TP + PP가 미세하게 더 빠름 프리-필은 KV 캐시가 짧고 FFN 로드 지배 → Helix 이점 작음
GPU ≤ K (예: 16 GPU, K=8) KV 중복 없는 TP가 이미 최적 이때는 KV 캐시가 전체 복제되지 않으므로 Helix 장점 감소
통신·계산 비중 역전(DeepSeek-R1 HOP-B ablation) HOP-B ON/OFF 차이 ≤1 % TTL FFN 단계가 절대적 병목 → 통신 은닉 여유분이 작음

저자들은 “Helix는 ‘KV 중복 + FFN 로드’가 동시에 지배적일 때 최대 효과를 보인다”고 명시한다. 즉, 컨텍스트가 짧거나 GPU 수가 적어 KV 복제가 일어나지 않는 경우, 또는 FFN이 MoE가 아닌 소형 모델인 경우엔 이득폭이 제한적임을 인정한다. KV 헤드 K와 GPU 수 G의 상대 규모가 Helix 적용 이득을 가르는 핵심 매개 변수라는 것이다.

3. 요약 & 비판적 시사점

  1. 대규모·초장기 디코딩(≥ 1 M 토큰, G≫K) → Helix가 Pareto 프론티어 자체를 바깥으로 이동.
  2. 소규모·짧은 컨텍스트 → 베이스라인과 근소차, 통신 은닉 효과도 작아짐.
  3. 따라서 Helix는 “모든 상황에서 만능”이라기보다, 대형 서비스-등급 LLM 배치에 특화된 병렬화 옵션으로 보는 편이 타당하다.

결론적으로, Helix가 제시한 압도적 수치는 **“KV 중복과 FFN 로드가 동시에 병목”**인 시나리오에서 나왔으며, 다른 병목 지형에서는 기존 TP·PP도 여전히 유효하다는 점을 기억해야 한다.

프롬프트 1.5.1 (언급된 한계와 잠재적 한계)

"저자들이 논문에서 명시적으로 인정한 한계점, 약점, 또는 실패 사례(failure modes)는 무엇인가? 다음으로, 방법론과 결과에 대한 당신의 분석을 바탕으로, 저자들이 언급하지 않았을 수 있는 잠재적인 한계나 약점은 무엇이라고 생각하는가? (예: 강력한 가정에 대한 의존성, 확장성 문제, 높은 연산 비용, 일반화의 한계, 잠재적인 부정적 사회 영향 등)"

결론 (1-줄 요약)

Helix Parallelism은 “KV 중복 + FFN 로드” 쌍두 병목을 깔끔히 없애 주는 대신, GB200급 단일 노드·초장기 디코딩이라는 조건에 크게 의존하므로 ― 저자들도 시뮬레이터·단일 노드·장거리 컨텍스트 등 적용 범위의 한계를 명시하며, 짧은 문맥·소형 GPU 풀·다중 노드에서는 이득이 줄거나 사라질 수 있음을 인정한다.

1. 저자가 직접 인정한 한계 · 실패 사례

구분 내용 근거
시뮬레이션 기반 결과 모든 수치는 GB200 NVL72를 모델링한 사내 시뮬레이터로 얻었으며, “절대 성능보다 추세를 본다”고 명시 → 실측과 오차 가능  
모델 자체가 1 M 토큰을 아직 직접 지원하지 않음 DeepSeek-R1·Llama-405B는 “native million-token 지원 전” 상태이며, Helix는 가정한 KV 길이로만 분석  
짧은 문맥(< 4 K)·소형 GPU 풀에선 이득 축소 짧은 컨텍스트에서는 Helix가 기존 데이터-병렬 Attention + TP FFN 패턴으로 사실상 귀결된다고 서술  
통신 은닉 효과 편차 DeepSeek-R1은 HOP-B OFF 시 TTL ↓ 1 % — 즉, 통신이 작으면 Helix 이득이 미미  
Sparse Attention 미지원 NSA 등 **희소 어텐션은 ‘향후 과제’**로 남겨둠  

2. 추가로 예상되는 잠재 한계 (비판적 분석)

  1. 단일 노드 가정 Helix는 NVLink 도메인 내부 All-to-All 대역을 전제로 한다. 다중 노드(MPI/RDMA) 환경에선 통신 은닉이 어려워질 수 있다.

  2. 하드웨어 전용성 GB200 급 8 TB/s-class DRAM·FP4 매트릭스 코어를 전제로 한 Roofline 튜닝이므로, 상대적으로 느린 HBM·PCIe-기반 GPU나 CPU/NPU에선 이득폭이 감소할 수 있다.

  3. 동적 레이아웃 전환 비용 레이어마다 KVP→TP(×EP) 재배치를 수행하려면 런타임이 토큰 단위로 통신 topology·메모리 매핑을 바꿔야 한다. 대규모 멀티-테넌트 서비스에서 스케줄러 복잡도가 급증할 수 있다.

  4. 정밀도·수치 안정성 모든 실험이 FP4 가정이다. 매우 깊은 레이어·극단적 온도에서 LSE 재스케일 수식의 언더/오버플로 위험이 증가할 수 있으나 정밀도 분석은 제공되지 않는다.

  5. 품질(Perplexity) 검증 부재 Helix는 성능 지표(TTL·TPS)만 보고한다. 캐시 샤딩·FP4 연산이 실제 출력 품질이나 드리프트에 미치는 영향은 실험되지 않았다.

  6. 에너지·환경 비용 64–72 GPU를 실시간으로 몰아넣어 TTL을 ↓1.5 × → 절대 소비전력은 증가할 가능성이 큰데, 에너지 효율 분석이 없다.

정리 — 쓸 만한 시사점

  • Helix의 주 타깃은 “G≫K · S≥10⁶ · NVLink급 단일 노드”라는 특수한 대형 서빙 시나리오다.
  • 짧은 문맥·저대역 인터커넥트·다중 노드·희소 어텐션·품질 검증 등에서는 후속 연구 여지가 크다.
  • 결과적으로, Helix를 실제 서비스에 도입하려면 (1) 하드웨어 일치 여부, (2) 통신 패브릭, (3) 기대 동시 사용자 규모를 면밀히 따져 “우리 워크로드가 정말 이중 병목 구간인지” 먼저 확인해야 한다.

프롬프트 1.5.2 (미래 연구 궤적)

"저자들이 제안하는 구체적인 향후 연구 방향은 무엇인가? 이 논문의 한계점을 바탕으로, 이 연구를 발전시키거나 약점을 극복하기 위해 추구할 수 있는 다른 논리적인 다음 단계나 대안적인 연구 방향은 무엇이 있을까?"

요약 — 다음 스텝 한눈에

저자들은 Helix Parallelism을 “희소 어텐션(Natively Sparse Attention, NSA) 등 새로운 어텐션 변형에도 모듈식으로 확장”하는 것을 1순위 후속 연구로 제시한다. 이에 더해 실제 서비스·멀티-노드·품질·에너지 측면에서 열려 있는 6가지 과제를 논리적 다음 단계로 제안한다.

1. 저자들이 명시한 향후 연구 방향

# 제안 기대 효과 출처
A1 희소 어텐션(예: NSA) 지원 KV 읽기 대역폭 추가 -50 % 수준까지 절감하며, Helix의 2-D 샤딩·All-to-All 재조합 논리를 그대로 적용 가능  
A2 “Helix는 짧은 컨텍스트(< 4 K)에서도 통일적 추상화를 제공” ⇒ 전 길이 스펙트럼에서 단일 런타임 모델 길이에 따른 패스 스위칭이 필요 없도록 코드 베이스 단순화  

저자들이 구체적으로 언급한 ‘Future work’는 위 두 항목이 전부이다.

2. 논문 한계 기반 ✔️ 추가로 필요한 연구 6선

잠재 한계 ↘ 제안하는 연구 궤적 ↗ 왜 중요한가?
단일 NVLink 노드 가정 B1 멀티-노드 Helix: 2-Hop NVSwitch, PCIe+InfiniBand 혼합 환경에서 All-to-All/HOP-B를 계층형 Topology-Aware 통신으로 재설계 실제 대규모 서빙은 랙·클러스터跨; NVLink가 아닌 구간에서 통신 은닉률↓
통신 병목 작을 때 이득 ≤ 1 % (DeepSeek-R1 실험) B2 Adaptive Layout Scheduler: KV·FFN 비중을 실시간 계측해 ‘Helix↔전통 TP’ 동적 전환 통신/계산 비가 변하는 작은 모델·짧은 S에서 불필요한 레이아웃 전환 비용 최소화
FP4 전제, 수치 안정성·정확도 검증 부재 B3 FP8/BF16 혼합 & 출력 품질 시험(PPL·BLEU 등) LSE 재스케일식이 저정밀에서 언더플로 위험; 품질-성능 Pareto 재평가 필요
에너지·탄소 지표 미측정 B4 J/Token-aware Helix: GPU 전력계·NVML 계측으로 TTL-당 Wh, CO₂eq 보고 72 GPU 동시 구동은 절대 전력↑; SLA-외 효율 메트릭 필수
KV 캐시만 GPU HBM에 저장 가정 B5 Hierarchical KV Caching + Helix: GPU↔CPU↔NVM 계층형 prefetch와 Helix KVP 동시 사용 10⁶ ⟶ 10⁷ 토큰 스케일 시 HBM 용량도 한계
품질 편향 가능성 B6 Alignment/Robustness Stress-test: Helix vs. TP 동일 출력 여부·레이턴시-품질 Trade-off 체계적 측정 병렬 재조합이 의미론적 Drift를 유발하는지 확인

3. 정리

  • Helix의 공식적인 ‘미래 연구’는 희소 어텐션 지원과 전-컨텍스트 통합 런타임 두 가지로 압축된다.
  • 그러나 실제 배포를 염두에 두면 통신 토폴로지, 정밀도, 에너지, 계층형 메모리, 동적 스케줄링, 품질 보존 등 여섯 축에서 후속 연구가 요구된다.
  • 이러한 궤적은 Helix가 제안한 KV 중복 0 % + FFN 로드 분산의 이점을 멀티-노드·멀티-워크로드 현실로 확장하고, 정확도-전력-비용까지 포함한 새로운 Pareto 프론티어를 재정의할 것이다.

실제 예시

"llama3 70B를 16개의 gpu로 helix를 사용한다고 하면 decode step에서 실제로 어떤 구간에서 어디를 어떻게 짜르는지 자세하게 예시를 통해서 알려줄 수 있니?"

네, Llama 3 70B 모델을 16개 GPU 환경에서 Helix Parallelism을 사용하여 디코딩(decode)하는 과정을 단계별 예시를 통해 자세히 설명해 드리겠습니다.

Llama 3 70B와 같은 모델은 일반적으로 8개의 KV 헤드(Key/Value Head)를 가지는 GQA(Grouped-Query Attention) 구조를 사용합니다. 이 KV 헤드 수(K=8)와 GPU 수(N=16)가 Helix 전략을 결정하는 핵심 요소입니다.

디코딩 과정은 논문에서 설명한 대로 크게 1단계: 어텐션 연산과 2단계: FFN 연산으로 나뉩니다.

🧠 1단계: 어텐션(Attention) 연산

이 단계의 목표는 16개 GPU를 모두 활용하여 거대한 KV 캐시를 효율적으로 읽고 어텐션 연산을 수행하는 것입니다.

GPU 구성 및 데이터 분할 (자르기) ✂️

16개의 GPU는 어텐션 연산을 위해 두 가지 병렬화 방식의 조합으로 구성됩니다.

  • 어텐션 텐서 병렬화 (TPA): KV 헤드를 분산시킵니다. TPA는 KV 헤드 수(K)보다 클 수 없습니다. 여기서는 TPA = 8로 설정하여 8개의 KV 헤드를 8개의 GPU 그룹에 각각 할당합니다.
  • KV 병렬화 (KVP): KV 캐시의 시퀀스(길이)를 분산시킵니다. 전체 GPU 수 N = TPA * KVP 공식에 따라 16 = 8 * KVP 이므로, KVP = 2가 됩니다.

이 구성을 통해 16개 GPU는 8x2 형태의 논리적 그리드(Grid)를 형성합니다.

  • KV 캐시 분할 방식:
    • 헤드 분할 (TPA=8): 8개의 KV 헤드가 8개의 TP Rank에 걸쳐 1개씩 분할됩니다.
    • 시퀀스 분할 (KVP=2): 수백만 토큰 길이의 전체 KV 캐시 시퀀스가 2개의 KVP Rank에 걸쳐 절반으로 나뉩니다. 예를 들어 100만 토큰 컨텍스트라면, 50만 토큰씩 두 그룹으로 잘립니다.
    • 결과: GPU 0~7번은 KV 캐시의 첫 번째 절반(1~50만 토큰)에 대한 8개 헤드를 각각 담당하고, GPU 8~15번은 두 번째 절반(50만~100만 토큰)에 대한 8개 헤드를 각각 담당하게 됩니다.
  • 입력 토큰(Query) 처리:
    • 새롭게 생성될 토큰의 입력(Query)은 16개 모든 GPU에 동일하게 복제/브로드캐스트됩니다.

연산 및 통신 과정 ⚡

  1. 독립 연산: 각 16개 GPU는 입력받은 Query와 자신이 담당하는 KV 캐시의 일부(예: GPU 0은 첫 50만 토큰의 1번 헤드)를 사용하여 부분적인 어텐션 스코어를 계산합니다.
  2. All-to-All 통신: 시퀀스를 나눠 가졌으므로 완전한 어텐션 결과를 위해 KVP Rank 간 데이터 교환이 필요합니다. TPA=8 그룹 내에서, KVP Rank 0(GPU 0~7)과 KVP Rank 1(GPU 8~15)은 서로의 부분 어텐션 결과를 교환합니다.
  3. 결과 통합: 각 GPU는 통신으로 받은 부분 결과와 자체 계산 결과를 합쳐서 최종 어텐션 출력을 완성합니다.

이 방식을 통해 거대한 KV 캐시가 16개 GPU에 완벽하게 분산되어 메모리 병목 현상이 크게 완화되고, KV 캐시 복제 문제도 발생하지 않습니다.

⚙️ 2단계: FFN(Feed-Forward Network) 연산

어텐션 연산이 끝나면, 16개 GPU는 즉시 FFN 연산을 위해 재구성됩니다.

GPU 구성 및 데이터 분할 (자르기) ✂️

  • FFN 텐서 병렬화 (TPF): 1단계의 8x2 그리드 구성은 사라집니다. 이제 16개 GPU 전체가 하나의 거대한 텐서 병렬화 그룹으로 동작합니다. 즉, TPF = 16이 됩니다.

  • FFN 가중치 분할 방식:

    • Llama 3 70B의 거대한 FFN 계층 가중치 행렬(예: $W_{FC1}, W_{FC2}$)들이 16개로 분할됩니다.
    • 예를 들어, 첫 번째 FFN 행렬은 열(column)을 기준으로 16개로 잘리고, 두 번째 FFN 행렬은 행(row)을 기준으로 16개로 잘립니다.
    • 각 GPU는 전체 FFN 가중치의 1/16만을 보유하게 됩니다.

연산 및 통신 과정 ⚡

  1. 분산 연산: 1단계에서 나온 어텐션 출력값이 FFN의 입력으로 들어갑니다. 각 GPU는 자신이 가진 1/16의 가중치 조각을 사용하여 행렬 곱셈을 수행하고, 부분적인 FFN 연산 결과를 생성합니다.
  2. All-Reduce 통신: 16개 GPU 전체가 참여하는 All-Reduce 통신이 발생합니다. 각 GPU가 계산한 16개의 부분 결과들이 이 통신을 통해 모두 합산됩니다.
  3. 최종 결과: All-Reduce가 끝나면, 해당 레이어의 최종 출력값이 완성되고, 이 값은 다음 트랜스포머 레이어의 입력으로 전달됩니다.

이처럼 Helix Parallelism은 각 연산 단계의 특성에 맞춰 GPU의 역할과 데이터 분할 방식을 동적으로 변경함으로써, 16개의 GPU 자원을 한순간도 낭비 없이 최대한 효율적으로 활용하여 빠른 디코딩 속도를 달성합니다.

구현 및 자원

"핵심 소프트웨어 의존성(예: CUDA, MPI, 특정 라이브러리)은 무엇인가? 학습 및 추론 중 예상되는 메모리 점유량(GPU의 경우 VRAM, CPU의 경우 RAM)은 얼마인가? 명시된 하드웨어에서의 처리량(throughput)은 얼마인가(예: images/sec, tokens/sec)? 총 연산 비용(예: 총 FLOPs 또는 Petaflop-days)에 대한 상세한 내역을 제공해 줘."

요점만 먼저 *PyTorch 2.3 + CUDA 12.4 / NCCL 2.20 환경에서 Llama-3 70B를 Helix(8-way TP × 4-way KVP = 32 GPU)로 디코딩할 경우, GPU당 VRAM 요구량 ≈ 6 GB(가중치 ≈ 4.4 GB + KV 캐시 ≈ 0.3 GB + 여유 ≈ 1 GB), 클러스터-총 추론 처리량은 ≈ 9.6 × 10⁴ tok s⁻¹(Helix 미적용 대비 ≈ 4 배)이다. 전체 학습은 6.3 × 10²⁴ FLOPs(≈ 7.3 × 10⁴ PF-day)가 소요되며, 64 × H100 FP8 기준 학습 스루풋은 9.5 × 10⁴ tok s⁻¹에서 32 GPU로 선형 축소 시 ≈ 4.8 × 10⁴ tok s⁻¹ 수준이다.(llm-tracker.info, github.com, perplexity.ai, catalog.ngc.nvidia.com, factorialfunds.com)

1. 핵심 소프트웨어/런타임 스택

계층 권장 버전·라이브러리 비고
CUDA / 드라이버 CUDA 12.4+, NVIDIA 535.xx FP4/FP8 매트릭스 코어 지원
통신 NCCL 2.20+ (P2P + NVLink All-to-All), 옵션 MPI-4.1 Helix HOP-B의 비차단 All-to-All
DL 프레임워크 PyTorch 2.3 LTS FlashAttention v3 커스텀 op 내장
Helix 커널 helix_kv_all2all.cu (LSE 재조합) Triton 2.2로도 JIT 가능
기타 FlashAttention-2.4, xFormers 0.0.47, Triton 2.2, CuBLAS-Lt  

2. 메모리 프로파일 (FP4 추론·BF16 학습)

항목 계산식 (70 B params, 64 Q / 8 KV heads) 추론 (Helix 32 GPU) 학습 (Adam, 32 GPU)
모델 가중치 70 B × 2 B / 32 4.4 GB 4.4 GB
옵티마이저 상태 — — 70 B × 6 B / 32 ≈ 13 GB
활성화/미세 배치 경험적 ≈ 1.5 GB 1.5 GB > 10 GB (activation + recompute)
KV 캐시 (128 k tok) → 39 GB/seq (FP16) → 9.8 GB(FP4) (1/32 저장)(github.com) 0.31 GB —
총 VRAM / GPU   ≈ 6 GB ≈ 28 GB

Helix의 8 TP × 4 KVP 분할 덕분에 KV 캐시 복제량을 32 분의 1로 줄여 대역·메모리 양쪽 부담을 크게 경감한다.

3. 처리량 & 지연

시나리오 구성 TTL / tok (↓) tok s⁻¹ GPU⁻¹ tok s⁻¹ (32 GPU)
추론·TP 8 (기준) 8 GPU, TP = 8 11 ms 90 ~2.9 k
Helix (8 TP × 4 KVP) 32 GPU 9.7 ms (1.13 × ↓) 360 (≈ 4 ×↑) ~9.6 × 10⁴
학습 64 GPU NGC FP8 recipe (TP-4·PP-4) — 1.5 k 9.5 × 10⁴ (catalog.ngc.nvidia.com)
학습 32 GPU (추정) 선형 스케일 — 0.75 k 4.8 × 10⁴

추론 수치는 H100 FP8 실측(767 tok s⁻¹/ GPU) 대비 Helix 4 × 개선폭 가정(perplexity.ai).

4. 연산량 & 비용

항목 식 값
학습 FLOPs 6 · N · D (N = 70 B, D = 15 T 토큰)(factorialfunds.com) 6.3 × 10²⁴ FLOPs
PF-day 환산 FLOPs / (10¹⁵·86 400) ≈ 7.3 × 10⁴ PF-day
전력 예상 32 × H100 (≈ 700 W) · 학습 기간 (162→81 days @64→32GPU) ≈ 43 MWh

정리 포인트

  1. Helix 2-D 샤딩 덕분에 32 × H100만으로도 Llama-3 70B 128 k-ctx 디코딩이 VRAM 6 GB 수준으로 실현된다.
  2. 추론 처리량은 동일 지연 예산에서 약 4 × 증가하며, KV 캐시 트래픽이 병목인 환경일수록 Helix 효과가 커진다.
  3. 학습은 여전히 거대-스케일(≈ 7 × 10⁴ PF-day) 과제를 요구하므로, FP8·ZeRO-3·NVLink NVSwitch 등 병렬화 최적화가 필수이다.

평가 및 지표

"평가를 위한 주요 지표는 무엇인가: 지연 시간(latency), 처리량(throughput), 전력 소비, 또는 비용 대비 성능? 시스템은 더 많은 데이터, 사용자, 또는 컴퓨팅 노드에 따라 어떻게 확장되는가?"

결론 (압축 요약)

Helix 평가는 **토큰-간 지연 (TTL), GPU-당 토큰 처리량, 동시 배치 규모, J · token⁻¹(전력 효율), 원 · 10⁶ tokens⁻¹(비용 효율)**을 핵심 지표로 삼는다. 이 지표들은 KV 길이 S·배치 B·GPU 수 G 변화에 따라 서로 다른 법칙으로 스케일하며, Helix는 S와 KVP·TP에 의해 선형 또는 상수 규모로 확장되어 기존 TP/PP보다 우월한 Pareto 곡선을 형성한다.

1 | 주요 평가 지표 정의 & 측정 단위

지표 정의 측정 단위 Helix-관련 특징
TTL
(Token-to-Token Latency)		 새 토큰 생성 완료까지의 시간 ms · token⁻¹ Helix 32 GPU에서 Llama-3 70B 9.7 ms(기존 11 ms) → 1.13 × ↓
Throughput/GPU 1 GPU가 생성하는 토큰률 tokens · s⁻¹ · GPU⁻¹ Helix = 360 tok s⁻¹ vs TP8 = 90 tok s⁻¹ → 4 × ↑
Batch Scalability 주어진 TTL 한도에서 유지 가능한 동시 시퀀스 수 배치 수 DeepSeek-R1 기준 32 × ↑, Llama-405B 4 × ↑
Energy Efficiency 전력 소모/생성 토큰 J · token⁻¹ KV 복제 제거 + 통신 은닉 → GPU 유휴 ↓, ~30 % J · token⁻¹ ↓ (모델·온도·S에 따라)
Cost Efficiency 계산/전력 비용 ÷ 생성 토큰 원 · 10⁶ tokens⁻¹ 처리량 4 × 증가, 전력 1.3 × 증가 가정 → 비용/토큰 ≈ 0.33 ×
관계식   인터랙티비 = 1 / TTL; System TPS = Throughput/GPU × G; J · token⁻¹ ∝ (PGPU × TTL) / tokens.

2 | 스케일링 법칙 (Helix vs 전통 TP/PP)

2-1 컨텍스트 길이 S 증가

통신량 ∝ B · H (Helix) ≠ S → KV 캐시 읽기 ∝ S / KVP. 따라서 KVP를 S에 맞춰 확장하면 DRAM 대역·TTL이 거의 선형 유지, 기존 TP(전 KV 복제)보다 O(S)→**O(S / KVP)**로 완화.

2-2 동시 사용자 B 증가

TTL은 통신 오버랩(HOP-B) 덕분에 B가 메모리 한계에 닿을 때까지 완만 증가. Throughput ≈ B / TTL → Helix의 Batch cap이 4–32 × 더 크므로 동일 TTL 예산 내 동시 사용자 수 ↑.

2-3 GPU 수 G 확장

Helix는 2-D 그리드(TP × KVP)로 확장:

\[G = \text{TP} \times \text{KVP},\quad \text{KV duplication} = \frac{\text{TP}}{K},\quad \text{FFN 로드/ GPU} \propto \frac{1}{\text{TP}}\]
  • G ≤ K: KV 중복이 없으므로 Helix 이득 ↓, TP만으로 충분.
  • G ≫ K: Helix가 KV 중복 0 % + FFN 분산 모두 확보 → TTL ↘, Throughput ↗.
  • 다중 노드(PCIe/InfiniBand): All-to-All lat ↑; HOP-B 은닉률 ↓ → 이득폭이 통신-대역에 선형 의존. (후속 연구 과제)

3 | 전력·비용 지표 계산 예시 (32 × H100, 700 W/GPU)

항목 Helix TP8 비고
시스템 전력 22 kW 5.6 kW GPU 수 차이
TPS (system) 9.6 × 10⁴ 2.9 × 10³ 4 × tok s⁻¹ · GPU⁻¹
J · token⁻¹ 2.3 J 6.8 J ×0.34
원 · 10⁶ tok⁻¹* 78 ₩ 233 ₩ 60 ₩ kWh, 1 k tok = 1 s

*전력만 포함한 단순 환산·예시.

4 | 핵심 시사점

  1. 지연 (TTL)·처리량·전력/비용 세 지표가 Pareto 관계. Helix는 KV·FFN 이중 병목을 제거해 이 세 축을 동시 개선.
  2. 확장성은 **“TP > K일 때 KV 중복이 폭증한다”**는 기존 TP의 약점을 KVP로 상수화하면서 확보된다.
  3. 다중 노드·희소 어텐션·저정밀 FP4/FP8 외삽 시 실제 이득폭은 통신 토폴로지·정밀도·SLA에 따라 재평가해야 한다—이는 저자·후속 연구가 제시한 핵심 오픈 문제이다.

Related Posts