Membaca struktur biaya layanan AI

Layanan AI dijual mirip listrik: kamu membayar pemakaian, bukan barang. Bedanya, satuannya tidak sejelas kilowatt-jam. Ada yang dihitung dari teks yang masuk, ada yang dari teks yang keluar, ada yang hanya muncul saat model diminta berpikir lebih lama, dan ada yang datang dari lapisan perantara di antara keduanya.

Sebab itu tagihan pertama sering terasa seperti kejutan. Bukan karena angkanya besar, melainkan karena kita membandingkan total, padahal yang menentukan total adalah susunan. Kategori ini membahas susunannya, bukan nominalnya: angka bergerak dan selalu perlu diverifikasi ke sumber resmi masing-masing penyedia, sementara komponennya relatif stabil dari bulan ke bulan.

Tiga lapisan yang bergantian muncul di tagihan

Biaya satu fitur AI hampir tidak pernah berasal dari satu tempat. Ada tiga lapisan yang perlu dipisahkan saat membaca tagihan.

Lapisan penyedia model. Ini yang paling terlihat: pemakaian model itu sendiri, dihitung dari teks masuk dan teks keluar. Penyedia berbeda memakai satuan berbeda, dan pemisahan masuk atau keluar penting karena keduanya tidak pernah sama beratnya.

Lapisan perantara. Kalau kamu tidak mendaftar langsung ke penyedia model, biaya melewati satu lapisan lagi: agregator, gateway, atau akun bersama. Di lapisan ini muncul hal yang tidak dibahas di halaman harga mana pun - mata uang saldo, nilai tukar saat pengisian, aturan sisa saldo, dan kebijakan pemakaian minimum.

Lapisan sistem kamu sendiri. Ini yang paling sering terlupa, padahal paling besar. Fitur AI menempel pada server yang tetap menyala, basis data yang tetap tumbuh, penjadwal yang tetap berjalan, dan berkas yang tetap disimpan. Selain itu ada pemakaian yang tidak menghasilkan jawaban apa pun: percobaan ulang saat koneksi gagal, pengujian internal, dan proses yang jalan otomatis tiap beberapa menit.

Baca satu tagihan sebagai tiga kolom, bukan satu angka. Kalau sebuah baris tidak bisa kamu tempatkan di salah satu dari tiga lapisan itu, kamu belum tahu apa yang kamu bayar.

Satuan yang bergerak, dan kenapa artinya berbeda

Sebelum membandingkan penawaran, pahami dulu apa yang dihitung.

Token adalah potongan teks yang menjadi satuan hitung model bahasa. Ia tidak sama dengan kata: satu kata bisa terpecah menjadi beberapa token, dan dua teks yang panjangnya sama bisa menghasilkan jumlah token berbeda. Bahasa, tanda baca, dan format berkas ikut memengaruhi.

Token masuk dan token keluar. Teks yang kamu kirim (perintah, dokumen, riwayat percakapan, hasil pencarian) dihitung terpisah dari teks yang dihasilkan model. Fitur yang gemar melampirkan konteks panjang akan terasa mahal di sisi masuk, sedangkan fitur yang menulis panjang terasa mahal di sisi keluar. Dua fitur bisa terasa sama bagi pengguna, tapi sangat berbeda di tagihan.

Konteks yang di-cache. Sebagian penyedia mengenal pemakaian berulang: kalau awalan perintahnya sama setiap kali dipanggil, bagian yang tidak berubah bisa dihitung lebih ringan daripada diproses ulang dari awal. Ini membuat perancangan perintah ikut memengaruhi biaya, bukan hanya jumlah permintaan.

Input gambar dan audio. Kalau fiturnya menerima gambar, hitungannya berpindah ke ukuran dan tingkat detail. Gambar beresolusi tinggi dan gambar berukuran kecil tidak dihitung sama, dan pengiriman gambar berulang di setiap langkah percakapan biasanya jadi sumber pemakaian yang paling cepat membesar.

Token penalaran. Model yang diminta menalar bisa menghasilkan proses berpikir yang tidak tampil di jawaban akhir, tapi tetap masuk hitungan. Artinya: pengalaman pengguna tidak berubah, tagihan berubah.

Percobaan ulang. Otomasi yang tahan gangguan selalu punya mekanisme coba lagi. Setiap percobaan yang akhirnya gagal tetap memakai sumber daya. Ini masuk kategori biaya yang tidak menghasilkan apa pun bagi pengguna, dan justru sering mendominasi saat sebuah integrasi belum stabil.

Yang biasanya baru terlihat setelah dipakai sungguhan

Perkiraan sebelum rilis hampir selalu meleset, dan biasanya ke arah yang sama.

