Chiko IT
AI 코딩 도구

AI 전력 비용 1,000배 절감 주장 — 진짜 가능한지 따져봤다

Chiko
11min read

목차

변경 전과 변경 후, 한눈에

특히, 오늘 한 일은 단순하다. AI 추론 비용에 대한 머릿속 모델을 업데이트했다. 헤드라인을 보고 반사적으로 "에이 마케팅 카피겠지"라고 넘긴 게 찜찜해서, 자료를 끝까지 따라가 봤다. 결과를 표 하나로 먼저 박아둔다.

구분 변경 전 (어제까지의 기본 가정) 변경 후 (자료 정리 후)
절감 상한 인식 양자화 단독으로 4~8배가 한계 기법 조합 시 두 자릿수 후반~세 자릿수까지 보고 사례 존재
1,000배 주장에 대한 태도 마케팅 카피로 자동 분류 조건부 가능, 다만 비교 기준이 사실상 전부
주요 기법 목록 INT8 양자화, 모델 다이어트 양자화 + MoE 라우팅 + 증류 + 추측 디코딩 + KV 캐시 압축
의사결정 기준 "정확도 손실 5%p 이내" 한 줄 토큰 단가 / 지연 / 정확도 / 운영 부담 4축

물론, 전 Databricks AI 책임자급 인물이 했다는 발언으로 헤드라인이 돌았다. 1,000배라는 숫자가 너무 컸다. 진위는 출처마다 조금씩 다르게 옮겨져 있어서 단정하지 않는다. 다만 그 숫자가 어디서 나오는지, 어떤 조건에서 성립하는지는 따져볼 가치가 있었다. 아래는 그 메모다.

1,000배 주장의 출처를 따라가본다

어떤 모델과 어떤 모델을 비교한 건가

1,000배라는 숫자는 거의 대부분 극단적인 두 점 사이의 비율이다. 기준점이 GPT-4급 풀 크기 모델의 단일 토큰 추론이고, 비교점이 task-specific 소형 모델의 배치 추론이라면 1,000배는 산술적으로 그릴 수 있는 범위다. 작은 모델은 활성 파라미터 수가 한 자릿수 ~ 두 자릿수 배수로 작고, 그 위에 양자화로 2~4배, KV 캐시·배치 최적화로 2~3배가 더 붙는다. 곱셈을 따라가면 600~1,200배가 한 줄로 떨어진다.

문제는 이게 같은 작업을 두고 한 비교가 아닐 수 있다는 점이다. 800B 모델로 풀던 자유 텍스트 생성을 7B 모델 + 도메인 fine-tune으로 좁히면 비용은 세 자릿수 배 떨어지지만, 그건 "비용을 줄였다"기보다 "문제를 바꿨다"에 가깝다. 작은 모델이 큰 모델과 동일한 범용 능력을 갖춘다는 뜻이 전혀 아니다. 헤드라인을 옮길 때 이 단서가 가장 먼저 휘발된다.

단위가 전력인지 비용인지

또 하나 헷갈리는 지점이 "전력"과 "비용"의 차이다. 데이터센터 단가 기준이라면 전력이 비용으로 거의 그대로 환산되지만, 사용자 입장의 토큰 단가는 GPU 종류, 가동률, 마진, 캐시 히트율까지 섞인 숫자다. 1,000배 절감을 전력(kWh) 기준으로 말한 건지, GPU 시간 기준인지, API 청구서 기준인지에 따라 같은 숫자가 다른 의미를 가진다.

특히 "전력"이라고 표기된 비교는 추론 한 번에 들어가는 J(줄) 단위로 측정한 경우가 많다. 그런데 실서비스에서는 모델 로드, 워밍업, idle 상태의 전력까지 다 비용이다. idle 전력을 빼고 token-당 J만 비교하면 숫자는 훨씬 크게 떨어진다. 이건 거짓말은 아닌데, 운영하는 입장에서 보면 절반의 그림이다.

시점 한정과 빠진 가정

2026년 6월 기준으로 정리해두면, 추론 효율을 끌어올리는 데 자주 인용되는 사례는 다음 조합이 흔하다.

  • 풀 모델 → MoE로 활성 파라미터 비율을 1/8 이하로 제한
  • FP16 → INT8 또는 INT4 양자화
  • 직접 디코딩 → 추측 디코딩(speculative decoding)
  • 단일 요청 → 동적 배치 + KV 캐시 압축

이처럼, 각 단계가 단독으로는 1.5~5배 정도 효율을 끌어올린다. 곱하면 두 자릿수 후반에서 세 자릿수 초반이 나온다. "1,000배"는 여기에 모델 크기 자체를 1/100로 줄이는 단계까지 끼워 넣었을 때의 숫자로 보인다. 즉, 동치인 비교가 아니라 "추론 인프라 전체를 갈아엎었을 때의 상한"에 가깝다.

