DeepSeek API Akan Naik Harga: Panduan Optimalisasi Biaya untuk Developer

DeepSeek membangun basis pengembangnya dengan tawaran sederhana: model mendekati frontier dengan harga yang membuat biaya token terasa tidak relevan. Pada 6 Agustus 2026, perusahaan mengumumkan bahwa harga API akan naik “dalam waktu dekat” dan kenaikannya diperkirakan “signifikan”. Pengumuman yang pertama kali diliput oleh Dataconomy tidak menyertakan angka, tanggal efektif, maupun rincian per model atau tier harga.

Coba Apidog hari ini

Konteksnya membuat peringatan ini layak ditindaklanjuti. DeepSeek menyebut kenaikan biaya komputasi, keterbatasan kapasitas, dan trafik besar pada V4-Flash serta V4-Pro. Ini merupakan perubahan harga kedua dalam waktu kurang dari sebulan setelah tarif jam sibuk dan di luar jam sibuk diperkenalkan pada pertengahan Juli. Langkah ini juga terjadi ketika V4 Pro 0813 mencapai ketersediaan umum pada 12 Agustus, yang berpotensi meningkatkan permintaan. eWeek membingkai perubahan ini sebagai ujian bagi keunggulan biaya rendah DeepSeek di APAC dan wilayah lain.

Anda tidak dapat mengontrol tarif baru. Namun, Anda dapat mengontrol jumlah token yang dibeli, model yang digunakan, cache-hit rate, waktu eksekusi batch, dan provider yang menangani request. Artikel ini membahas langkah implementasi yang dapat dilakukan sebelum kenaikan berlaku, termasuk simulasi biaya pada skenario 1,5x, 2x, dan 3x.

TL;DR

• DeepSeek mengumumkan kenaikan harga API yang “signifikan” pada 6 Agustus 2026, tanpa angka, tanggal, atau detail per model.
• Pengungkit biaya terbesar adalah cache awalan prompt. Input cache-hit V4-Pro ditagih kurang dari 1% tarif cache-miss.
• Gunakan V4-Flash untuk request sederhana dan bervolume tinggi. Gunakan V4-Pro hanya untuk reasoning yang memang membutuhkan model lebih kuat.
• Pindahkan pekerjaan batch ke jendela di luar jam sibuk yang diperkenalkan DeepSeek pada pertengahan Juli.
• Siapkan provider kedua dan uji failover dengan suite yang sama. Apidog dapat digunakan untuk menjalankan request yang sama ke DeepSeek dan provider cadangan.
• Bahkan dalam skenario spekulatif 3x, output V4-Pro akan bernilai $2,61 per juta token—masih di bawah perbandingan publik $25–30 per juta token untuk pesaing frontier.

Apa yang Diumumkan DeepSeek, dan Apa yang Belum Diumumkan

Informasi resminya terbatas:

• Harga API akan naik “dalam waktu dekat”.
• Kenaikannya disebut “signifikan”.
• Alasannya adalah biaya komputasi, keterbatasan kapasitas, dan trafik tinggi pada endpoint V4-Flash serta V4-Pro.

Hingga 13 Agustus, tarif yang tercantum masih berlaku. Namun, DeepSeek belum menjelaskan:

• Besar kenaikan harga.
• Tanggal efektif.
• Apakah V4-Flash dan V4-Pro naik dengan pengali yang sama.
• Apakah tarif cache-hit dan cache-miss berubah secara proporsional.
• Apakah workload reasoning mendapat perlakuan tarif yang berbeda.

Spekulasi komunitas menyebut rentang 2x hingga 3x, tetapi itu belum dikonfirmasi. Karena itu, rencanakan biaya menggunakan beberapa skenario, bukan satu angka tunggal.

Berikut tarif yang menjadi dasar perhitungan:

Model	Input (cache miss)	Input (cache hit)	Output
DeepSeek V4-Pro	$0.435 / juta token	$0.003625 / juta token	$0.87 / juta token
DeepSeek V4-Flash	$0.14 / juta token	—	$0.28 / juta token

