Seedance 2.0 API không còn chỉ là một câu hỏi về khám phá mô hình nữa. Với các nhóm sản phẩm, những câu hỏi khó hơn là liệu route có khả dụng cho đúng chế độ đầu vào họ cần hay không, mức sử dụng được tính phí như thế nào, và điều gì xảy ra khi một mô hình video preview hoặc early-access không khả dụng.
Sự khác biệt đó rất quan trọng vì bức tranh mô hình công khai đang thay đổi nhanh chóng. ByteDance đã chính thức ra mắt Seedance 2.0 vào ngày 12 tháng 2 năm 2026, với khả năng nhập đa phương thức và âm thanh đồng bộ là các tính năng cốt lõi. Tính đến ngày 27 tháng 7 năm 2026, thư mục mô hình công khai của Flatkey liệt kê seedance-2.5 là tùy chọn text-to-video và image-to-video early-access ở 1080p, trong khi seedance-2.0-i2v được liệt kê là route image-to-video tính phí theo mức sử dụng ở 720p.
Những mục trong danh mục đó là điểm khởi đầu hữu ích, không phải một hợp đồng vĩnh viễn. Một tích hợp production nên xác minh khả năng sẵn có của mô hình, phương thức, độ phân giải, đơn vị tính giá và ngữ nghĩa của job trước mỗi lần ra mắt hoặc chiến dịch lớn.
Hướng dẫn này giải thích cách đánh giá khả năng truy cập Seedance trong năm 2026, ước tính chi phí thực của video được tạo ra, và thiết kế định tuyến dự phòng không bị gián đoạn khi tên mô hình, route của nhà cung cấp hoặc khả năng thay đổi.
Seedance 2.0 API: câu trả lời ngắn gọn
Các nhóm đánh giá Seedance 2.0 API nên xem nó như một quy trình media bất đồng bộ với hợp đồng khả năng theo phiên bản.
Trên thực tế, điều đó có nghĩa là ứng dụng của bạn nên:
- Xác thực liệu route đã chọn có hỗ trợ text-to-video, image-to-video, âm thanh, độ phân giải mục tiêu, thời lượng và khu vực hay không.
- Gửi một job tạo thay vì chờ phản hồi kiểu chat.
- Lưu ID job của nhà cung cấp và khóa idempotency của riêng bạn.
- Polling hoặc xử lý webhook cho đến khi job đạt trạng thái cuối cùng.
- Chuẩn hóa URL đầu ra, metadata, chi phí và lý do lỗi.
- Thử lại một cách an toàn hoặc chọn route dự phòng tương thích khi route chính không khả dụng.
Nếu Seedance chỉ là một mô hình trong một sản phẩm lớn hơn, hãy đặt logic này sau một lớp định tuyến thay vì nhúng giả định của một nhà cung cấp xuyên suốt ứng dụng của bạn.
Những gì đã thay đổi kể từ các hướng dẫn Seedance 2.0 API đầu tiên
Các bài viết Seedance 2.0 ban đầu tập trung vào việc tìm bất kỳ đường API nào dùng được. Điều đó không còn đủ nữa.
Hiện tại, bề mặt ra quyết định bao gồm:
- Nhiều phiên bản mô hình: một nhóm có thể gặp Seedance 2.0, một route 2.0 theo từng phương thức, hoặc một route Seedance 2.5 mới hơn.
- Các tổ hợp khả năng khác nhau: text-to-video, image-to-video, độ phân giải, âm thanh và giới hạn thời lượng có thể không khớp giữa các route.
- Trạng thái truy cập thay đổi: early access, danh sách cho phép, khả dụng theo khu vực và điều kiện tài khoản có thể thay đổi mà sản phẩm của bạn không thay đổi.
- Đơn vị tính phí khác nhau: giá video có thể được biểu thị theo giây, theo tài sản được tạo, theo credit, hoặc thông qua một đơn vị sử dụng đặc thù của nền tảng.
- Rủi ro vận hành bất đồng bộ: thời gian trong hàng đợi, timeout, gửi trùng lặp, URL đầu ra hết hạn và các job thất bại đều ảnh hưởng đến cả chi phí lẫn trải nghiệm người dùng.
Kết quả là một câu hỏi tích hợp trưởng thành hơn: không phải “có tồn tại API Seedance hay không?” mà là “route nào đáp ứng yêu cầu này hôm nay, và sản phẩm sẽ hoạt động thế nào nếu route đó không còn đáp ứng được nữa?”
Ảnh chụp trạng thái truy cập Seedance hiện tại cho ngày 27 tháng 7 năm 2026
Bảng sau đây là một tài liệu đánh giá có tính thời điểm. Hãy kiểm tra thư mục mô hình trực tiếp trước khi triển khai vì quyền truy cập và giá có thể thay đổi.
| Route | Trạng thái trong danh mục công khai | Phương thức | Đầu ra được liệt kê | Trường hợp sử dụng tốt nhất |
|---|---|---|---|---|
seedance-2.5 |
Truy cập sớm | Text-to-video và image-to-video | 1080p | Các đánh giá mới cần bộ khả năng hiện tại rộng hơn |
seedance-2.0-i2v |
Theo mức sử dụng | Image-to-video | 720p | Các quy trình image-to-video hiện có hoặc ưu tiên khả năng tương thích |
Ảnh chụp này làm nổi bật một quy tắc định tuyến quan trọng: một mô hình mới hơn không tự động là phương án dự phòng hợp lệ cho mọi yêu cầu, và một mô hình cũ hơn cũng không tự động có thể thay thế cho tuyến mới hơn.
Phương án dự phòng hợp lệ phải đáp ứng các khả năng mà yêu cầu cần. Nếu người dùng cung cấp một ảnh tham chiếu, phương án dự phòng phải hỗ trợ image-to-video. Nếu sản phẩm cam kết đầu ra 1080p, một tuyến chỉ 720p không phải là tương đương. Nếu cần âm thanh đồng bộ, một tuyến video im lặng phải không đạt kiểm tra khả năng trước khi gửi.
Truy cập trực tiếp nhà cung cấp so với cổng API hợp nhất
Có hai cách phổ biến để tích hợp một mô hình Seedance.
Tích hợp trực tiếp với nhà cung cấp
Truy cập trực tiếp có thể phù hợp khi:
- Seedance là mô hình video duy nhất trong sản phẩm.
- Tài khoản của nhà cung cấp có sẵn ở khu vực vận hành của nhóm.
- Nhóm thoải mái triển khai xác thực, trạng thái tác vụ, webhook, thanh toán và quy trình hỗ trợ riêng cho nhà cung cấp.
- Không có yêu cầu chuyển đổi mô hình mà không cần phát hành client.
Đánh đổi là sự ràng buộc vận hành. Các trường request, mã lỗi, xử lý tài sản và logic thanh toán đặc thù của nhà cung cấp có thể lan vào sản phẩm nếu nhóm không tạo ranh giới adapter riêng của mình.
Tích hợp qua cổng hợp nhất
Một cổng sẽ hữu ích hơn khi:
- Tạo video nằm bên cạnh các khối lượng công việc chat, hình ảnh, giọng nói hoặc agent.
- Nhóm cần một key và một bề mặt thanh toán duy nhất trên nhiều nhà cung cấp mô hình.
- Khả năng sẵn có của mô hình hoặc quyền truy cập theo khu vực có thể thay đổi.
- Sản phẩm cần hạn mức tập trung, danh sách cho phép mô hình, nhật ký sử dụng hoặc giới hạn chi tiêu.
- Nhóm muốn thay đổi định tuyến mô hình mà không cần viết lại mọi client.
Flatkey tài liệu hóa một lớp truy cập ổn định, hạn mức theo từng key, danh sách cho phép mô hình, và khả năng hiển thị mức sử dụng. Lợi ích chính không chỉ là thiết lập ngắn hơn. Đó là khả năng cô lập một bức tranh nhà cung cấp thay đổi phía sau một ranh giới định tuyến được kiểm soát duy nhất.
Xem hướng dẫn định tuyến agent đa phương thức rộng hơn để hiểu vai trò kiến trúc của ranh giới đó trên các khối lượng công việc video, hình ảnh, giọng nói và văn bản.
Xây dựng hợp đồng năng lực trước khi chọn mô hình
Đừng bắt đầu thiết kế phương án dự phòng bằng một danh sách tên mô hình. Hãy bắt đầu bằng một hợp đồng yêu cầu.
Một hợp đồng nội bộ minh họa có thể trông như sau:
{
"operation": "image_to_video",
"required": {
"resolution": "1080p",
"audio": true,
"max_queue_seconds": 90
},
"preferred_models": [
"seedance-2.5",
"seedance-2.0-i2v"
],
"fallback": {
"allow_lower_resolution": false,
"allow_silent_output": false,
"max_attempts": 2
}
}
Đây không phải là phần thân yêu cầu của nhà cung cấp. Đây là một chính sách ở cấp ứng dụng mà bộ định tuyến của bạn có thể đánh giá trước khi ánh xạ yêu cầu sang API cụ thể của nhà cung cấp.
Hợp đồng nên tách biệt:
- Yêu cầu cứng: phương thức, độ phân giải tối thiểu, âm thanh, thời lượng, khu vực tuân thủ và định dạng đầu ra.
- Ưu tiên: thứ tự mô hình, mức chất lượng, độ trễ kỳ vọng và mục tiêu chi phí.
- Mức suy giảm được phép: liệu người dùng có chấp nhận độ phân giải thấp hơn, đầu ra không có âm thanh, thời lượng ngắn hơn hoặc phong cách hình ảnh khác hay không.
- Giới hạn vận hành: thời gian chờ tối đa trong hàng đợi, số lần thử lại, ngân sách và thời hạn.
Không có sự tách biệt đó, việc định tuyến dự phòng sẽ trở thành phỏng đoán.
Quy trình định tuyến dự phòng đáng tin cậy
1. Duy trì một sổ đăng ký tuyến đường trực tiếp
Lưu từng tuyến đường ứng viên cùng với trạng thái khả năng và trạng thái truy cập hiện tại của nó:
- mã định danh mô hình
- nhà cung cấp
- các phương thức được hỗ trợ
- giới hạn độ phân giải và thời lượng
- hỗ trợ âm thanh
- hạn chế theo khu vực hoặc tài khoản
- đơn vị tính giá
- trạng thái sức khỏe hiện tại
- thời điểm yêu cầu thành công gần nhất
- thời điểm làm mới bằng chứng gần nhất
Đừng cho rằng tên mô hình trong marketing chứa đủ thông tin để định tuyến an toàn.
2. Lọc theo khả năng trước khi xét sức khỏe
Trước tiên, loại bỏ các tuyến đường không thể đáp ứng yêu cầu. Sau đó xếp hạng các tuyến còn lại theo sức khỏe, chi phí, độ trễ hoặc chất lượng.
Thứ tự này ngăn một tuyến đường khỏe mạnh nhưng không tương thích nhận một yêu cầu mà nó không thể thực hiện.
3. Tách lỗi tiếp nhận khỏi lỗi tác vụ
Các API video có thể thất bại trước hoặc sau khi tạo tác vụ.
Lỗi tiếp nhận bao gồm thông tin xác thực không hợp lệ, mô hình không khả dụng, tham số không được hỗ trợ, hạn chế tài khoản và giới hạn tốc độ. Những lỗi này thường có thể kích hoạt việc đổi tuyến ngay lập tức.
Lỗi tác vụ xảy ra sau khi nhà cung cấp chấp nhận yêu cầu. Chúng có thể liên quan đến lọc an toàn, lỗi tạo sinh, hết thời gian chờ hoặc giao tài nguyên thất bại. Việc thử lại những lỗi này đòi hỏi thận trọng hơn vì lần thử đầu tiên có thể đã tiêu tốn thời gian hoặc tài nguyên tính phí.
4. Sử dụng tính idempotency tại ranh giới của bạn
Gán một ID tác vụ ứng dụng trước khi gọi bất kỳ nhà cung cấp nào. Lưu mọi lần thử của nhà cung cấp dưới ID đó.
Nếu khách hàng thử lại vì hết thời gian chờ mạng, dịch vụ của bạn nên trả về trạng thái tác vụ hiện có thay vì gửi lại một yêu cầu tạo sinh giống hệt. Điều này đặc biệt quan trọng đối với khối lượng công việc video, nơi các bản sao vô tình có thể rất tốn kém.
5. Chuẩn hóa trạng thái của nhà cung cấp
Sản phẩm của bạn không nên hiển thị một máy trạng thái khác nhau cho mỗi mô hình video. Hãy ánh xạ các trạng thái cụ thể của nhà cung cấp vào một tập nội bộ nhỏ như:
queuedrunningsucceededfailed_retryablefailed_terminalcancelled
Lưu trạng thái gốc của nhà cung cấp và lỗi thô để gỡ lỗi, nhưng giữ hợp đồng sản phẩm ổn định.
6. Áp dụng các quy tắc dự phòng có giới hạn
Dự phòng nên được thực hiện có chủ đích, không phải một vòng lặp vô hạn.
Một chính sách thực tế có thể cho phép:
- một tuyến thay thế ngay lập tức sau khi bị từ chối tiếp nhận
- một lần thử lại sau khi tác vụ thất bại nhưng có thể thử lại
- không dự phòng sau khi bị từ chối vì chính sách hoặc an toàn
- không hạ cấp thấp hơn độ phân giải hoặc yêu cầu âm thanh mà người dùng đã nêu rõ
- không gửi lại yêu cầu mới sau khi ngân sách hoặc hạn chót của yêu cầu đã cạn
7. Ghi lại quyết định tuyến
Với mỗi tác vụ, hãy ghi:
- các khả năng được yêu cầu
- tuyến đã chọn và lý do
- các ứng viên bị từ chối và lý do
- ID tác vụ của nhà cung cấp
- dấu thời gian cho hàng đợi, bắt đầu và hoàn thành
- thời lượng và độ phân giải đầu ra
- số tiền tính phí hoặc đơn vị sử dụng
- lịch sử thử lại và dự phòng
Các bản ghi này biến việc định tuyến từ một hộp đen thành một hệ thống sản phẩm có thể kiểm toán.
Giá API Seedance 2.0: xác minh đơn vị trước khi so sánh con số
Cụm từ “Seedance 2.0 API pricing” có thể che giấu một số mô hình tính phí khác nhau. Trước khi so sánh các nhà cung cấp hoặc gateway, hãy xác nhận tất cả những mục sau:
| Trường giá | Cần xác minh gì |
|---|---|
| Đơn vị tính phí | Theo giây tạo ra, theo tài sản, theo credit, hay một đơn vị sử dụng khác |
| Độ phân giải | 720p và 1080p có mức giá khác nhau hay không |
| Thời lượng | Thời lượng tối thiểu, mức tăng, và thời lượng tối đa |
| Âm thanh | Âm thanh đồng bộ có làm thay đổi mức giá hay không |
| Tác vụ thất bại | Các lần tạo thất bại hoặc bị lọc có bị tính phí hay không |
| Thử lại | Mỗi tác vụ nhà cung cấp mới có bị tính phí riêng hay không |
| Lưu trữ | Thời gian lưu giữ đầu ra và chi phí tải xuống hoặc egress |
| Phí nền tảng | Bất kỳ phí gateway, chiết khấu theo cam kết khối lượng, hoặc mức giá doanh nghiệp nào |
Hãy dùng công thức khối lượng công việc này thay vì so sánh một con số nổi bật đơn lẻ:
chi phí tạo hàng tháng =
tổng số giây đầu ra thành công
× đơn giá hiệu dụng mỗi giây
+ chi phí thử lại và thất bại
+ chi phí lưu trữ và phân phối
+ chi phí nền tảng hoặc hỗ trợ
Ví dụ, một sản phẩm tạo ra 10.000 clip thành công mỗi tháng có thể có hiệu quả kinh tế rất khác nhau tùy theo thời lượng trung bình, độ phân giải, tỷ lệ thử lại, và việc có bao gồm âm thanh hay không. Một cải thiện nhỏ ở tỷ lệ thành công ngay từ lần đầu có thể quan trọng hơn một khác biệt nhỏ trong đơn giá được quảng cáo.
Sử dụng trang giá trực tiếp của Flatkey pricing page để xem thông tin gói và mua hàng hiện tại. Với một lần triển khai nghiêm túc, hãy ghi nguồn giá chính xác và ngày kiểm tra vào cùng sổ đăng ký tuyến lưu trữ các khả năng của mô hình.
Di chuyển từ Seedance 2.0 sang Seedance 2.5 mà không làm hỏng sản phẩm
Hãy xem việc nâng cấp mô hình như một thay đổi tuyến có kiểm soát, không phải một phép thay thế chuỗi.
So sánh hợp đồng
Kiểm tra xem tuyến mới có giữ nguyên:
- các loại đầu vào và giới hạn kích thước
- hành vi của prompt
- các tỷ lệ khung hình được hỗ trợ
- thời lượng và độ phân giải đầu ra
- hành vi âm thanh
- ngữ nghĩa trạng thái công việc
- hành vi kiểm duyệt
- thời hạn tồn tại của URL tài sản
- báo cáo chi phí
Chạy đánh giá shadow
Đối với một mẫu nhỏ các yêu cầu đủ điều kiện, hãy gửi cùng một đầu vào đã chuẩn hóa đến cả hai tuyến ngoài đường dẫn quan trọng đối với khách hàng. So sánh tỷ lệ hoàn thành, độ trễ, chất lượng đầu ra, chi phí và kết quả chính sách.
Sử dụng triển khai theo giai đoạn
Chuyển một tỷ lệ nhỏ các công việc tương thích sang tuyến mới hơn. Chỉ giữ tuyến trước đó ở những nơi nó vẫn đáp ứng đầy đủ hợp đồng yêu cầu.
Duy trì khả năng quan sát ở cấp tuyến
Đừng gộp số liệu của Seedance 2.0 và Seedance 2.5 vào một tổng “video” duy nhất. Theo dõi riêng từng phiên bản để một đợt triển khai không che khuất các hồi quy.
Các lỗi tích hợp API Seedance phổ biến
Xem việc tạo video như hoàn thành chat
Các công việc video chạy lâu cần trạng thái bền vững, quản lý hàng đợi và xử lý tài sản. Mẫu yêu cầu đồng bộ sẽ tạo ra các lần hết thời gian chờ mong manh và hành vi thử lại kém.
Dùng tên mô hình làm chính sách dự phòng
seedance-2.5 và seedance-2.0-i2v không thể hoán đổi cho nhau chỉ vì chúng cùng một họ tên. Hãy định tuyến theo khả năng.
Thử lại mà không có tính idempotent
Thời gian chờ của phía khách không chứng minh được rằng nhà cung cấp đã từ chối yêu cầu. Việc thử lại mù quáng có thể tạo ra các công việc tính phí trùng lặp.
Hứa một độ phân giải mà tuyến dự phòng không thể tạo ra
Nếu sản phẩm cam kết 1080p, một tuyến 720p không nên âm thầm thay thế. Hãy xin sự đồng ý của người dùng hoặc thất bại một cách rõ ràng.
Sao chép một mức giá không ghi ngày vào logic sản phẩm
Các trang giá có thể thay đổi. Lưu nguồn giá và ngày đã xác minh, sau đó đặt ngưỡng chi phí có thể cấu hình.
Bỏ qua việc lưu giữ đầu ra
Các URL của nhà cung cấp có thể hết hạn. Hãy sao chép các tài sản đã hoàn tất vào kho lưu trữ được phê duyệt của riêng bạn trước khi hiển thị một URL sản phẩm bền vững.
Danh sách kiểm tra làm mới cho một hướng dẫn mô hình video mới nổi
Các trang về mô hình mới nổi nên có chủ sở hữu làm mới và chu kỳ bằng chứng rõ ràng. Xem lại trang này mỗi khi một phiên bản Seedance lớn ra mắt, và ít nhất hàng tháng trong khi quyền truy cập đang thay đổi nhanh.
Mỗi lần làm mới nên xác minh:
- Thông báo chính thức về mô hình/phiên bản.
- Định danh mô hình hiện tại trong danh mục trực tiếp.
- Hỗ trợ text-to-video và image-to-video.
- Giới hạn về độ phân giải, thời lượng, âm thanh và khu vực.
- Trạng thái truy cập, bao gồm quyền truy cập sớm hoặc yêu cầu allowlist.
- Đơn vị tính giá hiện tại và trang mua hàng.
- Ngữ nghĩa của việc tạo công việc, thăm dò, webhook và hủy.
- Hành vi thử lại, tính phí khi thất bại và lưu giữ đầu ra.
- Trạng thái tuyến công khai và các tuyên bố có ghi ngày trong bài viết.
- Các liên kết nội bộ đến hướng dẫn về giá và định tuyến đa phương thức.
Đó là sự khác biệt giữa một bài viết chỉ xếp hạng trong thời gian ngắn và một tài sản vẫn hữu ích khi nhu cầu tìm kiếm vẫn đang hình thành.
Câu hỏi thường gặp
Có API Seedance 2.0 không?
Có. Seedance 2.0 là một bản phát hành mô hình video chính thức của ByteDance, và quyền truy cập API có sẵn thông qua các tuyến của nhà cung cấp và cổng trung gian. Định danh mô hình, phương thức, khu vực và điều kiện đủ điều kiện của tài khoản phụ thuộc vào đường dẫn truy cập, vì vậy hãy xác minh danh mục trực tiếp trước khi triển khai.
API Seedance 2.0 có hỗ trợ chuyển văn bản thành video và chuyển ảnh thành video không?
Seedance là một họ mô hình video đa phương thức, nhưng từng tuyến API riêng lẻ có thể chỉ hỗ trợ một phương thức cụ thể. Tính đến ngày 27 tháng 7 năm 2026, Flatkey liệt kê seedance-2.0-i2v cho chuyển ảnh thành video và liệt kê seedance-2.5 cho cả chuyển văn bản thành video lẫn chuyển ảnh thành video.
API Seedance 2.0 có giá bao nhiêu?
Câu trả lời phụ thuộc vào nhà cung cấp, tuyến, độ phân giải, thời lượng, chế độ âm thanh và đơn vị tính phí. Hãy xác nhận liệu tuyến đó tính phí theo giây, theo tài sản, theo tín dụng hay theo một đơn vị sử dụng khác, rồi đưa các lần thử lại, lỗi, lưu trữ và phí nền tảng vào ước tính khối lượng công việc.
Seedance 2.5 có thể là phương án dự phòng cho Seedance 2.0 không?
Đó có thể là một ứng viên khi nó đáp ứng cùng phương thức bắt buộc, độ phân giải, âm thanh, khu vực, ngân sách và hợp đồng vận hành. Đừng coi nó là sự thay thế tự động chỉ dựa trên tên họ mô hình.
Điều gì nên kích hoạt một tuyến dự phòng?
Các tác nhân kích hoạt tốt bao gồm tuyến không khả dụng, hạn chế tài khoản, giới hạn tốc độ và các lỗi hạ tầng có thể thử lại. Các từ chối liên quan đến an toàn, khả năng không được hỗ trợ, ngân sách cạn kiệt và thời hạn đã hết thường nên dừng lại thay vì kích hoạt một lần tạo thay thế không kiểm soát.
Bước tiếp theo thực tế
Trước khi chọn một tuyến Seedance, hãy ghi rõ các khả năng mà sản phẩm của bạn cam kết và các mức suy giảm mà nó có thể cho phép. Sau đó xác minh danh mục mô hình đang hoạt động và nguồn giá, chạy một bài kiểm tra công việc bất đồng bộ quy mô nhỏ, và ghi lại ngày của bằng chứng.
Nếu Seedance sẽ đứng cạnh các mô hình video, hình ảnh hoặc ngôn ngữ khác, hãy giữ chi tiết nhà cung cấp sau một lớp định tuyến ổn định. Điều đó giúp nhóm của bạn có một cách được kiểm soát để áp dụng các mô hình mới hơn, duy trì các tùy chọn dự phòng, và làm mới các giả định về quyền truy cập mà không phải xây dựng lại sản phẩm mỗi khi bức tranh mô hình thay đổi.
