Benchmark LLM: đừng để cluster nổ aptomat

Benchmark LLM: đừng để cluster nổ aptomat

Muốn triển khai LLM phân tán nghiêm túc, đừng bắt đầu bằng model hot. Hãy bắt đầu bằng benchmark recipe có thể lặp lại, dry-run được, và so tradeoff rõ ràng.

“Anh ơi, benchmark này chạy lại được không?” — câu hỏi nghe hiền như hỏi mượn sạc điện thoại, nhưng đủ làm nhiều team AI đứng hình.

Vì trong demo, ai cũng có thể khoe một endpoint trả lời mượt. Nhưng tới lúc tech lead hỏi: cấu hình GPU nào, batch ra sao, latency có ổn không, nếu tách prefill và decode thì lợi gì, chạy lại tuần sau có ra cùng điều kiện không — tự nhiên cả hệ thống giống ổ cắm bị cắm quá nhiều thiết bị. Chưa cháy, nhưng mùi khét bắt đầu có.

Luận điểm của mình trong bài này: benchmark LLM serving không nên là một buổi đo thủ công, mà phải là một artifact triển khai được version, review, dry-run và mở rộng như code.

Dịch sang tiếng người: thay vì “chạy thử xem sao”, team bạn cần một bộ recipe nói rõ muốn chạy gì, trên cluster nào, bằng container nào, quét những tham số nào, và đọc kết quả theo tradeoff nào.

Sơ đồ minh họa cho bài Benchmark LLM: đừng để cluster nổ aptomat

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: biến benchmark thành bản thiết kế vận hành

NVIDIA srt-slurm đáng chú ý không phải vì nó làm benchmark nghe oách hơn. Điểm đáng giữ là cách nó ép benchmark đi vào kỷ luật: dùng YAML khai báo cấu hình, dùng srtctl để chuyển thành workflow SLURM, có dry-run, có recipe, có parameter sweep, rồi phân tích kết quả theo Pareto frontier.

Một vài thuật ngữ cần neo nhanh:

Điểm mình muốn bạn nghĩ khác sau bài này: đừng hỏi “model nào chạy nhanh nhất?” trước. Hãy hỏi “quy trình benchmark nào giúp team ra quyết định mà không tự đánh lừa mình?”

Checklist trước khi đụng vào cluster thật

Nếu bạn đang chuẩn bị triển khai distributed LLM serving, đây là checklist ngắn nhưng khá gắt:

  1. Cluster profile đã rõ chưa?

Node, GPU, container runtime, đường dẫn model, network assumption — mọi thứ nên nằm trong file cấu hình, không nằm trong trí nhớ của một bạn infra đang nghỉ phép.

  1. Benchmark có dry-run được không?

Nếu recipe không validate nổi trước khi submit job, bạn đang lấy GPU production làm cầu chì thử tải.

  1. Có tách workload theo lớp chưa?

Với LLM lớn, prefill và decode có hành vi tài nguyên khác nhau. Gộp hết vào một phép đo có thể khiến bạn tối ưu nhầm.

  1. Có sweep tham số hay chỉ chọn một cấu hình “cảm giác hợp lý”?

Một điểm đo đơn lẻ thường chỉ kể chuyện rất giỏi. Sweep mới bắt đầu cho thấy đường cong tradeoff.

  1. Có nhìn throughput cùng latency không?

Throughput cao nhưng latency làm user bỏ đi thì không phải thắng. Latency thấp nhưng tốn GPU vô lý cũng không phải thơm.

Mổ hệ thống theo 4 lớp nên giữ lại

Thay vì xem srt-slurm như “tool benchmark của NVIDIA”, mình nhìn nó như một mẫu thiết kế cho team builder.

Lớp 1: cấu hình khai báo

Bạn mô tả cluster, container alias, GPU setting, model path trong YAML. Lợi ích không nằm ở YAML đẹp hay xấu, mà ở việc cấu hình có thể review bằng Git.

Một khung tối giản có thể trông như thế này:

cluster:
  name: dev-slurm
  partition: gpu
  gpus_per_node: 8

containers:
  sglang: registry.example.com/sglang:latest

models:
  deepseek_r1:
    path: /models/deepseek-r1

Đây không phải file copy-paste để chạy ngay, mà là kiểu cấu trúc bạn nên hướng tới: đưa giả định vận hành ra ánh sáng.

Lớp 2: recipe có thể chạy lại

Recipe là nơi bạn mô tả benchmark: dùng backend nào, model nào, topology nào, workload nào. Với bài toán lớn kiểu DeepSeek-R1, nguồn chính có nhắc tới mô hình tách prefill và decode thành các pool riêng.

Ví dụ cụ thể: nếu team bạn phục vụ chatbot nội bộ đọc tài liệu dài, phần prefill có thể nặng vì prompt dài; còn decode phụ thuộc số token trả lời. Nếu chỉ đo một endpoint chung, bạn không biết nút nghẽn nằm ở đâu. Tách hai giai đoạn giống như chia mạch điện thành từng nhánh: nhánh nào quá tải thì thấy rõ hơn, thay vì cả phòng tối om rồi mới đi mò.

Lớp 3: dry-run trước khi submit

Trong nguồn chính, Colab được dùng như workspace phát triển recipe, dù không có SLURM thật. Đây là điểm thực dụng: bạn có thể clone repo, cài package, kiểm tra CLI, inspect schema, validate expanded config, sinh artifact mô phỏng.

