핵심 요약

  • 모델의 경제성을 따질 때는 일회성 학습뿐 아니라 서비스 기간 내내 반복되는 추론 비용을 봐야 한다. 학습보다 추론이 12배 중요하다는 계산도 특정 사용량과 모델 수명을 전제로 한다.
  • 추론 성능은 GPU 사양만으로 결정되지 않는다. 요청 배분, 이전 계산의 재사용, 작업 묶음 구성, 메모리 관리가 함께 작동해야 한다.
  • 같은 공개 모델이라도 제공업체의 양자화와 도구 호출 처리, 추론 엔진 설정에 따라 응답 품질이 달라질 수 있다.
  • 비용을 절감할 때는 실제 작업의 품질도 함께 검증해야 한다. 공개 벤치마크, 고객별 평가, 가벼운 상시 감시는 서로 다른 문제를 찾는다.

학습이 끝난 뒤 시작되는 비용 경쟁

Y Combinator의 이번 페이퍼 클럽은 Together AI, Ollama, Luminal과 SGLang 관계자들이 AI 추론 시스템을 설명한 기술 발표 자리다. 학습을 마친 모델이 사용자 요청에 답하는 과정인 추론을 어떻게 더 저렴하고 빠르게 실행하면서 품질을 지킬지가 논의의 중심이었다.

도입 발표자는 DeepSeek V3의 학습과 서비스 운영에 쓰인 GPU 시간을 비교했다. 학습에는 약 280만 H800 시간이 들었고 추론에는 하루 약 4만3,000 H800 시간이 쓰였다는 공개 수치를 인용했다. 이를 연간으로 환산하면 추론에 쓰는 연산량이 학습의 약 6배이며 같은 모델 가중치를 2년간 사용한다고 가정하면 약 12배가 된다는 계산이다.

이 숫자는 모든 모델에 적용되는 비율이 아니다. 발표자는 해당 사용량 자료가 이미 오래됐으며 모델을 쓰는 사람이 늘수록 추론의 비중도 커질 수 있다고 봤다. 학습 한 번의 비용보다 모델을 운영하는 전체 기간의 비용을 함께 계산해야 한다고 강조했다.

성능 지표도 하나로 묶을 수 없다. 첫 응답이 나오기까지의 시간, 이후 토큰 하나를 생성하는 시간, GPU당 처리량은 각각 다르다. 여기에 약속한 응답 속도를 지키며 처리한 양까지 봐야 한다. 총처리량이 높아도 개별 사용자가 오래 기다리면 같은 성능이라고 할 수 없다.

GPU를 늘리기 전에 이미 한 계산을 찾아야 한다

Together AI 연구 책임자 댄 푸는 요청이 데이터센터에 도착한 뒤 어느 GPU로 향하는지부터 성능 차이가 생긴다고 설명했다. 일반적인 웹 서비스처럼 한가한 서버로 보내는 것만으로는 충분하지 않다. 해당 요청에 필요한 이전 계산을 어느 GPU가 갖고 있는지도 살펴야 한다.

여기서 중요한 것이 KV 캐시다. 모델이 앞선 문맥을 처리하며 계산한 정보를 보관해 다음 요청에서 재사용하는 장치다. 코딩 에이전트가 처음에 코드베이스 전체를 보낸 뒤 짧은 추가 지시를 계속 받는다면 매번 처음부터 처리할 필요가 없다. 반대로 서로 관계없는 새 대화를 반복하면 재사용할 여지가 줄어든다.

추론 내부에도 성격이 다른 두 단계가 있다. 입력 문맥을 한꺼번에 처리하는 프리필은 연산 능력의 영향을 크게 받는다. 이후 토큰을 하나씩 생성하는 디코드는 모델 가중치를 메모리에서 읽어 오는 속도가 병목이 되기 쉽다. 푸는 이런 차이 때문에 두 단계를 서로 다른 GPU에 배치하거나 다른 실행 방식을 적용한다고 설명했다.

여러 요청을 묶는 스케줄러도 제품 경험에 영향을 준다. 같은 GPU로 더 많은 사용자를 처리할지, 각 사용자에게 더 빠르게 답할지에 따라 선택이 달라진다. 추론 최적화는 추상적인 최대 속도가 아니라 실제 요청의 길이, 반복 패턴, 허용 대기 시간에서 출발한다.

