Autoscaling endpoints for LLM inference

Together AI · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài của nhà cung cấp, viết như hướng dẫn dùng tính năng autoscaling cho Dedicated Model Inference; mọi nhận định là theo Together AI. Giữ lại vì có thí nghiệm so sánh ba tín hiệu scale trên cùng tải. Bài cùng loạt: Together AI 2026.

Bối cảnh

• Trả tiền theo replica-phút nên phải cân hai kiểu sai: cấp dư (GPU ngồi ở 15% chỉ để chờ đỉnh) và cấp thiếu. Theo bài, LLM serving thoái hoá phi tuyến: replica chạm giới hạn concurrency không "chậm hơn chút" mà bắt đầu xếp hàng, TTFT nhảy từ 200 ms lên 15 giây.
• Hai giả định của autoscaling cổ điển bị phá: (1) metric kiểu CPU nói sai về tải: GPU báo 60% mà hàng đợi của engine đã dồn, vì utilization đo cường độ tính toán chứ không đo áp lực; (2) cold start vài phút: xếp lên node GPU, kéo hàng chục GB weight, nạp vào VRAM, warm-up. Không thể scale kịp một đỉnh đã tới, nên phải phản ứng theo tín hiệu dẫn trước.

Thay đổi chính

• Vòng điều khiển tỉ lệ: metric quan sát → số replica mong muốn ceil(N × observed/target) → cửa sổ thời gian để giảm dao động → kẹp trong [min, max] → xếp GPU.
• Hai cửa sổ bất đối xứng: scale_up_window ngắn (scale nhầm lên chỉ tốn vài replica-phút; bỏ lỡ thì user chịu latency); scale_down_window dài, mặc định 5 phút, dài hơn nhịp tự nhiên của traffic (scale nhầm xuống tốn cả latency lẫn tiền vì phải cold start lại). Triệu chứng răng cưa (scale xuống ở mỗi đáy, cold start ở mỗi đỉnh) là dấu hiệu cửa sổ xuống quá ngắn.
• Danh mục metric theo engine: concurrency (inflight_requests, dẫn trước, mặc định target 8 mỗi replica; tăng cho chat prompt ngắn, giảm cho agent ngữ cảnh dài prefill lâu); SLO (ttft, e2e_latency, trễ sau: khi p95 vượt thì user đã thấy); hiệu suất (gpu_utilization, token_utilization, tối ưu chi phí, ít khoảng đệm). Metric theo token chỉ có khi client stream.
• Không có scale-to-zero tự đánh thức: min=max=0 là dừng hẳn endpoint (hết tính tiền), request tới sẽ lỗi. Cold start chia pha (xếp GPU → tải weight → nạp engine → warm-up) được ghi vào event feed; theo bài cỡ phút, nên auto-stop chỉ đáng cho dev/staging.
• Tương tác với rollout và routing: trong lúc rollout, nền tảng ghim giới hạn autoscale của cả hai deployment; trọng số chia traffic tính theo replica sẵn sàng nên scale lên tự nhận thêm traffic mà không đổi routing.

Vì sao (thí nghiệm của Together AI, 2026)

• Qwen3.5-9B, 1×H100 mỗi replica, giới hạn 1–3 replica, cùng một kịch bản tải hình sin 12–48 RPS có hai đỉnh 80 RPS, chạy dưới ba policy.
• Chỉ policy inflight_requests (target 8) scale. p95 phía client 3–5 giây, hệ rõ ràng bão hoà, nhưng policy ttft p95 300 ms không bao giờ scale vì continuous batching dồn áp lực hàng đợi vào latency tổng chứ không vào token đầu đo ở engine; policy gpu_utilization 75% cũng không scale vì request ngắn, dồn dập không đẩy GPU qua ngưỡng.
• Khi đỡ đỉnh nhanh hơn cold start (ví dụ gấp 10 lần trong 90 giây với cold start 4 phút), theo bài chỉ còn hai cách: min_replicas dư sẵn hoặc target cao giữ capacity thừa; đây là câu hỏi về hình dạng capacity cần trả lời trước ngày ra mắt.

Bài học cho SWE

• Chọn tín hiệu scale đo áp lực (việc đang chờ) thay vì mức bận của tài nguyên; với hệ có batching, latency đo ở engine có thể khoẻ trong khi user đang chờ lâu.
• Cửa sổ lên/xuống nên bất đối xứng theo chi phí của từng kiểu sai; cold start càng dài thì cửa sổ xuống càng phải kiên nhẫn.
• Cold start dài biến autoscaling từ cơ chế phản ứng thành bài toán dự trữ; xem NVIDIA 2026 cho hướng rút ngắn cold start.

Liên quan

• Together AI 2026 · NVIDIA 2026 · Monzo 2020 · Expedia 2020 · Tinder 2020 (autoscaler không kịp đỉnh nhọn)
• Hạ tầng phục vụ LLM inference · Tự động hoá vận hành và auto-remediation