Groq가 마치 치트키처럼 느껴지는 이유

최근 저는 멀티 에이전트 (multi-agent) LangGraph 파이프라인을 구축하고 있었는데, 무료 티어 LLM 제공업체들을 조합해서 사용하는 대부분의 사람들처럼 저도 Groq를 기존의 주요 업체들과 비교하게 되었습니다. 그 차이는 미묘한 수준이 아니었습니다. 다른 제공업체들은 일반적인 API 호출처럼 느껴졌습니다. 요청을 보내고, 기다리면, 익숙한 속도로 텍스트가 스트리밍되어 돌아옵니다. 하지만 Groq는 마치 치트키 (cheating)처럼 느껴졌습니다. 70B 파라미터 (70B-parameter) 모델이 제가 방금 입력한 프롬프트를 다 읽기도 전에 전체 응답을 반환하는 수준이었으니까요.

저의 첫 번째 가정은 지루한 것이었습니다. Groq가 단순히 더 좋은 GPU를 가지고 있거나, 더 많은 GPU를 보유하고 있거나, 혹은 어떤 영리한 부하 분산 (load balancing) 기술을 사용하고 있을 것이라는 생각이었습니다. 그 가정은 틀렸으며, 실제 답은 "더 많은 컴퓨팅 자원"보다 훨씬 더 흥미롭습니다.

Groq는 GPU를 전혀 사용하지 않습니다. 그들은 LPU — 언어 처리 장치 (Language Processing Unit) — 라고 불리는 자체 칩을 처음부터 직접 만들었습니다. 이 모든 것은 GPU의 설계 방식이 LLM 추론 (inference)에 실제로 필요한 방식과 근본적으로 맞지 않는다는 도박(bet) 덕분에 존재합니다.

잘못된 직관: "단순히 더 나은 하드웨어"

왜 "더 나은 GPU"가 당연한 정답처럼 느껴지는지 짚어볼 가치가 있습니다. 지난 5년간의 모든 AI 성능 이야기는 GPU 이야기였습니다. 더 큰 클러스터, 더 많은 H100, 더 나은 인터커넥트 (interconnects) 같은 것들 말이죠. Nvidia의 지배력이 워낙 압도적이라 일상적인 대화에서는 "AI 칩"과 "GPU"가 기본적으로 동의어가 되었습니다.

하지만 GPU는 원래 이 작업을 위해 설계된 것이 아닙니다. GPU는 그래픽 렌더링 (graphics rendering)을 위해 설계되었으며, 이후 그 병렬 아키텍처 (parallel architecture)가 신경망 (neural networks)의 대부분을 구성하는 행렬 곱셈 (matrix multiplication)에 잘 들어맞았기 때문에 딥러닝 (deep learning) 용도로 전용되었습니다. 이러한 전용 방식은 방대한 양의 데이터를 처리하며 가공되지 않은 병렬 처리량 (raw parallel throughput)이 중요한 학습 (training) 단계에서는 매우 효과적이었습니다.

추론 (Inference), 특히 단일 요청 (single-request) 기반의 실시간 토큰 생성 (token generation)은 전혀 다른 문제입니다. 그리고 GPU에는 여기서 오히려 방해가 되는, 학습 중심의 많은 부채 (baggage)가 실려 있다는 사실이 드러났습니다.

실제 병목 현상: 메모리 벽 (the memory wall)

LLM 추론에서의 실제 제약 사항은 칩이 얼마나 많은 계산을 할 수 있느냐가 아니라, 그 계산에 필요한 데이터를 얼마나 빨리 공급할 수 있느냐입니다. 이를 때때로 "메모리 벽 (memory wall)"이라고 부르며, 이것이 바로 Groq의 아키텍처가 존재하는 이유 전체입니다.

표준 GPU에서 모델 가중치 (model weights)는 연산 코어 (compute cores)와 물리적으로 분리된 별도의 메모리 스택에 위치한 HBM (High Bandwidth Memory, 고대역폭 메모리)에 저장됩니다. HBM은 하드 드라이브에 비하면 빠르지만, 실제 수학 연산이 일어나는 곳과는 여전히 명확한 거리(hop)가 떨어져 있습니다. 칩이 가중치를 필요로 할 때마다 그 간극을 가로질러 접근해야 합니다. 거대한 배치 크기 (batch sizes)를 사용하는 학습 단계에서는 이러한 오버헤드 (overhead)가 분산되어 상쇄됩니다. 하지만 한 번에 하나의 토큰을 생성하는 단일 요청 추론 단계에서는, 연산 유닛 (compute units)이 시간의 상당 부분을 단순히 데이터가 도착하기를 기다리는 데 소비하게 됩니다.

