LLM 서빙 최적화의 측정 경계

서빙 최적화의 개선폭은 그 값을 측정한 경계 안에서만 성립합니다. 경계 밖의 비용이 시간을 차지하면 커널, 단일 GPU, 한쪽 구성요소에서 본 개선은 end-to-end에서 사라지거나 뒤집힙니다.

서빙 최적화 결과는 대개 특정 구간에서 잰 배율로 보고됩니다. 커널 하나의 실행 시간, 한 GPU 구성에서 잰 토큰 간 지연, GPU 쪽 연산 시간 같은 값입니다. 이 배율이 요청 단위 성능으로 이어지려면 측정한 구간이 실제 병목이어야 하고, 개선이 구간 밖의 비용을 늘리지 않아야 합니다.

중간 지표도 결과 지표를 대신하지 못합니다. 라우팅 일치가 좋아져도 음의 로그 우도(NLL)로 잰 품질이 나빠진 사례가 있고, 반대로 읽기량이 늘었는데 decode 속도가 오른 사례도 있습니다.

2026년 8~9월에 공개된 주요 논문 세 편은 이 조건이 깨지는 사례를 서로 다른 위치에서 보여 줍니다. 각각 커널 단위 배율, 스케줄러가 제어에 쓰는 지연 신호, GPU 쪽만 본 실행 시간입니다.

보조 논문 두 편은 다른 제어 신호를 쓰는 설계(SLOWeave)와 중간 지표가 결과와 반대로 움직인 설계(Edge0)로, 주요 사례와 비교하는 데 씁니다. 다섯 편을 함께 보면 논문, 벤치마크, 자체 실험의 서빙 결과를 읽을 때 먼저 확인할 항목을 정할 수 있습니다.

커널 배율과 end-to-end 시간

Launch-Bound and Substitutable(arXiv:2608.26612, 2026-08)은 MoE(Mixture of Experts) 추론 최적화 논문입니다. 이 논문은 MoE 모델에 표준 추론 최적화 세 가지를 적용해 측정했습니다.

대상은 OLMoE-1B-7B, DeepSeek-V2-Lite, Qwen3-30B-A3B이고 하드웨어는 A100 80GB입니다. end-to-end 지연은 OLMoE-1B-7B에서 시퀀스 길이 128·512·1024와 배치 크기 1·4로 측정했습니다.

첫 번째 최적화는 Triton으로 융합한 커널 두 개(RMSNorm, 라우터 softmax)입니다. RMSNorm 커널은 격리 벤치마크에서 은닉 차원 512에서 5.62배, 4096에서 8.98배 빨랐고, softmax 커널은 2.01배였습니다. 두 커널을 함께 적용한 end-to-end 속도는 시퀀스 512·배치 4에서 0.999배였고, 시퀀스 128·배치 1에서는 0.785배로 오히려 느려졌습니다.

논문은 이 차이를 암달의 법칙으로 설명합니다. 프로파일러 구간으로 재면 두 커널이 맡은 연산은 순전파 시간의 7.87%(RMSNorm 7.70%, softmax 0.17%)만 차지했습니다. 유효 커널 가속 6.88배를 넣으면 end-to-end 상한은 1.072배이고, 실측값은 이 상한에도 미치지 못했습니다.

def amdahl_ceiling(f: float, s: float) -> float:
    # f: 개선한 구간이 전체 시간에서 차지하는 비율
    # s: 그 구간만 격리해 잰 가속 배율
    return 1 / ((1 - f) + f / s)
 
print(round(amdahl_ceiling(0.0787, 6.88), 3))  # 1.072

논문은 이 모델이 산술 연산보다 커널 실행 대기에 묶여 있다(launch-bound)고 봅니다. 작업량을 32배(시퀀스 128·배치 1에서 1024·배치 4로) 늘려도 지연이 246.8 ms에서 383.4 ms로 1.55배만 늘었다는 것이 근거입니다. 순전파당 약 1,000회라는 커널 실행 횟수는 전문가 64개와 레이어 16개의 루프 구조에서 나온 규모 추정이며, 논문은 직접 센 값을 보고하지 않았습니다.

torch.compile의 그래프 브레이크 23개를 모두 없앤 최적화도 같은 방향입니다. 시퀀스 1024·배치 4에서는 eager 실행의 0.327배 속도로 약 3배 느려졌고, 512·배치 4에서는 0.613배였습니다. 이 하위 실험은 cuDNN 어텐션 백엔드를 끄고 측정했으므로 앞의 end-to-end 수치와 직접 비교할 수 없습니다.

