Function Compute:Ikhtisar penagihan

Kuota percobaan

Function Compute menyediakan kuota percobaan (paket sumber daya percobaan CU) untuk pengguna baru. Jika Anda belum membeli jenis paket sumber daya lainnya, penggunaan yang melebihi kuota percobaan dalam setiap siklus penagihan akan dikenai biaya berdasarkan metode bayar sesuai penggunaan.

Bayar sesuai penggunaan

Anda dikenai biaya berdasarkan sumber daya komputasi yang benar-benar Anda gunakan. Secara default, ketika jumlah instans minimum adalah 0, tidak ada biaya yang dikenakan jika tidak terjadi pemanggilan fungsi. Namun, jika Anda mengatur jumlah instans minimum menjadi 1 atau lebih tinggi, instans tetap berjalan 24/7 dan terus-menerus dikenai biaya: periode pemrosesan permintaan ditagih dengan tarif instans elastis (aktif), sedangkan periode idle (tidak ada permintaan tertunda) ditagih dengan tarif instans elastis (idle). Untuk informasi selengkapnya, lihat Konfigurasikan kebijakan elastis untuk jumlah instans minimum.

Rencana Sumber Daya

Function Compute menawarkan paket sumber daya CU dalam tier bulanan dan tahunan. Setelah Anda membeli paket sumber daya, paket tersebut akan mengimbangi konsumsi sumber daya Anda terlebih dahulu. Ketika paket habis, penagihan secara otomatis beralih ke metode bayar sesuai penggunaan. Paket sumber daya menawarkan harga satuan yang lebih rendah sehingga mengurangi biaya keseluruhan Anda.

Kolam sumber daya resident (langganan)

Kolam sumber daya resident menyediakan kapasitas komputasi GPU melalui langganan bulanan. Beli kolam, tetapkan instans resident ke fungsi GPU Anda, dan dapatkan biaya yang dapat diprediksi tanpa cold start.

Item yang dapat ditagih

Biaya Function Compute terdiri dari dua bagian:

• Penggunaan CU: Function Compute menggunakan penggunaan CU sebagai item penagihan terpadu. Seluruh penggunaan sumber daya dikonversi ke penggunaan CU menggunakan faktor konversi tetap. Topik ini berfokus pada cara pengukuran dan penagihan penggunaan CU.

• Lalu lintas Internet arah keluar: Lalu lintas Internet arah keluar digabungkan dengan produk Alibaba Cloud lain yang menghadap Internet dan ditagih di sisi CDT. Untuk informasi selengkapnya, lihat Penagihan CDT. Lalu lintas Internet arah keluar terdiri dari tiga bagian berikut:

  1. Lalu lintas transfer data dalam fungsi: lalu lintas yang dihasilkan ketika suatu fungsi menginisiasi permintaan ke Internet.

  2. Lalu lintas permintaan-respons fungsi: lalu lintas yang dihasilkan ketika suatu fungsi dipanggil melalui Internet dan mengembalikan respons.

  3. Lalu lintas back-to-origin dari CDN: lalu lintas yang dihasilkan ketika Function Compute berfungsi sebagai server origin untuk CDN dan terjadi pengambilan back-to-origin oleh CDN.

Harga satuan

Penggunaan CU ditagih berdasarkan tier bulanan dan dihitung secara independen per wilayah. Penggunaan CU di setiap wilayah diakumulasi secara terpisah dan tidak digabungkan antar-wilayah. Untuk informasi selengkapnya, lihat Contoh penagihan.

Siklus penagihan

Function Compute menagih secara per jam. Penggunaan CU per fungsi per jam dibulatkan ke atas, kemudian dijumlahkan dari semua fungsi untuk menghasilkan total penggunaan CU per jam. Jika Anda memiliki paket sumber daya, paket tersebut akan mengimbangi penggunaan CU terlebih dahulu. Setelah paket habis, penagihan berdasarkan metode bayar sesuai penggunaan diterapkan.

Rumus perhitungan

Seluruh penggunaan sumber daya dikonversi ke penggunaan CU menggunakan faktor konversi tetap, lalu dijumlahkan untuk mendapatkan total penggunaan CU.

Penggunaan CU = Σ(penggunaan sumber daya × faktor konversi CU)

Penggunaan sumber daya

Instans elastis memiliki dua status: aktif dan idle. Ketika sebuah instans tidak memiliki permintaan untuk diproses atau tidak menjalankan tugas latar belakang, instans tersebut secara otomatis memasuki status idle. Tabel berikut menjelaskan skenario untuk setiap status:

Ambang batas untuk menentukan status aktif dan idle

Sistem menggunakan indikator berikut untuk menentukan apakah sebuah instans telah memasuki status idle. Semua kondisi harus terpenuhi secara bersamaan:

• Pemanfaatan CPU — Ketika pemanfaatan vCPU instans terus-menerus berada di bawah 0,01 core vCPU (setara dengan pemanfaatan 1% dari satu core), kondisi CPU untuk status idle terpenuhi.

• Pemanfaatan GPU — Ketika prosesor aliran GPU, decoder, dan komponen lainnya berada di bawah ambang batas sistem, kondisi GPU untuk status idle terpenuhi. Ambang batas ini bervariasi tergantung seri GPU.

• Lalu lintas jaringan — Ketika lalu lintas jaringan inbound dan outbound instans terus-menerus berada di bawah 1.000 byte/detik, kondisi jaringan untuk status idle terpenuhi.

• Pemrosesan permintaan — Instans tidak memproses permintaan HTTP atau tugas latar belakang apa pun.

Durasi aktif dan idle tidak ditampilkan secara langsung dalam log pemanggilan. Daftar Invocation Requests di halaman Logs Konsol menampilkan bidang seperti durasi eksekusi dan penggunaan memori, tetapi tidak menunjukkan durasi aktif atau idle sebuah instans. Untuk melihat durasi eksekusi permintaan, Anda dapat mengaktifkan metrik tingkat permintaan di konfigurasi fungsi, lalu memeriksa durasi eksekusi di daftar Invocation Requests pada halaman Logs.

Resource usage = elastic instance (active) usage + elastic instance (idle) usage. Ketika sebuah instans idle, sistem secara otomatis membekukan beberapa sumber daya dan menagih dengan tarif keep-alive minimum:

• Sumber daya vCPU: Tidak dikenai biaya.

• Sumber daya GPU: Dikenai biaya sebesar 11,7% hingga 23% dari tarif aktif tergantung seri GPU:

  Ada.1 series	Seri Ada.2	Ada.3 series	Seri Tesla	Seri Hopper	Seri Hopper.1	Seri Hopper.2	Seri Ampere	Seri Blackwell.1	Seri Xpu.1
  11,7%	11,7%	11,7%	23%	13%	14%	14%	16%	13%	19%

Mengatur jumlah instans minimum menjadi 1 atau lebih tinggi cocok untuk workload yang sensitif terhadap latensi (afinitas sesi, koneksi persisten, dll.) dan skenario tugas latar belakang. Ini memberikan manfaat berikut:

• Warm start: Mencapai warm start tingkat milidetik agar layanan tetap berjalan tanpa gangguan.

• Pengiriman terjamin: Mengunci sumber daya elastis untuk menjamin ketersediaan sumber daya.

• Penagihan cerdas untuk periode sibuk dan idle: Secara otomatis beralih ke penagihan idle ketika tidak ada permintaan atau tugas latar belakang, sehingga lebih mengurangi biaya.

Penagihan pemanggilan dalam skenario afinitas sesi MCP

Ketika Anda men-deploy MCP Server di Function Compute dan mengaktifkan session affinity untuk Streamable HTTP, permintaan initialize dan permintaan tools/call berikutnya dalam protokol MCP merupakan permintaan HTTP terpisah, dan masing-masing memicu pemanggilan fungsi FC terpisah. Setiap pemanggilan ditagih secara independen berdasarkan penggunaan CU aktualnya. Akibatnya, satu pemanggilan tool (initialize + tools/call) menghasilkan 2 pemanggilan fungsi. Permintaan initialize biasanya memicu cold start, dan permintaan berikutnya menggunakan kembali instans yang sama tetapi tetap ditagih sebagai pemanggilan terpisah.

Faktor konversi CU

Penagihan untuk kode status error

Penggunaan CU didasarkan pada apakah permintaan mencapai instans fungsi dan instans tersebut dieksekusi, bukan pada kode status HTTP yang dikembalikan fungsi. Setelah permintaan mencapai instans fungsi dan fungsi berjalan, pemanggilan tersebut ditagih berdasarkan durasi eksekusi aktual dan konsumsi sumber daya, terlepas dari apakah fungsi mengembalikan kode status 200, 404, 401, atau kode status HTTP lainnya.

Jika permintaan ditolak di lapisan gerbang sebelum mencapai instans fungsi — misalnya, kode 404 dikembalikan karena tidak ada HTTP trigger yang dikonfigurasi — tidak ada instans fungsi yang berjalan dan tidak ada penggunaan CU yang dikenai.