빠른 LLM inference를 위한 두 가지 다른 트릭

발행: 12시간 전 (2026년 2월 15일 오후 06:27 GMT+9)

18 분 소요

죄송합니다만, 번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 전체 내용을 알려주시면 한국어로 번역해 드리겠습니다.

Source: …

Fast Mode Showdown: Anthropic vs. OpenAI

Anthropic와 OpenAI는 모두 “fast mode”를 발표했으며, 이는 최고의 코딩 모델을 훨씬 더 높은 속도로 사용할 수 있게 하는 방법입니다.

이 두 fast mode는 매우 다릅니다. Anthropic의 제공은 초당 2.5배 토큰(≈ 170 t/s, Opus 4.6의 65 t/s에서 상승)을 지원합니다. OpenAI의 fast mode는 1 000 t/s 이상(GPT‑5.3‑Codex의 65 t/s에서 상승, 즉 ≈ 15배)을 제공합니다. 따라서 OpenAI의 fast mode는 Anthropic의 fast mode보다 대략 6배 빠릅니다¹.

핵심 차이점: Anthropic은 실제 Opus 4.6 모델을 제공하는 반면, OpenAI의 fast mode는 더 작은 GPT‑5.3‑Codex‑Spark 모델을 실행합니다—전체 크기의 GPT‑5.3‑Codex가 아니라요. Spark는 더 빠르지만 눈에 띄게 능력이 낮아, 일반 모델에서는 절대 실수하지 않을 도구 호출을 혼동하거나 잘못 처리할 수 있습니다.

차이점은 왜 발생할까?

실험실에서는 빠른 모드의 정확한 메커니즘을 공개하지 않았지만, 가능한 설명은 다음과 같습니다:

Anthropic: 소규모 배치 추론.
OpenAI: 특수하고 거대한 Cerebras 칩.

아래는 각 접근 방식에 대한 자세한 분석입니다.

Anthropic의 빠른 모드 작동 방식

AI 추론 비용 구조에서 핵심적인 배치 처리는 메모리가 주요 병목 현상이기 때문입니다. GPU는 빠르지만, 데이터를 GPU에 올리는 과정은 그렇지 않습니다. 모든 추론 요청은 연산이 시작되기 전에 전체 프롬프트를 GPU에 복사해야 합니다². 여러 사용자를 하나의 배치에 묶으면 전체 처리량은 증가하지만, 각 사용자는 배치가 채워지기를 기다려야 합니다.

비유 – 버스 시스템

배치가 전혀 없는 상황은 승객이 탑승하는 순간 바로 출발하는 버스와 같습니다. 승객 입장에서는 이동이 빠르지만, 버스가 반쯤 비어 있는 경우가 많아 전체 처리량이 떨어집니다.

Anthropic의 빠른 모드는 본질적으로 즉시 출발하도록 보장하는 “버스 패스”와 같습니다. 다른 승객과 공유할 수 있었던 용량을 독점하기 때문에 비용이 약 6배 더 들지만, 대기 시간이 전혀 없습니다³.

편집: 한 독자는 “버스를 기다리는” 비용이 첫 토큰에만 적용되며, 스트리밍 지연에는 영향을 주지 않는다고 지적했습니다(즉, 턴당 혹은 툴 호출당 지연만). 따라서 배치 크기의 성능 영향은 작은 배치가 더 적은 FLOP을 요구하고 더 빨리 끝난다는 점에 주로 해당합니다. 비유하자면 “가벼운 버스가 더 빠르게 달린다”는 것이죠.

이 설명이 100 % 정확하다고는 할 수 없습니다. Anthropic이 초고속 컴퓨팅이나 새로운 알고리즘 트릭을 보유했을 가능성도 있습니다. 그러나 저배치 크기라는 접근만으로도 “2.5배 빠르면서 토큰당 6배 비싼” 비율을 설명할 수 있습니다.

OpenAI의 빠른 모드 작동 방식

OpenAI의 빠른 모드는 근본적으로 다릅니다. 새롭고 성능이 낮은 모델(Spark)을 도입했다는 사실은 속도 향상이 단순히 배치 크기 조정만으로 이뤄진 것이 아님을 시사합니다. 그들의 발표 블로그에서는 지원 하드웨어로 Cerebras를 명시했습니다⁴.

Cerebras 파트너십

OpenAI는 2024년 1월에 Cerebras와의 파트너십을 발표했습니다. Cerebras는 초저지연 컴퓨팅을 위해 거대한 칩을 제조합니다. NVIDIA H100이 약 1인치 제곱 정도라면, Cerebras의 웨이퍼‑스케일 엔진은 ≈ 70 in²에 달합니다.

Cerebras wafer‑scale chip

