LLM 서빙 트레이드오프의 이동

Gyullbb·4일 전

LLM

목록 보기
8/8

LLM 서빙 시 발생할 수 있는 트레이드오프를 다섯 가지로 정리하면 다음과 같다.

  • 처리량 vs 지연시간
  • 메모리 효율 vs 모델 품질
  • 하드웨어 활용 vs 유연성
  • 수직 확장 vs 수평 확장
  • 정적 최적화 vs 적응형 서빙

앞서 정리한 트레이드오프를 단순하게 해결하려 하면, 보통 전체 요청이나 자원에 하나의 정책이나 실행 설정을 적용하게 된다. 예를 들어 처리량 vs 지연시간 트레이드오프는 배치 크기를 하나 정해서 전체 요청에 적용하는 식으로 풀 수 있다. 수직 확장 vs 수평 확장도 레플리카를 동일한 단위로 취급한다는 전제에서 출발한다.

그런데 이 전제가 항상 맞지는 않는다. 요청 중에는 의미가 겹치는 것들이 있어서 실제로는 다르게 처리할 여지가 있다. 테넌트마다 쓰는 파인튜닝 모델(어댑터)이 다르면, 모델 하나로 전부를 처리한다는 전제 자체가 성립하지 않는다. 디바이스마다 쓸 수 있는 연산 유닛이 다르면, 하나의 실행 설정을 모든 디바이스에 동일하게 적용할 수 없다. 그리고 학습 루프에 들어가면 "레플리카마다 결과가 달라도 된다"던 전제가 깨지고, 대신 "재현 가능해야 한다"는 제약이 새로 생긴다.

지연시간이나 자원 사용을 지금보다 더 줄이려면, "전부 동일하게 처리한다"는 전제를 버리고 요청·어댑터·디바이스·레플리카 단위로 다르게 판단해야 한다. 이 네 단위에 각각 대응하는 기법이 시맨틱 캐싱/라우팅(요청 단위), Multi-LoRA 서빙(어댑터 단위), 엣지 이기종 컴퓨팅(디바이스 단위), RLHF 서빙(레플리카 단위)이다.

이름만으로는 정확한 원리를 파악하기 어렵다. 왜 이런 구조가 필요한지, 그 대가로 무엇을 지불하는지를 아래에서 살펴본다.

1. 시맨틱 캐싱과 라우팅

시맨틱 캐싱의 동작 방식은 다음과 같다. 문자열은 다르지만 의미가 같은 질문들을 같은 캐시 항목으로 묶는다. 새 질의가 들어오면 과거 질의들의 임베딩과 비교해서 충분히 가까운 게 있는지 벡터 검색으로 찾는다. 있으면(hit) 저장된 응답을 그대로 재사용하고, 없으면(miss) LLM을 호출한 뒤 결과를 캐시에 넣는다.

전통적인 캐싱은 문자열이 정확히 같아야 적중한다. 그런데 "시애틀에서 하와이까지 비행시간은?"과 "시애틀-하와이 비행시간이 몇 시간이나 돼?"는 문자열은 다르지만 뜻은 같다. 이 둘을 같은 걸로 보려면 텍스트를 의미 공간(semantic space)의 좌표로 바꿔야 한다. 그 좌표가 임베딩이다.

문제는 이 임베딩을 어떤 인코더로 만드느냐다. 문장 유사도를 매기는 인코더는 두 갈래로 나뉜다.

Cross-encoder와 Bi-encoder

  • Cross-encoder: 두 문장을 함께 모델에 넣어서 유사도 점수를 직접 뽑는다. 정확하지만, 캐시에 저장된 문장 하나하나와 매번 새로 짝지어 계산해야 한다.
  • Bi-encoder: 각 문장을 따로 인코딩해서 고정 차원 벡터로 바꾼다. 정확도는 좀 떨어지지만, 저장된 응답의 벡터를 미리 계산해두고 벡터 연산(내적·코사인 유사도)만 하면 된다.

캐싱이 되려면 "미리 계산해둔 벡터를 재사용"할 수 있어야 하는데, 이게 가능한 건 bi-encoder뿐이다. 그래서 시맨틱 캐싱은 처음부터 더 빠르지만 덜 정확한 방식을 쓸 수밖에 없다.

