🤖 AI

Think Before You Grid-Search: Floor-First Triage for LLM Serving

본 논문은 LLM 디코딩을 5차원 리소스 벡터로 모델링하여 과도한 프로파일링이나 그리드 탐색에 의존하기 전에 성능 경계치를 분석적으로 결정하고 구속 조건을 식별함으로써 다양한 운영 지점에 대한 계산 가능한 레이아웃 결정을 가능하게 하는 구성적이고 추정 중심적인 워크플로우인 "Floor-First Triage"를 제안한다.

원저자: Yihua Liu

게시일 2026-07-08✓ Author reviewed ⓘ

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Yihua Liu

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

큰 문제: 추측하기 vs 알기

당신이 수백만 명의 고객에게 음식을 제공하는 거대하고 빠른 레스토랑(거대 언어 모델, LLM)을 운영하고 있다고 상상해 보세요. 당신은 주방이 폭발하지 않으면서도 최대한 빠르게 음식을 서빙하고 싶습니다.

현재는 주방이 느려지면 대부분의 팀이 당황하여 모든 것을 시도합니다. 요리사의 수를 바꾸고, 테이블 크기를 조절하고, 오븐의 종류를 바꾸고, 레시피를 바꿉니다. 수백 번의 테스트를 실행하고 결과를 측정하며, 어떤 조합이든 작동하기를 바랍니다. 이것을 "그리드 서치(grid-searching)"라고 합니다. 이는 비용이 많이 들고, 시간을 낭비하며, 종종 진짜 문제를 놓치게 만듭니다.

이 논문은 이렇게 주장합니다: 추측하지 마세요. 계산부터 하세요.

핵심 아이디어: 먼저 "바닥(Floor)"을 구축하라

저자들은 **"플로어 퍼스트(Floor First)"**라고 불리는 새로운 워크플로우를 제안합니다.

레스토랑에 콘크리트 바닥이 있다고 상상해 보세요. 가구를 어떻게 배치하든, 그 바닥은 가구가 내려갈 수 있는 절대적인 최저점입니다. 컴퓨터 칩의 세계에서 이 "바닥"은 물리 법칙(전기가 얼마나 빨리 움직이는지, 데이터가 메모리에 얼마나 들어가는지 등)에 기반한 이론적 최소 시간을 의미합니다.

워크플로우:

바닥 계산하기: 노브를 하나라도 건드리거나 테스트를 실행하기 전에, 하드웨어의 "속도 제한"을 찾기 위해 간단한 수학 계산을 수행합니다.
현실 측정하기: 시스템을 실제로 실행하여 얼마나 빠른지 확인합니다.
격차 확인하기:
- 작은 격차: 실제 속도가 이론적 바닥에 매우 가깝다면, 당신은 잘하고 있는 것입니다. 멈추세요. 프로파일링(성능 분석)에 시간을 낭비하지 마세요. 하드웨어가 이미 물리적으로 할 수 있는 만큼 최선을 다하고 있습니다.
- 큰 격차: 실제 속도가 바닥보다 훨씬 느리다면, 그때 "프로파일러"(정교한 진단 도구)를 열어 이유를 찾아냅니다. 요리사가 재료를 떨어뜨리고 있나요? 아니면 문이 걸려 있나요?

비유:
자동차를 생각해보세요. 도로의 제한 속도가 60mph인데 당신의 차가 60mph로 달리고 있다면, 정비사에게 엔진이 괜찮다는 말을 들을 필요가 없습니다. 그냥 한계에 도달했다는 것을 알 수 있죠. 하지만 20mph로 달리고 있다면, 그때는 엔진을 점검해야 합니다. 이 논문은 언제 검사를 멈춰야 할지 알 수 있도록 당신에게 속도 제한 표지판을 제공합니다.

"5차원" 성적표

이 바닥을 계산하기 위해, 저자들은 이 문제를 여행을 위한 쇼핑 리스트처럼 다섯 가지 간단한 자원 범주로 나눕니다:

메모리 트래픽: 얼마나 많은 데이터가 이동해야 하는가? (예: 얼마나 많은 캐리어를 옮겨야 하는가).
연산 능력: 얼마나 많은 수학 계산이 필요한가? (예: 얼마나 많은 거리를 운전해야 하는가).
네트워크 트래픽: 컴퓨터 간에 얼마나 많은 데이터가 전송되는가? (예: 얼마나 많은 전화를 거는가).
네트워크 메시지: 얼마나 자주 "안녕하세요"라고 말해야 하는가? (예: 통화를 시작하는 데 걸리는 시간).
저장 용량: 대화의 "기억"을 위한 공간이 얼마나 있는가? (예: 트렁크의 크기).

