AI ANALYSIS 박종관· October 20, 2026 ·13 min

AI 추론 가속의 진짜 의미: 모델의 지능은 그대로 두고 10배 빠르게 만들 수 있을까?

가속 서빙의 원리부터 DSpark, vLLM, LithosAI까지 살펴보며 토큰 생성 속도보다 중요한 품질 보존과 실제 추론 성능의 의미를 엔지니어링 관점에서 설명한다.

AI 추론 가속의 진짜 의미: 모델의 지능은 그대로 두고 10배 빠르게 만들 수 있을까?

가속 서빙(Inference Acceleration)의 원리부터 DSpark, vLLM, LithosAI까지 — 토큰 생성 속도보다 중요한 기술적 진실

들어가며: AI가 똑똑해지는 것과 AI가 빨라지는 것은 다른 문제다

최근 AI 모델을 비교하다 흥미로운 현상을 발견했다.

동일한 계열의 모델을 제공하는 여러 API 업체의 출력 속도가 크게 다르다는 것이다. 어떤 서비스는 초당 수십 개의 토큰을 생성하는 반면, 어떤 서비스는 초당 수백 개, 특정 벤치마크에서는 1,000개가 넘는 토큰을 생성한다.

이 차이는 단순히 GPU 성능이 다르기 때문에 발생하는 것일까?

아니면 모델을 실행하는 방법 자체를 바꾸면, 모델의 지능을 희생하지 않고도 훨씬 빠른 추론이 가능하기 때문일까?

여기서 말하는 기술은 흔히 가속 서빙(Accelerated Inference Serving) 또는 추론 가속이라고 부르는 영역이다.

핵심은 모델을 더 작게 만들거나 저성능 모델로 교체하는 것이 아니다. 이미 학습된 모델의 가중치를 그대로 유지하면서, 추론을 수행하는 엔진과 하드웨어의 활용 방식을 최적화하는 것이다.

물론 모든 가속 기술이 원본과 동일한 품질을 보장하는 것은 아니다. 양자화로 정밀도를 낮추거나 일부 연산을 근사하면 속도는 빨라질 수 있지만 결과가 달라질 가능성이 있다.

반면 적절한 검증 알고리즘을 사용하는 일부 추론 가속 기법은 원본 모델의 출력 확률 분포를 보존하면서 속도를 높일 수 있다.

그렇다면 실제로 어느 정도의 가속이 가능할까? 그리고 LithosAI, Baseten, DeepInfra 같은 추론 서비스 업체는 이러한 기술을 어떻게 활용하고 있을까?

이 글에서는 그 질문을 엔지니어링 관점에서 살펴본다.

1. 먼저 알아야 할 것: LLM은 왜 느릴까?

대규모 언어 모델은 일반적으로 다음 토큰을 하나씩 생성한다.

예를 들어 모델이 다음 문장을 출력한다고 해 보자.

추론 엔진을 최적화하면 모델의 응답 속도를 높일 수 있다.

모델은 첫 번째 토큰을 계산하고, 그 결과를 바탕으로 다음 토큰을 계산한다. 이 과정을 반복하면서 문장을 완성한다.

이러한 생성 방식을 자기회귀 생성(Autoregressive Generation)이라고 한다.

문제는 토큰 하나를 생성할 때마다 대규모 모델의 가중치를 반복해서 읽어야 한다는 점이다.

기술 블록 ①: 메모리 대역폭 병목

LLM의 추론에서는 연산 능력뿐 아니라 GPU 메모리에서 모델 가중치를 얼마나 빠르게 읽을 수 있는지가 중요하다.

특히 배치 크기가 작은 토큰 생성 단계에서는 GPU가 보유한 연산 능력을 전부 활용하지 못하고, 메모리 대역폭이 병목이 되는 경우가 많다.

이를 단순화하면 다음과 같이 표현할 수 있다.

메모리 병목 상황에서의 최대 생성 속도 근사치

생성 가능한 토큰 수/초 ≈ 메모리 대역폭 ÷ 토큰당 필요한 가중치 읽기량

예를 들어 1조 바이트에 해당하는 가중치를 매 토큰마다 전부 읽어야 한다면, 초당 8TB의 메모리 대역폭을 제공하는 환경에서도 단순 계산상 초당 약 8토큰이 한계다.