캐시에 임베딩이 수백만 개 쌓여 있다면, 매번 코사인 유사도를 전부 비교(O(N))하는 건 비효율적이다. 널리 쓰이는 근사 최근접 이웃(ANN) 알고리즘이 HNSW(Hierarchical Navigable Small World)다. 여러 층으로 된 그래프를 만들어서, 최상위 층은 노드가 적고 멀리 뛰는 연결만 두고, 아래로 내려갈수록 촘촘한 연결이 늘고, 최하위 층에는 벡터가 전부 들어 있게 한다. 검색은 최상위 층의 아무 노드에서 시작해 목표 벡터와 더 가까운 이웃으로 계속 이동하다가, 더 가까운 이웃이 없으면 한 층 내려간다. 캐시 항목이 100만 개라면 전수조사는 매번 100만 개의 벡터와 비교해야 한다. HNSW는 이 계층형 그래프를 따라 탐색 범위를 빠르게 좁혀가면서, 모든 벡터를 비교하지 않고도 근사 최근접 이웃을 찾는다. 다만 파라미터 M(노드당 연결 수), ef_construction(구축 시 탐색 폭), ef_search(검색 시 후보 수)에 따라 탐색 속도와 정확도가 달라진다. 벡터 검색 자체에도 정확도-속도 트레이드오프가 있는 셈이고, 시맨틱 캐싱은 트레이드오프를 없앤 게 아니라 그걸 검색 엔진 내부로 옮긴 것이다.

그럼 캐싱은 언제 이득일까. 캐싱을 쓰면 모든 요청에서 임베딩+검색 비용 c_search가 무조건 든다. 그리고 캐시가 비어있을 확률 (1-p)(p는 히트율)에서만 LLM 호출 비용 c_llm이 추가된다. 이 기대 비용이 그냥 매번 LLM을 부르는 비용보다 작아야 캐싱이 이득이다.

csearch+(1−p) cllm<cllmc_{search} + (1-p)\,c_{llm} < c_{llm}

양변에서 겹치는 항을 정리하면,

csearch<p⋅cllm⟺p>csearchcllmc_{search} < p \cdot c_{llm} \quad\Longleftrightarrow\quad p > \frac{c_{search}}{c_{llm}}

히트율 p가 c_search / c_llm만 넘으면 캐싱은 본전을 넘긴다. LLM 호출은 첫 토큰까지 걸리는 TTFT뿐 아니라, 이후 토큰을 하나씩 생성하는 시간까지 더해진다. 그래서 전체 응답 지연은 임베딩+ANN 검색(보통 수~수십 ms)보다 훨씬 크다. c_search / c_llm이 1%도 안 되는 경우가 흔하고, 이 정도면 손익분기 히트율도 1% 아래로 떨어진다. 캐시가 100번 중 1번만 맞아도 본전을 넘길 수 있다는 뜻이다. 손익분기가 이렇게 낮다는 것을 다시 생각해 보면, 이 기법의 진짜 위험은 비용이 아니라 캐시가 잘못 맞았을 때(오판) 생기는 응답 품질 문제이다.

오판이 왜 생기는지 보면, 코사인 유사도 임계값을 낮추면 히트율은 오르지만 오판(false positive)이 늘고, 높이면 오판은 줄지만 히트율이 떨어진다. 더 근본적인 문제는 부정어 문제다. "X 기능을 켜는 방법"과 "X 기능을 끄는 방법"은 단어가 거의 겹쳐서, 뜻은 정반대이지만 많은 임베딩 모델에서 코사인 유사도가 매우 높게 나온다. sentence embedding 모델은 화제(topic)에는 잘 반응하지만, 부정어 하나가 뜻을 뒤집는 건 잘 못 잡아낸다.

