LLM 서비스 및 최적화 실습하기 (Korean Edition)

제6장. 필수 LLM 최적화 기법

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이전 장들에서 우리는 서비스 제공을 위한 LLMs 최적화의 중요성과 과제를 살펴보았습니다. 다음 두 장에서는 서비스 제공 요구 사항에 따라 이러한 기법을 언제, 어떻게, 왜 사용해야 할지 판단할 수 있는 지식을 갖추실 수 있도록, 핵심 LLM 최적화 기법들을 하나씩 심도 있게 다룰 것입니다.

특히 이 장에서는 대부분의 최적화 개념을 이해하고 많은 최적화 목표를 달성하는 데 도움이 될 핵심 기법들에 초점을 맞출 것입니다. 보다 고급 기법과 업계 동향에 대해서는 7장에서 다루도록 하겠습니다.

이 장에서는 다음을 활용하는 방법에 대해 논의할 것입니다:

• 더 나은 병렬 처리 및 GPU 활용도를 달성하기 위한 요청 배치 및 스케줄링

• 더 나은 연산 효율, 필요한 연산량 감소, 그리고 더 나은 메모리 관리를 위한 어텐션 최적화

• 모델 압축을 통해 모델 크기 축소, 메모리 이동 감소 및/또는 연산량 절감

• 이전 prompts를 캐싱하고 재사용하기 위한 접두사 캐싱(Prefix caching), 여기에는 효율적인 구현 방법과 높은 캐시 적중률 확보 방법이 포함됩니다

요청 배치 및 스케줄링 수준 최적화

2장에서는 모델 서빙 을 오프라인 서빙과 실시간 온라인 서빙으로 구분했습니다. 실시간 온라인 서빙에서는 사용자가 요청을 보내면 즉시 수신하는 반면, 오프라인 서빙에서는 요청을 미리 확보해 두었다가 하나씩 전송하는 대신 모두 묶어 하나의 큰 텐서 입력으로 만들어 모델에 공급할 수 있습니다.

서빙 과정에서 요청을 묶어 처리하면 응답 속도는 느려질 수 있지만, 더 높은 처리량을 달성할 수 있습니다. 제5장에서 배운 개념인 '산술 강도( arithmetic intensity)'를 활용하여 그 이유를 좀 더 깊이 있게 살펴보겠습니다.

실시간 서빙에서 배칭이 필요한 이유는 무엇일까요?

제2장에서 처음 설명했듯이, LLM 서빙( )은 프리필(prefill)과 디코딩(decode)이라는 두 단계로 이루어집니다. 프리필 단계는 모델이 입력 프롬프트를 이해하는 단계입니다. 제5장에서 분석한 바와 같이, 입력 프롬프트의 토큰은 병렬로 처리될 수 있으며 높은 산술 집약도를 달성하므로, 이는 연산 집약적인 워크로드로 이어집니다. 디코딩 단계는 LLM이 한 번에 하나의 토큰을 생성하는 단계입니다. 이 단계는 자기회귀적 특성을 지니기 때문에 메모리 대역폭에 의존적입니다. 즉, 모델은 기본적으로 수십억 개에 달하는 모든 매개변수를 훑어보며 한 번에 단 하나의 토큰만 생성해야 하므로, GPU 메모리 대역폭(FLOPS로 측정) 측면에서 매우 비효율적입니다(그림 6-1).

그림 6-1. 프리필 단계에서는 입력 prompt의 ...