물론 실제 모델은 여러 GPU에 분산되며, 캐시와 배치 처리, 연산량, 메모리 접근 패턴 등 다양한 요소가 작용한다. 위 식은 실제 성능을 예측하는 공식이 아니라 메모리 병목을 이해하기 위한 근사 모델이다.

여기서 중요한 질문이 생긴다.

매번 토큰 하나만 생성하기 위해 가중치를 반복해서 읽어야 한다면, 한 번의 모델 실행에서 여러 토큰을 처리하도록 만들 수는 없을까?

이 질문이 추론 가속 기술의 핵심 출발점이다.

2. 가속 서빙은 모델을 바꾸는 기술이 아니라 실행을 최적화하는 기술이다

추론 가속을 이해하려면 세 가지를 구분해야 한다.

① 모델 자체의 변경

양자화, 증류, 프루닝 등을 통해 모델의 크기나 계산량을 줄인다.

이 방식은 메모리 사용량을 줄이고 실행을 빠르게 만들 수 있다. 하지만 원본 모델과 계산 결과가 달라질 수 있다.

② 추론 엔진의 최적화

동일한 모델 가중치를 사용하면서 GPU 메모리 접근, 연산 커널, 배칭, 캐시 관리, 스케줄링 등을 최적화한다.

대표적인 추론 엔진으로 vLLM이 있다. vLLM은 PagedAttention, 연속 배칭, 다양한 양자화 및 speculative decoding 기법 등을 지원한다.

공식 문서: https://docs.vllm.ai/en/latest/features/speculative_decoding/

③ 추론 알고리즘 자체의 가속

기존에는 모델이 토큰을 하나씩 생성했다면, 새로운 알고리즘은 여러 토큰을 미리 제안하고 이를 병렬로 검증하도록 만든다.

이때 원본 모델이 최종적으로 허용하는 결과만 채택한다면, 생성 속도를 높이면서 출력 분포를 보존할 수 있다.

이 세 가지는 서로 배타적이지 않다. 실제 서비스는 여러 방법을 결합할 수 있다.

하지만 원본 모델의 품질을 유지하는 것이 목표라면, 단순히 정밀도를 낮추는 방법과 출력 분포를 보존하는 알고리즘을 구분해서 평가해야 한다.

3. 가장 중요한 기술: Speculative Decoding

Speculative Decoding은 추론 가속을 이해하는 데 가장 중요한 개념 중 하나다.

한국어로는 추측 디코딩 또는 투기적 디코딩이라고 번역한다.

이름은 조금 낯설지만 원리는 직관적이다.

큰 모델이 토큰을 하나씩 생성하는 동안, 별도의 작은 모델이나 전용 초안 생성기가 앞으로 나올 토큰을 여러 개 미리 제안한다. 큰 모델은 이 후보들을 한 번의 실행에서 검증한다.

후보가 맞으면 여러 토큰을 한꺼번에 채택할 수 있다. 틀린 부분부터는 원본 모델의 규칙에 따라 수정하고 다시 진행한다.

기술 블록 ②: Draft → Verify → Accept

예를 들어 원본 모델이 다음과 같은 문장을 생성하려 한다고 하자.

The inference engine can improve generation speed

초안 생성기는 다음 토큰들을 미리 제안한다.

The inference engine can increase generation speed

원본 모델이 후보를 검증하면 앞부분의 여러 토큰은 그대로 채택할 수 있지만, improve와 increase의 차이가 발생하는 지점에서는 원본 모델의 분포에 맞춰 처리한다.

이 과정을 반복하면 원본 모델이 토큰을 하나씩 생성하는 것보다 적은 횟수의 순차적 실행으로 같은 길이의 결과를 만들 수 있다.

단, 이 예시는 이해를 돕기 위한 것이다. 실제 speculative decoding에서는 단순히 정답 문자열과 후보 문자열을 비교하는 것이 아니라 토큰의 확률 분포와 검증 규칙을 사용한다.

그렇다면 품질은 어떻게 보존되는가?

적절하게 설계된 speculative sampling에서는 초안 모델이 제안한 토큰을 무조건 채택하지 않는다.