캐싱과 비슷한 논리가 라우팅에도 적용된다. RouteLLM은 인간 선호도 데이터로 라우터를 학습시켜, 어려운 질의는 강한 모델로, 쉬운 질의는 약한 모델로 보낸다. MCP(Model Context Protocol)는 JSON-RPC 2.0 기반 프로토콜로, 각 툴을 이름·설명·입력 스키마로 등록한다. 툴이 수십~수백 개면 전체 목록을 매번 프롬프트에 다 실어 보내는 게 prefill 비용을 키우므로, 사용자 요청과 툴 설명의 임베딩을 비교해서 관련성 높은 몇 개만 고른다. 앞서 본 HNSW 검색을 "응답 캐시"가 아니라 "툴 카탈로그"에 적용한 것과 정확히 같은 방식이다.

정리하면, 시맨틱 캐싱/라우팅은 트레이드오프를 없앤 것이 아니다. 캐싱은 LLM 호출 비용을 줄이는 대신 유사도 임계값과 오판 위험을 떠안았고, 라우팅은 정적 설정의 일반화 실패를 라우터의 오판(misrouting)이라는 문제로 옮겼다.

2. Multi-LoRA 서빙

기업이 LLM을 도입하는 두 번째 단계, 즉 파인튜닝(RAG 다음 단계)에 들어가면 새로운 메모리 문제가 생긴다. 테넌트마다 따로 파인튜닝된 모델을 쓰려면, 단순하게 생각했을 때 N개의 파인튜닝 모델에 N개의 GPU가 필요하다. 양자화는 모델 하나의 크기만 줄여줄 뿐, "모델이 N개 필요하다"는 문제 자체는 못 푼다. 이 문제에 대한 답이 LoRA와 Multi-LoRA 서빙이다.

LoRA는 파인튜닝할 때 가중치 변화량 ΔW가 낮은 랭크 구조를 가진다고 가정한다. 원래 가중치 W₀ ∈ R^(d×d)를 직접 바꾸는 대신 이렇게 쓴다.

W′=W0+BA,B∈Rd×r, A∈Rr×d, r≪dW' = W_0 + BA,\qquad B \in \mathbb{R}^{d\times r},\ A \in \mathbb{R}^{r\times d},\ r \ll d

전체 파인튜닝이면 레이어당 d×d개 파라미터를 통째로 새로 학습해야 한다. LoRA는 2dr개만 학습하면 된다. 두 파라미터 수의 비율을 구해보면,

d×d2dr=d2r\frac{d\times d}{2dr} = \frac{d}{2r}

d=4096, r=16을 넣으면 4096/32 = 128이 나온다. LoRA는 원래 필요했던 파라미터의 128분의 1만 학습한다는 뜻이다. 7B 모델의 어텐션 프로젝션에만 rank 16 LoRA를 적용해도 전체 어댑터 파라미터가 원본 모델의 0.1% 수준에 그치는 이유가 여기 있다. 어댑터는 원본 모델보다 훨씬 작기 때문에, 여러 어댑터를 하나의 GPU 메모리에 함께 올려 관리하기가 상대적으로 쉽다. Multi-LoRA 서빙은 이 성질 위에 서 있다.

문제는 이렇게 가벼운 어댑터를 실제 배칭에 어떻게 끼워 넣느냐다. 연속 배칭은 "같은 배치 안 요청들이 같은 가중치로 forward pass를 돈다"는 걸 전제로 한다. Multi-LoRA 서빙에서는 이게 깨진다. 같은 배치 안에서 요청 A는 어댑터1을, 요청 B는 어댑터2를 써야 한다. 어댑터별로 배치를 쪼개면 배치 크기가 작아져 GPU 활용도가 떨어지고, 요청마다 따로 연산하면 배치 연산의 이점을 아예 못 살린다. 결국 배치는 유지하면서 요청마다 다른 가중치를 적용하는 커널이 필요한데, Punica는 SGMV(Segmented Gather Matrix-Vector multiplication) 커널로 이 문제를 푼다.

  1. 배치 안 요청들을 쓰는 어댑터 기준으로 세그먼트로 묶는다.
  2. 베이스 모델 연산(x·W₀)은 배치 전체를 하나의 큰 GEMM으로 처리한다. 모든 요청이 같은 가중치를 쓰니까 원래 배칭 그대로다.
  3. LoRA 보정 연산(x·B·A)은 세그먼트별로 묶어서 배치 행렬곱으로 처리한다. 세그먼트마다 B, A는 다르지만 세그먼트 안에서는 여전히 배치로 묶인다.
  4. 두 결과를 더한다: y = x·W₀ + x·B·A.

