3 cấp độ định tuyến LLM: Fast, Smart và Power Model Stacks

Thiết kế một bộ định tuyến mô hình sẵn sàng cho sản xuất với các cấp độ Fast, Smart và Power, bao gồm circuit breaker, triển khai thử nghiệm (canary rollout) và danh sách kiểm tra triển khai.

Tìm hiểu về định tuyến mô hình AI

Hóa đơn LLM của bạn vừa lên tới 50.000 USD trong tháng này. Bạn đang gửi mọi yêu cầu đến GPT-4, bất kể người dùng hỏi "2+2 bằng bao nhiêu?" hay cần trợ giúp viết một tài liệu pháp lý phức tạp. Cách tiếp cận này hoạt động, nhưng nó tốn kém và không hiệu quả.

Bộ định tuyến mô hình AI giải quyết vấn đề này. Nó phân tích từng yêu cầu đến và gửi đến mô hình phù hợp nhất trong hệ thống của bạn. Các câu hỏi đơn giản sẽ được gửi đến những mô hình nhanh, rẻ. Các tác vụ phức tạp sẽ được gửi đến những mô hình mạnh mẽ, đắt tiền. Kết quả là chi phí thấp hơn, hiệu suất tốt hơn và dịch vụ đáng tin cậy hơn.

Hầu hết các nhóm đều giảm được 30-50% chi phí sau khi triển khai định tuyến thông minh. Một số nhóm đạt được mức tiết kiệm lên đến 85% cho các khối lượng công việc cụ thể. Ngoài chi phí, định tuyến còn cải thiện độ trễ bằng cách khớp độ phức tạp của yêu cầu với khả năng của mô hình. Một mô hình nhỏ có thể trả lời các câu hỏi cơ bản nhanh hơn một mô hình lớn.

Thiết lập bộ định tuyến mô hình yêu cầu đưa ra quyết định về việc sử dụng mô hình nào, cách phân loại yêu cầu và khi nào cần chuyển sang các tùy chọn mạnh mẽ hơn. Bài viết này sẽ hướng dẫn toàn bộ quy trình, từ việc lựa chọn kiến ​​trúc đến giám sát hiệu suất trong môi trường sản xuất.

Các thành phần cốt lõi của bộ định tuyến mô hình

Một bộ định tuyến mô hình hoạt động hiệu quả bao gồm một số thành phần chính phối hợp với nhau.

Công cụ phân tích yêu cầu

Công cụ phân tích yêu cầu kiểm tra các truy vấn đến và trích xuất những đặc điểm liên quan. Các đặc điểm này xác định mô hình nào nên xử lý yêu cầu.

Các đặc điểm phổ biến bao gồm độ dài prompt, ngôn ngữ được phát hiện, loại truy vấn, cấp độ người dùng và độ phức tạp ước tính. Một số hệ thống sử dụng mô hình phân loại nhỏ để phân loại yêu cầu. Những hệ thống khác sử dụng logic dựa trên quy tắc hoặc nhúng.

Công cụ phân tích chạy nhanh vì nó nằm trong đường dẫn quan trọng. Mỗi mili giây ở đây làm tăng độ trễ cho trải nghiệm người dùng. Các hệ thống dựa trên quy tắc đơn giản thêm 10-50ms độ trễ. Những hệ thống nhúng thêm 50-200ms. Công cụ phân loại dựa trên LLM thêm 500-2000ms.

Logic định tuyến

Logic định tuyến quyết định mô hình nào nhận được mỗi yêu cầu. Điều này có thể đơn giản như một tập hợp các quy tắc nếu-thì hoặc phức tạp như một hệ thống Machine Learning.

Định tuyến dựa trên quy tắc sử dụng các điều kiện rõ ràng. Nếu độ dài prompt dưới 100 từ, hãy sử dụng Mô hình A. Nếu truy vấn chứa code, hãy sử dụng Mô hình B. Phương pháp này minh bạch và dễ gỡ lỗi, nhưng yêu cầu điều chỉnh thủ công.

