WaveSpeedAI

Harga DeepSeek V4: 20-50x Lebih Murah Dari OpenAI (Rincian Biaya)

Harga DeepSeek V4: 20-50x Lebih Murah Dari OpenAI (Rincian Biaya)

Baru-baru ini, saya mencari model yang lebih hemat, sesuatu yang bisa saya panggil berkali-kali tanpa harus memantau meteran setiap jam. DeepSeek V4 terus muncul dalam percakapan dengan pembuat lain, biasanya dengan alis terangkat: “Ini… sangat murah.”

Dora ada di sini. Saya menghabiskan paruh kedua Januari 2026 mengintegrasikannya ke beberapa alur kerja kecil: peringkas penelitian, penulis ulang catatan produk, dan pengorganisir backlog mingguan. Tidak ada yang mewah. Saya peduli tentang bagaimana token diterjemahkan menjadi dolar nyata selama seminggu normal. Inilah yang saya pelajari tentang biaya API DeepSeek V4, diskon yang penting, dan cara sederhana untuk membugetnya sebelum Anda meluncurkan.

Harga DeepSeek Saat Ini

Saya tidak akan berpura-pura angkanya stabil. Harga bergerak, dan berbeda tergantung di mana Anda membeli akses (langsung vs. melalui broker seperti OpenRouter). Jadi, dua titik jangkar:

  • Periksa sumbernya: dokumen API DeepSeek resmi dan halaman harga. Ini adalah tarif kanonik saat Anda terhubung langsung.
  • Jika Anda merutekan melalui marketplace, buka kartu model mereka. Misalnya, model DeepSeek di OpenRouter mencantumkan tarif per-juta token dan diskon berbasis waktu apa pun. Apa yang saya lihat pada akhir Januari 2026 di seluruh penyedia konsisten dalam semangat: DeepSeek V4 berada jauh di bawah model frontier untuk token input dan output. Sentnya yang tepat berbeda-beda. Saya berbagi cara saya bekerja dengan harga daripada membekukannya di tempat.

Tarif Standar

Jika Anda baru dalam penagihan model berbasis penggunaan, dua baris penting:

  • Token input (yang Anda kirim): ditagih per 1 juta token.
  • Token output (apa yang Anda dapatkan kembali): juga ditagih per 1 juta token, biasanya lebih tinggi dari input.

Dalam operasi saya, tarif mentah V4 cukup rendah sehingga lonjakan harian kecil tidak mengganggu. Ini muncul paling banyak dalam pekerjaan batch. Misalnya, pengorganisir backlog mingguan saya mengirim ~20 prompt dari ~3–5K token input masing-masing dan menerima ~1–2K token output. Bahkan dengan tarif sampel konservatif, total untuk keseluruhan operasi tetap berada di zona “uang kopi”.

Dua catatan praktis:

  • Inflasi output diam-diam menyelinap. Jika prompt Anda mendorong pemikiran panjang, baris output dapat menggandakan tagihan Anda. Saya membatasi max_tokens dan merapatkan gaya. Hemat uang, hasil yang lebih baik.
  • Ukuran chunk penting. Jika Anda meringkas dokumen panjang, Anda akan membayar untuk setiap token yang tumpang tindih. Saya beralih dari tumpang tindih 1.600-token menjadi 400 dan tidak kehilangan kualitas.

Diskon Cache Hit (90% off)

Ini mengubah matematika mental saya. Beberapa platform dan vendor model mendukung prompt caching untuk awalan yang diulang. Jika N token pertama prompt Anda tidak berubah (pesan sistem, instruksi bersama, skema), cache hit dapat ditagih dengan diskon yang curam. 90% off adalah angka yang saya lihat didokumentasikan di beberapa implementasi caching vendor (ketersediaan bervariasi: konfirmasi pada halaman harga penyedia Anda).

Apa rasanya ini dalam praktik:

  • Peringkas penelitian saya berbagi pesan sistem panjang yang tetap dan skema alat yang stabil. Hanya teks sumber yang berubah.
  • Setelah panggilan pertama, panggilan berikutnya mencapai cache untuk awalan bersama itu.
  • Pada platform yang menghormati penagihan cache, token yang digunakan kembali itu turun ke tarif yang didiskon.

Dua peringatan dari pengujian:

  • “Dekat” tidak di-cache. Ubah satu baris dalam awalan bersama dan Anda akan melewatkan hit-nya.
  • Skema besar yang tetap membayar sendiri. Jika Anda dapat mengonsolidasikan instruksi dan alat ke dalam awalan yang stabil, lakukan sekali dan manfaatkan cache.

