Mengoptimalkan biaya untuk beban kerja AI pada Azure

Artikel ini memperlihatkan kepada tim startup tahap awal cara mengidentifikasi dan mengurangi biaya dalam beban kerja AI pada Microsoft Azure. Ini ditulis untuk pendiri, CTO, atau orang teknik pertama yang direkrut yang bertanggung jawab atas tagihan cloud dan set evaluasi (eval) sekaligus. Ini mencakup penandaan dan kebersihan anggaran, empat pengungkit pada jalur permintaan (penyimpanan cache, pemrosesan batch, perutean, dan pemilihan model), penyesuaian kapasitas GPU untuk inferensi yang dihosting sendiri, pola pengambilan data multi-tenant, dan siklus perubahan yang aman yang dapat Anda jalankan tanpa tim platform khusus. Setiap bagian ditandai dengan tahap dari panduan arsitektur Azure untuk startup tempatnya berlaku (Jelajahi, Perluas, atau Ekstrak), sehingga Anda dapat menghindari pengoptimalan untuk masalah yang belum Anda miliki.

Dalam artikel ini, Anda akan mempelajari cara:

  • Identifikasi driver biaya teratas dalam beban kerja AI pada Azure.
  • Cocokkan tuas pengoptimalan biaya dengan tahap startup Anda.
  • Terapkan cache prompt, cache semantik, pemrosesan batch, perutean model, dan penyesuaian kapasitas yang tepat.
  • Rancang mekanisme pengambilan data multi-tenant dan pola database yang dapat diskalakan secara linear seiring pendapatan, bukan seiring penggunaan.
  • Bungkus perubahan biaya di gerbang evaluasi, pemberitahuan anggaran, dan batas tarif per penyewa.
  • Kenali tanda-tanda awal bahwa pendekatan lakukan sendiri untuk mengelola biaya sudah tidak lagi memadai bagi Anda.

Prasyarat

  • Langganan Azure yang memiliki setidaknya satu beban kerja AI yang berjalan di produksi, lingkungan staging, atau prototipe yang berfungsi.
  • Izin Pemilik atau Kontributor pada sumber daya yang ingin Anda ukur.
  • Kenyamanan membuka portal Azure. Tidak diperlukan pengalaman sebelumnya dengan Cost Management atau Azure Monitor. Artikel ini mengarahkan Anda ke halaman yang relevan.
  • Kumpulan evaluasi kecil untuk fitur AI Anda, dengan 10 hingga 50 prompt yang representatif dan perilaku yang diharapkan. Jika Anda belum memilikinya, lihat bagian Artikel terkait. Anda dapat membangun versi pertama di sore hari.

Mengapa ini penting untuk startup

Untuk startup tahap awal, biaya AI berisiko operasional. Inferensi yang lebih murah membebaskan waktu kerja tim engineering untuk eksperimen berikutnya, dan biaya per pengguna aktif yang stabil memungkinkan Anda merencanakan jauh melampaui tonggak pendanaan berikutnya, alih-alih hanya sampai tagihan berikutnya. Pola dalam artikel ini sengaja dibuat kecil. Masing-masing dapat dicapai oleh insinyur pendiri selama akhir pekan, tanpa platform atau tim FinOps yang diperlukan.

Important

Anda tidak memerlukan tim FinOps khusus untuk memulai. 80 persen penghematan biaya awal diperoleh dengan menandai semuanya sejak hari pertama, menunjuk satu orang untuk memimpin peninjauan manajemen biaya mingguan, dan menerapkan langkah-langkah dalam artikel ini sesuai urutan tahap. Membawa alat dan proses FinOps formal hanya setelah pengeluaran melebihi sekitar $ 50.000 per bulan atau mencakup lebih dari lima beban kerja yang berbeda.

Mengapa biaya AI muncul secara berbeda dari biaya cloud tradisional

Dalam aplikasi web tradisional, tagihan bulanan Anda didominasi oleh VM, database, dan keluar. Anda biasanya dapat memprediksinya dalam 10 persen dengan mengetahui berapa banyak pengguna yang Anda layani. Beban kerja AI mematahkan intuisi tersebut. Pengguna yang sama dapat dikenakan biaya $ 0,001 satu menit dan $ 0,40 berikutnya, tergantung pada panjang konteks, kedalaman pengambilan, dan model mana permintaan dirutekan.

