Lập luận cho việc rời OpenAI đã mạnh lên rõ rệt trong năm 2026. Các mô hình trọng số mở đã đạt tới mức mà khoảng cách chất lượng gần như biến mất trong công việc sản xuất thường ngày, giá niêm yết thấp hơn, và bản thân trọng số có thể tải về, điều biến quan hệ với nhà cung cấp từ sự phụ thuộc thành một lựa chọn.

Nhưng điều đó không khiến việc chuyển đổi trở nên miễn phí. Lệnh gọi API gần như y hệt; mọi thứ xung quanh nó mới là phần phải làm. Bài viết này nói rõ cái gì chuyển được nguyên vẹn, cái gì hỏng âm thầm, cách thiết kế một phép so sánh có ý nghĩa, và khi nào ở lại mới là câu trả lời đúng.

Đặt kỳ vọng trước: đổi nhà cung cấp là đổi một base URL, một tên mô hình và một chuỗi xác thực. Nhưng lấy lại đúng chất lượng đầu ra là bài toán kỹ thuật prompt tính bằng ngày. Hãy dành một đến ba tuần cho một tính năng có phạm vi rõ ràng. Mọi ước lượng giả định thay thế tức thì đều là ước lượng lạc quan.

Những gì chuyển được nguyên vẹn

Nhiều hơn bạn nghĩ, và đó chính là lý do đáng cân nhắc.

Định dạng gọi chuyển được. Hầu hết nhà cung cấp mô hình mở nghiêm túc hiện đều có API tương thích quy ước OpenAI, nên thư viện client, hình dạng request và xử lý streaming hiện tại của bạn thường chạy không cần sửa. Chẳng hạn Kimi K3 cung cấp cả giao diện tương thích OpenAI lẫn Anthropic, chi tiết có trong hướng dẫn Kimi K3 API .

Toàn bộ kiến trúc xung quanh chuyển được. Lớp proxy giữ chuỗi xác thực, hàng đợi, logic thử lại, đo lường theo người dùng, ghi log: không phần nào quan tâm phía sau là mô hình gì. Nếu bạn đã dựng lớp đó tử tế thì việc chuyển đổi thật sự chỉ là đổi cấu hình. Ngược lại, nếu SDK của nhà cung cấp nằm rải rác khắp mã nguồn, đây là lúc bạn phát hiện ra điều đó.

Lớp truy hồi chuyển được. Embedding, kho vector và chiến lược chia đoạn đều độc lập với mô hình sinh, dù nếu cửa sổ ngữ cảnh của mô hình mới khác biệt lớn thì kích thước đoạn đáng được xem lại.

Những gì hỏng âm thầm

Các kiểu hỏng đủ nhất quán để lên kế hoạch trước.

Prompt không mang theo được. Đây là hạng mục lớn nhất. Prompt thường được tinh chỉnh, một cách vô thức, theo thói quen của một mô hình cụ thể. Bê nguyên sang mô hình khác, bạn nhận được đầu ra đúng về kỹ thuật nhưng lệch về phong cách: mức độ dài dòng khác, định dạng khác, mức sẵn sàng nói “tôi không biết” cũng khác. Hãy chuẩn bị viết lại prompt hệ thống, và đó chính là phần lớn công việc chuyển đổi.

Đầu ra có cấu trúc hành xử khác. Nếu bạn dựa vào phản hồi ràng buộc theo schema, hãy kiểm tra nhà cung cấp mới cưỡng chế điều đó thế nào. Có nơi bảo đảm tuân thủ ngay ở lớp giải mã, có nơi chỉ yêu cầu lịch sự và phần lớn thời gian được đáp ứng. Mã viết theo giả định “được bảo đảm” rồi sẽ gặp một trường dữ liệu méo mó.

Gọi công cụ khác nhau ở chi tiết. Định dạng đã chuẩn hóa, nhưng độ tin cậy, mức sẵn sàng gọi nhiều công cụ liên tiếp, và hành vi khi không công cụ nào phù hợp đều khác nhau. Tải tác tử là nơi đau nhất, vì sai số tích lũy qua từng bước.

Hành vi suy luận và cách tính tiền khác nhau. Một số mô hình luôn suy luận và tính token suy luận vào đầu ra. Mô hình bật suy luận mặc định ở mức tối đa có thể tốn nhiều hơn mỗi request so với mô hình dẫn đầu bạn vừa rời, dù giá niêm yết thấp hơn. Đọc kỹ giá trị mặc định trước khi mô hình hóa khoản tiết kiệm.

Ranh giới an toàn và điểm từ chối dịch chuyển. Mỗi nhà cung cấp vạch ranh giới ở chỗ khác nhau. Nội dung mô hình hiện tại xử lý được có thể bị từ chối, và ngược lại. Nếu ứng dụng chạm tới y tế, pháp lý hay tài chính, hãy kiểm thử phần này một cách rõ ràng thay vì để khách hàng phát hiện hộ.

