지난 5년 동안 '어떻게 모델을 더 좋게 만들까'에 대한 답은 항상 같았습니다. 더 큰 모델, 더 많은 데이터, 손실 곡선이 휘기를 기다리는 것이었습니다. 스케일링 법칙(Scaling laws) 덕분에 AI 발전은 거의 지루하게 느껴질 정도였습니다. 예측 가능하고 복리 이자처럼 말입니다.

그 노브는 여전히 작동합니다. 하지만 이제 흥미로운 부분은 아닙니다.

현재 팀들이 씨름하는 진짜 질문은 이것입니다. 이미 가지고 있는 모델에 대해, 질문당 얼마나 많은 컴퓨팅 자원을 할애해야 하는가? 훈련 실행(training run) 당이 아니라, 질문당 말입니다. 그리고 그 답은 여러분의 추론 스택(inference stack)이 구축된 거의 모든 가정을 깨뜨립니다.

단일 순방향 패스(single forward pass)는 항상 약한 고리였다

아무도 충분히 크게 말하지 않는 것이 있습니다. 모델의 첫 번째 답변은 종종 그저 노이즈가 섞인 샘플에 불과하다는 것입니다. 정답은 어딘가에 있었지만, 가장 크거나 명확하게 들리지 않았을 뿐입니다. 이것을 더 많은 사전 학습 토큰(pretraining tokens)으로 고칠 수는 없습니다. 더 많이 샘플링하거나, 작업을 확인하거나, 모델이 두 번째 패스를 하도록 함으로써 해결할 수 있습니다.

이것이 바로 테스트 시간 컴퓨팅(test-time compute)의 전체 아이디어입니다. 그리고 이 추가적인 컴퓨팅 자원을 사용하는 방법은 세 가지가 있으며, 이들은 서로 대체 가능하지 않습니다:

• 모델이 더 오래 장황하게 말하도록 한다. 저렴합니다. 또한 일부 모델이 불필요한 우회로를 3,000 토큰 이상 이야기하다가 정답을 스스로 무효화하는 이유이기도 합니다.
• N개의 답변을 생성하고 투표한다. 병렬적이고 간단하며, 이미 가지고 있는 인프라에 연결됩니다. 또한: 성능 저하(drop off)가 빠릅니다. 특정 N을 넘어서면, 약간의 이득을 위해 GPU 초를 소모하게 됩니다.
• 부분적인 추론 단계들의 트리를 검색하고, 검증기(verifier)를 사용하여 나쁜 가지들을 일찍가지치기한다. 단연코 가장 컴퓨팅 효율적인 옵션입니다. 또한 여러분의 서빙 스택(serving stack)을 조용히 망가뜨리는 원인이기도 합니다.

대부분의 실제 시스템은 이 세 가지를 모두 수행하게 됩니다. 기본적으로는 저렴하지만, 자신감 점검(confidence check)이 '이건 어려워'라고 말할 때만 비용을 늘립니다. 그 증폭 결정 자체가 또 하나의 아키텍처 조각입니다. 대부분의 팀들은 이것을 나중에 덧붙이는 방식으로 처리합니다. 하지만 그래선 안 됩니다.

여러분의 서빙 스택은 이를 위해 만들어지지 않았습니다

연속 배치(Continuous batching), 페이지드 KV-캐시(Paged KV-cache), 추측 디코딩(Speculative decoding) 등 이 모든 인프라는 요청들이 독립적이고, 길이가 비슷하며, 한 번에 완료된다고 가정합니다.

테스트 시간 컴퓨팅은 이러한 모든 가정을 위반합니다:

• 검색 요청이 부모의 캐시를 공유하는 자식들을 생성합니다. 이것을 놓치면, 하나의 쿼리당 같은 접두사(prefix)를 수백 번 재계산하게 됩니다.
• 길이가 매우 이봉분포적(bimodal)으로 변합니다. 쉬운 쿼리는 빠르게 끝나지만, 어려운 쿼리는 수십 개의 긴 스레드로 분기됩니다. 중앙값에 맞춰 스케줄러를 조정하면, 긴 꼬리 부분(long tail)을 기아 상태로 만들거나 처리량(throughput)을 잡아먹게 할 것입니다.
• 하나의 '요청'이 이제 여러 모델에 접촉합니다: 생성기(generator), 검증기(verifier), 어쩌면 라우터(router). 이것은 단일 호출이 아니라 분산 파이프라인입니다.

만약 이전에 추측 디코딩을 구축해 본 적이 있다면, 검색 브랜치 전반에 걸쳐 KV-캐시를 포크하는 것이 익숙하게 느껴질 것입니다. 이는 여전히 '공유 접두사, 분기된 접미사(shared prefix, divergent suffix)' 문제입니다. 다만 훨씬 더 긴 범위에 걸쳐 펼쳐져 있으며, 캐시 관리를 잘못하면 훨씬 더 많은 것을 잃게 됩니다.

실제적인 변화

스케일링 법칙은 모델이 사용자를 만나기 전에 돈을 어떻게 쓸지 알려주었습니다. 테스트 시간 컴퓨팅은 더 어려운 질문을 던집니다: 검색 프로세스가 스스로의 심판관을 속이는 법을 조용히 가르치지 않으면서, 실제 시간에 쿼리당 돈을 어떻게 쓸 것인가?

이것은 프롬프팅 트릭이 아닙니다. 이것은 정렬 문제(alignment problem)가 내장된 추론 아키텍처이며, 사전 학습(pretraining)에 5년 동안 쏟아부었던 것과 동일한 엄격함을 받을 자격이 있습니다.