Melakukan benchmarking pada model di leaderboard yang luas hanya memberi tahu Anda seberapa baik model tersebut menangani trivia dan tes terstandarisasi. Hal itu hampir tidak memberi tahu apa pun tentang bagaimana model tersebut akan bernalar melalui masalah yang berantakan dan terkendala yang sebenarnya dihadapi oleh sistem produksi Anda. Sebelum Anda merilis model bahasa besar (LLM) apa pun ke pengguna, Anda memerlukan kerangka pengujian (harness) yang menguji pola kognitif spesifik yang dibutuhkan aplikasi Anda. Benchmark penalaran adalah tempat di mana model membedakan dirinya dari chatbot.

Panduan ini akan memandu Anda membangun benchmark penalaran yang terfokus dari awal. Anda akan membandingkan tiga arsitektur yang berbeda: DeepSeek R1 671B MoE, Llama 3.3 70B, dan Qwen 3 32B. Alih-alih merakit klaster GPU sendiri, Anda akan menjalankan ketiganya melalui Oxlo.ai. Untuk evaluasi, Anda akan menggunakan Kimi K2.6 sebagai juri untuk menilai output berdasarkan kejelasan penalaran, kebenaran, dan kualitas kode.

Mengapa Penalaran Menjadi yang Pertama Gagal

Kegagalan produksi jarang terlihat seperti kesalahan tata bahasa atau penolakan. Kegagalan tersebut tampak seperti kesalahan logika yang halus. Sebuah model mungkin menghasilkan prosa yang meyakinkan sambil salah memahami batasan, melewatkan langkah, atau mengubah variabel secara diam-diam di tengah proses. Benchmark publik sering kali lebih mengutamakan keluasan daripada kedalaman, sehingga sebuah model dapat memperoleh skor tinggi tanpa pernah menyelesaikan masalah kombinatorial yang sulit.

Benchmark yang ditargetkan memaksa masalah tersebut muncul. Ia memberikan tugas optimasi terkendala yang sama kepada setiap model, menuntut rantai pemikiran (chain of thought) yang dapat ditelusuri, dan mengukur apakah solusi yang dihasilkan benar-benar memenuhi aturan. Jika sebuah model tidak dapat bernalar secara konsisten melalui matematika diskrit, ia juga tidak akan dapat menangani alokasi inventaris, mesin penjadwalan, atau router sumber daya Anda secara andal.

Model dan Platform

DeepSeek R1 671B MoE menggunakan desain mixture-of-experts. Hanya sebagian kecil dari 671 miliar parameternya yang aktif untuk setiap token tertentu, yang mengubah kurva biaya-terhadap-performa dan terkadang tekstur penalaran model tersebut. Llama 3.3 70B adalah model padat (dense model), dan Qwen 3 32B berada pada skala yang lebih kecil dengan kemampuan multibahasa dan coding yang kuat. Membandingkan ketiganya akan memberi tahu Anda apakah kualitas penalaran sejalan dengan jumlah total parameter, jumlah parameter aktif, atau metodologi pelatihan.

Oxlo.ai menghosting model-model ini di balik API yang terpadu. Anda tidak perlu mengelola infrastruktur inferensi atau berurusan dengan perjanjian penyedia yang terpisah. Platform ini juga menggunakan harga per-permintaan (per-request) alih-alih harga per-token. Prompt sistem sepanjang dua ribu kata biayanya persis sama dengan satu baris kalimat yang singkat. Detail tersebut lebih penting daripada kedengarannya. Ini berarti Anda dapat menulis instruksi yang menyeluruh, menyertakan persyaratan format yang mendetail, dan menyematkan contoh few-shot tanpa khawatir biaya token input membengkak. Anda membayar untuk pemanggilan (call), bukan untuk keberlebihan kata (verbosity).

Anda akan memerlukan Python 3.10 atau yang lebih baru, library OpenAI Python, dan kunci API Oxlo.ai.

Langkah 1: Terhubung ke Endpoint

Karena Oxlo.ai menyediakan API yang kompatibel dengan OpenAI, integrasinya sangat mudah. Arahkan OpenAI SDK ke URL dasar Oxlo, masukkan kunci API Anda, dan verifikasi koneksi dengan permintaan ringan ke DeepSeek R1. Jangan lewatkan pemeriksaan kelayakan (sanity check). Konfirmasikan latensi, konfirmasikan bahwa pengenal model dikenali, dan pastikan lingkungan Anda dapat melakukan streaming atau buffering format respons yang ingin Anda simpan. Setelah jabat tangan (handshake) berhasil, Anda memiliki satu klien yang dapat mengakses ketiga model tersebut hanya dengan mengubah satu string.