Định tuyến ngữ nghĩa sử dụng các embedding để khớp những yêu cầu với các danh mục được xác định trước. Mỗi danh mục ánh xạ tới một mô hình cụ thể. Phương pháp này xử lý các sắc thái tốt hơn so với những quy tắc nhưng yêu cầu duy trì một tập hợp các ví dụ tham chiếu.

Định tuyến hỗ trợ LLM sử dụng một mô hình nhỏ để phân loại các yêu cầu và quyết định định tuyến. Phương pháp này linh hoạt và có thể thích ứng với các loại truy vấn mới, nhưng nó làm tăng độ trễ và chi phí.

Model registry

Model registry theo dõi các mô hình có sẵn, khả năng của chúng, trạng thái hiện tại và chi phí. Khi một mô hình gặp sự cố, registry sẽ đánh dấu nó là không khả dụng. Bộ định tuyến sau đó sẽ chuyển lưu lượng truy cập đến nơi khác.

Registry nên theo dõi URL endpoint của mô hình, API key, giới hạn tỷ lệ, giá mỗi token, độ trễ trung bình và tỷ lệ lỗi gần đây. Thông tin này giúp bộ định tuyến đưa ra quyết định sáng suốt.

Bộ xử lý dự phòng

Bộ xử lý dự phòng sẽ tiếp quản khi mô hình chính gặp sự cố. Điều này có thể bao gồm việc thử lại cùng một mô hình, chuyển sang mô hình dự phòng hoặc trả về phản hồi đã được lưu cache.

Một chiến lược dự phòng tốt cần có nhiều cấp độ. Đầu tiên, hãy thử lại cùng một mô hình một hoặc hai lần đối với các lỗi tạm thời. Thứ hai, chuyển sang một mô hình tương đương từ nhà cung cấp khác. Thứ ba, chuyển sang một mô hình đơn giản hơn có thể xử lý yêu cầu một cách thỏa đáng. Thứ tư, trả về lỗi cho người dùng.

Cache phản hồi

Semantic cache lưu trữ các phản hồi và tái sử dụng chúng cho những truy vấn tương tự. Không giống như cache truyền thống yêu cầu khớp chuỗi chính xác, semantic cache sử dụng các embedding để tìm những truy vấn tương tự.

Khi nhận được yêu cầu, hệ thống sẽ tạo ra một embedding và tìm kiếm các mục đã được lưu cache tương tự. Nếu tìm thấy kết quả trùng khớp vượt quá ngưỡng tương đồng nhất định, nó sẽ trả về phản hồi đã được lưu trong cache thay vì gọi mô hình. Điều này có thể giảm chi phí API từ 40-60% cho các ứng dụng có truy vấn lặp lại.

Bước 1: Chọn mô hình 

Bước đầu tiên là quyết định xem nên đưa những mô hình nào vào bộ định tuyến của bạn. Điều này phụ thuộc vào trường hợp sử dụng cụ thể, nhưng hầu hết các hệ thống đều được hưởng lợi từ việc có ít nhất ba cấp độ.

Cấp độ Fast

Cấp độ Fast xử lý các yêu cầu đơn giản, khối lượng lớn. Các mô hình này có giá từ 0,001 đến 0,002 USD cho mỗi 1.000 token và phản hồi trong vòng dưới 500ms.

Ví dụ bao gồm GPT-3.5 Turbo, Claude Instant, Llama 3 8B và Mistral 7B. Các mô hình này hoạt động tốt cho việc phân loại cơ bản, trả lời câu hỏi đơn giản, tóm tắt ngắn và điền mẫu.

Hãy cố gắng định tuyến 40-60% lưu lượng truy cập của bạn đến cấp độ này nếu có thể. Đây là nơi tiết kiệm chi phí nhiều nhất.

Cấp độ Smart

Cấp độ Smart xử lý các yêu cầu tiêu chuẩn cần khả năng suy luận tốt hơn. Các mô hình này có giá từ 0,01 đến 0,03 USD cho mỗi 1.000 token và phản hồi trong vòng 1-3 giây.

Ví dụ bao gồm GPT-4, Claude 3.5 Sonnet và Gemini Pro. Các mô hình này xử lý suy luận nhiều bước, giải thích chi tiết, tạo code và tạo nội dung.

Hầu hết các nhóm định tuyến 30-40% lưu lượng truy cập đến cấp độ này.