병렬화와 양자화에는 각각 다른 대가가 있다

큰 모델을 여러 GPU에 나누면 더 많은 연산 능력과 메모리 대역폭을 활용할 수 있다. 푸는 행렬 계산을 나누는 텐서 병렬화, 모델의 층을 나누는 파이프라인 병렬화, 서로 다른 입력을 분산하는 데이터 병렬화를 소개했다.

고속 연결 범위가 커지면 새로운 배치도 가능해진다. 그는 72개 GPU를 높은 대역폭으로 연결하는 랙에서 모델 안의 여러 전문가 모듈을 서로 다른 GPU에 배치할 수 있다고 설명했다. 한 GPU가 담당하는 전문가에 충분한 토큰이 모이면 GPU가 잘 처리하는 큰 행렬 연산 형태에 가까워진다.

연결 규모가 커지면 장애의 영향도 커진다. 모델 하나가 GPU 72개에 의존하는 상황에서 복구 설계가 부족하면 GPU 한 개의 고장으로 전체 모델 실행이 멈출 수 있다. 푸는 처리량 향상과 함께 장애가 나도 서비스를 이어 가는 설계에 투자하고 있다고 밝혔다.

양자화는 또 다른 절충이다. 모델의 수치를 저장하는 비트 수를 줄여 메모리와 처리 비용을 아끼는 기법이다. 푸는 16비트로 학습한 모델을 8비트나 4비트로 줄일 수 있지만 최종 응답 품질을 확인하는 일이 중요하다고 강조했다.

Together AI는 공개 벤치마크 외에도 모델이 플래피 버드 게임을 반복해서 구현하게 하고 실제 도구 호출과 에이전트 작업을 시험한다. 양자화 뒤 게임이 작동하지 않거나 도구를 제대로 쓰지 못하면 원인을 추적한다. 푸는 원래 학습 데이터 전체가 없는 상태에서 추가 학습을 하면 모델이 일부를 잊을 수 있어 자사에서는 추가 학습 없이 양자화하는 방식을 쓴다고 설명했다.

같은 모델 이름이 같은 응답을 보장하지 않는다

Ollama 공동창업자 겸 CEO 제프리 모건은 공개 모델을 여러 제공업체에서 받아 쓰는 구조의 어려움을 짚었다. 사용자는 같은 모델 이름을 선택했다고 생각하지만 실제 서비스에는 서로 다른 정밀도의 가중치, 추론 엔진, 샘플링 방식과 도구 호출 처리가 들어갈 수 있다.

문제는 단순한 답변 정확도에 그치지 않는다. 도구 호출의 이름과 인자가 정해진 형식을 따르는지, 실패한 호출을 복구하는지, 긴 문맥에서도 제대로 작동하는지가 모두 영향을 준다. 모건은 제공업체에 따라 모델 이름이 잘못 붙거나 문맥 길이가 제한되는 경우도 있다고 설명했다.

이 차이는 여러 단계를 연속 수행하는 에이전트에서 더 커진다. 한 번의 응답 오류가 뒤 단계의 입력으로 이어지기 때문이다. 모건은 매 단계 10%의 오류 가능성이 있는 15단계 작업을 예로 들어 전체 작업에서 오류가 발생할 가능성이 약 79%까지 커질 수 있다고 설명했다.

그가 제시한 검증 방법에는 각각 한계가 있다. 종합 벤치마크는 품질 문제를 폭넓게 찾지만 비용과 시간이 많이 든다. 기준 모델과 출력 분포를 비교하는 검사는 상대적으로 저렴하지만 문제의 원인까지 알려주지는 못한다.

다음 토큰의 확률 정보를 뜻하는 로그 확률을 과거 기준값과 비교하면 추론 엔진 교체나 설정 변경 뒤 응답 특성이 달라졌는지 저렴하게 감시할 수 있다. 다만 이 정보를 제공하지 않는 API가 있고 처음부터 품질이 나빴다면 과거와 같다는 사실만으로는 충분하지 않다.

도구 호출 실패율과 출력 길이 같은 요청의 형태도 신호가 된다. 모건은 공개 평가에만 맞춘 최적화를 걸러내기 위해 고객의 실제 용도와 데이터에 맞춘 비공개 평가도 활용한다고 밝혔다.

