Các vấn đề về phiên bản chưa được nhìn thấy ảnh hưởng đến hiệu suất suy luận AI

Mô hình đã không hồi quy. Bạn đã không gửi một lỗi. Nền tảng đã thay đổi nó.

Các ứng dụng AI sản xuất của bạn phụ thuộc vào một thứ mà hầu hết các nhóm không nhận ra rằng họ đã chuyển giao quyền kiểm soát:hành vi của mô hình đằng sau điểm cuối của họ. Thực tế là mô hình không phải là một sản phẩm cố định. Đó là một mục tiêu di động. Để duy trì tính cạnh tranh, các nền tảng liên tục cập nhật trọng số, hoán đổi mức lượng tử hóa, nâng cấp công cụ suy luận, định tuyến lại lưu lượng truy cập trên phần cứng và đôi khi thay thế hoàn toàn mô hình - mà không thay đổi tên điểm cuối.

Khi điều đó xảy ra, ứng dụng của bạn sẽ thay đổi theo nó. Đầu ra thay đổi. Lời nhắc ngừng hoạt động. Hành vi được điều chỉnh cẩn thận sẽ suy giảm. Và bạn thường không tìm hiểu từ nhật ký thay đổi:bạn tìm hiểu từ người dùng.

Đây là rủi ro tiềm ẩn của cơ sở hạ tầng AI hiện đại:bạn đang xây dựng trên một hệ thống có thể thay đổi bên dưới bạn bất cứ lúc nào mà không có gì đảm bảo rằng “mô hình tương tự” ngày mai cũng chính là mô hình bạn đã thử nghiệm hôm nay. Bài viết này tìm hiểu xem thực tế điều đó trông như thế nào, tại sao nó lại xảy ra và tại sao hầu như không có nền tảng nào giải quyết tốt vấn đề đó - cũng như những gì các nhóm đang làm để đối phó với vấn đề đó.

Mẫu bạn gửi kèm không phải là mẫu bạn đang chạy.

Bài học chính

• “Lập phiên bản mô hình” chưa hoàn thiện về mặt thiết kế:Những gì trông giống như một mô hình thực chất là một tập hợp các bộ phận chuyển động - trọng lượng, công cụ suy luận, phần cứng, định tuyến và lan can - tất cả đều có thể thay đổi độc lập mà không cần thay đổi tên điểm cuối.
• Những thay đổi thầm lặng tạo ra rủi ro sản xuất thực sự:Những cập nhật này phá vỡ khả năng tái tạo, vô hiệu hóa việc điều chỉnh kịp thời và đưa ra các hồi quy mà các nhóm thường chỉ phát hiện sau khi người dùng bị ảnh hưởng - chứ không phải thông qua khả năng hiển thị hoặc giám sát nền tảng.
• Khoảng cách không nằm ở vấn đề kỹ thuật - mà là tính minh bạch và quyền sở hữu:Các nền tảng đã theo dõi nội bộ những thay đổi này nhưng không tiết lộ chúng; khi AI trở nên quan trọng trong sản xuất thì việc đảm bảo phiên bản toàn bộ ngăn xếp, nhật ký thay đổi và khả năng tái tạo sẽ trở thành tiêu chí chính trong việc lựa chọn nền tảng.

Hình dạng của vấn đề phiên bản

Thực ra “cùng một mô hình” có nghĩa là gì

Điểm cuối của mô hình không phải là một tạo phẩm bất biến duy nhất. Đó là cấu hình của:

• Các trọng số của mô hình cơ bản (có thể bản thân chúng đã được lượng tử hóa, cắt bớt hoặc chắt lọc từ bản gốc)
• Công cụ suy luận chạy chúng (cho dù đó là vLLM, TensorRT-LLM, SGLang hay công cụ độc quyền - mỗi công cụ tạo ra kết quả đầu ra hơi khác nhau)
• Việc tạo GPU và bố cục bộ nhớ
• Phiên bản mã thông báo và mọi mẫu trò chuyện được áp dụng
• Lời nhắc hệ thống mà nền tảng có thể đưa vào mà bạn không bao giờ thấy
• Lớp an toàn, điều độ hoặc lớp lan can phía trước mô hình
• Logic định tuyến quyết định bản sao hoặc khu vực nào xử lý yêu cầu của bạn

