Jalapeño가 드러낸 LLM 추론칩 설계 전환
이 글에서 먼저 가져갈 세 가지
Jalapeño의 발표는 특정 벤더의 성능 승부보다, LLM 서비스를 실제 워크로드에서 빠르고 안정적으로 돌리기 위한 ‘공동 설계’가 AI 인프라의 중심으로 이동했음을 보여 줍니다.
- 01추론 가속기는 모델 서비스의 병목을 알아야 합니다.
칩은 범용 연산량이 아니라 커널, 메모리 이동, 요청 스케줄링, 네트워크 패턴과 함께 평가해야 합니다. 본문 1절
- 02‘더 빠른 응답’은 하나의 수치가 아니라 경로의 합입니다.
프리필·디코드·KV 캐시·배칭·전송 중 어느 단계가 길어지는지 분리해야 올바른 최적화가 가능합니다. 본문 2절
- 03공개 발표는 구매 결론이 아니라 측정 계획의 시작점입니다.
모델, 입력 길이, 동시성, 장애, 이식성을 포함한 자체 기준으로 약속을 검증해야 합니다. 본문 3절
‘GPU를 더 붙였는데 왜 응답은 그대로일까?’ 추론은 연산 장치 하나로 끝나지 않는다
2026년 6월 OpenAI와 Broadcom은 LLM 추론에 맞춘 첫 번째 ‘Intelligence Processor’인 Jalapeño를 공개했습니다. 발표의 중요한 지점은 특정 칩의 절대 성능 수치가 아닙니다. OpenAI는 이 가속기를 현재와 미래 LLM의 서빙 패턴을 염두에 두고, 모델 커널·메모리 시스템·네트워킹·스케줄링·배포 시스템과 함께 설계했다고 설명합니다. 초기 시험 결과가 전력당 성능에서 기존 최상급 시스템보다 나을 것이라고 언급했지만, 최종 성능 보고서는 아직 추후 공개 예정입니다. 따라서 지금 이 발표를 “확정된 성능 순위”로 읽는 것은 맞지 않습니다.
대신 이 뉴스는 AI 인프라의 질문이 바뀌었다는 신호로 읽어야 합니다. 학습은 거대한 배치 작업을 오래 돌리는 일에 가깝지만, 제품 추론은 짧고 긴 요청, 서로 다른 컨텍스트 길이, 갑작스러운 동시 접속, 도구 호출을 동반한 에이전트 작업이 뒤섞인 상태에서 매 순간 토큰을 돌려줘야 합니다. 이때 가속기 자체가 빨라도 메모리에서 가중치와 KV 캐시를 읽는 경로, 여러 요청을 묶고 푸는 스케줄러, 노드 사이를 오가는 네트워크가 뒤처지면 사용자가 보는 p95·p99 지연은 줄지 않습니다.
- [ ] 입력 토큰이 긴 요청과 짧은 대화 요청이 같은 대기열에서 서로의 응답 시간을 늘립니까?
- [ ] GPU 사용률은 높지만, 메모리 대역폭·캐시 적중률·네트워크 대기 시간은 따로 보지 않습니까?
- [ ] 모델을 바꾸면 처리량은 좋아지는데 긴 컨텍스트의 p99는 악화됩니까?
- [ ] 배치 크기·동시성·지역을 바꿔도 어떤 경로가 병목인지 설명할 수 없습니까?
Jalapeño가 제시한 방향은 바로 이 분해에서 출발합니다. OpenAI는 칩 구조를 현재 제품과 모델에서 얻은 통찰로 설계했고, 메모리 이동을 줄이며 연산·메모리·네트워크 자원을 균형 있게 배치해 실제 활용률을 이론적 최대치에 더 가깝게 만들려 한다고 설명했습니다. 좋은 추론 시스템은 FLOPS라는 한 줄의 사양보다, 요청이 들어와 첫 토큰이 나오는 시간과 이후 토큰이 끊기지 않고 나오는 시간을 함께 관리합니다.
그렇다면 서비스 팀은 ‘추론 특화’라는 말을 어떤 내부 경로로 이해해야 할까요? 다음은 칩 이름보다 중요한 운영 단위입니다.
‘첫 토큰과 다음 토큰이 왜 다른 병목을 가질까?’ LLM 서빙 경로를 네 조각으로 나누는 법
LLM 요청은 대략 두 단계로 구분할 수 있습니다. 프리필(prefill) 은 사용자가 보낸 입력 전체를 읽어 내부 상태를 만드는 과정입니다. 문서나 대화가 길수록 연산과 메모리 읽기가 커지고, 이 단계가 길면 사용자는 답변이 시작되기까지 기다립니다. 디코드(decode) 는 만들어진 상태를 바탕으로 다음 토큰을 한 개 또는 작은 묶음으로 계속 생성하는 과정입니다. 이 단계는 반복적인 메모리 접근과 낮은 지연 시간이 중요합니다. 같은 ‘추론’이라도 병목과 최적화 목표가 달라지는 이유입니다.
여기에 KV 캐시, 요청 배칭, 네트워크가 더해집니다. KV 캐시는 앞선 토큰의 계산 결과를 재사용해 디코드 비용을 줄이지만, 컨텍스트가 길고 동시 요청이 많아질수록 상당한 메모리를 차지합니다. 배칭은 가속기를 더 잘 쓰게 할 수 있지만, 너무 오래 기다려 요청을 모으면 첫 토큰 지연을 해칠 수 있습니다. 여러 장비에 모델이나 캐시를 나누면 메모리 압박은 완화할 수 있어도 전송과 동기화가 새 병목이 될 수 있습니다. 그래서 “가속기 사용률이 낮으니 배치를 키우자”는 단일 처방은 자주 실패합니다.
[요청 도착]
|
v
[프리필: 긴 입력 처리] ----> [KV 캐시 배치]
| |
v v
[디코드: 다음 토큰 반복] <--- [메모리 읽기·갱신]
|
v
[배칭·스케줄러] ----> [네트워크/클라이언트 응답]
OpenAI가 Jalapeño를 설명하며 커널, 메모리 이동, 네트워킹, 서빙 패턴을 한 문장에 묶은 이유도 여기에 있습니다. 칩이 계산만 빠르면 가중치와 캐시를 이동시키는 동안 유휴 시간이 생길 수 있습니다. 반대로 메모리만 넓어도 요청을 조정하는 스케줄러가 긴 입력에 매달리면 짧은 요청이 함께 늦어집니다. 네트워크가 불안정하면 분산된 병렬 처리의 꼬리 지연이 전체 응답을 끌어올릴 수 있습니다. 제품에서 중요한 것은 가장 빠른 한 단계를 고르는 일이 아니라, 가장 느린 단계가 반복해서 전체 경로를 지배하지 않게 하는 일입니다.
Google Research도 2026년 I/O에서 Gemini의 낮은 지연과 높은 처리량을 위해 추측 디코딩을 확장한 블록 검증과 트리 구조 드래프팅을 TPU에 맞게 최적화했다고 소개했습니다. 이는 칩이 같더라도 모델 실행 방법과 하드웨어의 맞물림에 따라 체감 속도가 달라짐을 보여 줍니다. 그러므로 Jalapeño 같은 칩 발표를 볼 때는 “어떤 모델이 얼마나 빨랐나” 하나만 묻지 말고, 어떤 입력 길이·배칭 정책·메모리 구조에서 그 결과가 나왔는지를 함께 확인해야 합니다.
‘전용 칩이면 자동으로 싸고 안정적일까?’ 공동 설계의 이득과 새 의존성
▲ 실제 서빙 지연은 중앙 가속기만의 문제가 아니다. 입력 분기, 메모리 접근, 출력 전송 중 한 곳의 혼잡도 전체 응답을 늦출 수 있다.
전용 가속기는 반복되는 워크로드가 뚜렷할수록 유리할 수 있습니다. 모델의 주요 커널, 정밀도, 메모리 접근, 인터커넥트 패턴이 비교적 안정적이라면 범용성을 조금 덜어내고 그 경로에 전력과 실리콘 면적을 집중할 여지가 생깁니다. OpenAI는 Jalapeño가 범용 가속기를 적응시킨 설계가 아니라 현대 LLM 추론을 위해 처음부터 설계된 가속기라고 설명합니다. 이는 모델 운영자가 실제로 마주한 병목을 하드웨어 설계의 입력으로 되돌리는 방식입니다.
다만 ‘특화’는 언제나 좋은 뜻만 갖지 않습니다. 모델 아키텍처가 예상보다 빨리 바뀌거나, 멀티모달·에이전트·긴 컨텍스트 비중이 계획과 달라지거나, 특정 런타임의 최적화가 필요한 경우에는 이식성과 운영 선택지가 줄 수 있습니다. 칩, 컴파일러, 커널 라이브러리, 런타임, 랙 네트워크, 관측 도구가 함께 바뀌므로 벤더 하나의 부품을 추가하는 것과도 다릅니다. OpenAI 역시 Jalapeño가 Broadcom의 실리콘 구현과 네트워크, Celestica의 보드·랙 통합을 포함한 다세대 플랫폼의 첫 단계이며, 초기 배포 목표를 2026년 말로 제시했습니다. 지금은 서비스에 이미 적용된 확정 성과가 아니라, 검증해야 할 설계 가설의 단계입니다.
| 검토 축 | 전용 추론 플랫폼이 노리는 이점 | 도입 전에 확인할 반대 질문 |
|---|---|---|
| 연산·커널 | 자주 쓰는 LLM 연산에 맞춘 높은 실제 활용률 | 우리 모델의 정밀도·연산 그래프가 그 최적화와 맞는가? |
| 메모리 | 가중치와 KV 캐시 이동을 줄여 토큰 생성 대기를 낮춤 | 긴 컨텍스트·동시 사용자에서 캐시 용량과 회수 정책은 충분한가? |
| 네트워크 | 분산 랙에서 예측 가능한 전송과 병렬 실행 | 노드·링크 장애가 생길 때 p99와 재시도는 어떻게 달라지는가? |
| 운영 | 모델·컴파일러·서빙 계층을 한 목표로 조정 | 런타임 성숙도, 관측성, 멀티 벤더 이식성은 확보됐는가? |
이 표는 Jalapeño만을 평가하는 표가 아닙니다. GPU, TPU, ASIC, 클라우드 인스턴스를 고를 때 모두 같은 질문을 던지게 하는 체크리스트입니다. 하드웨어 선택은 모델의 이름과 가격표만 비교하는 조달 문제가 아니라, 우리 제품의 실제 요청 분포와 장애 허용 범위를 어떤 플랫폼이 가장 덜 왜곡하는가의 아키텍처 문제입니다.
여기서 특히 피해야 할 안티패턴이 있습니다. 첫째, 평균 토큰 처리량만 보고 계약하는 일입니다. 사용자는 평균이 아니라 기다림이 길어진 순간을 경험합니다. 둘째, 공급사가 제시한 모델 하나의 수치를 우리의 모델·프롬프트·도구 호출·지역 구성에도 그대로 적용하는 일입니다. 셋째, 하드웨어 교체와 함께 런타임·배칭·캐시 정책도 바꾸면서 원인을 분리하지 않는 일입니다. 변경이 겹치면 좋아진 결과도, 나빠진 결과도 무엇 때문인지 알 수 없게 됩니다.
💡 최소 원칙: 하드웨어 교체 전후에는 첫 토큰 시간, 토큰 간 지연, p95·p99, 요청 취소율, 캐시 메모리, 전력당 유효 작업량을 같은 표본으로 남기세요.
‘우리 팀은 이 뉴스를 내일부터 어떻게 써야 할까?’ 칩 구매가 아닌 측정 로드맵
새 가속기 발표가 나왔다고 바로 플랫폼을 갈아탈 필요는 없습니다. 하지만 아무 행동도 하지 않으면 다음 결정 때도 가격·브랜드·피크 처리량만 비교하게 됩니다. 가장 현실적인 첫 단계는 현재 추론 서비스를 네 개의 숫자로 쪼개는 것입니다. 입력 길이 구간별 첫 토큰 시간, 생성 길이 구간별 토큰 간 지연, 동시성별 p99, 캐시 메모리와 네트워크 사용량을 같은 대시보드가 아니라 같은 요청 식별자로 연결해 봐야 합니다. 여기서 병목 가설이 생깁니다.
두 번째 단계는 하나의 모델, 하나의 지역, 하나의 트래픽 구간에서만 비교 실험을 설계하는 것입니다. 가속기 자체를 바꿀 수 없다면 배칭 상한, 프리필과 디코드의 분리, 캐시 재사용, 요청 라우팅처럼 같은 원리에 닿는 소프트웨어 조정을 시험할 수 있습니다. 핵심은 성공 조건을 “처리량이 올랐다”가 아니라 “긴 컨텍스트의 p99가 목표 안에 있고, 짧은 대화의 첫 토큰이 악화되지 않으며, 취소율과 비용도 허용 범위”처럼 복수의 계약으로 정하는 데 있습니다.
마지막 단계는 이식성과 실패를 문서화하는 것입니다. 특정 플랫폼에서만 잘 되던 커널은 다른 가속기에서 어떻게 대체되는지, 캐시를 잃은 노드가 생겼을 때 어떤 요청을 다시 시작하는지, 특정 리전에 용량이 없을 때 어느 품질·비용·지연을 희생할지 결정해야 합니다. Jalapeño 발표가 흥미로운 까닭은 AI가 더 큰 모델의 경쟁을 넘어, 추론을 하는 물리적 경로 전체를 제품 경험의 일부로 만들고 있기 때문입니다.
최신 AI 인프라의 질문은 “어떤 칩이 가장 빠른가”가 아니다. “우리 사용자의 요청이 어떤 경로에서, 어떤 비용과 꼬리 지연으로, 끝까지 응답되는가”다.
공식 참고 자료
원문 참고 자료
이 글의 사실 확인과 추가 읽기를 위한 원문입니다. OpenAI — OpenAI and Broadcom unveil LLM-optimized inference chip
댓글 0