Orthrus 듀얼뷰 확산 디코딩으로 LLM 무손실 병렬 추론 구현하기

순차 생성이 GPU를 묶어 두는 이유

자기회귀 언어 모델은 앞서 생성한 모든 토큰을 조건으로 다음 토큰을 하나씩 결정한다. 텍스트의 인과관계를 충실히 반영하는 구조지만 병렬 연산에 강한 GPU를 충분히 활용하기 어렵다. 1000개 토큰을 출력하려면 1000회의 순차 포워드 패스가 필요하고, 매번 전체 KV 캐시를 참조해야 한다.

서빙 환경에서는 이 순차성이 두 방향으로 비용을 만든다. 컨텍스트가 길어질수록 TTFT(Time to First Token)와 TPOT(Time Per Output Token)이 함께 증가한다. 각 단계에서 GPU가 포화되지 않은 채 기다리는 시간도 늘어나 하드웨어 활용률이 낮아진다.

가속을 위한 기존 접근은 세 범주로 나뉜다.

투기적 디코딩(Speculative Decoding)은 작은 드래프트 모델이 토큰 여러 개를 예측하면 큰 검증 모델이 후보를 한꺼번에 수락하거나 거부한다. EAGLE-3와 DFlash가 이 방식에 속한다. 두 모델을 함께 메모리에 유지해야 하고, 컨텍스트 유형에 따라 드래프트 수락률이 크게 달라지는 것이 부담이다.

Medusa Head는 하나의 모델에 복수의 예측 헤드를 붙여 다음 N개 토큰을 동시에 예측한다. 구조는 비교적 단순하지만 원본 모델의 파인튜닝이 필요하며, 장문 컨텍스트에서는 정확도가 떨어질 수 있다.

Diffusion LM은 마스킹된 토큰 전체를 병렬로 두고 반복적으로 정제한다. 완전한 병렬 생성이 이론적으로 가능하지만 자기회귀 모델보다 품질이 현저히 낮아질 수 있고, 기존 학습 데이터와 파이프라인을 그대로 재활용하기 어렵다.

2026년 5월 arXiv에 공개된 Orthrus(arxiv: 2605.12825)는 이 접근들의 약점을 함께 다룬다. PyTorch Korea 커뮤니티에서도 주목받은 이 프레임워크의 핵심 주장은 출력 품질을 손상시키지 않으면서 추론을 7.8배 가속하는 것이다.

공유 KV 캐시를 자기회귀와 확산 관점에서 사용한다

Orthrus에는 자기회귀 뷰(AR View)와 확산 뷰(Diffusion View)가 있다. 자기회귀 뷰는 정확한 KV 표현을 만들고, 확산 뷰는 그 표현을 이용해 토큰을 병렬로 샘플링한다. 두 뷰가 각자 캐시를 만드는 대신 동일한 KV 캐시에 접근한다는 점이 설계의 중심이다.

⤢✕

프리필링 단계에서 자기회귀 뷰가 입력 프롬프트를 처리해 고품질 KV 표현을 구축한다. 생성 단계로 넘어가면 확산 뷰가 이 캐시를 그대로 참조해 여러 토큰을 동시에 만든다. 투기적 디코딩과 달리 후보를 다시 검사하는 수락·거부 과정이 없으므로 별도의 검증 패스도 필요하지 않다.

기반 모델을 동결한 채 확산 뷰만 학습한다

Orthrus는 기반 LLM 전체를 다시 학습하지 않는다. 백본을 동결하고 전체 파라미터의 약 16%에 해당하는 경량 확산 뷰 모듈만 파인튜닝한다. 별도의 드래프트 모델을 유지하는 대신 확산 뷰가 직접 병렬 생성을 수행하도록 만드는 방식이다.

학습에는 자기회귀 뷰의 출력 분포를 확산 뷰로 증류하는 방법을 사용한다. 손실 함수는 두 뷰의 토큰 확률 분포 사이 KL 발산을 최소화하도록 구성되며, 이를 통해 출력 분포의 무손실 보장을 수학적으로 확보한다.

⤢✕

구현은 Qwen3 백본의 1.7B, 4B, 8B 모델을 기반으로 한다. HuggingFace Transformers와 호환되며, 소스 코드와 사전학습 가중치는 GitHub의 chiennv2000/orthrus 저장소에 공개돼 있다.

