Together AI công bố lộ trình chuyển đổi từ mô hình đóng sang mô hình mở

May mắn thay, việc chuyển đổi từ mô hình đóng (closed source) sang mô hình mở (open source) đã phá vỡ truyền thống di chuyển chậm chạp và đầy đau đớn, đặc biệt là nếu bạn sử dụng dịch vụ được quản lý (managed service). Các dịch vụ này luôn bắt kịp tốc độ đổi mới của AI, đồng thời giảm bớt phần lớn sự phức tạp cho doanh nghiệp của bạn.

Giờ đây, phạm vi ảnh hưởng (blast radius) đã nhỏ hơn nhiều và ngăn xếp kỹ thuật (technical stack) cần di chuyển cũng bớt phức tạp hơn. Các bộ khung (harnesses), cổng kết nối (gateways) và công cụ đều được xây dựng để tương thích với nhiều loại mô hình khác nhau. Bạn có thể tận dụng tối đa điều này để thực hiện quá trình chuyển đổi nhanh chóng và toàn diện từ mô hình đóng sang mô hình mở.

Chúng tôi sẽ hướng dẫn bạn chiến lược di chuyển thành công mà chúng tôi đã đúc kết từ khách hàng của mình. Quá trình này có thể chỉ mất vài tuần đến vài tháng thay vì vài tháng đến vài năm. Trong tương lai, chúng tôi cũng sẽ cung cấp các tài nguyên để giúp bạn theo dõi tiến độ của mình trong suốt chặng đường.

Khám phá (Discover)

Khi bắt đầu tìm kiếm các mô hình ứng viên, điều quan trọng nhất là phải biết bạn đang đánh giá dựa trên tiêu chí nào. Không có mô hình nào là tốt nhất trong mọi trường hợp. Các mô hình khác nhau có thế mạnh khác nhau trên từng lĩnh vực, và bạn càng xác định rõ các vấn đề cần giải quyết, việc rút gọn danh sách các mô hình thực sự phù hợp với bạn càng trở nên dễ dàng hơn. Hãy bắt đầu bằng việc xác định trường hợp sử dụng (use-case) và khối lượng công việc (workload) bằng ngôn ngữ đơn giản: mô hình xử lý những tác vụ gì, phản hồi như thế nào là tốt và lưu lượng truy cập của bạn thực tế bao gồm những gì.

Với trường hợp sử dụng đã được xác định, các bộ tiêu chuẩn đánh giá (benchmarks) có sẵn sẽ trở thành công cụ lọc hữu ích. Hãy xác định các bộ tiêu chuẩn phù hợp nhất với công việc của bạn để các con số trên bảng xếp hạng (leaderboard) tương quan với hiệu suất thực tế trong các tác vụ của bạn. Các nguồn benchmark uy tín bao gồm The Open Frontier, Artificial Analysis, Epoch AI, Vals AI, các bảng xếp hạng của Scale, Intelligence và Arena. Trong đó, bạn có thể thấy các bộ benchmark sau đây rất hữu ích:

Hãy nhớ rằng, nhiệm vụ của bạn là xác định xem những tiêu chuẩn nào phù hợp để thu hẹp danh sách các mô hình ứng viên; chúng ta sẽ thảo luận sâu hơn về các bài đánh giá tùy chỉnh (custom evals) sau. Thông thường, bạn sẽ thấy có ba cấp độ mô hình để lựa chọn, như đã hiển thị ở trên.

Đối với các ứng viên hàng đầu, hãy nhìn xa hơn hiệu suất thô. Hãy xem xét chi phí trên mỗi tác vụ, số lượng token mà mô hình tiêu tốn cho mỗi lần thử, số bước cần thiết, thời gian chạy từ đầu đến cuối (end-to-end runtime) và tốc độ bạn có thể xác minh một câu trả lời đúng. Nhiều bộ benchmark mới hiện đang báo cáo các con số theo từng tác vụ này và chúng tôi tin rằng chúng tương quan tốt hơn với chi phí và hiệu suất thực tế của mô hình. Một mô hình có điểm số thấp hơn một chút nhưng hoàn thành tác vụ với lượng token ít hơn một nửa và thời gian nhanh hơn một nửa có thể là lựa chọn phù hợp hơn.