이렇게 하면 서로 다른 어댑터가 섞인 요청도 하나의 배치 안에서 처리하면서, base model의 배칭 이점을 유지할 수 있다.

S-LoRA는 Punica의 배칭 아이디어에 메모리 관리를 더한다. 핵심은 "LoRA 가중치도 KV 캐시처럼 크기가 들쭉날쭉한 메모리 자원"이라는 것이다. 어댑터마다 rank가 달라서 메모리 블록 크기가 제각각이기 때문이다. S-LoRA는 vLLM의 페이지드 어텐션과 같은 아이디어를 어댑터 가중치에도 적용해서, KV 캐시와 어댑터 가중치를 같은 메모리 풀에서 고정 크기 페이지 단위로 관리한다(Unified Paging). 여기에 텐서 병렬화 환경에서 LoRA 연산의 통신 비용을 줄이는 병렬화 전략도 함께 제안한다.

배칭과 메모리 문제를 풀어도 남는 게 콜드 스타트 비용이다. GPU 메모리에는 자주 쓰는(hot) 어댑터만 올라가 있고, 트래픽이 적은(cold) 어댑터는 CPU나 디스크에 있다가 요청이 오면 그때 로드된다. 어댑터는 원본 모델보다 훨씬 작아 전송 비용을 줄일 수 있지만, 요청이 콜드 어댑터에 계속 몰리면 로드 비용이 반복해서 발생한다. KV 캐시 오프로딩의 콜드 스타트 문제와 같은 패턴이고, 위에서 본 캐시 히트율 문제와도 닮았다. 뭔가를 미리 계산해두고 재사용하는 전략은 항상 "그게 없을 때 갑자기 비싸진다"는 대칭적인 비용을 남긴다.

그렇다고 항상 Multi-LoRA가 정답인 건 아니다. 기준으로 삼을 만한 질문은 이거다. "어댑터 하나의 트래픽만으로 GPU 하나를 가득 채울 수 있는가." 어댑터당 트래픽이 낮아서 여러 개를 묶어야 GPU가 다 찰 정도라면(다수의 소규모 테넌트), Multi-LoRA가 유리하다. 반대로 소수의 어댑터가 각각 큰 트래픽을 받는다면, 병합한 뒤 수평 확장하는 게 더 단순하고 효율적이다.

정리하면, Multi-LoRA 서빙은 "메모리 효율 vs 품질" 트레이드오프를 없앤 게 아니다. "메모리 효율 vs 커널·스케줄링 복잡도"로 바꿔치기한 것이다. GPU 수를 N개에서 1개로 줄이는 대신, SGMV·Unified Paging 같은 특수 커널과 메모리 관리자를 새로 도입해야 하고, 콜드 어댑터를 스와핑할 때 생기는 지연시간 변동도 감수해야 한다.

3. 엣지 디바이스의 이기종 컴퓨팅

데이터센터는 엣지 디바이스보다 전력과 냉각에 훨씬 여유가 있고, 상대적으로 표준화된 GPU 환경을 구성하기 쉽다. 반면 엣지는 세 가지 제약을 한꺼번에 안고 있다. 제조사·세대별로 완전히 다른 NPU/GPU 조합, 배터리·발열이라는 물리적 한계, 배칭으로 효율을 낼 수 없는 단일 사용자 환경이다. 그래서 엣지에서는 "튜닝을 얼마나 유연하게 할 것인가"가 문제가 아니다. 정적인 설정 하나로는 애초에 작동 자체가 안 된다는, 더 강한 제약이 걸린다.