예를 들어, 발언자가 그걸 의도했는지는 옮긴 매체마다 뉘앙스가 다르다. 그래서 인용할 때는 "1,000배"보다 "조합 최적화 시 세 자릿수 배 절감이 보고된다" 정도로 인용하는 게 안전해 보인다.

새로 알게 된 것 — 실제로 쓸 수 있는 절감 기법

오늘 머리에 정리한 부분이다. 각 기법이 단독으로 몇 배 절감되는지보다, 조합했을 때 곱셈으로 줄어드는 구조를 이해하는 게 핵심이라는 걸 늦게 알았다. 자주 듣는 단어들이라 다 안다고 착각했는데 실제로는 라우팅 오버헤드, 메모리 비대칭 같은 단서를 다 빼먹고 있었다.

양자화: 손쉽지만 한계가 명확하다

INT8은 FP16 대비 메모리·연산을 절반 이하로 줄인다. INT4까지 가면 또 한 번 절반. 추론 품질 손실은 모델·태스크에 따라 다르지만, 7B~13B 모델에서는 INT8까지는 거의 무손실에 가까운 것으로 보고된다(출처: bitsandbytes 0.43.x 이후 문서).

# transformers + bitsandbytes로 8-bit 로딩
from transformers import AutoModelForCausalLM, BitsAndBytesConfig

bnb_config = BitsAndBytesConfig(
    load_in_8bit=True,
    llm_int8_threshold=6.0,  # 이상치(outlier) 분리 임계값
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3-8B",
    quantization_config=bnb_config,
    device_map="auto",
)
# 메모리 점유: 약 16GB → 8GB 근처로 떨어진다

그런데, 다만 양자화는 한 모델 안에서 곱셈 효과가 잘 안 붙는다. 4비트 아래로 가면 정확도 손실이 가파르게 커진다. 그래서 양자화는 "4~8배 정도 안정적으로 가져가는 기본기"로 두고, 그 위에 다른 기법을 쌓는 게 정석이다. 양자화만으로 100배를 만들겠다는 글은 일단 의심하면서 본다.

MoE 라우팅: 활성 파라미터 비율이 핵심

Mixture of Experts는 전체 파라미터는 크게 유지하되, 입력마다 일부 expert만 활성화한다. 활성화 비율이 1/8이면 같은 출력을 내는 데 드는 연산이 산술적으로 1/8이 된다. 실제로는 라우팅 오버헤드 때문에 1/5~1/6 정도로 보면 무리가 없다.

문제는 메모리다. 전체 모델은 그대로 GPU에 올라가 있어야 해서, 연산(=전력)은 줄지만 메모리 비용은 그대로다. 1,000배 주장을 평가할 때 이 부분을 빼먹으면 안 된다. "전력 1,000배 절감"과 "운영 비용 1,000배 절감"이 같은 의미가 되려면 메모리·인프라까지 비례해서 줄어야 하는데, MoE는 그 구도를 만들지 않는다.

즉, 이걸 무시한 비교를 한 번 본 적이 있다. 활성 파라미터만 가지고 "8B 모델과 동급"이라고 주장하면서 실제로는 100B를 GPU에 올려놓는 식이었다. 토큰 단가는 매력적인데 시설비가 그대로라 절감이 거의 안 됐다.

추측 디코딩: 작은 모델이 큰 모델을 가속한다

작은 draft 모델이 토큰 여러 개를 미리 뽑고, 큰 verifier 모델이 한 번에 검증한다. 같은 출력을 내면서 디코딩 호출 횟수를 2~3배 줄인다. vLLM 0.5 이후로 비교적 안정적으로 들어왔다(출처: vLLM Release Notes v0.5.x 이후).

# vLLM 추측 디코딩 설정 예시
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3-70B-Instruct",
    speculative_model="meta-llama/Llama-3-8B-Instruct",
    num_speculative_tokens=5,
    use_v2_block_manager=True,
)

sampling = SamplingParams(temperature=0.2, max_tokens=512)
# 큰 모델 단독 대비 처리량 1.8~2.5배 향상이 보고된다

한편, 체감상 가장 가성비 좋은 기법이다. 모델 자체를 손 안 대고 처리량만 끌어올린다. draft 모델만 잘 고르면 정확도 손실도 사실상 없다(verifier가 마지막에 확인하기 때문이다). 운영에 들어가 있는 70B 모델을 그대로 두고 적용할 수 있다는 게 가장 큰 장점이다.

단점은 temperature가 높거나 sampling 다양성이 큰 워크로드에서는 가속 효과가 떨어진다는 점이다. 챗봇처럼 자유로운 대화보다, 코드 생성·요약처럼 비교적 결정적인 작업에서 효과가 크다.

지식 증류: 모델 자체를 바꾼다

결국, 큰 teacher 모델의 출력 분포를 작은 student 모델이 학습한다. 같은 태스크라면 student 모델은 teacher의 1/10~1/100 크기로도 90% 이상 성능을 내는 사례가 흔하다(출처: Hinton et al. 2015 이후 누적된 distillation 연구, 그리고 최근 2024~2025년의 LLM distillation 논문들).