Bất kỳ điều nào trong số này có thể thay đổi mà không thay đổi tên model. Điều quan trọng cần nhận ra là hầu hết chúng đều thay đổi thường xuyên trong suốt vòng đời của một ứng dụng sản xuất. Sự thay đổi này là cần thiết cho sự phát triển của các sản phẩm AI vì công nghệ cơ bản thường được cải thiện sau mỗi thay đổi. Sự thay đổi ngày càng tăng này là một phần cốt lõi của ngành Phần mềm AI.

Ba loại thay đổi thầm lặng

Danh mục đầu tiên là các bản cập nhật phiên bản rõ ràng trong đó nền tảng thay đổi theo trọng số của điểm cuối. Ví dụ:“GPT-4” đã có nhiều mô hình khác nhau theo thời gian và điểm cuối Claude được cập nhật thường xuyên. Điểm cuối của mô hình nguồn mở trên nền tảng được lưu trữ thường tự động theo dõi các bản phát hành ngược dòng.

Loại thứ hai là những thay đổi ở cấp độ cơ sở hạ tầng trong đó trọng số giữ nguyên nhưng có thứ gì đó trong ngăn xếp phân phát sẽ thay đổi. Một số ví dụ về điều này bao gồm khi:

• Công cụ suy luận được nâng cấp
• Mức độ lượng tử hóa thay đổi vì lý do chi phí
• Các quyết định định tuyến sẽ chuyển lưu lượng truy cập giữa các hoạt động triển khai khác nhau lẽ ra là tương đương nhưng thực tế lại không như vậy.

Danh mục thứ ba là những thay đổi về hành vi từ các bổ sung cấp nền tảng:lớp kiểm duyệt mới, lời nhắc hệ thống đã thay đổi, bộ lọc an toàn bổ sung hoặc mẫu trò chuyện đã sửa đổi. Trong những trường hợp này, mô hình giống nhau nhưng những gì mô hình nhận được và những gì người dùng nhận được lại khác nhau.

Mỗi danh mục thực sự ảnh hưởng như thế nào đến hành vi của người mẫu

Bài toán hồi quy thầm lặng

Hồi quy thầm lặng là sự suy giảm chất lượng đầu ra của mô hình do một thay đổi ở đâu đó trong ngăn xếp phân phối chưa bao giờ được công bố, chưa bao giờ được ghi lại và không bao giờ bị ràng buộc với một bản nâng cấp phiên bản. Tên model ở điểm cuối giống nhau. Hợp đồng API cũng vậy. Yêu cầu bạn gửi có byte giống hệt với yêu cầu bạn đã gửi vào tháng trước. Tuy nhiên, chất lượng phản hồi đã giảm - đôi khi rất tinh tế, đôi khi rất rõ ràng - và không có thông tin nào trên bề mặt công khai của nền tảng cho bạn biết lý do.

Cơ chế này hầu như luôn là một trong ba loại thay đổi so với trước đó:trọng số được cập nhật một cách lặng lẽ, nội dung nào đó trong cơ sở hạ tầng đã thay đổi hoặc lớp cấp nền tảng (lan can bảo vệ mới, lời nhắc hệ thống được sửa đổi, bộ lọc kiểm duyệt được thắt chặt) đã được thêm vào hoặc thay đổi. Nhìn từ bên ngoài, cả ba đều trông giống hệt nhau - kết quả đầu ra của bạn trở nên kém hơn và nền tảng không cho bạn biết. Từ bên trong, chúng là những nguyên nhân cốt lõi khác nhau với các cách khắc phục khác nhau và bạn không có cách nào để phân biệt chúng nếu không có sự hợp tác của nền tảng.

