Jika Anda menguji prompt di lebih dari satu model, peramalan biaya akan gagal begitu Anda memperlakukan setiap permintaan seperti token chat biasa. Satu tim mungkin menjalankan prompt teks singkat pada gpt-5-mini, sweep evaluasi yang lebih panjang pada claude-sonnet-4-6, varian gambar pada gpt-image-2, lalu beberapa pengujian video sebelum peluncuran. Itu bukan satu bentuk tagihan. Itu adalah tumpukan berbagai jenis unit, pola retry, dan alur persetujuan.
Panduan ini memberi Anda alur kerja pengujian prompt multi-model yang praktis untuk peramalan pengeluaran AI API sebelum trafik meningkat. Tujuannya bukan presisi keuangan yang sempurna di hari pertama. Tujuannya adalah menghentikan kejutan di minggu peluncuran dengan mengubah pengujian prompt menjadi lembar kerja peramalan kecil yang dapat dibaca oleh pendiri, operator, dan pemimpin engineering.
Pada Minggu, 19 Juli 2026, beranda publik Flatkey masih menggambarkan produk sebagai hanya API resmi, diverifikasi setiap jam, dengan 160+ model frontier di balik satu kunci dan satu base URL yang kompatibel dengan OpenAI di https://router.flatkey.ai/v1. Halaman harga publik juga masih menyebutkan:
- setiap isi ulang mendapat kredit bonus:
+$3untuk$10,+$8untuk$20, dan+$100untuk$200 - satu saldo dapat merutekan lintas model GPT, Claude, Gemini, DeepSeek, gambar, audio, dan video
- penggunaan diukur berdasarkan model, jenis token, dan log permintaan
Bentuk produk itu penting karena alur kerja peramalan yang baik bukan sekadar tabel harga. Ia membutuhkan sumber langsung untuk baris model, tampilan saldo bersama, dan log yang menunjukkan di mana pengujian prompt benar-benar menghabiskan uang.
Jawaban singkat
Gunakan urutan ini:
- Pisahkan peramalan ke jalur teks, gambar, dan video sebelum Anda membandingkan harga.
- Perkirakan trafik pengujian prompt secara terpisah dari trafik pengguna nyata.
- Ramalkan satu model baseline, satu model fallback, dan satu pengganda alur persetujuan untuk setiap jalur.
- Tambahkan buffer untuk retry, cache miss, dan materi kreatif yang ditolak sebelum Anda melakukan isi ulang.
- Periksa ulang halaman harga langsung sebelum peluncuran, lalu kunci batas kuota dan pantau log permintaan setelah trafik dimulai.
Itulah inti dari alur kerja pengujian prompt multi-model. Sebagian besar tim melewatkan langkah dua atau empat, lalu terkejut ketika benchmark yang terlihat murah berubah menjadi alur persetujuan yang mahal.
Mengapa sebagian besar peramalan pengujian prompt gagal
Para pendiri biasanya memulai dengan pertanyaan sederhana: "Berapa biaya model ini jika kita menjalankannya saat peluncuran?"
Pertanyaan itu terlalu luas. Peramalan yang berguna harus menjawab lima pertanyaan yang lebih kecil:
| Pertanyaan | Apa yang berubah |
|---|---|
| Apakah ini pengujian prompt internal atau permintaan pengguna nyata? | Volume pengujian biasanya meledak secara sporadis dan repetitif; lalu lintas saat peluncuran lebih stabil dan lebih sulit diprediksi. |
| Apakah jalurnya teks, gambar, atau video? | Satuan penagihan berubah, jadi satu lembar gabungan cepat menjadi menyesatkan. |
| Berapa banyak varian yang Anda setujui sebelum satu output dikirim? | Loop peninjauan kreatif dapat melipatgandakan pengeluaran lebih cepat daripada pertumbuhan token saja. |
| Model mana yang menjadi default dan mana yang menjadi fallback? | Kebijakan keandalan dapat mengubah biaya gabungan Anda bahkan ketika lalu lintas tetap datar. |
| Berapa persentase permintaan yang diperkirakan berupa retry, cache miss, atau penolakan? | Di sinilah matematika demo yang bersih biasanya runtuh. |
Jika Anda melewatkan pertanyaan-pertanyaan itu, Anda tidak punya perkiraan. Anda hanya punya rata-rata yang penuh harap.
Snapshot sumber pada hari publikasi
Alur kerja di bawah ini hanya menggunakan permukaan publik Flatkey yang diperiksa ulang pada Minggu, 19 Juli 2026.
| Sumber | Diperiksa pada | Fakta berguna |
|---|---|---|
https://flatkey.ai/ |
19 Juli 2026 | Beranda publik masih menyatakan hanya API resmi, diverifikasi per jam, satu kunci, dan 160+ model frontier. |
https://flatkey.ai/pricing |
19 Juli 2026 | Halaman harga publik masih menyatakan kredit bonus top-up bersifat permanen, satu saldo mencakup teks/gambar/audio/video, dan penggunaan diukur berdasarkan model, jenis token, dan log permintaan. |
https://router.flatkey.ai/api/pricing |
19 Juli 2026 | API harga publik mengembalikan pricing_version: group-model-ratio-v1, 176 baris, 175 baris bergaya token, 1 baris harga tetap, dan keluarga endpoint yang didukung untuk openai, anthropic, gemini, image-generation, openai-response, openai-video, dan video. |
Papan langsung beranda pada 19 Juli 2026 juga menampilkan contoh tarif sisi input yang berguna untuk penganggaran kasar jalur teks:
| Model | Tarif input beranda publik |
|---|---|
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 |
Anggap itu sebagai contoh pada hari publikasi, bukan konstanta abadi. Ini adalah artikel peramalan, jadi proses lebih penting daripada harga pada satu hari tertentu.
Alur kerja pengujian prompt multi-model
Langkah 1: Pisahkan traffic pengujian dari traffic peluncuran
Jangan mencampur pengujian internal dengan traffic publik. Laboratorium prompt Anda sering memiliki:
- lebih banyak prompt berulang
- lebih banyak rerun manual
- lebih banyak prompt panjang
- lebih banyak output yang ditolak
Traffic peluncuran sering memiliki:
- prompt yang lebih singkat atau lebih ternormalisasi
- volume yang lebih stabil
- lebih sedikit rerun manual
- persyaratan kuota yang lebih kuat
Mulailah dengan dua lembar terpisah:
| Lembar | Tujuan | Pemilik umum |
|---|---|---|
| Forecast pengujian prompt | Eksperimen pra-peluncuran, perbandingan model, siklus persetujuan | Produk, operasi, engineer AI |
| Forecast traffic peluncuran | Volume pengguna yang diharapkan setelah rilis | Pendiri, keuangan, lead engineering |
Jika Anda hanya membuat satu lembar, anggaran pengujian biasanya akan tersembunyi di dalam anggaran produksi Anda.
Langkah 2: Pisahkan berdasarkan modalitas sebelum melakukan perhitungan apa pun
Di sinilah banyak tim membuat kesalahan nyata pertama. Alur kerja teks, gambar, dan video tidak boleh berbagi satu kolom sederhana "biaya per permintaan".
| Jalur | Satuan utama | Pendorong forecast |
|---|---|---|
| Prompt teks | input tokens, output tokens, cached tokens | panjang prompt, panjang respons, tingkat fallback |
| Generasi gambar | harga gambar spesifik model ditambah jumlah rerender | konsep per gambar yang disetujui, loop pengeditan, pilihan resolusi |
| Generasi video | detik atau unit generasi spesifik penyedia | durasi klip, rerender, kegagalan antrean, loop persetujuan |
Halaman publik Flatkey sendiri menegaskan pemisahan ini. Halaman harga menyebutkan satu saldo dapat dirutekan ke teks, gambar, audio, dan video, tetapi itu tidak berarti satu formula forecasting harus mencakup semuanya.
Langkah 3: Tentukan matriks pengujian sebelum memperkirakan biaya
Alur kerja pengujian prompt multi-model yang nyata dimulai dengan matriks pengujian, bukan tabel harga.
Gunakan tabel seperti ini:
| Jalur | Tujuan | Model default | Model fallback | Pengujian harian | Faktor persetujuan atau retry |
|---|---|---|---|---|---|
| Teks | membandingkan kualitas instruksi | claude-sonnet-4-6 |
gpt-5.4 |
500 | 1.10 |
| Teks | sweep evaluasi massal biaya rendah | deepseek-v4-flash |
gpt-5-mini |
2,000 | 1.05 |
| Gambar | pengujian konsep kreatif | gpt-image-2 |
model gambar kedua dari halaman harga live | 80 | 2.50 |
| Video | sweep prompt trailer peluncuran | baris video live dari /pricing |
baris video cadangan dari /pricing |
12 | 1.80 |
Poinnya sederhana: forecast alur kerja aktual yang akan Anda jalankan, bukan fantasi di mana setiap model dipanggil sekali dan selalu diterima.
Langkah 4: Gunakan dulu matematika dasar jalur teks
Untuk prompt teks, mulailah dengan estimasi konservatif di sisi input. Cara ini lebih cepat dan biasanya cukup untuk menangkap masalah anggaran yang jelas sebelum Anda membangun model token yang sepenuhnya terperinci.
Formula dasar teks
pengeluaran teks dasar
= permintaan
× rata-rata token input
× harga sisi input per 1M
÷ 1,000,000
× faktor persetujuan atau retry
Contoh 1: 500 prompt pengujian harian pada Claude Sonnet 4.6
500 permintaan
× 1.800 token input
× $2.00 / 1M input
÷ 1.000.000
× faktor retry 1.10
= $1.98 per hari pengeluaran input baseline
Contoh 2: 2.000 prompt evaluasi berbiaya rendah per hari di DeepSeek V4 Flash
2.000 permintaan
× 1.800 token input
× $0.056 / 1M input
÷ 1.000.000
× faktor retry 1.05
= sekitar $0.21 per hari pengeluaran input baseline
Itu tidak menggantikan pencatatan token penuh. Itu memberi Anda pemeriksaan cepat. Jika baseline saja sudah terlihat terlalu tinggi, proyeksi penuh tidak akan menyelamatkan Anda.
Langkah 5: Tambahkan proyeksi teks penuh hanya setelah baseline lolos
Setelah baseline terlihat dapat diterima, lanjutkan ke lembar token penuh.
| Variabel | Arti |
|---|---|
| token input tidak di-cache | token prompt yang ditagihkan pada tarif input normal |
| token input yang di-cache | konteks prompt yang dapat digunakan kembali dan ditagihkan pada tarif cache jika didukung |
| token output | token yang dihasilkan |
| porsi fallback | persentase permintaan yang dikirim ke model cadangan |
| faktor retry | penjalanan tambahan yang disebabkan oleh kegagalan, pengulangan QA, atau penulisan ulang prompt |
Rumus teks penuh
pengeluaran teks harian
= permintaan
× (
token input tidak di-cache × tarif input tidak di-cache
+ token input yang di-cache × tarif cache
+ token output × tarif output
)
÷ 1.000.000
× faktor retry
API harga publik Flatkey berguna di sini karena struktur barisnya sudah mengekspos bidang terpisah untuk komponen biaya bergaya token. Pada 19 Juli 2026, misalnya:
| Model | Bidang sisi input | Bidang sisi output | Bidang 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 |
Gunakan baris langsung untuk model yang tepat yang sedang Anda uji. Jangan meminjam baris yang dekat hanya karena "terlihat cukup mirip."
Langkah 6: Proyeksikan pengujian gambar sebagai alur persetujuan, bukan keluaran tunggal
Biaya gambar adalah area yang membuat banyak operator menganggarkan terlalu rendah. Satu gambar jadi bisa menyembunyikan beberapa percobaan yang ditolak.
Gunakan lembar kerja ini:
| Input | Contoh |
|---|---|
| konsep yang diuji | 20 |
| rata-rata render per konsep | 3 |
| rata-rata edit per konsep yang disetujui | 2 |
| total operasi gambar | 100 |
| baris harga langsung | ambil dari /pricing pada hari publikasi |
| buffer untuk penjalanan yang ditolak | 15% |
Rumus proyeksi gambar
pengeluaran uji gambar
= total operasi gambar
× harga model gambar langsung
× buffer penolakan
Aturan operasional yang penting adalah ini: jangan paksa prakiraan gambar masuk ke tabel token teks. Halaman publik Flatkey dengan jelas menunjukkan bahwa satu saldo dapat mencakup teks dan gambar, tetapi anggaran internal Anda tetap memerlukan matematika loop persetujuan yang terpisah.
Langkah 7: Perkirakan pengujian video berdasarkan durasi dan faktor rerender
Pengujian prompt video bahkan lebih mudah terhitung kurang karena setiap klip yang disetujui sering berada di atas beberapa generasi yang gagal atau direvisi.
Pada beranda publik yang diperiksa pada 19 Juli 2026, Flatkey masih mendeskripsikan pembuatan video sebagai ditagihkan per detik pada saldo prabayar yang sama seperti model teks. Artinya, lembar kerja video Anda seharusnya terlihat seperti ini:
| Input | Contoh |
|---|---|
| konsep yang akan diuji | 6 |
| rata-rata klip per konsep | 2 |
| durasi rata-rata | 8 detik |
| faktor rerender | 1.8 |
| harga per detik langsung | ambil dari /pricing pada minggu peluncuran |
Formula perkiraan video
pengeluaran uji video
= konsep
× klip per konsep
× detik per klip
× harga per detik langsung
× faktor rerender
Sekali lagi, pisahkan video. Jangan berpura-pura bahwa sebuah klip hanyalah permintaan lain di lembar model teks.
Langkah 8: Tambahkan buffer peluncuran sebelum melakukan top up
Setelah Anda menjumlahkan pengeluaran uji teks, gambar, dan video, tambahkan buffer peluncuran. Halaman harga yang diperiksa pada 19 Juli 2026 secara eksplisit menyebutkan bahwa Flatkey bersifat prabayar dan penggunaan diukur melalui log permintaan. Itu membuat buffer berguna secara operasional, bukan sekadar rapi secara finansial.
Gunakan tabel buffer seperti ini:
| Risiko | Buffer yang disarankan |
|---|---|
| retry teks dan cache miss | 10% |
| penolakan gambar atau edit tambahan | 15% hingga 30% |
| rerender video | 20% hingga 40% |
| ketidakpastian minggu peluncuran | 10% |
Kemudian pilih jumlah top up yang sesuai dengan total:
| Opsi top up | Nilai pada halaman harga publik pada 19 Juli 2026 |
|---|---|
$10 |
bayar $10, dapatkan kredit $13 |
$20 |
bayar $20, dapatkan kredit $28 |
$200 |
bayar $200, dapatkan kredit $300 |
Untuk lab prompt kecil, pertanyaan yang tepat bukanlah "top up mana yang paling murah?" Melainkan "top up mana yang menjaga loop pengujian tetap berjalan tanpa memaksa penghentian operasional di tengah persiapan peluncuran?"
Tabel kalkulator sederhana yang bisa Anda gunakan kembali
Salin ini ke dalam lembar kerja sebelum setiap siklus pengujian prompt yang serius.
| Jalur | Model | Volume pengujian | Input unit | Sumber tarif | Faktor retry | Estimasi pengeluaran |
|---|---|---|---|---|---|---|
| Teks | model utama | rata-rata token input/output | baris harga langsung | |||
| Teks | model fallback | rata-rata token input/output | baris harga langsung | |||
| Gambar | model gambar utama | operasi per aset yang disetujui | /pricing |
|||
| Video | model video utama | detik per klip yang disetujui | /pricing |
|||
| Buffer | semua jalur | subtotal × faktor risiko | aturan internal |
Jika tabel ini tidak lengkap, proyeksi peluncuran Anda juga tidak lengkap.
Apa yang perlu diperiksa setelah hari pertama lalu lintas langsung
Halaman harga menyatakan penggunaan diukur berdasarkan model, jenis token, dan log permintaan. Artinya, tinjauan hari pertama Anda harus menjawab:
- Model mana yang sebenarnya menangani permintaan terbanyak?
- Apakah traffic fallback sesuai dengan porsi yang diharapkan?
- Apakah token output jauh lebih besar daripada asumsi pengujian?
- Family prompt mana yang menghasilkan rerun terbanyak?
- Apakah loop persetujuan gambar atau video biayanya lebih tinggi daripada jalur teks?
Umpan balik itulah yang mengubah alur kerja pengujian prompt multi-model menjadi praktik tata kelola biaya yang dapat diulang, bukan sekadar spreadsheet satu kali pakai.
Kesalahan umum
| Kesalahan | Mengapa ini merugikan |
|---|---|
| mencampur teks dan media menjadi satu biaya rata-rata per permintaan | menyembunyikan pendorong utama pengeluaran gambar dan video |
| memprediksi hanya model default | mengabaikan dampak fallback pada tagihan |
| menggunakan volume pengujian seolah-olah itu volume peluncuran | mencampur perilaku lonjakan internal dengan perilaku pengguna nyata |
| mengabaikan loop persetujuan | paling cepat meremehkan biaya gambar dan video |
| mengisi ulang tanpa buffer risiko | menimbulkan gangguan saat peluncuran yang sebenarnya bisa dihindari |
FAQ
Haruskah saya mulai dengan model termurah?
Tidak secara otomatis. Mulailah dengan model yang paling sesuai untuk tugasnya, lalu uji apakah model yang lebih murah bisa menangani sebagian traffic tanpa meningkatkan retry, pekerjaan QA, atau volume fallback.
Mengapa biaya media harus dipisahkan dari lembar kerja token?
Karena persetujuan gambar dan video berkembang secara berbeda. Prompt teks mungkin hanya memerlukan satu retry. Konsep video mungkin memerlukan beberapa render ulang sebelum ada yang menyetujuinya.
Kapan proyeksi dianggap cukup baik untuk peluncuran?
Ketika Anda memiliki:
- baseline dan estimasi teks penuh
- lembar kerja gambar dan video terpisah jika relevan
- model fallback yang dinamai untuk setiap jalur penting
- keputusan saldo prabayar
- tinjauan kuota dan log penggunaan yang siap untuk hari pertama
Di mana saya harus membandingkan baris model sebelum keputusan akhir?
Gunakan halaman harga Flatkey yang live untuk konteks rute dan penagihan saat ini, lalu bandingkan opsi yang berdekatan dalam panduan perbandingan harga model AI yang sudah ada. Halaman pertama membantu Anda memulai. Halaman kedua membantu Anda memutuskan baris mana yang layak diuji.