이 범주들을 채우는 데 걸리는 시간을 모두 더하면 "바닥(Floor)"이 나옵니다. 논문은 영리한 기법을 도입하는데, 모든 일이 완벽하게 동시에 일어난다고 가정하는 **낙관적 바닥(Optimistic Floor)**과 모든 일이 순차적으로 일어난다고 가정하는 **비관적 바닥(Pessimistic Floor)**을 계산합니다. 만약 실제 속도가 이 두 숫자 사이에 있다면, 당신의 시스템이 작업들을 얼마나 잘 중첩(overlap)시키고 있는지 알 수 있습니다.

사례 연구: "H20" 칩

이 논문은 NVIDIA H20이라는 특정하고 까다로운 컴퓨터 칩을 대상으로 이 아이디어를 테스트합니다.

상황: 이 칩은 거대한 화물칸(메모리)은 있지만 엔진(연산 능력)은 약한 트럭과 같습니다.
갈등: 두 팀이 이 트럭들을 사용하여 서로 다른 레스토랑을 만들었습니다.
- A팀은 요리사(프로세서)들이 하나의 큰 그룹으로 함께 일하도록 주방을 배치했습니다.
- B팀은 요리사들이 더 작고 분리된 그룹으로 일하도록 배치했습니다.
- 그들은 "민간 전승(folklore)"과 시행착오에 의존하며 어떤 방식이 더 나은지에 대해 논쟁했습니다.

논문의 판결:
"플로어 퍼스트" 수학을 사용했을 때, 저자들은 정답이 전적으로 대기 중인 고객의 수에 달려 있다는 것을 보여주었습니다.

고객이 적을 때: A팀의 배치가 더 빠릅니다.
고객이 많을 때: B팀의 배치가 더 빠릅니다. 왜냐하면 엔진은 약간 느릴지라도 "트렁크 공간"(메모리 용량)을 더 잘 처리하기 때문입니다.

수학은 두 팀 모두 각자의 상황에서 옳았음을 증명했습니다. 당신의 특정 고객 수가 천장에 부딪히는 지점(벽)이 어디인지 계산함으로써 추측할 필요가 없습니다.

"에이전트(Agent)" 기술

이 논문은 또한 이 로직을 AI 코딩 에이전트에게 가르칠 수 있다고 언급합니다. AI 에이전트가 무작정 테스트를 실행하며 돈을 낭비하는 대신, 다음과 같이 프로그램될 수 있습니다:

먼저 수학 계산하기: 바닥을 계산합니다.
허락 구하기: "제 계산에 따르면 이 테스트는 시간 낭비입니다. 건너뛰어도 될까요?"
필요할 때만 프로파일링하기: "제 계산에 따르면 큰 격차가 있습니다. 지금 진단 도구를 열어야 합니다."

요약

이 논문은 최적화를 위해 "무차별 대입(brute-forcing)"하는 것을 멈추라는 촉구입니다.

과거의 방식: 모든 것을 시도하고, 모든 것을 측정하며, 운이 좋기를 바랍니다.
새로운 방식 (플로어 퍼스트): 수학을 통해 속도 제한을 찾으세요. 제한에 가깝다면 멈추세요. 제한과 멀리 떨어져 있다면, 누출(leak)을 찾으세요.

이것은 혼란스럽고 비용이 많이 드는 추측 게임을, 언제 멈춰야 하고 언제 더 깊이 파고들어야 하는지 정확히 알 수 있는 깔끔하고 논리적인 과정으로 바꿉니다.

기술 요약: LLM 서빙을 위한 Floor-First 트리아지(Triage)

