Đánh giá Image 2.6 về chất lượng, tốc độ và chi phí

GPT Image 2.6 đáng thử nếu bạn làm nhiều bản nháp hình ảnh, cần sửa phần cụ thể hoặc muốn thử cảnh khó chụp thật. Giữ GPT Image 2.5 hoặc quy trình Nano Banana hiện tại làm mốc khi thử. Bằng chứng hiện có dẫn đến kết luận hữu ích hơn lời khuyên “nâng cấp”: mô hình mới có thể nhanh hơn với một số việc, nhưng tốc độ và chi phí không đi cùng nhau, và ảnh đầu đẹp chỉ là khởi đầu của công việc sáng tạo.

Trong hồ sơ năm prompt Clico lưu lại, 2.6 Flare có thời gian phản hồi trung vị nhanh hơn 2.5 Flare nhưng phí trung bình cao hơn. Bài thử Sunburst riêng thấy 2.6 chậm hơn 2.5 qua ba yêu cầu. Cả hai đều chưa đủ lớn để xếp hạng mô hình nói chung. Chúng cho thấy cần so sánh toàn bộ công việc: ảnh đầu tiên, các lần sửa cần thiết, thời gian chờ và hóa đơn thực tế.

Khi nào nên xem kỹ 2.6 hơn

Khi thử ý tưởng, mô hình ảnh hữu ích nếu biến ý tưởng thành hình đủ cụ thể để đánh giá. Cá voi kính màu được Picsart và OpenAI chia sẻ làm ví dụ GPT Image 2.6 kết hợp màu trong mờ, ánh sáng và cảm giác quy mô thuyết phục. Đó là cảnh phi thực tế mà đội ngũ sáng tạo có thể dùng để thảo luận hướng làm trước khi sản xuất.

Ảnh trả lời tốt một câu hỏi: có thể hình dung hướng này thành hình không? Nó chưa trả lời một chiến dịch có tạo lại đúng con cá voi từ góc thứ hai hay giữ hình dạng qua các lần sửa được không. Đó là kiểm tra riêng. Nếu tính liên tục quan trọng hơn khung đầu đẹp, dùng tham chiếu sẵn có và yêu cầu thay đổi nhỏ, cụ thể. ví dụ bìa cho thấy kiểu sửa có mục tiêu đó: áo khoác đổi từ đỏ sang xanh lam, còn khăn cam, tư thế và tiệm giặt vẫn dễ nhận ra. Ví dụ hữu ích để biết cần kiểm tra gì, không bảo đảm giữ nguyên từng pixel.

Hình ảnh sản phẩm có ràng buộc khác. Ví dụ của OpenArt giữ nến HEARTH dễ nhận ra trong bốn bối cảnh theo mùa. Nhãn và lọ màu hổ phách làm điểm cố định của bố cục khi môi trường thay đổi. Với chiến dịch, điều đó quan trọng hơn nền đẹp.

Ví dụ được chọn không chứng minh mô hình giữ được bao bì thực tế của bạn. Với sản phẩm thật, đối chiếu nhãn, nắp, tỷ lệ, màu và nội dung thuộc quy định quản lý với ảnh nguồn. Nền đẹp hơn không có ích nếu lọ hay chữ đã thay đổi mà không nhận ra. So sánh thời gian sửa các chi tiết đó với thời gian đang dùng cho cùng việc trong 2.5.

Cảnh bếp của OpenArt đặt ra bài thử khác. Ánh sáng lạnh từ tủ lạnh tách người phụ nữ ở tiền cảnh khỏi bóng người thứ hai trong tối. Ấm đỏ tạo điểm nhấn giữa khung hình tối. Với ý tưởng phim và thời trang, quan hệ đó cần thể hiện đúng ánh sáng và dàn cảnh bạn muốn.

Đây là ví dụ được chọn để tiếp thị, không phải kết quả Clico hay bài thử đối đầu mô hình khác. Chúng gợi ý điều cần ghi trong bản định hướng. Với chiến dịch sản phẩm, tiêu chí đạt có thể là nhãn giữ đúng trong bốn bối cảnh. Với ý tưởng phim, có thể là vị trí hai người và nguồn sáng nhất quán. Với ảnh siêu thực, có thể là giữ chủ thể khi đổi góc nhìn. Không có tiêu chí ấy, rất dễ chọn ảnh nổi bật nhất rồi bỏ qua công việc còn phải làm.

GPT Image 2.6 so với 2.5

Điều đáng chú ý nhất trong hồ sơ Clico lưu lại không chỉ là thời gian phản hồi, mà là thời gian đi cùng chi phí. ghi âm chứa năm prompt khác nhau, gửi một lần cho mỗi mô hình ngày 5 tháng 11 năm 2026 qua OpenRouter Images API, với quality tự động và yêu cầu ảnh vuông 1024 pixel.

