Ploy chuyển đổi mô hình AI mặc định sang GPT-5.6 Sol: Hiệu suất tăng gấp đôi, chi phí giảm mạnh

Kể từ hôm nay, tác nhân (agent) của Ploy chạy trên GPT-5.6 Sol, phiên bản hàng đầu thuộc dòng mô hình mà OpenAI vừa ra mắt sáng nay. Trong nhiều tháng, chúng tôi không thể tìm thấy mô hình nào thách thức được Claude Opus do tiêu chuẩn chất lượng cực kỳ khắt khe của chúng tôi. Điều đó đã thay đổi với GPT-5.6 Sol. Sau khi chạy thử nghiệm đối đầu trực tiếp với Claude Opus, chúng tôi đã chọn GPT-5.6 Sol làm mô hình mặc định cung cấp năng lượng cho mọi không gian làm việc (workspace) trên Ploy.

Đây là một sự thay đổi lớn hơn so với vẻ ngoài của nó. Tác nhân của Ploy xây dựng và chỉnh sửa các trang web tiếp thị thực tế. Nó lập kế hoạch cho một trang, đọc mã nguồn, viết các thành phần, tạo hình ảnh, chụp ảnh màn hình công việc của chính nó và quyết định khi nào công việc hoàn thành. Bản mô tả công việc đó đặt ra tiêu chuẩn rất cao cho một mô hình, và chúng tôi kiểm thử mọi bản phát hành tiên phong dựa trên tiêu chuẩn này. Trong bốn tháng Opus giữ vị trí mặc định (đầu tiên là Opus 4.7, sau đó là 4.8), không có gì chúng tôi thử nghiệm vượt qua được nó. GPT-5.6 là mô hình đầu tiên làm được điều đó.

Không phải lần chạy đánh giá (eval) đầu tiên đã hoàn hảo. Nó có những kiểu lỗi thực sự, mà chúng tôi sẽ cho bạn thấy. Nhưng nó đã làm rất tốt, và tiềm năng là ngay lập tức và cụ thể: thời gian xây dựng hoàn tất giảm xuống dưới một nửa so với thời gian thực, chi phí thấp hơn 27%, và đạt điểm bằng hoặc cao hơn mô hình hiện tại của chúng tôi đối với các công việc đã hoàn thành. Những con số như vậy xứng đáng để một mô hình thực hiện quá trình chuyển đổi thực sự.

Mặc dù sử dụng Vercel’s AI SDK, một bộ công cụ LLM phổ quát, việc chuyển từ Claude Opus 4.8 sang GPT-5.6 Sol đòi hỏi phải khám phá từng lỗi đánh giá một, rằng những thứ chúng ta coi là "mô hình" thực chất là các hành vi đặc thù của nhà cung cấp mà toàn bộ hệ thống (stack) của chúng tôi đã âm thầm thích nghi xung quanh: cách nó điền các đối số công cụ, cách bộ nhớ đệm prompt (prompt cache) hoạt động, cách nó phát lại lập luận của chính nó giữa các lượt.

Đây là những gì cần làm: sửa bộ khung đánh giá (eval harness), sau đó là lược đồ công cụ (tool schemas), bộ nhớ đệm và việc phát lại lập luận.

Bước 0: Sửa bộ khung của bạn trước khi tin vào bất kỳ con số nào

Bộ đánh giá của chúng tôi chạy tác nhân thực trên các không gian làm việc mẫu thực tế. Hàng trăm trường hợp, từ "xây dựng trang chủ từ đầu" đến "yêu cầu nhân bản này có an toàn để thực thi không". Các trường hợp xây dựng được chấm điểm bởi một giám khảo trực quan chạy các kiểm tra nhị phân so với thiết kế tham chiếu, mười câu hỏi có/không như "hero là một cảnh chụp ảnh tràn viền" hoặc "các CTA chính là hình chữ nhật bo tròn, không phải hình viên thuốc", cộng với kiểm tra nội dung, kiểm tra quỹ đạo công cụ và xác nhận tệp. Mọi trường hợp thất bại đều được phân loại dựa trên dấu vết (trace) đầy đủ của nó: các lệnh gọi công cụ thực tế và văn bản của mô hình, không chỉ là điểm số.

Việc chạy bộ đánh giá đó trên hai dòng mô hình đã làm chúng tôi ngạc nhiên hơn bất kỳ kết quả riêng lẻ nào:

Bộ khung của bạn được tinh chỉnh cho mô hình hiện tại và bạn không biết điều đó. Ngân sách gọi công cụ của chúng tôi được định cỡ cho phong cách tuần tự của Opus; GPT-5.6 phân nhánh các lệnh gọi song song và đã vượt quá giới hạn trong các trường hợp nó đang giải quyết đúng. Bộ thực thi đánh giá của chúng tôi không hỗ trợ đọc tệp theo lô, điều mà Opus hiếm khi sử dụng còn GPT-5.6 thì sử dụng liên tục. Khoảng một phần ba các lỗi thô trong lần chạy chéo mô hình đầu tiên bắt nguồn từ các giả định của bộ khung, không phải hành vi của mô hình, và chúng không được phân bổ đều giữa các mô hình. Nếu bạn đang đánh giá một mô hình thách thức so với mô hình hiện tại, hãy phân loại các dấu vết trước khi tin vào tỷ lệ vượt qua. Nếu không, bạn đang chấm điểm mô hình mới dựa trên việc nó bắt chước mô hình cũ tốt đến mức nào.

Hãy đảm bảo bạn đang chấm điểm các mô hình một cách công bằng trong các bài đánh giá. Một tập dữ liệu bỏ qua ngưỡng minScore đã âm thầm kế thừa giá trị mặc định là 1.0, vì vậy GPT-5.6 "thất bại" ở một hero mà nó đạt 0.98, và Opus "thất bại" ở một trường hợp trong khi vượt qua mọi kiểm tra riêng lẻ. Hai hướng thiết kế có thể bảo vệ được; một ngưỡng vô hình.

Với bộ khung đã được làm sạch, đây là mẫu từ bộ thiết kế lại của chúng tôi, nơi tác nhân xây dựng lại trang chủ của một thương hiệu dựa trên thiết kế tham chiếu:

Đây là hình dáng của lời hứa: nhanh hơn 2,2 lần để hoàn thành một trang, rẻ hơn 27% và chỉ bằng khoảng một nửa số token đầu ra. GPT-5.6 viết mã tinh gọn. Trên một cặp so khớp, Opus tạo ra tệp globals.css dài 17.957 ký tự với 174 biến CSS (đầy đủ dải màu, hầu hết không sử dụng) trong khi GPT-5.6 viết 2.508 ký tự và 45 biến cho một trang hiển thị tương đương (và đôi khi tốt hơn).

Thiết kế: sắc nét, sạch sẽ, nhưng hơi đồng nhất

Nhận định tổng thể của chúng tôi về công việc thiết kế của GPT-5.6: nó rất giỏi trong các bố cục sạch sẽ, hiện đại, lưới chặt chẽ, nhưng nó có xu hướng hội tụ về vẻ ngoài đó trừ khi bạn điều hướng nó tốt. Với bộ khung cũ được thiết kế cho Opus 4.8, GPT-5.6 Sol có xu hướng bỏ qua các hệ thống thiết kế hiện có và thay vào đó tạo ra kết quả sắc nét, hạn chế và có vẻ chung chung.

Chi tiết về cách chúng tôi khắc phục điều này xứng đáng có một bài đăng blog riêng. Với chuyên môn của đội ngũ thiết kế và kỹ thuật, chúng tôi có thể điều hướng các mô hình để đạt được sự tuân thủ thương hiệu đẳng cấp thế giới mà bạn không thể có được ngay khi vừa sử dụng (out of the box).

Bước 1: Kiểm tra các lệnh gọi công cụ của bạn

Đây là lỗi đã âm thầm làm hỏng kết quả trước khi chúng tôi phát hiện ra.

Công cụ mã của tác nhân chúng tôi có 25 tham số cấp cao nhất, một tham số bắt buộc (action) và phần còn lại là tùy chọn. Claude gửi hai hoặc ba tham số nó đang sử dụng và bỏ qua phần còn lại. GPT-5.6 gửi tất cả 25 tham số, mỗi lần đều như vậy, tự tạo ra các giá trị hợp lý cho những tham số nó không cần: offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000".

Ba ngày theo dõi sản xuất, các lệnh gọi code(read) mang theo mọi thuộc tính:

Vấn đề không phải là sự dài dòng. Vấn đề là một giá trị được tạo ra không thể phân biệt được với một giá trị có chủ đích. offset: 0 trông giống như một đối số thực. Việc triển khai đọc tệp của chúng tôi coi nó là một đối số, và 52% đến 64% các lần đọc tệp của GPT-5.6 trả về kết quả trống vì điều đó. Công cụ trả về success: true theo cả hai cách, vì vậy mô hình không có cách nào biết rằng nó đang đọc các tệp trống. Nó chỉ làm công việc tệ hơn, với nhiều lệnh gọi hơn.

Prompting không giải quyết được vấn đề này. Một chỉ thị mô tả công cụ để "bỏ qua các tham số không sử dụng": vẫn là 25/25. Các gợi ý cho từng thuộc tính "TÙY CHỌN, bỏ qua nếu không sử dụng": vẫn là 25/25. Chế độ nghiêm ngặt (strict mode) của OpenAI: hành vi giống hệt (chúng tôi đã đo lường), và việc áp dụng nó sẽ buộc chúng tôi phải loại bỏ xác thực pattern, format và array-bound khỏi mọi lược đồ. Điều này đã ăn sâu vào cách mô hình phát ra các lệnh gọi hàm. Bạn không thể hướng dẫn nó bỏ qua; bạn phải thiết kế xung quanh nó.

Giải pháp hiệu quả là chuyển đổi lược đồ tại ranh giới nhà cung cấp. Chỉ dành cho các mô hình thuộc dòng OpenAI, chúng tôi viết lại mọi thuộc tính tùy chọn thành bắt buộc nhưng có thể nhận giá trị null, sử dụng anyOf: [T, null], điều này cung cấp cho mô hình một cách rõ ràng để nói "không sử dụng cái này". Sau đó, tại điểm nối duy nhất mà mọi lệnh gọi công cụ đi qua, chúng tôi loại bỏ các giá trị null trước khi xác thực, vì vậy không cần thay đổi việc triển khai công cụ nào cả. Kết quả: mô hình thấy một lược đồ nơi sự trung thực có thể được thể hiện; các công cụ thấy các đầu vào giống như chúng vẫn luôn nhận được.

Kết quả: các lần đọc tệp trống giảm từ 52% xuống 0%, và tác nhân cần ít hơn khoảng 30% lệnh gọi công cụ cho cùng một công việc, vì nó không còn đọc lại các tệp trả về trống nữa.

Bước 2: Xây dựng lại bộ nhớ đệm prompt

Đây là sự khác biệt kỹ thuật mang tính hướng dẫn nhất, bởi vì trên bề mặt, cả hai nhà cung cấp đều cung cấp "bộ nhớ đệm prompt" và các từ ngữ che giấu hai thiết kế hoàn toàn khác nhau. Nếu bạn di chuyển một thứ gì đó một cách cẩn thận, hãy làm điều này: trước khi chúng tôi thực hiện, GPT-5.6 trông đắt hơn khoảng 50% so với Opus. Đó không phải là giá của mô hình; đó là cấu hình bộ nhớ đệm của chúng tôi.

Prompt của tác nhân chúng tôi mở đầu bằng một tiền tố tĩnh khoảng 29K token (lược đồ công cụ cộng với prompt hệ thống cốt lõi) giống hệt nhau cho mọi cuộc hội thoại. Trên Claude, chúng tôi đánh dấu các điểm ngắt bộ nhớ đệm bằng cache_control và tiền tố đó được lưu vào bộ nhớ đệm trên toàn bộ tổ chức: bất kỳ cuộc hội thoại nào, bất kỳ không gian làm việc nào, một mục nhập dùng chung, không cần suy nghĩ về ngân sách thông lượng. Tỷ lệ trúng bộ nhớ đệm đạt 92% đến 96% và việc lưu vào bộ nhớ đệm trở nên vô hình.

GPT-5.6 đã thay đổi mô hình bộ nhớ đệm của OpenAI mà chúng tôi không hay biết. Các mô hình GPT trước đây lưu vào bộ nhớ đệm ngầm định trên các khớp tiền tố một phần, mang lại tỷ lệ trúng khá tốt mà không mất phí. GPT-5.6 đã loại bỏ khớp tiền tố một phần: bộ nhớ đệm ngầm định hiện chỉ tạo ra các mục nhập toàn bộ prompt được khóa theo tin nhắn mới nhất. Một cuộc hội thoại mới chia sẻ tiền tố tĩnh 29K của chúng tôi đã lưu vào bộ nhớ đệm 0%. Mọi cuộc hội thoại đều tính phí lại toàn bộ tiền tố ở mức chưa lưu vào bộ nhớ đệm, và trên GPT-5.6, mọi prompt chưa lưu vào bộ nhớ đệm cũng phải chịu thêm 1,25 lần phí ghi bộ nhớ đệm, bất kể bạn có sử dụng bộ nhớ đệm hay không.