Thiết kế một phép so sánh có ý nghĩa

Benchmark của nhà cung cấp không trả lời câu hỏi của bạn. Hãy dựng một bộ đánh giá nhỏ và tự trả lời.

Thu thập từ 30 đến 100 đầu vào thật từ lưu lượng sản xuất, chọn sao cho đại diện toàn dải kể cả các ca rắc rối, và ghi lại đầu ra bạn coi là đúng cho từng ca. Đây chính là hệ thống được mô tả trong hướng dẫn tích hợp OpenAI API , và nếu bạn đã có sẵn thì phép so sánh chỉ mất một buổi chiều.

Chạy cả hai mô hình với prompt được tinh chỉnh riêng cho từng bên. So một prompt tối ưu cho mô hình này với mô hình kia dùng đúng prompt đó không phải là so sánh, mà chỉ là bằng chứng rằng prompt không mang theo được.

Đo bốn thứ: chất lượng đầu ra theo tiêu chí của bạn, tổng chi phí mỗi request bao gồm token suy luận, độ trễ ở phân vị mà người dùng thực sự trải nghiệm chứ không phải trung vị, và các kiểu hỏng. Hạng mục cuối quan trọng nhất và hay bị bỏ sót nhất. Một mô hình kém hơn chút ít về trung bình nhưng không bao giờ sinh đầu ra méo mó có thể là lựa chọn tốt hơn cho pipeline tự động.

Sau đó chạy triển khai bóng. Nhân bản lưu lượng thật gửi sang mô hình ứng viên mà không dùng phản hồi của nó, rồi so sánh trên một tuần sử dụng thực. Đánh giá tổng hợp bỏ sót phần đuôi dài; lưu lượng sản xuất thì không.

Rời OpenAI: khi nào khoản tiết kiệm là thật

Hãy tính toán trước khi làm kỹ thuật, vì câu trả lời thay đổi rất lớn theo loại tải.

Khoản tiết kiệm là thật và lớn khi bạn có khối lượng cao công việc thường quy: phân loại, trích xuất, tóm tắt, định tuyến. Những tác vụ này hiếm khi cần năng lực đỉnh, chúng chạy liên tục, và chênh lệch giá mỗi token cứ thế cộng dồn. Đây là lập luận mạnh nhất và thường tự nó đủ để biện minh cho việc chuyển đổi.

Khoản tiết kiệm là thật nhưng nhỏ hơn với các tính năng tương tác quy mô vừa. Một trợ lý hỗ trợ xử lý vài nghìn hội thoại mỗi tháng tốn không bao nhiêu ở cả hai bên, và thời gian kỹ thuật có thể vượt cả năm tiết kiệm.

Khoản tiết kiệm có thể là ảo tưởng khi token suy luận được tính vào đầu ra và mô hình mới suy luận ở mọi lệnh gọi. Hãy mô hình hóa bằng độ dài prompt thật của bạn, không phải giá niêm yết.

Có loại tiết kiệm không liên quan đến tiền. Trọng số tải về được là một lối thoát. Nếu nhà cung cấp ngừng mô hình bạn đang phụ thuộc, đổi giá giữa hợp đồng, hoặc áp hạn mức không phù hợp, việc có chỗ để đi là có giá trị. Chi phí thực sự để thực thi lựa chọn đó nằm trong hướng dẫn tự vận hành Kimi K3 , và cao hơn phần lớn các đội hình dung.

Câu trả lời thường là “cả hai”

Đóng khung việc này thành một cuộc chuyển đổi mới là sai lầm. Những đội thu được nhiều nhất chạy nhiều mô hình sau một giao diện duy nhất.

Định tuyến theo tác vụ. Gửi công việc thường quy khối lượng lớn tới mô hình rẻ nhất vượt qua bộ đánh giá. Gửi công việc ngữ cảnh dài và tác tử tới mô hình xử lý nó tốt nhất. Giữ lại một mô hình dẫn đầu cho phần nhỏ request mà bạn muốn câu trả lời mạnh nhất và giá không phải yếu tố quyết định.

Cũng có thể định tuyến theo phân loại dữ liệu. Request chứa tài liệu không được rời khỏi phạm vi pháp lý đi tới mô hình bạn tự vận hành, phần còn lại dùng API được quản lý. Vì giao diện giống nhau, ứng dụng không cần biết request đã đi đường nào.

Điều này đòi hỏi lớp trừu tượng phải tồn tại trước khi bạn cần đến nó. Dựng ranh giới trước để việc chọn nhà cung cấp trở thành thay đổi cấu hình chứ không phải một dự án, và điều đó cũng khiến các lần chuyển đổi sau rẻ đi. Về bức tranh ngân sách rộng hơn, hướng dẫn chi phí tích hợp AI tách riêng chi phí xây dựng và vận hành.

