Apa itu Model Serving? Menggunakan Model AI yang Berfungsi pada Skala Besar

Melatih model AI adalah masalah penyelidikan. Membuatnya menjawab ribuan permintaan sesaat dengan latency yang konsisten, ketersediaan tinggi dan kos yang boleh diramalkan adalah masalah kejuruteraan yang berbeza. Model serving adalah lapisan infrastruktur yang merapatkan jurang antara model yang dilatih dan sistem pengeluaran yang boleh dipercayai oleh perniagaan.

Bagi pemimpin teknologi dan operasi, model serving adalah tempat kebanyakan penggunaan AI dunia nyata berjaya atau gagal. Modelnya mungkin sangat baik. Tetapi jika infrastruktur serving tidak dapat mengendalikan beban, mengekalkan masa operasi atau mengawal kos, nilai perniagaan tidak akan pernah terwujud.

Apa itu Model Serving

Model serving adalah set perisian dan infrastruktur yang mendedahkan model machine learning yang dilatih sebagai perkhidmatan yang boleh dipanggil. Apabila aplikasi anda menghantar pertanyaan pengguna kepada pembantu AI, model serving adalah lapisan yang menerima permintaan, menghalakannya kepada tika model yang sedang berjalan, melaksanakan model dan mengembalikan hasilnya.

Dalam bentuknya yang paling mudah, model serving melibatkan:

• Tika model yang sedang berjalan (dimuatkan ke dalam memori GPU atau CPU)
• Endpoint API yang menerima permintaan
• Logik untuk mengurus serentak (mengendalikan berbilang permintaan serentak)
• Mekanisme untuk mengembalikan keputusan kepada pemanggil

Dalam amalan, model serving dalam pengeluaran adalah jauh lebih kompleks. Ia merangkumi autoscaling (melancarkan lebih banyak tika model di bawah beban dan menskalakan ke bawah untuk menjimatkan kos), load balancing (mengedarkan permintaan merentasi tika), health checks (mengesan dan menggantikan tika yang gagal), versionan (menjalankan berbilang versi model serentak semasa rollout) dan monitoring (menjejaki latency, kadar ralat dan penggunaan sumber).

Bagaimana Model Serving Berbeza daripada Terma Berkaitan

Terma-terma ini sering digunakan secara longgar, dan perbezaannya penting untuk membuat keputusan.

Inference adalah tindakan menjalankan model pada input untuk menghasilkan output. Ia adalah operasi pengkomputeran. Model serving adalah infrastruktur yang menjadikan inference tersedia sebagai perkhidmatan yang boleh dipercayai.

Pengoptimuman inference merujuk kepada teknik yang menjadikan inference lebih pantas atau lebih murah: quantization, batching, caching, pengoptimuman kernel. Pengoptimuman adalah sifat model dan runtime. Serving adalah sistem yang mengehoskan dan mendedahkan model yang dioptimumkan.

MLOps adalah amalan yang lebih luas dalam mengoperasikan machine learning, termasuk saluran paip latihan, penjejakan eksperimen, pendaftaran model, automasi penggunaan dan monitoring. Model serving adalah satu komponen dalam kitaran hayat MLOps, khususnya lapisan penggunaan dan runtime.

Model deployment kadangkala digunakan secara bergantian dengan model serving, tetapi deployment lebih tepat merujuk kepada tindakan menjadikan model tersedia (peristiwa peralihan), manakala serving merujuk kepada keadaan operasi berterusan ketersediaan tersebut.

Seni Bina Sistem Serving dalam Pengeluaran

Sistem model serving dalam pengeluaran biasanya mempunyai beberapa lapisan:

Model registry. Simpanan berversi artefak model yang dilatih. Sebelum model boleh disajikan, ia mesti didaftarkan (bersama metadata: tarikh latihan, penanda aras prestasi, kebergantungan).

Serving runtime. Perisian yang memuatkan model dan melaksanakan inference. Pilihan biasa termasuk TensorFlow Serving, TorchServe, NVIDIA Triton Inference Server dan runtime yang diurus oleh pembekal seperti AWS SageMaker atau endpoint Azure ML. Untuk large language model khususnya, framework seperti vLLM, TGI (Text Generation Inference) dan Ollama digunakan secara meluas.

API gateway. Menghala permintaan masuk, menguatkuasakan pengesahan dan had kadar, serta menyediakan alamat endpoint yang stabil yang tidak berubah apabila infrastruktur serving asas berskala atau dikemas kini.

Autoscaler. Memantau volum permintaan dan penggunaan sumber, kemudian menambah atau mengeluarkan tika model untuk memadankan beban. Ini adalah mekanisme yang membolehkan sistem mengendalikan lonjakan trafik 10x tanpa pra-peruntukan untuk kapasiti puncak sepanjang masa.

Model monitoring. Menjejaki latency, kadar ralat dan kualiti output dalam pengeluaran. Memberi amaran apabila tingkah laku model menyimpang daripada garis asas.

Keputusan Perniagaan dalam Model Serving

Model serving adalah tempat tradeoff kos dan kebolehpercayaan pelaburan AI anda menjadi konkrit. Pemimpin perniagaan biasanya mempengaruhi beberapa keputusan utama.

Diurus berbanding dihoskan sendiri. Pembekal awan (AWS, Azure, Google Cloud) menawarkan platform model serving yang diurus di mana pembekal mengendalikan penskalaan, perkakasan dan pengurusan runtime. Serving yang dihoskan sendiri (pada infrastruktur awan anda sendiri atau on-premises) memberikan lebih kawalan dan berpotensi kos yang lebih rendah pada skala besar tetapi memerlukan pelaburan kejuruteraan untuk beroperasi.

