DeepSeek-V4-Flash-0731: Kenapa Agent AI-nya Makin Tajam

Banyak yang mengira model AI baru harus datang dengan parameter lebih besar, context lebih panjang, atau nama yang makin ribet. Padahal, DeepSeek-V4-Flash-0731 justru menarik karena fondasinya nyaris tidak berubah. Arsitekturnya sama. Ukurannya sama. Tapi kemampuan agent-nya naik jauh. Model besar tetap penting. Tapi saat AI dipakai buat ngoding, menjalankan tool, dan menyelesaikan workflow multi-step di production, yang dicari bukan cuma jawaban pintar. Reliability, latency, throughput, sampai kemampuan tidak nyasar di tengah proses ikut menentukan.

Di situlah DeepSeek-V4-Flash-0731 terlihat: bukan sekadar refresh model, tapi contoh bahwa post-training yang tepat bisa mengubah kualitas agent tanpa memaksa biaya inference ikut meledak.

Build 0731: upgrade tanpa ganti mesin

DeepSeek-V4-Flash-0731 masuk public beta pada 31 Juli 2026 sebagai rilis resmi V4 Flash. Bagi pengguna preview, bagian paling nyaman adalah cara pakainya tidak berubah: model tetap dipanggil dengan nama deepseek-v4-flash. Tidak perlu bongkar endpoint, migrasi payload besar-besaran, atau memisahkan traffic hanya karena versi baru keluar.

Yang berubah ada di belakang layar: re-post-training.

Secara sederhana, model dasarnya sudah punya kemampuan bahasa, coding, reasoning, dan context panjang. Lalu model dilatih lagi supaya lebih disiplin saat menghadapi instruksi rumit, tool call, error, serta pekerjaan yang butuh banyak langkah. Ini bukan perubahan kosmetik seperti gaya jawaban yang lebih enak dibaca. Targetnya lebih dekat ke cara kerja engineer saat menangani task nyata.

Alurnya kira-kira seperti ini:

Baca kebutuhan --> pahami context --> pilih tool --> jalankan aksi --> cek hasil --> perbaiki jika gagal --> lanjutkan task

Di chat biasa, model cukup menjawab satu kali. Di agent workflow, model perlu menjaga arah kerja selama beberapa putaran. Saat command gagal, model harus membaca error. Saat output tool kosong, model perlu memilih langkah berikutnya. Saat requirement ambigu, model tidak boleh langsung mengarang solusi dengan percaya diri.

Agent yang bagus bukan agent yang paling banyak bicara. Agent yang bagus tahu kapan harus bertindak, kapan perlu cek, dan kapan harus berhenti.

DeepSeek menyebut build 0731 punya arsitektur serta ukuran yang sama dengan V4-Flash Preview. Jadi, lompatan performa ini bukan datang dari model yang tiba-tiba dibuat jauh lebih besar. Ini lebih dekat ke proses mengasah model supaya keputusan per langkahnya lebih rapi.

Kenapa agent capability lebih penting dari sekadar code generation

Bikin fungsi, menulis query SQL, atau menjelaskan error stack trace sudah lama jadi kekuatan model bahasa. Tapi pekerjaan engineering jarang selesai di satu output.

Misalnya ada bug checkout yang cuma muncul pada kombinasi diskon dan payment tertentu. Agent yang benar-benar berguna tidak cukup memberi potongan code “mungkin begini.” Agent perlu bisa membaca issue, menelusuri file terkait, menjalankan test, memahami hasil, lalu membuat perubahan yang cukup sempit supaya tidak merusak flow lain.

Workflow-nya biasanya lebih berantakan dari demo:

1. Issue masuk dengan informasi kurang lengkap.

2. Agent membaca log dan mencari area code yang paling relevan.

3. Agent menemukan beberapa kemungkinan penyebab.

4. Agent menjalankan test atau command untuk mempersempit masalah.

5. Patch pertama gagal atau memunculkan regression.

6. Agent membaca output baru lalu mengubah rencana.

7. Agent membuat patch yang lebih aman.

8. Engineer mengecek diff dan memutuskan apakah patch layak merge.

Perbedaan antara “model jago coding” dan “model jago sebagai agent” banyak muncul di langkah 4 sampai 7. Bukan pada syntax.

Masalahnya, environment production tidak pernah serapi benchmark. Ada codebase lama, dependency yang tidak terdokumentasi, test flaky, config rahasia, dan aturan bisnis yang hanya hidup di kepala beberapa orang. Model yang terlalu agresif akan terus mencoba action tanpa arah. Model yang terlalu pasif tidak menyelesaikan pekerjaan.