Empat bentuk biaya berulang di sebagian besar produk AI pada Azure:

  • Pengeluaran token diskalakan dengan panjang konteks, bukan jumlah pengguna. Prompt retrieval-augmented generation (RAG) yang naif dapat membengkak dari 800 menjadi 12.000 token setelah satu perubahan pada produk.
  • Waktu diam GPU adalah biaya tersembunyi terbesar dalam inferensi yang dihost sendiri. A100 yang dibiarkan berjalan semalaman biayanya lebih mahal daripada biaya operasional database Postgres kecil selama sebulan.
  • Mengambil fan-out dari senyawa database pencarian dan vektor . Setiap giliran obrolan mungkin mengeluarkan tiga hingga delapan kueri tersembunyi yang tidak pernah Anda lihat di log Anda.
  • Egres dan penyimpanan muncul secara perlahan melalui artefak model, embedding, log audit, dan indeks khusus per penyewa.

Setiap faktor biaya memiliki serangkaian pengungkit yang sudah diketahui. Bagian yang tersisa menjelaskannya dalam urutan prioritas, ditandai dengan tahap startup tempat tuas berlaku, sehingga tim tidak melakukan rekayasa berlebihan untuk masalah yang belum mereka miliki.

Tip

Gunakan panduan pengoptimalan biaya dari Azure Well-Architected Framework dalam arsitektur Anda untuk mempertahankan dan meningkatkan laba atas investasi (ROI).

Peta tahapan: tuas mana berada di bagian mana

Panduan arsitektur Azure untuk startup menjelaskan tiga tahap pengembangan produk: Jelajahi, Perluas, dan Ekstrak. Faktor pengoptimalan biaya dalam artikel ini sesuai dengan tahapan tersebut. Gunakan tabel berikut untuk mencakup bagian mana yang berlaku untuk tim Anda hari ini dan yang akan ditangguhkan.

Panggung Jumlah karyawan Tujuan biaya utama Faktor pendorong yang membuahkan hasil
Jelajahi 1-10 teknisi Opsionalitas dan kecepatan Penandaan, cache prompt, model default berbiaya rendah
Perluas 10-50 teknisi Hentikan biaya yang meningkat seiring dengan pendapatan Tembolok semantik, penskalaan ke nol, perutean, API Batch
Ekstrak 50+ insinyur Margin, prediktabilitas, FinOps Reservasi, indeks khusus, kuantisasi, harga per penyewa

Identifikasi faktor pendorong biaya utama Anda

Sebelum mengoptimalkan apa pun, dapatkan pandangan datar tentang ke mana uang benar-benar pergi. Dalam Azure, jalur tercepat adalah Cost Management, dikelompokkan menurut layanan dan tag, selama 30 hari terakhir.

Tandai semuanya sejak hari pertama

Penerapan tag adalah praktik yang memberikan dampak terbesar terhadap visibilitas biaya. Tanpa tag yang konsisten, Anda tidak dapat mengaitkan pengeluaran ke penyewa, fitur, atau lingkungan. Referensi Startup Scale Landing Zone (SSLZ) mewajibkan penandaan pada tingkat kebijakan zona pendaratan. Gunakan pendekatan yang sama untuk sumber daya AI.

costCenter = product | platform | research
tenant     = <customer-id> | shared
workload   = inference | embedding | training | eval
env        = prod | staging | dev
team       = <owning-team>

Di mana harus melihat terlebih dahulu

Faktor pemicu biaya Di mana menemukannya Porsi tagihan biasanya
Token (LLM API) Azure metrik OpenAI > Token Permintaan/Penyelesaian yang Diproses 30-60%
GPUs Jam node VM/AKS berdasarkan SKU (seri ND, NC, dan NV) 20-50%
Vektor/pencarian Unit kueri AI Search, Cosmos DB RU/s 5-20%
Storage Blob Storage, Azure Files, dan Azure Container Registry untuk artefak model 3-10%
Egress Bandwidth di luar wilayah, terutama panggilan lintas cloud 2-15%

Ekspor Manajemen Biaya ke akun penyimpanan setiap hari dan hubungkan ke infrastruktur analitik yang sudah ada. Bagan mingguan biaya per pengguna aktif adalah sinyal yang dapat diandalkan bahwa pengoptimalan memiliki efek yang dimaksudkan.

Tuas 1: Penyimpanan cache, pemrosesan batch, perutean, dan pemilihan model

