Tốc độ Suy luận cho Các Tác nhân Lập trình: TTFT so với Thông lượng

Tốc độ trong mã hóa AI rất dễ bị đơn giản hóa quá mức. Các nhóm thường nói về một mô hình hoặc backend như thể nó chỉ đơn giản là nhanh hoặc chậm, nhưng quy trình làm việc mã hóa thực tế chia tốc độ thành ít nhất hai câu hỏi khác nhau: tốc độ mà token hữu ích đầu tiên xuất hiện nhanh như thế nào, và hệ thống có thể duy trì bao nhiêu công việc khi quá trình tạo bắt đầu.

Một tiêu chuẩn Cline gần đây đã làm cho sự phân chia đó trở nên rất rõ ràng. Trong một nhiệm vụ loại bỏ ngắn, một thiết lập dựa trên đám mây đã thắng vì nó bắt đầu nhanh nhất. Trong một bài kiểm tra suy luận thô dài hơn, một thiết lập DGX Spark cục bộ đã cung cấp thông lượng duy trì mạnh mẽ hơn nhiều so với một GPU tiêu dùng chạy cùng mô hình với việc tải bộ nhớ nặng. Đối với các nhóm chọn nơi chạy các tác nhân mã hóa, sự khác biệt đó rất quan trọng.

So sánh nhanh: những gì bài kiểm tra đã chỉ ra

• Một thiết lập Mac dựa trên đám mây đã thắng nhiệm vụ “Thunderdome” ngắn trong 1,04 giây.
• Cùng tiêu chuẩn đó đo được DGX Spark ở mức 42,9 token mỗi giây trong cuộc đua suy luận trực tiếp.
• Thiết lập RTX 4090 đạt 8,7 token mỗi giây với việc tải RAM nặng.
• Thời gian thực trong cuộc đua suy luận trực tiếp là 5,11 giây cho Mac dựa trên đám mây, 21,83 giây cho DGX Spark, và 93,89 giây cho máy trạm 4090.

Các chi tiết phần cứng giúp giải thích sự chênh lệch. NVIDIA’s Tổng quan hệ thống DGX Spark làm nổi bật thiết kế bộ nhớ hợp nhất 128 GB của nó, trong khi máy 4090 trong bài kiểm tra có 24 GB VRAM và phải tải phần lớn mô hình 120B vào RAM hệ thống. Điều đó thay đổi toàn bộ hình dạng của khối lượng công việc.

Tại sao TTFT thắng cuộc đua ngắn

Trong một nhiệm vụ tuần tự nhỏ, thời gian đến token đầu tiên quyết định người chiến thắng. Hệ thống đầu tiên hiểu được lời nhắc, tạo ra một lệnh hợp lệ và thực thi nó sẽ có lợi thế mà các hệ thống khác có thể không bao giờ phục hồi được. Đó chính xác là những gì đã xảy ra trong bài kiểm tra Cline ngắn.

Cơ sở hạ tầng đám mây có thể tỏa sáng ở đây vì backend đã được tối ưu hóa cho các đường dẫn phản hồi nhanh. Nếu khối lượng công việc của bạn chủ yếu là phân loại nhanh, lời nhắc ngắn, hoặc các vòng lặp tác nhân nhỏ nơi câu trả lời đầu tiên quan trọng hơn so với thời gian dài, TTFT thấp có thể đánh bại một máy cục bộ mạnh hơn.

Tại sao thông lượng quan trọng hơn trong các phiên mã hóa thực tế

Hầu hết các phiên mã hóa không phải là các cuộc chiến kéo dài một giây. Chúng là các vòng lặp dài, lộn xộn với các chỉnh sửa tệp, gọi công cụ, thử lại, chạy thử nghiệm, và hàng trăm hoặc hàng nghìn token được tạo ra. Đó là nơi thông lượng duy trì bắt đầu quan trọng hơn so với sự bùng nổ ban đầu.

