1,000토큰당 16센트. 이것이 대략 A100 GPU에서 Llama 3 70B를 16비트 풀 정밀도로 프로덕션 서빙하는 데 드는 비용이다. 표준 4비트 양자화 버전으로 내리면 약 4센트 정도다. 같은 아키텍처, 같은 가중치, 같은 답변. 대체로는.

이제 TurboQuant라는 프로젝트가 등장해 4비트를 훌쩍 넘어 2비트 이하 영역까지 밀어붙일 수 있다고 주장한다. 품질 저하는 "무시할 수준"이라고 설명한다. 그리고 이어진 Hacker News 스레드는 올해 내가 본 것 중 가장 흥미로운 실시간 동료 검증 현장이 되었다.

TurboQuant가 실제로 주장하는 것

핵심 제안은 간단하다. TurboQuant는 혼합 정밀도 양자화와 학습된 코드북 압축을 결합하여 대형 언어 모델의 파라미터 크기를 약 80% 줄인다. 일반적으로 4비트 정밀도 이하로 내려가면 품질이 급격히 떨어지는 GPTQ나 AWQ 같은 표준 학습 후 양자화 도구와 달리, TurboQuant는 특정 모델 레이어를 1.5~2비트까지 낮추면서 민감도가 요구되는 다른 레이어는 더 높은 정밀도를 유지할 수 있다고 주장한다.

핵심 기술적 주장은 이렇다. 적응형 레이어 민감도 분석이 모델의 어떤 부분이 공격적인 압축을 견딜 수 있고 어떤 부분이 견딜 수 없는지를 결정한다. 어텐션 헤드와 출력 프로젝션 레이어는 높은 비트 폭을 유지한다. 트랜스포머 아키텍처에서 파라미터 수의 대부분을 차지하는 피드포워드 레이어가 가장 강하게 압축된다.

프로젝트의 공개 벤치마크에 따르면, TurboQuant로 압축된 Llama 3 70B는 원본 모델의 MMLU 점수 대비 1.2% 이내의 성능을 보이면서 약 14GB의 VRAM에 들어간다. 참고로, 풀 정밀도 모델은 약 140GB가 필요하다. 표준 4비트 GPTQ 버전은 약 35GB다.

메울 수 있다고 주장하기엔 상당히 대담한 격차다.

Hacker News 스트레스 테스트

Show HN 게시물이 올라간 지 몇 시간 만에 스레드는 실시간 벤치마크 실험실이 되었다. 개발자들이 TurboQuant 코드를 받아 자체 평가 도구로 돌리고 결과를 게시했다.

초기 반응은 세 진영으로 나뉘었다.

첫 번째 진영은 소규모 모델에서 방향적으로 유사한 결과를 확인했다. 여러 댓글 작성자들이 TurboQuant로 압축된 Mistral 7B와 Phi-3 버전이 코딩 벤치마크에서 4비트 버전에 놀랍도록 근접한 성능을 보이면서 메모리 사용량은 상당히 적다고 보고했다. 소비자용 RTX 4090에서 추론을 실행한 한 댓글 작성자는 이전에 듀얼 GPU 구성이 필요했던 모델을 로드할 수 있게 되었다고 언급했다.

두 번째 진영은 방법론적 문제를 제기했다. 다수의 사용자들이 MMLU 점수만으로는 프로덕션에서 중요한 종류의 성능 저하를 포착할 수 없다고 지적했다. 추론 체인이 끊어진다. 명령어 따르기가 흐릿해진다. 40개 이상의 추천을 받은 특히 상세한 댓글 하나는 TurboQuant로 압축된 Llama를 다단계 수학 문제 모음으로 테스트했는데, 표준 4비트 버전 대비 6~8%의 정확도 하락을 발견했다 — 치명적이지는 않지만 "무시할 수준"도 아니다.

세 번째 진영, 그리고 내가 가장 흥미롭게 보는 진영은 숫자에 대해 전혀 논쟁하지 않았다. 그들은 프레이밍에 대해 논쟁했다. 한 댓글 작성자가 이렇게 표현했다: "우리는 양자화된 모델을 계속 풀 정밀도 원본과 비교하고 있다. 진짜 질문은 압축된 70B 모델이 같은 컴퓨팅 비용에서 풀 정밀도 7B 모델을 능가하느냐다. 그것이 경제적으로 의미 있는 비교다."

그 댓글 작성자가 핵심을 짚었다.

실제 비용 산술

이 섹션은 내가 항상 쓰는 부분인데, 이번에는 수학이 정말로 흥미로워진다.

하루에 1,000만 토큰을 처리하는 추론 워크로드를 운영한다고 가정하자. 대단한 규모가 아니다 — 수천 명의 활성 사용자가 AI 기능을 사용하는 중간 규모 SaaS 제품 정도다.

A100(80GB)에서 16비트 풀 정밀도로 운영하면 Llama 3 70B를 넣기 위해 GPU 2장이 필요하다. 주요 클라우드의 온디맨드 가격이 GPU 시간당 약 $2.50이니, 시간당 $5.00, 하루 $120, 월 약 $3,600이 컴퓨팅 비용만으로 든다.

표준 4비트 GPTQ 양자화에서는 A100 한 장에 여유 있게 들어간다. 이것만으로 기본 컴퓨팅 비용이 월 $1,800으로 줄어든다 — 이미 의미 있는 절감이다.

TurboQuant가 주장하는 압축 수준에서는 대부분의 클라우드에서 시간당 약 $0.65인 L4 GPU 한 장에 모델을 넣을 수 있을 것이다. 월 약 $470이다.

$3,600에서 $470으로. 서빙 비용 7.6배 절감이다.

하지만 여기서 까다로워진다 — 그리고 HN의 회의론자들이 일리가 있는 부분이기도 하다. 복잡한 추론 작업에서 6~8% 정확도를 잃고 있다면, 사용자가 올바른 답에 도달하기 위해 더 많은 토큰이 필요할 수 있다. 재시도 루프, 더 긴 프롬프트, 모델 약점을 보완하기 위한 사고 연쇄 스캐폴딩. 공격적인 양자화로 컴퓨팅을 60% 절감했지만 토큰 소비가 40% 증가해서 실제 절감 효과는 훨씬 작아진 프로덕션 시스템을 본 적이 있다.

정직한 수학 — "실제로 지불하게 될 금액" 수학 — 은 워크로드 프로필에 달려 있다. 분류, 요약, 단순 추출 작업을 하고 있다면, TurboQuant의 압축은 광고된 절감 효과의 대부분을 전달할 것이다. 이런 작업들은 양자화 노이즈에 강하다. 다단계 추론, 코드 생성, 또는 일관된 논리 체인이 필요한 작업을 하고 있다면, 더 높은 토큰 소비를 예산에 반영하고 도입 전에 공격적으로 테스트하라.

양자화는 그 자체로 하나의 엔지니어링 분야가 되어가고 있다

이 특정 도구가 모든 주장을 이행하는지와는 별개로, TurboQuant 이야기가 정말로 시사하는 바는 이것이라고 생각한다.

2년 전만 해도 양자화는 배포 단계의 부수적 작업이었다. 모델을 훈련하고, 출시하고, 너무 크면 GPTQ나 bitsandbytes로 돌려보고 잘 되기를 바랐다. 양자화를 하는 사람과 배포를 하는 사람이 같았다. 전문적인 작업이 아니었다.

이것이 빠르게 바뀌고 있다.

지난 12개월 동안만 벌어진 일을 생각해 보라. GGUF가 자체 도구 생태계를 갖춘 사실상의 포맷 표준이 되었다. 캘리브레이션 데이터셋 선택 자체가 연구 주제가 되었다 — 양자화 중 사용하는 데이터가 어떤 능력이 압축에서 살아남느냐에 극적인 영향을 미치기 때문이다. 서로 다른 레이어에 서로 다른 비트 폭을 부여하는 혼합 정밀도 전략이 학술적 호기심에서 프로덕션 관행으로 전환되었다. 그리고 이제 TurboQuant가 신호 처리 분야의 기법을 차용해 학습된 코드북 압축을 대화에 끌어들이고 있다.

이것은 더 이상 배포가 아니다. 자체적인 지식 체계, 자체적인 실패 모드, 자체적인 비용 모델을 갖춘 독립적인 엔지니어링 분야다.

2000년대에 데이터베이스 관리에서 일어난 일과 비교하겠다. 수년간 "개발자"가 데이터베이스도 관리했다. 그러다 워크로드가 충분히 복잡해지면서 조직들이 전담 DBA를 고용하기 시작했다 — 작업 자체가 절대적으로 더 어려워서가 아니라, 잘못했을 때의 비용이 전문화를 정당화할 만큼 높아졌기 때문이다.

모델 압축도 그 변곡점에 다가가고 있다. 잘 양자화된 모델과 잘못 양자화된 모델의 차이가 월 수천 달러의 서빙 비용으로 이어질 때 — 또는 단일 GPU에 넣느냐 클러스터가 필요하냐의 차이로 이어질 때 — 양자화를 제대로 하는 것에 대한 ROI가 전담 전문성을 정당화한다.

회의론자의 논거와 신봉자의 논거

TurboQuant에 구체적으로 회의적이라면, 합당한 이유가 있다. 벤치마크 모음이 좁다. 프로젝트가 초기 단계다. 2비트 이하 양자화는 선별된 평가에서는 좋아 보이다가 다양한 실제 입력에서 무너지는 오랜 역사가 있다. HN 스레드는 프로젝트 자체 벤치마크가 포착하지 못한 여러 실패 모드를 발견했다.

낙관적이라면, 역시 합당한 이유가 있다. 적응형 레이어 민감도 분석과 학습된 코드북을 결합한 기술적 접근 방식은 원리적으로 타당하다. 같은 방향을 탐구하는 여러 대학 연구 그룹의 최근 연구와 맥을 같이 한다. 그리고 원시적인 메모리 절감은 스레드에서 여러 독립적인 사용자들에 의해 실제로 검증되었다.

어느 진영에 합류할지 결정하는 방법은 이렇다: 벤치마크를 보지 마라. 자신의 워크로드를 보라.

프로덕션 로그를 꺼내라. 추론 호출을 작업 유형별로 분류하라. 각 카테고리의 대표 샘플에 대해 TurboQuant의 압축 모델을 실행하라. 정확도만이 아니라 성공적 완료당 토큰 소비량도 측정하라. 그다음 비용 계산을 하라.

워크로드의 80%가 추출과 요약이라면, 이것은 아마 피처 플래그 뒤에서 프로덕션 테스트를 해볼 만하다. 80%가 다단계 추론이라면, 다음 이터레이션을 기다리면서 스레드를 계속 주시하라.

앞으로 추적할 세 가지 신호

첫째, TurboQuant가 가장 공격적인 압축 수준에서 GSM8K, HumanEval 같은 추론 중심 벤치마크 결과를 공개하는지 여부다. 현재 벤치마크 공백은 눈에 띈다.

둘째, 주요 추론 프레임워크 — vLLM, TensorRT-LLM, llama.cpp — 가 TurboQuant 포맷에 대한 네이티브 지원을 추가하는지 여부다. 지금은 독립형 도구다. 서빙 스택에의 통합이 연구 프로젝트와 프로덕션 도구를 가르는 기준이다.

셋째, 이것이 가장 중요한데, 클라우드 제공업체들이 양자화 최적화 인스턴스 유형을 제공하기 시작하는지 여부다. AWS는 이미 훈련과 추론 인스턴스를 구분하고 있다. 논리적인 다음 단계는 압축된 모델 서빙에 최적화된 인스턴스다 — 낮은 메모리, 높은 컴퓨팅 밀도, 그에 맞는 가격. 이것이 실현된다면, 양자화가 배포 트릭에서 인프라 카테고리로 졸업했음을 확인시켜 주는 것이다.

모델 압축 논의는 "양자화를 해야 하는가?"를 지나 "얼마나 공격적으로 양자화할 수 있으며, 실제 비용은 얼마인가?"로 넘어갔다. TurboQuant가 그 질문에 최종적인 답을 내리는 도구가 아닐 수도 있다. 하지만 그 질문 자체가 — 지금 이 순간 Hacker News 스레드에서 수백 명의 엔지니어에 의해 실시간으로 스트레스 테스트되고 있는 — 지금 물어야 할 올바른 질문이다.