저자들은 원인으로 동적 shape를 듭니다. 브레이크 23개 중 16개는 전문가 디스패치의 데이터 의존 연산 torch.nonzero에서 나왔습니다. 이 연산을 그래프에 넣으면 컴파일러가 임의 크기를 처리하는 코드와 가드를 생성합니다.

중간 지표와 출력 품질

INT4 실험은 같은 문제를 품질 쪽에서 보여 줍니다. OLMoE를 bitsandbytes의 4비트(NF4)로 양자화하자 토큰 위치마다 선택된 전문가 8개 중 평균 0.53개가 바뀌었습니다. 그런데 FP16 가중치에 INT4의 라우팅만 적용하자 NLL 증가분의 2.7%만 재현됐습니다.

라우터만 FP16으로 유지한 실험도 같은 결론을 가리킵니다. NF4 조건에서 Jaccard 기준 라우팅 드리프트는 0.1140에서 0.0910으로 약 20% 줄었지만, NLL 증가분은 +0.0872에서 +0.0979로 커졌습니다. 라우팅 일치라는 중간 지표를 개선해도 출력 품질은 나빠질 수 있습니다.

논문은 이를 전문가들이 서로 대체 가능하다는 근거로 해석합니다. 인과 재현은 OLMoE 한 모델과 양자화 라이브러리 하나에서 수행했으므로, 다른 MoE에 적용하려면 추가 측정이 필요합니다. 전문가 라우팅의 기본 구조는 MoE 로드 밸런싱과 그래디언트 간섭에 정리했습니다.

제어 신호를 재는 위치

Decode-Latency Feedback Prefill(DLFP, arXiv:2609.38386, 2026-09)은 prefill 청크 상한을 조절하는 제어기입니다. 진행 중인 decode와 새 요청의 prefill이 겹칠 때만 작동합니다.

관측한 간격이 목표보다 길면 다음 상한을 줄이고, 짧으면 키웁니다. 관측값 L_t에는 스케줄러 호출 사이의 경과 시간을 쓰며, GPU 완료 시각은 재지 않습니다. 아래 식의 floor_128은 128토큰 단위로 내림하는 연산입니다.

c_next = clamp(floor_128(c_t * T / L_t), c_min, c_max)
 
T      = 80 ms        혼합 반복의 목표 시간
c_0    = 3072 tokens  초기 상한
c_min  = 1024 tokens
c_max  = 6144 tokens
L_t    = 관측한 스케줄러 호출 간격

중심 실험은 Qwen3-0.6B(BF16)를 A100 80GB 한 장에서 vLLM 0.17.1로 실행했습니다. 비동기 스케줄링과 CUDA graphs를 켜고, 입력 16,384토큰·출력 256토큰의 합성 Agent 부하를 Poisson 1 req/s로 보냈습니다. 시드 3개에서 각각 100요청을 잰 결과, P99 ITL(토큰 간 지연)은 평균 27.7% 줄었습니다(95% 신뢰구간 21.0~34.3%).

같은 실험에서 P99 TTFT(첫 토큰까지의 시간)는 평균 34.8% 늘었습니다(95% 신뢰구간 3.665.9%). SLO(서비스 수준 목표) goodput 변화는 −0.10%였고, 신뢰구간(−0.50+0.29%)은 0을 포함했습니다. 선언한 SLO(TTFT 5초, 평균 ITL 35 ms, 전체 지연 14초 이하)는 300/300 요청이 통과했습니다.

일반화 실험에서는 모델과 실행 구성을 바꿨습니다. Qwen3-8B와 Qwen3-32B는 NVLink 없이 PCIe로 연결한 A100 80GB 두 장에서 실행했습니다. 각 행은 별도 조건의 기준선과 후보를 비교하며, 8B와 32B 행은 요청 20개 또는 12개의 소표본입니다.

8B 0.25 req/s 행에서는 P99 ITL과 서비스 결과가 갈라집니다. P99 ITL은 1.763 s에서 707 ms로 줄었지만, P99 TTFT는 12.33 s에서 14.81 s로 늘었고 SLO 통과는 2/20에서 0/20이 됐습니다. P99 ITL 하나만 보고했다면 이 행은 개선으로 읽혔을 것입니다.

