Skip to content
Published on

Cerebras Ultrafast와 에이전트 루프의 병목 — 초당 750토큰이 줄이지 못하는 시간

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드✨Start Quiz
공유하기
Authors

이 글은 2026-08-15에 Hacker News API와 GeekNews 피드에서 직접 확인한 항목을 바탕으로 합니다. 점수와 순위는 계속 바뀝니다.

무엇이 올라와 있었나

Hacker News API로 확인한 항목입니다. 제목은 Accelerating GPT-5.6 Sol Ultrafast, 아이템 번호는 49289844이고 2026-08-15 기준 694점에 댓글 270개입니다. 링크는 Cerebras 블로그의 발표문입니다. GeekNews 피드에도 같은 항목이 올라와 있었습니다.

발표문은 Cerebras와 OpenAI가 Ultrafast 모드라는 새 서비스 티어를 OpenAI API에 올렸다고 밝히고, 출력 속도를 초당 최대 750토큰이라고 적고 있습니다.

발표문이 지목한 것은 연산이 아니라 이동입니다

이 발표문에서 가장 중요한 문장은 속도 수치가 아닙니다. 문제의 성격을 규정한 부분입니다. 발표문은 이것을 데이터 이동의 문제로 부르고, 가중치가 칩 위에 머무르며 토큰이 웨이퍼에 걸쳐 파이프라인된 층들을 끊김 없이 흘러간다고 설명합니다. 하드웨어는 웨이퍼 스케일 엔진이고 웨이퍼 크기의 칩 하나당 SRAM이 44GB라고 적혀 있습니다.

왜 이동이 문제인지는 디코딩의 성질에서 나옵니다.

토큰을 하나 생성할 때 모델은 가중치 전체를 한 번 읽습니다. 그런데 그 가중치로 하는 연산은 토큰 하나 분량입니다. 즉 읽어 온 바이트 수에 비해 연산량이 극히 적습니다. 연산 강도가 낮다는 말이 이 뜻입니다.

이 상태에서는 연산기를 아무리 붙여도 소용이 없습니다. 속도를 정하는 것은 가중치를 메모리에서 읽어 오는 시간이고, 그래서 배치 1 디코딩의 상한은 대략 메모리 대역폭을 모델 크기로 나눈 값이 됩니다. 여러 요청을 묶어서 한 번 읽은 가중치를 여러 요청이 같이 쓰게 만드는 것, 즉 배치 처리가 처리량을 올리는 이유도 여기 있습니다. 다만 배치는 처리량을 올릴 뿐 한 요청의 지연을 줄이지는 못합니다.

Cerebras가 택한 길은 대역폭 문제를 우회하는 대신 거리를 없애는 것입니다. 가중치를 외부 메모리가 아니라 칩 위 SRAM에 두면 읽어 오는 시간이 근본적으로 달라집니다. 대신 SRAM은 비싸고 용량이 작으므로 모델을 여러 웨이퍼에 층 단위로 나눠 얹고 토큰을 그 사이로 흘려보냅니다. 발표문의 파이프라인이라는 표현이 그것입니다.

추론 스택에서 이 갈래를 다루는 방법은 KV 캐시와 페이지드 어텐션과 vLLM 내부 구조 개요에 정리해 두었습니다.

발표된 배속 수치를 어떻게 읽어야 하나

발표문에 실린 비교는 다음과 같습니다. Artificial Analysis가 보고한 출력 속도 기준으로 한 경쟁 모델보다 11배, 다른 모델의 고속 모드보다 5배 빠르다고 적혀 있습니다. 그리고 두 가지 종단 간 수치가 있습니다.

하나는 Humanity's Last Exam입니다. 2,500문항 전체를 Ultrafast 모드에서 11시간 11분에 끝냈고, 비교 대상 모델은 같은 결론에 이르는 데 78시간 27분이 걸렸다고 적혀 있습니다. 다른 하나는 GDP-Val로, 품질 손실 없이 종단 간 5.6배 빨라졌다고 되어 있습니다.

여기서 두 종류의 숫자를 구분해야 합니다. 11배와 5배는 토큰 생성 속도의 비교입니다. 11시간 11분과 5.6배는 작업 완료 시간의 비교입니다. 후자가 전자보다 낮다는 사실 자체가 정보입니다. 토큰이 11배 빨라져도 종단 간으로는 5.6배에 그쳤다는 뜻이고, 차이만큼이 토큰 생성이 아닌 시간입니다.

발표문은 성능이 워크로드와 구성과 날짜와 대상 모델에 따라 달라질 수 있다는 단서를 달고 있습니다. 가격은 공개되지 않았고 제공은 일부 고객 대상 한정 프리뷰입니다.

댓글에서 나온 가장 유용한 지적