Trong nhóm nhỏ này, 2.6 Flare trả kết quả sớm hơn 2.5 Flare nhưng phí trung bình ghi nhận cao hơn. Riêng ảnh chân dung 2.6 Flare tốn $0.174125, nên một tác vụ ảnh hưởng đáng kể đến trung bình. Yêu cầu dùng quality tự động, nhưng quality và complexity cuối cùng không được ghi lại. Vì vậy không thể tách riêng phiên bản làm nguyên nhân chênh lệch. Đây là phí OpenRouter, không phải giá credit bán lẻ của Clico.

Chỉnh sửa từ tham chiếu làm rõ sự đánh đổi đó. Cả hai phiên bản Flare nhận cùng minh họa chai xanh lam và cùng yêu cầu: chỉ đổi thân chai sang xanh rừng đậm, giữ nắp, nhãn kem, bóng và bố cục.

Cả hai phiên bản đổi chai sang xanh lá và giữ nắp, nhãn cùng bố cục tổng thể dễ nhận ra. Kết quả 2.6 xanh đậm hơn nhưng cặp này không có cải thiện cấu trúc rõ: 2.5 đã làm được đổi màu cơ bản. Yêu cầu 2.6 Flare được ghi nhận mất 9.423 giây và $0.033197, so với 12.557 giây và $0.014357 của 2.5 Flare. Chờ ngắn hơn nhưng phí cao hơn, chưa phải lý do rõ để thay 2.5 cho mọi chỉnh sửa đơn giản.

Khác biệt này quan trọng khi đội ngũ tạo nhiều phương án. Tiết kiệm vài giây cho bản nháp có thể đáng giá nếu giúp việc duyệt diễn ra liên tục. Nhưng nếu mỗi phương án đắt hơn hoặc cần sửa nhiều lần, phản hồi đầu nhanh chưa chắc giảm chi phí của ảnh được duyệt. Theo dõi tổng chi phí cho kết quả dùng được, không chỉ một yêu cầu.

Giá token bằng nhau không có nghĩa hóa đơn bằng nhau. Biểu giá tiêu chuẩn của OpenAI giống nhau với các mô hình 2.5 và 2.6 tương ứng, nhưng lượng token dùng có thể khác. công cụ tính chi phí đầu ra ước tính 196 token đầu ra cho ảnh vuông 1024 pixel ở quality low của 2.5, và 823 cho 2.6. Ở quality high, cả hai đều là 1,756. Các số này chưa gồm chi phí đầu vào.

Cũng có ví dụ phản chứng cho tuyên bố tốc độ chung. Trong Thử nghiệm của Kingycủa Curtis Pyke, ba yêu cầu ảnh tĩnh ở chất lượng medium, mỗi yêu cầu chỉ thử một lần, mất tổng cộng 39.752 giây với 2.5 Sunburst và 48.739 giây với 2.6 Sunburst. Ước tính chi phí theo mức sử dụng lần lượt là $0.044622 và $0.124542. Đây là tổng của bài thử khác, không phải các dòng bổ sung để tính chung với trung vị của Clico. Mỗi lần sửa dùng kết quả trước đó của chính mô hình làm tham chiếu. Bài thử bỏ qua complexity, vốn mặc định high ở 2.6, nên cùng quality vẫn không có nghĩa mọi điều kiện giống nhau. Điều này cho thấy kết quả thay đổi theo mô hình và thiết lập, không có nghĩa Sunburst luôn chậm hơn.

Chọn thiết lập phù hợp với chỉnh sửa

OpenAI định hướng Flare cho các vòng chỉnh sửa nhanh, còn Sunburst cho chi tiết, bố cục và chỉnh sửa khó hơn trong hướng dẫn mô hình. Đó là điểm bắt đầu hợp lý để thử, không phải quy tắc rằng ảnh Sunburst luôn tốt hơn. Với đổi nền đơn giản, giữ đúng sản phẩm có thể quan trọng hơn thêm chi tiết ở nơi khác.

Hướng dẫn OpenAI Image API tách quality khỏi complexity. Quality liên quan đến kết xuất, còn complexity điều khiển mức lập kế hoạch của mô hình. Khi bỏ qua complexity, mặc định là high. OpenAI lưu ý lập kế hoạch nhiều hơn có thể tăng độ trễ và gây thay đổi không mong muốn. Với chỉnh sửa cụ thể, thử complexity thấp hơn nếu nhà cung cấp cho chỉnh, rồi kiểm tra phần đã yêu cầu giữ. Với bố cục đông chi tiết, mức cao hơn có thể đáng thử. Kết quả, không phải tên thiết lập, quyết định bản sửa có dùng được không.