Di situlah post-training agentic punya nilai. Tujuannya bukan membuat model terlihat lebih cerdas saat demo, tapi membuatnya lebih bisa dipercaya saat loop kerja mulai panjang.

Angka benchmark-nya besar, tapi cara membacanya harus waras

DeepSeek membawa sejumlah benchmark yang fokus pada agent, terminal, coding, dan automation. Angka yang paling sering dibahas adalah Terminal Bench 2.1 sebesar 82,7 dan DeepSWE 54,4. Ada juga skor 76,7 di Cybergym, 70,3 di Toolathlon Verified, serta 54,2 di NL2Repo.

Benchmark ini memberi sinyal jelas: DeepSeek menaruh V4 Flash sebagai model kerja, bukan hanya model chat. Tapi angka vendor tetap perlu diperlakukan sebagai sinyal awal, bukan keputusan akhir untuk memindahkan traffic production.

Ada beberapa alasan.

• Setup evaluasi bisa sangat memengaruhi hasil

• Task publik belum tentu mirip dengan codebase internal

• Benchmark internal perlu dibaca lebih hati-hati

• Cost per token tidak selalu sama dengan cost per task

• Tool integration sering menjadi titik gagal, bahkan saat model dasarnya bagus

DeepSeek menjalankan sebagian benchmark coding-agent dengan DeepSeek Harness mode minimal dan reasoning effort maksimum. Itu wajar untuk menunjukkan batas kemampuan, tapi belum tentu setting yang paling cocok untuk request biasa. Dalam workflow internal, reasoning maksimum untuk setiap task bisa menaikkan latency dan biaya tanpa memberi dampak yang sepadan.

Baca juga PewDiePie Dan Odysseus Mengenal Workspace AI Self Hosted

Evaluasi pihak ketiga juga memberi gambaran yang cukup menarik. Artificial Analysis menempatkan DeepSeek-V4-Flash-0731 pada skor 50 di Intelligence Index, naik 10 poin dibanding V4 Flash sebelumnya. Untuk tugas agentic real-world work, skornya naik dari 1189 menjadi 1559 Elo di GDPval-AA v2.

Yang menarik, perbaikan ini banyak ditopang oleh hallucination rate yang lebih rendah, bukan hanya karena model makin sering menemukan jawaban benar. Ini detail yang layak diperhatikan. Dalam agent workflow, model yang lebih jarang mengarang langkah atau hasil tool bisa lebih berharga daripada model yang kadang terlihat spektakuler tapi tidak konsisten.

Untuk task yang menyentuh repository, API, atau data operasional, jawaban yang hati-hati sering lebih berguna daripada jawaban yang terdengar sangat yakin.

Arsitektur MoE: besar di atas kertas, hemat saat inference

V4 Flash memakai pendekatan sparse mixture-of-experts atau MoE. Total parameternya sekitar 284 miliar, tapi yang aktif saat inference hanya sekitar 13 miliar parameter. Angka ini menjelaskan kenapa model bisa punya kapasitas besar, tapi tetap diposisikan sebagai efficiency model.

Bayangkan model punya banyak kelompok spesialis. Saat menerima token atau tugas tertentu, sistem tidak mengaktifkan semua kelompok sekaligus. Hanya sebagian expert yang dipilih untuk bekerja. Karena itu, compute aktifnya lebih rendah dibanding model dense dengan skala total serupa.

Untuk user API, dampak yang paling terasa ada di tiga area:

• Biaya inference lebih masuk akal

• Throughput berpotensi lebih baik untuk traffic besar

• Model tetap punya ruang kapasitas untuk task yang beragam

Tapi MoE bukan sihir tanpa trade-off. Routing antar expert harus stabil. Infrastruktur serving lebih kompleks. Performa bisa berubah tergantung batching, cache, hardware, dan kondisi traffic. Model dengan parameter aktif rendah juga tidak otomatis selalu lebih cepat di semua kondisi.

Di production, latency tetap dipengaruhi banyak hal:

Ukuran request --> context yang dibawa --> antrean --> batching --> tool latency --> output length

Jadi jangan melihat angka 13B active lalu mengasumsikan semua request pasti ringan. Kalau agent membawa puluhan file, log panjang, hasil tool, dan reasoning panjang, total waktu serta biaya tetap bisa naik.

Namun sebagai strategi produk, kombinasi 284B total dan 13B active cukup masuk akal. DeepSeek tidak mencoba menang lewat label “model terbesar.” Fokusnya lebih ke kualitas agent per biaya inference.

Context 1 juta token: luas, tapi bukan alasan membuang semua data

DeepSeek-V4-Flash-0731 mendukung context hingga 1 juta token. Ini angka besar. Secara praktis, context sepanjang itu bisa menampung codebase yang cukup luas, dokumen panjang, log operasional, percakapan support, atau kumpulan spesifikasi dalam satu request.

Buat task tertentu, ini sangat berguna.

• Review repository yang punya banyak file saling terkait

• Analisis dokumen legal atau policy yang panjang

• Membaca incident timeline beserta log dan catatan on-call

• Menjaga style guide serta requirement produk saat menghasilkan banyak output

• Membuat agent yang perlu menyimpan state dari workflow panjang

Tapi context besar sering disalahpahami sebagai solusi untuk semuanya.

Masalahnya, memasukkan seluruh data ke prompt tidak otomatis membuat model lebih fokus. Kalau informasinya tidak relevan, model tetap perlu menyaring noise. Context yang besar juga bisa memperlambat request dan menambah biaya input.

Pola yang lebih sehat biasanya seperti ini:

1. Ambil dokumen atau file yang relevan lewat retrieval.

2. Buat ringkasan state jika workflow mulai panjang.

3. Masukkan raw detail hanya saat model memang membutuhkannya.

4. Pakai cache untuk instruction dan context yang stabil.

5. Buang output tool yang sudah tidak relevan dari loop berikutnya.

Context besar itu workspace yang luas. Bukan pengganti retrieval, struktur data, atau prompt yang jelas.

Untuk coding agent, misalnya, tidak semua file perlu dibawa sejak awal. Mulai dari issue, entry point, test terkait, dan dependency paling dekat. Kalau model menemukan jalur baru, baru context diperluas. Pendekatan bertahap seperti ini biasanya lebih murah dan lebih mudah diobservasi.

Responses API dan Codex adaptation: detail integrasi yang punya dampak nyata

Build 0731 membawa dukungan native untuk Responses API serta adaptasi untuk Codex. Bagi pengguna chat biasa, ini mungkin terlihat seperti catatan rilis kecil. Buat tim yang sedang membangun agent, ini bagian yang paling praktis.

Format chat completion cocok untuk pola sederhana: kirim messages, bisa respons. Agent modern sering butuh lebih dari itu. Mereka perlu tool calls, hasil tool, state yang berlanjut, structured outputs, dan loop action yang rapi.

Alurnya bisa terlihat seperti ini:

Permintaan user --> model menyusun langkah --> tool dipanggil --> hasil tool masuk --> model mengevaluasi --> action berikutnya --> output akhir

Baca juga MiniMax Design Resmi Dirilis Persaingan AI Makin Sengit

Saat API mendukung format agentic secara native, integrasi tidak perlu terlalu banyak adapter custom. Ini bukan berarti semua masalah hilang. Tapi layer penerjemah yang lebih sedikit biasanya berarti lebih sedikit titik error.

Yang sering kelewat adalah observability. Ketika agent gagal, tim perlu tahu persis masalahnya ada di mana:

• Model memilih tool yang salah

• Argument tool tidak valid

• Tool executor timeout

• Hasil tool gagal diparse

• Prompt state hilang di middleware

• Agent melakukan retry terlalu banyak

• Response akhir tidak konsisten dengan tindakan sebelumnya

Dukungan API yang lebih cocok untuk agent membuat trace ini lebih mudah dirapikan. Dan pada sistem yang menyentuh banyak tools, trace sering lebih penting daripada jawaban final yang terlihat bagus.

Tiga hal yang perlu dicek sebelum integrasi

1. Tool schema discipline Cek apakah model konsisten mengikuti JSON schema, field wajib, tipe data, dan enum. Satu argument salah bisa menghentikan seluruh workflow.

2. Recovery saat gagal Uji kondisi seperti permission denied, timeout, response kosong, atau command gagal. Model yang baik tidak terus mengulang action sama tanpa belajar dari error.

3. Batas tindakan Bedakan action read-only, action yang bisa di-rollback, dan action berisiko tinggi. Jangan memberi akses write penuh hanya karena benchmark terminal-nya tinggi.

Agent capability yang naik harus diikuti permission boundary yang lebih jelas, bukan akses yang lebih bebas.

Harga per token murah, tapi yang penting biaya per task

Harga yang banyak dirujuk untuk DeepSeek-V4-Flash-0731 adalah US0,14 per 1 juta input token dan US0,28 per 1 juta output token. Untuk cache hit input, biayanya dilaporkan jauh lebih rendah. Ini menarik untuk workflow yang terus mengirim system prompt, tool definition, policy, atau

+------------------------------------------------------------+
| ALUR: Harga per token murah, tapi yang penting biaya |
+------------------------------------------------------------+
| [Prompt…] --> [Context…] --> [Beberapa…] --> [Hasil tool…] |
| | |
| v |
| [retry / perbaiki jika gagal] |
+------------------------------------------------------------+

context stabil berulang kali.