저자들은 원인을 측정 위치에서 찾습니다. 작은 모델에서는 스케줄러 호출 간격이 GPU 반복 완료 시간과 상관됐지만, 큰 커널과 비동기 큐잉, 텐서 병렬 동기화가 이 상관을 깨뜨린다는 분석입니다. 호스트 쪽 간격이 짧게 관측되면 제어기는 상한을 키우는데, 그때 디바이스 작업은 아직 남아 있을 수 있습니다.

sequenceDiagram
    participant S as 스케줄러 (호스트)
    participant G as GPU
    S->>G: 반복 t 제출
    S->>G: 반복 t+1 제출
    Note over S: 짧은 호출 간격 L_t 관측, 상한 확대
    S->>G: 더 큰 청크로 반복 t+2 제출
    G-->>S: 반복 t 완료

이 그림은 저자의 분석을 재구성한 개념도이며 측정한 타임라인이 아닙니다. 논문도 한계 절에서 디바이스 완료 시각을 직접 측정하지 않았다고 밝힙니다.

완료 시점에 제어기를 갱신하고 제어 단계의 폭을 제한한 32B 변형도 동기 스케줄링에서 기준선보다 P99 ITL과 SLO 통과가 모두 나빠졌습니다. 요청 12개 규모의 이 결과는 신호 변경만으로 문제가 해결된다는 근거가 되지 못합니다.

마감 기반으로 청크를 고르는 SLOWeave(arXiv:2609.07883, 2026-09)는 마지막 토큰 완료 시각에 TPOT(출력 토큰당 시간) 목표를 더해 마감을 정합니다. 그리고 예측 비용에 여유분을 더한 값이 가장 이른 마감까지 남은 시간에 들어가는 최대 청크를 고릅니다.

이 방식의 보장에도 경계가 있습니다. 논문의 명제는 비용 예측이 정확하고, 비용이 청크 크기가 커질수록 줄지 않으며, decode만 실행해도 마감을 지킨다는 가정을 둡니다. 그 가정에서 반복 하나의 마감만 보장하며, TTFT, 처리량, 과부하에서의 기아 방지는 보장 범위 밖입니다.

구성요소 지표와 토큰당 시간

SSD-LLaMA(arXiv:2609.18110, 2026-09)는 SSD에 둔 MoE 가중치로 소비자용 PC에서 추론합니다. 실험 환경은 Intel Ultra5 230F, RTX 5090(32GB), 호스트 DRAM 16GB, 최대 9 GiB/s의 4TB NVMe이며 배치 크기는 1입니다. 이 시스템에는 SSD에서 가중치를 가져오는 전달 경로와, 선택된 전문가를 CPU와 GPU 중 어디서 실행할지라는 두 결정이 있습니다.

논문 §4.3은 DeepSeek 모델에서 두 결정을 분리해 비교합니다. 77 MiB 레이어 버퍼를 쓰고, 모든 실행 위치 구성에서 SSD 읽기를 16,770회, 총 224.204 GB로 맞췄습니다. 같은 절의 22 GiB VRAM 캐시 구성은 캐시 조건이 다른 별도 비교입니다.

저자들은 CPU 배정으로 GPU 커널 시간은 줄었다고 설명합니다. 그러나 CPU에 배정한 전문가가 늘면서 남은 CPU 작업이 토큰당 9.42 ms에서 64.52 ms로 늘었고, 이 작업이 레이어 완료를 늦췄습니다. GPU 커널 시간만 쟀다면 CPU 배정은 개선으로 보였을 것입니다.

표의 첫 행과 셋째 행은 둘 다 GPU 실행이므로, 513.95 ms와 148.87 ms의 차이는 캐시 조건의 차이입니다. CPU 배정 행(529.52~573.73 ms)과 셋째 행을 비교하면 실행 위치와 캐시 조건이 함께 바뀌므로, 그 차이를 실행 위치의 효과로 읽을 수 없습니다. 실행 위치를 비교하려면 캐시 용량과 읽기량을 맞춰야 하고, §4.3의 통제 비교가 그렇게 설계됐습니다.

적중률도 결과 지표를 대신하지 못합니다. Alpaca 데이터셋의 캐시 정책 비교에서 gate 텐서만, 또는 gate·up 텐서만 캐시하는 정책은 전문가당 공간이 작아 전체 텐서 캐시보다 VRAM 적중률이 높았습니다. 그러나 캐시하지 않은 텐서의 반복 미스와 추가 I/O 때문에 처리량은 낮았고, 전체 텐서 캐시가 캐시 없는 기준선 대비 2.78배로 가장 높았습니다.