컴파일러가 바꾸는 GPU 시간의 가치

Luminal 공동창업자 겸 CEO는 모델 계산을 하드웨어 실행 코드로 바꾸는 컴파일러가 GPU 시간을 얼마나 많은 토큰으로 전환할지 결정한다고 설명했다. 회사는 모델마다 사람이 실행 규칙을 정교하게 만드는 대신 여러 실행 형태를 탐색하는 접근을 택했다.

핵심 기술은 동등성 포화다. 같은 계산을 뜻하는 여러 표현을 지우지 않고 함께 보관한 뒤 실행 후보를 찾는 방식이다. Luminal은 복잡한 모델 연산을 덧셈, 곱셈, 합산 같은 약 14~15개 기본 연산으로 분해하고 이를 각 하드웨어가 지원하는 연산과 연결한다.

후보의 성능은 실제 하드웨어에서 실행해 측정한다. 모든 후보를 무작정 실행하는 것은 아니다. 데이터 이동량과 가능한 성능의 상한을 따져 이미 측정한 후보보다 느릴 수밖에 없는 경우는 일찍 제외한다.

컴파일 시간을 더 쓰는 대신 반복 실행 비용을 낮추는 선택도 가능하다. 발표자는 한 번 컴파일한 모델을 대규모로 서비스한다면 실행 속도의 몇 퍼센트 차이가 긴 컴파일 시간을 정당화할 수 있다고 봤다. 사용자가 시간 예산을 정하고 탐색의 추가 이득이 줄어드는 시점까지 최적화하는 방식이다.

이 접근의 범위도 분명히 했다. Luminal은 모델의 한 차례 순방향 계산을 최적화하며 추측 디코딩처럼 그 바깥에서 작동하는 기능은 vLLM이나 SGLang 같은 추론 엔진에 맡긴다. 계산 순서를 바꾸면 수치 정확도가 달라져 토큰 품질에 영향을 줄 수 있으므로 빠른 코드뿐 아니라 수치 정확도를 명시적으로 다루는 일도 필요하다고 설명했다.

에이전트의 긴 문맥을 다루는 메모리 설계

SGLang 측 발표자는 여러 에이전트가 긴 공통 문맥을 공유하는 상황에서 출발했다. 각 에이전트가 짧은 지시를 주고받을 때 공통 부분까지 계속 계산하지 않도록 입력 앞부분을 나무 구조로 관리하는 RadixAttention을 설계했다.

재사용은 저장만으로 해결되지 않는다. 공통 문맥이 같은 요청을 가까이 처리하면 캐시를 더 잘 활용할 수 있지만 서로 다른 문맥의 요청을 번갈아 처리하면 필요한 캐시가 먼저 밀려날 수 있다. 메모리 관리와 요청 순서를 함께 설계해야 하는 이유다.

GPU 메모리만으로는 몇 분이나 몇 시간 뒤 돌아오는 요청의 문맥을 모두 보관하기 어렵다. 발표자는 GPU 메모리, 호스트 메모리, 저장장치를 연결하는 계층형 캐시를 소개했다. 필요한 정보를 어느 계층에 남기고 얼마나 빨리 다시 가져올지가 중요하다.

모델 구조가 섞이면 관리도 복잡해진다. 전체 문맥을 보는 층, 최근 일부만 보는 슬라이딩 윈도 층, 정보를 고정된 크기의 상태로 압축하는 순환형 층은 재사용 조건이 다르다. SGLang은 이를 통합 트리로 조율하고 요청의 문맥 길이에 맞춰 메모리를 유연하게 나누는 방식을 설명했다. 할당과 회수 뒤 생긴 빈틈은 데이터를 재배치하고 메모리 매핑을 바꿔 다시 쓸 수 있게 한다.

발표자들은 공통으로 추론의 경제성이 모델 하나의 특성으로 결정되지 않는다고 설명했다. 같은 가중치를 쓰더라도 이전 계산을 얼마나 재사용하고 하드웨어에 어떻게 배치하며 품질 변화를 얼마나 빨리 발견하느냐에 따라 비용과 사용자 경험이 함께 달라진다.