댓글에서 반복적으로 제기된 첫 번째 문제는 품질입니다. 여러 댓글이 이 모드가 기존 모델과 정확히 동일하게 동작한다는 명시적 진술이 어느 발표문에도 없다는 점을 지적했습니다. 완전히 같다면 그렇게 말했을 것이라는 취지입니다. GDP-Val에 대해 품질 손실이 없다는 언급은 있지만 전체 범위에 대한 진술은 아닙니다.

두 번째는 이 글에서 가장 실무적인 지적입니다. 한 댓글은 토큰 처리량이 아무리 좋아져도 해결되는 병목은 일부일 뿐이라며 구체적으로 적었습니다. 종단 간 테스트가 한 시간 걸린다면 그 뒤에도 한 시간이고, 에이전트가 변경 후 돌리는 타입 검사가 10분이면 그것도 그대로이며, 거대한 코드베이스에 대한 검색도 똑같이 느리다는 것이었습니다.

이것은 정확히 암달의 한계입니다. 그리고 에이전트 워크로드에서 이 지적은 특히 강하게 작용합니다. 에이전트 루프의 벽시계 시간은 토큰 생성과 도구 실행이 번갈아 쌓인 합인데, 도구 실행 쪽에는 빌드, 테스트, 타입 검사, 파일 검색, 네트워크 호출이 들어 있고 이 중 어느 것도 추론 하드웨어로 빨라지지 않습니다.

가격이 없다는 점도 여러 댓글이 짚었습니다.

어떻게 적용하나

추론 가속을 검토하고 있다면 계약을 논의하기 전에 해야 할 계산이 하나 있습니다. 여러분의 루프에서 토큰 생성이 차지하는 비율을 재는 것입니다.

방법은 간단합니다. 에이전트 세션 20개 정도를 골라 각 단계의 시작과 끝 타임스탬프를 남기고, 시간을 두 통으로 나눕니다. 하나는 모델 응답을 기다린 시간, 다른 하나는 도구를 실행한 시간입니다. 그 비율이 나오면 상한이 바로 계산됩니다.

예시: 세션 평균 벽시계 600초
  - 모델 응답 대기 : 240초 (40%)
  - 도구 실행      : 360초 (60%)

토큰 생성이 무한히 빨라져도 → 600초는 360초로만 내려감 (약 1.67배)

이 표를 만들어 보면 대부분의 팀에서 놀라는 지점이 생깁니다. 코딩 에이전트에서 도구 실행 비중이 절반을 넘는 경우가 흔하고, 그 안에서도 테스트 실행 하나가 지배적인 경우가 많습니다. 그런 상황이라면 추론 티어를 바꾸는 것보다 테스트를 병렬화하거나 영향 범위만 골라 돌리는 쪽이 벽시계 시간을 더 많이 줄입니다. 게다가 그쪽은 계약도 필요 없습니다.

반대로 비율을 재 봤더니 모델 대기가 80%였다면, 그때는 가속이 실제로 큰 효과를 냅니다. 요점은 어느 쪽인지 재기 전에는 알 수 없다는 것입니다.

누구에게는 해당 없는가

처리량이 목표인 배치 워크로드에는 이 티어의 강점이 잘 맞지 않습니다. 야간에 문서 수백만 건을 처리하는 작업이라면 중요한 것은 한 요청의 지연이 아니라 단위 비용당 총 토큰 수이고, 그 축에서는 묶어서 처리하는 기존 방식이 유리한 경우가 많습니다. 이 티어가 겨냥하는 것은 대기하는 사람이나 대기하는 루프가 있는 상황입니다.

사람이 읽는 속도로 소비되는 출력도 해당이 적습니다. 채팅 응답을 사람이 읽는다면 초당 750토큰은 읽기 속도를 한참 넘어서므로 체감 차이가 크지 않습니다. 이 속도가 의미를 갖는 것은 출력을 기계가 소비할 때, 즉 추론 사슬이 길거나 에이전트가 스스로 읽고 다음 행동을 정할 때입니다.

가격이 공개되지 않았고 한정 프리뷰라는 점도 그대로입니다. 지금 단계에서 이 항목의 실질적 가치는 도입 검토가 아니라 위의 비율 계산을 한번 해 보게 만드는 데 있습니다.

정리

발표문에서 배울 것은 초당 750토큰이라는 숫자가 아니라 그 숫자가 나온 이유입니다. 디코딩이 느린 원인은 연산이 부족해서가 아니라 가중치를 읽어 오는 거리 때문이고, 그래서 해법도 더 빠른 연산기가 아니라 거리를 없애는 쪽이었습니다. 그리고 그 가속이 여러분에게 얼마짜리인지는 발표문이 아니라 여러분의 루프에서 도구 실행이 차지하는 비율이 정합니다.

원문과 관련 글

메모리 묶임에 대한 설명과 비율 계산 방법은 발표문에 적힌 내용을 바탕으로 제가 정리한 것입니다.

Discuss on Twitter • View on GitHub