원본 모델의 확률 분포를 기준으로 후보를 검증하고, 필요하면 보정된 확률 분포에서 토큰을 다시 선택한다.

이러한 검증 절차를 정확하게 구현하면 초안 모델이 작거나 부정확하더라도 최종 출력의 확률 분포를 원본 모델과 동일하게 유지할 수 있다.

이것이 핵심이다.

초안 생성기는 더 빠른 계산을 위해 사용하지만, 최종 결과를 결정하는 권한은 원본 모델에 남겨 두는 것이다.

따라서 초안 모델이 제안한 모든 토큰이 채택되는 것은 아니다. 얼마나 많은 토큰이 검증을 통과하는지가 가속 효율을 좌우한다.

여기서 한 가지 주의할 점이 있다. 출력 분포가 같다는 것은 같은 샘플링 설정에서 출력의 확률적 특성이 보존된다는 뜻이다. 서로 독립적으로 실행한 두 모델이 매번 문자 하나까지 같은 문장을 출력한다는 의미는 아니다. 결정론적 설정에서 동일한 결과를 얻으려면 난수 처리와 실행 조건까지 고려해야 한다.

4. DSpark: 초안 생성과 검증을 더 효율적으로 만드는 방법

이제 DSpark를 살펴보자.

DSpark는 DeepSeek 연구에서 나온 추론 가속 기술로, 기존 DFlash 계열의 초안 생성 구조에 두 가지 요소를 추가한다.

Markov head
Confidence head

관련 공개 구현은 vLLM 프로젝트의 Speculators 저장소에서 확인할 수 있다.

기술 문서: https://github.com/vllm-project/speculators/blob/main/docs/user_guide/algorithms/dspark.md

4-1. Markov head: 토큰 간의 연결성을 보완한다

여러 토큰을 병렬로 제안하면 한 가지 문제가 발생한다.

첫 번째 토큰을 제안할 때는 비교적 좋은 예측을 할 수 있어도, 뒤쪽 토큰으로 갈수록 앞에서 어떤 토큰이 선택됐는지에 대한 의존성이 약해질 수 있다.

예를 들어 첫 번째 단어를 잘 예측했다고 해도, 그 단어에 따라 두 번째와 세 번째 단어의 확률이 달라진다.

Markov head는 앞선 토큰 정보를 반영해 이후 후보를 보정함으로써 이 문제를 완화한다.

쉽게 말해 여러 토큰을 한꺼번에 제안하는 속도상의 이점을 유지하면서, 토큰 사이의 연결성을 조금 더 잘 반영하도록 만드는 것이다.

4-2. Confidence head: 확신이 낮은 후보는 짧게 검증한다

초안 생성기가 다섯 개의 토큰을 제안했다고 해 보자.

첫 세 토큰은 채택될 가능성이 높지만, 뒤의 두 토큰은 불확실할 수 있다.

이때 다섯 개를 무조건 모두 검증하는 것은 비효율적이다.

Confidence head는 각 후보가 검증을 통과할 가능성을 추정한다. 이 정보를 이용하면 확신이 높은 구간은 길게 제안하고, 불확실한 구간은 짧게 검증하도록 조절할 수 있다.

이런 적응형 검증은 특히 여러 요청이 동시에 처리되는 상황에서 중요하다.

4-3. DSpark는 모든 모델을 자동으로 10배 빠르게 만드는가?

그렇지 않다.

DSpark는 초안 생성과 검증의 비용을 절감하는 알고리즘이지, 모든 모델과 하드웨어에서 일정한 배수를 보장하는 만능 가속기가 아니다.

실제 성능은 다음 요소에 따라 달라진다.

원본 모델의 크기와 구조
초안 생성기의 속도와 정확도
검증을 통과하는 토큰 수
GPU 메모리 대역폭과 연산 능력
동시 요청 수
프롬프트 길이와 출력 길이

DSpark의 공개 구현은 GLM-5.2용 사전 학습 초안 모델과 Qwen 계열 학습 예제를 제공한다. 즉, 알고리즘이 존재한다는 사실과 특정 상용 API가 실제로 이를 사용한다는 사실은 구분해야 한다.

또한 DSpark라는 이름이 붙었다고 해서 모든 구현이 동일한 성능을 제공하는 것도 아니다. 초안 모델과 검증 모델의 호환성, 설정, 하드웨어 환경이 중요하다.