Tahap: Jelajahi melalui Ekstrak. Mulailah dengan penyimpanan cache di Explore, tambahkan perutean dan Batch di Expand, serta tambahkan pemilihan model yang lebih rinci untuk setiap tenant di Extract.

Tip

Simpan embedding dalam cache dengan hash konten sumber sebagai kunci, dan gunakan model yang lebih kecil dan lebih murah, seperti GPT-4o mini atau model 7B hingga 13B berbobot terbuka, untuk klasifikasi atau ekstraksi tahap awal. Tingkatkan ke model frontier hanya pada permintaan di mana model kecil tidak pasti. Pola ini saja sering memangkas biaya inferensi sebesar 60 hingga 80 persen tanpa kehilangan kualitas yang terukur pada kueri rutin.

Caching

  • Prompt caching: Azure OpenAI secara otomatis mendiskon awalan berulang untuk permintaan setidaknya 1.024 token, didukung pada GPT-4o dan model yang lebih baru. 1.024 token pertama harus identik untuk mencapai cache, jadi jaga agar permintaan sistem dan definisi alat tetap stabil.
  • Semantic cache: Simpan pasangan penyematan dan respons di Azure Cache for Redis atau Cosmos DB. Mengembalikan respons cache saat kueri baru memiliki kesamaan kosinus di atas sekitar 0,95.
  • Cache output: Untuk titik akhir yang tidak dipersonalisasi, seperti FAQ dan alat deterministik, cache time-to-live (TTL) sederhana memotong lalu lintas sebesar 30 hingga 80 persen.

Batching

Pekerjaan penyematan dan klasifikasi adalah kandidat yang jelas. Azure OpenAI Batch API memberikan diskon harga 50 persen dibandingkan pemrosesan real-time untuk tugas yang dapat menunggu hingga 24 jam, seperti penyegaran indeks setiap malam, eksekusi evaluator, dan perangkuman asinkron.

Routing

Sebagian besar produk tidak memerlukan model termahal pada setiap panggilan. Router, baik berbasis aturan atau dipelajari, dapat mengirim 60 hingga 80 persen lalu lintas ke model yang lebih murah tanpa penurunan kualitas yang terukur.

Pola Jalur murah Jalur mahal
Klasifikasi niat GPT-4o mini atau Phi-4 GPT-4o untuk permintaan ambigu
Penggunaan alat atau pemanggilan fungsi Model tingkat menengah Model kelas atas saat percobaan ulang
Ringkasan konteks panjang Jendela geser dengan model tingkat menengah Model kelas atas dengan konteks penuh
Pembuatan kode Model kelas menengah untuk templat standar Model kelas atas untuk pemfaktoran ulang

Pilihan model

Mengevaluasi ulang pilihan model setiap kuartal. Harga dan kualitas bergerak cepat. Model yang enam bulan lalu merupakan satu-satunya pilihan Anda kini mungkin lima kali lebih mahal daripada SKU yang lebih baru dengan selisih skor hanya satu hingga dua poin dalam evaluasi Anda.

Tuas 2: Infrastruktur ukuran yang tepat dengan skala otomatis

Tahap: Perluas dan Ekstrak. Di Explore, gunakan serverless atau platform as a service (PaaS), seperti App Service, Container Apps Consumption, atau Azure OpenAI Service, dan lewati opsi ini.

Jika Anda meng-host inferensi sendiri dengan vLLM, Triton, atau Text Generation Inference (TGI) pada Azure Kubernetes Service (AKS) atau Container Apps, faktor penentu terbesar kedua adalah memastikan GPU tidak menganggur.

Skalakan ke nol pada beban kerja yang tidak aktif

Atur minReplicas: 0 pada Container Apps dengan profil beban kerja GPU, atau gunakan Horizontal Pod Autoscaling (HPA) atau KEDA di AKS untuk menskalakan kumpulan node ke nol saat tidak ada permintaan yang sedang diproses. Awal dingin biasanya puluhan detik. Lakukan benchmark dengan model Anda, dan pertahankan satu replika tetap hangat selama jam kerja jika latensi yang dirasakan pengguna penting.

Sesuaikan SKU GPU dengan ukuran model

Cocokkan kelas GPU dengan jumlah parameter. T4 atau L4 cukup untuk model di bawah sekitar parameter 13B. A100 atau H100 baru sepadan untuk model dengan lebih dari sekitar 34 miliar parameter atau volume kueri per detik (QPS) yang tinggi secara berkelanjutan. GPU tanpa server Container Apps saat ini mendukung T4 dan A100. L4 dan H100 memerlukan AKS.

