Cara mengevaluasi AI API Gateway: checklist production
Proses reproduksibel untuk menguji protocol, failure, latency, usage dan cost, security, control plane, dan exit risk.
Evaluasi AI API gateway dengan menjalankan Protocol Contract sebenarnya, memaksa Failure Modes yang penting, dan memeriksa Request-level Evidence. Feature List atau “hello world” yang berhasil tidak membuktikan streaming yang benar, Tool Compatibility, fallback aman, Cost Accuracy, Security Boundary, maupun Exit Path.
Proses paling andal memisahkan dua kriteria: Mandatory Gates yang menggugurkan kandidat dan kualitas operasional yang baru diberi Evidence Score setelah semua gate lolos.
Definisikan Workload Contract terlebih dahulu
Jangan mulai dari tabel vendor. Pilih satu workload representatif dan tulis invariant contract:
- endpoint tepat: Responses, Chat Completions, Embeddings, Images, atau API lain;
- Model ID tepat dan apakah Alias diizinkan;
- mode Streaming dan Non-streaming yang digunakan;
- Structured Outputs, Function Calling, Hosted Tools, Reasoning, dan Field wajib;
- panjang Input/Output tipikal dan high-percentile;
- Concurrency, Request Rate, Region, dan User-facing Deadline;
- field Usage, Cache, Cost, dan Request Correlation yang diperlukan;
- Fallback Route yang diizinkan dan apakah Model Substitution dilarang;
- kebutuhan Data Retention, Access, Residency, dan Deletion;
- Application Operation yang dapat membuat Side Effect.
Satu gateway dapat lolos untuk text-only internal assistant tetapi gagal untuk streaming coding agent. “OpenAI-compatible” bukan definisi cukup karena Compatibility berbeda per Endpoint, Event Type, Tool, Schema Keyword, dan Provider Route.
Jika tim masih menentukan antara proxy atau Model-aware Control Plane, mulai dari LLM Proxy vs AI Gateway. Checklist ini menganggap kategori gateway sudah dibenarkan dan menguji implementasi tertentu.
Terapkan diskualifikasi cepat sebelum trial panjang
Review pertama harus menghapus kandidat yang tidak memenuhi batas wajib. Minta perilaku yang dapat direproduksi, bukan pernyataan roadmap.
| Gate | Kondisi gagal langsung | Evidence yang diminta |
|---|---|---|
| Protocol | Request Field, Output Item, atau Stream Event wajib hilang atau ditulis ulang salah | Request/response yang telah disensor dan Parser Result |
| Model Identity | Requested Model diganti diam-diam | Attempt Record dengan model diminta dan aktual |
| Streaming | Buffer seluruh response, kehilangan Cancellation, atau merusak Tool Argument Fragments | Timestamped Event Sequence dan Cancel Trace |
| Authentication | Browser atau Workload Client menerima Provider Credentials | Credential Flow dan Key Rotation nyata |
| Tenant Isolation | Satu Project dapat memakai/melihat Keys, Usage, atau Logs Project lain | Pemeriksaan dengan Account yang benar-benar terisolasi |
| Cost Evidence | Final Charge tidak dapat dihubungkan ke Model, Route, Price Basis, Usage | Reconciled Ledger satu Request |
| Failure Safety | Partial Stream diputar ulang transparan atau Cancel memulai Attempt baru | Partial-stream dan Cancellation Trace yang dipaksa |
| Export and Exit | Configuration dan Contract tidak dapat dipulihkan tanpa menulis ulang aplikasi | Export Sample dan Provider-native Rollback Drill |
Kegagalan Mandatory Gate tidak dapat dikompensasi skor total tinggi. Dashboard bagus tidak memperbaiki Tenant Isolation dan harga rendah tidak memperbaiki Tool Contract yang salah.
Bangun Protocol Conformance Corpus yang kecil
Gunakan Input deterministik dan non-sensitif serta version control untuk Expected Wire Behavior. Corpus harus memanggil endpoint asli; jangan Mock Provider atau menyalin Conversion Logic sebagai Test Oracle.
| Case | Request | Observasi wajib |
|---|---|---|
| Basic Non-streaming Text | Pinned Model dan Prompt tetap | Status, Model Identity, Text Location, Usage, Request ID benar |
| Streaming Text | Prompt sama dengan Streaming | Events berurutan, First Effective Output, Final Event, Cancellation |
| Structured Output | Strict Schema dengan Required dan additionalProperties: false |
Output valid atau Unsupported Error eksplisit, tanpa Silent Downgrade |
| Function Calling | Satu Read-only Function dan Result dikembalikan | Function Name, JSON Arguments, Call ID Correlation, Final Answer |
| No-tool Path | Tools dideklarasikan tetapi tidak dibutuhkan | Teks normal tanpa Tool Call buatan |
| Invalid Field | Request Unsupported atau Malformed sengaja | Client Error stabil; fallback tidak menyembunyikan cacat |
| Long Input Boundary | Input tepat di bawah dan atas Limit | Acceptance terdokumentasi atau Rejection eksplisit, tanpa Silent Truncation |
| Usage Detail | Request yang memicu Cache atau Reasoning Usage | Field melewati Route dan cocok dengan Billing Record |
| Cancellation | Cancel sesudah connect dan sesudah First Output | Upstream Work berhenti dan Fallback Attempt baru tidak mulai |
| Partial Stream | Connection Failure setelah Effective Output | Satu Partial Failure eksplisit, tanpa jawaban kedua tersembunyi |
Jalankan setiap Case pada semua Route yang dapat melayani workload. Primary Route yang lolos tidak otomatis meloloskan fallback. Panduan Structured Outputs dan perbandingan Function Calling menyediakan Field-level Cases.
Catat Gateway Version, Route Configuration Version, Model ID, Provider, Region, Timestamp, dan Sanitized Result Hash. Uji ulang sebelum rollout dan sesudah Route Change material.
Uji Routing dan Failure Behavior, bukan hanya sukses
Reliability Claim hanya berarti jika Failure Policy terlihat. Paksa kondisi berikut sebelum Production:
- Primary Route unavailable sebelum Headers;
- Provider Rate Limit dengan dan tanpa
Retry-After; - Upstream Authentication atau Account Failure;
- Slow Headers dan Slow First Effective Output;
- Malformed Provider Response;
- Caller Cancellation saat upstream pending;
- Connection Loss sesudah visible output mulai;
- semua route eligible habis.
Untuk setiap Case, simpan Attempt Order, Selected Route, Status, Timing, apakah Output sudah mulai, Terminal Reason, Usage, dan Cost. Pastikan model dan protocol diminta tetap sama kecuali ada Model-substitution Policy eksplisit.
Ukur Attempt Amplification di SDK, Application, Gateway, dan Provider. Satu layer menangani Same-contract Fallback langsung, sedangkan aplikasi menentukan apakah seluruh User Action boleh diulang. AI API Fallback Strategy memberikan Failure Matrix berbasis fase dan Retry Budget.
Latency membutuhkan ketepatan sama. Bandingkan Upstream Headers, First SSE Event, First Effective Output, First Visible Text, Completion, dan Visible Output Speed pada Concurrency realistis. Jangan menerima satu rata-rata “Latency” tanpa definisi. Lihat AI API Latency Metrics.
Rekonsiliasi Usage dan Cost dari satu Request
Ikuti beberapa Request selesai melalui seluruh chain:
application request ID
→ gateway attempt sequence
→ selected model and route
→ provider or normalized usage
→ applicable price basis
→ final recorded charge
Evaluasi harus menjawab:
- Apakah Input, Output, Cached, Reasoning, dan Tool-related Units tersedia?
- Nilai mana dari Provider dan mana yang Estimated?
- Kapan Model Price dipilih dan apakah dibekukan untuk Request?
- Bagaimana Group, Service Tier, Discount, atau Surcharge mengubah User Charge?
- Failed Attempt mana yang menciptakan Provider Cost dan bagaimana dicatat?
- Apakah fallback sukses menyembunyikan Billable Attempts sebelumnya?
- Apakah Currency Conversion dan Rounding Rules eksplisit?
- Dapatkah Finance mereproduksi Daily Total dari Immutable Records?
Uji Normal Completion, Same-contract Fallback, Cancelled Request, dan Upstream Error. Dashboard Total tidak cukup; perlu Per-request Record yang defensible. AI API Cost Tracking memisahkan Provider Usage, Platform Pricing, Customer Charge, dan Supplier Cost.
Jangan bandingkan savings tanpa menjaga Model, Workload, Cache Behavior, Output Length, Failure Rate, dan Provider Price Basis tetap sama. Biaya tampak rendah bisa berasal dari Missing Usage atau Silent Model Substitution.
Verifikasi Security dan Data Boundary
Gambarkan Data Flow asli dari Client ke Gateway dan tiap Provider. Pada setiap Hop, identifikasi akses ke Credentials, Request/Response Content, Metadata, dan Administrative Configuration.
Setidaknya verifikasi:
- Provider Credentials tetap Server-side, At-rest Encrypted, dan tidak pernah dikirim ke client umum;
- Application Keys dapat di-Scope per Project/Workload dan di-Revoke independen;
- Authorization Server-side berlaku pada semua Management dan Log Endpoints;
- Logs tidak menyimpan API Key penuh dan Prompt/Response Retention dikontrol eksplisit;
- Support Access terbatas dan dapat diatribusikan;
- perubahan memiliki Actor, Time, Before/After, dan Rollback Evidence;
- Exported Traces menghapus Secrets serta konten personal/proprietary;
- Deletion dan Retention dapat didemonstrasikan;
- Region dan Subprocessor Claims sesuai route aktual;
- Abuse Limits berjalan sebelum Upstream Work mahal bila mungkin.
Tanyakan dampak Key Rotation, Operator Departure, compromised Application Key, dan Provider-key Leak. Jalankan Rotation/Revocation dengan Test Credentials terisolasi, tanpa menyalin Production Secret.
Gateway tidak membuat Application Tools yang tidak aman menjadi aman. Tool Authorization, Transactionality, Approval, dan Idempotency tetap Application Responsibilities. AI API Key Security and Cost Controls memisahkan Credentials dan Workload Limits.
Evaluasi Operational Control Plane
Data Plane dapat bekerja sementara Control Plane menimbulkan risiko.
| Area | Pertanyaan wajib |
|---|---|
| Versioning | Apakah setiap Route, Price, Policy, dan Key Change berversi atau punya Actor? |
| Validation | Apakah Invalid Route atau Incompatible Model ditolak sebelum aktif? |
| Rollout | Dapatkah Change dimulai pada Workload/Percentage kecil? |
| Rollback | Dapatkah Last-known-good Configuration dipulihkan cepat? |
| Availability | Apa yang terjadi pada Existing/New Requests tanpa Control Plane? |
| Health | Apakah Channel Health memakai Evidence terkini dan Auto-disable dapat diaudit? |
| Incidents | Dapatkah satu Request direkonstruksi tanpa banyak sistem terpisah? |
| Limits | Apakah Rate/Quota Decisions tetap benar pada Concurrency tinggi? |
| Change Ownership | Apakah Emergency Edits terpisah dari Product Configuration? |
Selesaikan satu Configuration Rollback dan satu Unhealthy-route Removal. Hitung Operator Steps dan verifikasi Data-plane Behavior. Screenshot tombol bukan drill.
Uji Exit Path sebelum menandatangani
Gateway dapat membuat dependency pada Model Aliases, Custom Headers, Proprietary Route Names, Log APIs, Normalized Error Shapes, atau Hosted Prompt/Tool Configuration. Tentukan apakah tiap dependency adalah manfaat sengaja atau Lock-in tidak sengaja.
Exit Drill praktis harus:
- export Route, Key Policy, Price, dan Audit Configuration dalam format terdokumentasi;
- pindahkan satu Workload ke Provider-native Test Endpoint;
- ganti Gateway-only Headers/Aliases dengan Application Configuration eksplisit;
- jaga Request Correlation dan Usage Reconciliation selama perpindahan;
- dokumentasikan fungsi yang tidak dapat dipindah tanpa Redesign;
- estimasikan Exit Engineering dari pekerjaan nyata, bukan Sales Claim.
Exit Path tidak menuntut gateway interchangeable dengan semua Provider. Tim harus mengetahui Ownership-nya, Ownership gateway, dan cara memulihkan Protocol Contract dasar.
Beri skor hanya setelah semua Gate lolos
Gunakan pass/fail untuk Hard Boundaries dan skala Evidence kecil:
| Skor | Arti |
|---|---|
| 0 | Unsupported atau dibantah oleh test |
| 1 | Claimed atau didemonstrasikan sekali, Evidence lemah |
| 2 | Dapat diulang dengan Request-level Evidence |
| 3 | Dapat diulang, Monitored, dan Recoverable melalui Control teruji |
Nilai Protocol Coverage, Route Reliability, Attempt Evidence, Latency Diagnostics, Usage Accuracy, Cost Reconciliation, Key Isolation, Auditability, Configuration Rollback, Supportability, dan Exit Effort sesuai workload. Simpan Raw Evidence di samping setiap skor.
Hindari False Precision seperti 87.4/100. Dokumentasikan Gates, Evidence Links, Accepted Gaps dan Owner, Remediation Deadline, Cost/Contract Assumptions, kandidat terpilih dan ditolak, serta Review Date setelah bulan pertama Production.
Bandingkan Build dan Buy berdasarkan Ownership
Pertanyaannya bukan apakah gateway internal bebas License Fee, tetapi tanggung jawab apa yang dapat dimiliki tim terus-menerus.
| Tanggung jawab | Build internal | Purchased atau Managed |
|---|---|---|
| Protocol Updates | Pantau Provider Schemas dan Regressions | Verifikasi Vendor Updates dan Route Compatibility |
| Routing and Retry | Rancang State Machine dan Failure Evidence | Atur Policy dan audit Attempts aktual |
| Usage and Billing | Normalize Usage dan pelihara Pricing Logic | Rekonsiliasi Vendor Records dengan Finance Truth |
| Security | Simpan Secrets, tegakkan Tenancy, audit Access | Validasi Vendor Boundary dan Least Privilege |
| Reliability | Operasikan Data Plane, Control Plane, On-call | Monitor Vendor dan Integration, pertahankan Exit Path |
| Product Support | Diagnosis semua interaksi Application/Provider | Triase fault Gateway, Provider, dan Application |
Jangan memakai angka salary generik atau “engineering time saved”. Estimasi dari On-call Load, Protocol-change History, Incident Frequency, Finance Requirements, dan Compliance Work sendiri. Managed Product tetap butuh Accountable Internal Owner.
Terapkan checklist ke Modelflare secara akurat
Batas evaluasi Modelflare saat ini harus eksplisit. Platform menyediakan Workload API Keys, routing Requested Model melalui Groups dan Channels eligible, Ordered Group Fallback untuk regular Keys, Strategy-based Group Selection untuk Smart API Keys, Pre-upstream Group RPM Admission, serta Request-level Records untuk Usage, Cost, Status, dan Timing.
GPT, Codex, dan OpenAI Traffic adalah target compatibility yang diadaptasi penuh. Model Family OpenAI-compatible lain harus dievaluasi sebagai Raw Chat Completions Pass-through sampai capability terverifikasi. Shared Base URL tidak membuktikan Responses, Hosted Tools, Structured Outputs, atau Function Calling identik di setiap Route.
Fallback Modelflare harus mencari jalur eligible untuk Requested Model, bukan diam-diam memilih model lain. Channel Failover berhenti setelah Downstream Output dimulai. Uji claim ini dengan Corpus dan Failure Drills.
Gunakan Models & Pricing untuk Model/Group Surface saat ini dan Modelflare Docs untuk Test Key terisolasi. Gunakan Request non-sensitif, pin exact model, dan simpan Request IDs untuk menyelidiki Attempts.
Keputusan akhir harus reproduksibel: Engineer lain dapat menjalankan corpus yang sama, memeriksa kategori Evidence yang sama, dan memahami mengapa kandidat lolos. Ini lebih lambat daripada membaca comparison page, tetapi jauh lebih cepat daripada menemukan Tool Contract incompatibility, billing tak terlacak, atau fallback tidak aman setelah gateway melayani Production Traffic.