Hai máy tính dòng DGX Spark, một mô hình: mỗi máy chạy một bản sao thay vì chia nhỏ

Vận hành2026-10-31

Trong bảy tuần, mô hình ngôn ngữ cục bộ của chúng tôi chạy chia nhỏ trên hai máy NVIDIA GB10 với song song tensor. Vào ngày 22 tháng 10, chúng tôi thay thế cấu hình đó bằng một bản sao đầy đủ của mô hình trên mỗi máy cùng một proxy phân phối theo số kết nối ít nhất ở phía trước. Thông lượng tăng từ khoảng 180 lên 210 token mỗi giây, và bất kỳ máy nào cũng có thể khởi động lại mà không làm mất mô hình.

Tại sao chúng tôi từng chia nhỏ nó

Mỗi máy có 128 GB bộ nhớ dùng chung giữa CPU và GPU. Vào tháng 9, mô hình vừa khít trên một máy, nhưng bộ nhớ đệm của nó thì không: phiên bản vLLM chúng tôi dùng không thể giữ bộ nhớ đệm KV của mô hình này ở định dạng FP8, nên bộ nhớ đệm phải dùng BF16, và một máy chỉ đủ chỗ cho 499.110 token. Con số này ít hơn hai yêu cầu ở ngữ cảnh đầy đủ 262.144 token của mô hình. Khi chia nhỏ trên cả hai máy với song song tensor qua liên kết mạng trực tiếp, bộ nhớ đệm tăng lên hơn ba triệu token. Chúng tôi chia nhỏ mô hình để lấy chỗ, không phải để tăng tốc.

Những gì đã thay đổi

Một phiên bản 4-bit mới hơn của cùng mô hình (NVFP4, tạo bằng phương pháp chưng lượng hóa nhận thức) chiếm khoảng 71 GiB bộ nhớ, và một phiên bản vLLM cộng đồng cho GB10 (eugr/spark-vllm-b12x) chạy bộ nhớ đệm ở định dạng FP8. Giờ đây, một máy chứa toàn bộ mô hình và bộ nhớ đệm từ 0,76 đến 1,08 triệu token, đủ chỗ cho 2,9 đến 4,1 yêu cầu ở ngữ cảnh đầy đủ, tùy thuộc vào lượng bộ nhớ mà máy cấp phát. Cả hai bản sao đều sử dụng cơ chế giải mã suy đoán (MTP, bốn token nháp) của chính mô hình. Trước khi chuyển đổi, chúng tôi đã chạy bài kiểm tra gọi công cụ trên phiên bản mới: nó đạt 86 điểm, trong khi phiên bản bị thay thế chỉ đạt 75.

Những gì chúng tôi đo được

Một bản sao hoạt động độc lập, tính theo số lượng yêu cầu phục vụ đồng thời: với các prompt ngắn, 1 yêu cầu đạt 36 token mỗi giây, 4 yêu cầu đạt 82, 8 yêu cầu đạt 109 và 16 yêu cầu đạt 150. Với các prompt dài hơn của agent email, 4 yêu cầu đạt 81, 8 yêu cầu đạt 113 và 16 yêu cầu chỉ đạt 87: vượt quá tám yêu cầu dạng này, số lượng yêu cầu tăng thêm lại làm chậm hệ thống.

Trong một buổi chiều, một bản sao xử lý tối đa 12 yêu cầu đồng thời và bản sao kia 8 yêu cầu. Bản sao đầu tiên tạo ra 91 đến 93 token mỗi giây và hoàn thành 26 đến 27 yêu cầu mỗi phút; bản sao thứ hai tạo ra 81 đến 83 token mỗi giây và 22 yêu cầu mỗi phút. Hiện tại, cả hai đều xử lý 12 yêu cầu.

Những gì chúng tôi đã đánh đổi

Không gian. Mô hình phân tách có một bộ nhớ đệm hơn ba triệu token; các bản sao có hai bộ nhớ đệm nhỏ hơn, và một yêu cầu chỉ có thể sử dụng bộ nhớ đệm của bản sao phục vụ nó. Các agent của chúng tôi gửi nhiều yêu cầu ngắn và trung bình, nên thông lượng quan trọng hơn. Nếu bạn phục vụ một vài ngữ cảnh rất dài cùng lúc, việc phân tách có thể vẫn là lựa chọn tốt hơn. Chúng tôi vẫn giữ cấu hình phân tách, và việc chuyển đổi lại chỉ cần một script.