Điều làm cho hồi quy thầm lặng khác biệt với sự trôi dạt của mô hình thông thường là sự bất cân xứng của thông tin. Nền tảng biết những gì đã thay đổi. Bạn không. Và vì hoạt động giám sát của bạn gần như chắc chắn là đo lường thời gian hoạt động, độ trễ và tỷ lệ lỗi thay vì chất lượng đầu ra trên tập dữ liệu vàng nên hồi quy sẽ truyền đến người dùng của bạn trước khi nó hiển thị trên bất kỳ trang tổng quan nào mà bạn sở hữu. Vào thời điểm bạn xác nhận hồi quy là có thật, tách nó ra khỏi mô hình chứ không phải mã của riêng bạn và mở một phiếu hỗ trợ, nền tảng thường đã chuyển sang thay đổi im lặng tiếp theo. Cuối cùng, bạn gỡ lỗi một mục tiêu đang di chuyển với một nửa thông tin, trong khi người dùng của bạn phải gánh chịu cái giá phải trả cho một quyết định được đưa ra ở đâu đó ngược dòng mà bạn chưa bao giờ được thông báo.

Đây là vấn đề tồi tệ nhất trong bốn vấn đề ở phần này vì đây là vấn đề duy nhất mà nền tảng chứa thông tin có thể giải quyết vấn đề ngay lập tức và chọn không chia sẻ nó. Thất bại trong khả năng tái tạo, nợ nhanh chóng và sự trôi dạt từ đánh giá đến sản phẩm là tất cả các triệu chứng mà nhóm ít nhất có thể tự chẩn đoán. Hồi quy thầm lặng là nơi công cụ chẩn đoán bạn cần nằm ở phía bên kia của API.

Vấn đề về khả năng tái hiện

Mặc dù các mô hình GPT, như một ví dụ điển hình về loại triển khai AI phổ biến, về bản chất là mang tính xác suất, nhưng bạn vẫn có thể mong đợi nhận được câu trả lời tương tự khi sử dụng cùng một mô hình với cùng một lời nhắc. Tuy nhiên, khi bất kỳ thay đổi nào được mô tả trước đó xảy ra, kết quả bạn nhận được ngày hôm qua có thể không thể tái tạo được vào ngày hôm nay. Đây là mấu chốt của vấn đề về khả năng tái tạo:mọi kỳ vọng về cách thức hoạt động của một mô hình đều có thể bị vô hiệu bởi bất kỳ thay đổi nào trong số này.

Đối với các ứng dụng thực hiện đánh giá tự động hoặc so sánh các phiên bản mô hình với nhau, điều này phá vỡ giả định cơ bản rằng các đầu vào giống nhau tạo ra các đầu ra giống hệt nhau (hoặc tương tự, trong trường hợp mô hình xác suất) cho cùng một hạt giống. Nhiệt độ bằng 0 không thực sự mang lại cho bạn tính quyết định khi ngăn xếp cơ bản đang dịch chuyển theo bạn. Vấn đề nợ kỹ thuật nhanh chóng

Các nhóm thường dành hàng tuần để điều chỉnh các lời nhắc về đặc điểm riêng của một mô hình cụ thể và tối ưu hóa chúng để đáp ứng tốt hơn nhu cầu của người dùng. Khi mô hình đó được hoán đổi hoặc cập nhật một cách âm thầm, tất cả công việc điều chỉnh đó sẽ trở thành nợ một phần. Khi các lời nhắc được xây dựng cẩn thận để xử lý các chế độ lỗi của một mô hình giờ gặp phải một mô hình hơi khác với các chế độ lỗi hơi khác, hành vi cuối cùng mà người dùng của bạn gặp phải sẽ thay đổi.

Vấn đề trôi dạt từ đánh giá đến sản xuất

Đây là một tình huống phổ biến khác:bạn đánh giá một phiên bản mô hình dựa trên bộ thử nghiệm của mình và sau đó chuyển nó sang phiên bản sản xuất. Tuy nhiên, điểm cuối sản xuất không còn sử dụng mô hình mà bạn đã đánh giá nữa, ngay cả khi tên trên điểm cuối giống nhau. Một lần nữa, điều này có thể có tác động đáng chú ý đến hoạt động của sản phẩm cuối cùng.

Nền tảng thực sự làm gì

Phần này sẽ hướng dẫn cách các nền tảng suy luận chính xử lý việc lập phiên bản, dựa trên tài liệu công khai và hành vi có thể quan sát được.

Phiên bản kiểu OpenAI

