Metrik API Penting untuk Model Fine-Tuned

Model fine-tuned hanya layak dipertahankan jika ia tetap cukup cepat, cukup stabil, dan cukup murah di bawah lalu lintas API langsung.

Jika saya hanya melacak beberapa hal sejak hari pertama, saya akan mengamati latensi, throughput, error rate, timeout rate, success rate, fallback rate, penggunaan token, biaya per permintaan, kedalaman antrian, dan task completion rate. Kenapa? Karena sebuah model bisa mengembalikan 200 OK dan tetap gagal menyelesaikan tugas, membakar token ekstra, atau mendorong pengguna untuk pergi.

Ini versi singkatnya:

• Latensi: Amati TTFT dan p95/p99, bukan hanya rata-rata.
• Throughput: Uji RPS/TPS di bawah konkurensi produksi, bukan satu permintaan pada satu waktu.
• Keandalan: Pisahkan 4xx, 5xx, 429, 503, dan 504 agar pola kegagalan mudah dikenali.
• Timeout: Keluaran yang lebih panjang sering mendorong model fine-tuned melampaui batas waktu permintaan.
• Success vs. fallback: Respons API yang berhasil tidak sama dengan jawaban yang bisa digunakan.
• Token: Lacak input, output, dan total token dari field usage API.
• Biaya: Ukur biaya per permintaan, biaya per 1.000 token, dan biaya p95, bukan hanya pengeluaran bulanan.
• Kapasitas: Kedalaman antrian dan tekanan KV cache sering menunjukkan masalah sebelum grafik GPU melakukannya.
• Hasil pengguna: Amati task completion rate, tinjauan manusia, dan abandonment.
• Risiko rollback: Jika p99 melonjak, 5xx + timeout melampaui 5%, atau win rate vs. model dasar turun di bawah 50%–55%, saya akan menganggapnya sebagai peringatan keras.

Fine tuning dengan Metrik Komputasi Kustom

Perbandingan Cepat

Intinya: Saya tidak akan menilai model fine-tuned hanya dari skor offline. Saya akan membandingkannya dengan model dasar di produksi, menetapkan batas rollback sebelum peluncuran, dan menjaga satu dasbor yang menampilkan kecepatan, kegagalan, pengeluaran, dan hasil dalam satu tampilan.

Mengapa Metrik API Lebih Penting Setelah Fine-Tuning

Fine-tuning mengubah bagaimana model berperilaku di produksi. Di bawah lalu lintas langsung, latensi, penggunaan token, dan pola kegagalan semua bisa bergeser. Dalam beberapa kasus, fine-tuning memotong token input dengan menggantikan prompt yang panjang. Dalam kasus lain, ia mendorong biaya output naik dengan membuat completion lebih panjang ^[6]. Itu sebabnya kemenangan offline tidak berarti banyak dengan sendirinya. Anda harus memeriksanya terhadap metrik API langsung.

Kesenjangan antara pengujian offline dan produksi itu nyata. Riset menunjukkan bahwa model fine-tuned dapat memperoleh 12 poin pada holdout set khusus tugas dan tetap kehilangan 6 poin pada benchmark penalaran umum seperti GSM8K ^[2]. Itu bukan kasus sudut yang aneh. Itu adalah pola kegagalan yang dikenal disebut catastrophic forgetting, di mana meningkatkan satu keterampilan bisa melemahkan yang lain.

Pelajarannya di sini cukup sederhana: sebuah fine-tune bisa membantu tugas yang Anda pedulikan dan tetap merugikan kinerja di tempat lain. Dan jenis benchmark drift itu tidak muncul jelas jika Anda hanya menatap skor offline. Anda melihatnya ketika sinyal produksi duduk di samping hasil evaluasi.

Quality drift bukan satu-satunya masalah. Fine-tuning domain juga dapat melemahkan perilaku penolakan model dasar, yang membuat model lebih terbuka terhadap jailbreak dan prompt injection ^[2]. Di produksi, jenis kesalahan itu muncul cepat: success rate turun, fallback rate naik, dan lonjakan error mulai muncul dengan cara yang tidak akan ditangkap oleh test set statis. Perubahan itu muncul dalam metrik API yang mengikuti.

1. Latensi End-to-End

Latensi end-to-end adalah total waktu dari saat klien mengirim permintaan hingga respons lengkap tiba. Itu mencakup waktu jaringan, antrian, inferensi, dan pengiriman respons ^[7][9]. Untuk endpoint fine-tuned, ini adalah salah satu sinyal produksi pertama yang perlu diamati.

Cara sederhana untuk memikirkan latensi adalah ini: total time ≈ TTFT + output_tokens × TPOT ^[9].

TTFT mengukur seberapa cepat token pertama muncul, yang sangat penting untuk aplikasi streaming ^[9][10]. TPOT adalah waktu rata-rata antara token yang dihasilkan ^[9]. Pemisahan ini membantu Anda melihat apa yang berubah setelah fine-tune. Apakah kecepatan respons tergelincir? Apakah streaming mulai lebih lambat? Apakah pembuatan token melambat?

Model fine-tuned sering berjalan 10%–20% lebih lambat daripada model dasar. Jika latensi melonjak lebih dari 50%, itu biasanya menunjuk ke bobot LoRA yang belum digabungkan, kuantisasi yang hilang, atau output yang menjadi terlalu panjang ^[7][8]. Perbandingan yang berguna adalah terhadap model dasar. Itu memberi tahu Anda apakah fine-tune meningkatkan kualitas tugas cukup untuk membenarkan penurunan kecepatan.

Latensi ekor adalah apa yang diperhatikan pengguna selama giliran lambat, percobaan ulang, dan lonjakan antrian. p95 TTFT di atas 3–4 detik menciptakan perlambatan yang jelas bagi pengguna ^[3]. Dalam chat interaktif, p95 TTFT di bawah 500 ms terasa instan. Begitu melewati 3–4 detik, pengalamannya menurun cepat ^[12]. Jadi jangan menetapkan SLA hanya pada rata-rata. Tetapkan pada latensi ekor.

Latensi ekor yang tinggi biasanya menunjuk ke masalah kedalaman antrian atau overhead cold-start, bukan kecepatan GPU mentah ^[10]. Itu sebabnya latensi persentil lebih penting daripada waktu respons rata-rata dengan sendirinya.

Sebelum Anda mengukur, jalankan 2–3 permintaan pemanasan. Latensi panggilan pertama sering 30%–50% lebih tinggi ^[8].

2. Latensi p50, p90, dan p99

Latensi rata-rata dapat membuat hal-hal tampak lebih baik daripada kenyataannya. Anda mungkin melihat waktu respons rata-rata 1,2 detik dan berasumsi endpoint baik-baik saja, sementara p99 adalah 9 detik ^[15]. Itu berarti 1% pengguna masih menunggu hampir 10 detik, meskipun dasbor mengatakan semuanya tampak normal. Persentil membantu Anda melihat apakah fine-tune membantu sebagian besar permintaan atau hanya mendorong perlambatan ke ekor.

Berikut apa yang diberitahu setiap persentil tentang endpoint fine-tuned Anda:

Gunakan persentil ini untuk membandingkan model dasar dan model fine-tuned di bawah campuran lalu lintas yang sama.

Setelah fine-tuning, p50 dan p99 bisa bergerak ke arah berbeda. Jika fine-tune Anda menghasilkan output yang lebih pendek dan lebih terstruktur, p50 mungkin turun karena permintaan tipikal selesai lebih cepat. Tetapi p99 mungkin naik jika model kadang menjadi lebih bertele-tele ^[7][15]. Pemisahan itu penting. Jika p99 naik sementara p50 tetap datar, itu adalah sinyal untuk menyelidiki, bukan waktu respons rata-rata.

p99 adalah angka risiko-rollback Anda. Tetapkan regression gate di pipeline CI/CD Anda di sekitar ambang p99 ^[15]. Jika pembaruan model mendorong latensi ekor melewati batas Anda, build harus gagal sebelum mencapai produksi.

Latensi memberi tahu Anda seberapa lambat permintaan terasa. Berikutnya, lihat berapa banyak permintaan yang bisa ditangani endpoint.

3. Throughput dan Requests Per Second (RPS)

Latensi memberi tahu Anda bagaimana satu permintaan berkinerja. Throughput memberi tahu Anda berapa banyak pekerjaan yang bisa ditangani endpoint dari waktu ke waktu.

Angka utama yang perlu dilacak adalah Requests Per Second (RPS), Tokens Per Second (TPS), dan Tokens Per Minute (TPM) ^[17][18]. Bersama-sama, mereka menunjukkan apakah endpoint fine-tuned Anda dapat mengimbangi lalu lintas aktual, terutama saat menggunakan API LLM terpadu untuk mengelola beberapa penyedia.

Ini tangkapannya: sebuah model bisa terlihat cepat dalam uji sekali jalan dan tetap runtuh begitu lalu lintas menumpuk. Di bawah konkurensi, Anda bisa mengalami throughput collapse, di mana menambahkan lebih banyak permintaan paralel tidak lagi meningkatkan output, dan latensi mulai melonjak keras. Titik belok itu - di mana throughput berhenti berkembang - adalah plafon kapasitas Anda ^[15].

Salah satu faktor terbesar di balik RPS adalah panjang output. Jika fine-tune mulai memberi jawaban lebih panjang, throughput turun dan biaya naik, bahkan jika balasannya lebih baik ^[6][8].

Membantu juga untuk mengamati goodput, bukan hanya throughput mentah. Goodput adalah bagian dari permintaan yang masih memenuhi latency SLO. Jika goodput rendah, endpoint mungkin sibuk tetapi tetap meleset dari sasaran. Jenis kesenjangan itu sering menunjuk ke batching yang lemah atau saturasi server ^[17].

Jadi ketika Anda melakukan benchmark RPS dan TPS, uji pada konkurensi produksi, bukan dengan jalankan permintaan tunggal. Batasan yang terkait dengan rate cap, kedalaman antrian, dan VRAM sering tetap tersembunyi sampai sistem berada di bawah beban ^[7][9][15]. Jika endpoint dapat menahan kapasitas di sana, maka saatnya memeriksa apakah permintaan tersebut berhasil.

4. Error Rate Berdasarkan HTTP Status Code

Setelah beban terkendali, hal berikutnya yang perlu diamati adalah keandalan: seberapa sering endpoint gagal. Error rate memberi tahu Anda apakah permintaan selesai sebagaimana mestinya. Dalam praktik, ini terbagi menjadi dua keranjang: kegagalan sisi klien dan kegagalan sisi server.

Kenaikan error 4xx sering menunjuk ke ketidakcocokan prompt atau skema, atau masalah context-window yang diperkenalkan oleh fine-tune. Kenaikan error 503 atau 504 biasanya menunjuk ke tekanan server atau tekanan timeout. Ketika error 5xx melonjak, perlakukan itu sebagai risiko rollback yang serius.

Ada juga sudut uang di sini. Permintaan yang gagal tetap mengonsumsi token. Untuk melacak pengeluaran yang terbuang, jumlahkan biaya token dari permintaan yang gagal, terutama error 4xx selain 429 dan error 5xx apa pun ^[22]. Dan jika logika retry terlalu agresif, retry buruk itu dapat mendorong biaya inferensi naik 3x hingga 5x ^[21].

Berikut peta sederhana dari kode status paling umum, dari mana biasanya berasal, dan apa yang harus dilakukan selanjutnya:

Jangan gunakan logika retry yang sama untuk setiap kode error. Mencoba ulang 400 hanya membakar lebih banyak komputasi karena permintaannya masih rusak. Exponential backoff milik error 429 ^[21]. Jika 503 atau 504 terus muncul di tiga pemeriksaan, picu circuit breaker dan arahkan lalu lintas ke model baseline.

Berikutnya, periksa apakah respons lambat mengalami timeout sebelum selesai.

5. Timeout Rate

Ketika error naik dan tidak ada lonjakan jelas pada kegagalan langsung, timeout rate adalah hal berikutnya yang perlu diperiksa. Timeout tetaplah permintaan yang gagal: klien tidak mendapatkan respons sebelum tenggat. Lacak timeout rate sebagai bagian dari permintaan yang melewati tenggat itu, yang sering muncul sebagai error timeout sisi server.

Model fine-tuned lebih mungkin mengalami timeout karena mereka sering menghasilkan output lebih panjang. Jika data pelatihan cenderung bertele-tele, model mungkin menghasilkan lebih banyak token per permintaan daripada model dasar. Ini umum ketika menggunakan model Alibaba Qwen atau LLM berkinerja tinggi lainnya yang memprioritaskan respons terperinci. Lebih banyak token berarti lebih banyak waktu pembuatan, dan waktu ekstra itulah yang mendorong permintaan melewati tenggat ^[8].

Jika kedalaman antrian tetap di atas nol, sistem sudah berada pada kapasitas. Ketika itu terjadi, timeout rate biasanya memanjat tak lama setelahnya ^[12]. Perlakukan kedalaman antrian sebagai tanda peringatan dini alih-alih menunggu timeout muncul. Jika kedalaman antrian naik bersamaan dengan timeout, Anda sedang menghadapi masalah kapasitas, dan itu perlu tindakan segera. Setelah timeout rate mereda, pisahkan keberhasilan sejati dari respons fallback.

6. Success Rate dan Fallback Rate

Bahkan ketika timeout hilang, permintaan tetap bisa gagal menyelesaikan pekerjaan. Success rate memberi tahu Anda apakah model benar-benar menyelesaikan tugas, bukan hanya apakah ia mengembalikan HTTP 200. Itu berarti memeriksa hal-hal seperti kepatuhan skema, tool call yang benar, dan akurasi faktual. Model fine-tuned bisa mencatat akurasi token tinggi dan tetap gagal pada 15%–30% kueri produksi langsung karena regresi tingkat tugas ^[23].

Fallback rate memberi tahu Anda seberapa sering lalu lintas harus dikirim ke tempat lain setelah endpoint fine-tuned gagal, timeout, atau diblokir oleh safety filter ^[4][5]. Itu sebabnya ia harus dilacak tepat di samping success rate. Anda tidak hanya mengukur completion. Anda mengukur output yang bisa Anda gunakan.

Gunakan kedua metrik ini bersama-sama sebagai sinyal utama untuk kualitas penyelesaian. Jika salah satunya tergelincir, itulah saatnya memeriksa apakah fine-tune masih bertahan terhadap model dasar. Jika win rate versus model dasar turun di bawah 50%–55%, itu adalah ambang rollback yang umum ^[2][4].

Jika keberhasilan tetap tinggi tetapi biaya mulai memanjat, periksa penggunaan token berikutnya.

Keberhasilan tinggi tidak berarti banyak jika setiap permintaan terlalu mahal untuk dilayani.

7. Penggunaan Token per Permintaan

Setelah keandalan, penggunaan token memberi tahu Anda apakah model cukup ramping untuk berjalan dalam skala. Ia juga menunjukkan apakah fine-tuning menjalankan tugasnya dengan menggantikan overhead prompt dengan perilaku yang dipelajari. Penggunaan token yang lebih rendah biasanya berarti biaya lebih rendah dan balasan lebih cepat.

Lacak token input, output, dan total sebagai angka terpisah. Itu membuat lebih mudah mendeteksi pertumbuhan lambat sebelum berubah menjadi masalah biaya. Token input tinggi sering menunjuk ke prompt bloat atau context overflow. Token output tinggi biasanya berarti completion yang bertele-tele, aturan stop yang lemah, atau tidak ada batas output. Dan token output lebih mahal daripada token input, jadi verbositas adalah risiko biaya terbesar ^[15].

Tarik hitungan token dari objek usage API pada setiap respons, bukan dari estimasi tokenizer lokal ^[15][25]. Estimasi lokal bisa menyimpang dari hitungan yang ditagihkan. Jika Anda melihat lonjakan token 3x, asumsikan prompt bloat atau context overflow sampai Anda menemukan penyebabnya ^[3]. Membantu juga untuk menetapkan batas token output di CI/CD sehingga Anda bisa menangkap regresi verbositas sebelum dirilis ^[15].

Hitungan token memetakan langsung ke pengeluaran, itulah sebabnya metrik berikutnya adalah biaya per permintaan.

8. Biaya per Permintaan dan Biaya per 1.000 Token

Token berubah menjadi dolar. Tetapi tagihan bulanan saja tidak memberi tahu Anda mengapa pengeluaran naik. Untuk melihat apa yang menggerakkannya, lacak biaya per permintaan dan biaya per 1.000 token. Itu memberi Anda lapisan analisis produksi berikutnya.

Biaya per permintaan menunjukkan berapa biaya satu aksi pengguna. Hitung dari biaya token input, output, dan cache yang ditagihkan untuk permintaan itu ^[26][28]. Lalu lacak tarif yang ditagihkan per 1.000 token secara terpisah. Ketika Anda mengamati kedua angka bersama, Anda dapat mengetahui apakah pengeluaran memanjat karena Anda memiliki lebih banyak lalu lintas atau karena prompt dan completion menjadi lebih panjang. Pola itu sering disebut token creep ^[15][26].

Inferensi fine-tuned dapat menelan biaya 2x–5x lebih banyak per token, tetapi ia tetap bisa menurunkan biaya per permintaan ketika memotong panjang prompt ^[29][30]. Kenapa? Model fine-tuned memanggang definisi peran, guardrail, dan contoh few-shot ke dalam bobotnya. Jadi setiap prompt menjadi lebih pendek pada setiap panggilan. Dalam satu benchmark, model fine-tuned hanya membutuhkan 42 token completion di mana model dasar membutuhkan 85 - pengurangan 50,6% biaya inferensi per permintaan ^[19]. Dalam bahasa sederhana, harga satuan yang lebih tinggi bisa kalah dengan hitungan token yang lebih rendah. Itulah keuntungan yang ingin Anda ukur dalam lalu lintas API langsung.

Tandai setiap panggilan API dengan feature_name dan user_tier agar Anda dapat menghubungkan pengeluaran ke penggunaan produk ^[27][28]. Itu membuat data jauh lebih berguna ketika biaya mulai menyimpang.

Beberapa pemeriksaan paling penting:

• Amati token output dengan cermat. Pada harga model unggulan, mereka bisa menelan biaya 5x lebih banyak daripada token input, jadi memotong jawaban yang bertele-tele menghemat lebih banyak daripada memotong jumlah token prompt yang sama ^[15].
• Tetapkan plafon pada rata-rata token output di pipeline CI/CD Anda. Ini membantu menangkap regresi verbositas sebelum mencapai produksi ^[15].
• Tinjau biaya berdasarkan fitur dan user tier, bukan hanya secara agregat. Kalau tidak, penggunaan mahal bisa bersembunyi di dalam total yang tampak sehat.

Setelah biaya, lihat apakah pengeluaran cocok dengan permintaan nyata atau hanya kapasitas menganggur.

Berikutnya, bandingkan biaya ini dengan utilisasi infrastruktur dan panjang antrian.

9. Utilisasi Infrastruktur dan Panjang Antrian

Jika latensi dan timeout naik, lihat lapisan serving berikutnya: antrian, memori, dan tekanan cache. Kedalaman antrian paling penting di sini. Utilisasi GPU cenderung tertinggal dari permintaan, jadi ini adalah sinyal yang tertinggal. Itu sebabnya autoscaling harus berpatok pada kedalaman antrian per replika, bukan persentase komputasi ^[10][32].

Penggunaan KV cache adalah metrik lain yang sering dilewatkan tim. KV cache menyimpan konteks token di memori GPU, dan ketika memori itu menjadi sesak, mesin mungkin mulai mengantrikan permintaan baru meskipun komputasi GPU masih tampak terbuka ^[31][32]. Aturan praktis yang baik: perlakukan penggunaan KV cache 40%–50% sebagai peringatan dini, dan 90%+ sebagai saturasi ^[31][32].

Model fine-tuned menambah satu putaran lagi. Adapter LoRA membutuhkan memori di atas bobot model dasar, dan memuatnya pada permintaan pertama setelah scale-up menciptakan cold-start delay. Dalam banyak kasus, itu menambah beberapa ratus milidetik ke TTFT ^[10]. Memuat adapter sebelumnya saat startup menghindari sebagian besar dampak itu. Membantu juga untuk mengamati CPU secara terpisah, karena tokenisasi dan preprocessing dapat menambah latensi yang mudah terlewatkan ^[10].

Jika sinyal kapasitas ini masih tampak sehat, lanjut ke kualitas output.

10. Kepuasan Pengguna dan Task Completion Rate

Setelah latensi, biaya, dan keandalan, pemeriksaan terakhir sederhana: apakah model menyelesaikan pekerjaan? Endpoint fine-tuned bisa cepat, murah, dan stabil, namun tetap meleset dari sasaran.

Task Completion Rate (TCR) adalah bagian dari permintaan yang diselesaikan tanpa bantuan manusia. Human review rate adalah bagian dari output yang masih memerlukan perbaikan manual. Perbedaan itu penting. Model bisa mengembalikan HTTP 200 dan tetap menyerahkan sesuatu yang harus dibersihkan orang sebelum siapa pun bisa menggunakannya. Jadi TCR melacak hasil bisnis, bukan hanya apakah API menjawab.

Pada pekerjaan output terstruktur, 500 contoh berkualitas tinggi dapat mendorong kepatuhan format dari 68%–74% menjadi 97%–99% ^[33]. Lompatan semacam itu mengurangi seberapa sering staf perlu turun tangan. Setelah format benar, bandingkan model fine-tuned langsung dengan model dasar.

Kecepatan tetap penting di sini. Latensi P99 di atas 5 detik mendorong sekitar 45% abandonment ^[33]. Jadi jika fine-tune memperlambat pengalaman, pengguna akan menunjukkannya kepada Anda dengan cepat - dengan pergi.

Untuk pemeriksaan kualitas langsung, gunakan paired arena testing. Jalankan 200–500 sampel produksi melalui model dasar dan fine-tuned, lalu nilai output berdampingan dengan LLM-as-a-judge. Setelah itu, kunci model judge dan rubrik agar uji masa depan tetap konsisten. Jika win rate terhadap model dasar turun di bawah 50%–55%, itu adalah ambang rollback yang umum ^[2][4].

Membantu juga untuk mengamati sinyal-sinyal ini bersama:

• TCR
• Arena win rate
• Rangkaian benchmark yang dibekukan

Jika model turun lebih dari 5 poin pada benchmark umum, perlakukan itu sebagai kegagalan keras, bahkan ketika skor khusus tugas naik ^[2].

Gunakan pemeriksaan kualitas ini di samping metrik API dari bagian sebelumnya saat memutuskan apakah fine-tune siap untuk produksi.

Tabel Perbandingan Latensi dan Throughput

Tidak ada metrik tunggal yang menceritakan keseluruhan cerita untuk endpoint fine-tuned. Latensi rata-rata, misalnya, dapat menghaluskan ayunan permintaan-ke-permintaan, terutama ketika antrian dan batching sisi penyedia terlibat ^[9].

Itu sebabnya membantu untuk mengukur latensi dan throughput secara terpisah dulu, lalu membandingkannya berdampingan sebelum Anda menetapkan SLO.

Pecah hasil berdasarkan jenis endpoint, versi model, wilayah, dan waktu hari. Lalu lintas jam puncak sering memunculkan masalah latensi ke permukaan yang tidak akan ditangkap oleh uji di luar jam sibuk.

Pemotongan itu membuat jauh lebih mudah untuk melihat di mana endpoint fine-tuned mulai kesulitan di bawah lalu lintas langsung.

Metrik Keandalan yang Menandakan Risiko Rollback

Tanda paling jelas bahwa rollback mungkin diperlukan adalah win rate versus model dasar. Jalankan paired canary dan shadow routing agar Anda dapat membandingkan model fine-tuned dengan model dasar berdampingan. Jika win rate turun di bawah 50%, fine-tune tidak lagi menambah nilai di produksi. Lapisan routing Anda juga harus auto-rollback ketika kohort canary menahan penurunan 2 poin pada skor kualitas per-rubrik mana pun selama 30–60 menit ^[2][4]. Setelah perbandingan itu menjadi negatif, langkah berikutnya sederhana: temukan grup prompt yang rusak.

Beberapa sinyal lain harus bertindak sebagai pemicu rollback: 5xx + timeout rate, refusal rate, invalid-output rate, lonjakan 429, dan perilaku fallback. Ini adalah angka yang penting ketika Anda memutuskan apakah fine-tune harus tetap tayang. Lacak lonjakan 429 secara terpisah. Mereka sering menunjuk ke biaya komputasi lebih tinggi atau antrian lebih dalam ^[24][5].

Membantu juga untuk memisahkan refusal rate dari invalid-output rate alih-alih menggabungkannya. Penolakan di atas 2% sering menunjuk ke regresi keamanan atau filter penyedia yang bentrok dengan prompt kustom Anda ^[5][35]. Invalid-output rate biasanya menunjuk ke schema drift atau instruction following yang lebih lemah ^[2][24].

Pecah setiap metrik berdasarkan jenis prompt, rute alur kerja, dan versi model. Model bisa tampak baik pada permintaan umum dan tetap kesulitan pada jalur output terstruktur atau prompt khusus domain. Pemisahan itu membuat jauh lebih mudah menilai apakah model aman untuk terus dijalankan dan apakah profil biaya masih bertahan.

Metrik Biaya, Token, dan Sumber Daya dalam Bentuk Dolar

Setelah latensi, throughput, dan keandalan, langkah berikutnya sederhana: apakah endpoint sepadan dengan uangnya? Lalu lintas stabil tidak banyak membantu jika setiap permintaan terlalu mahal. Setelah keandalan terkendali, Anda perlu mengubah penggunaan token menjadi dolar.

Untuk GPT-4o, harga inferensi fine-tuned datang dengan markup 1,5x di atas tarif dasar. Itu setara dengan $3,75 per 1M token input dan $15 per 1M token output ^[36]. Biaya ekstra itu hanya masuk akal jika fine-tune menurunkan biaya untuk mendapatkan hasil yang berhasil. Salah satu cara umum untuk memotong pengeluaran adalah melalui diskon agregat untuk API AI dan model cascading: kirim kueri sederhana ke model yang lebih kecil dan lebih murah, dan simpan model yang lebih besar untuk tugas yang lebih sulit ^[37].

Membantu juga untuk meramalkan pengeluaran di seluruh kasus ramping, yang diharapkan, dan beban tinggi. Lalu tambahkan retry, penggunaan fallback, dan run evaluasi ^[26]. Langkah itu lebih penting daripada yang diperkirakan banyak tim, karena 40% tim melampaui anggaran API AI mereka pada kuartal pertama penggunaan ^[37]. Di atas itu, lacak biaya p95 per permintaan, bukan hanya rata-rata. Kalau tidak, prompt konteks panjang atau retry berulang dapat mencondongkan ramalan Anda dengan cara yang tidak akan ditunjukkan oleh rata-rata ^[24]. Pengeluaran mentah baru menjadi berguna ketika Anda menghubungkannya ke hasil yang berhasil.

Koneksi itu adalah biaya per hasil berhasil. Dalam praktik, itu mungkin berarti biaya per tiket dukungan yang terselesaikan atau biaya per jawaban yang diterima. Jika model fine-tuned meningkatkan bagian hasil yang berhasil, biaya per resolusi Anda bisa turun bahkan ketika harga per permintaan naik ^[26][37].

Untuk deployment self-hosted, utilisasi GPU adalah pendorong biaya utama. Pengeluaran GPU tetap baru terbayar setelah penggunaan melewati ambang tertentu. Dengan kata lain, utilisasi tinggi penting ketika ia meningkatkan efisiensi biaya. Anda juga harus mengamati panjang antrian di samping utilisasi. Jika kedalaman antrian terus memanjat, itu biasanya tanda saturasi, biaya tambahan, dan lebih banyak tekanan penskalaan ^[11][15].

Gunakan metrik ini bersama untuk membedakan beban sehat dari pemborosan yang mahal.

Sinyal Kualitas yang Bisa Anda Amati Melalui API

Setelah latensi, throughput, dan biaya dalam kondisi baik, langkah berikutnya sederhana: periksa apakah model benar-benar membantu pengguna menyelesaikan sesuatu. Kecepatan penting, tentu. Tetapi jawaban cepat yang tidak menyelesaikan masalah tetaplah kegagalan.

Fokus dulu pada task completion rate, escalation rate, dan human handoff rate. Ini adalah sinyal hasil utama Anda. Mereka memberi tahu Anda apakah model fine-tuned menangani permintaan sendiri atau apakah seseorang harus turun tangan. Dan itu lebih penting daripada skor benchmark karena metrik ini berasal dari log permintaan dan sesi aktual.

Anda juga dapat melacak rating thumbs-up/down dan abandonment rate sebagai sinyal tingkat sesi pendukung yang terkait dengan lalu lintas API. Bahkan jika umpan balik jarang, ia tetap bisa menunjukkan titik sakit yang berulang. Abandonment sangat berguna karena menunjukkan di mana model mulai menyimpang, kehilangan konteks, atau berhenti membantu di tengah percakapan.

Membantu juga untuk mengambil sampel lalu lintas langsung dengan LLM-as-judge untuk mengestimasi halusinasi dan masalah keamanan. Sampel 5% sering cukup untuk menangkap anomali tanpa mendorong pengeluaran evaluasi naik terlalu tinggi ^[39]. Perhatikan juga frekuensi pemicu guardrail. Jika lebih dari 20% permintaan diblokir, itu bisa menunjuk ke lonjakan output tidak aman atau ketidakcocokan antara apa yang diinginkan pengguna dan apa yang diharapkan sistem ^{[38] [1] [2]}. Peningkatan tajam dalam refusal rate sering berarti filter menjadi terlalu sensitif atau bahwa template prompt rusak di suatu tempat dalam stack ^{[39] [2]}.

Setiap kegagalan langsung harus kembali ke test set offline sebagai kasus permanen. Begitulah cara Anda menghentikan masalah yang sama menyelinap kembali nanti.

Gunakan tabel di bawah untuk memisahkan sinyal kualitas utama dari yang pendukung.

Gunakan sinyal ini bersama latensi dan biaya dalam dasbor observabilitas.

Dasbor Observabilitas untuk Endpoint Fine-Tuned

Melacak metrik tunggal membantu. Tetapi hasilnya datang ketika Anda melihat semuanya di satu tempat.

Penyiapan observabilitas yang solid untuk endpoint fine-tuned bertumpu pada empat pilar: metrik untuk sinyal yang digulung seperti latensi dan error rate, traces untuk jalur lengkap satu permintaan, logs untuk catatan terstruktur tentang apa yang terjadi, dan evaluasi untuk pemeriksaan kualitas asinkron ^[40][42].

Ini bahkan lebih penting dengan model fine-tuned. Sebuah permintaan bisa berhasil di tingkat sistem dan tetap gagal di tingkat makna, bahkan saat menggunakan antarmuka AI chat. Jadi dasbor perlu menunjukkan kegagalan semantik, bukan hanya keberhasilan transport. APM gaya lama bisa menunjukkan bahwa respons sehat. Ia tidak bisa memberi tahu Anda apakah jawabannya salah. Sebuah 200 OK tetap bisa menyembunyikan hasil yang buruk.

Bangun dasbor di sekitar lima tampilan: latensi, keandalan, biaya, kualitas, dan kapasitas. Gunakan OpenTelemetry dengan GenAI semantic conventions, dan tail-sample traces agar Anda menyimpan semua permintaan lambat dan gagal sambil mengambil sampel irisan kecil dari lalu lintas normal ^[40][41]. Penyiapan itu juga terbayar selama insiden: tracing dapat memotong mean time to recovery 3x ^[42].

Gunakan sinyal itu untuk membuat satu dasbor dengan lima panel inti: latensi, keandalan, biaya, kualitas, dan kapasitas.

Cara yang baik untuk memikirkannya: latensi memberi tahu Anda seberapa cepat sistem bergerak, keandalan menunjukkan apakah ia tetap tayang, biaya menunjukkan berapa biaya setiap jawaban, kualitas menunjukkan apakah jawabannya bagus, dan kapasitas memberi tahu Anda kapan sistem mulai berjalan panas.

Tabel Desain Dasbor

Tabel ini menghubungkan setiap widget dasbor ke jenis chart yang bekerja paling baik dan filter yang membuatnya berguna selama insiden dan tinjauan biaya.

Agar filter itu bekerja sejak hari pertama, tandai traces selama instrumentasi dengan model ID, versi prompt, dan environment. OpenTelemetry GenAI semantic conventions mencakup atribut seperti gen_ai.request.model dan gen_ai.usage.input_tokens ^[40].

Pilih chart yang membuat pola kegagalan mudah dilihat sekilas.

Cost Attribution menunjukkan versi model mana yang menggerakkan pengeluaran. Trace Explorer paling penting untuk alur kerja RAG dan agen karena menunjukkan latensi dan error di seluruh retrieval, tool call, dan inferensi ^[43][40].

Setelah Anda mendefinisikan setiap widget, tetapkan aturan retensi dan sampling. Simpan semua permintaan berlatensi tinggi, error, dan berskor kualitas rendah di Trace Explorer. Lalu ambil sampel permintaan berhasil rutin pada 5%–20% untuk menjaga biaya penyimpanan tetap terkendali ^[40].

Kesimpulan

Evaluasi fine-tune harus membuktikan peningkatan, bukan hanya perubahan. Itu sebabnya scorecard akhir perlu melihat metrik kecepatan, keandalan, biaya, dan hasil bersama-sama.

Jika Anda menyetel satu metrik secara terpisah, masalah produksi bisa merayap masuk cepat. Model mungkin menjadi lebih cepat tetapi kurang stabil. Atau mungkin memotong waktu tinjauan sambil mendorong error naik. Intinya adalah melacak keseluruhan gambar, bukan satu irisan saja.

Mulai dengan model dasar. Tanpa baseline itu, Anda tidak bisa menunjukkan bahwa fine-tune melakukan sesuatu yang lebih baik. Jalankan canary 5%–10% dan bandingkan hasil itu dengan model dasar melalui shadow routing. Tetapkan peringatan ketika latensi naik di atas 2x baseline atau ketika error rate melewati 5% selama 5 menit. Setelah guardrail itu ditetapkan, hubungkan angka-angka ke penghematan operasional.

Setiap metrik harus memetakan ke hasil bisnis. Human review rate adalah proksi langsung untuk penghematan operasional. Jika angka itu tidak bergerak, fine-tune tidak menciptakan nilai produksi.

Dasbor dan peringatan bukan opsional. Bangun observabilitas sebelum peluncuran agar regresi muncul sebelum pengguna menyadarinya.

Pertanyaan Umum

Metrik API mana yang harus saya pantau lebih dulu?

Mulai dengan metrik infrastruktur dan keandalan untuk memeriksa bahwa sistem stabil. Fokus pada TTFT pada persentil ke-95, latensi end-to-end, hard error rate, refusal rate, dan biaya per permintaan.

Setelah Anda memiliki baseline itu, amati kualitas output dengan skor LLM-as-judge dan capability drift. Itu membantu Anda mendeteksi apakah model mulai tergelincir pada keterampilan inti.

Bagaimana saya membandingkan model fine-tuned dengan model dasar?

Jalankan kedua model pada held-out test set yang sama - data yang tidak pernah dipakai dalam pelatihan - agar Anda dapat mengukur kesenjangan dengan bersih. Mulai dengan prompting baseline yang kuat pada model dasar dulu. Itu memberi Anda titik perbandingan yang adil alih-alih memihak.

Bandingkan model di seluruh kualitas, latensi, dan biaya.

Untuk kualitas, gunakan metrik yang cocok dengan pekerjaan, seperti:

• F1 untuk tugas klasifikasi atau ekstraksi
• Exact match untuk tugas dengan satu jawaban benar
• JSON parse rate untuk output terstruktur

Untuk latensi, ukur waktu respons end-to-end, bukan hanya runtime model mentah. Itu berarti mengatur waktu jalur permintaan penuh dari pengiriman prompt hingga output akhir.

Untuk biaya, gunakan harga per-1M-token setiap model dan hitung berapa yang akan Anda bayar berdasarkan penggunaan token input dan output aktual pada test set.

Kapan saya harus melakukan rollback model fine-tuned?

Rollback ketika pemantauan produksi menunjukkan kualitas telah turun dengan cara yang jelas. Itu bisa menunjuk ke model drift atau kegagalan pada input langsung.

Anda juga harus rollback jika model tergelincir pada refusal set Anda, membuka kelemahan prompt-injection baru, atau berkinerja lebih buruk daripada versi saat ini selama pengujian canary produksi.

Awasi dengan cermat latensi p95 dan masalah kualitas yang dilaporkan pengguna agar Anda bisa mendeteksi masalah lebih awal.