Riwayat yang tumbuh. Percakapan yang menyertakan seluruh riwayat membuat tiap permintaan baru lebih berat daripada permintaan sebelumnya, meski pertanyaannya sama pendeknya.
Langkah yang berantai. Satu tindakan pengguna bisa memicu beberapa panggilan model berurutan: merangkum, mencari, memeriksa, menyusun. Yang dilihat pengguna satu hasil, yang tercatat beberapa panggilan.
Tetangga yang tidak dikenal. Pratinjau tautan, penguji internal, dan integrasi yang berjalan terjadwal bisa memanggil endpoint yang sama tanpa ada pengguna.
Pekerjaan ulang saat model berganti. Mengganti model atau versinya bukan penggantian nama di satu baris kode. Perintahnya perlu disesuaikan dan diuji ulang. Itu biaya kerja manusia, dan sifatnya berulang setiap kali penyedia memperbarui modelnya.
Pemakaian yang tidak bisa dipecah. Kalau catatan pemakaian hanya tersedia sebagai satu total per akun, kamu tidak bisa menyalahkan atau memperbaiki fitur mana pun. Ini masalah tata kelola yang muncul jauh sebelum masalah anggaran.

Daftar periksa sebelum isi ulang

Ini pertanyaan yang kami ajukan sebelum menambah saldo, semuanya soal aturan, bukan nominal.

Apakah sisa saldo punya masa berlaku? Kalau ya, isi ulang besar-besaran justru mengubah uang menjadi tenggat.
Bagaimana aturan pemakaian minimum dan cara pengisiannya? Ini menentukan berapa sering pekerjaan administratif muncul.
Mata uang apa yang dipakai, dan siapa yang menanggung selisih nilai tukar? Untuk pemakaian bulanan yang stabil, pergerakan kurs masuk ke biaya.
Apakah ada batas atas pemakaian yang bisa disetel? Bisa per akun, per kunci, atau per proyek lebih baik daripada hanya per akun.
Apakah percobaan yang gagal ikut dihitung? Jawabannya mengubah cara kamu menulis mekanisme coba lagi.
Siapa saja yang boleh melihat catatan pemakaian? Kalau hanya satu orang, tim tidak bisa memperbaiki sendiri saat ada lonjakan.
Bisakah pemakaian dipecah per fitur atau per klien? Tanpa ini, keputusan harga ke pelanggan jadi menebak.
Bisakah catatan itu diekspor? Kalau tidak, kamu tidak bisa membandingkan bulan ke bulan setelah penyedia mengubah tampilannya.

Kapan menghitung per pemakaian bukan pilihan yang tepat

Kami tidak menganggap model bayar-per-pakai selalu lebih baik. Ada situasi yang lebih rapi kalau diselesaikan dengan cara lain.

Pemakaiannya kecil dan datar. Untuk kebutuhan yang volumenya sedikit dan stabil, biaya mengurus saldo, memantau, dan mengisi ulang bisa lebih besar daripada selisih yang dihemat. Di titik itu, kesederhanaan lebih bernilai.

Hasilnya harus sama persis setiap kali. Kalau keluarannya wajib identik untuk masukan yang sama, aturan biasa lebih mudah diuji dan jauh lebih murah dioperasikan. Model bahasa bagus untuk variasi, bukan untuk kepastian.

Datanya tidak boleh keluar dari lingkungan sendiri. Memindahkan pemrosesan ke infrastruktur sendiri memindahkan biaya ke tempat lain: mesin, waktu perawatan, dan orang yang menjaganya. Jumlahnya sering lebih besar dan sifatnya permanen, jadi keputusan ini layak dihitung sebagai kepatuhan, bukan sebagai penghematan.

Polanya sudah tetap dan berulang. Kalau sebagian besar permintaan ternyata bisa dipetakan ke beberapa jenis jawaban saja, menggantinya dengan prosedur dan templat biasa akan menghemat lebih banyak daripada upaya menekan harga per satuan.

Ukurannya belum bisa dijawab. Kalau pertanyaan "berapa" belum bisa dijawab tanpa menebak, jangan mulai dari harga. Mulai dari cara mencatat pemakaian, jalankan satu fitur, lalu baca catatannya. Angka yang datang dari pemakaian sendiri selalu lebih berguna daripada perkiraan siapa pun, termasuk dari kami.

Apa yang kami pakai di alur kerja sendiri

Di GenZi, pertanyaan biaya kami tempatkan setelah alurnya jelas, bukan sebelum. Kami menetapkan batas atas di tingkat kunci akses, mencatat pemakaian per fitur supaya bisa dipertanggungjawabkan, dan memperlakukan penggantian model sebagai pekerjaan uji ulang, bukan sekadar penukaran nama. Prinsipnya sederhana: kalau pemakaian tidak bisa dibaca, keputusan biaya hanya jadi tawar-menawar.

Dua catatan lain di situs ini menyambung dari sini: cara memilih proses pertama yang layak diotomasi dan kenapa pilot AI berhenti di tahap demo. Kalau kamu sedang menimbang struktur biaya untuk satu fitur, cakupan pekerjaan kami ada di layanan kami, atau ceritakan alurmu dan kami bantu menilai bagian mana yang layak diukur lebih dulu.