API tạo ảnh bằng AI tốt nhất năm 2026: Khung tiêu chí lựa chọn

Mức giá niêm yết trên mỗi hình ảnh là một bộ lọc ban đầu kém hiệu quả. Hai mô hình có cùng mức giá danh nghĩa có thể khác nhau về việc chúng có chấp nhận ảnh tham chiếu hay không, có hỗ trợ chỉnh sửa bằng mặt nạ (masked edits) hay không, cách chọn kích thước đầu ra như thế nào, và chi phí được tính theo từng yêu cầu hay theo token. Hãy lọc các ứng viên theo khả năng trước, sau đó so sánh chi phí trên mỗi kết quả đầu ra được chấp nhận dựa trên các prompt của chính bạn.

Bài viết này là một khung lựa chọn dành cho các API tạo ảnh. Nội dung tập trung vào việc tạo hình ảnh, không bao gồm video. Trong trường hợp pipeline cần cả hai, các cơ chế bất đồng bộ (async) và tính phí tương tự vẫn được áp dụng, nhưng video nằm ngoài phạm vi bài viết này.

Bước 1: Khớp thao tác được hỗ trợ

Vòng loại trừ đầu tiên mang tính vận hành. Một endpoint chỉ tạo ảnh từ văn bản sẽ không thể thực hiện chỉnh sửa bằng mặt nạ, và một mô hình được xây dựng chuyên cho inpainting không phải là công cụ đa năng để tạo ảnh từ prompt tổng quát.

Trên TokenLab, tạo ảnh và chỉnh sửa thường là các endpoint khác nhau:

Bạn cần gì	Endpoint	Ghi chú
Text-to-image	POST /v1/images/generations	Yêu cầu chỉ bắt đầu từ một prompt
Image-to-image / tạo ảnh dựa trên tham chiếu	POST /v1/images/generations	Các mô hình chấp nhận operation: "image-to-image" cùng với URL tham chiếu
Chỉnh sửa bằng mặt nạ hoặc multipart	POST /v1/images/edits	Các mô hình có tài liệu mô tả luồng chỉnh sửa (edit flow)
Biến thể của một ảnh hiện có	POST /v1/images/variations	Dành cho các tích hợp đã sử dụng định dạng variations
Trạng thái tác vụ	GET /v1/tasks/{id}	Khi phản hồi tạo tác vụ trả về task_id, status: "pending", hoặc poll_url

Xem hướng dẫn tạo ảnh để biết bảng quyết định và tài liệu tham khảo Create Image cùng Edit Image để biết các trường trong yêu cầu.

Có một quy tắc định tuyến gây ra tỷ lệ lỗi đặc biệt cao: các yêu cầu ảnh tham chiếu của Nano Banana (nano-banana-2, nano-banana-pro) phải gửi đến /v1/images/generations cùng operation: "image-to-image" và image_urls, chứ không phải /v1/images/edits. Ngược lại, các thao tác chỉnh sửa của gpt-image-2 thuộc về /v1/images/edits, nơi mô hình chấp nhận tải lên tệp multipart image, JSON image_url / image_urls, và tham chiếu images[] với tối đa 16 ảnh nguồn.

Các nhóm phân loại hữu ích từ danh mục TokenLab hiện tại:

• Cả tạo ảnh và chỉnh sửa: flux-2-klein-4b, flux-2-klein-9b, flux-2-pro, flux-2-flex, flux-2-max, flux-kontext-pro, flux-kontext-max, gemini-3-pro-image, gemini-3.1-flash-image, nano-banana-2, nano-banana-2-lite, nano-banana-pro, gpt-image-2, gpt-image-2.5-flare, gpt-image-2.5-sunburst, grok-imagine-image, grok-imagine-image-quality, grok-imagine-image-2.0, qwen-image-2.0, qwen-image-2.0-pro, qwen-image-3.0, seedream-4.0, seedream-4.5, seedream-5.0, seedream-5.0-lite, seedream-5.0-pro, vidu-image-lite, vidu-image-pro.
• Chỉ tạo ảnh từ văn bản (text-to-image): flux-1-dev, flux-pro-1.1, flux-pro-1.1-ultra, sd3.5-medium, sd3.5-large, sd3.5-large-turbo, sd3.5-flash, stable-image-core, stable-image-ultra, z-image, z-image-turbo, kling-image, kling-omni-image, hy-image-lite.
• Các công cụ chỉnh sửa chuyên dụng: stability-inpaint, stability-control-sketch, stability-control-structure, stability-style-guide, stability-upscale-fast, stability-upscale-conservative, image-upscaler, image-background-remover, flux-pro-1.0-fill, qwen-image-edit.