Cuối cùng, hãy "thử nghiệm thực tế" (kick the tires). Hãy đưa một vài tác vụ tiêu biểu vào môi trường thử nghiệm (playground) và xem các mô hình trong danh sách rút gọn của bạn có hoạt động như mong đợi hay không. Hãy chú ý đến các chế độ lỗi (failure modes) và tự hỏi liệu đó là do mô hình thất bại hay do bộ khung và ngữ cảnh xung quanh nó. Cũng rất đáng để xem các công ty khác đang sử dụng những mô hình này nói gì về trải nghiệm của họ. Bạn nên kết thúc bước này với hai đến ba mô hình sẵn sàng để đưa vào các bài đánh giá nghiêm túc.

Đánh giá (Evaluate)

Đánh giá mô hình sẽ là phần tốn nhiều công sức nhất trong quy trình này và chắc chắn cần một bài blog riêng, nhưng ở cấp độ tổng quan, bạn sẽ đánh giá hai yếu tố: độ chính xác (accuracy) và hiệu suất (performance).

Độ chính xác xác định khả năng của mô hình. Điều này có thể bao gồm khả năng tuân thủ hướng dẫn (instruction following), tóm tắt, gọi hàm (function calling), hiệu suất thị giác (vision performance), v.v. Đây là tất cả những gì mô hình có thể làm bất kể nó chạy ở đâu hay nhanh như thế nào. Bạn cần đánh giá xem nó có giải quyết được nhu cầu công việc của bạn hay không.

Hiệu suất bao gồm việc mô hình chạy tốt như thế nào. Điều này thay đổi dựa trên các yếu tố như kích thước và kiến trúc mô hình. Đối với các bài kiểm tra này, chúng ta không quan tâm mô hình phản hồi tốt đến mức nào. Chúng ta đang đánh giá xem mô hình này có đáp ứng được chi phí và trải nghiệm người dùng, hay độ trễ (latency), theo kỳ vọng để áp dụng một mô hình nguồn mở (OSM) hay không.

Đối với cả độ chính xác và hiệu suất, bạn cần có một tư duy nhất quán: các bộ benchmark chỉ mang tính định hướng, các bài kiểm tra thực sự phải được thực hiện với dữ liệu thực. Cách tốt nhất để đánh giá khối lượng công việc không phải là tra cứu hoặc chạy các benchmark chung chung. Các khối lượng công việc có hình thái lưu lượng, yêu cầu phản hồi đặc thù và cấu trúc yêu cầu khác nhau. Không có benchmark nào có thể đại diện cho điều đó ngoại trừ chính dữ liệu của bạn. May mắn thay, nếu bạn đang sử dụng các mô hình đóng, việc phát lại (replay) lưu lượng truy cập hiện có là tất cả dữ liệu bạn cần để làm benchmark. Không cần bộ công cụ tùy chỉnh, không cần tập dữ liệu lớn. Đây là, và luôn là, cách tốt nhất để đo lường ngay cả trước khi chúng ta có các benchmark cho các mô hình hiện đại (HPC, cơ sở dữ liệu, cân bằng tải, v.v.). Tuy nhiên, hãy đảm bảo rằng bạn vẫn đang kiểm tra dựa trên các mục tiêu đã xác định trước đó.

Nếu bạn không có dữ liệu để phát lại, bạn cũng không bị chặn! Chúng ta vẫn có thể định cỡ dựa trên các mô hình sử dụng chung như kích thước đầu vào/đầu ra và tỷ lệ trúng bộ nhớ đệm (cache hit rate) dự kiến. Nếu các nhà cung cấp mô hình đóng không cung cấp các số liệu này, các cổng kết nối như LiteLLM có thể giúp thu thập thông tin đó. Chúng tôi sẽ thảo luận kỹ hơn về kỹ thuật này trong một bài blog chuyên sâu.