문제 정의
LLM 서빙을 최적화하는 프로덕션 팀들은 병렬화 레이아웃(TP, EP, DP), 배칭, 양자화 및 커널 수준 작업이 얽힌 방대한 설정 공간에 직면해 있다. 미달된 레이턴시 타겟에 대한 기존의 운영 방식은 수많은 설정을 벤치마크하고 Nsight Systems와 같은 무거운 프로파일러를 무분별하게 투입하는 것이다. 이러한 접근 방식은 종종 비효식적인 그리드 탐색으로 변질되며, 측정된 성능 수치는 모호해진다. 예를 들어, 느린 TPOT(Time Per Output Token)가 근본적인 대역폭 제한 때문인지, 구현상의 결함인지, 노출된 통신 문제인지, 호스트 오버헤드인지, 혹은 성능이 낮은 커널 때문인지 알 수 없게 된다. 본 논문은 엔지니어링 커뮤니티가 언제 프로파일링이 필요한지, 그리고 어디를 먼저 살펴봐야 하는지를 결정하는 체계적인 의사결정 절차가 부족하다고 주장한다. 이로 인해 명시적인 자원 계산이 아닌 민속적 지식(folklore)에 기반하여 동일한 하드웨어에서 DeepSeek 모델에 대해 서로 상충하는 병렬 전략을 사용하는 등의 예측 불가능한 배포 선택이 발생한다.

방법론: Floor-First 트리아지
본 논문은 분석적 추정을 기본 프로파일링 계층으로 취급하는 잔차 기반(residual-driven) 트리아지 워크플로우인 "Floor First"를 제안한다. 이 방법론은 네 가지 뚜렷한 단계로 구성된다:

분석적 플로어 구축 (Analytical Floor Construction): 벤치마킹을 수행하기 전, 시스템은 주어진 설정에 대해 "양방향 플로어(two-sided floor)"를 계산한다. 이 모델은 각 디코드 단계를 HBM 바이트, FLOPs, 네트워크 바이트, 네트워크 메시지, KV 용량이라는 5차원 자원 벡터로 취급한다.
- 낙관적 플로어 ( $t_{opt}$ ): 완벽한 중첩(overlap)을 가정하여 독립적인 자원 시간들의 최댓값( $max(t_{HBM}, t_{compute}, t_{network})$ )으로 계산된다.
- 비관적 플로어 ( $t_{sum}$ ): 모든 자원 시간의 합( $t_{HBM} + t_{compute} + t_{network}$ )으로 계산되며, 이는 중첩이 전혀 없음을 가정한다.
- 진단 구간 (Diagnostic Interval): 측정된 벤치마크 값이 $[t_{opt}, t_{sum}]$ 구간 내 어디에 위치하는지는 시스템 중첩도를 파악하기 위한 제로 코스트 진단 도구가 된다. 측정값이 $t_{opt}$ 에 가깝다면 중첩이 잘 이루어지고 있는 것이고, $t_{sum}$ 에 가깝다면 스케줄링/중첩이 병목인 것이며, $t_{sum}$ 보다 높다면 측정되지 않은 비용(호스트 갭, 스트래글러 등)으로 시간이 누수되고 있는 것이다.
벤치마크 규율 (Benchmark Discipline): 벤칙마크는 엄격한 규칙 하에 수행되어야 한다: 자기 제한(self-throttling) 편향을 피하기 위한 오픈 루프 부하 생성, 현실적인 길이 분포, 정상 상태(steady-state) 운영, 그리고 꼬리 백분위수(P99) 보고.
조정 및 트리아지 (Reconciliation and Triage): 측정된 시간은 플로어와 비교된다.
- 작은 잔차 (< 1.3× floor): 조사를 중단한다. 시스템이 해당 축의 이론적 한계에 근접했으므로, 추가 최적화는 커널 튜닝이 아닌 아키텍처 변경(예: 희소 어텐션, 양자화)이 필요하다.
- 큰 잔차: 프로파일링을 격상한다. Nsight Systems는 오직 세 가지 질문에 답하기 위해서만 사용된다: 커널 사이에 갭이 존재하는가? 통신이 노출되어 있는가? 어떤 커널 클래스가 분석된 예산을 초과하는가? Nsight Compute는 다른 원인들이 배제된 후에도 자신의 예산을 초과하는 커널 클래스에 대해서만 엄격하게 사용된다.
월 오더링 (Wall Ordering): 단일 배치 레이턴시를 비교하는 대신, 부하가 증가함에 따라 어떤 자원 제약(KV 용량, KV 대역폭, 가중치 대역폭, 또는 연산량)이 먼저 벽(wall)에 부딪히는지 결정하는 "월 오더링"을 통해 배포를 평가한다. 용량은 사후적인 메모리 체크가 아니라 일급 자원 차원으로 취급된다.

주요 기여