Di atas kertas, harganya terlihat sangat kompetitif. Tapi biaya token bukan satu-satunya metrik yang perlu dipantau.

Satu task agent bisa mencakup:

• Prompt awal dan policy

• Context dari codebase atau knowledge base

• Beberapa tool call

• Hasil tool yang masuk lagi sebagai input

• Reasoning dan output intermediate

• Retry jika command gagal

• Final report, patch, atau action

Model murah bisa tetap mahal jika agent terus berputar tanpa menyelesaikan tugas. Sebaliknya, model dengan output token sedikit lebih mahal bisa lebih hemat jika berhasil dalam dua langkah, sementara model lain butuh sepuluh langkah.

Cara menghitung yang lebih realistis:

Biaya per task = token input + token output + tool execution + retry + waktu review manusia

Untuk itu, jangan hanya dashboard token usage. Pantau juga:

Routing effort biar cost tidak bocor

V4 Flash menyediakan opsi reasoning effort seperti low, high, dan max. Jangan pakai max sebagai default untuk semua request. Itu seperti menjalankan full regression test setiap kali mengganti satu copy button.

Pola yang lebih masuk akal:

• Low untuk klasifikasi, ekstraksi, atau summarization sederhana

• High untuk debugging, tool use, dan task coding dengan beberapa dependency

• Max untuk planning sulit, review kompleks, atau agent loop yang benar-benar perlu deliberation panjang

Routing seperti ini membuat model murah tetap murah saat traffic mulai besar. Bukan cuma untuk menghemat budget, tapi juga supaya latency tidak ikut naik tanpa alasan.

Uji dengan task nyata, bukan prompt demo

DeepSeek-V4-Flash-0731 punya sinyal kuat untuk coding dan agent workflows. Tapi sebelum memindahkan traffic production, tes terbaik tetap datang dari pekerjaan yang memang terjadi di tim.

Tidak perlu langsung membuat benchmark internal raksasa. Mulai dari 20 sampai 50 task yang sudah punya outcome jelas.

Contoh set awal:

• Bug kecil yang sudah pernah diperbaiki

• Pull request yang butuh review

• Issue dengan requirement ambigu

• Refactor yang sudah punya test suite

• Incident log untuk root-cause analysis

• Task dokumentasi API

• Workflow tool calling dengan data yang aman

• Kasus permission denied atau timeout yang disengaja

Kemudian nilai bukan cuma jawaban akhirnya.

• Apakah solusi benar dan bisa dijalankan?

• Apakah agent memilih tool yang tepat?

• Apa yang dilakukan saat tool gagal?

• Apakah perubahan yang dibuat terlalu luas?

• Berapa token dan tool call yang dipakai?

• Apakah hasilnya konsisten di beberapa run?

• Apakah agent tahu kapan harus meminta bantuan manusia?

Yang paling penting justru failure mode. Semua model terlihat pintar saat prompt bersih dan environment lancar. Uji saat dokumentasi usang, output tool kosong, test kontradiktif, atau requirement berubah di tengah jalan. Di situ baru terlihat apakah model hanya bagus mengikuti jalur lurus, atau benar-benar bisa bekerja saat sistem mulai berantakan.

Guardrail minimum untuk coding agent

Sebelum agent menyentuh repository atau tool internal, pasang batas dasar ini:

Baca juga Ox Alpha Model AI Terbaru Pesaing Di Industri AI

• Read-only access sebagai default

• Sandbox untuk command execution

• Allowlist command yang boleh jalan

• Timeout untuk setiap command dan workflow

• Budget token per task

• Batas maksimum tool call

• Approval manusia untuk write action

• Audit log untuk perubahan dan tool call

• Kill switch saat agent looping

Guardrail bukan tanda modelnya kurang kuat. Ini cara membuat sistem tetap aman saat capability meningkat. Engineer senior pun tidak seharusnya deploy ke production tanpa review, observability, dan rollback plan. Agent perlu standar yang sama.

Kesimpulan

DeepSeek-V4-Flash-0731 menarik bukan karena mengganti arsitektur, tapi karena memperbaiki cara model bekerja sebagai agent. Kombinasi post-training, tool calling, Responses API, dan biaya inference rendah membuat V4 Flash layak dipertimbangkan untuk coding workflow, automation, serta task multi-step yang butuh context panjang.

Nilai sebenarnya ada pada reliability saat loop mulai rumit: memilih reasoning effort sesuai task, membatasi tool call, dan mengukur cost per successful task, bukan sekadar harga token. Benchmark memberi arah, tapi eval internal tetap penentu. Mulai dari sandbox, task nyata, trace yang rapi, lalu naikkan akses hanya setelah recovery dan guardrail terbukti aman.