OpenAI ghim các ảnh chụp nhanh một cách rõ ràng (gpt-4-0613, gpt-4o-2024-08-06) và cho phép bạn nhắm mục tiêu chúng. Các điểm cuối bí danh (gpt-4, gpt-4o) trỏ đến mặc định hiện tại là gì và thay đổi theo thời gian. Các nhóm không biết cách ghim ảnh chụp nhanh sẽ nhận được bất kỳ phiên bản hiện tại nào và bí danh có thể thay đổi theo chúng.

Tuy nhiên, OpenAI đã thay đổi mô hình của họ vì nhiều lý do. Một ví dụ về điều này là Sự cố Sycophancy. GPT-4o được cho là 'quá tâng bốc hoặc dễ chịu - thường được mô tả là có tính chất nịnh nọt' và OpenAI đã đưa ra một loạt chỉnh sửa khi triển khai trước khi ngừng sử dụng mô hình này (nguồn). Việc mô hình này cuối cùng không được dùng nữa đã tạo ra nhiều làn sóng hơn khi mọi người than thở về sự mất mát của mô hình.

Điều khiến Sự cố Sycophancy mang tính hướng dẫn không phải là bản thân sự thay đổi tính cách - mà là những gì nó tiết lộ về hợp đồng điểm cuối. Các nhóm gọi gpt-4o trước, trong và sau khi triển khai hệ thống đồng bộ đều có cùng một tên điểm cuối nhưng có ý nghĩa khác nhau về các mô hình. Một bot hỗ trợ khách hàng được điều chỉnh dựa trên phiên bản tiền đồng bộ sẽ gặp phải một mô hình ấm áp hơn, dễ chịu hơn trong suốt thời gian sản xuất của nó, sau đó gặp phải hồ sơ hành vi thứ ba khi OpenAI sửa khóa học và lần thứ tư khi mô hình cuối cùng không được dùng nữa. Không có chuyển đổi nào trong số đó yêu cầu thay đổi mã ở phía khách hàng. Không ai trong số họ kích hoạt sự thay đổi phiên bản trên chuỗi điểm cuối. Lệnh gọi API hai dòng tương tự đã tạo ra bốn chế độ hành vi riêng biệt trong suốt nhiều tháng và tín hiệu duy nhất mà hầu hết các nhóm nhận được là người dùng của họ nói với họ rằng sản phẩm có cảm giác khác biệt. Cách tiếp cận của OpenAI tốt hơn hầu hết vì nó cho bạn tùy chọn sử dụng các phiên bản mô hình cũ hơn, miễn là OpenAI vẫn đang phục vụ họ. Tuy nhiên, vẫn cần lưu ý rằng việc lựa chọn là thủ công và sẽ khó thực hiện đối với những người không nghiên cứu để biết cách thay đổi mô hình sang các phiên bản cũ hơn.

Cách tiếp cận của loài người

Anthropic sử dụng số nhận dạng mô hình ngày tháng (kiểu claude-opus-4-5-20251101). Ghim hoạt động. Tuy nhiên, lớp an toàn và chèn lời nhắc của hệ thống ở cấp nền tảng phát triển độc lập với phiên bản mô hình, do đó, hai yêu cầu tới cùng một mô hình được ghim vào những ngày khác nhau có thể hoạt động khác nhau do những gì đang xảy ra xung quanh mô hình chứ không phải trong mô hình đó. Đây là một bước tiến xa về tính minh bạch nhưng việc lựa chọn mô hình cốt lõi vẫn tương tự như của OpenAI.

Một ví dụ về sự hồi quy thầm lặng từ Anthropic đã xảy ra gần đây trên Github Issue đáng chú ý, trong đó một nhà phát triển AI lớn đã chỉ ra sự “giảm sức mạnh” rõ ràng của các mô hình Claude Opus trong công việc kỹ thuật phức tạp của họ. Họ báo cáo rằng Claude đã bắt đầu phớt lờ các hướng dẫn, tuyên bố rằng "các cách sửa lỗi đơn giản nhất" là không chính xác, thực hiện ngược lại với các hoạt động được yêu cầu và họ khẳng định mô hình đã thực hiện hoàn thành theo hướng dẫn. Tất cả điều này không có sự thay đổi được báo cáo trong mô hình đang được sử dụng. Sự thay đổi thầm lặng này đã bị các nhà phát triển của Claude bác bỏ trong cùng một chủ đề, nhưng có sự đồng ý rộng rãi rằng một sự thay đổi đã diễn ra từ những người dùng khác, dựa trên phản hồi cho nhận xét.