Cơ chế dự định là rõ ràng: các điểm đánh dấu prompt_cache_breakpoint cộng với một prompt_cache_key bắt buộc. Và khóa là nơi thiết kế thực sự khác biệt, vì nó là một phần của danh tính bộ nhớ đệm. Prompt giống hệt nhau, khóa khác nhau: không có lần trúng bộ nhớ đệm nào. Mỗi khóa ánh xạ tới một nút bộ nhớ đệm duy trì khoảng 15 yêu cầu mỗi phút trước khi OpenAI phân tán lưu lượng truy cập sang các nút khác với các bộ nhớ đệm độc lập, lạnh (cold).

Điều đó biến "bật bộ nhớ đệm" thành một quyết định thiết kế thực sự: bạn xác định phạm vi khóa cho thực thể nào?

Chúng tôi gửi khóa theo phạm vi không gian làm việc và chia prompt hệ thống thành các lớp có điểm ngắt, phản ánh cấu trúc chúng tôi đã sử dụng cho Anthropic:

Mục nhập A là thứ làm cho lệnh gọi đầu tiên của phiên trở nên rẻ. Mục nhập B tự phục hồi: khi bộ nhớ không gian làm việc thay đổi, yêu cầu bỏ lỡ B nhưng vẫn trúng A, sau đó ghi một B mới. Một lần ghi kích thước ngữ cảnh thay vì tính phí lại toàn bộ 29K. Mục nhập C là chuỗi toàn bộ prompt ngầm định của OpenAI, hoạt động tốt trong một phiên vì các prompt của chúng tôi chỉ được thêm vào (append-only).

Một hệ quả không có cách giải quyết: việc chia sẻ tiền tố tĩnh giữa các không gian làm việc là không thể về mặt cấu trúc trên OpenAI. Anthropic có thể chia sẻ nó vì bộ nhớ đệm của nó được xác định phạm vi tổ chức mà không cần phân vùng khóa. Trên GPT-5.6, mỗi không gian làm việc phải trả một lần ghi lạnh 29K cho mỗi cửa sổ nhàn rỗi, khoảng $0,18. Một chi phí thực tế, nhưng có giới hạn và có thể dự đoán được.

Kết quả sau khi thay đổi: tỷ lệ trúng bộ nhớ đệm lần gọi đầu tiên tăng từ khoảng 0% lên 83,7%, tổng số token đầu vào chưa lưu vào bộ nhớ đệm giảm 28%, và chi phí mỗi bộ đánh giá của GPT-5.6 thấp hơn Opus. Mọi đô la chênh lệch mà chúng tôi đang nhìn vào đều là do cấu hình bộ nhớ đệm sai, không phải giá của mô hình. Nếu bạn đang so sánh chi phí các mô hình và một trong số chúng có bộ nhớ đệm lạnh, bạn đang so sánh cấu hình của mình, không phải các mô hình.

Bước 3: Làm cho việc phát lại lập luận trở nên khép kín

Ngắn gọn hơn, nhưng nó làm hỏng các cuộc hội thoại thực sự. API Phản hồi của GPT-5.6 phát lại lập luận của lượt trước dưới dạng tham chiếu mục phía máy chủ theo mặc định; của chúng tôi bắt đầu lỗi không liên tục giữa cuộc hội thoại với thông báo Item 'rs_...' not found. Giải pháp là store: false, khiến SDK yêu cầu nội dung lập luận được mã hóa và phát lại các khối khép kín thay vì các con trỏ đến trạng thái máy chủ. Một hệ quả khiến chúng tôi mất một buổi chiều gỡ lỗi: với trạng thái lập luận phía máy chủ trong vòng lặp, prompt hiệu dụng có thể thay đổi ngược dòng ngay cả khi các byte bạn gửi chỉ là thêm vào.

GPT-5.6 Sol đã sẵn sàng cho Ploy

Hãy tự mình thử nghiệm. GPT-5.6 đã ra mắt hôm nay, và nó đã hoạt động trên Ploy. Bạn có thể dùng thử miễn phí ngay bây giờ: hãy đưa cho nó một trang web để xây dựng và xem bản dựng dưới bốn phút trông như thế nào. Bắt đầu miễn phí tại ploy.ai.