Hóa đơn của Seedance video API hiếm khi bằng "số video sinh ra nhân một mức giá cố định". Cùng là video năm giây, độ phân giải, bậc mô hình, có đầu vào video hay không, thử lại khi thất bại và lưu trữ kết quả đều làm thay đổi chi phí thực tế. Lập ngân sách theo giá niêm yết, sau khi lên production hóa đơn cao hơn, thường không phải do đơn giá tăng mà do các biến số này chưa được tính vào.

Bài viết chia việc tính phí thành bốn chiều: thời lượng, độ phân giải, thử lại và lưu trữ, đồng thời đưa ra công thức ước tính, các bước đo và cách kiểm soát ngân sách. Đơn giá và cách tính cụ thể có thể điều chỉnh; vui lòng lấy giá mô hình trên trang và tài liệu tính phí của nhà cung cấp làm chuẩn.

Ghi chú: Seedance là mô hình tạo video thuộc ByteDance; Seedance, Doubao, Volcengine và BytePlus là nhãn hiệu của các chủ sở hữu quyền tương ứng (ByteDance và các công ty liên kết). Bài viết chỉ nhằm giải thích kỹ thuật, không có quan hệ trực thuộc hay đại lý với các chủ sở hữu quyền. Giá, giao diện và quy tắc tính phí lấy tài liệu gốc và trang giá làm chuẩn.

1. Vì sao không thể lập ngân sách video API theo "số video"

Đơn vị tính phí của API văn bản tương đối thống nhất, còn API video thì không. Một yêu cầu "tạo một video" phía sau có ít nhất bốn biến số: thời lượng, độ phân giải, bậc mô hình và cách đưa đầu vào. Bất kỳ biến nào thay đổi, hóa đơn đều có thể khác.

Rắc rối hơn là gửi một lần không đồng nghĩa nhận được một thành phẩm dùng được. Kiểm duyệt từ chối, hết thời gian, hình ảnh không dùng được đều dẫn đến thử lại; sau khi liên kết kết quả hết hạn còn phải tạo lại hoặc chuyển lưu. Chỉ lập ngân sách theo "số video nhân đơn giá" sẽ hệ thống hóa việc đánh giá thấp chi phí.

2. Bốn chiều tính phí

Chiều Ảnh hưởng chi phí thế nào Cần ghi khi ước tính Cách kiểm soát
Thời lượng Cộng dồn theo giây hoặc token quy đổi; càng dài càng tốn Thời lượng gửi, thời lượng thành phẩm, có chia đoạn không Thử bằng mức ngắn trước, thành phẩm mới ghép
Độ phân giải Tổng điểm ảnh tăng theo độ phân giải, thường cộng thêm ảnh hưởng của khung hình/giây Độ phân giải đầu ra, khung hình/giây, tỷ lệ khung Bản nháp độ phân giải thấp, bản cuối mới nâng
Mô hình và đầu vào Các thế hệ, bậc và cách đưa đầu vào có đơn giá khác nhau Tên mô hình, có khung đầu hay video tham chiếu Phân luồng theo độ khó, không mặc định dùng bậc cao nhất
Thất bại và thử lại Gửi trùng có thể bị tính trùng; quy tắc tác vụ thất bại khác nhau Trạng thái tác vụ, mã lỗi, số lần thử lại Phân loại lỗi, idempotent, giới hạn thử lại
Lưu trữ và lưu lượng Chuyển lưu, giữ và phân phối kết quả phát sinh phí thêm Kích thước tệp, số ngày lưu, lượng truy cập Dọn theo vòng đời, phân phối theo nhu cầu

Các dòng Seedance mới hơn được tài liệu gốc đo theo token; mức tiêu thụ liên quan đến độ phân giải, thời lượng và tình huống đầu vào; một số cổng quy đổi thành hiển thị theo giây hoặc theo video. Hãy xác nhận đơn vị hóa đơn trước khi ký kết.

3. Thời lượng và độ phân giải khuếch đại mức tiêu thụ thế nào

Thời lượng là biến trực quan nhất. Các mức phổ biến là năm giây và mười giây, nhưng mười giây không chắc đúng gấp đôi năm giây: có nền tảng đặt đơn vị tính phí tối thiểu, có nơi tính theo số giây sau khi làm tròn. Lập ngân sách nên dựa trên mức trừ thực tế của hóa đơn, không suy ngược từ thời lượng thành phẩm.