Jika penyedia Anda tidak mengekspos caching, Anda masih bisa mensimulasikan beberapa penghematan dengan memindahkan panduan berulang ke pesan sistem yang lebih pendek dan konsisten dan mengurangi redundansi dari pesan pengguna.

Diskon Off-Peak (75% off)

Beberapa marketplace telah mulai menawarkan diskon berbasis waktu untuk meratakan permintaan. Saya telah melihat jendela off-peak dengan potongan curam (angka seperti 50–75% off muncul, tetapi tergantung pada penjual ulang dan model). Model DeepSeek cenderung berpartisipasi karena ekonomi mereka sudah efisien.

Dua cara ini membantu saya:

  • Saya menjadwalkan pekerjaan backlog mingguan saya untuk jendela off-peak. Beban kerja yang sama, item baris yang lebih rendah.
  • Saya mengumpulkan ringkasan penelitian di malam hari. Latensi tidak penting, tetapi diskonnya penting.

Ini bukan universal. Jika Anda terhubung ke DeepSeek secara langsung, periksa apakah mereka menerbitkan harga apa pun berdasarkan waktu dalam sehari. Jika Anda melalui broker, baca cetakan kecil kartu model. Spread bisa cukup besar untuk mengubah kapan Anda menjalankan hal-hal.

Mengapa DeepSeek Sangat Murah

Saya ingin memahami apakah harga rendah itu adalah hal promosi, atau jika arsitektur benar-benar mendukungnya. Dari apa yang bersifat publik, dua bagian menonjol.

Arsitektur MoE

Model besar DeepSeek yang lebih baru bergantung pada Mixture-of-Experts (MoE). Dalam istilah sederhana: alih-alih membangunkan seluruh otak untuk setiap token, router memilih beberapa subjaringan ahli untuk menanganinya. Anda masih mendapatkan model yang mampu, tetapi hanya sebagian kecil dari parameter yang bekerja per langkah, yang mengurangi komputasi dan biaya.

Mengapa ini penting dalam praktik:

  • Throughput skala lebih baik. Di sisi saya, latensi p95 tetap masuk akal bahkan ketika saya mendorong pekerjaan paralel.
  • Biaya tidak melonjak secara linear dengan kompleksitas. Prompt panjang tidak menghukum sekeras yang mereka lakukan pada model padat yang selalu aktif.

Saya telah menggunakan model MoE lain yang terasa rapuh pada tugas khusus: V4 menangani prompt berat struktur (output JSON, penggunaan alat) tanpa goyah. Ketenangan itu adalah bagian dari cerita biaya juga: lebih sedikit pengulangan, lebih sedikit pengerjaan ulang.

Efisiensi Engram

Dokumen DeepSeek menyebutkan pekerjaan pada penanganan konteks dan efisiensi memori (mereka menyebutkan hal-hal seperti routing perhatian yang ditingkatkan dan penanganan KV cache di beberapa rilis). Saya tidak dapat memverifikasi internalnya, tetapi saya dapat berbagi apa yang saya amati:

  • Prompt konteks panjang tidak menghancurkan throughput pada tes saya di Januari 2026. Saya menjalankan konteks token 32K tanpa perasaan “semuanya menjadi melambat”.
  • Pemformatan deterministik bertahan pada suhu yang lebih tinggi dari yang saya harapkan, yang berarti saya bisa menjaga output lebih pendek tanpa menghancurkan kualitas.

Bacaan saya: harga bukan trik pemasaran. Ini adalah hasil dari arsitektur yang dibangun untuk menjaga komputasi per token rendah, ditambah kemauan untuk melewatkan itu dalam harga stiker. Jika Anda penasaran tentang catatan teknis, mulai dengan dokumen DeepSeek resmi dan makalah tertaut apa pun dari kartu model mereka.

Template Kalkulator Biaya

Saya tidak lagi mengunci anggaran ke sen yang tepat. Saya merencanakan rentang, kemudian menyesuaikan setelah penggunaan nyata stabil. Berikut adalah template yang saya gunakan untuk DeepSeek V4. Ini cukup sederhana untuk dikreasikan ulang di spreadsheet.

Input yang akan Anda isi per beban kerja:

  • Panggilan per hari (atau per batch)
  • Rata-rata token input per panggilan
  • Rata-rata token output per panggilan
  • Tarif input per 1 juta token (dari penyedia Anda)
  • Tarif output per 1 juta token (dari penyedia Anda)
  • Token awalan dapat di-cache per panggilan (0 jika tidak ada)
  • Diskon cache hit (mis., 0,90 untuk 90% off)
  • Pengganda off-peak (mis., 0,25 jika 75% off, jika tidak 1)