Kebanyakan syarikat pasaran pertengahan bermula dengan serving yang diurus daripada pembekal utama dan beralih kepada dihoskan sendiri pada skala yang lebih besar atau apabila ekonomi kos membenarkan overhed kejuruteraan.

Endpoint dikongsi berbanding khusus. Kebanyakan API AI berjalan pada infrastruktur bersama di mana permintaan anda beratur bersama permintaan pelanggan lain. Endpoint khusus menempah kapasiti untuk anda, menjamin latency dan ketersediaan tetapi pada kos yang lebih tinggi. Untuk aplikasi pengeluaran yang sensitif terhadap latency, kos endpoint khusus sering kali adalah wajar.

Tradeoff latency berbanding kos. Perkakasan yang lebih pantas dan lebih tinggi peringkatnya memerlukan kos lebih tinggi. Mengumpulkan permintaan bersama (menunggu beberapa terkumpul sebelum memprosesnya bersama) meningkatkan penggunaan perkakasan dan mengurangkan kos tetapi menambah latency. Tradeoff yang betul bergantung pada kepekaan kes penggunaan anda terhadap masa respons.

Konfigurasi penskalaan. Berapa bilangan minimum tika model yang perlu dikekalkan dalam keadaan berjalan (sifar bermakna kelewatan cold start apabila trafik disambung semula; bukan sifar bermakna sentiasa membayar untuk kapasiti melahu)? Berapa maksimumnya? Seberapa agresif autoscaler perlu menambah kapasiti?

Keputusan ini mempunyai implikasi kos langsung. Penggunaan serving yang terlalu diperuntukkan boleh membazirkan puluhan ribu dolar sebulan. Yang kurang diperuntukkan merendahkan pengalaman pengguna semasa puncak.

Model Serving untuk Large Language Models

Large language model memperkenalkan cabaran serving yang tidak dimiliki model yang lebih kecil, terutamanya kerana saiznya.

Model kelas GPT-4 memerlukan puluhan atau ratusan gigabait memori GPU hanya untuk dimuatkan. Kebanyakan penggunaan LLM dalam pengeluaran memerlukan serving multi-GPU, di mana model dibahagikan merentasi berbilang GPU. Ini dipanggil tensor parallelism atau pipeline parallelism, dan framework serving mesti mengatur semuanya.

Pengurusan cache key-value (KV) adalah kebimbangan operasi utama untuk LLM serving. Apabila menjana respons token demi token, model menyimpan cache pengiraan perantara daripada token sebelumnya (cache KV) untuk mengelakkan pengiraannya semula. Cache ini berada dalam memori GPU dan membesar dengan panjang konteks. Sistem serving mesti mengurus memori ini dengan teliti merentasi permintaan serentak.

Continuous batching adalah pengoptimuman khusus LLM di mana sistem serving mengumpulkan permintaan masuk baharu dengan permintaan yang sudah dalam pertengahan penjanaan, mengekalkan penggunaan GPU yang tinggi dan bukannya menunggu sehingga kumpulan selesai sebelum memulakan yang baharu. Sistem seperti vLLM mempelopori pendekatan ini.

Untuk penggunaan Edge AI, model serving pada perkakasan terhad (komputer riba, telefon, peranti terbenam) memerlukan pengoptimuman tambahan: saiz model yang lebih kecil, inference ketepatan lebih rendah dan framework serving yang direka untuk persekitaran CPU atau GPU mudah alih dan bukannya GPU pusat data.

Tanda-Tanda bahawa Masalah Serving Memberi Kesan kepada Nilai Perniagaan

Masalah model serving tidak selalu mengumumkan dirinya sebagai kegagalan infrastruktur. Lebih kerap, ia muncul sebagai:

• Pengguna melaporkan AI "terasa perlahan" tanpa amaran teknikal yang jelas
• Penggunaan jatuh selepas lonjakan pelancaran awal, tanpa masalah kualiti yang jelas
• Kos tumbuh secara tidak seimbang dengan penggunaan
• Masa respons yang tidak konsisten (kadang pantas, kadang perlahan) yang membuatkan ciri kelihatan tidak boleh dipercayai
• Kadar ralat melonjak di bawah beban walaupun model berfungsi dengan baik dalam keadaan biasa

Jika anda melihat gejala-gejala ini, masalahnya biasanya bukan model itu sendiri. Ia adalah lapisan serving.

Fakta Utama

• Model serving adalah infrastruktur yang menjadikan model AI yang dilatih tersedia sebagai perkhidmatan pengeluaran, berbeza daripada inference (pengiraan) dan MLOps (amalan operasi yang lebih luas).
• Sistem serving dalam pengeluaran merangkumi model registry, serving runtime, API gateway, autoscaler dan monitoring.
• Keputusan perniagaan utama: diurus berbanding dihoskan sendiri, endpoint dikongsi berbanding khusus, tradeoff latency berbanding kos, konfigurasi penskalaan.
• Large language model memperkenalkan cabaran serving khusus: pengurusan memori multi-GPU, cache KV dan continuous batching.
• Kebanyakan masalah serving muncul sebagai kemerosotan pengalaman pengguna (kelambatan, ketidakkonsistenan) dan bukannya kegagalan keras.