Với tốc độ 42,9 token mỗi giây, kết quả DGX Spark cho thấy điều gì xảy ra khi một mô hình lớn có thể duy trì trong bộ nhớ nhanh. Ngược lại, kết quả 4090 cho thấy việc chuyển tải trở nên đắt đỏ như thế nào khi mô hình quá lớn so với VRAM cục bộ. Cùng một họ mô hình có thể mang lại cảm giác hoàn toàn khác nhau tùy thuộc vào cách bố trí bộ nhớ, không chỉ dựa vào thương hiệu GPU hoặc giá cả.

Nếu bạn làm việc với các ngăn xếp cục bộ, tài liệu Ollama là một tài liệu tham khảo tốt về cách các nhóm triển khai các điểm cuối mô hình cục bộ và dựa trên đám mây một cách tương thích. Bài học quan trọng không phải là công cụ nào bạn chọn. Đó là kích thước mô hình, sự phù hợp với bộ nhớ và cấu trúc liên kết mạng thay đổi trải nghiệm người dùng nhiều hơn so với những gì một tiêu đề điểm chuẩn đơn lẻ gợi ý.

Kích thước mô hình thay đổi kinh tế học

So sánh của Cline tập trung vào một mô hình 120B, điều này đẩy phần cứng tiêu dùng vào một chế độ hoàn toàn khác. Một khi mô hình tràn ra khỏi bộ nhớ nhanh, chi phí của bạn không chỉ còn là token. Bạn cũng phải trả giá bằng độ trễ, xếp hàng và sự kiên nhẫn của nhà phát triển.

Đó là lý do tại sao việc chọn cục bộ hay đám mây hiếm khi là một lựa chọn hoàn toàn mang tính ý thức hệ. Đám mây có thể thắng về sự tiện lợi và khởi động nhanh. Các hệ thống cục bộ lớn có thể thắng về quyền riêng tư, chi phí biên dự đoán được và thông lượng duy trì. Phần cứng tiêu dùng vẫn có thể là lựa chọn đúng, nhưng thường dành cho các mô hình nhỏ hơn phù hợp một cách gọn gàng.

Vị trí của ShareAI

ShareAI giúp ích khi câu trả lời tốt nhất không phải là một backend mãi mãi. Với hơn 150 mô hình thông qua một API, bạn có thể giữ quy trình làm việc mã hóa ổn định trong khi thay đổi mô hình hoặc nhà cung cấp dựa trên công việc. Điều này hữu ích khi một nhiệm vụ ưu tiên TTFT thấp và nhiệm vụ khác ưu tiên đầu ra duy trì mạnh mẽ hơn hoặc giá cả khác nhau.

Bạn có thể sử dụng tài liệu ShareAI và Bắt đầu nhanh API để giữ lớp định tuyến đó đơn giản. Thay vì viết lại tích hợp của bạn mỗi khi bạn muốn so sánh các nhà cung cấp hoặc mô hình, bạn có thể giữ tác nhân hướng đến một API và đưa ra các quyết định backend thông minh hơn bên dưới nó.

Cách chọn ngăn xếp phù hợp

• Chọn ưu tiên đám mây khi câu trả lời đầu tiên quan trọng nhất và tốc độ thiết lập quan trọng hơn so với kiểm soát cục bộ.
• Chọn phần cứng địa phương có bộ nhớ cao khi bạn cần sự riêng tư, chi phí dự đoán được và thông lượng duy trì mạnh mẽ trên các mô hình lớn.
• Chọn GPU tiêu dùng một cách cẩn thận và ghép chúng với kích thước mô hình phù hợp.
• Chọn một lớp trừu tượng như ShareAI khi bạn muốn so sánh, định tuyến và thay đổi nhà cung cấp mà không cần xây dựng lại quy trình làm việc của mình.

Bước tiếp theo

Nếu bạn đang đánh giá tốc độ suy luận cho các tác nhân mã hóa, đừng dừng lại ở một con số tiêu đề. Đo lường phản hồi mở đầu, tốc độ tạo duy trì và các đánh đổi vận hành quan trọng đối với nhóm của bạn. Sau đó chọn một lớp định tuyến cho phép bạn thích nghi khi các ưu tiên đó thay đổi.