CPU는 범용성을 위해 분기 예측, 비순차 실행, 복잡한 캐시 계층에 트랜지스터 예산 대부분을 쓴다. 딥러닝의 핵심 연산인 행렬곱 입장에서는 비효율적인 설계다. 많은 NPU는 이 문제를 시스톨릭 어레이(systolic array) 구조로 푼다(Google TPU가 대표 사례다). 수천 개의 곱셈-누산 유닛을 격자로 배열해두고, 데이터가 그 배열을 따라 흘러가며 각 유닛은 도달한 데이터로 곱셈-누산만 한다. 한 번 적재한 데이터를 여러 사이클 재사용하기 때문에, 매번 메모리에서 새로 읽어오는 방식보다 데이터 이동 자체가 줄어든다. 연산보다 메모리 접근이 훨씬 많은 전력을 먹는다는 걸 생각하면, 데이터 이동을 줄이는 게 곧 저전력의 핵심이라는 걸 알 수 있다. 데이터센터 GPU가 절대 성능으로 경쟁한다면, 엣지 NPU는 배터리 한 번 충전으로 얼마나 오래, 뜨거워지지 않고 버티는지가 진짜 경쟁 지표다.

이렇게 다른 연산 유닛들이 한 디바이스 안에 섞여 있다 보니, 모델을 어떻게 쪼개서 나눠 돌릴지가 실제 구현의 핵심이 된다. ONNX Runtime의 Execution Provider는 모델 그래프의 각 연산자마다 지원하는 EP(CPU/CUDA/NPU 벤더별)를 찾아 서브그래프 단위로 할당하고, 미지원 연산자는 자동으로 CPU/GPU로 넘긴다. Apple Core ML의 Compute Units는 .cpuOnly, .cpuAndGPU, .all(ANE 포함) 옵션으로 실행 유닛을 지정하고, 레이어별 프로파일링을 거쳐 ANE 지원 연산은 ANE로 보낸다. Qualcomm QNN SDK는 Hexagon NPU/DSP, Adreno GPU, Kryo CPU 사이에서 그래프를 나누는데, 양자화 지원 여부가 파티셔닝 경계를 결정하는 주요 요인이다. 파티셔닝은 연산자 지원 여부, 프로파일링으로 예측한 실행 시간, 파티션 경계를 넘을 때 드는 데이터 이동 비용을 종합해서 결정된다. 파티션을 잘게 나눌수록 각 조각이 자기한테 맞는 유닛에서 돌아갈 확률은 높아지지만, 경계를 넘는 횟수가 늘수록 이동 오버헤드도 커진다. 여기서도 결국 "얼마나 잘게 나눌 것인가"가 또 다른 트레이드오프가 된다.

파티셔닝을 잘 해도 온도 문제는 남는다. 칩의 소비 전력은 대략 다음 식에 비례한다.

P∝V2×fP \propto V^2 \times f

전압 V가 제곱으로 걸린다. 그래서 클럭 f는 그대로 두고 전압만 살짝 낮춰도 소비전력은 제곱으로 줄어든다. 온도가 임계치에 가까워지면 DVFS(Dynamic Voltage and Frequency Scaling)가 클럭과 전압을 함께 낮추는 이유다. 문제는 이 조정이 실행 중에 실시간으로 일어난다는 것이다. 그래서 성능이 시간에 따라 예측 불가능해진다. big.LITTLE 아키텍처는 고성능 "big" 코어와 저전력 "LITTLE" 코어를 함께 둔다. 발열이 심할 때는 워크로드를 LITTLE 코어로 옮겨서 big 코어가 식을 시간을 번다. 엣지에서는 "최적화된 설정"이 그 순간의 온도 상태에 따라 계속 바뀐다. 시간 축의 적응형이 필수가 되는 이유다.

정밀도도 클라우드와 다르게 다뤄야 한다. 클라우드 GPU는 PTQ(학습 후 양자화)만으로 충분한 경우가 많다. 하지만 많은 NPU는 정수 연산만 처리하도록 설계돼 있어서, 부동소수점을 아예 못 쓰거나 쓰더라도 매우 느리다. 그러면 양자화는 선택이 아니라 필수가 된다. 이때는 PTQ만으로 정확도 손실이 커지는 경우가 많아서, 학습 단계부터 양자화를 반영해서 학습하는 QAT가 필요해진다.