Ảnh hưởng của độ phân giải kín đáo hơn. Từ 720p lên 1080p, tổng điểm ảnh tăng khoảng 2,25 lần; nếu khung hình/giây cũng tăng, mức tiêu thụ tiếp tục lên. Nhưng hóa đơn cuối cùng không chắc thay đổi theo đúng bội số đó, vì bậc mô hình, chiết khấu và làm tròn tính phí đều tham gia. Cách đúng là cố định câu lệnh và thời lượng, chỉ đổi độ phân giải để chạy một nhóm so sánh, ghi lại chênh lệch bị trừ.

Tỷ lệ khung cũng ảnh hưởng tổng điểm ảnh. Màn hình dọc và màn hình ngang ở cùng "bậc độ phân giải" có thể có số điểm ảnh thực tế khác nhau; nên lập ngân sách riêng, đừng dùng chung một giá trị trung bình tháng.

4. Vì sao thử lại và lưu trữ thường bị bỏ sót

Thử lại khi thất bại là phần dễ mất kiểm soát nhất trong chi phí video. Lỗi tham số không nên thử lại; kiểm duyệt từ chối thì gửi lại nhiều lần thường vô ích; chỉ giới hạn tần suất và một số lỗi máy chủ mới phù hợp thử lại có lùi thời gian.

Nên lưu mã tác vụ vào cơ sở dữ liệu, kiểm tra idempotent trước khi gửi, thử lại dùng lại cùng một bản ghi nghiệp vụ. Nếu không, vòng lặp script có thể gửi hàng chục tác vụ giống nhau trong vài phút, hóa đơn sẽ rất khó coi.

Chi phí lưu trữ thì thường bị bỏ qua. Liên kết kết quả thường có thời hạn; hết hạn phải tạo lại; sau khi chuyển sang lưu trữ đối tượng lại phát sinh phí lưu trữ, phí yêu cầu và phí lưu lượng tải xuống. Nên chuyển lưu sau khi thành công và đặt quy tắc dọn dẹp: bản nháp giữ bảy ngày, thành phẩm lưu theo dự án, tư liệu bỏ đi xóa kịp thời.

5. Viết chi phí mỗi video thành công thức

Chỉ số đáng tin hơn "đơn giá nhân thời lượng" là chi phí mỗi video dùng được:

Chi phí mỗi video dùng được = (phí tác vụ thành công + phí tác vụ thất bại nhưng vẫn bị tính + lưu trữ và lưu lượng + kiểm duyệt thủ công) ÷ số video đã duyệt và dùng được

Lưu ý mẫu số là thành phẩm dùng được, không phải số lần gửi. Đoạn mã Python dưới đây quy đổi, số tiền đọc từ hóa đơn, đừng viết cứng trong mã:

def cost_per_usable_video(task_costs, usable_count, storage_cost=0.0, review_cost=0.0):
    """task_costs: số tiền hóa đơn của từng tác vụ; usable_count: số thành phẩm dùng được"""
    if usable_count == 0:
        raise ValueError("Không có thành phẩm dùng được, hãy kiểm tra câu lệnh, tư liệu và tham số")
    total = sum(task_costs) + storage_cost + review_cost
    return total / usable_count

# Thay giá trị giữ chỗ sau khi xuất số tiền từ hóa đơn, giữ nguyên đơn vị
weekly_task_costs = [0.0] * 40
print(cost_per_usable_video(weekly_task_costs, usable_count=28))

Cũng ghi lại mô hình, thời lượng, độ phân giải, trạng thái và thời gian xử lý trong trường mức sử dụng của phản hồi. Cách ghi nhất quán mới so sánh được theo tuần; đừng trộn dữ liệu từ các kênh khác nhau.

6. Các bước chuẩn để đo lô nhỏ

  1. Cố định một bậc mô hình, một thời lượng, một độ phân giải làm đường cơ sở.
  2. Chuẩn bị hai mươi đến ba mươi câu lệnh nghiệp vụ thật và ảnh khung đầu, đừng chỉ dùng mẫu dễ qua.
  3. Ghi từng tác vụ: trạng thái, mã lỗi, thời gian xử lý và mức trừ trên hóa đơn.
  4. Tính tác vụ thất bại vào tổng chi phí, tính ra chi phí mỗi video dùng được.
  5. Quan sát liên tục bảy ngày, ngoại suy chi phí tháng từ giá trị trung bình ngày, cộng thêm lưu trữ, lưu lượng và giờ kiểm duyệt.
  6. Mỗi lần chỉ đổi một biến, ví dụ nâng độ phân giải một bậc, để có độ nhạy chi phí.
  7. Từ kết quả xác định "bậc thử" và "bậc thành phẩm", ghi vào quy định của nhóm.

Giá trị của đo lô nhỏ không chỉ là một con số, mà là biết chi phí nhạy với biến nào nhất.