Hãy kiểm tra các thao tác theo từng mô hình cụ thể thay vì theo họ mô hình. GET /v1/models?recommended_for=image trả về tập hợp được đề xuất hiện tại, và tài liệu tham khảo Get a Model hiển thị trường supported_operations cho biết một ID cụ thể chấp nhận những gì.

Bước 2: Kiểm tra cách mô hình nhận ảnh tham chiếu

Xử lý ảnh tham chiếu là khâu dễ làm gián đoạn tích hợp nhất. Tên các trường không thể dùng thay thế cho nhau:

• image_url — một ảnh tham chiếu duy nhất.
• image_urls — một hoặc nhiều ảnh tham chiếu dưới dạng JSON.
• reference_image_urls — các ảnh tham chiếu bổ sung cho các mô hình tách biệt đầu vào chính với tham chiếu.
• image — tải lên tệp multipart, dành cho các ảnh nguồn riêng tư hoặc được bảo vệ bằng header.
• images[] với image_url hoặc file_id — cấu trúc dành cho luồng chỉnh sửa; không được chấp nhận trên /v1/images/generations.

Các ràng buộc đáng lưu ý khi thiết kế hệ thống, trích từ tài liệu tham khảo API:

• Các tham chiếu từ xa phải là URL http/https công khai, không chứa thông tin xác thực nhúng hoặc phân đoạn (fragments), và không được phân giải về localhost, dải IP riêng tư hoặc dải IP dành riêng. Mỗi lượt chuyển hướng (redirect) đều được kiểm tra lại.
• Hình ảnh lấy từ URL: 50 MiB cho mỗi ảnh, tổng cộng tối đa 200 MiB cho mỗi yêu cầu (bao gồm cả mask), thời gian chờ nạp (fetch timeout) 30 giây, tối đa 3 lần chuyển hướng. Dữ liệu tải về phải là tệp PNG, JPEG hoặc WebP thực sự.
• Giới hạn số lượng ảnh nguồn khác nhau giữa các mô hình: gpt-image-2 chấp nhận tối đa 16 ảnh; giới hạn tối đa 3 ảnh đầu vào được ghi trong tài liệu áp dụng cụ thể cho grok-imagine-image và grok-imagine-image-quality (báo lỗi 400 too_many_images nếu vượt quá 3) và không được ghi nhận đối với grok-imagine-image-2.0.
• Một mask phải là tệp PNG dung lượng dưới 50 MiB và có cùng kích thước (dimensions) với ảnh nguồn.

Nếu hình ảnh nguồn của bạn ở chế độ riêng tư, hãy lên kế hoạch sử dụng tính năng tải lên multipart hoặc tham chiếu /v1/files thay vì truyền một signed URL sắp hết hạn. Signed URL hết hạn trước khi quá trình xử lý bắt đầu sẽ bị coi là đầu vào bị từ chối, chứ không phải lỗi do tạo ảnh.

Bước 3: So sánh các tùy chọn kiểm soát đầu ra, không chỉ tên mô hình

Hai mô hình trong cùng một phân khúc có thể cung cấp các cơ chế kiểm soát kích thước và chất lượng hoàn toàn khác nhau. Hãy xác nhận đặc tả tham số (selector contract) trước khi xây dựng giao diện người dùng (UI) xung quanh nó.

Tùy chọn kiểm soát	Điều cần kiểm tra
size	Các họ mô hình theo phong cách OpenAI chấp nhận auto hoặc WIDTHxHEIGHT. Với gpt-image-2, các kích thước phải là bội số của 16, cạnh dài nhất tối đa 3840px, tỷ lệ cạnh dài/cạnh ngắn tối đa là 3:1 và tổng số pixel nằm trong khoảng từ 655,360 đến 8,294,400
aspect_ratio	Các họ mô hình tạo ảnh của Google và Grok Imagine sử dụng 1:1, 16:9, 9:16, 3:2, 2:3 và các giá trị tương tự
resolution	gemini-3.1-flash-image, gemini-3-pro-image, nano-banana-2 và nano-banana-pro hỗ trợ 1k, 2k, 4k, trong khi nano-banana-2-lite chỉ hỗ trợ 1k. Grok Imagine hỗ trợ 1k và 2k
quality	Các mô hình GPT Image sử dụng auto, low, medium, high. Các mô hình khác có thể sử dụng các giá trị khác
n	Số lượng hình ảnh cho mỗi yêu cầu, tùy thuộc vào mô hình
response_format	url hoặc b64_json. Các tác vụ bất đồng bộ luôn trả về URL bất kể định dạng được yêu cầu
background, output_format, output_compression	Được ghi nhận trong tài liệu cho gpt-image-2; không hỗ trợ transparent
async	Được hỗ trợ cho gpt-image-2 và các mô hình tạo ảnh chính thức của FLUX/BFL