Kedua model memiliki context window 1 juta token. Lihat panduan harga API DeepSeek V4 untuk rincian tarif dan dokumentasi API DeepSeek untuk kartu harga terbaru.

Dua rasio penting dari tabel tersebut:

1. Input cache-hit V4-Pro jauh lebih murah daripada cache-miss.
2. V4-Pro kira-kira 3x lebih mahal daripada V4-Flash, baik untuk input maupun output.

Gunakan dua fakta tersebut sebagai dasar optimasi.

Langkah 1: Ukur Eksposur Biaya per Fitur

Kenaikan harga hanya dapat dihitung jika Anda mengetahui pola penggunaan saat ini. Mulailah dengan mencatat token input, output, dan cache-hit untuk setiap request.

Tambahkan metadata fitur atau endpoint saat memanggil model:

usage = response.usage

log.info("llm_call", extra={
    "feature": "ticket-summarizer",
    "model": "deepseek-v4-flash",
    "input_tokens": usage.prompt_tokens,
    "output_tokens": usage.completion_tokens,
    "cache_hit_tokens": usage.prompt_cache_hit_tokens,
})

Minimal, dashboard Anda perlu menjawab pertanyaan berikut per fitur:

• Fitur mana yang paling banyak menghabiskan token?
• Berapa proporsi input yang mendapat cache hit?
• Berapa banyak request V4-Pro yang sebenarnya dapat dipindahkan ke V4-Flash?
• Pada pengali tarif berapa fitur tertentu tidak lagi memenuhi unit economics?

Gunakan ambang terakhir sebagai batas keputusan untuk migrasi atau failover. Untuk pola atribusi biaya per fitur, lihat cara melacak pengeluaran API OpenAI per fitur. Pola instrumentasinya dapat diterapkan ke DeepSeek.

Contoh query agregasi harian yang dapat Anda gunakan di data warehouse:

SELECT
  feature,
  model,
  DATE(created_at) AS day,
  SUM(input_tokens) AS input_tokens,
  SUM(output_tokens) AS output_tokens,
  SUM(cache_hit_tokens) AS cache_hit_tokens
FROM llm_usage
WHERE provider = 'deepseek'
GROUP BY feature, model, DATE(created_at)
ORDER BY day DESC, input_tokens DESC;

Langkah 2: Maksimalkan Cache Hit dengan Awalan Prompt yang Stabil

DeepSeek melakukan caching otomatis pada awalan prompt. Jika bagian awal request sama dengan request sebelumnya, token tersebut dapat ditagih dengan tarif cache-hit.

Pada V4-Pro:

• Cache miss: $0.435 / juta token
• Cache hit: $0.003625 / juta token

Diskonnya besar, tetapi bergantung pada struktur prompt yang konsisten. Tidak ada flag cache yang perlu diaktifkan. Yang perlu dijaga adalah urutan dan isi token di awal prompt.

Jika Anda baru menggunakan teknik ini, baca apa itu prompt caching dan cara kerjanya.

Susun prompt: statis di awal, dinamis di akhir

Gunakan urutan berikut:

1. System prompt statis
2. Aturan/policy statis
3. Definisi tools statis
4. Few-shot examples statis
5. Dokumen atau konteks dinamis
6. Pesan pengguna terbaru

Contoh struktur yang lebih aman untuk cache:

messages = [
    {
        "role": "system",
        "content": SYSTEM_PROMPT,  # harus identik pada setiap request
    },
    {
        "role": "system",
        "content": TOOL_DEFINITIONS,  # urutan tool harus deterministik
    },
    {
        "role": "system",
        "content": FEW_SHOT_EXAMPLES,
    },
    {
        "role": "user",
        "content": f"Context:\n{retrieved_context}\n\nQuestion:\n{user_question}",
    },
]

Hindari elemen berikut di awal prompt:

• Timestamp.
• Request ID.
• Nama pengguna atau sapaan yang dipersonalisasi.
• Metadata sesi.
• Tool list dengan urutan yang berubah-ubah.
• JSON yang key order-nya tidak deterministik.

Contoh yang buruk:

system_prompt = f"""
Tanggal saat ini: {datetime.now().isoformat()}
Request ID: {request_id}
Anda adalah asisten untuk {user_name}.
"""

Contoh yang lebih baik:

system_prompt = """
Anda adalah asisten yang menjawab berdasarkan konteks yang diberikan.
Ikuti format output yang telah ditentukan.
"""

user_context = f"""
Nama pengguna: {user_name}
Tanggal saat ini: {current_date}
Request ID: {request_id}

Konteks:
{retrieved_context}

Pertanyaan:
{user_question}
"""

Hitung cache-hit rate dari respons

DeepSeek melaporkan data cache pada objek usage. Anda dapat menghitung cache-hit rate seperti ini:

u = response.usage

total_prompt_tokens = (
    u.prompt_cache_hit_tokens +
    u.prompt_cache_miss_tokens
)

hit_rate = (
    u.prompt_cache_hit_tokens / total_prompt_tokens
    if total_prompt_tokens else 0
)

Catat nilainya per fitur:

log.info("deepseek_cache_metrics", extra={
    "feature": "ticket-summarizer",
    "cache_hit_tokens": u.prompt_cache_hit_tokens,
    "cache_miss_tokens": u.prompt_cache_miss_tokens,
    "cache_hit_rate": hit_rate,
})

Jika fitur dengan prompt berulang memiliki cache-hit rate rendah, audit bagian awal prompt. Untuk agen multi-turn, dampaknya lebih besar karena riwayat percakapan sering dikirim ulang pada setiap giliran.

Langkah 3: Rute Berdasarkan Bentuk Tugas

Jangan gunakan satu model sebagai default untuk semua use case. V4-Pro masuk akal untuk reasoning yang kompleks, tetapi mahal untuk pekerjaan mekanis seperti klasifikasi atau transformasi JSON.

Gunakan matriks routing berikut:

Bentuk workload	Rute yang disarankan
Klasifikasi, ekstraksi, pemformatan, intent routing	V4-Flash, reasoning minimal
Ringkasan, jawaban RAG, draft awal	Mulai dari V4-Flash; naikkan ke Pro jika evaluasi gagal
Agent loop multi-langkah, debugging kompleks, analisis arsitektur	V4-Pro, dengan anggaran reasoning

Implementasikan router sederhana di level aplikasi:

def choose_model(task_type: str) -> str:
    flash_tasks = {
        "classification",
        "extraction",
        "formatting",
        "intent-routing",
        "summarization",
        "rag-answer",
    }

    if task_type in flash_tasks:
        return "deepseek-v4-flash"

    return "deepseek-v4-pro"

Untuk tugas yang kualitasnya tidak pasti, gunakan pola fallback berbasis evaluasi:

result = call_model(
    model="deepseek-v4-flash",
    prompt=prompt,
)

if not passes_quality_check(result):
    result = call_model(
        model="deepseek-v4-pro",
        prompt=prompt,
    )

Batasi token reasoning pada rute sederhana

Token reasoning ditagih sebagai token output. Pada V4-Pro, output adalah komponen tarif paling mahal dalam tabel: $0.87 / juta token.

Karena itu:

• Gunakan reasoning minimal atau tanpa reasoning untuk klasifikasi.
• Gunakan format output terstruktur agar respons tidak bertele-tele.
• Batasi max_tokens sesuai kebutuhan endpoint.
• Reservasikan reasoning mendalam untuk workflow yang memang terbukti membutuhkannya.

Contoh kontrak output untuk ekstraksi:

Kembalikan JSON valid saja.
Jangan tambahkan penjelasan.
Gunakan schema berikut:

{
  "category": "string",
  "priority": "low|medium|high",
  "summary": "string"
}

