AI Scaling: Mở rộng hệ thống AI #28

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: AI Scaling là quá trình giúp hệ thống AI phục vụ nhiều task hoặc người dùng hơn mà vẫn giữ chất lượng, an toàn, độ trễ và chi phí trong giới hạn. Scaling không chỉ là thêm máy; team phải đo toàn luồng, tìm đúng cổ chai và xác minh bằng load test.

Đọc xong, bạn sẽ hiểu:

• Vì sao thêm instance sai chỗ không làm hệ thống nhanh hơn.
• Cách đọc demand, concurrency, queue, throughput và latency p95.
• Cách lập Capacity Sheet và chạy một bài load-test giả lập trong 15 phút.

1. AI Scaling là gì, vì sao thêm máy chưa chắc giải quyết?

Hãy hình dung một siêu thị có hai quầy thu ngân nhưng chỉ một máy chủ kiểm tồn kho. Mở thêm tám quầy vẫn không tăng số hóa đơn hoàn thành nếu tất cả quầy cùng chờ máy kiểm tồn. AI system cũng vậy: web server có thể khỏe nhưng model quota, vector database, tool ngoài hoặc state store mới là điểm nghẽn.

Vì thế, câu hỏi đúng không phải “cần bao nhiêu server?” mà là “ở mức tải nào, thành phần nào chạm giới hạn trước, và outcome nào bắt đầu xấu?”. Một hệ thống chỉ được xem là scale được khi tải tăng mà successful task vẫn qua quality, safety, latency và cost guardrail.

Scaling có hai phạm vi dễ lẫn. Scaling một workload nghĩa là tăng capacity cho một sản phẩm cụ thể. Scaling toàn tổ chức nghĩa là nhiều team dùng pattern, component và governance chung. Bài này tập trung workload; Enterprise AI #29 sẽ bàn phạm vi tổ chức.

AWS mô tả kiến trúc production nên tách hệ thống AI phức hợp thành component lỏng ghép để retrieval, orchestration, frontend và các phần khác có thể triển khai, thay đổi và scale độc lập (AWS Prescriptive Guidance).

Hình 1 — Scaling chỉ có nghĩa khi toàn luồng giữ được quality, safety, latency và cost dưới tải tăng.

2. Bản đồ tải: demand, concurrency, queue và SLO

Trước khi scale, team cần một “hộ chiếu workload” gồm loại task, traffic trung bình, peak, request size, model route, dependency, state và ngưỡng chấp nhận.

Throughput là số task hoàn thành trong một đơn vị thời gian. Concurrency là số request đang được xử lý cùng lúc. Hai số không giống nhau: 100 request cùng vào nhưng mỗi request giữ worker 30 giây có thể tạo throughput thấp.

Latency p95 là mức mà 95% request không chậm hơn nó; 5% còn lại có thể chậm hơn. Average 2 giây không nói được tail 20 giây. Với trải nghiệm người dùng, p95 hoặc p99 thường cho thấy hàng chờ và dependency chậm rõ hơn average.

Queue giữ request chưa được xử lý. Queue giúp hấp thụ burst ngắn, nhưng queue dài biến thành latency và có thể làm dữ liệu hết hạn. Backpressure là cách hệ thống giảm, hoãn hoặc từ chối thêm tải khi downstream đã quá sức. Nhà hàng báo hết bàn và hẹn 20 phút là backpressure; nhận vô hạn rồi để khách chờ hai giờ không phải scaling.

SLO, hay service level objective, là mục tiêu đo được. Ví dụ demo:

• p95 dưới 5 giây ở 200 concurrent users;
• success rate ít nhất 96%;
• critical error bằng 0;
• cost mỗi successful task không quá 0,12 USD;
• không bypass authorization hoặc safety check.

Google SRE coi capacity planning và load testing định kỳ là phần cốt lõi để nối raw capacity với service capacity; demand forecast phải gồm cả tăng trưởng tự nhiên lẫn sự kiện như launch hoặc campaign (Google SRE).

3. Sáu lớp cần scale độc lập

a. Edge, quota và admission

Rate limit theo tenant/use case, chặn request trùng và đặt payload limit. Admission control quyết định request nào được nhận ngay, vào queue hay bị từ chối có hướng dẫn. Nó bảo vệ hệ thống khỏi một khách hàng chiếm hết capacity.