Việc gửi một trường không được ghi nhận trong tài liệu không phải là vô hại. Ví dụ, input_fidelity hiện không nằm trong danh sách các trường được hỗ trợ cho gpt-image-2 và sẽ trả về lỗi 400 unsupported_parameter. Các trường không được hỗ trợ trên những mô hình khác cũng sẽ gặp lỗi tương tự. Danh sách trường đầy đủ có trong tài liệu tham khảo Create Image.

Bước 4: Xác định đơn vị tính phí trước khi so sánh bất cứ điều gì

Việc so sánh chi phí sẽ sai lệch khi so sánh một mô hình tính phí theo token với một mô hình tính phí theo hình ảnh như thể chúng có cùng một đơn vị tính.

• gpt-image-2 được tính giá theo token. TokenLab tuân theo bảng phân tích mức sử dụng của nhà phát triển cho text input, image input, cached input được báo cáo và image output token; mô hình này không được lập hóa đơn theo mức cố định trên mỗi ảnh.
• Hầu hết các mô hình tạo ảnh khác được định giá theo yêu cầu, theo hình ảnh hoặc theo đơn vị khác hiển thị trên trang mô hình.

Hệ quả thực tế: đối với gpt-image-2, cùng một prompt với cùng các cài đặt danh nghĩa có thể phát sinh chi phí khác nhau tùy thuộc vào độ phân giải, chất lượng và chính nội dung prompt đó, do lượng token đầu ra thay đổi. Hãy đo lường trước khi quyết định một quy tắc định tuyến cố định.

Hãy đọc đơn vị tính phí và mức giá hiện tại tại thời điểm gửi yêu cầu thay vì hard-code thành một bảng cố định:

• Thanh toán và định giá giải thích cách thức hoạt động của các khoản tính phí, ước tính và tạm giữ trước cho tác vụ bất đồng bộ (async reservation).
• Get a Model trả về tokenlab.pricing và tokenlab.pricing_unit cho một mô hình đơn lẻ.
• List Models trả về danh mục kèm tokenlab.pricing, tokenlab.capabilities và tokenlab.deliveryAvailability.
• Trang Models hiển thị thông tin tương tự để tiện tra cứu.

Dấu gạch ngang trong cột giá của TokenLab có nghĩa là hiện không có gói cung cấp TokenLab Verified cho mô hình đó, chứ không phải là mô hình đó miễn phí. Các mô hình có nguồn cung Official vẫn có thể được truy cập thông qua tùy chọn phân phối Official hoặc Auto.

Bước 5: Lựa chọn luồng đồng bộ hay luồng dựa trên tác vụ

Các yêu cầu tạo ảnh độ phân giải cao có thể mất gần một phút hoặc lâu hơn. Hãy đặt thời gian chờ (timeout) cho HTTP client của bạn tối thiểu là 120 giây cho các lệnh gọi đồng bộ, hoặc sử dụng luồng tác vụ (task flow).

• Gửi async: true với gpt-image-2 hoặc các mô hình tạo ảnh FLUX/BFL chính thức để nhận task_id và poll_url thay vì nhận ảnh đã hoàn thành.
• Không nên hard-code một mô hình luôn là đồng bộ hoặc luôn là bất đồng bộ. Hãy kiểm tra phản hồi tạo tác vụ: nếu chứa status: "pending", task_id hoặc poll_url, hãy gọi tiếp theo poll_url được trả về.
• Các trạng thái gồm có pending, processing, completed và failed. Việc đọc trạng thái thành công sẽ trả về HTTP 200 ngay cả khi tác vụ đã thất bại; hãy sử dụng trường status, không dựa vào mã phản hồi HTTP.
• Kết quả hình ảnh bất đồng bộ được trả về dưới dạng URL. Nếu bạn cần dữ liệu thô b64_json, hãy sử dụng yêu cầu đồng bộ.
• Thực hiện thăm dò (poll) định kỳ mỗi vài giây và dừng lại khi đạt trạng thái kết thúc (terminal status). Các URL kết quả HTTP(S) của hình ảnh được tạo có thể được lưu trữ dưới dạng bản sao đa phương tiện trong 30 ngày; hãy kiểm tra media_retention.items để biết trạng thái và expires_at của từng mục.

Thông tin chi tiết có trong hướng dẫn tác vụ bất đồng bộ và thăm dò cùng tài liệu tham khảo Get Image Status.

Việc thử lại (retry) tiềm ẩn rủi ro về chi phí, không chỉ đơn thuần là rủi ro về độ trễ. Một yêu cầu tạo tác vụ được thử lại sau khi hết thời gian chờ có thể sinh ra một tác vụ thứ hai và bị tính phí lần thứ hai. Hãy lưu request_id, task_id và bất kỳ billing_transaction_id nào, đồng thời kiểm tra xem tác vụ đã được tạo hay chưa trước khi thực hiện thử lại.