‘Cùng một mô hình’ luôn là một khái niệm trừu tượng trong tiếp thị.

Các mô hình nguồn mở được lưu trữ

Các nền tảng lưu trữ các mô hình nguồn mở (Baseten, Fireworks, Together, DigitalOcean, Nebius Token Factory, Modal) thường đặt tên các điểm cuối theo mô hình cơ bản, chẳng hạn như “llama-3.1-70b-instruct”, mà không tiết lộ lượng tử hóa cụ thể nào, phiên bản công cụ suy luận nào hoặc cấu hình triển khai nào thực sự phục vụ yêu cầu. Đây có thể là một vấn đề lớn vì hiệu suất của mô hình sẽ khác nhau tùy theo nền tảng trong khi chúng có cùng tên. Các bản cập nhật cho bất kỳ bản cập nhật nào trong số đó thường không được thông báo khi phiên bản mô hình thay đổi. Khi nói đến các nhà cung cấp dịch vụ lưu trữ nguồn mở, người dùng có trách nhiệm thực hiện nghiên cứu về mọi thay đổi đối với việc triển khai mô hình cơ bản trong các tình huống Suy luận không có máy chủ. Trong quá trình triển khai tùy chỉnh, mọi thứ hơi khác một chút.

Triển khai tùy chỉnh

Khi bạn triển khai mô hình của riêng mình trên nền tảng như Modal hoặc Baseten, bạn sở hữu câu chuyện về phiên bản. Đây là tình huống rõ ràng nhất để tái tạo, kiểm soát quá trình sản xuất và quản lý các thay đổi mô hình cho các sản phẩm tiếp theo của bạn, nhưng điều đó có nghĩa là bạn phải tự mình gánh vác gánh nặng vận hành trong việc quản lý vòng đời mô hình. Điều quan trọng là phải cân nhắc sự cân bằng này khi mở rộng quy mô, vì thời gian mà nhà phát triển cần để quản lý các thay đổi sẽ tăng vọt.

Các nhóm đang làm gì về vấn đề này

Các phần bên dưới đề cập đến các giải pháp chung mà các nhóm đã áp dụng. Không có giải pháp nào trong số đó giải quyết được hoàn toàn vấn đề nhưng mỗi giải pháp đều đưa ra các bước đi đúng hướng. Ghim ảnh chụp nhanh khi có thể

Khi nền tảng hiển thị các ảnh chụp nhanh ngày tháng, việc ghim chúng là tiền cược trên bảng. Nhưng không phải mọi nền tảng đều hiển thị chúng và các ảnh chụp nhanh được ghim cuối cùng sẽ không được dùng nữa. Hãy cân nhắc điều này khi chọn nền tảng để lưu trữ mô hình cho các sản phẩm AI của bạn một cách cẩn thận, nếu không bạn có thể rơi vào tình huống mô hình của bạn biến mất mà không có kế hoạch dự phòng.

Thử nghiệm hồi quy tập dữ liệu vàng

Thử nghiệm hồi quy tập dữ liệu vàng là nơi bạn chạy một tập hợp đầu vào cố định thông qua các điểm cuối sản xuất theo lịch trình và phân biệt các đầu ra với đường cơ sở đã biết rõ ràng. Quá trình này cho phép bạn dễ dàng nắm bắt các hồi quy về chất lượng và các thay đổi hành vi quan trọng khác của mô hình, nhưng việc duy trì rất tốn kém và chỉ có thể bao gồm các mẫu mà bạn nghĩ sẽ quan sát. Kiểm tra hồi quy tập dữ liệu vàng thường xuyên có thể ngăn chặn tin tức đáng sợ rằng khách hàng đã phát hiện ra sự thay đổi hành vi của sản phẩm trước khi bạn phát hiện ra.

Lấy mẫu đầu ra và ghi nhật ký

Đây là quá trình ghi lại tỷ lệ phần trăm mẫu của các yêu cầu sản xuất và phản hồi để phân tích sau này. Điều này cho phép bạn phát hiện sự sai lệch sau khi thực tế xảy ra, nhưng vẫn yêu cầu bạn phải tự mình xây dựng cơ sở hạ tầng lấy mẫu, lưu trữ và phân tích.