5. 가속 성능을 숫자로 읽는 방법

추론 가속을 평가할 때 가장 흔한 실수는 TPS 숫자 하나만 비교하는 것이다.

TPS는 Tokens Per Second의 약자로, 초당 처리하는 토큰 수를 뜻한다. 하지만 어떤 TPS인지에 따라 의미가 완전히 달라진다.

지표	의미	중요한 이유
TTFT	첫 토큰까지의 시간	응답이 시작되는 속도
개별 요청 TPS	한 요청에서의 생성 속도	사용자가 체감하는 스트리밍 속도
전체 처리량	서버 전체의 초당 토큰 수	동시에 많은 사용자를 처리하는 능력
p95 지연 시간	요청의 95%가 이 시간 안에 완료되는 기준	혼잡 상황의 서비스 품질
작업 완료 시간	실제 업무가 끝날 때까지 걸리는 시간	에이전트의 실질적인 생산성

예를 들어 서버 전체가 초당 1,000토큰을 처리한다고 해도, 개별 요청에 초당 1,000토큰을 제공한다는 뜻은 아니다.

반대로 한 사용자의 출력 속도가 초당 1,000토큰이라고 해도 복잡한 작업을 10배 빨리 끝낸다는 보장은 없다. 모델이 결과를 생성하는 시간보다 외부 도구 호출이나 빌드, 테스트 시간이 더 길 수도 있기 때문이다.

기술 블록 ③: 실제 가속 배수 계산

같은 조건에서 원본 모델의 개별 요청 속도가 100 TPS이고, 가속 엔드포인트가 500 TPS라면 출력 속도 기준 가속 배수는 다음과 같다.

가속 배수 = 500 ÷ 100 = 5배

하지만 이 계산이 의미 있으려면 두 측정에서 모델의 변형, 출력 길이, 프롬프트 길이, 추론 설정, 하드웨어 조건 등이 적절하게 통제돼야 한다.

특히 서로 다른 업체의 API를 비교할 때는 제공되는 모델의 실제 변형이 동일한지도 확인해야 한다.

출력 속도 5배라는 숫자는 유용한 출발점이지만, 그 자체가 순수한 추론 엔진의 성능 향상 배수를 증명하지는 않는다.

6. 실제 서비스 업체는 얼마나 빠른가?

이제 이론이 아니라 실제 API 서비스를 살펴보자.

2026년 10월 기준으로 Artificial Analysis는 DeepSeek V4.1 Flash의 여러 제공업체를 비교하고 있다.

공개 벤치마크 페이지에서는 다음과 같은 출력 속도가 보고돼 있다.

LithosAI ULTRA CHAT: 약 1,396 TPS
Inco FAST: 약 1,234 TPS
Baseten FAST: 약 694 TPS
LithosAI FAST: 약 540 TPS

이 수치는 해당 벤치마크의 특정 측정 조건에서 나온 결과다. 서비스별 설정과 시간에 따라 변할 수 있으며, 모든 요청에서 동일한 속도가 보장되는 것은 아니다.

자료: https://artificialanalysis.ai/models/deepseek-v4-1-flash-non-reasoning/providers

이 결과는 중요한 사실을 보여 준다.

동일한 모델 계열을 제공하는 API 사이에서도 출력 속도가 크게 달라질 수 있다. 따라서 추론 서비스 업체의 최적화 역량은 실제로 비교할 가치가 있다.

하지만 이 숫자만으로 특정 업체가 원본 모델과 동일한 품질을 유지하면서 순수한 엔진 최적화만으로 해당 속도를 달성했다고 단정할 수는 없다.

왜냐하면 다음과 같은 차이가 섞여 있을 수 있기 때문이다.

서로 다른 정밀도나 모델 변형
서로 다른 GPU와 메모리 구성
추론 엔진의 최적화 수준
speculative decoding이나 기타 가속 기술의 사용 여부
요청 처리 정책과 서버 부하

따라서 빠른 API를 발견했다면 다음 질문을 해야 한다.

이 업체는 정확히 어떤 모델을, 어떤 정밀도로, 어떤 추론 엔진에서 실행하고 있는가?