정리하면, 이기종 컴퓨팅과 서브그래프 파티셔닝은 "하드웨어 활용 vs 유연성" 트레이드오프를 없앤 게 아니다. 그 대가를 엔지니어링 복잡도로 옮겼을 뿐이다. 파티션 경계마다 생기는 텐서 복사·포맷 변환 오버헤드, 디바이스 세대·펌웨어마다 반복해야 하는 유지보수 부담, DVFS/big.LITTLE이 만드는 성능 비결정성이 그 대가다.

4. RLHF 서빙과 재현성

앞의 세 사례가 요청·어댑터·디바이스에 따라 실행을 다르게 최적화하는 문제였다면, 이번은 좀 다르다. "수직 확장 vs 수평 확장"이라는 트레이드오프의 결론, 즉 대부분 수평 확장이 낫다는 결론 자체가 RLHF라는 맥락에서 흔들리는 이야기다.

수학에서는 (a+b)+c = a+(b+c)가 항상 참이다. 하지만 IEEE 754 부동소수점 연산에서는 대체로 성립하지 않는다. 유한한 비트로 실수를 근사하기 때문에 덧셈마다 반올림이 생기고, 그 오차가 계산 순서에 따라 다르게 쌓인다. 극단적인 예를 들면 다음과 같다. (1e20 + 1) - 1e20은 부동소수점에서 흔히 0이 나온다. 1e20에 1을 더해도 정밀도 한계 때문에 반올림되어 그대로 1e20이 되기 때문이다. 반면 1e20 + (1 - 1e20)은 1이 나온다. 수학적으로는 둘 다 1이어야 하는데 실제로는 다르다. 한 번의 연산에서는 무시할 만하지만, LLM의 forward pass는 레이어당 수천~수만 번의 곱셈-누산(reduction)을 한다. attention softmax, matmul 내적, layernorm의 평균·분산 계산이 전부 대규모 reduction이다.

이 반올림 오차가 서빙과 만나는 지점이 배치 크기다. cuBLAS/cuDNN 같은 라이브러리는 입력 행렬의 shape(차원, 배치 크기)에 따라 내부적으로 다른 커널 구현(타일링 전략, 스레드 블록 분할 방식)을 고른다. 성능을 위한 당연한 설계지만, 배치 크기가 다르면 같은 수학 연산이라도 실제 덧셈 순서가 달라질 수 있다. FlashAttention 같은 커널의 블록 단위 온라인 softmax도 마찬가지다. 배치·시퀀스 길이 조합에 따라 블록 분할이 달라지면 reduction 순서도 함께 달라진다. 앞서 다룬 연속 배칭은 매 스케줄링 스텝마다 그 순간 대기 중인 요청 조합에 따라 배치 구성이 계속 바뀐다. 즉,

연속 배칭이 처리량을 극대화하려고 배치 구성을 동적으로 바꾸는 바로 그 메커니즘이, 매번 미세하게 다른 부동소수점 reduction 순서를 만드는 원인이 된다.

같은 프롬프트를 두 번 보내도, 그 순간 함께 배치된 다른 요청이 다르면 로짓 값이 소수점 한참 아래에서 미세하게 달라진다. 경계선 상황에서는 토큰 하나의 argmax가 뒤집힐 수 있고, 그러면 이후 생성되는 시퀀스 전체가 갈라진다. 토큰 하나가 다음 토큰의 입력이 되는 구조라서, 작은 차이가 뒤로 갈수록 커진다.

Thinking Machines Lab의 "Defeating Nondeterminism in LLM Inference"(2025)는 이 문제를 정면으로 다룬다. 핵심 제안은 배치 불변(batch-invariant) 커널이다. 배치 구성이 뭐든 항상 같은 연산 순서(고정된 reduction tree)를 쓰도록 커널을 설계한다. GPU가 상황에 맞춰 가장 빠른 알고리즘을 고르는 자유도를 일부 포기하는 대신, 약간의 성능 손실을 감수하고 수치적 재현성을 얻는다.