Langkah-langkah:

  1. Pisahkan token input yang dapat di-cache dan tidak dapat di-cache.

    • cacheable_input = cacheable_prefix_tokens
    • variable_input = max(avg_input_tokens - cacheable_prefix_tokens, 0)

  2. Hargai bagian yang dapat di-cache pada tarif diskon.

    • cacheable_cost = (cacheable_input / 1.000.000) × input_rate × (1 − cache_hit_discount)

  3. Hargai input variabel pada tarif input penuh.

    • variable_input_cost = (variable_input / 1.000.000) × input_rate

  4. Hargai output pada tarif output.

    • output_cost = (avg_output_tokens / 1.000.000) × output_rate

  5. Jumlahkan per panggilan, kemudian terapkan pengganda off-peak apa pun.

    • raw_cost_per_call = cacheable_cost + variable_input_cost + output_cost
    • cost_per_call = raw_cost_per_call × off_peak_multiplier

  6. Skala berdasarkan volume.

    • daily_cost = cost_per_call × calls_per_day
    • monthly_cost ≈ daily_cost × 30

Contoh kecil yang nyata dari minggu pengujian saya (23–30 Januari 2026):

  • 120 panggilan/hari
  • 3.200 token input/panggilan, di mana 1.800 adalah awalan tetap yang dapat di-cache
  • 1.100 token output/panggilan
  • Tarif contoh: $0,40 per 1 juta input, $1,60 per 1 juta output (ganti dengan yang sebenarnya)
  • Diskon cache hit: 90%
  • Pengganda off-peak: 0,5 (jendela 50% off digunakan melalui penjual ulang)

Matematika (dibulatkan):

  • Biaya cacheable per panggilan = (1.800/1.000.000) × $0,40 × (1 − 0,90) ≈ $0,0000072
  • Biaya input variabel per panggilan = (1.400/1.000.000) × $0,40 ≈ $0,00056
  • Biaya output per panggilan = (1.100/1.000.000) × $1,60 ≈ $0,00176
  • Biaya mentah per panggilan ≈ $0,0023272
  • Disesuaikan off-peak ≈ $0,0011636
  • Harian ≈ $0,14
  • Bulanan ≈ $4,20

Itu bukan kesalahan ketik. Tarif per-juta rendah ditambah caching dan off-peak mengubah layanan “perhatikan meter” menjadi sesuatu yang bisa saya lupakan. Itu tidak menghemat waktu pada awalnya, saya menghabiskan satu jam membuat awalan yang dapat di-cache benar-benar tetap, tetapi setiap panggilan setelahnya menjadi lebih murah.

Beberapa pengaman yang saya simpan di lembar:

  • Tetapkan hard cap pada max_tokens. Inflasi output adalah pembunuh anggaran yang diam-diam.
  • Lacak pengulangan secara terpisah. Pengulangan adalah pengeluaran nyata.
  • Catat rata-rata token mingguan. Penyimpangan token terjadi saat prompt berkembang.

Siapa yang ini cocok untuk:

  • Tim yang menjalankan banyak panggilan kecil yang serupa (ETL, ringkasan, QA).
  • Pembuat dengan pekerjaan batch yang dapat dipindahkan ke off-peak.

Siapa yang mungkin tidak menyukainya:

  • Aplikasi yang memerlukan output streaming panjang sepanjang hari, on-peak. Penghematan menyempit.
  • Penyiapan tanpa dukungan caching. Anda masih akan membayar tarif rendah, tetapi bukan yang bodoh-rendah.

Jika Anda menginginkan titik awal, bangun kembali template di atas dalam alat pilihan Anda. Ini adalah 10 menit penyiapan dan menghemat berjam-jam menebak nanti.

Satu catatan terakhir: jika Anda mencampur penyedia, normalkan semuanya ke “biaya per 1K token” di lembar Anda juga. Ini membuat perbandingan cepat berdampingan lebih mudah ketika Anda memutuskan apakah akan menyimpan V4 dalam loop atau mengganti tugas ke model frontier untuk alasan kualitas.

Saya masih memantau bagaimana jendela off-peak berubah. Akhir-akhir ini mereka telah bergerak lebih awal di malam hari. Bukan masalah untuk pekerjaan batch, hanya sesuatu yang saya pantau.