그리고 원본 모델과의 품질 동등성을 어떻게 검증했는가?

이 두 가지 질문에 답할 수 있어야 속도 숫자를 기술적 성과로 평가할 수 있다.

7. 양자화와 무손실 가속은 반드시 구분해야 한다

속도를 높이는 기술이라고 해서 모두 같은 것은 아니다.

양자화(Quantization)

모델 가중치나 계산의 정밀도를 낮춰 메모리 사용량과 연산 비용을 줄이는 방법이다.

예를 들어 FP16이나 BF16 대신 FP8 또는 FP4와 같은 저정밀 형식을 사용하면 하드웨어에 따라 더 빠른 연산과 높은 처리량을 얻을 수 있다.

그러나 양자화는 원본 모델과 수학적으로 완전히 동일한 계산이 아니다. 결과 품질의 차이가 작을 수 있지만, 작업에 따라 특정 능력이 저하될 가능성도 있다.

따라서 FP4를 사용한다는 사실만으로 성능이 나쁘다고 판단할 수는 없지만, 원본과 완전히 동등하다고 주장하려면 별도의 검증이 필요하다.

Speculative decoding

반면 적절한 speculative decoding은 원본 모델이 후보를 검증하고 정확한 보정 절차를 적용해 출력 확률 분포를 보존할 수 있다.

이 방식의 목표는 모델의 계산 결과를 근사해서 빨리 얻는 것이 아니라, 원본 모델이 해야 할 순차적 계산을 더 효율적으로 수행하는 것이다.

이 차이는 매우 중요하다.

양자화는 계산의 표현 방식과 정밀도를 바꿀 수 있다. Speculative decoding은 원본 모델의 결과를 유지하면서 실행 순서를 효율적으로 구성할 수 있다.

물론 실제 서비스에서는 두 기술을 함께 사용할 수도 있다. 이 경우 양자화에 따른 품질 영향과 speculative decoding의 정확성 보장을 별도로 평가해야 한다.

8. 가속 서빙 업체가 실제로 DSpark를 사용하고 있는가?

여기서는 한 단계 더 엄격한 기준이 필요하다.

DSpark가 공개돼 있고 vLLM이 이를 지원한다는 사실은 확인할 수 있다.

그러나 그것만으로 LithosAI나 Baseten의 모든 API가 DSpark를 사용한다고 결론 내릴 수는 없다.

상용 업체는 자체 커널, 배칭, 캐시 관리, speculative decoding, 모델별 최적화 등 다양한 기법을 조합할 수 있다. 어떤 업체는 특정 모델에서 DSpark를 사용하고, 다른 모델에서는 다른 방식을 선택할 수도 있다.

따라서 확인해야 할 항목은 다음과 같다.

실제 엔드포인트에서 사용되는 모델 ID와 모델 변형
FP16, BF16, FP8, FP4 등 실제 가중치 정밀도
speculative decoding 사용 여부와 구체적인 방식
초안 모델과 검증 모델의 관계
원본과의 출력 분포 보존 또는 품질 검증 결과
공개 벤치마크와 자체 측정 결과의 차이

업체가 DSpark를 지원한다는 사실, 특정 서비스에서 DSpark를 활성화했다는 사실, 그리고 그 서비스가 원본과 동일한 품질을 제공한다는 사실은 서로 다른 주장이다.

기술적으로 신뢰할 수 있는 평가는 이 세 가지를 구분해야 한다.

9. 개발자에게 가장 중요한 것은 토큰이 아니라 성공한 작업이다

가속 서빙의 사업적 가치는 단순히 TPS가 높다는 데 있지 않다.

예를 들어 코딩 에이전트가 10만 토큰을 분석하고 수정 코드를 생성한다고 하자.

기존 API가 100 TPS를 제공하고 새로운 API가 500 TPS를 제공한다면, 출력 생성 시간은 이론적으로 5분의 1 수준으로 줄어들 수 있다.

그러나 전체 작업 시간이 반드시 5분의 1이 되는 것은 아니다. 파일 읽기, 테스트, 빌드, 도구 호출, 재시도 시간이 남아 있기 때문이다.

더욱이 가속된 API가 더 많은 재시도를 요구한다면 비용 절감 효과가 사라질 수도 있다.