Những sự cố trong quá trình chuyển đổi

1. Mười một phút không có mô hình, sau đó 30 giây lỗi 502. Mô hình phân tách phải dừng trước khi một bản sao có thể tải trên cùng các máy, nên các agent của chúng tôi phải chờ khoảng mười một phút. Khi bản sao đầu tiên khởi động, proxy tiếp tục trả lời "502 no live upstreams" trong khoảng 30 giây nữa: nó đã đánh dấu các backend là lỗi khi chúng ngừng hoạt động (max_fails=3, fail_timeout=30s) và không thử lại cho đến khi hết thời gian đó.
2. Một client bỏ qua proxy. Một trong các batch job của chúng tôi có địa chỉ của máy đầu tiên trong cấu hình, nên toàn bộ tải của nó dồn vào một bản sao trong khi bản sao kia còn dư năng lực. Hiện tại, mọi client đều đi qua proxy; địa chỉ riêng của các máy chỉ dùng cho kiểm tra sức khỏe.
3. Các số liệu đo lường bị nhảy. Bộ giám sát thông lượng của chúng tôi đọc /metrics của vLLM qua proxy. Với hai backend, các lần đọc liên tiếp đến từ các bản sao khác nhau, các bộ đếm nhảy qua lại, và bộ giám sát báo cáo mô hình bị thiếu hụt. Hiện tại, nó đọc trực tiếp từng bản sao và cộng dồn lại.
4. Bộ giám sát cũ có thể đã dừng bản sao mới. Cấu hình tách biệt có một bộ giám sát khởi động lại dịch vụ khi mô hình ngừng phản hồi. Dịch vụ mới khai báo Conflicts= với dịch vụ cũ, nên việc khởi động lại đó sẽ dừng bản sao mới. Phải tắt nó bằng systemctl disable --now, không chỉ dừng, vì lớp vận hành của chúng tôi khởi động lại các đơn vị đã bật nhưng không chạy.
5. Bộ nhớ trên máy thực hiện các công việc khác. Một máy cũng chạy cơ sở dữ liệu và bản dựng trang web của chúng tôi. Với gpu-memory-utilization của vLLM ở mức 0.78, chỉ còn 5 GiB cho mọi thứ khác, nên chúng tôi đã giảm xuống 0.74 và chỉ khởi động lại bản sao đó trong khi bản sao kia gánh tải. Trên các máy này, phần bộ nhớ bạn cấp cho vLLM lấy từ cùng bộ nhớ với mọi thứ khác.

Nếu bạn có hai máy như thế này

• Nếu mô hình và bộ nhớ đệm bạn cần vừa trên một máy, hãy chạy một bản sao trên mỗi máy phía sau proxy cân bằng tải theo số kết nối ít nhất. Chỉ tách mô hình khi một máy không chứa đủ bộ nhớ đệm bạn cần.
• Hướng mọi client đến proxy, bao gồm cả các tác vụ hàng loạt và cấu hình cũ.
• Đọc số liệu từ mỗi bản sao trực tiếp.
• Cấp cho mỗi máy một phần bộ nhớ riêng, tùy theo những gì khác đang chạy trên đó.
• Đặt số lượng yêu cầu mà một bản sao phục vụ cùng lúc theo lưu lượng của bạn: với hỗn hợp của chúng tôi, 12 tốt hơn 8.
• Hãy dự tính rằng việc chuyển đổi sẽ tạm thời mất mô hình trong khoảng thời gian bằng thời gian khởi động một bản sao, và lên kế hoạch cho điều đó.

Factory Floor cung cấp proxy và cấu hình khởi động cho một hoặc hai máy, kiểm tra sức khỏe và bài kiểm tra sử dụng công cụ mà chúng tôi chạy trước khi chuyển đổi mô hình, cùng với các bộ giám sát và bộ bảo vệ bộ nhớ cho phần còn lại của máy.