Triển khai bóng

Bạn có thể chạy cùng một yêu cầu đối với điểm cuối sản xuất hiện tại và điểm cuối mới dự kiến, đồng thời so sánh kết quả đầu ra để xem điều đó ảnh hưởng như thế nào đến hoạt động của mô hình. Điều này hoạt động rất hiệu quả trong việc đánh giá những thay đổi bạn đang thực hiện; nó không giúp ích gì cho những thay đổi mà nền tảng thực hiện dưới sự quản lý của bạn.

Tự lưu trữ mô hình

Bước kiểm soát cuối cùng:tự chạy mô hình trên cơ sở hạ tầng mà bạn kiểm soát. Điều này cho phép bạn có toàn quyền kiểm soát trọng số bạn đang sử dụng, công cụ suy luận, lượng tử hóa và bất kỳ điều gì khác có thể ảnh hưởng đến đầu ra. Điều này đánh đổi vấn đề về phiên bản để lấy gánh nặng vận hành của việc lưu trữ mô hình, đó là lý do tại sao hầu hết các nhóm không làm điều đó.

Chi phí thực sự của việc tạo phiên bản là bao nhiêu

Thuế tuân thủ

Mọi nhóm quan tâm đến chất lượng đầu ra đều đang xây dựng cơ sở hạ tầng đánh giá của riêng họ vì nền tảng không cung cấp cơ sở hạ tầng đó. Đây là công việc trùng lặp đang diễn ra trong toàn ngành - khung hồi quy nhanh chóng, công cụ phân biệt đầu ra, hệ thống giám sát chất lượng, v.v., tất cả đều được xây dựng bởi các nhóm ứng dụng, những người muốn xây dựng sản phẩm thực tế của họ. Thuế ủy thác

Khi tính năng AI của bạn bị hỏng do mô hình thay đổi theo bạn, người dùng sẽ không biết sự khác biệt giữa “AI không đáng tin cậy” và “nền tảng đã âm thầm cập nhật mô hình”. Sản phẩm của bạn chịu tổn thất danh tiếng do các quyết định đưa ra ở cấp trên.

Thuế di cư

Các nhóm xem xét chuyển đổi nền tảng không chỉ phải tính đến sự khác biệt về API mà còn cả sự khác biệt về hành vi giữa các mô hình cùng tên trên các nền tảng khác nhau. “Llama 3.1 70B” trên Fireworks không nhất thiết phải giống với “Llama 3.1 70B” trên Together - chúng có thể là một lượng tử hóa khác, sử dụng công cụ suy luận khác hoặc có ngăn xếp lan can hoàn toàn khác. Sự thiếu rõ ràng này khiến việc chuyển đổi giữa các nhà cung cấp trở nên khó khăn nếu không thử nghiệm rộng rãi.

Sẽ trông như thế nào tốt hơn

Một nền tảng suy luận nghiêm túc vào năm 2026 sẽ xử lý hành vi của mô hình theo cách các nhà cung cấp đám mây xử lý thời gian hoạt động:như một bề mặt hợp đồng chứ không phải một hộp đen.

Trạng thái hiện tại không phải là hạn chế về mặt kỹ thuật - đó là lỗ hổng công bố thông tin. Cơ sở hạ tầng đã tồn tại để theo dõi trọng lượng, động cơ, mức độ lượng tử hóa và các quyết định định tuyến; nền tảng đơn giản là không phơi bày nó.

Đây là những gì thực tế trông thấy.

1. Đôi khi, số nhận dạng phiên bản hoàn chỉnh, tên mẫu máy ngày nay xác định trọng số. Họ phải xác định cấu hình phân phát đầy đủ. Chuỗi phiên bản hoàn chỉnh nắm bắt mọi thứ có thể thay đổi những gì xuất phát từ điểm cuối:trọng số (với mức lượng tử hóa), công cụ suy luận và phiên bản, tạo phần cứng, phiên bản mã thông báo, mẫu trò chuyện và bất kỳ lời nhắc hoặc lớp lan can bảo vệ nào của hệ thống được đưa vào nền tảng. Một cái gì đó như llama-3.1-70b-instruct.fp8.vllm-0.6.3.h100.tmpl-v2.guardrail-v4 là xấu nhưng trung thực. Các nhóm có thể ghim bất kỳ thành phần nào mà họ phụ thuộc và nhận thông báo khi những thành phần khác thay đổi.

2. Nguồn cấp dữ liệu nhật ký thay đổi cho toàn bộ stackPlatforms xuất bản ghi chú phát hành khi họ cập nhật trọng số mô hình. Họ hiếm khi xuất bản bất cứ điều gì khi nâng cấp vLLM, thay đổi lượng tử hóa vì lý do chi phí hoặc định tuyến lại lưu lượng truy cập giữa các khu vực. Nguồn cấp dữ liệu nhật ký thay đổi thích hợp - lý tưởng nhất là máy có thể đọc được - sẽ bao phủ mọi lớp của ngăn xếp phân phát, có dấu thời gian và điểm cuối bị ảnh hưởng. Các nhóm có thể đăng ký các thay đổi đối với một cấu hình được ghim cụ thể và nhận thông báo trước khi triển khai chứ không phải sau khi người dùng phàn nàn.

3. Đảm bảo khả năng tái tạo với khả năng lưu giữ đã nêu. Ảnh chụp nhanh được ghim sẽ có ý nghĩa gì đó. Nền tảng phải cam kết với khoảng thời gian lưu giữ đã nêu - chẳng hạn như 12 hoặc 24 tháng - trong thời gian đó, cấu hình được ghim sẽ trả về kết quả đầu ra giống hệt byte cho các đầu vào giống hệt nhau ở nhiệt độ 0, cho toàn bộ ngăn xếp chứ không chỉ cho trọng số. Khi thời hạn đó hết hạn, các nhóm sẽ nhận được thông báo trước và lộ trình di chuyển. Đây là cách cơ sở dữ liệu và hệ điều hành xử lý việc lập phiên bản. Không có lý do gì mà suy luận lại khác.

4. Kiểm tra hồi quy do nền tảng cung cấp Mọi nhóm nghiêm túc đều đang xây dựng cơ sở hạ tầng đánh giá giống nhau một cách riêng biệt. Các nền tảng phải cung cấp tính năng này như một tính năng hạng nhất:đăng ký tập dữ liệu vàng, chạy tập dữ liệu đó theo lịch dựa trên điểm cuối đã ghim của bạn và nhận thông báo khi kết quả đầu ra vượt quá ngưỡng bạn đặt. Điểm thưởng cho việc kiểm tra sự khác biệt giữa các ảnh chụp nhanh để các nhóm có thể đánh giá xem có nên di chuyển hay không trước khi bị buộc phải làm vậy.

5. Tài liệu trung thực về những gì thay đổi và khi nào Mục khó nhất trong danh sách này, bởi vì nó yêu cầu các nền tảng phải thừa nhận rằng “cùng một mô hình” luôn là một khái niệm trừu tượng về tiếp thị. Tài liệu phải nêu tên mọi lớp có thể thay đổi độc lập với phiên bản mô hình, nêu rõ chính sách của nền tảng về việc thay đổi từng lớp và mô tả cách khách hàng sẽ được thông báo. Sau đó, các nhóm có thể đưa ra quyết định sáng suốt về việc nền tảng nào phù hợp với mức độ chấp nhận rủi ro của họ.

Danh sách kiểm tra của người mua

Nếu hôm nay bạn đang đánh giá một nền tảng suy luận, hãy hỏi nhà cung cấp những câu hỏi này trước khi ký:

• “Tôi có thể ghim một ảnh chụp nhanh mô hình cụ thể không và đảm bảo ảnh chụp nhanh đó có sẵn trong bao lâu?”
• “Chuỗi phiên bản mà tôi ghim có bao gồm công cụ suy luận, lượng tử hóa và phần cứng - hay chỉ các trọng số?”
• “Chính sách thông báo của bạn là gì khi bất kỳ lớp nào trong ngăn xếp phân phát thay đổi?”
• "Bạn có đưa vào lời nhắc hệ thống, rào chắn hoặc lớp kiểm duyệt mà tôi không thể nhìn thấy không? Tôi có thể chọn không tham gia không?"
• “Nếu tôi chạy cùng một yêu cầu hai lần ở nhiệt độ 0 cách nhau một tháng, bạn có đảm bảo gì về danh tính đầu ra?”
• “Bạn cung cấp công cụ kiểm tra hồi quy hay tôi tự xây dựng nó?”
• “Khi ảnh chụp nhanh được ghim không còn được dùng nữa, tôi sẽ nhận được bao nhiêu thông báo và đường dẫn di chuyển là gì?”

