Jalapeño 추론 칩 공개: OpenAI가 에이전트 지연 시간을 하드웨어 문제로 보는 이유

요약: OpenAI가 자체 추론 칩 Jalapeño의 초기 성능을 공개했다. 핵심은 단순히 토큰을 더 많이 뽑는 칩이 아니라, 에이전트형 워크로드에서 누적되는 지연 시간을 줄이기 위해 prefill, decode, KV cache, 네트워크를 한 시스템 안에서 맞췄다는 점이다. 실무 개발자에게 중요한 질문은 ‘언제 이 칩을 쓸 수 있나’보다 ‘우리 서비스의 지연 시간 병목을 지금 어떤 기준으로 재야 하나’다.

무엇이 발표됐나

OpenAI는 2026년 8월 25일 Jalapeño라는 자체 추론 칩의 첫 결과를 공개했다. 공개 내용에 따르면 Jalapeño는 GPT-OSS 120B, DeepSeek R1, Kimi K2.5 1T 같은 서로 다른 공개 모델에서 비교 시스템 대비 더 높은 성능/전력 효율과 낮은 end-to-end latency를 보였다. OpenAI는 세 모델에서 peak throughput 기준 1.51.9배 더 많은 AI work per watt, 1.73.6배 낮은 end-to-end latency, interactive workload 기준 2.1~4.1배 높은 성능을 언급했다.

숫자만 보면 하드웨어 벤치마크 기사처럼 보인다. 하지만 개발팀 관점에서는 다른 지점이 더 중요하다. OpenAI가 이 칩을 설명하면서 계속 강조한 것은 ‘에이전트’다. 챗봇은 한 번 질문하고 한 번 답하면 끝나는 경우가 많다. 반면 에이전트는 검색, 코드 실행, 파일 수정, 검증, 재시도처럼 여러 단계를 순서대로 수행한다. 각 단계에서 1초씩 느려지면 전체 작업은 금방 수십 초가 된다. Jalapeño는 이 누적 지연을 하드웨어와 시스템 설계의 문제로 본다.

병목은 토큰 생성 속도 하나가 아니다

LLM 추론은 크게 prefill과 decode로 나뉜다. Prefill은 긴 프롬프트와 컨텍스트를 한 번에 처리하는 단계라 계산량이 크다. Decode는 한 토큰씩 생성하는 단계라 메모리 대역폭과 KV cache 접근이 중요해진다. 기존 서비스 운영에서 흔한 실수는 전체 latency를 ‘tokens per second’ 하나로만 보는 것이다. 실제 사용자는 첫 토큰이 늦는지, 중간에 멈칫거리는지, tool call 이후 재개가 느린지, 긴 컨텍스트에서 비용이 튀는지를 따로 체감한다.

Jalapeño 발표에서 눈에 띄는 표현은 모델 상태와 KV cache를 명시적으로 배치하고, 요청 전체가 하나의 연결된 시스템 안에서 움직이도록 설계했다는 대목이다. 다시 말해 ‘칩 하나가 빠르다’가 아니라, 메모리·네트워크·스케줄러·커널이 함께 움직여야 에이전트 UX가 좋아진다는 주장이다. 서비스 개발팀도 같은 방식으로 생각해야 한다. 모델 API를 붙였는데 느리다면 모델만 바꾸기 전에, 컨텍스트 구성과 tool call 순서, 스트리밍 시작 시점, 캐시 재사용 여부를 함께 봐야 한다.

개발팀이 바로 확인할 성능 지표

이번 발표를 보고 당장 자체 칩을 구매할 수는 없다. 대신 운영 지표를 바꿀 수는 있다. 최소한 아래 지표를 로그에 남기는 것이 좋다.

• Time to first token: 사용자가 기다림을 처음 체감하는 시간
• End-to-end latency: 요청 시작부터 최종 답변 완료까지 걸린 시간
• Tool round-trip latency: tool call 시작, 외부 작업, 모델 재개까지의 시간
• Active session count: 동시에 진행 중인 대화나 에이전트 작업 수
• Context length bucket: 8K, 32K, 128K 이상처럼 컨텍스트 길이별 latency
• Retry count: 모델 재호출, tool 재시도, 검증 실패 후 재생성 횟수
• Cost per completed task: 토큰 비용이 아니라 성공한 작업 1건당 비용

특히 에이전트 서비스라면 request per second보다 active session과 step count가 더 유용하다. RPS는 낮아도 한 요청이 3분 동안 여러 tool call을 붙잡고 있으면 서버 자원은 계속 점유된다. Jalapeño가 interactive workload를 따로 언급한 것도 같은 맥락이다.

제품 설계에서 달라지는 점

추론 인프라가 빨라질수록 제품은 더 많은 단계를 모델에게 맡기려 한다. 그러나 지연 시간이 줄었다고 무조건 긴 에이전트 플로우를 넣으면 안 된다. 사용자는 ‘AI가 열심히 일하고 있다’보다 ‘중간 결과를 확인하고 통제할 수 있다’를 더 신뢰한다. 따라서 긴 작업은 단계별 체크포인트로 나누는 편이 낫다.

예를 들어 코드 수정 에이전트라면 한 번에 분석, 수정, 테스트, PR 설명까지 몰아넣기보다 다음처럼 나누는 것이 운영하기 쉽다. 첫째, 변경 범위를 요약한다. 둘째, 영향 파일을 보여준다. 셋째, 테스트 계획을 만든다. 넷째, 실제 수정과 검증을 수행한다. 이렇게 나누면 latency가 조금 길어도 사용자는 진행 상태를 이해한다. 반대로 아무 피드백 없이 90초 뒤 결과만 주면, 실제 처리량이 높아도 UX는 나쁘다.

벤치마크를 읽을 때 조심할 점

OpenAI 발표에는 InferenceX 기준 수치, package TDP, 모델별 비교가 포함되어 있다. 이런 수치는 방향성을 보는 데 유용하지만 그대로 우리 서비스 비용으로 환산하면 위험하다. 실제 서비스에서는 프롬프트 길이, 출력 길이, 동시성, tool call 비율, 캐시 정책, region, rate limit, 실패 재시도율이 비용을 바꾼다.

또 하나의 함정은 평균 latency다. 평균이 좋아져도 p95나 p99가 나쁘면 기업용 서비스에서는 장애처럼 보인다. 특히 에이전트는 한 단계라도 p99가 터지면 전체 작업이 느려진다. 따라서 벤치마크를 볼 때는 평균 TPS보다 tail latency와 session completion rate를 봐야 한다.

실행 체크리스트

• 현재 서비스의 time to first token, end-to-end latency, p95/p99를 분리해서 로깅한다.
• tool call이 있는 요청과 없는 요청을 별도 지표로 나눈다.
• 긴 컨텍스트 요청을 bucket으로 나눠 비용과 latency를 본다.
• ‘토큰당 비용’이 아니라 ‘성공한 작업 1건당 비용’을 계산한다.
• 사용자가 기다리는 긴 작업에는 단계별 상태 메시지와 취소 지점을 넣는다.
• 모델 교체 실험은 같은 프롬프트, 같은 tool, 같은 출력 기준으로 A/B 테스트한다.
• 출처: OpenAI, Jalapeño first results, 2026-08-25.