Sau khi đã tìm thấy dữ liệu: hãy xác định mục tiêu của bạn là gì. Bạn muốn tiết kiệm chi phí? Tốc độ? Chất lượng cải thiện hay tương đương? Khi bạn chạy lại dữ liệu của mình trên các mô hình mới đã chọn, đây chính là vạch đích của bạn. Bạn đang nhắm đến việc đạt được hoặc vượt qua mức này. Khi các OSM vượt qua vạch đích này, bạn đã có sự xác nhận về mặt kỹ thuật và có thể tiến hành di chuyển toàn diện.

Đầu tư vào các kỹ thuật đánh giá mạnh mẽ sẽ giúp đội ngũ của bạn nhanh chóng áp dụng các OSM mới một cách dễ dàng trong tương lai. Trong một bài blog tiếp theo, chúng tôi sẽ đi sâu hơn vào cách định cỡ khối lượng công việc, chạy lại lưu lượng truy cập và đánh giá kết quả. Hiện tại, đây là khái niệm nền tảng về cách đánh giá một OSM.

Thích ứng (Adapt)

Các mô hình mở tiên tiến đang ngày càng tốt hơn đến mức chúng thường hoạt động ngay lập tức (out of the box) cho hầu hết các ứng dụng, nhưng nếu một mô hình không vượt qua các bài đánh giá của bạn, bạn sẽ cần phải thích ứng. Điều đó không nhất thiết có nghĩa là mô hình đó là ngõ cụt. Nó thường có nghĩa là cách bạn đang sử dụng nó đã được tinh chỉnh cho một mô hình khác: lời nhắc (prompt), các tham số lấy mẫu (sampling parameters), bộ khung xung quanh nó. Thiết lập mô hình đóng của bạn mang theo rất nhiều sự tinh chỉnh tích lũy mà mô hình nguồn mở chưa từng thấy, và rất có thể bạn sẽ cần phải điều chỉnh nó.

Bạn có một vài đòn bẩy ở đây, sắp xếp theo thứ tự nỗ lực từ thấp đến cao:

Dù bạn sử dụng đòn bẩy nào, hãy coi quá trình này là một vòng lặp lặp đi lặp lại. Thiết lập các thí nghiệm cô lập một thay đổi duy nhất, đánh giá tác động của nó và lặp lại cho đến khi bạn tìm thấy những thứ thực sự cải thiện kết quả đánh giá. Hãy giữ cho các bài đánh giá của bạn ở dạng mô-đun và các thí nghiệm đơn giản. Nếu bạn kiểm tra quá nhiều thứ và thay đổi quá nhiều biến cùng một lúc, bạn sẽ không bao giờ cô lập được yếu tố nào đang thực sự hiệu quả giữa những nhiễu loạn. Một bộ các bài đánh giá được xác định rõ ràng, như đã thảo luận ở trên, là điều quan trọng nhất để lặp lại các bước thích ứng một cách hiệu quả.

Quyết định (Decide)

Xác nhận kỹ thuật chỉ là một nửa chặng đường, như với bất kỳ cuộc di chuyển nào. Khi bạn đã chứng minh được các OSM có thể sánh ngang hoặc vượt qua chức năng của dịch vụ mô hình đóng hiện tại, bạn cần đóng gói các kết quả này và truyền đạt "lý do" cho các bên liên quan.

Hãy phác thảo nỗ lực cần thiết để di chuyển sang OSM, các rủi ro là gì và tỷ suất hoàn vốn (ROI) ra sao.

Một số hướng dẫn cấp cao từ kinh nghiệm của chúng tôi:

Nỗ lực sẽ xác định khối lượng công việc thực tế cần thiết để chuyển đổi sang OSM. Đôi khi có những lo ngại về tính tương thích đối với các bộ khung và công cụ, nhưng khoảng cách này đang thu hẹp lại mỗi ngày. Ví dụ, togetherlink, một công cụ chúng tôi cung cấp, giúp việc bắt đầu sử dụng OSM trong bất kỳ bộ khung nào trở nên đơn giản như một lần cài đặt. Hãy ghi lại bất kỳ tích hợp hoặc thay đổi nào cần thực hiện để sử dụng OSM ở quy mô lớn.

