Load test LLM API mà không bị kết quả đánh lừa: hướng dẫn cho production

Bài viết này được dịch và biên tập từ bài gốc tiếng Anh trên blog của Modelflare.

Hướng dẫn cho môi trường production: load test LLM API mà không bị kết quả đánh lừa. Bài viết gồm một artifact có tính tất định (deterministic), các ranh giới lỗi, những bước kiểm tra khi rollout và các giới hạn có dẫn nguồn rõ ràng.

Quyết định trước tiên

Load test LLM API mà không bị kết quả đánh lừa là một hợp đồng production tường minh, không phải một thay đổi code đơn lẻ. Hãy xác định tín hiệu thành công, trạng thái lỗi cuối cùng và điều kiện rollback trước khi chuyển traffic. Artifact dưới đây tách bạch bằng chứng với giả định và giúp truy vết được từng lần thử.

Hãy bắt đầu với workload, chứng minh traffic bằng một case tất định, và coi ethics là một cửa kiểm soát (gate) trước khi release thay vì một việc để làm sau.

Artifact có thể tái sử dụng

Hãy dùng bảng này làm biên bản review. Một dòng chỉ đạt khi bằng chứng của nó đến từ cùng một request, cùng một khung thời gian test hoặc cùng một snapshot cấu hình.

Ví dụ minh họa

Ví dụ này là dữ liệu tổng hợp và có tính tất định. Hãy thay các identifier và threshold bằng những giá trị đã được review từ workload của chính bạn; tuyệt đối không dán secret production hay prompt của khách hàng vào test fixture.

scenario: steady_mixed
duration: 20m
warmup: 5m
arrival_rate_rps: 2
max_concurrency: 24
requests:
  short: 60%
  long: 25%
  tool: 10%
  structured: 5%
thresholds:
  error_rate: "< 0.01"
  first_output_p95_ms: "< reviewed_target"
report_failures: true

Quy trình triển khai

1. Đóng băng request, response, cấu hình và baseline quan sát được hiện tại trước khi thay đổi hành vi.
2. Chạy một case positive tất định và lưu lại toàn bộ kết quả mà client nhìn thấy.
3. Chạy case negative hoặc case giới hạn đi kèm để hành vi khi lỗi được chứng minh chứ không phải suy đoán.
4. Gắn mọi lần thử với một request ID logic, sau đó ghi lại timing, trạng thái cuối cùng và usage mà không lưu nội dung nhạy cảm.
5. Rollout qua một nhóm (cohort) có giới hạn với điều kiện dừng rõ ràng; đừng mở rộng traffic chỉ vì happy path đã chạy được.
6. Đọc lại trạng thái đã lưu bền vững và hành vi công khai sau khi thay đổi, và thực hiện kế hoạch rollback đã chuẩn bị nếu có bất kỳ bất biến nào bị vi phạm.

Các kiểu lỗi

Những lỗi sau làm kết quả mất giá trị ngay cả khi HTTP request bên ngoài trông có vẻ thành công:

• Công bố percentile mà không kèm phân phối workload, mức concurrency, các lỗi, region và khung thời gian lấy mẫu.
• Nhiều lớp retry độc lập nhân số lần thử lên và biến một đợt 429 nhỏ thành tình trạng quá tải kéo dài.
• Việc client hủy request không truyền tới công việc đang xếp hàng hoặc request upstream đang chạy, khiến tài nguyên vẫn bị tiêu tốn sau khi kết quả đã vô dụng.
• Prompt, credential, tham số tool dạng thô hoặc payload của provider bị sao chép vào telemetry có cardinality cao.

Ranh giới khi dùng Modelflare

Một gateway như Modelflare có thể tập trung hóa routing tương thích OpenAI, key, group, bản ghi usage và việc xử lý lỗi, nhưng một route đã được cấu hình không chứng minh rằng mọi upstream đều hỗ trợ mọi trường tùy chọn. Hãy kiểm chứng model và channel đã chọn bằng đường đi của giao thức gốc (native). Quản lý giá của provider theo nguồn giá hiện hành, giữ nguyên các giá trị 0 được khai báo tường minh, và coi kết quả quyết toán cuối cùng đã được lưu bền vững — không phải con số ước tính — là căn cứ tính phí.

Tham khảo bài hướng dẫn gốc để hiểu ranh giới quyết định ở phạm vi rộng hơn, và tài liệu thiết lập cho cấu hình client hiện tại.

Nguồn và ngày kiểm chứng

Các nguồn được kiểm tra vào ngày 2026-08-07. Chúng xác lập hợp đồng bên ngoài hoặc nguyên tắc vận hành; chúng không chứng minh khả năng hỗ trợ trên một route provider chưa được test.

• Grafana k6: Load testing websites
• Grafana k6: Thresholds

Tác giả là đội ngũ phát triển Modelflare, một AI API gateway; nếu bạn muốn dùng nhiều provider qua một API tương thích OpenAI, có thể tham khảo thêm tại https://modelflare.dev.