Meluaskan pelatihan dan pekerjaan batch untuk spot

Jalankan evaluasi malam hari, penyematan refresh, dan ringkasan offline pada kumpulan simpul spot, yang biasanya 60 hingga 80 persen lebih murah daripada sesuai permintaan. Pertahankan inferensi produksi pada kapasitas terdedikasi. Tabel berikut ini meringkas strategi skala otomatis dan penghematan khasnya.

Caution

Kapasitas spot dapat dihentikan dengan pemberitahuan paling singkat 30 detik sebelumnya. Hanya gunakan spot untuk pekerjaan yang dapat dicentang atau dimulai ulang dengan bersih, seperti evals batch, penyematan refresh, ringkasan offline, dan penyempurnaan dengan titik pemeriksaan yang sering. Jangan pernah menempatkan inferensi atau pekerjaan yang menghadap pengguna tanpa memulai ulang logika di tempat.

Strategy Bagaimana Penghematan umum
Skalakan ke nol minReplicas: 0 pada Aplikasi Kontainer dengan profil beban kerja GPU. Awal dingin biasanya puluhan detik. Lakukan benchmark dengan model Anda. Hingga 90%
KEDA berdasarkan panjang antrean Sesuaikan skala berdasarkan pesan Bus Layanan atau pesan antrean, bukan CPU. 30-60%
SKU ukuran yang tepat T4 atau L4 untuk model dengan parameter kurang dari 13B. A100 atau H100 hanya untuk model dengan parameter lebih dari 34B atau QPS tinggi. GPU tanpa server Container Apps saat ini hanya mendukung T4 dan A100. L4 dan H100 memerlukan AKS. 40-70%
Kapasitas Spot Kumpulan simpul spot untuk batch dan evaluasi. Kapasitas sesuai permintaan untuk produksi. 40-80%
Kuantisasi Kuantisasi 4-bit AWQ atau GPTQ agar sesuai dengan model yang lebih besar pada GPU yang lebih kecil. Paskan 30B pada 16 GB

Note

Menskalakan ke nol di antarmuka chat menyebabkan latensi cold start yang terlihat jelas. Pola umumnya adalah menyimpan satu hingga dua replika hangat selama jam kerja dan menskalakan ke nol dalam semalam.

Tuas 3: Pola multi-tenant tanpa lonjakan biaya pengambilan data

Tahap: Ekspansi dan Ekstraksi Akhir. Di Jelajahi, Anda hampir pasti memiliki satu penyewa: diri Anda sendiri. Lewati bagian ini hingga Anda memiliki setidaknya tiga pelanggan nyata.

Produk AI multitenan gagal saat diskalakan ketika mekanisme pengambilan data dan pola basis data dipilih untuk prototipe tenan tunggal. Tiga pola berulang.

Satu indeks per penyewa vs. indeks bersama dengan filter

Indeks AI Search khusus untuk setiap tenant memberikan isolasi yang jelas, tetapi biaya tetap dikenakan untuk setiap indeks meskipun sedang tidak digunakan. Indeks bersama dengan filter tenant jauh lebih murah pada skala kecil hingga menengah. Beralih ke mode khusus hanya untuk tier enterprise atau saat tenant melebihi ambang batas ukuran yang ditentukan.

Pilihan database vektor

Pilih penyimpanan vektor Anda berdasarkan infrastruktur dan skala yang ada. Tabel berikut merangkum kapan masing-masing opsi sesuai.

Warning

Menghapus indeks vektor atau penyimpanan dasarnya tidak dapat dibatalkan, dan melakukan embedding ulang pada korpus besar dapat menelan biaya ratusan hingga ribuan dolar untuk pemanggilan model serta berjam-jam waktu rekayasa. Sebelum melakukan perubahan destruktif apa pun pada penyimpanan vektor, buat snapshot dokumen sumber dan verifikasi bahwa alur penyematan ulang Anda berjalan dari awal hingga akhir pada subkumpulan kecil.

Option Paling cocok untuk Bentuk biaya
Pencarian Azure AI (vektor) Pencarian dan faset hibrid Per-replika, dapat diprediksi
Cosmos DB (vektor) Teams sudah menggunakan Cosmos DB untuk data aplikasi RU/dtk, meningkat seiring dengan QPS
pgvector di PostgreSQL Corpora kecil atau sedang, operasi sederhana Per-VM, sangat murah
Basis data vektor khusus Vektor 100M+, kebutuhan pengenalan tinggi Per simpul, berbiaya tinggi