b. Queue và worker

Tách request nhận vào khỏi job dài bằng queue. Worker pool scale theo queue age hoặc queue depth, nhưng phải có max queue, deadline và dead-letter path. Queue không sửa được model chậm; nó chỉ giúp điều tiết.

Google Cloud ghi nhận queue size là tín hiệu nhạy với load spike và phù hợp khi muốn tối ưu throughput/cost trong latency target; batch size có thể hợp hơn cho workload nhạy latency, nhưng batch lớn cũng có tradeoff về độ trễ (Google Cloud GKE).

c. Stateless orchestration

Horizontal scaling là thêm instance. Vertical scaling là tăng CPU, RAM hoặc accelerator cho một instance. Orchestrator dễ scale ngang hơn khi stateless: conversation state, idempotency key và job status nằm trong store chung, không mắc kẹt ở RAM một máy.

Không phải mọi thứ đều stateless. Session, vector index, cache và database cần consistency, partition hoặc replica phù hợp. Microsoft phân biệt lớp stateless như API/orchestration có thể thêm instance, còn data layer thường phải dùng read replica, partition hoặc sharding, tức chia dữ liệu/tải thành phần (Microsoft Azure Well-Architected).

d. Model routing và quota

Scale model path bằng routing theo task, provider quota, region và fallback đã kiểm thử. Một model endpoint có thêm worker nhưng vẫn đụng token-per-minute quota. Fallback chỉ được dùng nếu cùng authorization, data residency và quality gate; không tự chuyển dữ liệu nhạy cảm sang provider khác.

e. Data, retrieval và cache

Đo query latency, index freshness, connection pool và hot partition. Cache có thể giảm tải cho query lặp, nhưng key phải gồm tenant, version và quyền. Replica đọc không giải quyết write contention; sharding không nên làm sớm nếu chưa có evidence về partition bottleneck.

f. Tool và dependency ngoài

Tool API có quota, timeout và failure mode riêng. Dùng timeout, retry budget, idempotency và circuit breaker — cơ chế tạm ngắt gọi dependency đang lỗi để hệ thống không tự tạo bão retry. Fallback có thể trả “đang xử lý” hoặc chuyển human review; không bịa output.

Hình 2 — Mỗi lớp có capacity và failure mode khác nhau; thêm instance sai chỗ không mở được cổ chai.

4. Case SCALE-28: load test từ 50 lên 200 concurrent users

Case SCALE-28 / LOAD-2801 dùng dữ liệu demo, không phải benchmark vendor. Team tạo cùng bộ task, cùng success definition và tăng tải theo nấc 50, 100, 150, 200 concurrent users. Baseline có orchestrator scale ngang nhưng mọi request đổ thẳng vào một model route; tool retry không có budget rõ.

Ở nấc 200, baseline có p95 8,4 giây, success 91%, max queue 142, 18 timeout và cost 0,14 USD mỗi successful task. Trace cho thấy queue phình trước model call, premium route nhận cả task đơn giản và retry đồng loạt khi tool chậm.

Thay đổi được giới hạn ở ba chỗ: admission đặt max queue/deadline; routing đưa task đơn giản sang route đã qua eval; worker pool scale theo queue age với stabilization window. Tool retry còn một lần, có backoff và circuit breaker. Không đổi dataset, success definition hoặc safety policy.

Hình 3 — Queue, routing và worker pool cải thiện capacity trên cùng tải demo 200 người dùng đồng thời.

Kết quả đủ cho limited rollout, chưa chứng minh hệ thống chịu được traffic thật vô hạn. Team giữ canary nhỏ, rollback khi p95 vượt 5 giây ba cửa sổ liên tiếp, success dưới 96% hoặc xuất hiện critical error. Câu “thêm worker sẽ tăng capacity” là đoán chắc. Câu có điều kiện: thêm worker chỉ giúp khi worker là cổ chai và downstream còn headroom.

5. Sai lầm, giới hạn và checklist

