들어가며: 이미지 한 장이 서빙을 바꾼다
텍스트 LLM 서빙은 지난 몇 년간 상당히 표준화됐습니다. continuous(in-flight) batching으로 요청을 끊임없이 채우고, paged KV cache로 메모리를 가상메모리처럼 관리하며, decode 단계가 메모리 바운드라는 점을 이용해 양자화와 KV 최적화로 처리량을 끌어올립니다. vLLM, TensorRT-LLM, SGLang 같은 프레임워크가 이 패턴을 잘 구현합니다.
그런데 입력에 이미지가 들어오는 순간 이야기가 달라집니다. 멀티모달 LLM은 텍스트 토큰만 받던 파이프라인 앞에 비전 인코더 단계가 붙고, 요청마다 비주얼 토큰 수가 들쭉날쭉하며, 프리필(prefill) 비용이 텍스트 대비 급증합니다. 텍스트 전용 서빙에서 잘 통하던 가정들이 흔들립니다.
이 글에서는 멀티모달 LLM 서빙이 텍스트 전용과 무엇이 다른지, 그 차이가 만드는 구체적 과제와 대응을 정리합니다. 비전 인코더 추가 단계, 가변 비주얼 토큰, 프리필 비용, KV 캐시와 배칭의 난점, 지연 분해, 처리량 최적화, 비용, 그리고 운영 함정과 체크리스트까지 다룹니다.
텍스트 전용과 무엇이 다른가
비전 인코더라는 추가 단계
텍스트 전용 LLM은 토크나이즈 → 프리필 → 디코드의 흐름입니다. 멀티모달은 그 앞에 이미지 전처리와 비전 인코딩이 추가됩니다.
텍스트 전용 vs 멀티모달 서빙 흐름
[텍스트 전용]
텍스트 -> 토크나이즈 -> prefill -> decode(토큰 생성)
[멀티모달]
이미지 -> 전처리(리사이즈/정규화) -> 비전 인코더(ViT) ->
프로젝터(어댑터) -> 비주얼 토큰
텍스트 -> 토크나이즈 -> 텍스트 토큰
[비주얼 토큰 + 텍스트 토큰] -> prefill -> decode
비전 인코더는 무겁습니다. ViT 순전파는 GPU 연산을 추가로 소비하며, 이미지가 크고 많을수록 이 단계가 길어집니다. 이 추가 단계는 첫 토큰 지연(TTFT)에 그대로 들어갑니다.
가변 비주얼 토큰 수
텍스트 전용 서빙에서도 입력 길이는 가변이지만, 멀티모달은 변동성이 더 큽니다. 같은 "이미지 한 장"이라도 해상도에 따라 비주얼 토큰이 256개일 수도, 4000개일 수도 있습니다. 임의 해상도를 지원하는 모델(동적 해상도)에서는 더욱 그렇습니다.
비주얼 토큰 수의 변동(개념)
요청 A: 작은 썸네일 1장 -> 비주얼 토큰 ~256
요청 B: 고해상도 문서 1장 -> 비주얼 토큰 ~3000
요청 C: 이미지 4장 -> 비주얼 토큰 ~4000+
문제: 시퀀스 길이가 요청마다 크게 달라
배치 메모리/연산 예측이 어렵고 불균형 발생
이 변동성은 배칭과 메모리 계획을 어렵게 만듭니다. 한 배치에 토큰 수가 천차만별인 요청이 섞이면, 패딩 낭비나 메모리 초과가 생기기 쉽습니다.
프리필 비용 급증
비주얼 토큰이 많다는 건 프리필 시퀀스가 길다는 뜻입니다. 어텐션은 시퀀스 길이에 제곱으로 비싸므로, 프리필 연산이 급증합니다. 텍스트 전용에서는 프리필이 짧고 디코드가 길었다면, 멀티모달에서는 프리필 자체가 무거운 작업이 됩니다.
프리필 비용 비교(개념)
[텍스트 전용] 프롬프트 200토큰
prefill: 200토큰 1회 처리 (상대적으로 가벼움)
[멀티모달] 텍스트 50 + 비주얼 3000 = 3050토큰
prefill: 3050토큰 처리, 어텐션 O(L^2) 항 급증
-> TTFT의 대부분이 prefill + 비전 인코딩에서 발생
이미지 전처리와 캐싱
이미지 전처리(디코드, 리사이즈, 정규화)와 비전 인코딩은 비싸지만, 종종 재사용 가능합니다. 같은 이미지가 여러 요청(멀티턴 대화, 동일 문서 반복 질의)에서 등장하면 비전 인코딩 결과를 캐싱해 재활용할 수 있습니다.
이미지/비주얼 토큰 캐싱(개념)
요청 들어옴 -> 이미지 해시 계산
캐시 히트? -> 캐시된 비주얼 토큰 재사용 (비전 인코더 스킵)
캐시 미스? -> 전처리 + 비전 인코딩 -> 결과 캐시에 저장
효과: 멀티턴/반복 질의에서 비전 인코딩 비용 절감, TTFT 단축
주의: 캐시 키(해상도/전처리 파라미터 포함), 메모리 한도 관리
전처리 자체도 CPU 병목이 될 수 있습니다. 큰 이미지 디코드/리사이즈를 GPU나 별도 워커로 오프로드하고, 비동기 파이프라인으로 GPU 유휴를 줄이는 것이 좋습니다.
비전 인코더와 LLM의 파이프라이닝
비전 인코더와 LLM은 서로 다른 연산 특성을 가집니다. 둘을 직렬로 실행하면 한쪽이 도는 동안 다른 쪽이 놉니다. 파이프라이닝으로 겹치면 처리량이 올라갑니다.
직렬 vs 파이프라인(개념)
[직렬]
[비전 인코딩 A][LLM prefill A][비전 인코딩 B][LLM prefill B]...
-> 단계 간 유휴 발생
[파이프라인]
비전 인코딩: [A][B][C]...
LLM prefill: [A][B][C]... (A 인코딩 끝나면 곧장 prefill 시작)
-> 두 스테이지 중첩으로 GPU 활용률 상승
실무에서는 비전 인코더를 별도 스테이지(혹은 별도 GPU/서버)로 분리해 미리 비주얼 토큰을 만들어 두고, LLM 엔진은 토큰을 받아 prefill/decode에 집중하게 하는 분리 구조가 자주 쓰입니다. 이는 뒤에서 다룰 지연 분해와도 연결됩니다.
멀티모달 KV 캐시와 배칭의 난점
KV 캐시 압박
KV 캐시는 시퀀스의 모든 토큰에 대해 key/value를 저장합니다. 비주얼 토큰이 수천 개면 KV 캐시도 그만큼 커집니다. paged KV cache가 단편화는 줄여주지만, 절대 메모리 수요 자체가 커지는 건 막지 못합니다.
멀티모달 KV 캐시 압박(개념)
KV 캐시 메모리 ~ (총 토큰 수) x (레이어) x (헤드 x 차원) x 2(K,V)
비주얼 토큰 3000개가 더해지면 ->
해당 요청의 KV 캐시가 텍스트 대비 수~수십 배
-> 동시 처리 가능한 요청 수(배치) 감소
배칭의 불균형
continuous batching은 토큰 단위로 요청을 채워 처리량을 높입니다. 그러나 멀티모달에서는 시퀀스 길이 변동이 커서, 프리필이 긴 요청 하나가 배치 전체의 진행을 늦출 수 있습니다. 또 프리필(비주얼 토큰 다수)과 디코드(토큰 1개씩)는 연산 성격이 달라 한 배치에 섞기 까다롭습니다.
대응으로 chunked prefill(긴 프리필을 잘게 쪼개 디코드와 번갈아 실행)과 prefill/decode 분리(disaggregation, 프리필 전용·디코드 전용 인스턴스 분리)가 효과적입니다. 멀티모달은 프리필이 무겁기 때문에 이 분리의 이득이 텍스트 전용보다 큽니다.
chunked prefill + 분리(개념)
긴 비주얼 프리필을 청크로 분할:
prefill_chunk_1 -> decode 몇 스텝 -> prefill_chunk_2 -> ...
-> 긴 프리필이 디코드 요청을 굶기지 않음
prefill/decode 분리:
[Prefill 인스턴스] 비전 인코딩 + 프리필 담당
[Decode 인스턴스] KV 받아 토큰 생성 담당
-> 각 단계 특성에 맞춘 최적화 가능
지연 분해: TTFT에 인코딩이 포함된다
멀티모달 서빙의 지연은 텍스트 전용과 분해 구조가 다릅니다. 핵심은 TTFT(첫 토큰까지 시간) 안에 비전 인코딩이 들어간다는 점입니다.
지연 분해(개념)
[텍스트 전용]
TTFT = 토크나이즈 + prefill
TPOT = 토큰당 디코드 시간
[멀티모달]
TTFT = 이미지 전처리 + 비전 인코딩 + (비주얼+텍스트) prefill
TPOT = 토큰당 디코드 시간 (텍스트 전용과 유사)
함의: 멀티모달은 TTFT가 크게 늘어나기 쉽다.
TTFT 최적화 = 전처리/인코딩/프리필을 모두 줄여야.
따라서 TTFT를 줄이려면 (1) 이미지 전처리 가속/오프로드, (2) 비전 인코딩 캐싱·배칭, (3) 토큰 압축으로 프리필 길이 단축, (4) chunked prefill로 체감 지연 분산을 함께 써야 합니다. 반면 TPOT(토큰당 시간)는 디코드가 메모리 바운드라는 점에서 텍스트 전용과 비슷하게 양자화·KV 최적화·speculative decoding이 듣습니다.
처리량 최적화
처리량을 끌어올리는 레버는 텍스트 전용과 상당 부분 공유하되, 멀티모달 특성을 더합니다.
- **비주얼 토큰 줄이기**: 동적 해상도 상한과 토큰 압축으로 프리필을 줄이면 처리량이 직접 오릅니다. 토큰을 줄이는 게 가장 큰 레버입니다.
- **비전 인코딩 배칭**: 여러 이미지를 모아 비전 인코더를 배치 실행하면 GPU 활용률이 오릅니다.
- **prefill/decode 분리 + chunked prefill**: 무거운 프리필이 디코드를 막지 않게 합니다.
- **양자화**: FP8/INT4로 메모리·대역폭을 줄여 디코드 처리량과 배치 크기를 키웁니다.
- **speculative decoding**: 드래프트 모델로 후보를 만들고 본 모델이 검증, 메모리 바운드 디코드에서 약 2~3배 가속.
- **프레임워크 선택**: vLLM은 범용·넓은 모델/하드웨어 지원과 멀티모달 지원이 강점, TensorRT-LLM은 컴파일 기반으로 H100에서 약 15~30% 더 높은 처리량, SGLang은 RadixAttention으로 prefix 캐시 재사용에 강합니다.
처리량 레버 우선순위(개념)
1) 토큰 수 감소(동적 해상도, 압축) <- 가장 직접적
2) 비전 인코딩 캐싱/배칭
3) prefill/decode 분리 + chunked prefill
4) 양자화(FP8/INT4)
5) speculative decoding
비용
비용은 토큰 수와 GPU 시간에 직결됩니다. 멀티모달은 비주얼 토큰 때문에 같은 "한 요청"이라도 텍스트 대비 비싸집니다.
비용 동인(개념)
요청 비용 ~ (비전 인코딩 GPU 시간) + (prefill FLOPs) + (decode 시간 x 출력 길이)
비주얼 토큰 N_v 증가 -> prefill FLOPs와 KV 메모리 증가 ->
배치 크기 감소 -> 요청당 분담 비용 상승
절감 레버: 해상도 정책, 토큰 압축, 인코딩 캐싱, 양자화로 배치 키우기
따라서 비용 관리의 핵심은 "필요 이상으로 큰 이미지를 넣지 않기"와 "재사용 가능한 비전 인코딩을 캐싱하기"입니다. 정확도 손실 없이 토큰을 줄이는 모든 수단이 곧 비용 절감입니다.
오토스케일링과 부하 특성
멀티모달 서빙의 부하는 텍스트 전용보다 예측이 어렵습니다. 같은 초당 요청 수(RPS)라도 요청에 포함된 이미지의 크기·수에 따라 GPU 부하가 천차만별이기 때문입니다. 단순히 RPS로 오토스케일링을 걸면 과소/과대 프로비저닝이 생기기 쉽습니다.
부하 지표 선택(개념)
[부적절] RPS만으로 스케일
-> 같은 RPS라도 비주얼 토큰 양에 따라 부하가 크게 다름
[적절] 비주얼 토큰 처리량(tokens/s) 또는 GPU 활용률 기반
-> 실제 연산 부하를 더 잘 반영
추가: 큐 대기시간, TTFT p95를 SLO로 두고 그에 맞춰 스케일
또 비전 인코더와 디코드의 부하가 분리되어 있으므로, prefill/decode를 분리한 구조에서는 각 풀을 독립적으로 스케일하는 것이 효율적입니다. 이미지가 많은 트래픽 패턴에서는 prefill 풀을, 긴 응답이 많은 패턴에서는 decode 풀을 더 키웁니다.
모니터링: 무엇을 봐야 하는가
멀티모달 서빙은 텍스트 전용보다 관측해야 할 지표가 많습니다. 단계가 늘었고 변동성이 크기 때문입니다.
핵심 모니터링 지표(개념)
지연 계열:
- TTFT (전처리 + 인코딩 + 프리필 포함) p50/p95/p99
- TPOT (토큰당 디코드 시간)
- 단계별 분해: 전처리 / 비전 인코딩 / 프리필 / 디코드
처리량 계열:
- 요청/s, 출력 토큰/s, 비주얼 토큰/s
자원 계열:
- GPU 활용률(비전 인코더 vs LLM 분리 시 각각)
- KV 캐시 점유율, OOM 발생 횟수
- 캐시 히트율(비전 인코딩 캐시)
품질/비용 계열:
- 평균 비주얼 토큰 수, 요청당 비용
특히 TTFT를 단계별로 분해해 보는 것이 중요합니다. TTFT가 높을 때 원인이 전처리인지, 비전 인코딩인지, 프리필인지에 따라 처방이 완전히 다르기 때문입니다.
동시 멀티이미지와 긴 컨텍스트
한 요청에 이미지가 여러 장 들어오거나, 멀티턴 대화에서 이미지가 누적되면 컨텍스트가 빠르게 길어집니다. 이는 두 가지 압박을 동시에 만듭니다. 프리필 연산 증가와 KV 캐시 메모리 증가입니다.
멀티이미지/긴 컨텍스트 압박(개념)
요청에 이미지 4장(각 ~1000 토큰) + 텍스트
-> 비주얼 토큰 ~4000, 프리필 길어짐
멀티턴: 턴마다 이미지·응답 누적
-> KV 캐시가 대화 길이에 비례해 증가
-> 긴 대화에서 동시 처리 가능 세션 수 감소
대응:
- 이미지 수 상한, 오래된 이미지 토큰 요약/드롭
- 비전 인코딩 캐싱으로 재인코딩 회피
- prefix 캐시 재사용(동일 접두 컨텍스트)
멀티턴에서 같은 이미지가 반복 등장하면 prefix 캐시 재사용이 큰 이득을 줍니다. SGLang의 RadixAttention처럼 공통 접두를 공유하는 기법은 멀티모달 멀티턴에서 특히 효과적입니다.
안정성과 폴백
멀티모달 파이프라인은 단계가 많은 만큼 실패 지점도 많습니다. 손상된 이미지, 지원하지 않는 포맷, 과도하게 큰 입력 등이 들어올 수 있습니다. 견고한 서빙은 이런 입력을 우아하게 처리해야 합니다.
입력 검증과 폴백(개념)
입력 수신 ->
포맷/크기 검증 (지원 포맷? 최대 크기 이내?)
실패 -> 명확한 오류 반환 (파이프라인 진입 전 차단)
손상 이미지 디코드 실패
-> 해당 이미지 스킵 또는 오류 반환
과대 해상도
-> 상한으로 다운스케일 후 진행
원칙: 잘못된 입력이 GPU 단계까지 가서 자원을 낭비하지 않게
앞단에서 빠르게 검증/차단
GPU는 비싼 자원이므로, 잘못된 입력을 전처리 이전 단계에서 빠르게 걸러내는 것이 비용과 안정성 양면에서 유리합니다.
배포 토폴로지
멀티모달 서빙을 어떻게 배치하느냐는 처리량과 비용에 직접 영향을 줍니다. 크게 세 가지 토폴로지가 있습니다.
배포 토폴로지(개념)
[단일 통합]
하나의 엔진이 전처리+비전 인코딩+prefill+decode 모두 담당
장점: 단순, 운영 쉬움
단점: 단계별 독립 스케일 불가, 자원 불균형
[비전 인코더 분리]
비전 인코딩 서비스 | LLM 엔진(prefill+decode)
장점: 비전/LLM 독립 스케일, 비전 결과 캐싱 용이
단점: 토큰 전송 오버헤드, 운영 복잡도 증가
[완전 분리(prefill/decode 분해)]
비전 인코딩 | prefill 인스턴스 | decode 인스턴스
장점: 각 단계 최적 자원/스케일, 최고 효율
단점: 가장 복잡, KV 전송 등 통신 설계 필요
규모가 작으면 단일 통합으로 시작하고, 트래픽이 커지고 이미지 비중이 높아지면 비전 인코더 분리, 더 나아가 완전 분리로 진화하는 경로가 일반적입니다. 분리할수록 효율은 오르지만 운영 복잡도도 함께 오르므로, 규모에 맞춰 단계적으로 도입하는 것이 좋습니다.
프레임워크의 멀티모달 지원
주요 추론 프레임워크가 멀티모달을 어떻게 지원하는지 큰 그림을 정리합니다. 세부는 버전에 따라 변하므로 일반적 경향으로 이해하면 됩니다.
프레임워크별 특성(개념)
vLLM:
- 넓은 모델/하드웨어 지원, 멀티모달 입력 지원 성숙
- paged KV cache, continuous batching, chunked prefill
- 범용 서빙의 무난한 기본 선택
TensorRT-LLM:
- 컴파일 기반 최적화, H100에서 높은 처리량
- 멀티모달은 비전 인코더 통합 파이프라인 구성 필요
- 최고 성능 추구 시, 빌드/운영 비용 감수
SGLang:
- RadixAttention로 prefix 캐시 재사용에 강함
- 멀티턴/공통 접두 컨텍스트에서 이득 큼
- 멀티모달 멀티턴 워크로드에 적합
선택 기준은 워크로드 성격입니다. 다양한 모델을 빠르게 올려야 하면 vLLM, 단일 모델의 최대 처리량이 중요하면 TensorRT-LLM, 멀티턴 대화가 핵심이면 SGLang이 출발점이 됩니다. 실제로는 벤치마크를 통해 자신의 트래픽에서 검증하는 것이 정답입니다.
워크드 예시: 지연 분해 따라가기
추상적 논의를 구체화하기 위해, 한 멀티모달 요청의 지연을 단계별로 따라가 봅시다. 수치는 설명을 위한 가상의 상대값이며, 실제는 모델·하드웨어·설정에 따라 크게 다릅니다.
멀티모달 요청 지연 분해(개념, 가상 상대값)
요청: 고해상도 이미지 1장(비주얼 토큰 ~2000) + 텍스트 50토큰
출력: 200토큰 생성
단계별 기여:
이미지 전처리 : 작음
비전 인코딩 : 중간 (이미지 클수록 증가)
prefill(2050토큰) : 큼 (어텐션 O(L^2) 항)
----- 여기까지가 TTFT -----
decode(200토큰) : 토큰당 시간 x 200
관찰:
- TTFT가 전체 지연의 큰 부분 (인코딩 + 긴 prefill)
- decode는 텍스트 전용과 유사한 양상
이 분해가 주는 교훈은 명확합니다. 멀티모달에서 사용자가 체감하는 첫 응답 지연(TTFT)을 줄이려면, 텍스트 전용에서 주로 신경 쓰던 decode 최적화만으로는 부족합니다. 비전 인코딩과 prefill을 줄이는 것이 핵심입니다.
TTFT 단축 레버 적용 효과(개념)
기준: 인코딩 + 긴 prefill로 TTFT 큼
레버 1) 토큰 압축으로 비주얼 토큰 2000 -> 600
-> prefill 대폭 감소 -> TTFT 큰 폭 단축
레버 2) 비전 인코딩 캐시 히트
-> 인코딩 단계 거의 0 -> TTFT 추가 단축
레버 3) chunked prefill
-> 긴 prefill이 다른 요청을 막지 않음 -> 전체 p95 개선
세 레버를 함께 쓰면 TTFT와 처리량이 동시에 개선됩니다. 핵심은 "비주얼 토큰을 줄이고, 재사용 가능한 인코딩을 캐싱하고, 무거운 prefill을 분산시키는" 세 방향을 항상 같이 보는 것입니다.
비교: 텍스트 전용 vs 멀티모달 서빙
| 항목 | 텍스트 전용 | 멀티모달 |
| --- | --- | --- |
| 입력 전처리 | 토크나이즈(가벼움) | 이미지 전처리 + 비전 인코딩(무거움) |
| 프리필 비용 | 보통 가벼움 | 비주얼 토큰으로 급증 |
| 토큰 수 변동 | 중간 | 매우 큼(해상도 의존) |
| KV 캐시 | 텍스트 길이 비례 | 비주얼 포함해 훨씬 큼 |
| TTFT 구성 | 토크나이즈 + 프리필 | 전처리 + 인코딩 + 프리필 |
| 핵심 최적화 | 배칭, KV, 양자화 | 위 + 토큰 압축, 인코딩 캐싱, 분리 |
운영 함정과 체크리스트
함정:
- **해상도 무제한 입력**: 고해상도 이미지가 토큰을 폭증시켜 TTFT와 비용을 급등시킵니다. 동적 해상도 상한이 필수입니다.
- **비전 인코더 병목 간과**: LLM만 최적화하고 비전 인코더/전처리를 방치하면 그쪽이 병목이 됩니다.
- **배치 불균형**: 길이 편차가 큰 요청을 섞으면 긴 프리필이 짧은 요청을 굶깁니다. chunked prefill/분리로 완화하세요.
- **KV 메모리 초과(OOM)**: 비주얼 토큰을 간과한 메모리 계획은 OOM을 부릅니다. 최대 비주얼 토큰을 기준으로 예산을 잡으세요.
- **캐시 키 오류**: 전처리 파라미터(해상도/정규화)를 캐시 키에 빠뜨리면 잘못된 비주얼 토큰을 재사용합니다.
- **전처리 CPU 병목**: 이미지 디코드/리사이즈가 CPU에서 직렬화되면 GPU가 굶습니다. 오프로드/비동기화하세요.
체크리스트:
멀티모달 서빙 점검 항목
[ ] 동적 해상도 상한과 토큰 압축 정책이 있는가
[ ] 비전 인코딩 결과 캐싱(키에 전처리 파라미터 포함)이 있는가
[ ] 비전 인코더와 LLM을 파이프라인/분리했는가
[ ] chunked prefill 또는 prefill/decode 분리를 적용했는가
[ ] 최대 비주얼 토큰 기준으로 KV 메모리 예산을 잡았는가
[ ] TTFT/TPOT/처리량을 따로 모니터링하는가
[ ] 전처리 CPU 병목을 오프로드/비동기화했는가
[ ] FP8/INT4 양자화로 배치 크기를 확보했는가
마치며
멀티모달 LLM 서빙은 텍스트 전용 서빙의 연장선이지만, 이미지 입력이 만들어 내는 차이가 본질적입니다. 비전 인코더라는 추가 단계, 요청마다 들쭉날쭉한 비주얼 토큰, 그리고 무거워진 프리필이 TTFT와 메모리·비용 구조를 바꿉니다.
대응의 큰 줄기는 명확합니다. 토큰을 줄이고(동적 해상도·압축), 인코딩을 캐싱·배칭·파이프라인하며, 프리필을 분리·청크화하고, 디코드는 양자화·KV 최적화·speculative decoding으로 가속하는 것입니다. vLLM 같은 프레임워크의 멀티모달 지원이 성숙하면서 이 패턴들을 비교적 쉽게 적용할 수 있게 됐습니다. 결국 핵심 질문은 하나로 수렴합니다. "정확도를 지키면서 비주얼 토큰과 프리필 비용을 얼마나 줄일 수 있는가."
참고 자료
- [vLLM 문서](https://docs.vllm.ai/)
- [vLLM GitHub](https://github.com/vllm-project/vllm)
- [SGLang GitHub](https://github.com/sgl-project/sglang)
- [TensorRT-LLM GitHub](https://github.com/NVIDIA/TensorRT-LLM)
- [Qwen2-VL (arXiv 2409.12191)](https://arxiv.org/abs/2409.12191)
- [FlashAttention (arXiv 2205.14135)](https://arxiv.org/abs/2205.14135)
- [Attention Is All You Need (arXiv 1706.03762)](https://arxiv.org/abs/1706.03762)
- [QwenLM GitHub](https://github.com/QwenLM)
- [Hugging Face 문서](https://huggingface.co/docs)
현재 단락 (1/229)
텍스트 LLM 서빙은 지난 몇 년간 상당히 표준화됐습니다. continuous(in-flight) batching으로 요청을 끊임없이 채우고, paged KV cache로 메모리를...