여기까지는 일반 추론 서빙에서도 벌어지는 일이다. RLHF에서 이게 특히 문제가 되는 이유는 훈련 루프의 구조 때문이다. RLHF 루프는 대략 이렇게 돈다.

  1. 액터 모델(현재 정책)이 대량의 후보 응답을 생성한다.
  2. 보상 모델이 각 응답에 점수를 매긴다.
  3. 참조 모델과 비교해 정책 그래디언트를 계산한다.
  4. 액터 모델을 업데이트한다.
  5. 새 가중치를 서빙 레플리카에 동기화한다.

이 과정을 수천 번 반복한다. 같은 정책과 같은 프롬프트를 사용하더라도 생성 과정이 비결정적이면 실행마다 미세하게 다른 결과가 나올 수 있다. 특히 동일한 조건에서 결과를 재현해야 하는 실험이나 디버깅에서는 이러한 차이가 문제가 될 수 있다. 생성 결과의 차이가 그래디언트 추정에 영향을 주고, 수천 번의 반복 과정에서 학습 결과의 변동으로 이어질 수 있기 때문이다. 일반 추론 서빙에서 "성능"이 처리량·지연시간이었다면, RLHF 서빙에서는 "재현 가능한 정확한 로짓 분포"까지 성능에 들어간다.

OpenRLHF나 veRL(ByteDance) 같은 오픈소스 RLHF 프레임워크는 생성과 훈련을 분리된 프로세스 그룹으로 운영한다. 액터 모델은 vLLM/SGLang 같은 서빙 엔진으로 여러 레플리카에 배포되어 샘플을 만들고, 훈련 스텝이 끝나면 업데이트된 가중치를 NCCL 브로드캐스트로 서빙 레플리카에 뿌린다. 이 구조는 서빙과 훈련을 분리해서 GPU 활용도를 극대화하지만, 위에서 말한 비결정성 문제는 그대로 남는다. 최근에는 위에서 본 배치 불변 커널을 실제 파이프라인에 적용하거나, 같은 정책을 평가할 때는 배치 구성을 고정하거나, 비결정성이 훈련 안정성에 미치는 영향을 정량적으로 모니터링하는 방법이 함께 논의되고 있다.

정리하면, "수평 확장이 대체로 낫다"는 결론은 순수 추론 서빙에서는 여전히 맞다. 하지만 RLHF라는 맥락이 더해지면, 그 결론에 숨어 있던 전제 — "레플리카 간 결과가 완전히 같지 않아도 상관없다" — 가 깨진다. 즉 RLHF에서는 수직 확장 vs 수평 확장이라는 기존의 선택이 처리량뿐 아니라 재현성까지 고려해야 하는 문제로 확장된다.

5. 정리하며

지금까지 앞서 정리한 트레이드오프가 실제 시스템에서 어떻게 재등장하는지 네 가지 사례로 봤다. 시맨틱 캐싱/라우팅은 요청을, Multi-LoRA는 어댑터를, 엣지 이기종 컴퓨팅은 실행 위치를, RLHF 서빙은 레플리카를 각각 다른 기준으로 판단하는 기법이었다.

파트원래 트레이드오프옮겨간 축
1. 시맨틱 캐싱/라우팅처리량 vs 지연시간, 정적 vs 적응형정확도·신뢰성 (오판, 부정어 문제)
2. Multi-LoRA 서빙메모리 효율 vs 모델 품질커널·스케줄링 복잡도
3. 엣지 이기종 컴퓨팅하드웨어 활용 vs 유연성데이터 이동·엔지니어링 유지보수 부담
4. RLHF 서빙수직 확장 vs 수평 확장재현성(결정론)

네 사례를 같이 놓고 보면 패턴이 하나 보인다. 서빙 최적화 기법이 고도화될수록 트레이드오프는 사라지지 않는다. 대신 더 재기 어려운 축, 즉 신뢰성·복잡도·재현성 쪽으로 옮겨간다. 앞서 본 다섯 가지 트레이드오프는 답이 정해진 저울질이었다. 반면 이번에 본 해법들은 그 저울질 자체를 없애는 대신, 오판율·유지보수 비용·재현성 같은 새 기준을 하나씩 더 만든 것이다.

결국 중요한 문제는 이 새 기준들을 어떻게 측정하고 검증할 것인가에 있다.

profile
Gyullbb
이전 포스트

5편-1. GPU 연결 구조

0개의 댓글