읽기량도 결과와 어긋날 수 있습니다. Edge0(arXiv:2609.18063, 2026-09)은 적재 대기를 줄이려고 이전 토큰에서 계산한 prerouter 예측을 다음 토큰의 실제 전문가 선택으로 씁니다.

MacBook M2 16GB에서 Qwen3.6-35B-A3B 기반 int4 모델을 top-4 라우팅으로 실행했습니다. 스텝당 읽기량은 50.9 MiB에서 58.9 MiB로 16% 늘었지만, decode 속도는 3.5 tok/s에서 6.4 tok/s로 올랐습니다. 같은 측정에서 레이어별 적재 대기의 합은 스텝당 244.0 ms에서 101.9 ms로 줄었습니다.

적재 대기의 합은 겹쳐 실행되는 레이어 대기를 더한 값이어서 실제 정지 시간과 같지 않습니다. Mac mini M4 Pro 24GB의 warm 조건에서는 prerouter를 끈 경우 19.9 tok/s, 켠 경우 20.4 tok/s로 차이가 작았습니다.

Edge0의 prerouter는 원래 라우터의 선택을 대체하므로 출력이 달라질 수 있습니다. 논문의 품질 비교는 int4 양자화, 라우팅 대체, recovery LoRA를 묶은 결과여서 prerouter만의 품질 영향은 분리되지 않았습니다. 따라서 선택된 전문가를 그대로 쓰는 SSD-LLaMA와 같은 조건의 비교가 아닙니다.

경계 밖에서 결과를 정한 요인

위 사례에서 측정한 값과 결과 지표가 같은 방향으로 움직인다는 보장은 없었습니다. 결과 지표를 정한 것은 측정 구간 밖의 요인이었습니다. 아래 표는 각 사례에서 측정한 값, 결과를 정한 요인, 결과 지표를 나란히 놓습니다.

경계의 종류는 사례마다 다릅니다. 융합 커널 사례는 시간 비율, DLFP는 호스트와 디바이스라는 측정 지점의 경계입니다. 그래프 브레이크, 라우팅 드리프트, 적중률, 읽기량은 중간 지표의 경계이고, CPU 배정은 측정한 장치의 경계입니다.

주장이 성립하지 않는 조건

측정한 구간이 실제 병목이고 개선이 구간 밖의 비용을 늘리지 않으면 국소 개선은 end-to-end로 이어집니다. 암달 상한 1.072배는 대상 연산 비율 7.87%에서 나온 값이고, 비율이 크면 같은 커널 가속의 상한도 커집니다. 국소 측정은 여전히 필요하며, 시간 비율과 함께 보고될 때 end-to-end 상한을 계산할 수 있습니다.

DLFP의 단일 GPU 결과는 그 조건 안에서 유효합니다. 다른 구성으로 옮기려면 그 구성에서도 호출 간격이 GPU 완료 시간을 대신한다는 근거가 필요합니다. 저자들도 모델 크기나 장치 수로 결과를 일반화하지 말라고 적었습니다.

근거의 강도에도 한계가 있습니다. DLFP의 중심 실험은 3회 × 100요청이고, 8B와 32B 일반화 실험은 조건당 요청 20개 또는 12개입니다. 전문가 대체 가능성의 인과 재현은 OLMoE 한 모델에서, SSD-LLaMA는 배치 1에서만 측정했습니다.

launch-bound 판단은 지연의 스케일링에서 나온 간접 근거이며, 논문은 커널 실행 횟수를 직접 센 값을 보고하지 않았습니다. SSD-LLaMA v1은 초록의 가속 범위가 §5.2의 기준선별 범위와 맞지 않아, 이 글은 통합 가속 배수를 인용하지 않았습니다. SSD-LLaMA §4.3은 DeepSeek 모델의 정확한 변형을 밝히지 않았고, Edge0는 단발 벤치마크에서 실행 간 편차가 ±40%라고 경고합니다.

소스가 답하지 못한 것도 있습니다. 다섯 논문 모두 단일 노드에서 측정했으며, 운영 트래픽과 다중 노드에서 같은 패턴이 나타나는지는 답하지 않습니다.

위 표의 일곱 사례가 서빙 최적화 일반에서 반복되는 패턴이라는 것은 판단입니다. 이 글은 각 결과의 독립 재현을 확인하지 못했습니다.

결과를 읽을 때 확인할 측정 경계