이 칩들은 대용량 온‑칩 SRAM을 갖추고 있어 전체 모델을 메모리에 올려둘 수 있습니다. 일반 GPU의 SRAM은 수십 메가바이트에 불과해 추론 중에 무거운 가중치를 느린 DRAM에서 자주 스트리밍해야 합니다⁵. 충분한 SRAM을 갖추면 추론을 메모리 내에서 수행할 수 있어 관측된 ≈ 15배 속도 향상을 달성합니다.

최신 Cerebras 웨이퍼‑스케일 엔진은 44 GB SRAM을 제공합니다⁶. 이는 소형 모델(~20 B 파라미터 fp16, ~40 B int8) 정도는 수용할 수 있지만, 전체 GPT‑5.3‑Codex를 담기엔 부족합니다. 따라서 OpenAI는 GPT‑5.3‑Codex‑Spark라는 대형 모델의 증류 버전을 도입했습니다⁷.

OpenAI 버전의 기술적 인상

두 실험실은 빠른 추론을 달성하기 위해 전혀 다른 엔지니어링 경로를 선택했습니다:

항목	Anthropic	OpenAI
속도 향상	2.5× 토큰/초 (≈ 170 t/s)	15× 토큰/초 (≈ 1 000 t/s)
사용 모델	전체 Opus 4.6 (증류 없음)	증류된 GPT‑5.3‑Codex‑Spark
주요 기술	소규모 배치 추론 (대기 시간 감소)	Cerebras 웨이퍼‑스케일 엔진 (대용량 온‑칩 메모리)
비용	토큰당 약 6배 더 비쌈	토큰당 약 6배 더 비쌈 (비율 유사)
추가 메모	—	—

ade‑off**	Slightly higher latency per turn (first token)	Reduced model capability

Both approaches have merit. Anthropic’s method preserves model quality while shaving latency through smarter batching. OpenAI’s hardware‑centric strategy pushes raw throughput dramatically, at the expense of model size.

두 접근 방식 모두 장점이 있습니다. Anthropic의 방법은 모델 품질을 유지하면서 더 스마트한 배치를 통해 지연 시간을 줄입니다. OpenAI의 하드웨어 중심 전략은 모델 크기를 희생하면서 원시 처리량을 크게 향상시킵니다.

Footnotes (1‑7)

Source: …

이런 식으로 진행될 수 있다

OpenAI는 Cerebras와 1월 중순에 파트너십을 맺으며, 명백히 OpenAI 모델을 빠른 Cerebras 칩에 올리는 작업을 위해서이다.
Anthropic은 비슷한 전략이 없지만, OpenAI가 2월에 어떤 초고속 추론을 발표할 것이라는 사실을 알고 있으며, 그와 경쟁할 수 있는 뉴스를 만들고 싶어한다.
따라서 Anthropic은 자신들이 제공할 수 있는 빠른 추론을 마련하기 위해 서두른다: 기존 추론 스택에서 배치 크기만 줄이는 방식이다.
Anthropic은 (아마도) OpenAI가 훨씬 복잡한 Cerebras 구현을 마무리하기 며칠 전에 이를 발표함으로써 OpenAI가 자신들을 베낀 것처럼 보이게 만든다.

분명히 여기서 OpenAI의 성과가 기술적으로 더 인상적이다. Cerebras 칩에 모델을 올리는 일은 하드웨어가 매우 특수하기 때문에 간단하지 않다. 여전히 “어느 정도는 괜찮은” 20 B‑ 또는 40 B‑파라미터 GPT‑5.3‑Codex 디스틸을 학습하는 것도 쉬운 일이 아니다.

하지만 나는 Anthropic이 비기술적인 사람들에게는 거의 투명하지 않을 발표를 앞서 나갈 교묘한 방법을 찾은 점을 높이 평가한다. 이는 2025년 중반 OpenAI가 Responses API를 은밀히 도입해 추론 토큰을 숨기려 했던 사례와도 닮아 있다⁸.

빠른 AI 추론이 차세대 큰 흐름일까?

두 주요 연구소가 이 기능을 내놓은 것을 보면, 빠른 AI 추론이 그들이 쫓는 새로운 주요 목표라고 생각할 수도 있습니다. 저는 그렇지 않다고 생각합니다. 위의 이론이 맞다면, Anthropic은 그렇게 빠른 추론에 크게 신경 쓰지는 않으며, 단지 OpenAI 뒤에 남고 싶지 않았을 뿐입니다. 그리고 OpenAI는 주로 새로운 Cerebras 파트너십의 능력을 탐구하고 있습니다.

여전히 어떤 종류의 모델이 이 거대한 칩에 들어갈 수 있는지, 그 모델들이 얼마나 유용할지, 그리고 경제성이 언제든지 의미가 있을지에 대해서는 대부분 미해결 질문으로 남아 있습니다.