Langkah 2: Desain Tugas

Pilih masalah yang menuntut logika langkah demi langkah dan memiliki jawaban yang dapat diukur secara objektif. Bin-packing bekerja dengan sangat baik. Ini adalah masalah NP-hard, yang berarti heuristik greedy akan gagal dengan cara yang dapat diprediksi, dan ini memaksa model untuk melacak beberapa batasan secara bersamaan. Barang dengan berbagai ukuran harus muat ke dalam wadah dengan kapasitas tetap tanpa melebihi batas.

Susun prompt agar model harus melakukan dua hal: menjelaskan proses penalarannya, lalu memberikan kode Python yang berfungsi untuk menyelesaikan kasus tersebut. Gunakan prompt sistem yang secara eksplisit mengharuskan model untuk menunjukkan rantai pemikirannya (chain-of-thought) sebelum menulis kode apa pun. Hal ini sangat penting terutama untuk DeepSeek R1, yang dioptimalkan untuk jejak penalaran yang panjang. Anda ingin melihat apakah model tersebut benar-benar memikirkan pemeriksaan kapasitas atau hanya mencocokkan pola dari data pelatihan. Tugas yang baik harus cukup bersifat adversarial sehingga respons berbasis template akan gagal.

Langkah 3: Jalankan Benchmark

Feed the identical prompt to DeepSeek R1, Llama 3.3 70B, and Qwen 3 32B. Capture the full text responses, not just the final code blocks. Store them with timestamps and model identifiers. Since Oxlo.ai prices per request, you do not need to truncate your prompt or strip out clarifying instructions to save money. You can afford to be precise. That stability allows you to iterate on prompt design without cost anxiety, which leads to cleaner experiments and more reproducible results.

Run each model multiple times if your budget allows. Reasoning models can vary across stochastic generations, and you want to know whether a high score represents consistent competence or a lucky sample.

Step 4: Grade with an LLM Judge

Manual scoring does not scale, but numeric rubrics alone miss nuance. The middle ground is an LLM judge. Here, you will use Kimi K2.6. Feed it the original problem, the rubric, and each candidate response. Ask it to evaluate three specific dimensions:

  • Reasoning clarity: Does the explanation actually trace the logic, or does it hand-wave?
  • Correctness: Does the proposed solution satisfy all stated constraints?
  • Code quality: Is the Python clean, runnable, and free of obvious bugs?

Instruct the judge to return scores in JSON format. Structured output makes it trivial to diff results, plot trends, and feed downstream automation. Keep the judge prompt strict. If you give it a vague instruction like "rate the answer," you will get vague results. Instead, define what counts as a correct bin-packing solution. Capacities must not be exceeded. Every item must be assigned. The code must be syntactically valid. The more concrete your criteria, the more reliable your grades become.

Always spot-check the judge. If Kimi K2.6 consistently overrates one model because of surface-level polish, your benchmark is broken. A small human audit layer prevents garbage-in-garbage-out evaluation.

Step 5: Build the Report

Aggregate the JSON scores and pair them with excerpts from the raw model outputs. Drop everything into a single file that lives in your repository. When you update a model version or tweak the prompt, the diff in your pull request shows exactly how behavior shifted. A well-maintained benchmark becomes living documentation. It justifies why your production pipeline uses one model over another, and it catches silent regressions before they reach users.

Structure the report so a teammate can read it without running the code. Include the problem statement, the prompt template, the scores, and representative quotes from each model’s reasoning trace. Transparency matters. If DeepSeek R1 scores high but hallucinates a constraint, you want that visible in the text excerpt, not buried in an average.

Automating the Pipeline

A benchmark that lives only on your laptop is forgotten within a week. Move it into a nightly CI job. Every night, the harness spins up, queries the current model versions on Oxlo.ai, runs the bin-packing task, grades the outputs, and commits the results. If a model update causes a ten-point drop in correctness, you will know before your users do.

Once the core harness is stable, extend it. Test long-context variants by stuffing the prompt with irrelevant documents, then placing the bin-packing question at the end. Large context windows are useless if reasoning collapses under noise. See which models maintain logical discipline when the signal is buried in ten thousand tokens of distraction.

The Real Takeaway

Public leaderboards measure general knowledge. Your application measures something narrower and harder. A simple, repeatable harness that forces models to reason through constrained optimization, grades them with consistent criteria, and versions the results in git will give you more actionable insight than any aggregate score. Build the benchmark that fits your problem, run it across architectures that matter to you, and let the results dictate your production choice.

Source: DeepSeek R1 Model Architecture and Benchmarks

Community: GyaanSetu AI on Telegram