Cấp độ Power

Cấp độ Power xử lý các tác vụ phức tạp yêu cầu khả năng tối đa. Các mô hình này có giá từ 0,03 đến 0,10 USD cho mỗi 1.000 token và có thể mất 5-10 giây để phản hồi.

Ví dụ bao gồm GPT-4 Turbo, Claude Opus và Gemini Ultra. Các mô hình này xử lý những tác vụ nghiên cứu phức tạp, các bài toán lập trình nâng cao, phân tích chi tiết và những dự án viết sáng tạo.

Thông thường chỉ có 10-20% lưu lượng truy cập cần đến cấp độ này. Lạm dụng nó là nguồn gốc chính của chi phí không cần thiết.

Các mô hình chuyên biệt

Một số trường hợp sử dụng được hưởng lợi từ các mô hình chuyên biệt. Một trợ lý lập trình có thể bao gồm các mô hình được tối ưu hóa cho việc tạo code. Một bot dịch vụ khách hàng có thể bao gồm các mô hình được đào tạo trên những phiếu hỗ trợ.

Các mô hình này lấp đầy những khoảng trống cụ thể trong danh mục mô hình của bạn. Chúng thường là các mô hình mã nguồn mở mà bạn tinh chỉnh trên dữ liệu của mình.

Bước 2: Định nghĩa quy tắc định tuyến

Sau khi có mô hình, hãy định nghĩa các quy tắc để xác định yêu cầu nào sẽ được chuyển đến đâu. Bắt đầu đơn giản và tăng độ phức tạp khi cần thiết.

Định tuyến dựa trên quy tắc

Định tuyến dựa trên quy tắc sử dụng các điều kiện rõ ràng để phân loại yêu cầu. Phương pháp này đơn giản và hoạt động tốt cho nhiều ứng dụng.

Hãy bắt đầu bằng cách xác định các mẫu rõ ràng trong lưu lượng truy cập của bạn. Nếu ứng dụng xử lý hỗ trợ khách hàng, bạn có thể định tuyến dựa trên mức độ khẩn cấp, loại câu hỏi hoặc cấp độ người dùng. Nếu xây dựng một trợ lý lập trình, bạn có thể định tuyến dựa trên ngôn ngữ lập trình hoặc độ phức tạp của tác vụ.

Ví dụ về các quy tắc:

• Nếu độ dài prompt dưới 50 từ, hãy sử dụng cấp độ Fast
• Nếu prompt chứa “giải thích” hoặc “tại sao”, hãy sử dụng cấp độ Smart
• Nếu prompt chứa “phân tích” hoặc “nghiên cứu”, hãy sử dụng cấp độ Power
• Nếu người dùng đang sử dụng gói cao cấp, hãy sử dụng cấp độ Smart tối thiểu
• Nếu yêu cầu được đánh dấu là khẩn cấp, hãy sử dụng cấp độ Power

Phương pháp này xử lý 80% nhu cầu định tuyến với 5-10 quy tắc đơn giản. Bộ định tuyến thêm độ trễ tối thiểu và dễ gỡ lỗi.

Định tuyến ngữ nghĩa

Định tuyến ngữ nghĩa sử dụng các embedding để khớp những yêu cầu với các danh mục. Mỗi danh mục tương ứng với một tầng mô hình.

Đầu tiên, hãy định nghĩa các danh mục của bạn. Đối với một bot dịch vụ khách hàng, các danh mục có thể bao gồm những câu hỏi về thanh toán, hỗ trợ kỹ thuật, quản lý tài khoản và thông tin sản phẩm. Đối với một trợ lý lập trình, các danh mục có thể bao gồm gỡ lỗi, đánh giá code, triển khai tính năng và thiết kế kiến ​​trúc.

Tiếp theo, hãy tạo các ví dụ tham khảo cho mỗi danh mục. Đây là các truy vấn điển hình đại diện cho mỗi danh mục. Tạo embedding cho các ví dụ này bằng cách sử dụng mô hình như text-embedding-ada-002 hoặc tương tự.

Khi nhận được yêu cầu, hãy tạo embedding của nó và tính toán độ tương đồng cosine với từng embedding tham chiếu. Định tuyến đến mô hình được liên kết với danh mục tương tự nhất.

