"하나의 칩이 모든 단계를 최적으로 처리하는 건 물리적으로 불가능하다"
LLM 추론은 겉보기엔 단일 워크로드지만 사실 prefill, decode, speculative decode, tool call, 데이터 처리 등 병목 자원(메모리 대역폭 vs. 연산 집약도 vs. 레이턴시)이 완전히 다른 단계들의 집합이다. 트릴리언 달러짜리 CAPEX가 쏟아지는 지금, 이 차이를 무시하고 GPU 하나로 전부 돌리는 건 낭비다. Gimlet은 이 워크로드를 그래프로 추적·분해해 각 조각을 최적 실리콘에 자동 배치하는 소프트웨어 오케스트레이션 레이어를 핵심으로 삼는다.
왜 지금인가: 매일같이 Traxion·AMD·TPU·Nvidia와의 컴퓨트 계약 뉴스가 나오고, 새로운 추론 전용 가속기 회사가 등장한다. 이를 "GPU 킬러 vs. GPU" 구도로 보는 시각이 많지만, Gimlet은 모든 옵션이 서로 다른 용도에 최적이라는 시각으로 접근한다. 문제는 어떤 칩이 이길 것이냐가 아니라, 어떻게 올바른 칩에 올바른 작업을 보내느냐다.
워크로드 분해 방법론: PyTorch 등의 모델을 입력받아 트레이싱 → 그래프 표현으로 변환 → 오케스트레이터·스케줄러가 최적 분할점 결정 → 각 세그먼트를 타깃 하드웨어용으로 컴파일(예: Nvidia는 TensorRT, 타 벤더는 해당 프레임워크). "모든 칩을 위한 프로그래밍 언어를 새로 만드는 게 아니라, 각 하드웨어 파트너의 기존 저수준 프레임워크를 적극 활용한다"는 게 Natalie의 설명.
에이전트가 문제를 더 복잡하게 만든다: 단순 LLM 채팅보다 멀티스텝 코딩 에이전트, 멀티모달 백그라운드 에이전트는 훨씬 이종적(heterogeneous)이다. 모델 간 통신, tool call, 검색, 로컬 실행이 뒤섞이면 동질적(homogeneous) 스택의 비효율은 "완전히 감당 불가(untenable)" 수준이 된다고 Natalie는 강조했다.
CPU의 역할: tool call을 사용자 랩톱이 아닌 서버 사이드에서 실행하면 LLM 서버 ↔ 랩톱 간 네트워크 왕복이 제거돼 에이전트 end-to-end 레이턴시가 크게 줄어든다. 이를 위해 GPU·SRAM 가속기·CPU를 모두 고속 패브릭으로 동일 데이터 센터 내에 연결하는 것이 Gimlet의 물리적 아키텍처다.
"우리는 지금껏 누구도 연결해본 적 없는 칩들을 연결하고 있다. 벤더 A와 벤더 B의 칩을 꽂아서 단일 워크로드를 가로질러 오케스트레이션한 사람이 아직 없었기 때문이다."
쉽게 풀어보기 — 추론 워크로드 분해
- Prefill
- 사용자가 입력한 긴 컨텍스트를 한꺼번에 처리하는 단계. 연산 집약적(compute-bound).
- Decode
- 토큰을 하나씩 생성하는 단계. 메모리 대역폭 집약적(memory-bound).
- Speculative Decode
- 작은 모델이 다음 토큰 여러 개를 먼저 추측하고, 큰 모델이 한번에 검증하는 방식. 검증이 생성보다 훨씬 빠르다는 점을 이용.
- SRAM 기반 가속기
- HBM(고대역폭 메모리) 대신 온칩 SRAM에 가중치를 올려 극저지연 decode에 특화된 칩 구조.
- Pareto 프론티어
- throughput(처리량)과 interactivity(응답 속도)를 동시에 최대화할 수 없는 트레이드오프 곡선. 이 곡선 자체를 위로 밀어올리는 것이 목표.