Groq의 해답은 거의 고집스러울 정도로 단순했습니다. 메모리를 칩 외부에 두지 않는 것입니다. LPU는 느린 메모리 앞에 놓인 캐시 계층 (cache layer)이 아니라, 보통 아주 작은 CPU 캐시 (CPU caches)용으로 예약된 것과 동일한 유형인 SRAM을 주요 (primary) 가중치 저장소로 사용합니다. 수백 메가바이트의 SRAM이 연산 다이 (compute die) 위에 직접 자리 잡고 있습니다.

이로 인해 발생하는 대역폭(bandwidth) 차이는 엄청납니다. Groq의 온칩 SRAM (on-chip SRAM)은 초당 80 테라바이트 이상의 메모리 대역폭을 제공하는 반면, GPU의 오프칩 HBM (off-chip HBM)은 약 초당 8 테라바이트를 제공합니다. 다른 요소를 고려하기도 전에 이미 약 10배의 격차가 존재합니다. 독립적인 분해 분석(teardowns) 결과에 따르면, 단순한 대역폭뿐만 아니라 지연 시간(latency)까지 고려했을 때 SRAM이 HBM보다 갖는 액세스 속도(access-speed)의 이점은 약 20배에 달합니다.

두 번째 요소: 예측 불가능성 제거

메모리 대역폭만으로는 Groq의 수치를 온전히 설명할 수 없습니다. 이야기의 나머지 절반은 결정론(determinism)이며, 이는 제가 실제로 그 가치를 깨닫는 데 더 오랜 시간이 걸린 부분이기도 합니다.

GPU는 범용 칩(general-purpose chips)입니다. 즉, 하드웨어 큐(hardware queues), 캐시 히트/미스(cache hit/miss) 결정, 경쟁하는 작업 간의 중재(arbitration) 등 동적인 런타임 스케줄링(dynamic, runtime scheduling)에 의존하며, 이 모든 것이 칩이 작동하는 동안 즉석에서 결정됩니다. 이러한 유연성은 GPU가 지원해야 하는 방대한 범위의 워크로드(workloads)를 위한 기능입니다. 하지만 대가가 따릅니다. 특정 연산의 타이밍을 사전에 완전히 알 수 없으며, 수백 개의 코어가 동기화(synchronize)되어야 할 때 한 곳에서의 지연이 시스템 전체로 전파됩니다.

Groq의 컴파일러(compiler)는 정반대의 접근 방식을 취합니다. LPU의 아키텍처(architecture)에는 캐시(cache)가 없고, 동적 메모리 할당(dynamic memory allocation)이 없으며, 런타임 스케줄링(runtime scheduling) 결정도 필요하지 않기 때문에, 모든 연산, 모든 명령(instruction), 모든 칩 간 핸드오프(chip-to-chip handoff)를 포함한 전체 실행 그래프(execution graph)를 개별 클록 사이클(clock cycle) 단위까지 사전에(ahead of time) 계산할 수 있습니다. 칩은 실행되는 동안 다음에 무엇을 할지 결정하는 것이 아니라, 단 하나의 토큰(token)이 생성되기도 전에 이미 완전히 해결된 스케줄(schedule)을 실행하는 것입니다.

이것은 단순히 "유연성이 떨어진다"는 의미로 들릴 수 있고 실제로도 그렇습니다. 하지만 트랜스포머 추론(transformer inference)처럼 반복적이고 예측 가능한 워크로드(workload)의 경우, 이렇게 포기한 유연성은 GPU 추론 타이밍을 불분명하게 만드는 거의 모든 오버헤드(overhead)를 제거하는 대가로 얻어집니다. Groq의 자체 엔지니어링 자료는 이를 소프트웨어 우선 설계 철학(software-first design philosophy)으로 설명합니다. 다른 용도로 만들어진 칩에 맞추는 대신, 컴파일러의 스케줄링 작업이 결정론적(deterministic)이고 완전하게 이루어지도록 하드웨어를 특별히 설계한 것입니다.

이것이 실제 수치로 제공하는 이점

아키텍처 이야기도 훌륭하지만, 실제로 체감되는 것은 수치입니다. 독립적인 벤치마킹(benchmarking) 결과에 따르면, Llama 2 70B 모델은 Nvidia H100에서 초당 약 30~40 토큰(tokens per second)으로 실행되는 반면, Groq에서는 초당 약 300 토큰으로 실행되어 대략 10배의 차이를 보였습니다. Llama 3 8B와 같은 더 작은 모델의 경우, Groq는 H100의 약 100 토큰 대비 1,300개 이상의 초당 토큰을 입증했습니다.