Một nhịp làm việc hợp lý:

# kiểm tra CLI
srtctl --help

# dry-run recipe built-in hoặc custom
srtctl recipe run my-serving-recipe.yaml --dry-run

# validate cấu hình đã expand
srtctl validate expanded-config.yaml

Tên lệnh cụ thể có thể thay đổi theo phiên bản tool, nhưng nguyên tắc không đổi: đừng submit job tốn GPU nếu phần cấu hình còn chưa tự đứng vững.

Lớp 4: sweep và đọc Pareto

Sau khi recipe ổn, bạn mới sweep: batch size, số worker, cách chia prefill/decode, giới hạn concurrency, độ dài prompt, độ dài output.

Đừng chỉ chọn cấu hình có throughput cao nhất. Với serving, câu hỏi đúng hơn là:

Đây là nơi benchmark rời khỏi “bài kiểm tra tốc độ” và trở thành memo ra quyết định.

Một buổi làm việc: dựng playbook benchmark cho team bạn

Nếu là mình, mình sẽ không bắt team lao ngay vào benchmark production. Mình sẽ chia một buổi thành 5 việc.

Việc 1: viết file cluster giả lập
Dù chưa có đủ quyền trên cluster, hãy mô tả cluster như bạn hiểu hiện tại: partition, GPU per node, container, model path. Chỗ nào chưa chắc thì đánh dấu TODO, đừng để nó nằm trong chat Slack.

Việc 2: tạo recipe nhỏ nhất
Chọn một model đại diện, một workload đại diện, một backend phục vụ. Mục tiêu chưa phải tối ưu, mà là chạy được vòng validate → generate artifact → review.

Việc 3: thêm biến cần sweep
Chỉ chọn 2-3 biến trước. Ví dụ minh họa: concurrency, batch size, số decode worker. Nếu sweep quá nhiều từ đầu, bạn sẽ có một rừng kết quả nhưng không có quyết định.

Việc 4: định nghĩa tiêu chí đậu/rớt
Trước khi chạy, thống nhất ngưỡng latency chấp nhận được, throughput mong muốn, ngân sách GPU, và workload ưu tiên. Nếu không có tiêu chí trước, sau benchmark ai cũng sẽ cherry-pick phần hợp ý mình.

Việc 5: viết decision note sau khi xem Pareto
Không cần văn chương. Chỉ cần:

## Quyết định
Chọn cấu hình B cho staging.

## Lý do
- Nằm gần Pareto frontier.
- Latency ổn hơn cấu hình throughput tối đa.
- Dễ mở rộng thêm decode worker.

## Rủi ro còn lại
- Chưa đo workload prompt rất dài.
- Chưa chạy trên traffic thật.

Decision note này quan trọng hơn một biểu đồ đẹp. Nó lưu lại cách team suy nghĩ tại thời điểm ra quyết định.

Ba bẫy dễ làm benchmark chập mạch

Bẫy 1: lấy Colab làm bằng chứng production
Colab hữu ích để phát triển workflow, kiểm tra recipe, hiểu API. Nhưng nó không thay thế cluster thật. Dùng Colab để chuẩn bị dây điện, không phải để kết luận cả tòa nhà chịu tải tốt.

Bẫy 2: benchmark bằng workload quá sạch
Prompt đều nhau, output đều nhau, traffic đều nhau — nhìn rất gọn, nhưng production thường không ngoan vậy. Hãy thêm workload đại diện: prompt dài/ngắn, output ngắn/dài, request đồng thời, và lỗi timeout.

Bẫy 3: chỉ tối ưu một chỉ số
Nếu dashboard chỉ reo hò throughput, team sẽ vô thức hy sinh latency. Nếu chỉ nhìn latency, team có thể overprovision GPU. Pareto frontier không trả lời thay bạn, nhưng nó buộc bạn nhìn tradeoff tử tế hơn.

Điều đáng học từ các workflow cấu hình-driven

Nguồn liên quan về NeMo AutoModel cũng cho một tín hiệu cùng họ: cấu hình-driven workflow đang trở thành cách NVIDIA đẩy bài toán từ “notebook chạy được” sang “recipe có thể scale”. Với fine-tuning Qwen3 bằng LoRA trên một GPU, ý hay không nằm ở Colab, mà ở việc patch precision, batch size, checkpoint, scheduler trong cấu trúc recipe rồi giữ được đường lên môi trường lớn hơn.

Cùng logic đó cũng xuất hiện ở các hướng khác: app local dùng Apple Foundation Models cần tách web UI và companion app; UX testing bằng Nova Act cần tách flow, quan sát, action, log; translation app thì nhắc lại bài học cũ của Transformer: context quyết định chất lượng. Các ví dụ khác nhau, nhưng bài học vận hành giống nhau: AI system tốt thường thắng ở ranh giới giữa các lớp, không chỉ ở model ở giữa.

Vậy nếu team bạn đang chuẩn bị triển khai LLM serving phân tán, đừng bắt đầu bằng câu “chọn model nào hot nhất?”. Hãy bắt đầu bằng một recipe có thể chạy lại, một dry-run không tốn GPU, một sweep đủ hẹp, và một Pareto chart đủ thật để khiến cuộc họp bớt cảm tính.

Chốt lại: benchmark không phải màn khoe cơ bắp của cluster; nó là aptomat giúp bạn biết hệ thống sắp quá tải trước khi cả văn phòng tối thui.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo