GPU 메모리가 먼저 꽉 찬다. 그다음 벌어지는 일은 단순한 속도 저하만이 아니다. 어떤 모델은 버티고, 어떤 모델은 디코드 처리량이 급격히 떨어진다. 멀티모델 LLM 서빙이 어려운 이유가 여기에 있다. 한 대의 공유 하드웨어 위에서 모델 둘, 셋을 함께 돌리는 순간 문제는 “누가 더 빠른가”가 아니라 “누구를 언제 GPU에 남기고, 누구를 밀어내며, 그 비용을 누가 감당하나”로 바뀐다.

이번에 공개된 arXiv:2605.19593는 이 지점을 다룬다. 제목은 ‘Towards Multi-Model LLM Schedulers: Empirical Insights into Offloading and Preemption’이다. 핵심은 분명하다. GPU 메모리 제약 아래에서는 CPU-GPU 오프로딩과 선점을 피하기 어렵고, 그 대가가 모델마다 다르게 나타난다. 이는 서빙 엔진의 미세 조정 문제만이 아니다. 멀티모델 제품 전략과 인프라 비용 구조까지 건드리는 운영 문제다.

세 줄 요약

• 이 글의 핵심 이슈는 멀티모델 LLM 서빙에서 오프로딩과 선점이 성능에 미치는 영향이 모델별로 비선형적으로, 또 서로 다르게 나타난다는 점이다.
• 이게 중요한 이유는 단일 모델 기준의 처리량 최적화가 공유·이기종 환경에서는 꼬리 지연시간, GPU 활용도, 서비스 격리를 함께 해칠 수 있기 때문이다.
• 독자는 모델별 GPU 상주 비율 민감도, 선점 후 재로딩 비용, 전송 병목을 따로 계측해야 한다. 이를 하나의 전역 스케줄링 규칙으로 묶지 말아야 한다.

현황

논문 초록이 제시하는 문제 설정은 현실적이다. 배포 환경은 하나의 LLM만 서빙하지 않는다. 아키텍처, 크기, 전문화 수준이 다른 모델을 공유된 이기종 하드웨어에서 함께 운영한다. 이때 자원 배분, 디스패치, 스케줄링이 새 문제로 떠오른다. GPU 메모리가 부족하면 부분 오프로딩과 선점이 필요해진다.

선점 비용도 작지 않다. 같은 조사에서는 선점 오버헤드가 KV 캐시 이동보다 모델 상태 재적재에 더 크게 좌우된다고 정리한다. 즉, 스케줄러가 “잠깐 비켰다가 다시 올리면 된다”고 가정하면 실제 비용을 낮게 볼 수 있다. 특히 꼬리 지연시간은 이런 재적재 비용의 영향을 크게 받는다.

오프로딩 병목이 어디서 생기는지도 다른 연구가 보강한다. arXiv:2601.19910은 KV 오프로딩 요청을 처리할 때 지연시간의 99%가 전송에 쓰였다고 적었다. 같은 스니펫은 오프로딩된 요청을 서빙할 때 GPU가 정격 TDP의 28%만 사용했다고 덧붙인다. 계산이 느린 것이 아니라, 데이터 이동 경로가 막혀 GPU가 쉬고 있다는 해석이 가능하다.

이 결과를 함께 보면 그림이 더 선명해진다. 멀티모델 스케줄링은 “연산 자원 분배”만의 문제가 아니다. PCIe 같은 인터커넥트 대역폭, CPU 메모리와 GPU 메모리 사이의 왕복 비용, 시퀀스 길이에 따른 KV 캐시 이동량이 함께 얽힌다. 같은 GPU를 써도 어떤 모델은 상주시키는 편이 낫고, 어떤 모델은 오프로딩해도 손해가 덜할 수 있다.

분석

의사결정 관점에서 중요한 질문은 하나다. 공평한 스케줄링이 좋은가, 아니면 비용이 큰 모델을 우선 보호하는 차등 스케줄링이 좋은가. 조사 결과만 놓고 보면, 멀티모델 혼합 워크로드에서 지연시간과 처리량을 함께 안정적으로 잡는 단일 보편 정책은 아직 확인되지 않았다. 대신 방향은 비교적 분명하다. 모델별 오프로딩 민감도, 선점 후 재로딩 비용, 시퀀스 길이, 인터커넥트 대역폭을 함께 보는 정책이 필요하다. 단일 모델 시대의 “처리량 최대화” 규칙을 그대로 가져오면 맞지 않을 가능성이 크다.

기존 연구와의 거리도 냉정하게 볼 필요가 있다. FastServe의 skip-join MLFQ 기반 선점이나 Sarathi-Serve의 stall-free 스케줄링은 지연시간과 처리량의 균형을 개선했다는 근거를 제시했다. 다만 조사 결과는 이것이 멀티모델·공유·이기종·오프로딩 환경에서의 직접적인 head-to-head 우위로 검증된 것은 아니라고 짚는다. 다시 말해 “단일 시스템에서 잘된 기법”과 “멀티모델 운영에서 맞는 정책” 사이에는 아직 공백이 있다. 실제 데이터센터로의 일반화도 조심해야 한다. 최근 연구들이 이기종 GPU 자원과 CPU-GPU 결합 아키텍처를 다루기 시작했지만, 네트워크 토폴로지와 스토리지 계층, 운영 정책까지 포함한 외적 타당성은 제한적이다.

실전 적용

인프라 팀이 지금 바꿔야 할 사고방식은 단순하다. 모델을 하나의 평균값으로 보면 안 된다. 같은 GPU 메모리 압박을 받아도 어떤 모델은 급격히 느려지고, 어떤 모델은 상대적으로 완만하게 버틴다. 따라서 스케줄러의 기본 단위는 “요청”만이 아니라 “요청이 속한 모델의 민감도 프로필”이어야 한다. 여기에 선점 시 재적재 비용과 전송 병목까지 함께 봐야 한다.

예: 고객지원용 소형 모델과 분석용 대형 모델을 같은 클러스터에서 함께 서빙한다고 하자. 직관대로 소형 모델을 더 자주 밀어내면 전체 효율이 좋아 보일 수 있다. 하지만 작은 모델이 GPU 상주 축소에 더 민감하다면 응답성이 먼저 깨질 수 있다. 반대로 대형 모델은 선점 후 상태 재적재가 더 비싸다면, 짧은 요청을 위해 자주 끊는 전략이 전체 p99를 더 나쁘게 만들 수 있다. 이때 필요한 것은 평균 처리량 그래프보다 모델별 오프로딩 민감도 표다.

오늘 바로 할 일 체크리스트:

• 모델별로 GPU 상주 비율을 단계적으로 낮추며 디코드 처리량 변화를 측정해 민감도 곡선을 따로 만든다.
• 선점 이벤트마다 KV 이동 시간과 모델 상태 재적재 시간을 분리 계측해 무엇이 병목인지 확인한다.
• 전역 FIFO나 단순 우선순위 규칙을 그대로 쓰지 말고, 시퀀스 길이와 인터커넥트 혼잡도를 반영한 예외 규칙을 먼저 붙인다.

FAQ

Q. 멀티모델 혼합 워크로드에서 가장 좋은 스케줄링 정책은 이미 정해졌나?

아닙니다. 조사 결과 기준으로는 지연시간과 처리량을 함께 안정적으로 잡는 단일 보편 정책이 확인되지 않았습니다. 현재는 모델별 오프로딩 민감도, 선점 비용, 시퀀스 길이, 대역폭을 함께 고려하는 접근이 더 설득력 있습니다.

Q. 부분 오프로딩이 모델 응답 품질 자체를 떨어뜨리나?

검색 결과 기준으로는 그런 직접 근거가 확인되지 않았습니다. 확인된 것은 응답 품질 변화보다 디코드 처리 성능 저하입니다. 특히 성능 저하가 비선형적이고 모델마다 다르다는 점이 핵심입니다.

Q. 이 연구 결과를 상용 데이터센터에 바로 일반화해도 되나?

신중해야 합니다. 연구들은 이기종 하드웨어, GPU 메모리 제약, CPU-GPU 오프로딩 같은 현실 문제를 다루기 시작했지만, 모든 데이터센터의 네트워크와 스토리지, 운영 정책까지 포괄해 검증된 것은 아닙니다. 따라서 자체 워크로드에서 재현 측정이 먼저입니다.

결론

멀티모델 LLM 스케줄링의 핵심은 “누구를 얼마나 빨리 돌리나”보다 “누구를 GPU에 남길 때 손해가 더 적나”에 가깝다. 지금 필요한 것은 보편 해답을 찾는 일이 아니다. 모델별 민감도와 선점 비용을 계측하고, 그 결과에 따라 스케줄링 규칙을 분기하는 일이다.

다음으로 읽기

• AI 자료 모음 (24h) - 2026-05-20
• COBALT, 로봇 데이터 병목 해법
• 손글씨 수학 채점의 한계
• 다중 이미지 탈옥의 허점
• 주장 검증의 삼진 분류

참고 자료

• Characterizing and Optimizing LLM Inference Workloads on CPU-GPU Coupled Architectures - huggingface.co
• arxiv.org - arxiv.org
• Understanding Bottlenecks for Efficiently Serving LLM Inference With KV Offloading - arxiv.org
• APEX: Asynchronous Parallel CPU-GPU Execution for Online LLM Inference on Constrained GPUs - arxiv.org
• Demystifying Cost-Efficiency in LLM Serving over Heterogeneous GPUs - arxiv.org