Cách tiếp cận này xử lý những sắc thái tốt hơn so với các quy tắc. Nó thích ứng với cách diễn đạt mới mà không cần cập nhật thủ công. Nhược điểm là độ trễ tăng thêm cho việc tạo embedding và tính toán độ tương đồng.

Định tuyến hỗ trợ LLM

Định tuyến hỗ trợ LLM sử dụng một mô hình nhỏ để phân loại yêu cầu. Điều này mang lại tính linh hoạt cao nhất nhưng cũng làm tăng độ trễ nhiều nhất.

Mô hình phân loại nhận mỗi yêu cầu và trả về đề xuất về danh mục hoặc cấp độ. Bạn có thể sử dụng mô hình được tinh chỉnh và huấn luyện trên các danh mục cụ thể của mình hoặc sử dụng mô hình đa năng với prompt cẩn thận.

Cách tiếp cận này hoạt động tốt khi bạn có logic định tuyến phức tạp khó nắm bắt trong các quy tắc hoặc khi những danh mục của bạn thay đổi thường xuyên. Chi phí là độ trễ tăng thêm từ 500-2000ms cộng với chi phí gọi mô hình phân loại.

Các phương pháp kết hợp

Hầu hết các hệ thống sản xuất sử dụng những phương pháp kết hợp. Chúng áp dụng các quy tắc đơn giản trước, sau đó sử dụng định tuyến ngữ nghĩa hoặc dựa trên LLM cho những trường hợp ngoại lệ.

Một flow điển hình:

1. Kiểm tra độ dài prompt. Nếu dưới 50 từ, định tuyến đến cấp độ Fast
2. Kiểm tra các từ khóa cụ thể. Nếu tìm thấy, định tuyến tương ứng
3. Nếu không có quy tắc nào khớp, tạo embedding và sử dụng định tuyến ngữ nghĩa
4. Nếu độ tin cậy thấp, mặc định chuyển sang cấp độ Smart

Cách tiếp cận này kết hợp tốc độ của các quy tắc với tính linh hoạt của định tuyến ngữ nghĩa.

Bước 3: Thực hiện kiểm soát chi phí

Định tuyến giúp giảm chi phí, nhưng bạn vẫn cần các biện pháp kiểm soát để tránh những hóa đơn bất ngờ.

Theo dõi ngân sách

Theo dõi chi phí ở nhiều cấp độ. Giám sát tổng chi tiêu trên tất cả các mô hình, chi phí trên mỗi mô hình, chi phí trên mỗi người dùng hoặc nhóm và chi phí trên mỗi loại yêu cầu.

Khả năng hiển thị này giúp bạn xác định các mô hình tốn kém. Có thể một người dùng gửi các truy vấn đặc biệt phức tạp. Có thể một loại yêu cầu liên tục được định tuyến đến các mô hình đắt tiền trong khi một tùy chọn rẻ hơn có thể hoạt động.

Giới hạn tỷ lệ

Thực hiện giới hạn tỷ lệ cho các mô hình đắt tiền. Nếu người dùng hoặc nhóm đạt đến giới hạn của họ, hãy định tuyến các yêu cầu tiếp theo đến những mô hình rẻ hơn hoặc trả về lỗi.

Điều này ngăn chặn chi phí tăng vọt do lỗi hoặc lạm dụng. Giới hạn tỷ lệ cũng khuyến khích người dùng tối ưu hóa các prompt của họ.

Định tuyến có tính đến chi phí

Một số quyết định định tuyến nên xem xét chi phí một cách rõ ràng. Nếu hai mô hình có thể xử lý một yêu cầu tốt như nhau, hãy định tuyến đến mô hình rẻ hơn.

Điều này đặc biệt hữu ích trong thời gian sử dụng cao điểm. Khi chi phí API tăng vọt do nhu cầu cao, bộ định tuyến có thể chuyển lưu lượng truy cập sang các nhà cung cấp hoặc mô hình thay thế.

Bước 4: Thiết lập chuỗi dự phòng

Lỗi mô hình là điều không thể tránh khỏi. Hệ thống định tuyến của bạn cần xử lý chúng một cách khéo léo.

