현대 분산 ML 이해: HPC 스케줄러에서 LLM 서빙 엔진까지
오늘날 머신러닝 엔지니어는 모델을 대규모로 학습하고 배포하기 위해 다양한 도구와 개념을 다룹니다. 이 글에서는 다음과 같은 주요 주제를 자세히 다룹니다. **딥러닝 컨테이너(DLC)**로 작업 실행, 볼케이노(VOLC) 및 SLURM과 같은 HPC 배치 스케줄러 사용, vLLM 및 SGLang을 사용한 효율적인 LLM 서빙, 일반적인 학습 프레임워크 및 매개변수, 운영 모드(학습 대 추론), 병렬 처리 전략(DPTPPP – 데이터, 파이프라인, 텐서 병렬 처리), 분산 시스템에서 라우터 및 컨트롤러의 역할, 높은 처리량을 위한 데이터 로딩 전략. 각 개념을 설명하고, 예제(코드 및 구성 샘플 포함)를 제공하고, 기술적이고 정확한 방식으로 실용적인 통찰력을 제공합니다. 자세히 알아봅시다.
딥러닝 컨테이너(DLC) 및 ML 작업 실행
**딥러닝 컨테이너(DLC)**는 인기 있는 딥러닝 프레임워크와 종속성이 최적화되어 바로 실행할 수 있도록 미리 빌드된 Docker 컨테이너 이미지를 말합니다. 예를 들어, AWS는 TensorFlow, PyTorch, MXNet 등에 대한 DLC를 제공하며, 여기에는 최적화된 빌드(종종 GPU 지원, CUDA/cuDNN과 같은 라이브러리 설치, 다중 노드 학습을 위한 EFA와 같은 네트워크 최적화 포함)가 포함됩니다. 이러한 컨테이너는 연구자가 각 머신에 프레임워크를 수동으로 설치할 필요가 없도록 일관된 환경을 보장합니다. AWS에 따르면 DLC는 Amazon ECR(Elastic Container Registry)에서 Docker 이미지로 사용할 수 있으며 각 이미지는 특정 프레임워크 버전 및 작업(학습 또는 추론)에 맞게 조정됩니다(Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog). 즉, 원하는 프레임워크(예: CUDA 11이 있는 PyTorch 2.0)와 일치하는 컨테이너를 선택하고 필요한 모든 라이브러리가 있는지 확인할 수 있습니다.
작동 방식: 실제로 DLC를 사용하려면 컨테이너 이미지를 가져와서 그 안에서 학습 또는 추론을 실행해야 합니다. 이는 Docker가 설치된 클라우드 VM 또는 온프레미스 서버에서 수행할 수 있습니다. 예를 들어, EC2 GPU 인스턴스를 시작한 후 다음과 같이 할 수 있습니다.
# 1단계: 필요한 경우 AWS ECR public에 로그인하고 DLC 이미지를 가져옵니다.
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin <aws_account>.dkr.ecr.us-west-2.amazonaws.com
docker pull <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2
# 2단계: 학습 스크립트로 컨테이너를 실행합니다.
docker run --gpus all -v /data:/data -it <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2 \
python /data/train.py --epochs 5 --batch-size 32
위의 예에서는 AWS PyTorch 2.0 학습 DLC를 가져온 다음 그 안에서 학습 스크립트(train.py)를 실행했습니다. --gpus all 플래그는 컨테이너에 호스트의 NVIDIA GPU에 대한 액세스 권한을 부여하고, -v /data:/data는 호스트 데이터 디렉터리를 컨테이너에 마운트합니다. 이 접근 방식은 컨테이너 내부의 환경에 올바른 버전의 PyTorch, CUDA 등이 있는지 확인하여 작업 실행을 간소화합니다. 또한 이식성이 뛰어나 동일한 컨테이너를 Docker가 설치된 모든 머신에서 실행할 수 있으므로 실험을 재현할 수 있습니다.
DLC를 사용해야 하는 경우: DLC는 클라우드 플랫폼 및 관리형 서비스에서 특히 유용합니다. 예를 들어, Amazon SageMaker 학습 작업은 내부적으로 DLC 이미지를 사용하므로 이미지를 지정하고 학습 코드만 지정하면 플랫폼에서 나머지를 처리합니다. HPC 클러스터에서도 팀은 일관성을 위해 컨테이너화된 환경에서 작업을 실행하기 위해 Singularity 또는 Docker를 사용하는 경우가 있습니다. 요약하면 DLC는 딥러닝 작업에 대한 일관된 런타임을 제공하여 "내 머신에서는 작동한다"는 문제를 간소화합니다. 또한 테스트되고 최적화된 라이브러리가 함께 제공되어 성능 향상을 가져올 수 있습니다(예: AWS는 특정 인스턴스에서 최적화된 PyTorch 2.0 DLC를 사용하여 최대 42%의 속도 향상을 보고했습니다(Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog))).
볼케이노(VOLC) – AI 작업을 위한 Kubernetes 배치 스케줄링
**볼케이노(VOLC)**는 클라우드 네이티브 환경에서 고성능 컴퓨팅(HPC) 및 AI 워크로드를 실행하도록 설계된 Kubernetes 기반의 배치 스케줄링 시스템입니다. Kubernetes의 기본 스케줄러는 마이크로서비스에 적합하지만 딥러닝 작업에 필요한 몇 가지 기능(예: 갱 스케줄링, 큐 관리 및 우선 순위 스케줄링)이 부족합니다. 볼케이노는 Kubernetes 위에 사용자 지정 스케줄러와 작업 관리 CRD(Custom Resource Definitions)를 제공하여 이러한 문제를 해결합니다(Volcano: Collision between containers and batch computing | CNCF). 본질적으로 볼케이노는 Kubernetes가 배치 작업을 위한 HPC 클러스터 스케줄러처럼 작동하도록 합니다.
볼케이노란 무엇입니까: 볼케이노는 컨테이너와 배치 컴퓨팅을 연결하기 위해 도입되었습니다. 사용자가 여러 리소스(예: 2개 노드에서 8개의 GPU가 필요한 작업)를 요구하는 작업을 제출하고 작업이 시작되기 전에 해당 리소스가 함께 할당되도록 하여 TensorFlow, PyTorch, Spark 및 MPI와 같은 프레임워크를 지원합니다(Volcano: Collision between containers and batch computing | CNCF). 이 "갱 스케줄링"은 필요한 모든 포드가 시작될 수 있을 때까지 분산 학습 작업(많은 포드를 생성할 수 있음)이 시작되지 않도록 보장하여 작업의 절반이 실행 중이고 나머지 절반이 대기 중인 상황(리소스 낭비)을 방지합니다. 볼케이노는 또한 공정성 정책, 우선 순위 큐 및 혼합 워크로드를 공동 스케줄링하는 기능을 제공합니다.
작동 방식: 볼케이노는 Kubernetes와 스케줄링 플러그인으로 통합됩니다. 사용자는 일반적으로 작업 및 해당 복제본 수, 리소스 요구 사항 등을 지정하는 볼케이노 작업 YAML을 정의합니다. 예를 들어, YAML은 4개의 복제본이 있는 작업(각 복제본에 1개의 GPU 필요)과 minAvailable: 4(4개의 포드를 배치할 수 있는 경우에만 이 작업 예약)를 선언할 수 있습니다. 제출되면 볼케이노의 스케줄러가 클러스터에서 4개의 포드 모두에 대한 공간을 찾아 동시에 시작합니다. 3개의 GPU만 비어 있는 경우 4번째 GPU가 비워질 때까지 기다립니다(지금 3개를 시작하고 나중에 1개를 시작하는 대신). 이는 동기화를 위해 모든 순위가 동시에 작동해야 하는 Horovod 또는 PyTorch DDP와 같은 분산 학습 프레임워크에 매우 중요합니다.
볼케이노의 아키텍처에는 중앙 컨트롤러와 스케줄링 플러그인이 포함됩니다. 플러그인 메커니즘을 통해 공정 공유, 우선 순위 등과 같은 스케줄링 알고리즘을 고려합니다. 예를 들어, 큐 정책(특정 작업이 다른 작업을 굶어 죽이지 않도록)과 토폴로지 인식 스케줄링(성능을 위해 작업이 노드 또는 랙에 분산되도록)을 적용할 수 있습니다. 사용자 관점에서 볼케이노를 사용하는 것은 Kubernetes를 사용하는 것과 같지만 작업에 대한 다른 API와 ML 작업이 전체적으로 예약된다는 확신이 있습니다. 간단히 말해서 VOLC는 Kubernetes를 HPC 인식 스케줄러로 전환(Volcano: Collision between containers and batch computing | CNCF)하여 컨테이너의 편리함과 배치 작업 오케스트레이션의 강력함을 통합합니다.
사용 사례 예: GPU 노드가 있는 Kubernetes 클러스터가 있고 MPI 기반의 분산 학습 작업을 실행하려는 경우를 가정해 보겠습니다. 볼케이노를 사용하면 (예를 들어) 각각 4개의 GPU가 있는 2개의 포드를 요청하는 MPI 작업(볼케이노는 MPI Operator와 통합됨)을 제출할 수 있습니다. 볼케이노는 두 포드가 두 노드에서 함께 시작하고 각각 4개의 GPU를 갖도록 보장합니다. 또한 포드에 오류가 발생하면 전체 작업을 다시 예약하여 갱 시맨틱을 유지합니다. 이렇게 하면 포드 내부의 MPI mpirun 명령이 두 포드 모두에서 안정적으로 시작될 수 있습니다. 볼케이노가 없으면 기본 스케줄러가 하나의 포드를 시작한 다음 리소스가 확보될 때까지 두 번째 포드를 지연시켜 첫 번째 포드의 MPI 프로세스가 중단되거나 시간 초과될 수 있습니다.
SLURM: 기존 HPC 작업 스케줄링(심층 분석)
SLURM(Simple Linux Utility for Resource Management)은 HPC 클러스터에 널리 사용되는 오픈 소스 작업 스케줄러입니다. 클러스터의 "운영 체제"로 기능하여 작업에 리소스(CPU 코어, GPU, 메모리, 노드)를 할당하고, 리소스를 사용할 수 있을 때까지 작업을 큐에 넣고, 해당 작업을 시작하고 모니터링합니다. Slurm은 확장성이 뛰어나고 많은 최고 슈퍼컴퓨터에서 사용됩니다. 사용 가능한 리소스에 작업을 효율적으로 매칭하는 데 중점을 둔 클러스터 관리 및 작업 스케줄링 도구를 제공합니다(Choosing the Right Orchestration Tool for ML Workloads: Slurm vs. Kubernetes | Nscale).
SLURM 작동 방식: Slurm 클러스터는 큐 및 스케줄링을 관리하는 중앙 컨트롤러(slurmctld)와 각 컴퓨팅 노드에서 작업을 시작하고 감독하기 위해 실행되는 에이전트 데몬(slurmd)으로 구성됩니다. 사용자는 sbatch(배치 작업 스크립트 제출), salloc(대화형 할당 요청) 또는 srun(병렬 작업 시작)과 같은 명령을 통해 Slurm과 상호 작용합니다. Slurm은 특정 제한 또는 하드웨어 특성을 가진 파티션 목록(명명된 큐 또는 노드 그룹으로 생각)을 유지하고 구성된 정책(우선 순위, 공정성, 백필 스케줄링 등)에 따라 해당 파티션의 노드에 작업을 예약합니다.
작업 제출 예: 아래는 리소스를 요청하고 학습 프로그램을 실행하는 예제 Slurm 배치 작업 스크립트(train.sbatch)입니다.
#!/bin/bash
#SBATCH --job-name=train_model # 작업 이름
#SBATCH --nodes=1 # 단일 노드에서 실행
#SBATCH --ntasks=4 # 총 작업(프로세스) = 4
#SBATCH --gres=gpu:4 # 4개의 GPU 요청(하나의 노드에서)
#SBATCH --cpus-per-task=4 # 작업당 4개의 CPU 코어(총 16개의 코어)
#SBATCH --mem=64G # 작업에 대한 64GB의 메모리
#SBATCH --time=02:00:00 # 시간 제한 hh:mm:ss
#SBATCH --partition=ml_gpu # 파티션(큐) 이름
module load anaconda/2023a # 필요한 모든 모듈 로드(예: Anaconda)
source activate myenv # 필요한 경우 가상 환경 활성화
echo "Running on $SLURM_NNODES node(s) with $SLURM_NTASKS tasks..."
srun python train.py --epochs 10 --batch-size 128
이 스크립트에서 #SBATCH 줄은 Slurm에 대한 지시어입니다. 4개의 GPU가 있는 1개의 노드를 요청하고 srun을 통해 python train.py를 실행하도록 작업을 설정합니다. sbatch train.sbatch를 실행하면 Slurm이 작업을 큐에 넣습니다. 4개의 사용 가능한 GPU와 16개의 사용 가능한 CPU 코어가 있는 ml_gpu 파티션의 노드를 사용할 수 있게 되면 Slurm이 해당 노드를 작업에 할당하고 작업을 시작하며 srun이 4개의 작업을 시작합니다(--ntasks=4이므로). MPI 또는 PyTorch 분산을 사용하는 분산 학습 시나리오인 경우 해당 4개의 작업은 4개의 작업자(각각 하나의 GPU 할당)에 해당할 수 있습니다. Slurm은 해당 작업을 할당된 노드에서 실행하고 통신할 수 있도록 적절한 환경 변수를 사용하여 MPI 또는 torch.distributed에 대해 구성된 경우 적절한 환경 변수를 사용하여 시작합니다.
Slurm을 효과적으로 사용: Slurm은 작업 배열(비슷한 작업을 쉽게 제출하기 위해), 종속성 체인(작업 A가 완료된 후 작업 B 시작) 및 리소스 프로파일링과 같은 많은 기능을 제공합니다. ML의 경우 일반적인 패턴은 srun 또는 MPI를 사용하여 N개의 프로세스를 생성하기 위해 --gres=gpu:N을 요청하여 N개의 GPU를 가져오는 것입니다. Slurm은 이러한 모든 프로세스가 할당된 노드에서 실행되고 통신할 수 있도록 보장합니다(종종 SLURM_HOSTNAMES에 호스트 이름을 설정하고 MPI가 해당 호스트 이름을 사용할 수 있음). Slurm은 또한 스케줄링 정책을 허용합니다. 예를 들어 작업이 선점되거나 백필될 수 있습니다. 백필 스케줄링은 HPC에서 활용도를 극대화하는 데 유용합니다. 작은 작업은 큰 작업 사이에 공간이 있으면 큐에서 앞서 나갈 수 있습니다. 엔지니어로서 대규모 학습 작업이 있는 경우 더 긴 walltime을 요청할 수 있습니다. 그러나 작업을 더 짧은 청크로 나누거나 검사점을 지정하고 다시 시작할 수 있다면 백필을 활용하여 더 빨리 조각으로 실행할 수 있습니다.
요약하면 Slurm은 클러스터에서 배치 ML 작업을 실행하는 강력한 도구입니다. Kubernetes 또는 클라우드 서비스보다 하위 수준입니다. 일반적으로 로그인 노드에 SSH로 연결하고 sbatch를 사용하여 제출하지만 세분화된 제어를 제공합니다. 많은 연구자들이 학습 코드를 시작하는 Slurm 스크립트를 작성하여 GPU 리소스의 클러스터 스케줄링의 이점을 활용하여 Slurm 클러스터에서 PyTorch 또는 TensorFlow를 실행합니다.
vLLM: 고처리량 LLM 추론 엔진
대규모 언어 모델(LLM)이 연구에서 프로덕션으로 이동하면서 효율적으로 서빙하는 것이 과제가 되었습니다. vLLM은 빠르고 비용 효율적인 LLM 추론을 위해 설계된 오픈 소스 라이브러리 및 엔진입니다. UC Berkeley의 Sky Computing Lab에서 개발한 vLLM은 모델의 주의 키-값 캐시가 저장되고 액세스되는 방식을 최적화하기 위해 PagedAttention이라는 새로운 메모리 관리 기술을 도입했습니다(vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). 그 결과 기존 구현에 비해 처리량(초당 요청 수)이 훨씬 높아졌습니다. 실제로 vLLM은 GPT 스타일 모델 서빙에서 기준선 Hugging Face Transformers 라이브러리보다 최대 24배 더 높은 처리량을 달성합니다(vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). 모델 아키텍처를 변경할 필요 없이 말입니다.
vLLM 작동 방식: 자동 회귀 생성(LLM이 텍스트 토큰을 토큰별로 생성하는 일반적인 방식)에서는 각 시퀀스에 대해 과거 주의 키와 값의 캐시가 유지 관리됩니다. 이 KV 캐시는 시퀀스 길이에 따라 증가하고 많은 GPU 메모리를 소비할 수 있습니다(예: LLaMA-13B에서 단일 긴 시퀀스의 경우 1.7GB(vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog)). 대부분의 프레임워크는 가능한 최대 길이에 대해 연속 블록을 할당하여 많은 사용되지 않은 공간(단편화)을 만듭니다. vLLM의 PagedAttention은 대신 KV 캐시를 가상 메모리 페이지처럼 처리하여 블록으로 할당하고 비연속 스토리지를 허용합니다(vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). 이렇게 하면 메모리를 유연하게 관리할 수 있습니다. 생성을 완료한 시퀀스는 페이지를 비워 새 시퀀스에 다시 사용할 수 있습니다. 메모리 낭비를 크게 줄이고(일반적인 경우 6080%) vLLM이 다른 시스템보다 더 많은 동시 시퀀스를 처리할 수 있도록 합니다.
또한 vLLM은 연속 배치 처리를 구현합니다. 다른 요청이 생성 중간에 있는 동안에도 새로운 수신 요청을 즉석에서 배치에 추가할 수 있습니다. 기존 시스템은 각 생성 단계에서 처음부터 끝까지 고정된 배치 요청을 처리하는 경우가 많습니다. vLLM의 스케줄러는 대신 가능한 한 요청을 병합하도록 미세 조정되어 GPU를 계속 사용 중입니다. 또한 최적화된 CUDA 그래프를 사용하여 서빙 루프에서 Python 오버헤드를 방지하고, NVIDIA 및 AMD GPU를 모두 지원하며, Hugging Face Transformers와 통합되어 이름으로 모델을 로드하고 서빙할 수 있습니다.
사용 예: vLLM을 사용하는 것은 고급 추론 서버를 사용하는 것과 비슷합니다. 프로그래밍 방식으로 또는 API 서버를 통해 사용할 수 있습니다. 예를 들어 프로그래밍 방식으로 다음과 같습니다.
from vllm import LLM, SamplingParams
# 7B 모델을 로드합니다(가중치를 로컬에서 사용할 수 있거나 HuggingFace Hub를 통해 사용할 수 있다고 가정).
llm = LLM(model="facebook/opt-6.7b", tensor_parallel_size=1) # 텐서 평행 크기는 모델을 GPU에 분할하기 위해 >1일 수 있습니다.
prompts = [
"User: Hello, how are you?\nAssistant:",
"User: What is the capital of France?\nAssistant:"
]
# 특정 디코딩 매개변수로 생성합니다.
outputs = llm.generate(prompts, sampling_params=SamplingParams(top_p=0.95, max_tokens=100))
for out in outputs:
print("Prompt:\n", out.prompt)
print("Completion:\n", out.outputs[0].text)
이 코드는 LLM 인스턴스를 만들고 배치에서 두 개의 프롬프트에 대한 응답을 생성합니다. 내부적으로 vLLM은 PagedAttention을 사용하여 이러한 프롬프트에 대한 KV 캐시를 관리하고 가능한 경우 함께 배치할 수도 있습니다. outputs에는 각 프롬프트에 대한 완성이 포함됩니다. python -m vllm.entrypoints.openai.api_server --model your_model_name과 같은 명령을 사용하여 vLLM을 서버로 시작할 수도 있습니다(OpenAI와 호환되는 REST API 제공). 이렇게 하면 OpenAI API를 예상하는 애플리케이션과 vLLM을 쉽게 통합할 수 있습니다(이 서버를 가리키기만 하면 됨).
중요한 이유: vLLM은 기본적으로 LLM 서빙의 처리량 제한을 높입니다. 고정된 GPU 예산이 있는 경우 초당 더 많은 요청을 서빙하는 것은 요청당 비용이 낮다는 것을 의미합니다. 보고된 24배의 개선은 상대적으로 긴 출력을 사용하여 많은 동시 요청이 생성되는 시나리오에 있습니다(vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). 덜 극단적인 경우에도 vLLM은 종종 단순한 구현보다 몇 배 더 빠른 속도를 제공하고 많은 설정에서 Hugging Face의 TGI 서버보다 약 3배 더 빠른 속도를 제공합니다(vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). 또한 고급 디코딩 알고리즘(예: 빔 검색, 병렬 샘플링)을 효율적으로 지원합니다(vLLM and PagedAttention: A Comprehensive Overview | by Abonia Sojasingarayar | Medium). 엔지니어의 경우 vLLM을 채택하는 것은 vLLM의 API를 사용하도록 추론 코드를 교체하거나 해당 서버를 실행하는 것만큼 간단할 수 있습니다. 그 이점은 더 많은 GPU를 구매하지 않고 더 많은 사용자를 처리하거나 지연 시간을 줄이는 것입니다.
SGLang: 구조화된 생성 언어 및 서빙 프레임워크
vLLM은 단일 단계 프롬프트 완료의 원시 처리량에 중점을 두는 반면 SGLang은 LLM과의 복잡하고 구조화된 상호 작용을 효율적으로 오케스트레이션하는 문제를 해결합니다. SGLang(Structured Generation Language의 약자)은 다단계 LLM 프로그램을 설명하기 위한 **프런트엔드 DSL(Domain-Specific Language)**과 이를 실행하기 위한 고도로 최적화된 백엔드 런타임을 결합한 시스템입니다([[2312.07104] SGLang: Efficient Execution of Structured Language Model Programs) (SGLang: A Deep Dive into Efficient LLM Program Execution - DEV Community). 마치 SGLang이 프롬프팅을 위한 프로그래밍 언어(루프, 조건문, 병렬 호출과 같은 기능 포함)이면서 해당 프로그램이 빠르게 실행되도록 보장하는 서빙 엔진인 것과 같습니다.
SGLang이란 무엇입니까: SGLang의 핵심 아이디어는 많은 실제 애플리케이션에서 LLM에 대한 여러 호출과 구조화된 출력이 필요하다는 것입니다. 예를 들어, AI 에이전트는 단계를 계획하고 각 단계에 대해 LLM을 호출하거나 특정 스키마가 있는 JSON을 LLM이 출력하도록 요구할 수 있습니다. 이를 순진하게 수행하면 속도가 느려질 수 있습니다. 여러 호출은 오버헤드를 발생시키고 LLM은 동일한 프롬프트 부분을 반복적으로 처리하는 등입니다. SGLang의 프런트엔드를 사용하면 여러 생성 호출, 분기 논리 및 외부 도구 통합을 포함할 수 있는 단일 "스크립트"를 작성할 수 있습니다. 그런 다음 SGLang 컴파일러/런타임이 이를 효율적으로 실행합니다. 런타임은 RadixAttention(프롬프트 접두사에서 KV 캐시를 재사용하기 위한 알고리즘으로, vLLM의 페이지 매김과 유사하지만 공유 프롬프트 부분을 지향함) 및 구조화된 출력 문법을 위한 압축된 유한 상태 머신(구조화된 출력을 더 빠르게 처리하기 위해)과 같은 최적화를 도입합니다([[2312.07104] SGLang: Efficient Execution of Structured Language Model Programs). 평범한 용어로 RadixAttention은 많은 요청이 공통 접두사(예: 시스템 또는 퓨샷 프롬프트)를 공유하는 경우 SGLang이 해당 부분을 한 번 계산하고 재사용하여 채팅 봇 또는 검색 증강 생성을 중복 작업을 방지하여 훨씬 빠르게 만든다는 것을 의미합니다(What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium). 구조화된 출력 FSM은 예를 들어 고정 키가 있는 JSON을 예상하는 경우 SGLang이 고정 구두점/키를 토큰별로 생성하는 것을 건너뛰고 해당 부분이 결정적이므로 미리 점프할 수 있음을 의미합니다(What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium). 이를 통해 긴 JSON 또는 XML 출력을 생성하는 데 3배 이상의 속도 향상을 제공합니다(What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium).
작동 방식: SGLang은 Python 기반 DSL과 런타임의 두 부분으로 구성됩니다. DSL을 사용하면 사용자가 다음과 같은 것을 작성할 수 있습니다.
from sglang import sg # 가상 인터페이스
# 유사 코드: 구조화된 생성 흐름 정의
with sg.session(model="Llama-2-13b-chat") as sess:
# 두 개의 순차적 LLM 호출과 구조화된 출력이 있는 간단한 프로그램
user_input = "Translate the following English text to French and give sentiment: I love this product."
sg.prompt(f"User asks: {user_input}\nYou are a translator and sentiment analyzer.")
translation = sg.generate("First, translate to French:")
sentiment = sg.generate("Now, analyze the sentiment of the original text:")
sg.return_json({"translation": translation, "sentiment": sentiment})
(참고: 위는 설명 유사 코드입니다. SGLang의 실제 구문은 다를 수 있지만 개념적으로 순차적 및 병렬 생성을 허용하고 구조화된 데이터를 반환합니다.)
이 SGLang "프로그램"이 실행되면 런타임이 인계받습니다. 먼저 번역을 위해 첫 번째 생성 호출을 실행한 다음 감정을 위해 두 번째 생성 호출을 실행하고 마지막으로 JSON을 어셈블할 수 있습니다. 내부적으로 하나 이상의 LLM 추론 백엔드를 사용합니다(vLLM과 유사한 최적화 포함). 두 프롬프트가 초기 지침 컨텍스트를 공유하므로 SGLang은 두 번째 호출에 대해 해당 접두사의 계산을 재사용할 수 있습니다. 또한 JSON 키와 형식이 sg.return_json에 의해 미리 결정된 경우 괄호/쉼표에 여러 토큰을 소비하지 않고도 해당 토큰이 출력되도록 보장할 수 있습니다.
주요 기능: SGLang의 작성자는 제로 오버헤드 스케줄링(여러 호출을 오케스트레이션하기 위한 스케줄러가 사실상 추가 지연 시간을 추가하지 않음), 캐시 인식 부하 분산(캐시 적중률을 최대화하는 방식으로 작업자에게 요청을 라우팅할 수 있음) 및 다중 모드 지원(이미지에 대한 LLaVA와 같이 비전 언어 모델도 처리할 수 있음)을 포함한 기능을 강조합니다(GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.) (GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.). 또한 일반적인 효율성 트릭(양자화(int8/4비트 등), 추측 디코딩(사전에 여러 토큰을 생성하여 확인하여 긴 생성 속도를 높일 수 있음) 및 다중 모델 오케스트레이션(예: 프로그램의 한 부분에 대해 한 모델을 사용하고 다른 부분에 대해 다른 모델을 사용))을 지원합니다. 기본적으로 LLM 기반 애플리케이션을 작성하고 높은 성능으로 실행할 수 있는 올인원 프레임워크입니다.
성능 및 사용 사례: SGLang은 복잡한 작업에서 최첨단 시스템보다 최대 6.4배 더 높은 처리량 개선을 보여주었습니다([[2312.07104] SGLang: Efficient Execution of Structured Language Model Programs). 검색 증강 생성(RAG) 파이프라인을 고려하십시오. 일반적으로 컨텍스트에 대해 벡터 검색한 다음 프롬프트에 접두사를 추가한 다음 답변을 생성합니다. SGLang을 사용하면 이 전체 시퀀스(프롬프트 템플릿에 공급되는 벡터 검색 결과, 생성)를 단일 프로그램으로 표현할 수 있습니다. 런타임은 가능하면 일부 단계를 병렬화하고 캐시된 구성 요소를 재사용할 수 있습니다. 마찬가지로 대화 기록이 있는 채팅 봇의 경우 SGLang은 매번 전체 대화를 다시 처리하는 대신 턴 간에 프롬프트의 불변 부분을 재사용할 수 있습니다. 모델의 답변이 JSON 스키마를 따르도록 보장하는 것과 같은 구조화된 출력의 경우 SGLang의 유한 상태 머신 접근 방식은 모델이 형식을 벗어나는 것을 방지하고 고정 구문을 삽입하여 더 빠르게 수행할 수 있습니다. 엔지니어 관점에서 SGLang은 DSL을 통한 생산성 향상과 최적화된 실행을 통한 성능 향상을 모두 제공하여 복잡한 LLM 워크플로를 구축합니다.
누가 지원하고 있습니까: SGLang은 Stanford/Berkeley 연구원과 LinkedIn과 같은 회사를 포함한 커뮤니티에서 지원하는 오픈 소스 프로젝트입니다(해당 인정 사항에 따라). ByteDance 및 xAI와 같은 회사에서 프로덕션에 사용되었습니다(SGLang: A Deep Dive into Efficient LLM Program Execution - DEV Community).