Bước 6: Đánh giá trên tập prompt của chính bạn

Không có bảng xếp hạng chất lượng trung lập từ nhà cung cấp nào được đưa vào bài viết này, và bạn cũng không nên tin vào các thông tin quảng cáo tiếp thị. Hãy chứng minh cho lựa chọn của mình bằng cách đo lường trên khối lượng công việc thực tế của bạn:

1. Tập hợp một bộ prompt cố định phản ánh đúng phân phối thực tế trong môi trường sản xuất của bạn — các chủ đề, phong cách và định dạng chỉ dẫn mà bạn thực sự nhận được. Các prompt demo chung chung sẽ không giúp bạn phân biệt rõ các mô hình.
2. Chạy cùng một bộ prompt này trên các mô hình tiềm năng với cùng các thiết lập, và ghi lại thời gian tạo ảnh trên mỗi yêu cầu bao gồm cả các lần thử lại.
3. Chấm điểm kết quả đầu ra theo một thang tiêu chí cố định, thông qua quy trình tự động hoặc hội đồng đánh giá của con người, thay vì chỉ quan sát mẫu bằng mắt thường.
4. Tính toán chi phí trên mỗi hình ảnh được chấp nhận, chứ không phải chi phí trên mỗi hình ảnh được tạo ra. Một mô hình rẻ hơn nhưng cần đến hai lần thử mới cho ra một kết quả dùng được thì không hề rẻ hơn.
5. Nếu sản phẩm của bạn nhạy cảm với độ trễ, hãy ghi lại các phân vị (percentiles) thay vì giá trị trung bình, bởi vì phần đuôi phân phối (tail latency) mới là điều người dùng nhận thấy.
6. Hãy chạy lại bài so sánh khi bạn thay đổi nhà cung cấp hoặc mục tiêu độ phân giải, bởi vì cả đơn vị tính phí và hành vi của mô hình đều có thể thay đổi.

Chi phí trên mỗi hình ảnh được chấp nhận là con số duy nhất trả lời cho câu hỏi liệu một mô hình đắt tiền hơn có xứng đáng với mức giá của nó đối với khối lượng công việc của bạn hay không.

Yêu cầu minh họa

Dưới đây là một ví dụ minh họa về cấu trúc lệnh gọi tạo ảnh, không phải là kết quả đo lường. Ví dụ này sử dụng một mô hình hỗ trợ aspect_ratio và resolution.

curl https://api.tokenlab.sh/v1/images/generations \
  -H "Authorization: Bearer $TOKENLAB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3-pro-image",
    "prompt": "A cinematic portrait of a white cat sitting on a rainy windowsill",
    "aspect_ratio": "16:9",
    "resolution": "2k"
  }'

Nếu phản hồi đó trả về với status: "pending", hãy thăm dò poll_url được trả về thay vì coi đó là một lỗi.

Khả năng truy cập mô hình không đồng nhất giữa các định dạng API. TokenLab chấp nhận các định dạng yêu cầu Chat Completions, Responses, Anthropic Messages và Gemini, và một mô hình cụ thể có thể chỉ hỗ trợ một số trong số đó. Hãy kiểm tra trường tokenlab.accepted_request_formats trên mô hình trước khi tái sử dụng một client hiện có — xem Định dạng API.

Giới hạn của bài viết này

• Không có bài đánh giá chất lượng độc lập, phép đo độ trễ hoặc số liệu thông lượng nào cho bất kỳ mô hình tạo ảnh nào được đưa vào đây. Tuyên bố tiếp thị của nhà cung cấp về giải phẫu, hiển thị văn bản hoặc độ chân thực của ảnh chụp không được tái hiện như một sự thật hiển nhiên.
• Không có mức giá cụ thể nào được trích dẫn. Các đơn vị tính phí của mô hình tạo ảnh có sự khác nhau và có thể thay đổi; hãy đọc giá trị hiện tại từ trang Models hoặc qua GET /v1/models/{model}.
• Tính khả dụng của mô hình thay đổi tùy theo tùy chọn phân phối và workspace. Trường tokenlab.deliveryAvailability mô tả hỗ trợ được định cấu hình; trường này không đảm bảo tính khả dụng theo thời gian thực (vốn chỉ được kiểm tra khi yêu cầu được thực thi).
• Áp dụng các giới hạn theo khu vực công khai.

Tài liệu đọc thêm

• Hướng dẫn tạo ảnh
• Create Image và Edit Image
• Tác vụ bất đồng bộ và thăm dò
• Thanh toán và định giá
• List Models và Get a Model
• Định dạng API
• Danh sách mô hình và mức giá hiện tại: Trang Models