이게 1,000배 주장의 진짜 재료다. 단 증류는 태스크가 좁아야 동작한다. 범용 챗봇을 만들고 싶다면 증류만으로 1/100 모델을 못 만든다. 반대로 "법률 문서 요약", "특정 도메인 QA"처럼 좁은 태스크라면 1/50~1/100 모델이 teacher 성능의 95%까지 따라온다는 보고가 있다. 그 조건이면 전력은 정말로 두세 자릿수 배로 떨어진다.

증류의 비용은 한 번에 청구된다. teacher로 합성 데이터를 뽑고 student를 학습시키는 단계 자체가 무겁다. 모델이 자주 바뀌는 환경(매 분기 모델 교체)이라면 증류 비용이 절감액을 잡아먹는다. 1,000배 주장에는 이 학습 비용이 보통 빠져 있다.

메모: 오늘 추가한 검토 체크리스트

추론 비용 절감 제안서를 볼 때 머릿속에서 돌릴 질문 목록을 정리해둔다. 다음에 비슷한 헤드라인을 볼 때 그대로 꺼내 쓸 거다.

비교 기준 4축

[1,000배 절감 주장 검토 체크리스트]

1. 비교 기준이 무엇인가
   - 같은 모델의 다른 구성인가
   - 다른 모델 두 개의 비교인가
   - 다른 태스크 정의를 비교한 건 아닌가 (가장 흔한 함정)

2. 단위가 무엇인가
   - 전력(kWh / J per token)인가
   - GPU 시간인가
   - API 토큰 단가인가
   - idle 전력을 포함했는가

3. 측정 환경이 명시되어 있는가
   - 배치 크기, 컨텍스트 길이
   - 하드웨어 종류와 가동률
   - 측정 시점(라이브러리 버전, 날짜)

4. 빠진 비용은 없는가
   - 학습/증류 비용
   - 운영 인력 비용
   - 모델 업데이트 주기 비용
   - 정확도 회귀로 인한 클레임·운영 비용

한편, 이 네 가지 중 하나라도 흐릿하면 그 숫자는 마케팅 카피로 분류한다. 1,000배든 100배든 마찬가지다. 반대로 네 축이 다 명시되어 있고 재현 조건까지 공개돼 있으면 1,000배도 진지하게 본다.

빠진 비용 항목

가장 자주 누락되는 항목은 운영 비용이다. 비용을 100배 줄였는데 정확도가 5%p 떨어졌다면, 그 5%p가 운영팀의 일감을 얼마나 늘리는지를 같이 봐야 한다. 모델이 헛소리하는 케이스 1%가 늘면 클레임 처리 비용이 비례해서 늘어난다. 절감액을 운영팀이 다 까먹는 구조를 본 적이 있어서 이건 꼭 메모해둔다.

실제로, 증류 비용도 자주 빠진다. teacher 모델을 호출해서 합성 데이터를 만드는 단계는 한 번에 수십만 토큰을 뽑는다. 이건 추론 비용으로 잡히지만 절감 사례에는 보통 포함되지 않는다. 모델 교체 주기가 짧으면 이 비용이 계속 청구된다.

정확도 회귀 추적

정확도 회귀를 그래프로 띄워놓고 절감 사례를 같이 보는 습관이 필요하다고 느꼈다. 비용 절감 슬라이드의 옆 칸에 정확도 분포(p50, p95, worst-case)를 같이 박아두면, 의사결정이 훨씬 깔끔해진다. 평균만 보면 비용 1/100 모델이 매력적이지만, p95 정확도가 무너지면 운영 부담은 비용 절감보다 더 크게 늘어난다.

당장 할 만한 것 세 가지

  • 운영 중인 LLM 추론에 vLLM 추측 디코딩을 켜본다. 모델 교체 없이 처리량 2배 안팎을 노릴 수 있다(출처: vLLM 공식 문서 speculative decoding 섹션).
  • 7B~13B 모델은 INT8 양자화부터 적용한다. 정확도 손실이 거의 없어 가장 안전한 첫 수순이다.
  • 비용 절감 제안서를 볼 때 위의 4축 체크리스트를 그대로 꺼내본다. 항목 하나라도 빠지면 숫자를 곧이듣지 않는다.

그런데, 개인적으로는 1,000배라는 헤드라인을 놓고 진위를 다투기보다, **"우리 환경에서 곱셈으로 묶을 수 있는 기법이 몇 개인가"**를 세는 쪽이 훨씬 실용적인 것 같다. 양자화 4배, 추측 디코딩 2배, 배치·캐시 최적화 2배만 곱해도 16배다. 1,000배는 못 가더라도 두 자릿수 배는 사실상 누구나 닿을 수 있는 범위로 보인다.

관련 글

More posts