Mô hình chính và mô hình dự phòng

Đối với mỗi tầng, hãy xác định một mô hình chính và ít nhất một mô hình dự phòng. Khi mô hình chính gặp sự cố, bộ định tuyến sẽ thử mô hình dự phòng.

Chọn các mô hình dự phòng có khả năng tương tự. Nếu mô hình cấp độ Smart chính của bạn là GPT-4, mô hình dự phòng có thể là Claude 3.5 Sonnet. Nếu mô hình cấp độ Fast chính của bạn là GPT-3.5, mô hình dự phòng có thể là Llama 3.

Logic thử lại

Không phải tất cả các sự cố đều yêu cầu chuyển đổi mô hình. Các lỗi mạng tạm thời, giới hạn tốc độ tạm thời và sự cố dịch vụ ngắn thường được giải quyết nhanh chóng.

Thực hiện lùi thời gian theo cấp số nhân cho các lần thử lại. Hãy thử ngay một lần, sau đó đợi 1 giây và thử lại, rồi đợi 2 giây, rồi 4 giây. Sau 3-4 lần thử lại, hãy bỏ cuộc và thử với mô hình dự phòng.

Circuit breaker

Circuit breaker ngăn bộ định tuyến liên tục gọi đến một mô hình bị lỗi. Nếu một mô hình trả về lỗi trên 50% số yêu cầu trong vòng 1 phút, Circuit breaker sẽ mở. Bộ định tuyến ngừng gửi lưu lượng truy cập đến mô hình đó và sử dụng mô hình dự phòng thay thế.

Sau một khoảng thời gian chờ, Circuit breaker chuyển sang trạng thái bán mở. Nó gửi một tỷ lệ nhỏ lưu lượng truy cập đến mô hình bị lỗi trước đó. Nếu các yêu cầu đó thành công, Circuit breaker sẽ đóng lại và định tuyến bình thường được tiếp tục. Nếu chúng thất bại, Circuit breaker sẽ mở lại.

Mô hình này ngăn chặn tình trạng "bão" thử lại và cho phép các dịch vụ bị lỗi có thời gian phục hồi.

Chế độ suy giảm

Khi nhiều mô hình bị lỗi, hệ thống sẽ chuyển sang chế độ suy giảm. Điều này có thể có nghĩa là định tuyến tất cả lưu lượng truy cập đến mô hình hoạt động cuối cùng, chỉ phục vụ các phản hồi được lưu cache hoặc trả về lỗi cho người dùng.

Hãy xác định trước hành vi của chế độ suy giảm. Người dùng thích phản hồi chậm hơn là không có phản hồi.

Bước 5: Thêm khả năng quan sát

Bạn không thể tối ưu hóa những gì bạn không đo lường. Khả năng quan sát toàn diện là điều cần thiết cho một hệ thống định tuyến sản xuất.

Số liệu yêu cầu

Theo dõi số liệu cho mỗi yêu cầu. Ghi lại mô hình nào đã xử lý yêu cầu đó, thời gian thực hiện, chi phí, liệu yêu cầu có thành công hay không và phản hồi của người dùng.

Các số liệu chính bao gồm:

• Số yêu cầu mỗi giây theo mô hình
• Độ trễ trung bình theo mô hình và cấp độ
• Tỷ lệ lỗi theo mô hình
• Chi phí mỗi yêu cầu
• Số lượng token sử dụng theo mô hình
• Tỷ lệ truy cập cache
• Tần suất sử dụng phương án dự phòng

Số liệu chất lượng

Các quyết định định tuyến ảnh hưởng đến chất lượng đầu ra. Một yêu cầu được định tuyến đến mô hình rẻ hơn có thể tạo ra phản hồi kém hơn.

Theo dõi các số liệu chất lượng nếu có thể. Đối với dịch vụ khách hàng, hãy theo dõi tỷ lệ giải quyết vấn đề và điểm số hài lòng của khách hàng. Đối với trợ lý lập trình, hãy theo dõi xem code được tạo ra có biên dịch và vượt qua các bài kiểm tra hay không. Đối với việc tạo nội dung, hãy theo dõi các chỉnh sửa của người dùng và các yêu cầu tạo lại.