Jangan menurunkan model hanya berdasarkan intuisi. Pindahkan satu route ke V4-Flash, jalankan evaluation suite, lalu pertahankan perubahan jika kualitas tetap memenuhi threshold.

Langkah 4: Pindahkan Pekerjaan Batch ke Jendela di Luar Jam Sibuk

DeepSeek memperkenalkan harga jam sibuk dan di luar jam sibuk pada pertengahan Juli. Jadwal dan diskon aktif dapat diperiksa di dokumentasi API DeepSeek.

Identifikasi workload yang tidak membutuhkan respons real-time:

• Evaluasi model malam hari.
• Prompt regression test di CI.
• Pelabelan dataset.
• Backfill ringkasan atau enrichment.
• Proses embedding ulang.
• Analisis dokumen periodik.

Alih-alih menjalankannya segera, masukkan workload ke antrean dan lepaskan pada jendela yang sesuai.

Contoh worker sederhana:

from datetime import datetime, timezone

def should_run_batch(now: datetime) -> bool:
    # Sesuaikan dengan jendela off-peak yang dipublikasikan DeepSeek.
    return now.hour >= 0 and now.hour < 8

def process_queue():
    now = datetime.now(timezone.utc)

    if not should_run_batch(now):
        return

    while job := dequeue_batch_job():
        run_deepseek_job(job)

Langkah ini tidak mengubah kualitas output karena prompt dan model tetap sama; yang berubah hanya waktu eksekusi. Namun, DeepSeek belum menjelaskan apakah selisih harga off-peak akan tetap sama setelah kenaikan tarif. Gunakan diskon saat ini, lalu verifikasi kembali ketika tarif baru diumumkan.

Langkah 5: Siapkan Provider Kedua dan Uji Failover

Optimasi token mengurangi biaya, tetapi tidak menghilangkan risiko perubahan tarif atau kapasitas. Siapkan provider kedua sebelum Anda membutuhkannya.

Tujuannya bukan langsung memindahkan seluruh trafik. Tujuannya adalah memastikan aplikasi Anda dapat:

1. Mengirim request ke provider cadangan.
2. Menjalankan evaluation suite yang sama.
3. Membandingkan kualitas, latensi, dan biaya.
4. Mengalihkan route tertentu melalui konfigurasi, bukan refactor darurat.

Pisahkan konfigurasi provider dari kode bisnis:

PROVIDERS = {
    "deepseek": {
        "base_url": "https://api.deepseek.com",
        "model": "deepseek-v4-pro",
    },
    "backup": {
        "base_url": "https://provider-backup.example.com",
        "model": "backup-model",
    },
}

def get_llm_config(provider_name: str):
    return PROVIDERS[provider_name]

Kemudian gunakan feature flag atau environment variable untuk mengatur route:

provider = os.getenv("LLM_PROVIDER", "deepseek")
config = get_llm_config(provider)

response = client.chat.completions.create(
    base_url=config["base_url"],
    model=config["model"],
    messages=messages,
)

Jika Anda menggunakan OpenRouter, periksa harga model DeepSeek yang ditampilkan secara independen dan gunakan sebagai salah satu opsi pembanding. Jalankan request yang sama terhadap provider utama dan cadangan melalui environment terpisah di Apidog, lalu simpan hasil evaluasinya.

Simulasi Tagihan pada Kenaikan 1,5x, 2x, dan 3x

Bagian ini adalah ilustrasi, bukan prediksi. DeepSeek belum mengumumkan pengali tarif. Tabel berikut mengasumsikan semua tier naik secara proporsional.

Contoh workload bulanan:

• V4-Pro

  • 400 juta token input.
  • Cache-hit rate 60%.
  • 60 juta token output.
  • Biaya dasar: $69.60 cache miss + $0.87 cache hit + $52.20 output = $122.67.

• V4-Flash

  • 600 juta token input.
  • 120 juta token output.
  • Biaya dasar: $84.00 input + $33.60 output = $117.60.

