Sign inContact usStart free
Base URL and SDK MigrationJuly 27, 2026Flatkey Team

Satu Base URL yang Kompatibel dengan OpenAI untuk Pengujian Prompt Multi-Model

Tetap gunakan OpenAI SDK Anda, cukup ganti satu base URL, lalu bandingkan beberapa model dengan alur kerja pengujian prompt dan perpindahan ke produksi yang terkontrol.

Satu Base URL yang Kompatibel dengan OpenAI untuk Pengujian Prompt Multi-Model

Aplikasi Anda sudah tahu cara memanggil klien yang kompatibel dengan OpenAI. Menambahkan pilihan model seharusnya tidak mengharuskan membangun ulang integrasi tersebut untuk setiap penyedia.

Flatkey memberi Anda satu base URL yang kompatibel dengan OpenAI:

https://router.flatkey.ai/v1

Arahkan klien OpenAI SDK yang sudah Anda miliki ke URL itu, gunakan API key Flatkey, dan pilih model yang ingin Anda uji di field model. Pembungkus request, dataset prompt, rubrik evaluasi, dan kode aplikasi Anda dapat tetap berpusat pada satu antarmuka.

Itu menjadikan Flatkey cocok secara praktis ketika tim Anda siap membandingkan model, tetapi tidak ingin setup akun khusus penyedia dan penulisan ulang klien menjadi proyek evaluasi itu sendiri.

Jalur dengan hambatan paling rendah dari satu model ke shortlist

Evaluasi model yang umum biasanya dimulai dengan pertanyaan sederhana: apakah model lain dapat meningkatkan kualitas, latensi, atau biaya untuk workload ini?

Pekerjaan implementasi bisa dengan cepat menutupi pertanyaan itu. Integrasi terpisah menghasilkan variabel lingkungan, pola autentikasi, perilaku retry, adapter respons, dashboard, dan hubungan penagihan yang terpisah. Pada saat test harness siap, eksperimen prompt awal sudah berubah menjadi proyek infrastruktur.

Base URL yang kompatibel dengan OpenAI mengubah urutannya. Anda mempertahankan satu bentuk klien dan menjadikan model sebagai variabel utama.

Pertahankan stabil Ubah secara sengaja Validasi per model
SDK dan pembungkus request base_url satu kali Kualitas output
Dataset prompt model untuk setiap run Distribusi latensi
Rubrik evaluasi Parameter spesifik model saat diperlukan Penggunaan token dan biaya
Penyimpanan hasil Pengaturan timeout atau retry bila dibenarkan Perilaku tool dan output terstruktur
Observabilitas sisi aplikasi Routing produksi hanya setelah evaluasi Pola error dan penolakan

Tujuannya bukan untuk berpura-pura bahwa setiap model berperilaku identik. Tujuannya adalah menghapus varians integrasi yang dapat dihindari sehingga tim Anda dapat menghabiskan lebih banyak waktu untuk mengukur perbedaan yang penting.

Ubah base URL, bukan seluruh lapisan SDK Anda

Jika Anda sudah menggunakan OpenAI Python SDK, perubahan inti pada klien cukup kecil:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["FLATKEY_API_KEY"],
    base_url="https://router.flatkey.ai/v1",
)

Pola yang sama bekerja dengan klien OpenAI JavaScript:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FLATKEY_API_KEY,
  baseURL: "https://router.flatkey.ai/v1",
});

Setelah itu, gunakan model ID dari direktori model Flatkey yang terbaru dalam request. Jangan meng-hardcode asumsi model dari spreadsheet atau artikel lama; ketersediaan dan kemampuan model dapat berubah.

response = client.chat.completions.create(
    model=os.environ["EVAL_MODEL_ID"],
    messages=[
        {"role": "system", "content": "Jawab menggunakan kebijakan yang disediakan."},
        {"role": "user", "content": evaluation_prompt},
    ],
    temperature=0,
    max_tokens=800,
)

Ini adalah keunggulan adopsi inti: aplikasi Anda dapat mempertahankan klien yang kompatibel dengan OpenAI sementara evaluasi Anda mengubah pemilihan model.

Alur kerja pengujian prompt multi-model yang terfokus

Gunakan alur kerja berikut untuk mengubah migrasi base URL menjadi keputusan yang dapat dipertahankan tim Anda.

1. Bekukan kontrak permintaan

Mulailah dari satu permintaan yang sudah merepresentasikan beban kerja produksi. Pertahankan hal-hal berikut tetap sama di seluruh pass perbandingan pertama:

  • System dan user prompt
  • Contoh input
  • Temperature dan batas token
  • Definisi alat atau skema respons
  • Kebijakan timeout
  • Rubrik evaluasi

Jika Anda mengubah prompt, model, dan kebijakan retry secara bersamaan, Anda tidak akan tahu perubahan mana yang menghasilkan hasil tersebut.

2. Buat set evaluasi kecil yang representatif

Jangan mulai dengan ratusan prompt sintetis. Mulailah dengan 20 hingga 50 contoh yang mencakup kasus yang benar-benar dibuat pengguna Anda:

  • Permintaan umum dengan frekuensi tinggi
  • Input panjang atau berantakan
  • Instruksi ambigu
  • Kasus yang sensitif terhadap keselamatan atau cenderung memicu penolakan
  • Kasus keluaran terstruktur yang bersifat edge case
  • Kasus pemanggilan alat, jika aplikasi Anda menggunakan alat

Hapus data pribadi dan rahasia sebelum mengirim traffic evaluasi. Set evaluasi terbaik berukuran cukup kecil untuk diperiksa dan cukup representatif untuk mengungkap kegagalan yang berarti.

3. Jalankan kasus yang sama melalui setiap model kandidat

Biarkan base URL Flatkey dan pembungkus permintaan tetap sama. Iterasikan melalui ID model di daftar pendek Anda.

import time

candidate_models = [
    "MODEL_ID_A",
    "MODEL_ID_B",
    "MODEL_ID_C",
]

results = []

for model_id in candidate_models:
    for case in evaluation_cases:
        started_at = time.perf_counter()
        try:
            response = client.chat.completions.create(
                model=model_id,
                messages=case["messages"],
                temperature=0,
                max_tokens=case.get("max_tokens", 800),
            )
            elapsed_ms = round((time.perf_counter() - started_at) * 1000)
            results.append({
                "case_id": case["id"],
                "model": model_id,
                "latency_ms": elapsed_ms,
                "output": response.choices[0].message.content,
                "usage": response.usage.model_dump() if response.usage else None,
                "error": None,
            })
        except Exception as error:
            results.append({
                "case_id": case["id"],
                "model": model_id,
                "latency_ms": None,
                "output": None,
                "usage": None,
                "error": type(error).__name__,
            })

Gunakan placeholder dalam contoh bersama dan pilih ID model terbaru dari direktori live sebelum menjalankan pengujian. Pastikan juga setiap kandidat mendukung kapabilitas yang dibutuhkan beban kerja Anda.

4. Nilai hasilnya, bukan reputasi model

Kartu skor yang berguna memisahkan persyaratan ketat dari preferensi.

Dimensi Pertanyaan contoh Penanganan yang disarankan
Kebenaran Apakah respons memenuhi tugas? Penilai manusia atau penilai spesifik tugas
Mengikuti instruksi Apakah ia mematuhi batasan dan format? Lulus/gagal plus catatan
Output terstruktur Apakah payload dapat di-parse dan cocok dengan skema? Validasi otomatis
Perilaku alat Apakah panggilan valid dan dipilih dengan tepat? Pemeriksaan otomatis plus tinjauan
Latensi Berapa lama permintaan yang সফল berhasil memakan waktu? Median dan persentil ekor
Keandalan Seberapa sering permintaan gagal atau time out? Tingkat error per kelas
Penggunaan Berapa banyak token input dan output yang dilaporkan? Per kasus dan agregat
Biaya Berapa biaya beban kerja yang dievaluasi? Hitung dengan harga saat ini

Tolak kandidat mana pun yang gagal memenuhi persyaratan ketat, meskipun biayanya murah. Di antara model yang tersisa, bandingkan tradeoff yang penting bagi produk Anda.

5. Uji ulang finalis dengan perilaku produksi

Putaran pertama harus terkontrol. Putaran finalis harus realistis.

Uji streaming jika antarmuka Anda melakukan streaming. Uji panggilan alat jika agen Anda menggunakan alat. Uji output terstruktur jika kode downstream mem-parse-nya. Jalankan pengaturan timeout dan retry Anda yang sebenarnya, dan verifikasi bagaimana aplikasi Anda menangani rate limit, stream yang terputus, respons yang salah format, dan status completion yang ambigu.

Usage Logs Flatkey dapat membantu Anda memastikan bahwa permintaan mencapai gateway dan memeriksa aktivitas permintaan. Simpan juga ID permintaan sisi aplikasi dan data timing, sehingga Anda dapat menghubungkan visibilitas gateway dengan pengalaman pengguna.

Untuk detail retry dan cutover, gunakan panduan migrasi klien OpenAI untuk rate limit dan retry.

Kompatibilitas adalah titik awal, bukan jaminan perilaku yang identik

API yang kompatibel dengan OpenAI mengurangi pekerjaan migrasi klien. Itu tidak membuat model yang berbeda dapat dipertukarkan.

Sebelum Anda menyetujui model untuk produksi, verifikasi:

  • ID model yang tepat saat ini tersedia.
  • Model mendukung endpoint dan modality yang Anda perlukan.
  • Parameter yang diperlukan diterima dan berperilaku seperti yang diharapkan.
  • Panggilan alat, output JSON atau terstruktur, dan streaming lulus pengujian Anda.
  • Batas token sesuai dengan input dan output nyata Anda.
  • Perilaku keamanan sesuai dengan persyaratan produk Anda.
  • Timeout, retry, dan penanganan error tidak menciptakan pekerjaan duplikat atau ambigu.
  • Harga saat ini sesuai dengan campuran trafik yang diharapkan.

Jika Anda membutuhkan daftar periksa rekayasa yang lebih luas, lihat panduan migrasi API gateway yang kompatibel dengan OpenAI. Halaman ini sengaja dibuat lebih sempit: ditujukan untuk tim yang sudah memahami pola migrasi dan ingin mengubah satu perubahan base URL menjadi pengujian multi-model yang adil.

Daftar periksa cutover yang praktis

Berpindah dari evaluasi ke produksi hanya ketika Anda dapat menjawab ya untuk setiap item.

  • Paritas permintaan: Finalis bekerja dengan pola prompt, pesan, alat, dan output Anda yang nyata.
  • Ambang kualitas: Model tersebut memenuhi persyaratan ketat dalam rubrik Anda.
  • Penanganan kegagalan: Aplikasi Anda menangani batas rate limit, timeout, dan respons yang terputus dengan aman.
  • Observabilitas: Anda mencatat model, latensi, penggunaan, kelas error, dan pengenal permintaan aplikasi.
  • Model biaya: Anda telah menghitung pengeluaran yang diharapkan berdasarkan harga saat ini dan penggunaan token yang realistis.
  • Rollback: Anda dapat kembali ke model atau konfigurasi sebelumnya tanpa rilis kode.
  • Rencana canary: Anda dapat mengekspos perubahan ke porsi lalu lintas yang terbatas sebelum peluncuran penuh.

Antarmuka yang stabil memudahkan rollback dan pengujian berulang karena permukaan integrasi tetap konsisten. Keputusan model Anda dapat berubah tanpa memaksa lapisan klien spesifik penyedia baru masuk ke aplikasi setiap kali.

Mulai dengan satu base URL dan workload nyata

Jika tim Anda sudah menggunakan SDK yang kompatibel dengan OpenAI, langkah berikutnya yang berguna bukanlah debat arsitektur lain. Melainkan pengujian terkontrol dengan prompt Anda sendiri.

  1. Buat akun Flatkey dan API key.
  2. Setel base_url ke https://router.flatkey.ai/v1.
  3. Pilih shortlist model kecil dari direktori saat ini.
  4. Jalankan kasus representatif yang sama melalui setiap model.
  5. Tinjau kualitas, latensi, keandalan, penggunaan, dan biaya saat ini bersama-sama.

Bandingkan harga model saat ini dan pilih shortlist Anda, lalu jalankan evaluasi pertama melalui klien yang sama yang sudah digunakan aplikasi Anda.

Pertanyaan yang sering diajukan

Apa itu Flatkey OpenAI-compatible base URL?

Gunakan https://router.flatkey.ai/v1. Konfigurasikan di klien Anda yang kompatibel dengan OpenAI dan autentikasi dengan API key Flatkey.

Apakah saya perlu mengganti OpenAI SDK?

Tidak. Quickstart Flatkey mendokumentasikan penggunaan OpenAI Python dan JavaScript SDK dengan base URL Flatkey. Anda tetap harus menguji setiap fitur permintaan dan kemampuan model yang bergantung pada aplikasi Anda.

Bisakah saya membandingkan beberapa model dengan kode prompt yang sama?

Ya. Pertahankan klien, dataset prompt, dan logika evaluasi tetap stabil, lalu ubah nilai model untuk setiap kandidat. Kemampuan dan parameter spesifik model tetap perlu divalidasi.

Apakah kompatibilitas OpenAI sama dengan perilaku model yang identik?

Tidak. Kompatibilitas mengurangi perubahan integrasi. Model dapat berbeda dalam kualitas output, penggunaan alat, perilaku output terstruktur, latensi, batasan, perilaku keamanan, dan biaya.

Apa yang harus saya ukur dalam pengujian multi-model?

Ukur kebenaran tugas, kepatuhan terhadap instruksi, validitas skema atau alat, latensi, tingkat error, penggunaan token, dan biaya saat ini. Tentukan persyaratan keras sebelum membandingkan preferensi.

Di mana saya harus memeriksa harga model?

Gunakan halaman harga langsung Flatkey alih-alih menyalin harga ke dalam dokumen evaluasi jangka panjang.