Những số liệu này giúp bạn điều chỉnh các quy tắc định tuyến. Nếu bạn nhận thấy rằng định tuyến ngữ nghĩa gửi quá nhiều yêu cầu đến cấp độ Fast và chất lượng bị ảnh hưởng, hãy điều chỉnh ngưỡng tương đồng của bạn.

Dashboard và cảnh báo

Xây dựng dashboard hiển thị hiệu suất định tuyến một cách nhanh chóng. Hiển thị khối lượng yêu cầu hiện tại theo cấp độ, độ trễ trung bình, tỷ lệ lỗi, xu hướng chi phí và tỷ lệ truy cập cache.

Thiết lập cảnh báo cho các bất thường. Cảnh báo khi tỷ lệ lỗi vượt quá 5%, khi độ trễ trung bình tăng gấp đôi, khi chi phí hàng ngày vượt quá ngân sách hoặc khi tỷ lệ truy cập cache giảm xuống dưới mức cơ bản.

Bước 6: Triển khai semantic cache

Semantic cache có thể loại bỏ 40-60% số lượng gọi API LLM cho các ứng dụng có truy vấn lặp lại.

Tạo embedding

Khi nhận được yêu cầu, hãy tạo một embedding nắm bắt ý nghĩa ngữ nghĩa của nó. Sử dụng một mô hình như text-embedding-ada-002 hoặc một giải pháp thay thế mã nguồn mở như sentence-transformers.

Lưu trữ embedding này cùng với văn bản yêu cầu và phản hồi trong cơ sở dữ liệu vector. Các tùy chọn bao gồm Pinecone, Weaviate, Qdrant hoặc pg_vector cho PostgreSQL.

Tìm kiếm sự tương đồng

Trước khi định tuyến yêu cầu đến một mô hình, hãy tìm kiếm trong cache các truy vấn tương tự. Tính toán độ tương đồng cosine giữa embedding của yêu cầu mới và các embedding đã được lưu cache.

Nếu bạn tìm thấy một kết quả trùng khớp vượt quá ngưỡng của mình, hãy trả về phản hồi đã được lưu cache. Nếu không, hãy định tuyến yêu cầu như bình thường và lưu kết quả vào cache.

Chọn ngưỡng

Ngưỡng tương đồng xác định mức độ tương đồng của một mục đã lưu cache để được tính là một kết quả phù hợp. Ngưỡng cao hơn có nghĩa là ít kết quả giả hơn nhưng cũng ít kết quả khớp với cache hơn.

Bắt đầu với ngưỡng 0,95. Ngưỡng này chỉ khớp với các truy vấn rất giống nhau. Theo dõi tỷ lệ khớp với cache và tỷ lệ dương tính giả. Điều chỉnh ngưỡng dựa trên yêu cầu chất lượng của bạn.

Các trường hợp sử dụng khác nhau cần những ngưỡng khác nhau. Các truy vấn dịch vụ khách hàng có thể chấp nhận ngưỡng thấp hơn vì sự khác biệt về cách diễn đạt hiếm khi làm thay đổi câu trả lời. Việc tạo code cần ngưỡng cao hơn vì những thay đổi nhỏ trong yêu cầu rất quan trọng.

Vô hiệu hóa cache

Các phản hồi được lưu cache cuối cùng sẽ trở nên lỗi thời. Hãy triển khai các chính sách hết hạn dựa trên nhu cầu của bạn.

Hết hạn theo thời gian sẽ xóa các mục trong cache sau một khoảng thời gian nhất định. Điều này hoạt động tốt cho nội dung động như tin tức hoặc thông tin giá cả.

Vô hiệu hóa dựa trên sự kiện sẽ xóa các mục trong cache khi dữ liệu cơ bản thay đổi. Nếu hệ thống của bạn cập nhật danh mục sản phẩm, hãy vô hiệu hóa các phản hồi được lưu cache về những sản phẩm đó.

Loại bỏ theo thuật toán LRU (Least Recently Used) sẽ xóa các mục được sử dụng ít nhất gần đây khi cache đạt đến dung lượng tối đa. Điều này giúp cache tập trung vào các truy vấn hiện tại.