개인적으로 저는 “빠르고, 능력이 낮은 추론”이 특별히 유용하다고 생각하지 않습니다. Codex에서 이것을 가지고 놀아봤지만 별로 마음에 들지 않았습니다. AI 에이전트의 유용성은 그들이 얼마나 적은 실수를 하는가에 의해 좌우되며, 순수한 속도에 의해 좌우되지 않습니다. 실수가 20 % 더 늘어나는 대가로 속도가 6배 빨라지는 것은 나쁜 거래입니다. 왜냐하면 사용자의 대부분 시간은 모델을 기다리는 것이 아니라 실수를 처리하는 데 쓰이기 때문입니다⁹.

하지만 빠르고, 능력이 낮은 추론이 AI 시스템의 핵심 하위 수준 원시 연산이 될 가능성은 충분히 있습니다. Claude Code는 이미 일부 연산에 Haiku를 사용하고 있습니다¹⁰. 아마 OpenAI도 비슷한 방식으로 Spark를 사용할 수도 있습니다.

몇 가지 기술적 부가 설명

이전 토큰에 대한 KV‑캐시이든, 추론이 여러 GPU를 통해 파이프라인될 때 중간 활성화 텐서가 크든, 둘 중 하나가 관여합니다. 이에 대해서는 Why DeepSeek is cheap at scale but expensive to run locally 에서 더 자세히 다루고 있는데, 여기서는 DeepSeek가 어떻게 저렴한 가격에 제공될 수 있는지 설명합니다(대규모 배치는 거대한 고가 GPU에서 규모의 경제를 가능하게 하지만, 개별 소비자는 전혀 접근할 수 없습니다)¹¹.
낮은 배치 크기가 낮은 처리량을 의미한다는 것이 “fast‑pass” 시스템이 사용자에게 훨씬 더 큰 처리량을 제공한다는 것과 모순되는가? 아닙니다. 일부 사용자가 “fast mode”를 사용할 때 GPU 전체의 처리량은 훨씬 낮아지지만, 그 사용자들의 사용자당 처리량은 훨씬 높아집니다¹².
GPU는 빠르지만, 데이터를 GPU에 복사하는 것은 빠르지 않다는 점을 기억하세요. 각 “이 가중치를 GPU에 복사한다”는 단계는 전체 추론 시간에서 의미 있는 부분을 차지합니다⁹.
“fast” 모델은 GPT‑5.3‑Codex가 자체적으로 증류된 더 강력한 기본 모델의 작은 디스틸(distil)일 수도 있습니다. AI 연구소들이 정확히 어떻게 하는지는 잘 모르겠고, 매우 비밀리에 진행됩니다. 이에 대한 자세한 내용은 여기¹³에서 확인할 수 있습니다.
관련해서 흥미로운 점은 Cursor의 hype가 그들이 자체 “훨씬 빠르고, 약간 덜 능력 있는” 에이전트 모델을 출시한 시점에 거의 사라졌다는 것입니다¹⁴. 물론 이는 Claude Code가 방 안의 산소를 모두 빨아들인 것과도 관련이 있지만, 매우 빠른 모델이 존재한다고 해서 상황이 도와진 것은 아닙니다.

이 게시물이 마음에 드셨다면…

[구독](https://buttondown.com/seangoedecke)하여 새 게시물에 대한 이메일 업데이트를 받아보세요.
또는 [Hacker News에 공유](https://news.ycombinator.com/submitlink?u=https://www.seangoedecke.com/fast-llm-inference/&t=Two%20different%20tricks%20for%20fast%20LLM%20inference)하세요.

Additional Footnotes (8‑15)

OpenAI의 빠른 모드(≈ 1 000 t/s)는 Anthropic의(≈ 170 t/s)보다 대략 6배 빠릅니다. ↩
각 추론 요청은 계산을 시작하기 전에 전체 프롬프트를 GPU에 복사해야 합니다. ↩
“6배 비용”은 배치 내 다른 사용자와 공유될 수 있었던 용량에 대해 비용을 지불한다는 의미입니다. ↩
Cerebras 파트너십에 관한 OpenAI 블로그 게시물. ↩
GPU SRAM은 일반적으로 수십 메가바이트 단위로 측정되며, DRAM에서 가중치를 스트리밍하면 지연이 추가됩니다. ↩
Cerebras 웨이퍼‑스케일 엔진(WSE) SRAM 용량: 44 GB. ↩
Spark는 GPT‑5.3‑Codex의 정제 버전으로, Cerebras의 온‑칩 메모리 제한에 맞게 설계되었습니다. ↩
Sean Goedecke의 Responses API에 대한 논의를 참조하십시오. ↩
GPU 복사 지연 영향. ↩ ↩²
Haiku 이슈 댓글. ↩
위에서 언급된 DeepSeek 기사을 참조하십시오. ↩
사용자당 처리량과 전체 GPU 처리량의 차이에 대한 설명. ↩
모델 증류 관행에 대한 논의. ↩
Cursor의 빠르고 성능이 낮은 에이전트 모델 출시. ↩