Total biaya dasar: $240.27.

Kolom “Dioptimalkan” menerapkan langkah cache dan routing:

• Cache-hit rate V4-Pro naik dari 60% menjadi 85%.
• Output V4-Pro turun dari 60 juta menjadi 45 juta token.
• Biaya V4-Pro menjadi $26.10 cache miss + $1.23 cache hit + $39.15 output = $66.48.
• Biaya V4-Flash tidak berubah.
• Total biaya menjadi $184.08.

Skenario tarif	Tagihan tidak optimal	Dioptimalkan (Langkah 2–3)
Tarif saat ini	$240	$184
Kenaikan 1.5x	$360	$276
Kenaikan 2x	$481	$368
Kenaikan 3x	$721	$552

Bacalah tabel secara diagonal: workload yang sudah dioptimalkan pada kenaikan 2x ($368) hampir setara dengan workload yang belum dioptimalkan pada kenaikan 1,5x ($360).

Penghematan struktural ikut meningkat bersama tarif:

• Hemat sekitar $56 pada tarif saat ini.
• Hemat sekitar $168 pada skenario 3x.

Diskon off-peak belum dimasukkan ke simulasi karena nilainya bergantung pada jadwal tarif aktif. Karena itu, kolom optimasi dapat dianggap sebagai estimasi konservatif.

Kapan Beralih Model Lebih Baik daripada Optimasi?

Bahkan dalam skenario spekulatif 3x, output V4-Pro menjadi $2.61 / juta token. Perbandingan publik menempatkan output pesaing frontier pada kisaran $25–30 / juta token. Dengan kata lain, kenaikan tarif tidak otomatis membuat DeepSeek tidak kompetitif.

Tetap gunakan dan optimalkan DeepSeek jika:

• DeepSeek masih memenuhi quality threshold pada evaluation suite Anda.
• Banyak trafik Anda dapat memperoleh cache hit.
• Sebagian workload dapat dipindahkan ke V4-Flash.
• Anda memiliki waktu untuk memperbaiki routing dan struktur prompt.

Pertimbangkan migrasi atau pembagian trafik jika:

• Cache-hit rate secara struktural rendah karena setiap request selalu membawa dokumen panjang yang unik.
• Anda membayar V4-Pro untuk pekerjaan yang lulus evaluasi dengan model lebih kecil.
• Pengali tarif baru melewati ambang unit economics yang dihitung pada Langkah 1.
• Provider kedua memberi hasil lebih baik untuk route tertentu dalam evaluasi Anda.

Bagi sebagian besar tim, solusi terbaik kemungkinan hibrida:

• Pertahankan DeepSeek pada route dengan biaya per evaluasi lulus yang kuat.
• Pindahkan route yang lebih cocok untuk model lain.
• Jalankan suite paritas secara berkala agar perubahan harga berikutnya hanya menjadi perubahan konfigurasi.

Kesimpulan

DeepSeek telah memberi sinyal bahwa harga API akan naik, tetapi belum memberikan detail yang cukup untuk membuat satu prediksi biaya yang pasti. Jangan menunggu pengumuman berikutnya untuk bertindak.

Prioritaskan pekerjaan berikut:

1. Instrumentasikan biaya token per fitur dan per model.
2. Stabilkan awalan prompt agar cache-hit rate meningkat.
3. Rute tugas mekanis ke V4-Flash.
4. Batasi output dan reasoning pada endpoint sederhana.
5. Jalankan workload batch pada jendela di luar jam sibuk.
6. Uji provider cadangan sebelum failover diperlukan.

Sebagian besar langkah ini dapat diselesaikan dalam hitungan hari, bukan sprint panjang. Untuk menguji failover dalam satu workflow, unduh Apidog secara gratis: buat test suite sekali, arahkan ke api.deepseek.com dan provider cadangan menggunakan environment terpisah, lalu jadwalkan pengujian agar keduanya tetap tervalidasi saat informasi harga berkembang.