그래서 실제 제품에서는 다음 지표가 중요하다.

성공한 작업당 총비용

총 추론 비용 + 도구 호출 비용 + 재시도 비용 + 실패 복구 비용을 성공적으로 완료한 작업 수로 나눈다.

이 지표는 단순한 토큰 가격보다 실제 사업성을 잘 보여 준다.

가속 서빙은 동일한 품질을 유지하면서 작업 시간을 줄일 수 있다면 특히 가치가 크다. 실시간 음성 인식, 코딩 에이전트, 대규모 코드베이스 분석, 다중 에이전트 워크플로처럼 지연 시간이 전체 경험에 영향을 주는 분야에서 그렇다.

10. 직접 검증하려면 어떻게 해야 할까?

실제로 가속 서빙 API를 도입하려면 다음과 같은 실험을 권한다.

1단계: 기준 모델을 고정한다

동일한 모델 버전과 정밀도를 사용한다. 모델 이름이 같더라도 체크포인트나 양자화 방식이 다를 수 있으므로 실제 모델 변형을 확인한다.

2단계: 추론 설정을 맞춘다

Temperature, Top-p, 최대 출력 길이, reasoning 설정, 시스템 프롬프트 등을 가능한 한 동일하게 맞춘다.

3단계: 동일한 프롬프트를 반복한다

짧은 응답, 긴 코드 생성, 수학적 추론, 긴 문맥 분석 등 실제 업무를 대표하는 프롬프트를 준비한다.

4단계: 성능을 측정한다

TTFT, 개별 요청 TPS, 전체 처리량, p95 지연 시간, 작업 완료 시간과 비용을 기록한다.

5단계: 품질을 비교한다

동일한 모델의 출력 확률 분포를 보존하는 알고리즘인지 확인한다. 이것이 입증되지 않았다면 별도로 정답률, 코드 테스트 통과율, 추론 결과의 일관성 등을 비교해야 한다.

단순히 두 번의 응답이 비슷해 보인다는 이유만으로 품질이 동일하다고 결론 내려서는 안 된다.

또한 결정론적 추론 설정에서 결과가 일치하는지 확인하는 것과 출력 분포 자체가 동일한지를 검증하는 것은 다른 실험이다.

결론: 진짜 경쟁력은 지능을 희생하지 않는 속도다

AI 모델의 성능이 계속 발전하는 가운데 추론 인프라의 최적화는 또 다른 중요한 경쟁축이 되고 있다.

모델의 가중치를 낮은 정밀도로 바꾸거나 모델을 작게 만들어 속도를 높이는 방법도 유용하다. 그러나 원본 모델의 품질을 그대로 유지하면서 더 빠르게 추론할 수 있다면, 그것은 별도의 기술적 가치가 있다.

Speculative decoding과 DSpark는 그러한 가능성을 보여 주는 기술이다. vLLM과 같은 추론 엔진은 이 기술을 실제 서비스에 적용할 수 있도록 지원한다.

실제 API 벤치마크에서도 동일 모델 계열의 제공업체 사이에 큰 출력 속도 차이가 관측된다. 하지만 특정 업체의 초고속 수치가 어떤 기술에서 비롯됐는지, 원본 모델과 품질이 동등한지까지는 별도로 검증해야 한다.

따라서 가속 서빙을 평가할 때 가장 먼저 물어야 할 질문은 단순히 “초당 몇 토큰을 생성하는가?”가 아니다.

“원본 모델이 제공하던 추론 품질을 유지하면서, 실제 작업을 얼마나 더 빠르고 저렴하게 완수할 수 있는가?”

이 질문에 답할 수 있을 때 비로소 추론 가속은 단순한 속도 경쟁을 넘어 실제 제품과 서비스의 경제성을 바꾸는 기술이 된다.

참고 자료

참고: 이 글은 추론 가속의 기술적 원리와 공개 벤치마크를 설명한다. 개별 업체가 특정 가속 알고리즘을 실제로 사용하고 있는지, 원본과 동일한 품질을 제공하는지는 해당 엔드포인트의 기술 사양과 별도의 검증 결과를 확인해야 한다.

AI 추론 추론 가속 Speculative Decoding DSpark vLLM LLM 서빙