여기에는 직관에 반하는 에너지 이야기도 있습니다. 동일한 작업을 더 빠르게 수행하는 칩은 순간적으로 더 많은 전력을 사용할 것이라고 예상하게 되며, 실제로 그렇습니다. 하지만 작업을 수행하는 데 드는 '시간'이 훨씬 적기 때문에, 토큰당 총 에너지 비용은 실제로 더 낮게 나타납니다. Groq는 H100 기반 시스템의 토큰당 1030 줄(joules)과 비교하여, 토큰당 약 13 줄 범위의 수치를 보고했습니다. (에너지 측면에서 비용이 많이 드는 부분인) 데이터 이동의 감소와 고전력 활성 상태에서의 총 시간 감소가 결합되어, 단순한 속도 향상을 넘어 실제적인 효율성 승리를 거두게 됩니다.

함정 — 세상에 공짜는 없으니까요

이 모든 것이 공짜는 아니며, 그 트레이드오프(tradeoff)는 바로 SRAM 결정이 부메랑이 되어 돌아오는 지점입니다.

SRAM은 빠르지만, HBM이나 DRAM에 비해 물리적으로 크고 비트당 비용이 비쌉니다. 업계의 다른 모든 칩들이 주 저장 장치 대신 아주 작은 캐시 계층(cache layers)에만 SRAM을 사용하는 이유가 바로 이것입니다. Groq의 선택은 각 개별 LPU가 칩 위에 보유할 수 있는 메모리 양이 상대적으로 적다는 것을 의미합니다. 70B 파라미터 모델은 하나의 칩에 들어가지 않으며, 소수의 칩에도 제대로 들어가지 않습니다. 보고에 따르면 그 정도 규모의 모델을 대규모로 서빙하려면 수백 개의 LPU가 긴밀한 협력 하에 작동해야 하며, 이들은 Groq가 plesiosynchronous 프로토콜이라고 부르는 맞춤형 고속 인터커넥트(high-speed interconnect)로 연결됩니다. 이 프로토콜은 칩 간 통신이 단일 칩 내부에서 일어나는 모든 일만큼이나 결정론적(deterministic)으로 유지되도록 특별히 설계되었습니다.

모델 하나를 위해 사용되는 물리적 실리콘의 양이 매우 방대하며, 이는 경제성 측면에서 직접적으로 나타납니다. 추정치에 따르면 Groq의 하드웨어 비용은 칩 단위로 비교했을 때 동일한 처리량(throughput)을 가진 GPU 설정보다 유의미하게 높습니다. Groq의 도박은 지연 시간(latency)에 민감한 워크로드(workloads)의 경우 이것이 올바른 거래라는 것입니다. 애플리케이션이 진정으로 300ms 미만의 응답 시간을 필요로 할 때, 비교 대상은 "Groq 대 더 저렴한 GPU 옵션"이 아니라 "Groq 대 기능이 아예 작동하지 않는 상황"이 됩니다.

이것이 또한 Groq가 차세대 프런티어 모델(frontier model)을 학습시키려 하지 않는 이유이기도 합니다. LPU의 전체 설계는 이미 학습된 모델을 실행하는 고정되고 예측 가능한 계산 패턴에 최적화되어 있습니다. 학습은 훨씬 더 무질서하고 예측 불가능한 워크로드이며, 이는 바로 결정론(determinism)이 도움이 되지 않는 종류의 작업입니다. Groq는 이러한 분업을 받아들였습니다. 모델 자체를 구축하는 경쟁을 하기보다는, 다른 연구소의 오픈 웨이트(open-weight) 모델(Llama, Mixtral, DeepSeek, Qwen)을 가능한 한 빠르고 저렴하게 실행하는 데 집중하는 것입니다.

향후 방향

여기서 가장 흥미로운 최근의 발전은 이것이 더 이상 "Groq 대 Nvidia"의 구도로 프레임화되지 않는다는 점입니다. Nvidia의 차기 Vera Rubin 플랫폼은 실제로 단일 이기종 시스템(heterogeneous system) 내에서 Groq의 LPU를 Rubin GPU와 함께 결합합니다. 즉, GPU는 프리필(prefill) 단계와 디코드(decode) 중의 어텐션(attention) 계산을 처리하고, LPU는 지연 시간에 민감한 피드포워드(feed-forward) 및 MoE(Mixture-of-Experts) 실행을 담당합니다. 한 아키텍처가 다른 아키텍처를 대체하는 대신, 업계는 각 칩이 실제로 잘하는 일에 사용하는 방향으로 수렴하고 있는 것으로 보입니다. 추론(inference)의 병렬적이고 처리량 중심적인 부분에는 GPU를, 순차적이고 지연 시간에 민감한 부분에는 LPU를 사용하는 방식입니다.