대화형 코딩 도구는 수백 ms 안에 여러 토큰이 필요할 수 있지만, 배경 데이터 처리는 조금 늦어도 전체 용량을 많이 받는 편이 낫습니다. 연속 배칭은 두 요청을 같은 반복에 넣고 비슷한 토큰 진행 속도를 적용합니다. 우선순위로 순서를 바꿀 수는 있어도 엄격한 요청 하나 때문에 배치 전체를 줄이면 다른 작업의 처리량까지 잃습니다.
AdaServe는 추측 디코딩을 요청별 속도 조절 수단으로 사용합니다. 작은 초안 모델이 여러 다음 토큰을 제안하고 목표 모델이 이를 검증하므로 출력 분포는 바뀌지 않습니다. 모든 요청에서 승인 토큰 수를 최대로 만드는 대신, 각 요청의 SLO를 충족할 만큼의 트리를 선택하고 나머지 GPU 용량을 보존합니다. 서로 다른 기한은 서로 다른 트리 모양을 받습니다.
같은 반복 속도를 강제하는 배치
자동회귀 디코딩은 일반적으로 목표 모델 반복마다 요청 하나에서 토큰 하나를 만듭니다. 연속 배칭은 요청을 계속 넣고 빼며 GPU를 채우지만 활성 시퀀스는 배치 반복 시간에 맞춰 진행합니다. 엄격한 요청을 더 빨리 처리하려면 배치를 줄이거나 별도 자원을 줘야 하고, 두 방법 모두 여유 있는 요청과 함께 쓸 수 있는 용량을 남깁니다.
추측 디코딩은 한 번의 목표 모델 검증으로 여러 토큰을 진행할 수 있습니다. 초안 후보의 수와 분기 폭이 예상 진행량과 비용을 정합니다. 큰 트리는 승인률이 높은 요청을 빠르게 만들 수 있지만 다른 요청에 쓸 검증 슬롯을 사용합니다. 적절한 트리는 SLO와 초안 품질, 시퀀스 상태, 배치 구성과 GPU 처리량에 따라 달라집니다.
AdaServe는 이 선택을 제약 최적화로 표현합니다. 하드웨어 모델이 목표 GPU가 병렬로 검증할 후보 수를 추정하고, 스케줄러는 각 요청의 예상 토큰 속도가 목표를 지키면서 전체 유효 처리량이 높아지도록 트리를 배정합니다.
추측과 선택을 분리한 파이프라인
후보 분기마다 초안 모델을 따로 실행하면 이점이 사라질 수 있습니다. AdaServe는 과정을 세 단계로 나눕니다. 추측 단계가 후보를 만들고, 선택 단계가 현재 SLO와 하드웨어 용량에 맞는 트리를 고르며, 검증 단계가 선택된 후보를 목표 모델로 처리합니다. 파이프라인은 초안 작업을 겹치고 요청마다 계획을 순차적으로 다시 만드는 비용을 줄입니다.
정책은 선택 단계에 있습니다. 기한에 가까운 요청은 더 많은 승인 토큰을 기대하는 트리를 받고, 여유 있는 요청은 작은 트리나 일반 디코딩을 사용해 검증 용량을 남깁니다. 거부된 초안 경로는 버리고 목표 모델의 샘플링을 유지하므로 토큰의 정확한 분포는 바뀌지 않습니다.
요청 종류와 부하가 바뀌면 트리 매개변수도 조절합니다. 정적 프로파일은 GPU 처리 능력을 설명하고 실행 중 관측값은 승인률과 대기열을 보여 줍니다. 낮은 부하에서 유리한 큰 트리는 높은 부하에서 검증을 과부하시킬 수 있습니다. 제어기는 하나의 SLO 상태가 끝나기 전에 정책을 바꿀 만큼 빨라야 합니다.
SLO 관점별 평가 결과
AdaServe는 보고된 작업부하에서 가장 좋은 비교 시스템보다 SLO 위반률을 최대 4.3배 줄이고 유효 처리량을 최대 1.9배 높였습니다. 엄격한 요청 비율이 증가할 때는 SLO 충족률이 최대 1.5배, 유효 처리량이 64% 높았습니다. 엄격한 출력 토큰당 시간 목표에서는 유효 처리량이 최대 1.38배였습니다.
서로 다른 실험의 배율을 곱해서는 안 됩니다. 위반 감소폭은 비교 시스템이 처음에 얼마나 많이 놓쳤는지에 좌우됩니다. 유효 처리량은 선택한 SLO를 지킨 출력만 세므로 원시 토큰 수보다 의미가 크지만, 어떤 목표를 사용했는지에 따라 값이 달라집니다. 출력 토큰당 시간을 지켜도 첫 토큰 시간을 놓칠 수 있고 그 반대도 가능합니다.
평가는 여러 서비스 기록과 모델 구성을 사용하지만 실제 도입에서는 자체 승인률과 도착 분포를 다시 측정해야 합니다. 초안 모델의 예측이 나쁘거나 목표 모델이 작고, 초안 연산이 같은 병목을 다투면 이득이 줄어듭니다. 목표 모델이 많은 후보를 효율적으로 검증하고 지연시간 등급의 차이가 크면 기회가 늘어납니다.
승인률에 숨은 연산 비용
승인률만으로 효율을 판단할 수 없습니다. 넓은 트리는 거부될 토큰도 많이 만들어 진행량보다 큰 초안·검증 연산을 사용할 수 있습니다. 실제 지표는 초안 실행과 후보 선택, KV 캐시 접근과 버린 분기를 포함한 GPU 시간당 SLO 준수 목표 토큰입니다.
메모리도 달라집니다. 후보 분기에는 임시 토큰과 KV 상태가 필요합니다. 엄격한 요청에 큰 트리를 주면 배치 용량이 줄거나 메모리 조각화가 커질 수 있습니다. 하드웨어 모델에는 연산 처리량뿐 아니라 메모리 한도가 들어가야 합니다. 메모리 부족 뒤 모든 트리를 줄이는 방식은 순간 요청 증가에서 꼬리 지연시간을 더 나쁘게 만들 수 있습니다.
전력은 또 다른 제약이며, 추측 디코딩은 거부될 수 있는 연산을 의도적으로 수행합니다. 완료 시간은 줄이면서 승인 토큰당 에너지는 늘 수 있습니다. 랙 전력 한도가 있는 운영자는 남는 텐서 코어가 무료라고 가정하지 말고 에너지나 순간 전력을 최적화 조건에 넣어야 합니다.
지연시간 등급 사이의 공정성
요청마다 트리를 바꾸면 우선순위가 명시적인 자원 배분으로 바뀌며, 엄격한 등급은 여유 있는 작업보다 더 많은 추측 자원을 사용할 수 있습니다. 입장한 요청이 처리 가능 용량을 넘으면 어떤 트리로도 모두 만족시킬 수 없습니다. 평균 유효 처리량 뒤에 과부하를 숨기지 말고 거절, 품질 저하와 최소 진행 정책을 정해야 합니다.
SLO는 사용자가 비용 없이 고르는 표시가 아니라 서비스 가치와 연결돼야 합니다. 그렇지 않으면 모든 사용자가 가장 엄격한 등급을 요청합니다. 가격과 할당량, 작업 신원이 목표와 자원 권리를 연결해야 합니다. 스케줄러는 등급별 달성 지연시간과 사용한 검증 용량을 보고해 정책을 감사할 수 있게 해야 합니다.
엄격한 트래픽이 오래 지속되면 여유 있는 요청이 거의 진행하지 못할 수 있습니다. 느슨한 토큰 지연시간을 형식상 지키더라도 전체 완료는 지나치게 늦어집니다. 최대 대기 시간이나 완료 기한을 추가할 수 있으며, 수요가 가능한 범위를 넘었을 때의 동작을 정의해야 다중 SLO 시스템이 완성됩니다.
우선순위와 분리 서빙의 차이
우선순위 스케줄링은 급한 요청을 먼저 실행하지만 한 반복에 토큰 하나라는 구조는 바꾸지 않습니다. 선점과 작은 배치는 지연시간을 줄이는 대신 처리량을 잃습니다. AdaServe는 공유 검증 단계에서 요청별 진행량을 바꿔 새로운 제어 축을 만듭니다.
프리필과 디코드를 분리하면 각 단계를 따로 확장할 수 있지만 디코드 장비군 안에서도 토큰 목표는 섞입니다. AdaServe는 이 디코드 풀 안에서 동작할 수 있습니다. 초안 연산을 별도 자원에 두면 네트워크와 KV 이동이 지연시간에 들어가고, 같은 장치에 두면 전송은 줄지만 연산과 전력을 공유합니다.
엄격한 요청을 작은 모델로 보내는 모델 라우팅도 대안입니다. 이 방식은 출력 품질을 바꾸지만 무손실 추측 디코딩은 목표 모델의 결과를 유지합니다. 두 방법을 함께 쓸 수는 있어도 품질 교환과 시스템 가속을 구분해 측정해야 합니다.
운영 환경의 인수 시험
SLO 등급, 입력과 출력 길이, 목표·초안 모델, 요청률과 순간 증가 모양을 교차해 시험해야 합니다. 첫 토큰 시간, 출력 토큰당 시간, 완료 시간, 위반률, 원시 처리량, 유효 처리량, 거부된 후보 연산, 메모리와 전력을 보고합니다. 전체 평균보다 등급별 p95와 p99가 중요합니다.
요청 종류를 갑자기 바꾸고 제어기가 새 정책에 도달하는 시간도 측정해야 합니다. 초안 모델 성능 저하, 승인률 변화와 메모리 압력을 포함합니다. 안정된 기록에서 최적이어도 매 전환마다 기한을 놓치면 실제 서비스에는 맞지 않습니다.
정확성도 검증해야 합니다. 후보 거부와 샘플링 결과가 알고리즘이 보장한 목표 분포를 유지해야 합니다. 트리 선택 로그는 민감한 입력을 저장하지 않으면서 원인을 설명할 수 있어야 합니다. 프로파일이 없거나 가능한 계획을 찾지 못하면 일반 디코딩으로 안전하게 돌아가고 그 사실이 계측에 나타나야 합니다.
요청 기한에 값을 붙이는 추측 디코딩
AdaServe는 추측 디코딩을 모든 요청에 같은 가속 방식으로 적용하지 않고 자원 배정 수단으로 바꿉니다. 요청에 붙은 트리는 해당 토큰 기한을 지키기 위해 서비스가 추가 연산을 얼마나 사용할지를 나타냅니다. 공유 검증 파이프라인은 이 정책을 실제 GPU 작업으로 바꿉니다.
하나의 모델이 서로 다른 지연시간 등급을 제공하고 초안 승인률이 높을 때 효과가 큽니다. SLO가 모두 같거나 초안 품질이 낮고 메모리·전력이 이미 제한하면 이점이 줄어듭니다. 구매와 배포에서 볼 숫자는 부하 변화에 따른 등급별 유효 처리량이며 거부된 연산도 함께 표시해야 합니다. 최대 1.9배라는 결과는 그 분모의 엄격한 요청과 여유 있는 요청이 실제 서비스와 같을 때 의미가 있습니다.
출처와 저작권 안내
이 글은 EuroSys 2026 논문[1]을 우리 표현으로 다시 분석한 편집 다이제스트입니다. 논문의 문장·도판·표를 옮기지 않았으며, 본문 도판은 Silicon & Systems가 새로 제작했습니다. 결과는 저자들이 사용한 작업부하, SLO 정의, 모델과 비교 시스템 조건을 유지해 인용했습니다. 원 논문의 저작권은 저자에게 있고 출판권은 ACM(2026)에 허여됐습니다.