Nếu một nền tảng không thể trả lời rõ ràng hầu hết những điều này thì đó chính là câu trả lời. Bạn đang xây dựng trên cơ sở hạ tầng có thể thay đổi bên dưới bạn và bạn sẽ là người giải thích điều đó cho người dùng của mình.

Thực tế thương mại

Không có điều nào ở trên là khó về mặt kỹ thuật. Điều gây khó khăn là về mặt thương mại:các nền tảng được hưởng lợi từ tính linh hoạt trong việc thay đổi mọi thứ một cách lặng lẽ và trước đây khách hàng đã chấp nhận điều đó vì giải pháp thay thế, tự lưu trữ, rất tốn kém khi vận hành. Giao dịch đó bắt đầu trở nên tồi tệ hơn khi các tính năng AI chuyển từ bản demo sang sản phẩm mà mọi người phụ thuộc. Các nền tảng giải quyết được vấn đề này trước tiên sẽ giành được phân khúc thị trường thực sự quan tâm đến độ tin cậy. Những nhóm không làm như vậy sẽ tiếp tục gửi các hồi quy thầm lặng cho các nhóm tìm hiểu thông tin từ người dùng của họ.

Suy nghĩ kết thúc

Ngành công nghiệp đã xây dựng cơ sở hạ tầng AI dựa trên một giả định vay mượn từ phần mềm truyền thống:hiện vật được đặt tên là hiện vật ổn định. Giả định đó không đúng. Trọng lượng, động cơ, định tuyến và lan can đều thay đổi độc lập với tên trên điểm cuối và khoảng cách giữa “phiên bản mô hình” ngụ ý và những gì nó thực sự đảm bảo là nơi AI sản xuất lặng lẽ phá vỡ.

Đây là dự đoán:trong vòng 18 tháng tới, việc tạo phiên bản im lặng sẽ trở thành một vấn đề mua sắm chứ không chỉ là vấn đề kỹ thuật. Các nhóm mua khả năng suy luận đang bắt đầu đặt các câu hỏi trong danh sách kiểm tra ở trên và các nền tảng có thể trả lời chúng sẽ bắt đầu giành được các giao dịch mà những nền tảng khác thậm chí không biết là họ đã thua. Kỳ vọng sẽ thấy “SLA khả năng tái tạo”, “nhật ký thay đổi ở cấp độ ngăn xếp” và “cửa sổ lưu giữ ảnh chụp nhanh” chuyển từ danh sách mong muốn kỹ thuật sang hợp đồng doanh nghiệp. Nền tảng đầu tiên xuất bản chuỗi phiên bản đầy đủ dưới dạng tính năng sản phẩm - không phải chú thích chi tiết trong tài liệu - sẽ đặt lại kỳ vọng của khách hàng đối với những người khác.

Đối với các nhóm xây dựng dựa trên suy luận ngày nay, câu hỏi thực tế không phải là liệu sự thay đổi thầm lặng có ảnh hưởng đến sản phẩm của bạn hay không. Nó sẽ. Câu hỏi đặt ra là liệu bạn phát hiện ra điều đó từ việc theo dõi, từ các bài kiểm tra hồi quy của chính bạn hay từ khiếu nại của người dùng vào sáng thứ Hai. Điều nào trong ba điều đó phụ thuộc gần như hoàn toàn vào quyết định của bạn bây giờ, trước khi có bản cập nhật im lặng tiếp theo.

Mẫu bạn gửi kèm không phải là mẫu bạn đang chạy. Xây dựng phù hợp.

DigitalOcean có thể giúp bạn xây dựng các sản phẩm AI trên quy mô lớn.

Tác phẩm này được cấp phép theo Giấy phép quốc tế Creative Commons Ghi công-NonCommercial-ShareAlike 4.0.