Khi nào nên ở lại

Ở lại là câu trả lời đúng thường xuyên hơn nhiều so với những gì các bài viết về chuyển đổi gợi ý.

Ở lại nếu khối lượng của bạn thấp. Chi phí kỹ thuật sẽ không hoàn vốn, và thời gian đó dùng cho chính tính năng thì tốt hơn.

Ở lại nếu bạn thực sự phụ thuộc vào năng lực riêng của nhà cung cấp và đã kiểm chứng rằng bên thay thế thiếu nó, thay vì giả định. Hãy thử nghiệm trước khi kết luận.

Ở lại nếu ứng dụng nhạy cảm về an toàn và ranh giới của nhà cung cấp hiện tại khớp với yêu cầu sau khi kiểm thử thật. Xây lại niềm tin đó cũng tốn kém.

Và hãy ở lại, lúc này, nếu bạn chưa có hệ thống đánh giá. Chuyển đổi mà không có nó nghĩa là bạn sẽ không biết chất lượng đã tụt cho tới khi khách hàng nói. Hãy dựng hệ thống trước; nó hữu ích dù bạn quyết thế nào.

Để phép so sánh được chạy đúng cách

Mecanik nhận công việc LLM đa nhà cung cấp trong dịch vụ tích hợp AI : lớp định tuyến, hệ thống đánh giá, viết lại prompt cho mô hình đích, và triển khai bóng cho bạn biết môi trường sản xuất sẽ hành xử ra sao.

Chúng tôi cho lưu lượng của chính bạn chạy qua nhiều nhà cung cấp và đặt chất lượng, chi phí, độ trễ cạnh nhau trước khi bạn cam kết, kể cả những trường hợp khuyến nghị trung thực là hãy giữ nguyên. Nếu tích hợp hiện tại của bạn gắn cứng một nhà cung cấp trong toàn bộ mã nguồn, hướng dẫn tích hợp OpenAI API mô tả lớp proxy giúp lần chuyển đổi này và mọi lần sau đều rẻ.

Hãy cho biết mức chi hàng tháng hiện tại và tính năng đó làm gì, chúng tôi sẽ nói việc chuyển đổi có đáng công sức kỹ thuật hay không.

Bài viết liên quan: Fine-tuning vs RAG vs prompt: mỗi cách tốn bao nhiêu , Xây dựng chatbot OpenAI API: Hướng dẫn 2026 .

Câu hỏi thường gặp

Chuyển từ OpenAI sang mô hình trọng số mở có khó không? Bản thân lệnh gọi API rất đơn giản vì hầu hết nhà cung cấp có giao diện tương thích OpenAI: chỉ là base URL, tên mô hình và chuỗi xác thực. Công việc thật là viết lại prompt vốn được tinh chỉnh theo thói quen của một mô hình, và kiểm chứng lại đầu ra có cấu trúc cùng việc gọi công cụ. Hãy dành một đến ba tuần.

Mô hình trọng số mở có tiết kiệm tiền không? Tùy loại tải. Công việc thường quy khối lượng lớn như phân loại, trích xuất, tóm tắt thường tiết kiệm đáng kể. Còn tính năng tương tác quy mô nhỏ thường không hoàn được chi phí kỹ thuật. Hãy cảnh giác với mô hình luôn suy luận và tính token đó vào đầu ra, vì nó có thể xóa sạch lợi thế giá niêm yết.

Prompt hiện tại của tôi có chạy trên mô hình khác không? Thường là không nếu không viết lại. Prompt được tinh chỉnh theo mức dài dòng, định dạng và xu hướng từ chối của một mô hình cụ thể, nên cùng một prompt trên mô hình khác cho đầu ra đúng nhưng lệch phong cách. Hãy tinh chỉnh riêng cho từng mô hình trước khi so sánh.

Làm sao so sánh công bằng hai LLM? Dựng bộ đánh giá 30 đến 100 đầu vào thật với đầu ra đã biết là đúng, tinh chỉnh prompt riêng cho từng mô hình, rồi so chất lượng, chi phí mỗi request gồm token suy luận, độ trễ ở phân vị thực tế và các kiểu hỏng. Sau đó chạy triển khai bóng trên lưu lượng thật.

Nên dùng một nhà cung cấp hay nhiều? Nhiều nhà cung cấp sau một giao diện duy nhất. Gửi công việc thường quy khối lượng lớn tới mô hình rẻ nhất vượt qua bộ đánh giá, công việc ngữ cảnh dài và tác tử tới mô hình xử lý tốt nhất, và giữ một mô hình dẫn đầu cho số ít request cần câu trả lời mạnh nhất.