노드 1개에서 Llama 3.3 70B를 서빙합니다.

필요한 것

700억 파라미터입니다. 4비트에서는 가중치가 35 GB이고, KV 캐시는 8k 컨텍스트에서 단일 요청 기준으로 2.5 GB를 추가하며, 런타임 오버헤드는 약 15%입니다. 나머지는 모두 이 숫자 3개에서 나옵니다 — 사이징 가이드가 그 근거를 보여 줍니다.

128k의 4비트 행을 보십시오: AWQ와 GPTQ는 가중치만 양자화하므로, 가중치는 35 GB로 줄지만 캐시는 전혀 줄지 않습니다. 이 사실 하나가 아래 머신 선택의 대부분을 결정합니다.

노드 선택

이 모델을 단일 카드에 담는, 당사 카탈로그에서 가장 저렴한 머신입니다. 가능하다면 택해야 할 구성입니다 — 샤딩이 없으면 동기화도 없고, 디버깅할 것이 하나 줄어듭니다.

처리량은 단일 스트림 생성 기준이며, 메모리 대역폭에 좌우되고, 의도적으로 보수적으로 잡았습니다. 연속 배칭을 쓰면 동시 요청 전체의 합계는 몇 배 더 높아집니다 — 그것이 바로 vLLM의 존재 이유입니다.

설정 10분

주소를 빼면 여기에 당사에만 해당하는 것은 없습니다. Docker와 NVIDIA 컨테이너 툴킷, 그리고 동작하는 드라이버 스택은 이미 머신에 설치되어 있습니다.

$ ssh root@203.0.113.42
$ nvidia-smi --query-gpu=name,memory.total --format=csv

# Weights on the fast local NVMe, not the system volume.
$ mkdir -p /scratch/models
$ df -h /scratch

# A gated model needs a token. Skip if yours is open.
$ export HF_TOKEN=hf_xxxxxxxxxxxxxxxxxxxx

서버 시작

컨테이너 1개입니다. 첫 실행에서 양자화된 가중치를 약 40 GB 내려받으며, 1 Gbit/s 포트에서는 몇 분이 걸립니다. 이후 재시작은 몇 초면 됩니다.

$ docker run -d --name vllm --restart unless-stopped \
    --gpus all --ipc=host \
    -v /scratch/models:/root/.cache/huggingface \
    -e HF_TOKEN="$HF_TOKEN" \
    -p 127.0.0.1:8000:8000 \
    vllm/vllm-openai:latest \
    --model casperhansen/llama-3.3-70b-instruct-awq \
    --quantization awq_marlin \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.92

# Watch it load. "Application startup complete" is the signal.
$ docker logs -f vllm

$ curl -s http://127.0.0.1:8000/v1/models | head

$ curl -s http://127.0.0.1:8000/v1/chat/completions \
    -H 'Content-Type: application/json' \
    -d '{"model":"casperhansen/llama-3.3-70b-instruct-awq",
         "messages":[{"role":"user","content":"In one sentence: what is a KV cache?"}],
         "max_tokens":80}'

중요한 플래그

전 세계에 공개하지 않기

SSH 터널로 직접 쓰시는 머신에서 접속하십시오 — 포트를 열 필요도, 인증서를 관리할 필요도, 잘못 설정할 것도 없습니다:

$ ssh -N -L 8000:127.0.0.1:8000 root@203.0.113.42

# Now http://127.0.0.1:8000 on your laptop is the server.

정말로 공개해야 한다면, 앞단에 TLS와 API 키를 갖춘 리버스 프록시를 두고, 방화벽에서 출발지 주소도 제한하십시오. 문서에 최소한의 규칙 세트가 있습니다. 요청하는 누구에게나 응답하게 될 엔드포인트에는 이중, 삼중의 방어가 올바른 자세입니다.

처리량 높이기

시도해 볼 만한 순서대로입니다. 앞의 2가지는 비용이 들지 않으며 대개 가장 큰 이득을 줍니다.

1. --max-model-len 값을 실제 컨텍스트에 맞게 낮추십시오. 거의 언제나 단일 조치로는 가장 큰 이득이고, 실제로 쓰고 있던 것을 잃지도 않습니다.
2. --gpu-memory-utilization 값을 0.95로 올리십시오. 전용 머신이므로, 카드 위에 자리를 남겨 줄 다른 것이 없습니다.
3. 카드가 지원한다면 FP8 KV 캐시를 켜십시오. 담을 수 있는 양이 2배가 됩니다.
4. 클라이언트 쪽에서 배칭하십시오. 연속 배칭은 요청이 동시에 도착할 때만 효과가 있습니다. 요청을 하나씩 보내면 어떻게 설정하더라도 카드 대부분이 유휴 상태로 남습니다.
5. 그다음에, 그리고 그때에만 더 빠른 카드를 고려하십시오. 생성 속도는 메모리 대역폭에 좌우되므로, 같은 모델에서 4,800 GB/s의 H200은 2,000의 H100 PCIe보다 대략 2.4× 빠릅니다 — 실제 이득이지만, 이 목록에서 가장 비싼 방법입니다.

$ docker exec vllm python -m vllm.entrypoints.openai.api_server --help | head -1
$ docker exec vllm vllm bench serve \
    --model casperhansen/llama-3.3-70b-instruct-awq \
    --num-prompts 200 --request-rate 8

# And watch the card while it runs: if utilisation sits below 90%,
# the bottleneck is your client, not the GPU.
$ nvidia-smi dmon -s um

계속 가동하기

첫날에 해 둘 만한 3가지입니다. 3가지 모두 14일째에 발견하면 성가시기 때문입니다.

그리고 이용 기간이 끝나면 유예 기간 없이 1시간 이내에 디스크를 소거합니다. /scratch에 있는 모든 것이 함께 사라집니다. 이는 의도된 것입니다 — 받으신 머신에 다른 사람의 데이터가 없었음을 보장하는 것과 같은 약속입니다 — 다만 이용 기간의 마지막 날은 자료를 옮기기 시작할 날이 아니라는 뜻이기도 합니다.