병렬 디코딩 방식과 비교하면

방법	가속 배율	품질 손실	메모리 오버헤드	장문 컨텍스트
EAGLE-3	3~4배	없음	높음 (2개 모델)	성능 저하
Medusa	2~3배	소량	중간	성능 저하
확산 LM	5~8배	있음	낮음	안정적
Orthrus	7.8배	없음	낮음	안정적

Orthrus가 두드러지는 지점은 장문 컨텍스트다. 투기적 디코딩은 컨텍스트가 길어질수록 드래프트 수락률이 떨어지는 반면, Orthrus는 두 뷰가 KV 캐시를 공유해 컨텍스트 길이와 관계없이 일정한 가속률을 유지한다.

메모리 구성도 다르다. 완전한 모델 두 개를 올리는 대신 기존 모델에 경량 확산 헤드를 추가한다. 추가 파라미터는 16%이며, 기반 모델의 10~30% 크기인 전형적인 드래프트 모델과 비교할 때 메모리 부담이 상당히 낮다.

기존 PyTorch 서빙 코드에 연결하기

Orthrus는 HuggingFace Transformers의 AutoModel 인터페이스와 호환되도록 설계됐다. 기존 추론 코드의 사용 방식을 크게 바꾸지 않고 모델을 불러와 생성 메서드를 호출할 수 있다.

# 기존 HuggingFace 추론 코드와 동일한 인터페이스
from orthrus import OrthrusForCausalLM, OrthrusConfig

model = OrthrusForCausalLM.from_pretrained("chiennv2000/orthrus-qwen3-4b")
# generate() 메서드는 기존과 동일하게 사용
# 내부적으로 diffusion view가 병렬 토큰 생성 담당
outputs = model.generate(input_ids, max_new_tokens=512)

vLLM과 TGI(Text Generation Inference) 같은 주요 서빙 프레임워크의 통합은 로드맵에 포함돼 있다. PagedAttention 호환성도 연구 중이다.

병렬 토큰 생성은 요청 하나의 지연만 줄이는 데 그치지 않는다. GPU 연산 밀도가 높아져 배치 처리 효율이 개선되고, 동일한 GPU 클러스터가 처리할 수 있는 동시 요청 수도 늘어난다. 레이턴시와 처리량을 함께 개선할 수 있는 구조다.

프로덕션에서 맞는 워크로드 고르기

TPOT의 비중이 큰 코드 생성, 문서 요약, 장문 보고서 작성은 Orthrus의 장점을 활용하기 좋은 워크로드다. 반대로 출력 토큰이 적은 단답형 QA에서는 가속 효과가 제한적이다.

커스텀 모델이나 도메인 특화 모델에 적용할 때는 해당 기반 모델을 사용한 재학습이 필요하다. 백본을 동결하고 16%만 학습하므로 파인튜닝 비용은 상대적으로 낮다.

하드웨어 조건도 영향을 준다. 병렬 토큰 생성을 충분히 활용하려면 GPU의 연산 폭과 병렬 처리 능력이 뒷받침돼야 한다. A100/H100급 GPU에서 벤치마크된 7.8배 가속은 소규모 GPU에서 다소 낮아질 수 있다.

서빙 비용에 미치는 영향

7.8배 추론 가속을 GPU-시간 기준으로 환산하면 같은 양의 토큰 생성에 필요한 컴퓨팅은 약 87% 감소한다. 상용 LLM API 원가에서 추론 컴퓨팅이 차지하는 비중을 고려하면, Orthrus 수준의 가속이 보편화될 경우 토큰당 단가가 크게 낮아질 수 있다.

Orthrus는 자기회귀 LLM의 정확한 출력 분포와 확산 모델의 병렬 생성 능력을 결합한다. 단일 모델에 경량 헤드를 붙이는 구조, 무손실 7.8배 가속, HuggingFace 호환성은 프로덕션 도입 장벽을 낮춘다. 장문 컨텍스트에서의 안정적인 성능은 RAG, 코드 생성, 문서 처리 같은 엔터프라이즈 워크로드와도 맞닿아 있다.