NVIDIA Groq 3 LPX: 우리가 알고 있는 모든 것 - StorageReview.com

LPU(언어 처리 장치)는 Groq, Inc.에서 설계 및 제작한 맞춤형 AI 추론 가속기입니다. 2016년 구글 출신 엔지니어이자 TPU의 초기 발명가 중 한 명으로 알려진 조너선 로스가 설립한 Groq는 수년간 결정론적 소프트웨어 정의 프로세서 아키텍처를 처음부터 개발해 왔습니다. 동적 하드웨어 스케줄링과 다단계 캐시 계층 구조에 의존하는 GPU와 달리, LPU는 근본적으로 다른 접근 방식을 취합니다. 모든 반응형 하드웨어 구성 요소를 제거하고 전체 제어 평면을 컴파일러에 배치하여 클럭 사이클 단위까지 완벽하게 예측 가능한 실행을 가능하게 합니다. 작년 12월, NVIDIA는 Groq를 인수하여 LPU 아키텍처를 NVIDIA 산하로 편입시켰습니다. 이 인수는 업계에서 엄청난 호응을 얻었으며, NVIDIA가 Groq 기술을 자사의 데이터 센터 생태계에 어떻게 통합할지에 대한 즉각적인 추측을 불러일으켰습니다. 마침내 GTC 2026에서 NVIDIA는 Vera Rubin 플랫폼의 일곱 번째 칩인 Groq 3 LPX를 공개하며 이러한 질문에 대한 답을 제시했습니다. Groq 3 LPX는 Vera Rubin NVL72와 함께 랙 스케일 시스템에 256개의 LPU 가속기를 탑재한 제품입니다. 작년 AI 인프라 서밋에서 NVIDIA는 장기 컨텍스트 추론 쿼리 가속을 위해 설계된 몇 가지 구성의 CPX 랙을 발표했습니다. 당시 발표를 처음 접했을 때, CPX의 실제 기능에 대한 몇 가지 의문이 제기되었습니다. 언뜻 보기에는 흥미로운 아키텍처 개념이었지만, CPX는 어텐션 연산 가속을 제외하고는 Rubin GPU 자체보다 실질적으로 나은 기능을 제공하는 것처럼 보이지 않았습니다. 그러던 중 Groq 인수 소식이 전해지면서 NVIDIA가 Groq의 LPU 기술을 Vera Rubin 플랫폼에 어떻게 통합할지에 대한 추측이 촉발되었습니다. NVIDIA는 GTC 2026에서 LPX를 발표하며 궁금증을 해소했습니다. 발표 내용을 보면, 기존 CPX 랙 컨셉이 Groq 3 LPX 랙으로 진화했으며, CPX의 컨텍스트 처리 중심 설계는 Groq 실리콘 기반의 디코딩 가속 아키텍처로 완전히 대체된 것으로 보입니다. LPX 랙은 완전 액체 냉각 방식을 채택하고 MGX 인프라를 기반으로 구축되었으며, Vera Rubin의 본격적인 출시와 동시에 2026년 하반기에 출시될 예정입니다. NVIDIA는 이 새로운 제품을 통해 메가와트당 추론 처리량이 최대 35배 향상되고, 수조 개의 파라미터를 가진 모델에서 최대 10배의 수익 창출 기회를 제공할 수 있다고 주장합니다. 하지만 더 중요한 것은 NVIDIA가 LPU가 Vera 및 NVL72 플랫폼에서 실행되는 기존 CUDA 스택 내에서 가속기 역할을 하며, 토큰 단위로 연산이 투명하게 오프로드된다는 사실을 확인했다는 점입니다. GTC 질의응답에서 NVIDIA는 LPU를 "디코딩 모델 부스터"라고 설명하며, 차세대 프리미엄 모델 서빙을 구현하기 위해 수조 개의 매개변수를 가진 모델을 배포하는 AI 연구소 및 최첨단 모델 개발자들과 긴밀히 협력할 것이라고 밝혔습니다. CPX에 대한 의문이 해결되었으니, 자연스럽게 다음 질문은 NVIDIA가 랙 규모의 시스템 전체를 구축하는 데 사용하는 이 LPU가 정확히 무엇인가 하는 것입니다. LPU는 본질적으로 매우 큰 벡터 프로세서입니다. 연산과 통신의 기본 단위는 320개의 요소로 구성된 벡터이며, 이는 INT8 형식으로 320바이트, FP16 형식으로 640바이트로 이루어져 있습니다. 칩에서 수행되는 모든 연산, 즉 산술 연산, 메모리 접근, 데이터 재구성, 칩 간 데이터 전송 등은 모두 이러한 고정 크기 벡터를 기반으로 이루어집니다. 이 아키텍처는 단일 기본 구성 요소인 SIMD 기능 장치와 경량 명령어 디스패치 장치를 기반으로 구축됩니다. Groq는 이를 기본 클래스로 취급하며, 각 클래스는 특정 연산 범주에 최적화되어 네 가지 유형으로 특화됩니다. 매트릭스 실행 모듈(MXM): 이 핵심 연산 장치는 행렬-벡터 및 행렬-행렬 연산을 위한 고밀도 곱셈-누적 기능을 제공합니다. NVIDIA의 LPX 랙에 탑재된 8개의 Groq 3 LP30 칩 각각은 칩당 1.2 PFLOPS의 FP8 연산 성능을 제공하며, LPX 트레이 전체에서는 총 9.6 PLOPS의 FP8 연산 성능을 발휘합니다. 벡터 실행 모듈(VXM): 점별 산술 연산, 논리 연산, 형 변환 및 활성화 함수를 처리합니다. VXM에는 컴파일러가 자동으로 연결하여 복합 연산(예: 축소, 편향 추가, 활성화, 형 변환)을 단일 패스로 구성하는 ALU 배열이 포함되어 있습니다. 스위치 실행 모듈(SXM): 벡터의 순열, 회전, 분산 및 전치를 포함한 구조화된 데이터 이동을 수행합니다. 메모리 단위(MEM): 캐시, 계층 구조, 캐시 미스 개념이 없는 평면형 SRAM 우선 메모리 아키텍처를 채택한 Groq 3 LP30은 150TB/s의 대역폭으로 500MB의 온칩 SRAM을 제공합니다. 컴파일러는 프로그램 실행 전반에 걸쳐 모든 데이터의 정확한 위치를 파악하여 물리적 뱅크 위치를 직접 참조합니다. 각 기능 단위 유형의 여러 복사본이 칩의 수평 방향으로 찍어져 있습니다. 명령어는 위아래에서 중앙으로 흐르고, 데이터 흐름은 동서 방향으로 흐르면서 기능 단위들을 교차하여 연산을 수행합니다. LPU의 기능 장치 간 통신은 의도적으로 단순화된 1차원 상호 연결 방식인 스트림 레지스터를 통해 이루어집니다. 통신 경로는 동쪽 방향과 서쪽 방향으로 각각 하나씩 총 두 개가 있으며, 각 스트림 레지스터는 단일 홉을 나타냅니다. 데이터는 클록 사이클당 정확히 한 홉씩 이동하므로 컴파일러는 칩 레이아웃 상의 물리적 위치를 기준으로 간단한 덧셈 또는 뺄셈 연산을 수행하여 두 기능 장치 간의 이동 시간을 계산할 수 있습니다. 상호 연결 내에는 대기열이나 경합 메커니즘이 없습니다. 따라서 스케줄링 문제는 복잡한 2차원 빈 패킹 문제에서 훨씬 다루기 쉬운 1차원 문제로 단순화됩니다. Groq의 최고 설계자인 이고르 아르소프스키는 이를 다음과 같이 설명합니다. 가장 좋은 점은 컴파일러가 10 사이클 후에 데이터가 정확히 어디에 있을지 정확히 알 수 있다는 것입니다. 왜냐하면 데이터가 정확히 10홉 거리에 있기 때문입니다. 모호함도 없고, 추측도 없으며, 하드웨어가 독립적으로 라우팅 결정을 내릴 필요도 없습니다. LPU의 가장 큰 특징은 결정성입니다. 동적 스케줄링, 캐시 동작, 메모리 접근 경합 등으로 인해 런타임 변동성이 발생하는 기존 프로세서와 달리, LPU는 변동성이 전혀 없이 실행되며 모든 기능 단위가 완벽하게 동기화되어 작동합니다. 이러한 결정론은 하드웨어 인터록과 같은 기능을 제거하고 모든 의사 결정을 컴파일러로 옮김으로써 달성됩니다. 하드웨어는 단순히 결과로 나온 스케줄을 실행하기만 합니다. 이 접근 방식의 또 다른 이점은 모든 것이 정확히 동일한 지연 시간으로 작동하고, 심지어 전력 소비량까지 모든 시점에서 예측 가능하다는 것입니다. Groq의 TruePoint 기술을 통해 수치 영역에서도 결정론적 특성이 구현됩니다. 이 기술은 아키텍처의 연산 순서 보장을 통해 320개 요소의 융합 내적과 단일 반올림 단계를 거쳐 FP16 입력에서 FP32 수준의 정확도를 달성합니다. LLM 추론에서 수치적 결정론이 중요한 이유와 비결정론적 하드웨어가 실행마다 미묘하게 다른 출력을 생성하는 이유에 대한 자세한 내용은 Thinking Lab의 백서에서 확인할 수 있습니다. LLM 추론에서 비결정론 극복하기이는 이 글의 주요 내용은 아니지만, 수치 정확도에 미치는 영향에 관심 있는 독자는 글 말미에 링크된 Groq의 TruePoint 기술 문서에서 관련 분석을 찾아볼 수 있습니다. 가장 간단하게 설명하면, LPU 간의 데이터 이동은 조립 라인과 유사합니다. 시스템용 모델이 컴파일될 때, 컴파일러는 모델을 여러 단계로 분할하고 각 단계를 LPU 칩 그룹에 공간적으로 매핑합니다. 각 그룹은 필요한 가중치 매개변수를 온칩 SRAM에 저장합니다. 추론 과정에서 칩 그룹 간에 이동하는 데이터는 이전 단계의 중간 활성화 출력뿐입니다. 데이터는 마치 컨베이어 벨트를 따라 이동하는 제품처럼 칩에서 칩으로 흐르며, 각 스테이션은 할당된 계산을 수행하고 결과를 다음 스테이션으로 전달합니다. 이는 각 계산 단계에서 오프칩 HBM 메모리에서 전체 가중치 세트를 가져와 결과를 다시 저장해야 하는 GPU와는 근본적으로 다릅니다. LPU에서는 가중치가 이미 각 스테이션의 SRAM에 상주하고 있으므로 활성화 텐서만 이동합니다. 토폴로지 세부 사항을 살펴보기 전에 혼동을 일으킬 수 있는 부분을 명확히 하는 것이 중요합니다. LPX 시스템 전체에 사용되는 칩 간(C2C) 링크는 Groq의 RealScale C2C 인터커넥트입니다. 이는 NVIDIA 생태계의 다른 곳에서 사용되는 NVIDIA의 C2C 기술과는 다릅니다. 두 기술은 아키텍처적으로 완전히 별개입니다. LPX 랙의 모든 C2C 연결은 트레이 내부, 스파인을 통한 트레이 간 연결, 또는 전면 패널 포트를 통한 랙 간 연결 등 모든 경우에 RealScale을 사용합니다. 이는 Groq가 최초의 GroqNode부터 사용해 온 기본 상호 연결 기술로, 링크 속도만 (레인당 30Gbps에서 112Gbps로) 확장되었을 뿐 아키텍처는 변경되지 않았습니다. 참고: 다음 섹션에서 설명하는 연결 방식은 Groq의 문서(마지막에 링크되어 있음)를 바탕으로 저희가 이해한 아키텍처를 기반으로 합니다. NVIDIA 블로그 게시물그리고 GTC 부스에서 제공받은 랙에 대한 설명은 다음과 같습니다. Groq 네트워크 토폴로지의 기본 구성 요소는 최초의 GroqNode에서 NVIDIA Groq 3 LPX로 변경되지 않았습니다. 각 1U 컴퓨팅 트레이에는 정확히 8개의 LP30 칩이 포함되어 있으며, 이 칩들은 완전 그래프(all-to-all) 방식으로 촘촘하게 상호 연결되어 모든 칩이 동일한 속도로 다른 모든 칩과 직접 통신할 수 있습니다. 각 LP30 칩에는 96개의 C2C 링크가 있으며, 각 링크는 112Gbps의 속도로 작동하여 칩당 2.5TB/s의 양방향 대역폭을 제공합니다. 8개의 칩으로 구성된 전체 그래프에서 각 칩은 7개의 이웃 칩을 갖습니다. 트레이 내에서 고유한 칩 간 연결의 수는 C(8,2) = 28개입니다. 각 칩의 96개 링크 중 일부는 이러한 트레이 내 모든 칩 간 연결에 사용되고, 나머지 링크는 백플레인(랙 스파인용)과 프런트 패널(랙 간 연결용)로 연결됩니다. NVIDIA에서 발표한 사양에 따르면 트레이당 총 확장 대역폭은 20TB/s이며, 이는 트레이 내 및 스파인 대역폭을 합한 값입니다. 이를 검증해 보면, 각 트레이에는 8개의 칩 × 96개의 링크 = 총 768개의 링크가 있습니다. 프런트 패널의 랙 간 연결 레인 32개를 제외하면 확장에 사용할 수 있는 링크는 736개입니다. 링크당 112Gbps라고 가정하면, 총 736 × 112Gbps = 82,432Gbps, 즉 방향당 약 10.3TB/s의 대역폭이 필요하며, 양방향으로는 약 20.6TB/s에 해당합니다. 이는 NVIDIA가 제시한 트레이당 20TB/s라는 수치와 잘 부합합니다. 이 8개 칩으로 구성된 전체 연결 그룹은 드래곤플라이 네트워크 토폴로지의 "로컬 그룹"을 형성합니다. 기존 GroqChip 1은 카드당 11개의 C2C 링크를 가지고 있었으며, 각 링크는 레인당 30Gbps(링크당 4개 레인)의 속도를 제공하여 카드당 총 330GB/s의 대역폭을 지원했습니다. Groq 3 LP30은 112Gbps 속도의 96개 링크를 통해 동일한 토폴로지 구조를 유지하면서 칩당 I/O 대역폭을 획기적으로 향상시켰습니다. 단일 LPX 랙 내에서 32개의 컴퓨팅 트레이(총 256개의 칩)는 백플레인의 4개 ETL 스파인을 통해 상호 연결됩니다. 이 스파인들은 트레이 간 RealScale C2C 트래픽을 전송하여 랙 규모의 확장 도메인을 구축합니다. 전체 랙의 총 확장 대역폭은 640TB/s(32개 트레이 × 트레이당 20TB/s)입니다. 4개의 스파인 각각은 약 160TB/s의 양방향 대역폭을 처리합니다. 각 1U 컴퓨팅 트레이는 전면 패널에 4개의 QSFP C2C 포트를 제공하여 랙 간 통신을 위한 총 32개 레인(포트당 8개 레인)을 제공합니다. 이 포트들은 대칭적인 패턴으로 인접한 랙에 연결됩니다. 즉, 2개의 포트(16개 레인)는 왼쪽 인접 랙에, 2개의 포트(16개 레인)는 오른쪽 인접 랙에 연결됩니다. 각 U 위치는 인접한 랙의 해당 U 위치에 연결됩니다(랙 A의 첫 번째 U는 랙 B의 첫 번째 U에, 두 번째 U는 두 번째 U에 연결되는 식입니다). 각 트레이의 32개 랙 간 레인은 레인당 112Gbps의 속도를 제공하며, 총 3,584Gbps, 즉 트레이당 양방향으로 약 448GB/s의 랙 간 대역폭을 제공합니다. 전체 랙을 고려하면 32개의 트레이는 32 × 32 = 1,024개의 랙 간 레인을 제공합니다. 이는 1,024 × 112Gbps = 114,688Gbps, 즉 인접한 각 랙으로 양방향으로 약 14.3TB/s의 대역폭을 제공한다는 것을 의미합니다(좌측 및 우측 이웃에 각각 약 7.2TB/s씩 균등하게 분배). 설계상 랙 간 대역폭은 랙 내 대역폭보다 희박합니다. 랙 내부에서는 640TB/s의 확장 도메인이 스파인을 통해 모든 랙에 대한 조밀한 연결성을 제공합니다. 랙 간에는 프런트 패널 링크가 드래곤플라이 토폴로지의 희박한 글로벌 연결을 제공합니다. 이는 기존 GroqRack과 동일한 아키텍처 패턴으로, 칩당 4개의 외부 C2C 링크가 로컬 그룹(노드)을 연결하여 네트워크 직경이 낮은(264개 칩 배포 시 최대 3홉) 멀티랙 시스템을 구성합니다. 기존 4개 랙으로 구성된 GroqRack에는 264개의 GroqChip 프로세서가 탑재되었습니다. 단일 LPX 랙에는 256개의 LP30 칩이 MGX ETL 랙 하나에 집적되어, 액체 냉각 및 무선 백플레인을 갖춘 단일 랙 폼팩터에 약 4배 높은 칩 밀도를 구현했습니다. 8개 칩으로 구성된 전체 네트워크 로컬 그룹, 드래곤플라이 토폴로지, 소프트웨어 스케줄링 기반 라우팅 방식은 모두 그대로 유지됩니다. Groq 네트워킹의 기본 기술은 변경되지 않았으며, 단지 확장성만 향상되었습니다. 단일 랙의 SRAM 용량(256개 칩에 걸쳐 총 128GB)을 초과하는 모델의 경우, 전면 패널의 C2C 포트를 통해 여러 개의 LPX 랙 또는 랙 열을 상호 연결하여 조립 라인을 확장할 수 있습니다. 실제 모델 크기에 미치는 영향에 대한 자세한 내용은 다음 섹션에서 설명합니다. NVIDIA가 LPX로 어떤 작업을 오프로드하는지, 그리고 그 이유를 구체적으로 살펴보기 전에, NVIDIA가 지적했듯이 이러한 아키텍처적 결정이 필요한 더 넓은 추세를 이해하는 것이 도움이 됩니다. AI 추론은 단일하고 균일한 워크로드가 아닙니다. 단일 요청 내에서도 사전 채우기 단계(프롬프트 입력 및 키-값 캐시 구축)와 디코딩 단계(토큰을 하나씩 생성)는 하드웨어에 매우 다른 요구 사항을 부과하며, 이러한 요구 사항은 배치 크기, 컨텍스트 길이 및 모델 구조에 따라 달라집니다. 모델이 더 긴 추론 출력과 다단계 사고 과정을 생성함에 따라, 각 요청에서 순차적인 디코딩 단계로 넘어가는 비중이 점점 커지고 있습니다. 동시에, 접두사 캐싱과 같은 기술은 요청 간에 공유되는 프롬프트 상태를 재사용하여 사전 채우기 비용을 줄여주지만, 이는 디코딩 비용을 상대적으로 더욱 두드러지게 만듭니다. 컨텍스트 윈도우 또한 수십만 개의 토큰으로 커지면서 어텐션 연산 중 메모리 대역폭에 대한 부담이 가중되고 있습니다. 에이전트 기반 워크플로우에서는 여러 모델 호출, 도구 상호 작용, 검증 루프에 걸쳐 지연 시간이 누적됩니다. 이러한 누적 효과로 인해 디코딩 지연 시간이 사용자가 체감하는 병목 현상이 되고 있으며, 단순히 최대 총 처리량에 최적화된 하드웨어는 각 개별 요청에 대해 빠르고 예측 가능한 토큰 생성이 필요한 워크로드에 항상 최적의 선택은 아닙니다. 또한, 다음과 같이 볼 수 있습니다. Anthropic의 빠른 모드 릴리스 속도 향상, 지연 시간 단축 및 토큰 처리량 증가는 더 높은 수익을 창출하며, Anthropic의 빠른 추론 서비스는 일반 요청보다 6배 더 비쌉니다. 이번 LPX 발표를 통해 NVIDIA는 가장 큰 디코딩 병목 현상인 피드포워드 네트워크(FFN) 레이어를 LPU로 넘기려는 의도를 알 수 있습니다. FFN이 목표인 이유와 그 의미를 가늠하기 위해 현재 가장 인기 있는 오픈 소스 모델들의 FFN 파라미터 수를 분석해 보았습니다. 모든 트랜스포머 레이어는 크게 두 가지 주요 블록으로 구성됩니다. 바로 어텐션 블록과 피드포워드(FFN) 블록입니다. 어텐션 블록은 토큰들이 시퀀스 내의 다른 토큰들의 정보를 참조하고 결합할 수 있도록 합니다. FFN 블록은 각 토큰에 대해 독립적으로 작동합니다. 토큰의 표현을 더 높은 차원의 공간으로 투영하고, 비선형 변환을 적용한 후, 다시 원래 차원으로 투영합니다. FFN 블록은 모델의 지식 저장소라고 생각할 수 있으며, 사실적 연관성과 학습된 변환 정보가 저장되는 곳입니다. MoE(Mixture of Experts) 아키텍처는 DeepSeek R1, Kimi K2, Qwen3-235B, GLM-5, MiniMax M2.5, OpenAI의 GPT-OSS 120B 등 오늘날 주요 오픈 소스 대규모 언어 모델에서 지배적인 아키텍처로 자리 잡았습니다. 이러한 MoE 모델에서 FFN 블록은 수백 개의 더 작은 독립 복사본(전문가)으로 복제되는 반면, 어텐션은 공유됩니다. 경량 학습 라우팅 함수는 토큰 단위로 활성화할 전문가의 하위 집합을 동적으로 선택합니다. 결과적으로 모델은 엄청난 수의 전체 파라미터를 저장하지만 토큰당 일부만 활성화하여 비례적인 컴퓨팅 비용 증가 없이 규모의 이점을 누릴 수 있습니다. 하지만 아시다시피, 이는 또 다른 문제를 야기합니다. FFN 레이어가 모델 가중치의 대부분을 차지한다는 점입니다. 특히 MoE 모델의 경우, 모델 가중치의 최대 90%에 달할 수 있습니다. 예를 들어 DeepSeek R1 모델을 자세히 살펴보겠습니다. 이 모델은 은닉 차원(H)이 7,168인 61개의 Transformer 레이어로 구성되어 있습니다. 처음 3개의 레이어는 표준 밀집 FFN을 사용하고, 나머지 58개 레이어는 MoE를 사용합니다(추가로 전문가 영역을 가진 MTP 레이어 1개를 포함하여 총 59개의 MoE 레이어가 있습니다). 최신 LLM 모델은 SwiGLU라는 변형을 사용하는데, 이는 두 개가 아닌 세 개의 가중치 행렬을 사용합니다. 순방향 전달에서는 w2(SiLU(w1(x)) ⊙ w3(x))를 계산합니다. 여기서 w1(게이트 투영)과 w3(상향 투영)은 모두 은닉 차원을 H에서 중간 크기 I로 확장하고, w2(하향 투영)는 이를 다시 압축합니다. ⊙는 게이트 경로와 비게이트 경로 간의 요소별 곱셈을 나타냅니다. 이러한 행렬에는 바이어스 항이 없으므로 각 SwiGLU FFN 블록은 정확히 3 × H × I개의 파라미터를 포함합니다. DeepSeek R1의 밀집 레이어(처음 3개 레이어)의 경우 중간 차원은 18,432이므로 레이어당 3 × 7,168 × 18,432 = 3억 9,640만 개의 파라미터가 있습니다. MoE 레이어의 경우, 256개의 라우팅된 전문가 각각은 중간 차원이 2,048인 완전한 SwiGLU 블록이므로 각 전문가는 3 × 7,168 × 2,048 = 4,400만 개의 파라미터를 가집니다. 256개의 전문가를 곱하면 레이어당 라우팅된 전문가에만 112억 7천만 개의 파라미터가 있게 됩니다. 여기에 더해, 각 MoE 레이어에는 공유 전문가(모든 토큰에 대해 항상 활성화되는 동일한 4,400만 파라미터 SwiGLU 블록), 라우터 게이트(형태가 [256, 7168]인 선형 투영 = 180만 개의 파라미터), 그리고 라우팅 중 부하 분산을 위해 사용되는 256개의 FP32 값으로 구성된 작은 바이어스 벡터가 있습니다. 전체 FFN은 약 669.1억 개의 파라미터를 가지고 있습니다. FP8 E4M3 형식(가중치당 1바이트)으로 변환하면 약 623.1GB의 FFN 데이터가 됩니다. 이는 디스크 상의 모델 전체 크기 추정치의 97.7%에 해당합니다. 나머지 약 2.3%는 어텐션 가중치, 임베딩, 출력 헤드, 레이어 노름 및 FP8 스케일 메타데이터입니다. NVIDIA는 이제 디코딩 단계를 단일 작업이 아닌 토큰별로 반복되는 루프로 간주하며, 각 부분에서 서로 다른 하드웨어 병목 현상이 발생합니다. 사전 채우기 단계는 대용량 입력을 처리하고 키-값 캐시를 구축하는 작업이 주를 이루는데, 이 작업은 고밀도 병렬 컴퓨팅과 대용량 메모리를 활용하면 효율성을 극대화할 수 있습니다. Vera Rubin NVL72는 특히 프롬프트가 방대하고 가변적인 장문 컨텍스트 워크로드에서 이러한 작업을 효율적으로 처리합니다. 디코딩은 다릅니다. 새로운 토큰이 생성될 때마다 시스템은 누적된 전체 KV 캐시에 대해 어텐션 연산을 수행한 다음, 어텐션 출력에 대해 FFN/MoE 연산을 실행해야 합니다. NVIDIA의 어텐션-FFN 분해(AFD) 아키텍처에서는 이 두 단계가 두 개의 엔진으로 분리됩니다. Rubin GPU는 디코딩 어텐션을 처리합니다. HBM에서 KV 캐시를 읽고, 어텐션 점수를 계산하고, 중간 활성화 값을 생성합니다. 이 활성화 텐서(NVIDIA에서는 "중간 텐서 상태"라고 함)는 LPX로 전달되어, LPX는 매우 높은 대역폭과 결정론적 지연 시간으로 FFN 또는 MoE 전문가 연산을 실행한 후 결과를 GPU로 반환하여 토큰 생성을 계속합니다. 이러한 핸드오프는 모든 토큰에 대해 발생합니다. GPU와 LPU 간에 교환되는 활성화 텐서는 가중치 데이터에 비해 매우 작으며, 이는 LPU의 거의 제로에 가까운 오버헤드 네트워킹이 탁월한 성능을 발휘하는 영역과 정확히 일치합니다. 이러한 분할은 각 프로세서의 근본적인 강점을 활용합니다. GPU는 대용량 KV 캐시에서 가변 길이 어텐션에 필요한 HBM 용량과 유연한 실행을 제공하는 반면, LPU는 대역폭 제약이 있고 정적으로 스케줄링 가능한 FFN 가중치에 필요한 SRAM 대역폭과 결정론적 스케줄링을 제공합니다. 여기서 미묘하지만 중요한 확장성 특성을 언급할 필요가 있습니다. 컨텍스트 길이가 증가함에 따라 어텐션 연산에 필요한 컴퓨팅 및 메모리 요구 사항도 함께 증가합니다. KV 캐시는 컨텍스트 토큰이 추가될 때마다 선형적으로 확장되며, 각 새로운 디코딩 단계는 누적된 전체 캐시를 처리해야 합니다. 그러나 FFN은 컨텍스트 길이에 따라 전혀 증가하지 않습니다. FFN 가중치 행렬(SwiGLU의 w1, w2, w3)은 모델 아키텍처의 고정 상수입니다. 컨텍스트 길이가 1,000개 토큰이든 1,000,000개 토큰이든 크기가 동일하며, 각 토큰은 이 행렬을 독립적으로 통과합니다. 즉, AFD 아키텍처에서 컨텍스트 윈도우가 계속 증가함에 따라 GPU 측은 증가하는 비용(KV 캐시용 HBM 증가, 어텐션 연산 증가)을 흡수하는 반면, LPX 측은 완전히 고정된 상태를 유지합니다. 모델의 FFN을 처리하는 데 필요한 LPX 랙의 수는 서빙 구성의 컨텍스트 길이가 아니라 모델 아키텍처에 의해 전적으로 결정됩니다. 이 방식은 SRAM 전용 가속기의 가장 큰 문제점 중 하나였던, 증가하는 컨텍스트 요구 사항이 결국 고정된 온칩 메모리 용량을 초과하는 문제를 깔끔하게 해결합니다. AFD 분할 방식에서는 컨텍스트 종속적인 작업은 확장 가능한 HBM을 갖춘 하드웨어에 유지되고, LPU는 고정된 SRAM에 자연스럽게 저장되는 컨텍스트 독립적인 작업만 처리합니다. 이러한 2개 엔진 루프를 실제 운영 환경에서 작동시키려면 하드웨어만으로는 부족합니다. NVIDIA의 Dynamo 오케스트레이션 레이어가 이기종 디코딩을 실용화하는 핵심 요소입니다. Dynamo는 GPU 및 LPU 백엔드 전반에 걸쳐 분산된 서비스를 조정하고, AFD에 필요한 토큰별 분류, 라우팅 및 활성화 전송을 처리합니다. 실제로 Dynamo는 프리필(prefill) 처리를 GPU 워커에 할당하여 입력값을 처리하고 키-값 캐시(KV cache)를 구축합니다. 디코딩 과정에서 Dynamo는 AFD 루프를 조율합니다. GPU는 누적된 KV 캐시에 대해 어텐션(attention) 연산을 수행하고, 중간 활성화 값은 FFN/MoE 실행을 위해 LPU로 전달되며, 최종 출력은 토큰 생성을 계속하기 위해 GPU로 돌아갑니다. 결과적으로 두 개의 분리된 시스템이 아닌, 하나의 일관된 서비스 경로가 구현됩니다. Dynamo는 KV 인식 라우팅(관련 KV 캐시가 이미 있는 워커에 요청이 도달하도록 함), 지연 시간 목표 기반 스케줄링(대화형 세션이 긴 대기열에 들어가지 않도록 함), 그리고 오버헤드가 낮은 전송 관리 기능을 제공합니다. 이러한 기능은 가변적인 컨텍스트 길이, 혼합된 요청 유형, 그리고 급증하는 동시 접속이 발생하는 실제 운영 환경에서 오케스트레이션 계층이 테일 지연 시간을 안정적으로 유지하고 테넌트 간 지터로 인해 사용자 경험이 저하되는 것을 방지하는 데 중요합니다. 이제 LPX의 작동 방식과 해결하고자 하는 문제를 이해했으니, 하드웨어 요구 사항 측면에서 어떤 의미를 갖는지 살펴보겠습니다. 우리는 널리 사용되는 모델들에 대해 매개변수 개수와 디스크 상의 FFN 크기를 계산했습니다. config.json 모델.safetensors.index.json Huggingface에서 이용 가능합니다. | 모델 | FFN 매개변수 | FFN 크기(디스크 용량) | FFN % | D 타입 | 전문가 구성 | |---|---|---|---|---|---| | DeepSeek R1 및 DeepSeek V3.2 | 669.1B | 623.1 GB | 97.7% | FP8 | 256 | | 키미 K2 | 1.02T | 948.0 GB | 98.9% | FP8 | 384 | | 키미 K2.5 | 1.02T | 474.0 GB | 98.5% | INT4 | 384 | | 미니맥스 M2.5 | 224.7B | 209.3 GB | 97.7% | FP8 | 256 | | 오픈AI GPT-OSS 120B | 114.7B | 53.4 GB | 95.4% | MXFP4 | 128 | | GLM 5 | 738.1B | 1,374.8 GB | 98.0% | BF16 | 256 | | Qwen3 235B-A22B | 227.2B | 423.1 GB | 96.6% | BF16 | 128 | 이 패턴은 앞서 살펴본 내용을 다시 한번 확인시켜 줍니다. 분석 대상 모델 모두에서 FFN 파라미터가 디스크 상의 전체 모델 크기의 95%에서 99%를 차지합니다. 특히 Kimi K2는 레이어당 384명의 전문가가 연결되어 있어 FFN 파라미터 수가 1조 개를 넘고 전체의 거의 99%를 차지하는 가장 극단적인 사례입니다. 심지어 가장 작은 모델인 OpenAI의 GPT-OSS 120B(MXFP4에 저장된 128명의 전문가 사용)에서도 FFN이 전체의 95.4%를 차지합니다. 디스크 상 크기는 4비트 양자화 덕분에 비교적 작은 53GB의 GPT-OSS 120B에서 양자화 없이 BF16에 저장된 GLM 5의 거의 1.4TB까지 다양합니다. 이 수치들은 LPX 랙의 크기를 이해하는 데 도움이 됩니다. 단일 LPX 랙은 256개의 칩에 걸쳐 총 128GB의 SRAM을 제공합니다. OpenAI의 GPT-OSS 120B와 같은 53GB FFN 모델은 FFN 칩의 무게가 단일 랙에 여유 공간을 두고 충분히 들어갑니다. 623GB의 DeepSeek R1은 약 5개의 LPX 랙이 필요하고, 1.4TB의 BF16 기반 GLM 5는 10개 이상의 랙이 필요합니다(FP8로 양자화하면 필요한 랙 수가 절반으로 줄어듭니다). 바로 이러한 이유로 랙 간 전면 패널 C2C 포트가 필요합니다. 이 포트를 통해 여러 개의 LPX 랙을 연결하여 조립 라인을 확장하고 더 큰 모델을 수용할 수 있습니다. NVIDIA는 AFD 디코딩 루프 외에도 LPX의 두 번째 주요 사용 사례로 투기적 디코딩에서 초안 생성 엔진 역할을 하는 것을 제시합니다. 예측 디코딩은 LLM 추론에서 지연 시간을 줄이는 데 점점 더 중요해지는 기술입니다. 이 아이디어는 간단합니다. 더 작고 빠른 초안 모델이 미리 여러 개의 후보 토큰을 생성하고, 더 큰 목표 모델은 이를 병렬로 검증하고 승인합니다. 초안 모델의 예측이 정확할 경우(일반적인 텍스트의 경우 대부분 정확함), 단일 검증 단계에서 여러 토큰을 한 번에 확정할 수 있습니다. 결과적으로 초당 처리되는 유효 토큰 수가 크게 증가하고 최종 사용자가 체감하는 지연 시간이 줄어듭니다. 문제는 추측 디코딩을 위해서는 초안 모델이 매우 빠르게 실행되어야 한다는 점입니다. 초안 모델이 후보를 생성하는 데 소요되는 매 밀리초는 검증기가 기다리는 매 밀리초와 같습니다. 기존의 GPU 전용 설정에서는 초안 모델과 목표 모델이 동일한 하드웨어 리소스를 놓고 경쟁하며, 초안 모델의 속도는 다른 모든 것에 영향을 미치는 HBM 대역폭 제약 조건에 의해 제한됩니다. LPX는 이러한 역할에 매우 적합합니다. 결정론적 실행 모델과 LP30의 뛰어난 온칩 SRAM 대역폭 덕분에 매우 빠르고 예측 가능한 드래프트 토큰 생성이 가능합니다. 작은 드래프트 모델은 단일 LPX 트레이 또는 소수의 트레이의 SRAM에 충분히 들어갈 수 있으며, 결정론적 스케줄링은 검증기와 파이프라인 처리를 어렵게 만드는 변동성 없이 일관되고 예측 가능한 속도로 드래프트 생성을 보장합니다. 이 구성에서 시스템은 두 프로세서를 상호 보완적인 역할을 위해 짝지어 사용합니다. LPX는 저지연 아키텍처를 사용하여 초안 토큰을 신속하게 생성하고, Rubin GPU는 높은 처리량의 컴퓨팅 성능과 대용량 HBM을 활용하여 토큰을 효율적으로 검증하고 확정합니다. 이러한 분리를 통해 투기적 디코딩을 이기종 프로세서에서 실행할 수 있으므로 두 모델이 단일 GPU를 공유할 필요가 없어 동종 구성에 비해 초안 생성 속도와 검증 처리량을 향상시킬 수 있습니다. NVIDIA는 AFD와 함께 투기적 디코딩을 LPX의 핵심 워크로드로 강조하며, 이를 시스템의 중요한 가치 제안 요소로 보고 있음을 시사했습니다. 최첨단 모델이 계속 발전하고 추론 체인이 길어짐에 따라, 특수 하드웨어에서 토큰을 병렬로 생성하고 검증하는 기능은 대화형 응답성을 유지하는 데 중요한 역할을 할 수 있습니다. NVIDIA의 Vera Rubin 플랫폼과 LPX 접근 방식에서 가장 눈에 띄는 점 중 하나는 각 구성 요소가