서빙 최적화 결과를 읽을 때는 개선폭보다 측정 경계를 먼저 확인합니다. 아래 질문에 답할 수 없는 결과는 end-to-end 개선의 근거로 쓰기 어렵습니다.

• 개선한 구간이 전체 시간에서 차지하는 비율을 보고하는가? 비율과 격리 배율로 암달 상한을 계산해 보고된 end-to-end 값과 비교합니다.
• 병목을 직접 측정했는가? 커널 실행 대기, CPU 작업, 전송 대기를 프로파일러로 쟀는지, 구조에서 추정했는지 구분합니다.
• 제어와 판단에 쓰는 신호는 어디서 측정하는가? 비동기 실행에서 호스트의 호출 시각은 디바이스의 완료 시각과 다를 수 있습니다.
• 상충 지표를 함께 보고하는가? ITL을 줄인 결과라면 TTFT, 전체 지연, SLO 통과, goodput과 각 신뢰구간을 확인합니다.
• 한 장치의 시간만 쟀는가? GPU 커널 시간이 줄어도 CPU 작업이나 전송이 토큰 완료를 늦출 수 있습니다.
• 비교 구성 사이에서 다른 변수를 맞췄는가? 캐시 용량, 읽기량, 배치 크기, 동기·비동기 스케줄링이 다르면 차이를 한 원인으로 돌릴 수 없습니다.
• 중간 지표가 결과 지표를 대신하는가? 적중률, 읽기량, 라우팅 일치, 그래프 브레이크 수는 결과 지표와 반대로 움직인 사례가 있습니다.
• 실행 구성이 바뀐 뒤 다시 측정했는가? 모델 크기, GPU 수, 텐서 병렬, 인터커넥트, 메모리 용량이 바뀌면 개선이 사라질 수 있습니다.

자체 실험이라면 같은 항목을 측정 계획에 넣습니다. 목표 지연을 지키는 처리량을 정하는 절차는 수용 가능 처리량 산정과 검증에 정리했습니다. TTFT와 토큰 간 지연 지표는 Transformer 구조와 LLM 서빙 최적화에 있고, KV 캐시 기법의 계측 순서는 KV 캐시 중심으로 본 LLM 서빙에 있습니다.

참고 자료

• Launch-Bound and Substitutable: Why Three Inference Optimizations Fail to Pay Off in Mixture-of-Experts Models, arXiv:2608.26612 (2026-08)
• Decode-Latency Feedback Prefill: A Model-Free Controller and Its Generalization Limits, arXiv:2609.38386 (2026-09)
• Deadline-Aware Adaptive Prefill Chunking for Efficient Large Language Model Serving, arXiv:2609.07883 (2026-09)
• SSD-LLaMA: SSD-Native Inference for Trillion-Parameter MoE at 1+ Token/s on a Consumer PC, arXiv:2609.18110 (2026-09)
• The Other Half of the Memory Wall: Serving 35B MoEs from SSD with Trained Routing Prediction, arXiv:2609.18063 (2026-09)

모든 수치는 2026-10 기준으로 각 원문에서 대조했습니다. DLFP, SLOWeave, SSD-LLaMA는 v1, Launch-Bound 논문과 Edge0는 v2를 기준으로 했습니다.

정리

서빙 최적화의 개선폭은 측정한 경계 안에서만 성립합니다. 융합한 RMSNorm 커널은 격리 벤치마크에서 5.62~8.98배 빨랐습니다. 그러나 두 융합 커널이 맡은 연산은 순전파의 7.87%여서 end-to-end 상한이 1.072배였습니다.

DLFP의 P99 ITL 27.7% 감소는 단일 GPU 조건의 결과였습니다. 저자들이 호출 간격과 GPU 완료 시간의 상관이 깨진다고 분석한 구성에서는 SLO 통과가 줄거나 그대로였습니다. 이 분석은 디바이스 완료 시각을 직접 측정한 결과가 아닙니다.

SSD-LLaMA에서는 CPU 배정으로 GPU 커널 시간이 줄었지만 CPU 작업이 늘어 토큰당 시간이 길어졌습니다. SSD-LLaMA의 적중률과 Edge0의 읽기량도 처리량과 다른 방향으로 움직였습니다.

결과를 읽을 때는 개선폭보다 앞의 체크리스트에 있는 측정 경계를 먼저 확인합니다. 근거는 소표본, 단일 모델, 배치 1 실험에서 나왔으므로, 이 패턴을 다른 시스템에 적용할 때는 같은 경계로 다시 측정해야 합니다.