Nếu bạn đang kiểm thử prompt trên nhiều hơn một mô hình, việc dự báo chi phí sẽ đổ vỡ ngay khi bạn coi mọi yêu cầu như token chat thông thường. Một nhóm có thể chạy các prompt văn bản ngắn trên gpt-5-mini, các lượt đánh giá dài hơn trên claude-sonnet-4-6, các biến thể hình ảnh trên gpt-image-2, rồi sau đó thêm vài bài kiểm thử video trước khi ra mắt. Đó không phải là một kiểu hóa đơn. Đó là một chồng các loại đơn vị khác nhau, các mô hình retry và các vòng phê duyệt.
Hướng dẫn này cung cấp cho bạn một quy trình kiểm thử prompt đa mô hình thực tế để dự báo chi tiêu API AI trước khi lưu lượng tăng mạnh. Mục tiêu không phải là độ chính xác tài chính hoàn hảo ngay từ ngày đầu. Mục tiêu là ngăn những bất ngờ trong tuần ra mắt bằng cách biến các bài kiểm thử prompt thành một bảng dự báo nhỏ mà nhà sáng lập, người vận hành và trưởng kỹ thuật đều có thể đọc được.
Vào Chủ nhật, ngày 19 tháng 7 năm 2026, trang chủ công khai của Flatkey vẫn mô tả sản phẩm là chỉ API chính thức, được xác minh mỗi giờ, với hơn 160 mô hình frontier sau một khóa và một URL nền tảng tương thích OpenAI tại https://router.flatkey.ai/v1. Trang giá công khai cũng vẫn ghi rằng:
- mỗi lần nạp tiền đều nhận credit thưởng:
+$3cho$10,+$8cho$20, và+$100cho$200 - một số dư có thể định tuyến qua các mô hình GPT, Claude, Gemini, DeepSeek, hình ảnh, âm thanh và video
- mức sử dụng được đo theo mô hình, loại token và nhật ký yêu cầu
Hình dạng sản phẩm đó rất quan trọng vì một quy trình dự báo tốt không chỉ là một bảng giá. Nó cần một nguồn trực tiếp cho các hàng mô hình, một chế độ xem số dư dùng chung, và các nhật ký cho thấy các bài kiểm thử prompt đang thực sự tiêu tiền ở đâu.
Câu trả lời ngắn gọn
Hãy dùng thứ tự này:
- Tách dự báo thành các tuyến văn bản, hình ảnh và video trước khi so sánh giá.
- Dự toán lưu lượng kiểm thử prompt tách biệt với lưu lượng người dùng thực.
- Dự báo một mô hình cơ sở, một mô hình dự phòng và một hệ số vòng phê duyệt cho mỗi tuyến.
- Thêm biên dự phòng cho retry, cache miss và nội dung sáng tạo bị từ chối trước khi nạp tiền.
- Kiểm tra lại trang giá trực tiếp trước khi ra mắt, sau đó khóa giới hạn quota và theo dõi nhật ký yêu cầu sau khi lưu lượng bắt đầu.
Đó là cốt lõi của quy trình kiểm thử prompt đa mô hình. Hầu hết các nhóm bỏ qua bước hai hoặc bốn, rồi tỏ ra ngạc nhiên khi một benchmark trông có vẻ rẻ lại biến thành một vòng phê duyệt đắt đỏ.
Tại sao hầu hết các dự báo kiểm thử prompt đều thất bại
Các nhà sáng lập thường bắt đầu với một câu hỏi đơn giản: "Mô hình này sẽ tốn bao nhiêu nếu chúng ta chạy nó lúc ra mắt?"
Câu hỏi đó quá rộng. Một dự báo hữu ích phải trả lời năm câu hỏi nhỏ hơn:
| Câu hỏi | Nó thay đổi điều gì |
|---|---|
| Đây là các bài kiểm thử prompt nội bộ hay yêu cầu từ người dùng thực? | Khối lượng kiểm thử thường theo kiểu bùng lên theo đợt và lặp lại; lưu lượng khi ra mắt ổn định hơn và khó dự đoán hơn. |
| Kênh này là văn bản, hình ảnh hay video? | Đơn vị tính phí thay đổi, vì vậy một bảng tổng hợp duy nhất sẽ nhanh chóng trở nên gây hiểu lầm. |
| Bạn phê duyệt bao nhiêu biến thể trước khi một đầu ra được phát hành? | Vòng lặp duyệt sáng tạo có thể làm chi phí tăng nhanh hơn cả mức tăng token đơn thuần. |
| Mô hình nào là mặc định và mô hình nào là phương án dự phòng? | Chính sách độ tin cậy có thể làm thay đổi chi phí tổng hợp của bạn ngay cả khi lưu lượng không đổi. |
| Tỷ lệ phần trăm yêu cầu dự kiến là thử lại, cache miss hoặc bị từ chối là bao nhiêu? | Đây là chỗ mà phép tính demo gọn gàng thường bị phá vỡ. |
Nếu bạn bỏ qua những câu hỏi đó, bạn không có dự báo. Bạn chỉ có một mức trung bình đầy hy vọng.
Ảnh chụp nguồn vào ngày phát hành
Quy trình dưới đây chỉ sử dụng các bề mặt công khai của Flatkey được kiểm tra lại vào Chủ nhật, ngày 19 tháng 7 năm 2026.
| Nguồn | Đã kiểm tra vào | Thông tin hữu ích |
|---|---|---|
https://flatkey.ai/ |
Ngày 19 tháng 7 năm 2026 | Trang chủ công khai vẫn ghi chỉ dùng API chính thức, được xác minh theo giờ, một khóa, và hơn 160 mô hình frontier. |
https://flatkey.ai/pricing |
Ngày 19 tháng 7 năm 2026 | Trang giá công khai vẫn ghi bonus credit khi nạp tiền là vĩnh viễn, một số dư dùng cho văn bản/hình ảnh/âm thanh/video, và mức sử dụng được đo theo mô hình, loại token, và nhật ký yêu cầu. |
https://router.flatkey.ai/api/pricing |
Ngày 19 tháng 7 năm 2026 | API giá công khai trả về pricing_version: group-model-ratio-v1, 176 hàng, 175 hàng kiểu token, 1 hàng giá cố định, và các họ endpoint được hỗ trợ cho openai, anthropic, gemini, image-generation, openai-response, openai-video, và video. |
Bảng trực tiếp trên trang chủ vào ngày 19 tháng 7 năm 2026 cũng hiển thị các mức giá đầu vào mẫu, hữu ích cho việc ước tính sơ bộ ngân sách cho kênh văn bản:
| Mô hình | Mức giá đầu vào trên trang chủ công khai |
|---|---|
gpt-5.5 |
$3.33 / M in |
claude-sonnet-4-6 |
$2.00 / M in |
gpt-5.4 |
$1.67 / M in |
claude-opus-4-8 |
$3.33 / M in |
deepseek-v4-flash |
$0.056 / M in |
Hãy xem những con số đó là ví dụ trong ngày phát hành, không phải các hằng số vĩnh viễn. Đây là một bài viết về dự báo, nên quy trình quan trọng hơn bất kỳ mức giá của một ngày đơn lẻ nào.
Quy trình kiểm thử prompt đa mô hình
Bước 1: Tách lưu lượng kiểm thử khỏi lưu lượng ra mắt
Đừng trộn lẫn kiểm thử nội bộ với lưu lượng công khai. Phòng thí nghiệm prompt của bạn thường có:
- nhiều prompt lặp lại hơn
- nhiều lần chạy lại thủ công hơn
- nhiều prompt dài hơn
- nhiều đầu ra bị từ chối hơn
Lưu lượng ra mắt thường có:
- prompt ngắn hơn hoặc được chuẩn hoá hơn
- khối lượng ổn định hơn
- ít lần chạy lại thủ công hơn
- yêu cầu hạn mức chặt chẽ hơn
Bắt đầu với hai bảng riêng biệt:
| Bảng | Mục đích | Người phụ trách điển hình |
|---|---|---|
| Dự báo kiểm thử prompt | Thử nghiệm trước khi ra mắt, so sánh mô hình, vòng phê duyệt | Sản phẩm, vận hành, kỹ sư AI |
| Dự báo lưu lượng ra mắt | Khối lượng người dùng kỳ vọng sau khi phát hành | Nhà sáng lập, tài chính, trưởng bộ phận kỹ thuật |
Nếu bạn chỉ xây một bảng, ngân sách kiểm thử thường sẽ bị ẩn trong ngân sách sản xuất của bạn.
Step 2: Phân tách theo modality trước khi làm bất kỳ phép tính nào
Đây là lúc nhiều đội ngũ mắc sai lầm thực sự đầu tiên. Quy trình text, image và video không nên dùng chung một cột đơn giản "chi phí trên mỗi yêu cầu".
| Lane | Đơn vị chính | Yếu tố dự báo |
|---|---|---|
| Text prompts | input tokens, output tokens, cached tokens | độ dài prompt, độ dài phản hồi, tỷ lệ fallback |
| Tạo ảnh | giá ảnh theo từng mô hình cộng với số lần render lại | số concept trên mỗi ảnh được duyệt, vòng chỉnh sửa, lựa chọn độ phân giải |
| Tạo video | số giây hoặc đơn vị tạo theo từng nhà cung cấp | độ dài clip, render lại, lỗi hàng đợi, vòng phê duyệt |
Các trang công khai của chính Flatkey cũng củng cố sự tách biệt này. Trang giá cho biết một số dư có thể định tuyến qua text, image, audio và video, nhưng điều đó không có nghĩa là chỉ một công thức dự báo nên bao phủ tất cả.
Step 3: Xác định ma trận kiểm thử trước khi ước tính chi phí
Một multi-model prompt testing workflow thực sự bắt đầu với một ma trận kiểm thử, không phải một bảng giá.
Sử dụng một bảng như sau:
| Lane | Mục tiêu | Mô hình mặc định | Mô hình dự phòng | Kiểm thử hằng ngày | Hệ số phê duyệt hoặc thử lại |
|---|---|---|---|---|---|
| Text | so sánh chất lượng chỉ dẫn | claude-sonnet-4-6 |
gpt-5.4 |
500 | 1.10 |
| Text | quét đánh giá hàng loạt chi phí thấp | deepseek-v4-flash |
gpt-5-mini |
2,000 | 1.05 |
| Image | kiểm thử concept sáng tạo | gpt-image-2 |
mô hình ảnh thứ hai từ trang giá trực tiếp | 80 | 2.50 |
| Video | quét prompt trailer ra mắt | dòng video trực tiếp từ /pricing |
dòng video dự phòng từ /pricing |
12 | 1.80 |
Điểm mấu chốt rất đơn giản: hãy dự báo đúng quy trình thực tế bạn sẽ chạy, chứ không phải một kịch bản lý tưởng nơi mọi mô hình chỉ được gọi một lần và luôn được chấp nhận.
Step 4: Dùng phép tính baseline cho text lane trước
Với prompt text, hãy bắt đầu bằng ước tính thận trọng ở phía input. Cách này nhanh hơn và thường đủ để phát hiện các vấn đề ngân sách rõ ràng trước khi bạn xây dựng một mô hình token đầy đủ chi tiết.
Công thức baseline cho text
baseline text spend
= requests
× average input tokens
× input-side price per 1M
÷ 1,000,000
× approval or retry factor
Ví dụ 1: 500 prompt kiểm thử mỗi ngày trên Claude Sonnet 4.6
500 yêu cầu
× 1.800 token đầu vào
× $2.00 / 1M đầu vào
÷ 1.000.000
× 1.10 hệ số thử lại
= $1.98 mỗi ngày chi tiêu đầu vào cơ sở
Ví dụ 2: 2.000 prompt đánh giá chi phí thấp mỗi ngày trên DeepSeek V4 Flash
2.000 yêu cầu
× 1.800 token đầu vào
× $0.056 / 1M đầu vào
÷ 1.000.000
× 1.05 hệ số thử lại
= khoảng $0.21 mỗi ngày chi tiêu đầu vào cơ sở
Điều đó không thay thế cho việc tính toán token đầy đủ. Nó cho bạn một cách kiểm tra nhanh. Nếu mức cơ sở đã có vẻ quá cao, dự báo đầy đủ cũng sẽ không cứu được bạn.
Bước 5: Chỉ thêm dự báo văn bản đầy đủ sau khi mức cơ sở đạt
Khi mức cơ sở có vẻ chấp nhận được, hãy chuyển sang bảng token đầy đủ.
| Biến | Ý nghĩa |
|---|---|
| token đầu vào không được cache | các token của prompt được tính theo mức giá đầu vào thông thường |
| token đầu vào được cache | ngữ cảnh prompt có thể tái sử dụng, được tính theo mức giá cache khi được hỗ trợ |
| token đầu ra | các token được tạo ra |
| tỷ lệ fallback | phần trăm yêu cầu được gửi tới mô hình dự phòng |
| hệ số thử lại | các lần chạy bổ sung do lỗi, chạy lại QA hoặc viết lại prompt |
Công thức văn bản đầy đủ
chi tiêu văn bản mỗi ngày
= yêu cầu
× (
token đầu vào không được cache × đơn giá đầu vào không cache
+ token đầu vào được cache × đơn giá cache
+ token đầu ra × đơn giá đầu ra
)
÷ 1.000.000
× hệ số thử lại
API giá công khai của Flatkey hữu ích ở đây vì cấu trúc từng dòng đã hiển thị riêng các trường cho các thành phần chi phí kiểu token. Ví dụ, vào 19 tháng 7 năm 2026:
| Mô hình | Trường phía đầu vào | Trường phía đầu ra | Trường cache |
|---|---|---|---|
gpt-5-mini |
0.02 |
8 |
0.12 |
claude-sonnet-4-6 |
1.5 |
5 |
0.1 |
gpt-image-2 |
3.325 |
6 |
0.251127819549 |
Hãy dùng dòng trực tiếp cho đúng mô hình bạn đang kiểm thử. Đừng lấy tạm một dòng gần giống chỉ vì nó "có vẻ đủ gần."
Bước 6: Dự báo kiểm thử hình ảnh như các vòng phê duyệt, không phải đầu ra đơn lẻ
Chi phí hình ảnh là nơi nhiều người vận hành đặt ngân sách thấp hơn thực tế. Một hình ảnh hoàn chỉnh có thể che giấu vài lần thử bị từ chối.
Hãy dùng bảng tính này:
| Đầu vào | Ví dụ |
|---|---|
| số khái niệm cần kiểm thử | 20 |
| số lần render trung bình cho mỗi khái niệm | 3 |
| số lần chỉnh sửa trung bình cho mỗi khái niệm được duyệt | 2 |
| tổng số thao tác hình ảnh | 100 |
| dòng giá trực tiếp | lấy từ /pricing vào ngày phát hành |
| biên đệm cho các lần chạy bị từ chối | 15% |
Công thức dự báo hình ảnh
chi tiêu kiểm thử hình ảnh
= tổng số thao tác hình ảnh
× giá mô hình hình ảnh trực tiếp
× biên đệm cho lần bị từ chối
Quy tắc vận hành quan trọng là: không gộp dự báo hình ảnh vào bảng token văn bản. Các trang công khai của Flatkey cho thấy rõ rằng một số dư có thể dùng chung cho cả văn bản và hình ảnh, nhưng ngân sách nội bộ của bạn vẫn cần phép tính riêng cho vòng phê duyệt.
Bước 7: Dự báo kiểm thử video theo thời lượng và hệ số rerender
Kiểm thử prompt video còn dễ bị tính thiếu hơn vì mỗi clip đã được duyệt thường nằm trên nền của nhiều lần tạo sinh thất bại hoặc đã chỉnh sửa.
Trên trang chủ công khai được kiểm tra vào 19 tháng 7, 2026, Flatkey vẫn mô tả việc tạo video là được tính phí theo giây trên cùng số dư trả trước như các mô hình văn bản. Điều đó có nghĩa là bảng tính video của bạn nên trông như sau:
| Input | Ví dụ |
|---|---|
| các ý tưởng cần kiểm thử | 6 |
| số clip trung bình mỗi ý tưởng | 2 |
| thời lượng trung bình | 8 giây |
| hệ số rerender | 1.8 |
| giá theo giây thực tế | lấy từ /pricing vào tuần ra mắt |
Công thức dự báo video
chi phí kiểm thử video
= ý tưởng
× số clip mỗi ý tưởng
× số giây mỗi clip
× giá theo giây thực tế
× hệ số rerender
Một lần nữa, hãy tách riêng video. Đừng giả vờ rằng một clip chỉ là một yêu cầu khác trong bảng tính mô hình văn bản.
Bước 8: Thêm vùng đệm ra mắt trước khi nạp thêm tiền
Sau khi tổng hợp chi phí kiểm thử văn bản, hình ảnh và video, hãy thêm một vùng đệm ra mắt. Trang giá được kiểm tra vào 19 tháng 7, 2026 nêu rõ rằng Flatkey là trả trước và mức sử dụng được tính qua nhật ký yêu cầu. Điều đó khiến vùng đệm trở nên hữu ích về mặt vận hành, chứ không chỉ để sổ sách gọn gàng hơn.
Sử dụng một bảng vùng đệm như sau:
| Rủi ro | Vùng đệm đề xuất |
|---|---|
| thử lại văn bản và cache miss | 10% |
| ảnh bị từ chối hoặc chỉnh sửa thêm | 15% đến 30% |
| rerender video | 20% đến 40% |
| các ẩn số trong tuần ra mắt | 10% |
Sau đó chọn một mức nạp tiền phù hợp với tổng chi phí:
| Tùy chọn nạp tiền | Giá trị trên trang giá công khai vào 19 tháng 7, 2026 |
|---|---|
$10 |
trả $10, nhận $13 credit |
$20 |
trả $20, nhận $28 credit |
$200 |
trả $200, nhận $300 credit |
Đối với các phòng thí nghiệm prompt quy mô nhỏ, câu hỏi đúng không phải là "mức nạp nào rẻ nhất?" Mà là "mức nạp nào giúp vòng kiểm thử tiếp tục chạy mà không buộc phải dừng vận hành giữa lúc chuẩn bị ra mắt?"
Bảng tính đơn giản bạn có thể dùng lại
Sao chép bảng này vào một sheet trước mỗi chu kỳ kiểm thử prompt nghiêm túc.
| Làn | Mô hình | Khối lượng kiểm thử | Đầu vào đơn vị | Nguồn giá | Hệ số thử lại | Chi tiêu ước tính |
|---|---|---|---|---|---|---|
| Văn bản | mô hình chính | số token đầu vào/đầu ra trung bình | hàng giá trực tiếp | |||
| Văn bản | mô hình dự phòng | số token đầu vào/đầu ra trung bình | hàng giá trực tiếp | |||
| Hình ảnh | mô hình hình ảnh chính | số thao tác trên mỗi tài sản đã được phê duyệt | /pricing |
|||
| Video | mô hình video chính | số giây trên mỗi clip đã được phê duyệt | /pricing |
|||
| Đệm | tất cả các làn | tổng phụ × hệ số rủi ro | quy tắc nội bộ |
Nếu bảng này không đầy đủ, dự báo ra mắt của bạn cũng không đầy đủ.
Những gì cần kiểm tra sau ngày đầu tiên có lưu lượng thực
Trang giá cho biết mức sử dụng được đo theo mô hình, loại token và nhật ký yêu cầu. Điều đó có nghĩa là đánh giá ngày đầu tiên của bạn nên trả lời:
- Mô hình nào thực sự xử lý nhiều yêu cầu nhất?
- Lưu lượng dự phòng có khớp với tỷ lệ kỳ vọng không?
- Token đầu ra có lớn hơn đáng kể so với giả định kiểm thử không?
- Nhóm prompt nào tạo ra nhiều lần chạy lại nhất?
- Vòng phê duyệt hình ảnh hoặc video có tốn kém hơn làn văn bản không?
Vòng phản hồi đó là thứ biến một quy trình kiểm thử prompt đa mô hình thành một thực hành quản trị chi phí có thể lặp lại, thay vì chỉ là một bảng tính dùng một lần.
Lỗi thường gặp
| Lỗi | Vì sao nó gây hại |
|---|---|
| trộn văn bản và nội dung đa phương tiện thành một chi phí trung bình cho mỗi yêu cầu | che khuất các động lực thực sự của chi tiêu cho hình ảnh và video |
| dự báo chỉ mô hình mặc định | bỏ qua tác động của cơ chế dự phòng lên hóa đơn |
| dùng khối lượng kiểm thử như thể đó là khối lượng ra mắt | trộn lẫn hành vi tăng đột biến nội bộ với hành vi người dùng thực |
| bỏ qua các vòng phê duyệt | đánh giá thấp chi phí hình ảnh và video nhanh nhất |
| bổ sung mà không có vùng đệm rủi ro | tạo ra gián đoạn có thể tránh được trong tuần ra mắt |
Câu hỏi thường gặp
Tôi có nên bắt đầu với mô hình rẻ nhất không?
Không tự động. Hãy bắt đầu với mô hình phù hợp nhất với công việc, rồi kiểm thử xem một mô hình rẻ hơn có thể gánh một phần lưu lượng mà không làm tăng số lần thử lại, khối lượng công việc QA hoặc khối lượng dự phòng hay không.
Vì sao phải giữ chi phí đa phương tiện ngoài bảng tính token?
Bởi vì việc phê duyệt hình ảnh và video được nhân theo cách khác nhau. Một prompt văn bản có thể chỉ cần một lần thử lại. Một ý tưởng video có thể cần nhiều lần dựng lại trước khi có ai đó phê duyệt.
Khi nào dự báo đủ tốt để ra mắt?
Khi bạn có:
- một đường cơ sở và ước tính văn bản đầy đủ
- các bảng tính hình ảnh và video riêng biệt khi phù hợp
- một mô hình dự phòng được chỉ định cho mỗi làn quan trọng
- quyết định số dư trả trước
- sẵn sàng rà soát hạn mức và nhật ký sử dụng cho ngày đầu tiên
Tôi nên so sánh các hàng mô hình ở đâu trước quyết định cuối cùng?
Sử dụng trang giá Flatkey trực tiếp để xem thông tin lộ trình và thanh toán hiện tại, sau đó so sánh các tùy chọn liền kề trong hướng dẫn so sánh giá mô hình AI hiện có. Trang đầu tiên giúp bạn bắt đầu. Trang thứ hai giúp bạn quyết định những hàng nào đáng để kiểm thử.
