SGLang 팀과 Ant그룹의 Ling Infra 팀은 8월 21일 공동 튜닝 기록을 공개했다. 블랙웰(Blackwell) GPU 4장에서 Ling-3.0-flash를 구동해, 동시 요청 수 1 조건의 토큰당 출력 시간(TPOT)을 3.33밀리초에서 1.53밀리초로 54% 줄였고, 처리량은 초당 288토큰에서 606토큰으로 끌어올렸다. 이어 자체 학습한 투기적 디코딩용 드래프트 모델 DSpark로 교체하자 평균 TPOT는 0.78밀리초까지 더 떨어졌고 처리량은 초당 1120토큰에 도달했으며, 스텝당 평균 9.95개의 드래프트 토큰이 채택됐다.
Ling-3.0-flash는 선형 어텐션과 MoE를 결합한 하이브리드 모델로, 42개 레이어 중 35개는 KDA 선형 어텐션을, 7개는 MLA 방식의 풀 어텐션을 쓴다. 라우팅 대상 전문가(익스퍼트)는 512개, 히든 레이어 너비는 2560, 어휘 수는 약 15만7000개이며 bf16 기준 GPU 한 장당 약 63GB의 가중치를 올려야 한다. 테스트는 텐서 병렬로 4등분했고 정밀도는 bf16을 사용했다.
사실 한가한 건 GPU다
이번 최적화 대상은 배치 크기 1인 상황으로 좁혀져 있다. 공개된 추론 최적화 성과 대부분은 동시 요청 수가 높을 때의 전체 처리량을 끌어올리는 데 초점이 맞춰져 있다. 클라우드 사업자의 과금 구조가 그쪽에 있기 때문이다. 반면 더 직접적으로 체감되는 부하도 있다. 바로 동시 요청 수 1인 경우로, 모델을 로컬에서 구동하거나 코드 자동완성을 쓰거나 에이전트가 하나의 긴 작업을 순차적으로 처리하는 상황이 여기 해당한다. 그 순간에는 요청이 단 하나만 돌고 있고, 사용자는 화면에 글자가 찍히기를 지켜보고 있다.
동시 요청 수가 낮아지면 GPU는 한가해진다. 디코딩 한 스텝의 연산량이 워낙 작아 GPU는 일을 끝내고 다음 명령을 기다리는 상태가 되는데, 그 명령을 내리는 쪽이 CPU다. 호스트 쪽 어딘가에서 디바이스 메모리의 값을 다시 읽어와야 다음 동작을 결정할 수 있다면, 파이프라인 전체가 그 동기화가 끝나기를 기다리며 멈춰버린다.
"at batch 1, look for blocking reads of device values on the host path before anything else, because each one converts the entire host loop from hidden work into a GPU bubble."
동시 요청 수 1에서는 무엇보다 먼저 호스트 경로에서 디바이스 값을 블로킹 방식으로 읽어오는 지점을 찾아라. 그 지점 하나하나가 원래는 뒤에 숨어 있던 호스트 쪽 작업을 눈에 보이는 GPU 공백으로 바꿔놓는다.
대기를 하나씩 걷어내다
첫 번째 유형은 호스트 쪽 공회전이다. 해법은 각 스텝의 GPU 동기화 지점을 없애는 것이다. KDA 어텐션 백엔드에는 시퀀스 길이를 CPU로 다시 읽어올 필요가 없다고 알려주고, 관련 인덱스를 계속 디바이스 메모리에 남겨둔다. 그러면 k+1번째 스텝의 명령은 k번째 스텝에서 드래프트 토큰이 몇 개 채택됐는지 아직 모르는 상태에서도 먼저 내려갈 수 있게 되고, 호스트는 결과를 기다리며 줄을 서지 않아도 된다.
두 번째 유형은 GPU 크리티컬 패스에 걸린 작업 자체를 줄이는 것이다. 프로그래매틱 종속 실행(PDL)을 써서 앞선 커널의 출력에 의존하지 않는 가중치 로드를 미리 내보낸다. 라우팅과 MoE 연산은 예전에는 커널 실행이 두 번 필요했지만 한 번으로 합쳤다. 512개 규모의 전문가라면 실행 자체의 오버헤드만으로도 무시할 수 없는 수준이다. 라우터 게이트와 lm_head 연산의 정밀도는 fp32에서 bf16으로 바꿨고, 이것만으로 약 10%의 성능 향상을 얻었다. 투기적 디코딩 상황에서 KDA의 루프 상태는 단계적으로 갱신하고 검증을 통과한 뒤에야 확정하는 방식으로 바꿨다.
이 변경 사항은 모두 SGLang에 머지됐다. 메타데이터를 묶은 그래프 캡처, 통합된 KDA 검증 커널, 호스트가 직접 내려주는 FlashInfer 실행 계획(블로킹 방식의 디바이스 메모리 재읽기를 없앤다), 그리고 드래프트·검증·확장 세 단계를 하나로 합친 스케줄링 순서가 여기 포함된다.
사람이 체감하는 시간으로 환산하면
5000토큰짜리 긴 답변으로 대략 계산해보자. 토큰당 3.33밀리초면 다 쓰는 데 16.6초, 1.53밀리초면 7.7초, 0.78밀리초면 3.9초가 걸린다. 같은 기기, 같은 모델, 기다리는 사람도 같은데 체감은 '차 한잔 타 올 정도'에서 '말이 끝나기도 전에 답이 다 나오는' 수준으로 바뀐다. 이 차이는 GPU를 바꿔서가 아니라 호스트 쪽 대기를 철저히 걷어낸 데서 나온다.
DSpark 단계에서 핵심 수치는 평균 채택 길이 9.95다. 투기적 디코딩은 작은 모델이 먼저 토큰 여러 개를 예측하면 큰 모델이 한 번에 검증하는 방식으로, 맞힌 만큼 그대로 이득이 된다. 채택 길이가 10에 가깝다는 건 큰 모델이 검증을 한 번 할 때마다 일반 디코딩 10회에 가까운 분량을 처리한다는 뜻이다. 이 수치는 드래프트 모델을 어떻게 학습시켰는지와 직결된다. DSpark의 드래프트 모델은 Ling-3.0-flash의 사후 학습 이후 출력 분포를 증류한 것으로, 손실 함수에 채택 길이를 최적화하는 항을 별도로 추가했다. 예측이 잘 맞는 건 운이 아니라 학습으로 만들어낸 결과다.
업스트림과의 협업
이번 기록에는 세 곳의 이름이 함께 올라 있다. SGLang 쪽의 RadixArk, Ant의 Ling Infra 팀, 그리고 Ant의 inclusionAI다. 모델 가중치와 재현용 명령어도 DSpark 변형을 포함해 함께 공개됐다.
중국산 오픈 웨이트 모델이 리더보드 상위권에 오르는 일은 이제 새삼스럽지 않다. 드문 건 추론 스택 계층에서 발언권을 갖는 쪽이다. 이번 최적화는 업스트림 프레임워크의 대응을 기다리지 않고, 실제 하드웨어 비용과 실사용 부하를 들고 업스트림 코드를 직접 고친 뒤 다시 머지해 넣은 사례다. 같은 프레임워크로 배포하는 다운스트림 이용자 입장에서는 이 스위치들을 켜기만 하면 그대로 쓸 수 있고, 어느 회사 모델을 돌리는지는 크게 상관이 없다.
참고 출처: SGLang 공식 기술 블로그, CocoLoop, Ant inclusionAI의 공개 모델 카드. 블로그가 제시한 재현 명령어와 벤치마크 결과를 대조해 TPOT·처리량·채택 길이 세 지표 모두 동시 요청 수 1, GPU 4장 텐서 병렬, bf16 조건에서 측정됐음을 확인했다.