API cũng tạo được SVG và GIF qua yêu cầu tạo mới. Các định dạng này quan trọng nếu cần đồ họa sửa được hoặc hoạt ảnh ngắn, nhưng endpoint chỉnh sửa không xuất SVG hay GIF. Đừng cho rằng lựa chọn định dạng trong API có mặt ở mọi ứng dụng ảnh.

Người dùng Nano Banana có nên chuyển không?

Nếu Nano Banana đã tạo được kết quả bạn duyệt, bắt đầu từ đúng phiên bản đang dùng. Google gọi mô hình mới hơn là Nano Banana 2.1, với API ID gemini-nano-banana-2.1; Nano Banana 2 là gemini-3.1-flash-image, còn Nano Banana Pro là gemini-3-pro-image. Đây là các mô hình khác nhau; so sánh chỉ ghi “Nano Banana” có thể che khuất lựa chọn thực sự cần cân nhắc.

của Google hướng dẫn tạo ảnh nêu đầu ra 1K, 2K, 4K và chỉnh sửa qua trò chuyện cho 2.1. Tài liệu mô tả tối đa 14 ảnh tham chiếu trong các quy trình Gemini API được hỗ trợ, gồm vật thể và nhân vật. Ứng dụng riêng có thể giới hạn thấp hơn. Với chiến dịch dùng nhiều tham chiếu hoặc cần độ phân giải lớn, đó là lý do thực tế để giữ 2.1 trong so sánh. Nếu cần tạo SVG hoặc GIF qua OpenAI API, 2.6 lại có lý do khác để thử.

Chi phí cũng cần xem kỹ như khả năng. Tính đến ngày 5 tháng 11, Giá Gemini API tiêu chuẩn của Google ước tính phí đầu ra ảnh Nano Banana 2.1 là $0.0336 cho 1K, $0.0504 cho 2K và $0.113 cho 4K. Phí đầu vào, văn bản hoặc suy luận và phí tìm kiếm áp dụng có thể cộng thêm. Không thể xếp các ước tính đầu ra này cạnh tổng phí OpenRouter trong bảng trước như thể chúng tính cùng chi phí. Cả hai đều không phải giá credit bán lẻ Clico.

Hồ sơ Clico lưu không có kết quả Nano Banana, nên chưa xác định được bên thắng về tốc độ hay chất lượng so với 2.6. Quyết định chuyển công bằng bắt đầu bằng cùng bản định hướng và tham chiếu, dùng thiết lập bạn thực sự sẽ trả tiền, rồi kiểm tra ảnh hoàn chỉnh lẫn các lần sửa. Giữ mô hình đang dùng nếu nó đáp ứng bản định hướng với tổng chi phí tốt hơn hoặc ít sửa hơn.

Kiểm tra đúng kết quả cần bàn giao

Ví dụ sớm từ nhà sáng tạo có thể gợi ý điều cần kiểm tra, chưa đủ để quyết định. Trong Bài đăng trên X ngày 4 tháng 11, Angel chia sẻ bản xem trước hoạt ảnh cú, ảnh đồ ăn và cua kiểu pixel, cho biết nhiễu đã giảm nhưng vẫn khó làm đồ họa pixel. Bài đăng không nêu prompt, biến thể hay chất lượng cụ thể. Đây là nhận xét của một nhà sáng tạo, không phải tỷ lệ lỗi hay bằng chứng về cải thiện chung.

Ảnh xem trước tĩnh không cho biết vòng lặp có nối mượt không. Kingy đánh giá GIF tạo trực tiếp bằng 2.6 của mình có điểm nối rõ và chuyển động không đều. Nếu chuyển vì hoạt ảnh, hãy phát tệp thật và kiểm tra điểm nối. Nếu cần đồ họa pixel, xem cạnh ở kích thước hiển thị sẽ dùng. Nếu cần quảng cáo sản phẩm, đối chiếu chữ và bao bì với nguồn. Mỗi kiểm tra xuất phát từ sản phẩm bàn giao, không phải thông báo ra mắt mô hình.

Chọn một bản định hướng hiện có và lưu kết quả bạn sẽ dùng nếu không đổi mô hình. Thử 2.6 Flare để làm các vòng chỉnh sửa, hoặc Sunburst cho bố cục hay chỉnh sửa khó, rồi lặp đủ lần để xem kết quả có ổn định không. Ghi thời gian chờ, phí nhà cung cấp thực tế và các lần sửa để được duyệt. Chuyển ở nơi toàn bộ quy trình giúp công việc tốt hơn; giữ mô hình cũ khi không cải thiện.