7. Cách kiểm soát ngân sách cụ thể

  • Mỗi dự án một Key, tách thử nghiệm và production để tránh trộn chi phí.
  • Đặt hạn mức cho Key trong bảng điều khiển và cấu hình cảnh báo mức dùng ngày hoặc tuần.
  • Ước tính một lần theo tham số hiện tại trước khi gửi; vượt ngưỡng mỗi video thì chuyển sang xác nhận thủ công.
  • Giới hạn đồng thời và số lần thử lại tối đa, đặc biệt với script hàng loạt.
  • Bản nháp dùng chung độ phân giải thấp; chỉ cảnh đã duyệt mới tạo bản độ nét cao.
  • Chuyển lưu kết quả kịp thời và đặt vòng đời; đối soát hàng tuần theo dự án, mô hình, độ phân giải.

Phía cổng thường cung cấp hạn mức theo Key, danh sách mô hình cho phép và xuất mức sử dụng; cụ thể lấy bảng điều khiển làm chuẩn. Cảnh báo phải đến được người chịu trách nhiệm; gửi vào nhóm mà không ai xem thì coi như chưa đặt.

8. Thứ tự giảm chi phí và ba hiểu lầm phổ biến

Giảm chi phí nên tiến theo mức ảnh hưởng từ lớn đến nhỏ: nâng tỷ lệ thành công trước, giảm thử lại vô ích, rồi phân tầng độ phân giải và cắt thời lượng, tiếp theo xử lý lưu trữ, cuối cùng mới cân nhắc đổi kênh. Nếu đảo thứ tự, kết cục thường là đơn giá giảm nhưng tỷ lệ thất bại và tổng chi phí lại cao hơn.

Ba hiểu lầm phổ biến:

  1. Chỉ nhìn giá niêm yết, không nhìn tỷ lệ thành công và thử lại. Kênh rẻ nhưng thường thất bại có thể có chi phí mỗi video dùng được cao hơn.
  2. Thử bằng thời lượng ngắn nhất nhưng production dùng thời lượng dài nhất và độ phân giải cao, ngân sách đương nhiên không khớp.
  3. Bỏ qua thời hạn của liên kết kết quả, hết hạn lại tạo lại, tức là trả tiền hai lần.

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

Seedance API tính theo lần, theo giây hay theo token?

Các dòng Seedance mới hơn trong tài liệu gốc thường đo theo token; mức tiêu thụ liên quan đến độ phân giải, thời lượng và cách đưa đầu vào; một số cổng quy đổi thành hiển thị theo giây hoặc theo video. Xác nhận đơn vị hóa đơn trước khi tích hợp và lấy giá mô hình trên trang làm chuẩn.

Độ phân giải từ 720p lên 1080p có làm chi phí gấp đôi không?

Tổng điểm ảnh khoảng 2,25 lần, nhưng mức trừ thực tế còn chịu ảnh hưởng của bậc mô hình, đơn vị tính phí tối thiểu và chiết khấu, không thể nhân đôi đơn giản. Dùng cùng câu lệnh để chạy so sánh sẽ đáng tin hơn.

Tác vụ thất bại hoặc bị kiểm duyệt từ chối có bị trừ tiền không?

Quy tắc khác nhau giữa các nền tảng và nguyên nhân thất bại. Có hệ thống không trừ với lỗi, có nơi tính phí ngay sau khi tạo tác vụ. Xác nhận bằng đơn thử trước khi tích hợp và tính chi phí thất bại vào chi phí mỗi video.

Vì sao lúc thử rất rẻ, lên production hóa đơn tăng nhanh?

Nguyên nhân thường gặp: thử dùng năm giây độ phân giải thấp, production dùng mười giây độ nét cao; thử lại khi thất bại tăng; chuyển lưu và phân phối phát sinh thêm phí; nhiều người dùng chung Key không quy được trách nhiệm. Hãy tách Key theo dự án và ghi hóa đơn theo cấp tác vụ.

Làm sao đặt trần ngân sách cho tạo video?

Ít nhất ba tầng: hạn mức cấp Key, ngân sách cấp dự án, ước tính trước khi gửi ở cấp tác vụ. Khi đạt ngưỡng, tạm dừng tác vụ không quan trọng và thông báo người phụ trách, đừng chỉ dựa vào hóa đơn cuối tháng.

Bước tiếp theo

Trước tiên hãy tạo Key thử nghiệm trên ZSQH AI Gateway, chạy hai mươi đến ba mươi tác vụ với cấu hình thấp nhất, ghi lại tỷ lệ thành công, thời gian xử lý và mức trừ, rồi quy đổi ngân sách tháng theo giá mô hình. Nếu cần hiểu quy trình tác vụ bất đồng bộ trước, có thể đọc tiếp hướng dẫn tích hợp trên trang.

Bài viết liên quan: