Một tác tử cục bộ được vận hành trong 22 giờ trên một hệ thống DGX Spark duy nhất. Tác tử này đã bị quá thời gian chờ 1.330 lần.

Một hệ thống DGX Spark, một mô hình Qwen3.8 27B, một tác tử (agent), tổng thời gian thực tế 21 giờ 36 phút. Nhật ký phiên làm việc ghi nhận 2.874 bước mô hình, 3,77 triệu token đầu ra và 1.330 yêu cầu bị phía máy khách hủy bỏ sau 5 phút không có tín hiệu phản hồi. Tác tử vẫn hoàn thành toàn bộ khối lượng công việc được giao. Cấu hình thiết lập Ở bài viết trước, mô hình Qwen3.8 27B được vận hành thông qua DeepSeek Harness (DSH) trên ba hệ thống máy: DGX Spark, RTX 5090 và Radeon R9700. Trong phần tiếp theo, vấn đề áp lực bộ nhớ VRAM của RTX 5090 đã được phân tích và cô lập. Cả hai thử nghiệm đều được xây dựng từ các phiên tác tử thực tế, không sử dụng các bài kiểm chuẩn tổng hợp. Thử nghiệm lần này có quy mô tinh gọn nhất trong chuỗi bài viết: một hệ thống máy, một phiên làm việc dài và một khối lượng công việc duy nhất. Hệ thống DGX Spark cung cấp dịch vụ vLLM với cấu hình từ bài viết đầu tiên: checkpoint Unsloth NVFP4, bộ nhớ đệm KV chuẩn FP8, hạn mức bộ nhớ 0,80, độ dài ngữ cảnh mô hình 262.144 token, bốn chuỗi xử lý đồng thời, cùng cơ chế giải mã suy đoán MTP với ba token nháp. DSH vận hành ở phía máy khách, kết nối với điểm cuối (endpoint) tương thích OpenAI. Toàn bộ thông số được giữ nguyên cho lượt chạy này. Quá trình vận hành diễn ra liên tục trước khi trích xuất dữ liệu. Lưu ý về nguồn dữ liệu: các tham số cấu hình máy chủ được dẫn từ bài viết đầu tiên, không nằm trong tệp xuất dữ liệu lần này. Tệp xuất chỉ ghi nhận các thông số từ phía tác tử (mô hình, cửa sổ ngữ cảnh, số bước, số lượt thử, số lần thử lại) mà không bao gồm tiến trình của máy chủ. Khối lượng công việc Nhiệm vụ được giao là nghiên cứu doanh nghiệp trên quy mô lớn: xử lý danh sách gồm 93 quỹ đầu tư tư nhân (PE), tìm kiếm toàn bộ các công ty trong danh mục đầu tư, chấm điểm từng công ty dựa trên một hồ sơ tiêu chuẩn bằng văn bản, lập hồ sơ nghiên cứu và đưa ra danh sách rút gọn các doanh nghiệp phù hợp nhất. Kết quả thu được gồm: 93 tệp báo cáo nghiên cứu tương ứng với từng quỹ. Một bảng tính nghiên cứu gồm 1.819 dòng, mỗi dòng tương ứng với một công ty trong danh mục đầu tư, được phân loại theo bộ tiêu chí. Quá trình kiểm tra sau đó cho thấy có hai quỹ đã được nghiên cứu đầy đủ nhưng bị sót trong quá trình tổng hợp dữ liệu. Một tài liệu Word tổng hợp danh sách rút gọn: 122 công ty được đánh giá là đáp ứng tốt tiêu chí, trong đó 17 công ty đã có dữ liệu trong hệ thống CRM. Mức độ chính xác của các kết quả này sẽ được phân tích ở phần riêng bên dưới. Cấu trúc phiên làm việc chính là yếu tố biến nhiệm vụ này thành một bài kiểm tra áp lực thực sự: Tác tử chính đọc tài liệu hồ sơ tiêu chuẩn, chuyển đổi định dạng tệp PDF gốc bằng GenOffice và thiết lập bộ tiêu chí chấm điểm. Tác tử chính phân bổ 33 tác tử phụ theo từng đợt nghiên cứu, khởi đầu từ nhóm các quỹ PE và sau đó chuyển sang cấp độ từng công ty. Các tác tử phụ này tiếp tục kích hoạt thêm 58 tác tử con, nâng tổng số lên 91 phiên làm việc của tác tử phụ. Mỗi tác tử nghiên cứu truy cập trang web của từng quỹ PE, tìm kiếm từng công ty trong danh mục và sử dụng lệnh grep trên dữ liệu trích xuất từ CRM để kiểm tra lịch sử liên hệ. Xuyên suốt 91 phiên làm việc ghi nhận: 3.847 lượt gọi công cụ, bao gồm 1.944 lệnh shell (chủ yếu là `curl` và `grep`), 1.186 lượt tìm kiếm trên mạng và 105 thao tác ghi tệp. Sự can thiệp của con người trong toàn bộ quá trình chỉ gồm ba chỉ lệnh: giao nhiệm vụ lúc 18 giờ 32 phút UTC, một dòng hiệu chỉnh phạm vi lúc 18 giờ 50 phút UTC và một lệnh "continue" duy nhất lúc 00 giờ 45 phút UTC. Toàn bộ thời gian sau đó, kéo dài hơn 15 giờ, hoàn toàn vận hành tự động. Cơ chế nén ngữ cảnh được kích hoạt ba lần ở tác tử chính và bảy lần ở các tác tử phụ, toàn bộ phiên làm việc đều tiếp nhận và xử lý ổn định. Kết quả ghi nhận Trước hết cần xác định rõ các khái niệm, do các chỉ số dưới đây đều phụ thuộc vào định nghĩa này. Một "bước" (step) là một thao tác của tác tử (một phản hồi từ mô hình), được giới hạn bởi `step/start` và `step/end`. Một "lượt thử" (attempt) là một yêu cầu HTTP gửi đến điểm cuối của mô hình; một bước có thể gồm nhiều lượt thử. Một "lần thử lại" (retry) là yêu cầu được phát lại sau khi bị quá thời gian (timeout). "Quá thời gian" là trạng thái một lượt thử bị máy khách hủy bỏ sau 300 giây gián đoạn mà không nhận được bất kỳ dữ liệu nào. https://medium.com/media/f1825c15ec0e934f27381a8d8ad2063e/hrefSố lượng token được tính lũy kế theo nhật ký tác tử, không phải dung lượng ngữ cảnh đơn lẻ. Số lượng token đầu vào bao gồm cả lịch sử hội thoại được gửi lại ở từng bước. Tốc độ 48,5 token/giây được tính bằng số lượng token đầu ra chia cho toàn bộ thời gian thực tế ...thời gian thực tế, do đó bao gồm cả chi phí điều phối, thực thi công cụ, thời gian chờ và thử lại. Đây không phải là bài đánh giá hiệu năng giải mã (decode benchmark) của vLLM. Để hình dung về quy mô: với tỷ lệ khoảng 0,75 từ trên mỗi token, 3,77 triệu token đầu ra tương đương khoảng 2,8 triệu từ, tương đương dung lượng của 35 cuốn tiểu thuyết, được tạo ra trong vòng chưa đầy một ngày bởi một máy chủ đơn lẻ thông qua hàng nghìn yêu cầu riêng biệt thay vì một phiên sinh văn bản kéo dài. Với giả định mức tiêu thụ điện liên tục là 240 W, 21,6 giờ vận hành sẽ tiêu tốn khoảng 5,2 kWh. Mức tiêu thụ điện thực tế không được đo lường trực tiếp. Con số 384 giờ không có thực Tổng thời lượng của toàn bộ 2.874 bước xử lý theo ghi nhận từ phía máy khách (client) là 384,9 giờ, trong khi phiên làm việc thực tế chỉ kéo dài 21,6 giờ. Sự chênh lệch này đòi hỏi quá trình phân tích phải được rà soát kỹ lưỡng trước khi đưa ra kết luận. Nguyên nhân nằm ở tính đồng thời (concurrency). Tổng cộng 384,9 giờ xử lý bước trong 21,6 giờ thời gian thực đồng nghĩa với việc trung bình có 17,8 bước xử lý đang chờ tại mọi thời điểm, với mức đỉnh là 30 bước, trong khi máy chủ chỉ được cấu hình để xử lý đồng thời bốn chuỗi hoạt động. Tham số `max-num-seqs` giới hạn số lượng chuỗi mà vLLM thực thi cùng một lúc, nhưng không giới hạn số lượng yêu cầu có thể xếp hàng chờ. Nói một cách rõ ràng, phía client không có giới hạn nào đối với số lượng yêu cầu gửi đến mô hình đang trong tiến trình xử lý. Tác tử chính (parent agent) liên tục điều phối các tác tử phụ (subagent) theo từng đợt; các tác tử phụ này lại tiếp tục gửi đi các yêu cầu riêng mà không có cơ chế trung gian nào kiểm soát lưu lượng đến điểm cuối (endpoint). Quy luật theo từng giờ cũng phản ánh rõ điều này. Hiện tượng quá thời gian chờ (timeout) tăng giảm tương ứng với số lượng bước xử lý tồn đọng: từ 107 đến 127 lượt mỗi giờ trong những đợt tác tử phụ đầu tiên, khi số bước tồn đọng trung bình từ 26 đến 27; tăng lên 134 đến 173 lượt mỗi giờ ở đợt đỉnh điểm thứ hai; và giảm xuống gần như bằng 0 khi số bước tồn đọng dưới 12 trong những giờ cuối cùng. Xét trên 22 khung thời gian theo giờ, hệ số tương quan đạt r = 0,86. Số bước LLM tồn đọng được đo từ phía client (phía trên), so với số lượt quá thời gian chờ mỗi giờ (phía dưới). Đường nét đứt biểu thị bốn chuỗi mà vLLM được cấu hình để chạy đồng thời, không phải độ sâu hàng đợi được ghi nhận. Các bước tồn đọng thể hiện tính đồng thời ở phía client chứ không phải độ sâu hàng đợi của máy chủ: một số bước trong đó đang trong tiến trình sinh văn bản thay vì chờ đợi. Cần lưu ý hai điểm. Mối quan hệ này có tính chất hai chiều: một bước bị quá thời gian chờ vẫn tiếp tục duy trì trạng thái tồn đọng trong ít nhất 5 phút tiếp theo, do đó hiện tượng timeout vừa phản ánh, vừa làm tăng số lượng tác vụ đồng thời. Ngoài ra, mức độ đồng thời không phải là yếu tố duy nhất giải thích toàn bộ vấn đề. Ở giờ thứ 7, số bước tồn đọng trung bình là 20 nhưng chỉ ghi nhận 34 lượt timeout. Các sự cố quá thời gian chờ gây lãng phí lớn. Tính từ lúc gửi yêu cầu đến khi hủy bỏ, 1.330 lượt timeout đã tích lũy tổng cộng 114,4 giờ yêu cầu của client, chiếm khoảng 30% tổng thời gian xử lý bước từ phía client. Đây là thời gian của máy khách tiêu tốn cho các yêu cầu bị chồng lấn chứ không phải thời gian máy chủ nhàn rỗi, và toàn bộ số thời gian này không mang lại bất kỳ kết quả sử dụng nào.