Hindari pengambilan data N+1 yang tersembunyi

Setiap langkah agen yang memanggil search adalah kueri yang dikenai biaya. Catat jumlah panggilan pengambilan untuk setiap giliran pengguna dan beri peringatan ketika median melebihi anggaran Anda. Target awal yang baik adalah dua kali atau kurang pengambilan data dalam setiap giliran. Pemeringkat ulang dan penulis ulang merupakan titik yang mudah menyebabkan trafik berlipat ganda tanpa sengaja.

Tata kelola: menjaga perubahan biaya tetap aman

Tahap: Semua tahapan. Versi ringan, yang mencakup anggaran, pemeriksaan evaluasi satu baris sebelum penyebaran, dan batas tarif tunggal, termasuk dalam Jelajahi sejak hari pertama. Versi yang lebih kompleks, dengan eval gate yang memblokir CI dan pembatasan laju per tenant di API Management, berada pada tahap Expand dan seterusnya.

Pengoptimalan yang merusak kualitas bukanlah pengoptimalan. Ini adalah gangguan. Bungkus setiap perubahan biaya dalam tiga pagar pembatas. Setiap pagar pembatas dapat diatur dalam waktu kurang dari satu jam oleh satu insinyur.

  1. Pemeriksaan evaluasi: Jalankan rangkaian evaluasi Anda sebelum menerapkan perubahan apa pun pada prompt, model, atau routing. Pada tahap awal, pemeriksaan ini bisa menjadi skrip yang Anda jalankan secara manual. Blokir penerapan atau kembalikan ke versi sebelumnya jika skor turun melebihi batas toleransi Anda, misalnya satu poin pada skala 100 poin.
  2. Peringatan anggaran: Tetapkan anggaran Azure Cost Management per grup sumber daya dengan peringatan pada 50, 80, dan 100 persen. Arahkan ke saluran Slack atau Teams yang sama yang menerima notifikasi error Anda, sehingga pengeluaran dan insiden masuk ke tempat yang sama.
  3. Batas laju permintaan: Bahkan satu batas per IP atau per-API-key di API Management, NGINX, atau gateway Anda mencegah satu klien pelarian mengosongkan saldo kredit Anda dalam semalam. Tambahkan batas per penyewa nanti ketika Anda memiliki pelanggan yang membayar.

Berhati-hatilah dengan menggabungkan beberapa pengoptimalan biaya ke dalam satu rilis. Ketika sekumpulan perubahan digabungkan sekaligus, penentuan penyebab menjadi sulit dan regresi apa pun mahal untuk ditelusuri penyebabnya.

Eksperimen dua tuas: cara membandingkan sebelum dan sesudah

Saat Anda memutuskan di mana harus memulai, pilih dua tuas dari bagian sebelumnya, kirimkan di belakang bendera fitur, dan ukur selama 7 hingga 14 hari. Dua tuas cukup untuk mendeteksi gerakan yang bermakna. Lebih dari dua membuat atribusi tidak dapat diandalkan.

Pasangan pertama yang disarankan berdasarkan tahap

Panggung Tuas A Tuas B
Pra-peluncuran (<100 DAU) Penyimpanan sementara prompt Perutean model dengan model default berbiaya rendah
Daya tarik awal (100-10k DAU) Cache semantik Skala-ke-nol pada inferensi
Skala (10k+ DAU) API Batch untuk pekerjaan asinkron Strategi indeks per penyewa
Tingkat perusahaan Indeks khusus untuk akun teratas Model kuantisasi pada L4 atau H100 
Baseline window:   2026-04-15 to 2026-04-28 (14 days)
Treatment window:  2026-05-01 to 2026-05-14 (14 days)
Levers shipped:    1) semantic cache on /chat
                   2) scale-to-zero on vLLM

Metrics:
  cost_per_active_user   (target: down 30%)
  p95_latency_ms         (guardrail: +<= 150 ms)
  eval_score_delta       (guardrail: >= -1.0)

Decision rule: Keep both if all guardrails hold. Otherwise, revert and ship one at a time.

Apa yang dibahas artikel ini dan apa yang tidak dibahasnya