잔차 기반 트리아지 워크플로우: 타겟 정의, 플로어 구축, 프로파일러 격상을 분리하고, 최적화 노력을 파이프라인 작업(레이아웃/스케줄링) 또는 커널 작업으로 배정하는 명시적인 정지 규칙을 가진 의사결정 루프를 제공한다.
양방향 플로어 모델: 측정된 값과 플로어 사이의 간극을 사용하여 프로파일러 실행 없이도 중첩 효율성을 진단할 수 있는 분석적 모델을 제공한다.
월 오더링 결과물: 동시성이 증가함에 따라 어떤 자원 벽이 먼저 발생하는지를 기준으로 배포 대안을 비교하는 방법을 제시하며, 이를 통해 단일 배치 레이턴시는 더 나쁘더라도 더 높은 용량 벽을 가진 레이아웃이 높은 동시성 영역의 굿풋(goodput) 프런티어를 지배할 수 있음을 밝혀낸다.
메트릭 규율: 활용도 메트릭(MFU vs. MBU)을 "리지 아이덴티티(ridge identity)" ( $MFU/MBU = I_{work}/I_{ridge}$ )를 기반으로 체계화하여, 바인딩된 자원에 맞는 올바른 메트릭이 보고되도록 보장한다.
아티팩트 및 에이전트 스킬: 제로 디펜던시 파이썬 아티팩트(floor.py)와 에이전트가 읽을 수 있는 스킬(SKILL.md)을 통해 이러한 규율을 강제하며, 에이전트가 무의식적으로 프로파일러를 찾는 것을 방지한다.

사례 연구 결과
본 논문은 이 방법론을 16개의 NVIDIA H20 GPU 상에서 구동되는 DeepSeek-V3.2 스타일의 671B MoE 모델에 적용한다.

하드웨어 특성 파악: H20 GPU는 약 74 FLOP/byte의 리지 포인트(ridge point)를 가진 것으로 식별되었다(H100의 ~590 대비). 이는 메모리 바운드 영역이 8배 더 넓은 극단적인 "디코드 지향형" 부품임을 의미한다.
레이아웃 판단:
- TP16: 배치 사이즈 64 및 컨텍스트 8K에서, TP16은 KV 용량에 의해 약 70개의 동시 요청으로 제한된다. KV 대역폭 항이 유의미하며, 연산 벽(compute wall)은 실행 가능한 영역 내에서 도달 불가능하다.
- EP16 + DP Attention: 이 레이아웃은 가중치 트래픽을 약간 희생하는 대신, 약 644개의 요청이라는 훨씬 높은 용량 벽을 제공한다. TP16은 단일 스트림 레이턴시 측면에서는 더 빠르지만(B=1에서 2.4배 빠름), 고동시성 굿풋 프런티어에서는 EP16+DP가 우위를 점한다.
- Sparse Attention (DSA): KV 대역폭 벽은 제거하지만, 전체 KV가 주소 지정 가능해야 하므로 용량 벽은 제거하지 못한다.
이견의 해소: 본 연구는 왜 서로 다른 팀들이 동일한 하드웨어에서 상반된 레이아웃(TP vs. DP)을 배포했는지 설명한다. 최적의 선택은 작동 지점(동시성)의 함수이다. 고동시성은 DP를 선호하고, 저동시성은 TP를 선호한다.

의의 및 주장
본 논문은 프로덕션에서의 의견 불일치가 광범한 실험이 아닌, 작은 규모의 자원 계산(GPU당 5개의 숫자와 모델 차원)으로부터 예측 가능하다고 주장한다. 이 계산을 체계화함으로써, 본 워크플로우는 다음과 같은 일반적인 트리아지 절차를 제공한다:

측정값이 분석적 플로어에 근접했을 때 낭비되는 프로파일링 노력을 방지한다.
값비싼 도구를 사용하기 전에 올바른 최적화 축(파이프라인 vs. 커널)을 식별한다.
점 단위의 벤치마크가 아닌 "월 오더링"을 통해 배포 선택을 설명한다.
표준 휴리스틱이 실패하는 극단적인 특성(H20와 같은)을 가진 하드웨어에 대한 견고한 방법을 제공한다.

저자들은 현재 초안이 분석적 플로어와 보정된 상수에 의존하고 있으며, 잔차 임계값과 격상 규칙을 경험적으로 검증하기 위한 측정 캠페인(섹션 8)이 계획되어 있다고 겸허히 언급한다. 이 방법은 시뮬레이터나 프로파일러를 대체하기 위한 것이 아니라, 플로어 체크를 통과한 잔차를 위해 여전히 필수적인 엔지니어링 의사결정 절차로서 제시된다.