Sai lầm thứ nhất là scale mọi component cùng lúc, khiến team không biết thay đổi nào có tác dụng. Sai lầm thứ hai là chỉ nhìn CPU; queue age, provider quota hoặc connection pool có thể nghẽn khi CPU còn thấp. Sai lầm thứ ba là retry không giới hạn, biến lỗi nhỏ thành retry storm. Sai lầm thứ tư là load test đường “happy path” nhưng bỏ request dài, tool timeout và tenant ồn.

Giới hạn: load generator không mô phỏng hoàn hảo người dùng, prompt distribution và network thật. Một giờ test không đại diện campaign dài. Autoscaling có cold start và stabilization lag. Multi-region tăng resilience nhưng tăng cost, data-consistency và operational complexity. Nhiều replica cũng không sửa được thuật toán tệ hoặc database lock.

Checklist:

1. Viết workload passport và success definition.
2. Khóa SLO cho p95, success, safety và cost/success.
3. Vẽ demand → queue → orchestration → model → data/tool.
4. Đo utilization, queue age, timeout và quota ở từng layer.
5. Tăng tải theo nấc; giữ dataset và guardrail.
6. Chọn một bottleneck, một thay đổi và một rollback rule.
7. Test burst, long request, dependency chậm và partial failure.
8. Canary nhỏ; so baseline/scaled; ghi capacity headroom.
9. Review lại khi model, traffic mix, quota hoặc architecture đổi.

Đứng ngoài nếu chưa có observability, SLO hoặc môi trường test tách biệt. Dừng khi critical error xuất hiện, tenant isolation hỏng, queue mất giới hạn, fallback bypass quyền, downstream hết headroom hoặc cost/success vượt budget.

6. Bắt đầu từ đâu: Capacity Sheet 15 phút

Dùng Google Sheets với số demo, không gửi traffic thật và không dùng tiền thật.

Tạo cột:

Stage | Arrival rate | Concurrency | Capacity | Queue max | p95 | Success | Timeout | Cost/success | Owner | Action

a. Mẫu đối chiếu Capacity Sheet

Trong 15 phút:

1. Chọn một demo workflow và vẽ năm stage.
2. Điền capacity giả định từng stage: 40, 30, 12, 25, 20 task/phút.
3. Khoanh số nhỏ nhất: model route 12 task/phút là bottleneck giả định.
4. Tạo hai phương án: thêm model capacity hoặc route task dễ.
5. Ghi guardrail và rollback rule; không kết luận trước load test.

Kết quả mong đợi là một hypothesis có thể kiểm: “Nếu route 40% task dễ sang route B đã qua eval, throughput tăng mà success vẫn ≥96% và cost/success ≤0,12 USD.” Capacity Sheet không thay load test; nó giúp team biết cần test điều gì.

7. Tổng kết

a. Năm ý chính

• AI scaling là giữ outcome đạt chuẩn khi tải tăng.
• Throughput, concurrency, queue và p95 trả lời các câu hỏi khác nhau.
• Edge, worker, orchestrator, model, data và tool phải scale độc lập.
• Load test cần tăng tải theo nấc, đo bottleneck và giữ cùng guardrail.
• SCALE-28 chỉ đủ limited rollout, không phải bằng chứng “scale vô hạn”.

b. Câu hỏi tự kiểm tra

• Vì sao thêm web server có thể không tăng throughput?
• Queue giúp gì và không giúp gì?
• Khi nào horizontal scaling dễ hơn?
• Vì sao CPU thấp vẫn có thể nghẽn?

c. Gợi ý đáp án

Xem gợi ý câu 1

Model quota, data hoặc tool có thể là cổ chai thật. Xem mục 1 và 3.

Xem gợi ý câu 2

Queue hấp thụ burst và điều tiết; nó không làm downstream xử lý nhanh hơn. Xem mục 2.

Xem gợi ý câu 3

Khi instance stateless và state nằm trong store chung có capacity phù hợp. Xem mục 3.

Xem gợi ý câu 4

Hệ thống có thể chạm quota, queue, connection pool hoặc dependency timeout trước CPU. Xem mục 5.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• Google SRE — Introduction and capacity planning
• Google Cloud — Autoscaling LLM inference workloads
• AWS — Architecting generative AI applications for production
• Microsoft Azure — Architecture pattern for AI workloads

Điều hướng: Ôn AI Cost Optimization #27. Tiếp theo: Enterprise AI #29.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.