Artikel ini sengaja dibatasi cakupannya. Bagian berikut mencantumkan topik yang berada dalam cakupan, topik yang berada di luar cakupan, dan sinyal yang menunjukkan kapan harus menambahkannya.

Termasuk dalam cakupan

  • Pelabelan, anggaran, dan praktik pengelolaan biaya yang tepat untuk perusahaan rintisan apa pun.
  • Empat tuas jalur permintaan: penyimpanan cache, pemrosesan batch, perutean, dan pemilihan model.
  • Penyesuaian ukuran GPU dan penskalaan ke nol untuk inferensi yang dihosting sendiri.
  • Pola pengambilan data multitenan untuk produk dengan tiga hingga 100 tenant berbayar.
  • Siklus tata kelola perubahan yang aman: gerbang evaluasi, peringatan anggaran, dan batas laju per penyewa.

Di luar cakupan

Topic Kapan harus menambahkannya
Reservasi dan paket penghematan untuk komputasi AI Tagihan inferensi tetap selama 90 hari, biasanya hingga pertengahan Expand.
Alat FinOps khusus, seperti Apptio Cloudability, Vantage, dan alat serupa Pengeluaran cloud melebihi sekitar $50.000 per bulan, atau Anda mengoperasikan multi-cloud. Sebagian besar startup tahap awal tidak memerlukan ini.
Penagihan berbasis token kustom per pelanggan akhir Anda menjual harga berbasis penggunaan, atau satu penyewa melebihi 25 persen dari tagihan.
Pengoptimalan biaya pelatihan, seperti DeepSpeed dan penyetelan FSDP Anda melatih model di rumah. Produk yang mengutamakan inferensi tidak memerlukan ini.
Arbitrase biaya lintas wilayah atau multi-cloud Anda berada pada tahap Extract dengan ekonomi satu wilayah yang sudah terbukti.

Ketika pendekatan ini tidak lagi cukup

Praktik dalam artikel ini dirancang untuk tim kecil yang menjalankan cloud mereka sendiri. Pada titik tertentu, bisnis Anda melampaui mereka. Sinyal berikut bukan kegagalan. Mereka adalah pertumbuhan. Jika dua atau lebih kondisi ini terpenuhi, pertimbangkan untuk menghadirkan tool khusus atau penanggung jawab platform paruh waktu.

  • Pengeluaran Azure bulanan melebihi sekitar $50.000, dan AI lebih dari 30 persen.
  • Lebih dari 10 insinyur dapat mengirimkan perubahan yang memindahkan biaya sebesar 5 persen atau lebih.
  • Setidaknya satu pelanggan memiliki penggunaan di atas $ 10.000 per bulan dan membayar Anda biaya tetap.
  • Investor atau mitra keuangan Anda telah mulai meminta prakiraan biaya bulanan.
  • Produk berjalan di lebih dari satu wilayah atau cloud Azure.

Sampai saat itu, siklus sederhana yang dibahas dalam artikel ini, yang mencakup tag, anggaran, tahap evaluasi, dan ulasan bulanan, adalah alat yang tepat. Tahan godaan untuk mengadopsi alat FinOps perusahaan lebih awal. Ini menambahkan overhead proses sebelum menambahkan nilai.

Daftar periksa referensi

Gunakan item berikut sebagai daftar periksa ulasan bulanan. Setiap item sesuai dengan bagian di artikel ini.

  • Semua sumber daya AI ditandai dengan costCenter, , tenant, workloaddan env.
  • Dasbor Cost Management ada, dikelompokkan menurut tag, dan ditinjau mingguan.
  • Prompt sistem cukup stabil sehingga menghasilkan hit pada cache prompt.
  • Pekerjaan asinkron, seperti penyematan, evaluasi, dan ringkasan, berjalan pada API Batch.
  • Router mengirimkan setidaknya 60 persen lalu lintas ke model yang lebih murah tanpa regresi evaluasi.
  • Beban kerja GPU diskalakan ke nol di luar jam kerja atau menggunakan instans spot untuk pemrosesan batch.
  • Median jumlah pengambilan data per giliran adalah dua atau kurang.
  • Strategi multitenan ditentukan secara eksplisit: mode bersama dengan filter atau mode khusus.
  • Anggaran dan batas tarif per penyewa diberlakukan.
  • Setiap perintah, model, atau perubahan perutean menjalankan gerbang evaluasi sebelum digabungkan.
  • Last updated on