Rủi ro phản ánh các rủi ro truyền thống liên quan đến việc áp dụng công nghệ mới: tuân thủ, quy mô, quá trình di chuyển liên tục, sự quen thuộc với công cụ, ảnh hưởng đến các dịch vụ hạ nguồn (downstream services). Hãy ghi lại những điều này và giải quyết chúng theo nhu cầu cụ thể của công ty bạn. Phần lớn các rủi ro này được giải quyết bởi các nhà cung cấp dịch vụ được quản lý nếu bạn chọn sử dụng một đơn vị như vậy.

ROI có thể được tính toán như một giá trị định lượng từ giai đoạn đánh giá của bạn. Bạn có thể tạo bao nhiêu token trên mỗi đô la? So sánh với mô hình đóng thì sao? Chúng tôi thấy trong một số trường hợp, chi phí giảm tới 70% khi khách hàng chuyển sang nguồn mở. Bạn cũng có thể làm điều này cho chất lượng: chất lượng so với mô hình đóng như thế nào? Điều này sẽ giúp xác định ROI của bạn với các bên liên quan.

Lý tưởng nhất là khi các rủi ro, nỗ lực và ROI đã được xác định, quyết định sẽ trở nên dễ dàng hơn. Việc áp dụng tại thời điểm này thiên về giáo dục hơn là các rào cản kỹ thuật.

Sản xuất (Production)

Tại thời điểm phê duyệt, quá trình di chuyển bắt đầu. Như đã đề cập, theo truyền thống, việc chuyển sang môi trường sản xuất sau khi di chuyển là một quá trình dài và mệt mỏi. Tuy nhiên, với việc chuyển đổi từ mô hình đóng sang OSM, chúng tôi thấy đây thực sự là một trong những bước nhẹ nhàng nhất.

Chúng ta có thể học hỏi từ các phương pháp di chuyển truyền thống để kiểm kê tác động của việc di chuyển và tạo lộ trình. Chúng ta có thể dựa phần lớn vào các phần nỗ lực và rủi ro từ trước đó. Liệu chúng ta có ảnh hưởng đến các dịch vụ hạ nguồn không? Làm thế nào để một mô hình được các nhóm bảo mật và tuân thủ phê duyệt? Có thay đổi nào cần thiết đối với công cụ hoặc dịch vụ được xây dựng trên các mô hình trước đó không? Sự thay đổi này cũng không cần phải diễn ra ngay lập tức. Các đợt triển khai thử nghiệm (canary deployments) đã đạt được thành công lớn với khách hàng của chúng tôi để xác thực dựa trên các trường hợp sử dụng thực tế, bắt đầu với 10% lưu lượng truy cập sang nguồn mở.

Một lộ trình bao gồm tất cả các bước cần thiết cho việc áp dụng OSM của bạn. Điều này nên bao gồm bất kỳ thay đổi nào về bảo mật/tuân thủ, công nghệ hoặc dịch vụ hạ nguồn cần thực hiện. Đừng cảm thấy bị đe dọa, việc triển khai kỹ thuật có thể đơn giản như việc thay đổi một điểm cuối (endpoint)!

Chúng tôi hiểu rằng đây là một cái nhìn tổng quan rất đơn giản, nhưng về cốt lõi, chúng tôi đã chứng kiến quá trình chuyển đổi này hàng chục lần với các khách hàng lớn nhất của mình và tin tưởng mạnh mẽ rằng nó ít rườm rà hơn nhiều so với một cuộc di chuyển kỹ thuật truyền thống.

Nếu bạn đang trải qua một quá trình di chuyển tương tự, chúng tôi khuyến khích bạn theo dõi các bài blog trong tương lai hoặc liên hệ với [email protected] nếu có bất kỳ câu hỏi nào. Và chúng tôi rất mong nhận được phản hồi về những gì có thể còn thiếu ở đây. Chúc bạn xây dựng thành công!