View a markdown version of this page

Inferensi dan Orkestrasi CPU - Amazon EKS
IkhtisarMengapa CPU untuk Beban Kerja AI?CPU vs GPU/Trainium: Kapan Memilih Masing-masingKerangka Keputusan Beban KerjaPola ProduksiPraktik Terbaik OptimasiMengevaluasi Kualitas Model untuk Beban Kerja CPU-FirstReferensi

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Inferensi dan Orkestrasi CPU

Ikhtisar

Instans CPU adalah opsi komputasi kelas satu untuk berbagai beban kerja AI di Amazon EKS. Dari model bahasa kecil (SLM) dan inferensi ML klasik hingga pipeline data dan orkestrasi agen, CPU menawarkan kinerja harga yang kuat, ketersediaan kapasitas yang luas, dan semantik penjadwalan Kubernetes yang sudah dikenal.

CPU dan GPU saling melengkapi, tidak kompetitif. Ketika pipeline AI agentic tumbuh dalam kompleksitas, permukaan beban kerja CPU tumbuh bersamanya: setiap panggilan inferensi dikelilingi oleh eksekusi alat, rakitan konteks, pencarian vektor, pagar pembatas, dan logika orkestrasi yang semuanya berjalan pada CPU. Kami merekomendasikan merancang arsitektur yang menggunakan kedua jenis komputasi dengan sengaja, menempatkan setiap beban kerja pada tingkat di mana ia memberikan kinerja biaya terbaik.

Tidak semua beban kerja membutuhkan GPU. Perutean, klasifikasi, pengambilan, penyematan, orkestrasi, dan semakin banyak inferensi model bahasa semuanya berjalan secara efektif pada CPU. Current-generation Instans CPU di arm64 dan x86 memberikan kinerja harga yang kuat untuk inferensi ML. Dikombinasikan dengan konsolidasi node Karpenter, penskalaan berbasis peristiwa KEDA, dan penyajian model terkuantisasi, ini menyediakan tumpukan siap produksi yang dapat dioperasikan oleh tim platform tanpa keahlian GPU yang mendalam.

Panduan ini untuk:

  • Insinyur platform merancang cluster EKS multi-penyewa untuk beban kerja AI.

  • Praktisi ML mengevaluasi backend inferensi untuk model di bawah parameter 30B.

  • FinOps tim yang mencari tuas biaya beton tanpa mengorbankan SLO.

Apa yang akan Anda pelajari:

  • Beban kerja AI mana yang termasuk dalam CPU dan di mana GPU atau Trainium diperlukan.

  • Bagaimana menerapkan kerangka keputusan empat dimensi untuk setiap beban kerja baru.

  • Dua pola produksi: pra-penyaringan SLM agen dan pertanian model kepadatan tinggi.

  • Praktik terbaik pengoptimalan: kuantisasi, pengepakan tempat sampah, penjadwalan Spot, dan penskalaan otomatis.

Awas

Setiap rekomendasi dalam panduan ini harus divalidasi secara empiris. Keluarga instans yang tepat (arm64, x86, GPU, atau Trainium) bergantung pada model, data, dan anggaran latensi Anda. Gunakan panduan ini sebagai titik awal yang terinformasi, lalu patokan sebelum melakukan.

Mengapa CPU untuk Beban Kerja AI?

Pipa AI produksi mendistribusikan pekerjaan di banyak tingkatan komputasi. CPU menangani routing, klasifikasi, pengambilan, orkestrasi, dan semakin banyak inferensi. Current-generation Instans CPU memberikan kinerja harga yang kuat dan penjadwalan Kubernetes yang familiar, menjadikannya pilihan praktis untuk banyak beban kerja AI.

Tiga faktor membuat CPU menarik untuk beban kerja ini:

Ketersediaan kapasitas

Instans GPU sering memerlukan reservasi kapasitas beberapa minggu sebelumnya. Instans CPU tersedia secara luas di semua wilayah AWS tanpa plugin perangkat khusus, tanpa konfigurasi DRA, dan tidak ada partisi MIG. Ketika Anda perlu menskalakan dengan cepat, kapasitas CPU adalah pilihan yang paling tersedia.

Ekonomi

Current-generation Instans CPU memberikan kinerja harga yang kuat untuk inferensi ML. Untuk tim yang menjalankan FinOps ulasan atau mengelola cluster multi-tenant, perbedaan biaya antara CPU dan GPU sangat signifikan, terutama untuk SLM terkuantisasi di mana akselerasi GPU memberikan pengembalian yang semakin berkurang. Kami merekomendasikan benchmarking di seluruh rangkaian instans yang tersedia (Graviton, AMD, Intel) untuk menemukan biaya per token terbaik untuk beban kerja Anda.

Kesederhanaan operasional

Pod CPU menggunakan penjadwalan Kubernetes standar (requests,, afinitas nodelimits, penyebaran topologi). Tidak ada plugin perangkat, tidak ada penjadwal khusus, tidak ada nvidia.com/gpu jenis sumber daya. Tim yang ingin menjalankan beban kerja AI tanpa keahlian GPU yang mendalam dapat mencapai produksi lebih cepat di CPU.

Menumbuhkan permukaan CPU di saluran pipa agen

Dalam pipeline AI agen, setiap panggilan inferensi GPU dikelilingi oleh pekerjaan CPU: eksekusi alat, perakitan konteks, pencarian vektor, pencarian penyematan, pagar pembatas, validasi respons, manajemen memori, dan logika orkestrasi. Ketika agen tumbuh lebih kompleks (lebih banyak alat, rantai yang lebih panjang, penalaran multi-langkah), beban kerja CPU ini tumbuh sangat linier. Protokol seperti MCP (Model Context Protocol) memperkuat ini lebih lanjut: setiap panggilan alat MCP memicu pengambilan data, transformasi, dan pemformatan yang berjalan sepenuhnya pada CPU.

CPU vs GPU/Trainium: Kapan Memilih Masing-masing

Faktor Pilih CPU Pilih GPU/Trainium

Ukuran Model

SLM 1-8B (terkuantisasi); penyematan; pengklasifikasi

8B+untuk inferensi online latensi rendah; 70B+secara umum

Latensi SLO

p95 100-500ms dapat diterima

p95 <50 ms diperlukan

Bersamaan

< 100 req/s per titik akhir

> 100 req/s berkelanjutan

Jenis Beban Kerja

Orkestrasi, pengambilan, ETL, penilaian batch

Inferensi online, fine-tuning, pelatihan

Kapasitas

Ketersediaan segera, tidak ada reservasi

Seringkali membutuhkan kapasitas cadangan

Sensitivitas Biaya

CPU memberikan $/token terbaik untuk beban kerja yang memenuhi syarat

GPU diamortisasi pada pemanfaatan tinggi

Keahlian Tim

Operasi Kubernetes Standar

Membutuhkan pengetahuan operasi GPU

Kedaulatan Data

Inferensi SLM di VPC; jejak audit penuh; data tidak pernah meninggalkan akun Anda

Sama jika dikelola sendiri; tidak tersedia dengan API eksternal
Tip

Ambang batas ini adalah titik awal. Sebaiknya jalankan mesin inferensi target Anda pada keluarga instance kandidat (arm64 dan x86) dengan model dan pola lalu lintas Anda yang sebenarnya sebelum melakukan ke tingkat komputasi.

Kerangka Keputusan Beban Kerja

Memilih komputasi yang tepat untuk beban kerja AI bermuara pada empat dimensi:

  1. Ukuran dan presisi model: Apakah kuantisasi menjaga kualitas dalam kisaran yang dapat Anda terima?

  2. SLO latensi dan throughput: Apa p50/p95 target dan tingkat permintaan puncak Anda?

  3. Jenis beban kerja: Inferensi online, penilaian batch, pengambilan, atau orkestrasi?

  4. Kendala biaya dan kapasitas: FinOps anggaran, ketersediaan daerah, strategi reservasi?

Gunakan tabel di bawah ini sebagai matriks keputusan.

Beban kerja CPU GPU/Train Catatan

SLM (parameter 1-8B, terkuantisasi)

Pilihan default. Kinerja harga yang kuat pada latensi 100-500 ms, QPS sedang. Benchmark di seluruh keluarga instance.

Ketika p95 <50ms or concurrency >100 req/s.

Kuantisasi Q4_K_M atau Q8_0 direkomendasikan

Model sedang (parameter 8-30B)

Batch, async, penilaian offline. Uji kuantisasi Q4.

Inferensi online, konteks panjang, latensi ketat.

Benchmark Q4 di seluruh keluarga instans

LLM besar (70B+parameter)

Non-real-time hanya, kuantisasi berat

Default untuk inferensi online produksi

Bahkan 70B dapat berjalan pada CPU; mengharapkan latensi tinggi

Klasik ML/Embeddings/CV

High-density melayani; bin-pack di seluruh node.

Penglihatan berat atau multi-modal dalam skala.

TorchServe, Triton pada CPU menangani ribuan model.

Pipa data/ETL/Data sintetis

Ray dan Spark pada CPU untuk persiapan data dan rekayasa fitur.

N/A

CPU menjangkar seluruh tahap persiapan data ini

Orkestrasi agen/pengambilan RAG

Network-bound layanan: gateway API, lapisan proxy, retriever, chunker.

N/A

Manfaat dari instance CPU bandwidth tinggi.

Fine-tuning /Pelatihan

Persiapan data dan orkestrasi pipa.

Pelatihan model dan distilasi.

Hibrida: Persiapan CPU, kereta GPU, kesimpulan CPU.

Compliance-sensitive inferensi (FSI, perawatan kesehatan, pemerintah)

SLM di VPC pada CPU. Data tetap dalam akun, jejak audit penuh.

Sama jika dikelola sendiri di GPU.

CPU menang pada biaya untuk model sub-8B di lingkungan yang diatur.
Awas

Meskipun secara teknis dimungkinkan untuk menjalankan model 70B+pada CPU dengan kuantisasi berat (Q4 atau lebih rendah), ini hanya layak untuk beban kerja non-real-time, offline, atau batch. Harapkan tingkat pembuatan token dalam satu digit rendah (1-5 tokens/sec), persyaratan memori melebihi 40GB bahkan pada Q4, dan latensi diukur dalam menit per respons untuk output yang lebih lama. Untuk kasus penggunaan interaktif atau sensitif latensi, model 70B+termasuk dalam GPU atau Trainium.

Alur Kerja Benchmark Cepat

Sebelum berkomitmen ke keluarga instans, sebaiknya jalankan benchmark terstruktur yang membandingkan keluarga CPU kandidat Anda (arm64 dan x86) dengan GPU pada satu metrik yang sebanding: kueri biaya per 1.000 pada latensi p95 target Anda. Terapkan satu node per keluarga dengan konfigurasi model yang identik (kuantisasi yang sama, ukuran konteks, jumlah utas), masing-masing uji beban, dan bandingkan. Jika instance CPU memenuhi SLO p95 Anda, kemungkinan besar akan menang berdasarkan biaya. Jika meleset dengan selisih kecil, cobalah generasi terbaru dalam keluarga itu sebelum pindah ke GPU. Jika latensi masih terlalu tinggi pada target konkurensi Anda, itu adalah sinyal untuk memindahkan beban kerja ke GPU.

Pola Produksi

Pola 1: Agentic AI - SLM Pre-Filter pada CPU dengan Eskalasi LLM

Sebagian besar alur kerja agen mengeksekusi pola sempit yang sama berulang kali: mengklasifikasikan permintaan, memilih alat, mengekstrak data terstruktur, memvalidasi respons. Tugas-tugas ini tidak memerlukan model parameter 70B.

Penelitian tentang SLM (ar Xiv:2506.02153) menunjukkan bahwa model di bawah parameter 10B, ketika dikhususkan untuk domain, dapat mencocokkan atau melampaui LLM besar pada sub-tugas terbatas sambil berjalan secara efisien pada CPU dengan biaya dan latensi yang jauh lebih rendah. Ketika sebuah model disetel dengan baik untuk domain tertentu, footprint yang lebih kecil dapat membuatnya lebih akurat dan lebih murah daripada menggunakan LLM tujuan umum.

Dalam pola ini, SLM pada CPU menangani sebagian besar permintaan end-to-end. Lapisan perutean (juga berjalan pada CPU) hanya meningkatkan kasus yang benar-benar kompleks ke LLM. GPU-hosted

Komponen yang berjalan pada CPU:

Komponen pada GPU/Trainium:

  • LLM besar untuk sintesis kompleks, penalaran konteks panjang

Mengapa pola ini berfungsi: Dalam banyak alur kerja agen, 60-80% permintaan dapat diklasifikasikan atau diekstraksi oleh SLM. Untuk setiap panggilan LLM yang Anda hindari, Anda juga menghindari pekerjaan CPU di sekitarnya untuk merakit jendela konteks besar, menjalankan pagar pembatas pada respons yang panjang, dan mengelola keadaan kompleks. Skala tingkat CPU secara independen dari tingkat GPU.

Kategori beban kerja CPU dalam saluran agen tipikal meliputi: eksekusi alat (panggilan server MCP, panggilan API, kueri basis data), perakitan konteks, pencarian vektor dan pencarian penyematan, logika orkestrasi dan perencanaan, pagar pembatas dan penyaringan keselamatan, validasi respons dan pemformatan, memori agen dan manajemen status, dan. logging/observability

Pola ini juga sesuai dengan siklus hidup fine-tuning: mengumpulkan data domain pada node CPU, menyempurnakan GPU, lalu menerapkan model terkuantisasi kembali ke CPU untuk inferensi dengan biaya yang jauh lebih rendah daripada titik akhir LLM. Penelitian dari LoRa Land (ar Xiv:2405.00732) menunjukkan bahwa model 7B yang disetel dengan baik mengungguli GPT-4 sebagian besar tugas khusus domain yang diuji, membuat jalur “menyempurnakan model kecil dan menjalankannya di CPU” layak untuk banyak kasus penggunaan produksi.

Pola 2: Pertanian Model High-Density CPU

Pipa produksi ML secara rutin menggunakan ratusan atau ribuan model yang lebih kecil: penyematan, pemberi rekomendasi, pengklasifikasi, pencetak gol, dan model visi komputer. BERT-based Secara individual ringan, model ini menjadi mahal ketika masing-masing diberi sumber daya GPU sendiri.

Kami merekomendasikan penyajian CPU densitas tinggi (bin-packing beberapa model per node menggunakan TorchServe atau Triton pada CPU), dengan Karpenter mengelola siklus hidup node dan penskalaan KEDA pada beban yang diamati.

Pola ini meluas secara alami ke arsitektur RAG: pembuatan embedding, chunking dokumen, dan pengambilan dari OpenSearch semua run hemat biaya pada node CPU, memasukkan hasil ke LLM hanya untuk langkah generasi terakhir. GPU-hosted CPU farm menangani volume; GPU menangani kompleksitas.

Untuk industri yang diatur (layanan keuangan, perawatan kesehatan, pemerintah), pola ini sangat menarik: ratusan model khusus yang menjalankan in-VPC pada CPU, dengan jejak audit penuh dan data yang tidak pernah keluar dari akun. Persyaratan kepatuhan untuk inferensi yang dikelola sendiri sejalan secara alami dengan keunggulan biaya CPU untuk model sub-8B.

Praktik Terbaik Optimasi

Kuantisasi

Menjalankan model 7B pada BF16 penuh pada CPU tidak praktis; menjalankannya pada kuantisasi Q4 layak dan hemat biaya. Memahami mengapa kuantisasi membantu CPU adalah kunci untuk membuat keputusan infrastruktur yang baik.

Mengapa kuantisasi penting untuk inferensi CPU. Inferensi CPU terikat dengan bandwidth memori, bukan terikat komputasi. Selama fase decode (menghasilkan token satu per satu), seluruh bobot model dibaca dari RAM untuk setiap token yang dihasilkan. CPU menghabiskan sebagian besar waktunya menunggu data datang dari memori, tidak melakukan matematika. Model 7B di BF16 kira-kira 14GB; pada Q4_K_M, menyusut menjadi sekitar 4GB. Karena bottleneck memindahkan byte dari RAM ke inti CPU, model yang 3,5x lebih kecil membaca 3,5x lebih cepat, yang diterjemahkan hampir langsung ke generasi token 3,5x lebih cepat. Inilah sebabnya mengapa kuantisasi adalah pengoptimalan tunggal yang paling berdampak untuk inferensi CPU, dan mengapa generasi CPU yang lebih baru dengan lebih banyak saluran memori menghasilkan inferensi yang lebih cepat bahkan pada kecepatan clock yang sama.

Sebaiknya buat mesin inferensi Anda dengan backend yang dioptimalkan untuk arsitektur (ARM NEON/SVE2 untuk arm64, AVX-512/AMX untuk x86), menyetel jumlah utas sama dengan jumlah vCPU, dan memilih format kuantisasi Q4_K_M atau Q8_0.

Kuantisasi Dampak Kualitas Throughput vs BF16 Kasus Penggunaan

Q4_K_M

Rendah (1-3% delta kebingungan, tergantung model)

~ 4-5x lebih cepat

Default produksi untuk SLM

Q8_0

Dapat diabaikan

~ 2x lebih cepat

Quality-sensitive tugas

Q5_K_M

Sangat rendah

~ 3.5x lebih cepat

Keseimbangan kualitas dan kecepatan

BF16

Tidak ada

1x (garis dasar)

Hindari pada CPU untuk model 7B +

Untuk model sub-2B, CPU menang pada kinerja harga vs GPU. Model-model ini cukup kecil sehingga akselerasi GPU memberikan manfaat minimal sementara biaya per jam secara signifikan lebih tinggi. Jika beban kerja Anda dapat menggunakan model sub-2B, CPU adalah default yang disarankan.

Architecture-specific pengoptimalan: Pada arm64, instance Graviton generasi saat ini mendukung SVE2. Bangun mesin inferensi Anda dengan -march bendera yang sesuai untuk target Anda. Pada x86, instans AMD EPYC mendukung AVX-512, dan instans Intel Xeon menambahkan AMX untuk akselerasi matriks. Karena inferensi terikat dengan bandwidth memori, generasi CPU yang lebih baru dengan lebih banyak saluran memori DDR5 menghasilkan inferensi yang lebih cepat bahkan pada kecepatan clock yang sama. Saat memilih jenis instance, prioritaskan bandwidth memori di atas jumlah inti.

Ukuran jendela konteks: Untuk klasifikasi dan beban kerja perutean, input biasanya di bawah 200 token dan outputnya 2-3 token. Menyetel jendela konteks kecil (misalnya, 512 token) alih-alih 2048 default mengurangi penggunaan memori cache KV dan meningkatkan latensi per permintaan. Hanya tingkatkan jendela konteks jika input Anda benar-benar panjang.

Perhatian Flash: Aktifkan Perhatian Flash jika mesin inferensi Anda mendukungnya. Flash Attention mengurangi penggunaan memori untuk perhitungan perhatian dengan menghindari materialisasi matriks perhatian penuh. Pada CPU, manfaatnya lebih kecil daripada pada GPU, tetapi masih membantu untuk input yang lebih lama.

Tip

Degradasi kualitas Q4_K_M bervariasi menurut model dan tugas. Selalu evaluasi pada dataset Anda sendiri sebelum menerapkan ke produksi.

Bin-packing untuk penyajian padat

Untuk model mL dan penyematan klasik (masing-masing biasanya <500MB), tujuannya adalah kepadatan pod maksimum per node pada latensi ekor yang stabil. Dua hal menentukan apakah Anda mencapainya: permintaan sumber daya yang akurat, dan threading terkontrol.

Dasarkan Anda requests pada penggunaan p50-p90 yang diamati di bawah beban realistis. Gunakan Goldilocks, rekomendasi VPA, atau histogram Prometheus dari uji beban. Default hampir selalu salah di kedua arah.

Pustaka ML (PyTorch, ONNX Runtime, MKL, OpenBLAS) menelurkan thread sebanyak mungkin karena mereka dapat melihat VCPU pada node, bukan CPU yang dialokasikan ke pod. Pada node padat dengan 20 pod, setiap pod mencoba menelurkan 32 utas. Node meronta-ronta pada peralihan konteks dan lonjakan latensi p99. Perbaiki ini secara eksplisit:

env:
  - name: OMP_NUM_THREADS
    value: "2"          # match your cpu request (2000m = 2 threads)
  - name: MKL_NUM_THREADS
    value: "2"
  - name: OPENBLAS_NUM_THREADS
    value: "2"
  - name: INTRA_OP_NUM_THREADS    # PyTorch / ONNX Runtime
    value: "2"
  - name: NUM_INTER_THREADS
    value: "1"          # keep inter-op parallelism minimal

Tetapkan setiap nilai sama dengan atau di bawah permintaan CPU Anda. Untuk pod dengan 4+ core, benchmark mulai dari 2-4 thread. Banyak model kecil berkinerja lebih baik dengan thread yang lebih sedikit karena efisiensi cache. Jika Anda menggunakan HPA dengan banyak pod tipis, 1-2 utas per pod hampir selalu menang.

Penjadwalan dan optimalisasi biaya

Dua praktik digabungkan untuk mengurangi biaya inferensi CPU secara signifikan: Instans spot dengan konsolidasi Karpenter, dan gambar kontainer multi-lengkungan.

Konsolidasi Karpenter bekerja dengan baik untuk inferensi CPU karena pod inferensi stateless di belakang antrian atau penyeimbang beban mentolerir interupsi dengan anggun. Konfigurasikan konsolidasi untuk bertindak pada node yang kurang dimanfaatkan dengan anggaran yang membatasi gangguan bersamaan (misalnya, 20% node sekaligus) untuk menghindari penurunan kapasitas selama penurunan skala. nodePoolSpesifikasi Karpenter memungkinkan Anda mencampur Spot dan On-Demand kapasitas dalam satu kumpulan, dengan Spot sebagai opsi pilihan dan On-Demand sebagai fallback.

Membangun gambar multi-lengkungan (arm64danamd64) membuka ini lebih lanjut. Dengan kedua arsitektur yang tersedia, Karpenter dapat memilih dari rangkaian lengkap keluarga instans (Graviton, AMD, Intel) berdasarkan harga dan ketersediaan waktu nyata. Ini sangat berharga untuk beban kerja Spot di mana diversifikasi di seluruh jenis dan arsitektur instans mengurangi frekuensi interupsi. Gunakan docker buildx atau pipeline CI dengan build multi-platform untuk menghasilkan manifes tunggal yang mencakup kedua arsitektur.

Optimalisasi startup kontainer

Saat Karpenter menyediakan node baru (scaling up, Spot replacement), runtime container perlu menarik image inferensi sebelum pod dapat dimulai. Untuk gambar inferensi multi-GB, ini dapat menambahkan 30-60 detik ke startup pod.

Sebaiknya gunakan Bottlerocket sebagai OS node untuk beban kerja inferensi, dikombinasikan dengan snapshotter SOCI dalam mode paralel. pull/unpack SOCI menggantikan ekstraksi lapisan sekuensial default dengan unduhan berbasis potongan paralel, secara signifikan mengurangi waktu tarik gambar untuk gambar besar. Tidak diperlukan perubahan pada gambar kontainer Anda.

Untuk panduan konfigurasi terperinci, lihat bagian Kinerja dari panduan ini, yang mencakup konfigurasi SOCI, pra-penarikan snapshot EBS, dan strategi cache runtime container.

Observabilitas

Tanpa observabilitas pada lapisan model, Anda menskalakan secara membabi buta. Kami merekomendasikan untuk mengekspos metrik Prometheus untuk setiap layanan inferensi dan menggunakannya untuk mendorong penskalaan KEDA dan dasbor operasional.

Sebagian besar server inferensi (llama.cpp, VllM, Triton, TorchServe) mengekspos Prometheus-compatible metrik pada titik akhir. /metrics Nama metrik bervariasi menurut server, tetapi konsepnya sama.

Metrik kunci untuk instrumen:

Kategori Metrik Deskripsi Ambang Peringatan

Pemrosesan permintaan/dalam penerbangan

Jumlah permintaan yang saat ini ditangani oleh server.

Gunakan untuk penskalaan (lihat bagian penskalaan otomatis di bawah)

Permintaan antri/ditangguhkan

Jumlah permintaan menunggu slot pemrosesan.

Pemicu skala. Setiap antrian berkelanjutan berarti latensi akan menurun.

Throughput token

Token yang dihasilkan per detik.

Waspada jika throughput turun di bawah 50% dari baseline di bawah beban

Minta latensi

End-to-end histogram latensi (pemrosesan cepat+pembuatan token).

Peringatan pada p95 melebihi SLO Anda

Pemanfaatan cache KV

Seberapa penuh cache nilai kunci (0,0 hingga 1,0). Mendekati 1.0 berarti server akan mulai menolak atau mengantri permintaan.

Peringatan pada 85% +

Memori kontainer

Memori RSS per pod (container_memory_working_set_bytes).

Peringatan pada 85% dari batas

Penskalaan otomatis: skala pada kedalaman antrian, bukan pemanfaatan CPU

Pemanfaatan CPU adalah metrik saturasi. Ini melonjak setelah latensi telah terdegradasi. Pada saat autoscaling berbasis pemanfaatan bereaksi, pengguna sudah menunggu.

Kedalaman antrian (permintaan deferred/waiting) adalah indikator utama. Ini naik sebelum latensi menurun, karena permintaan mulai mengantri ketika semua slot pemrosesan sibuk. Penskalaan pada kedalaman antrian berarti replika baru disediakan sementara replika yang sudah ada masih merespons secara normal.

KEDA mendukung penggabungan beberapa metrik ke dalam rumus penskalaan tunggal menggunakan scalingModifiers (membutuhkan KEDA 2.12+). Pola yang direkomendasikan untuk beban kerja inferensi adalah menggabungkan permintaan dalam penerbangan dengan permintaan antrian, yang sangat membobot metrik antrian:

advanced:
  scalingModifiers:
    formula: "running + (waiting * 10)"
    target: "25"
    activationTarget: "5"

Rumusnya running + (waiting * 10) berarti bahkan 3 permintaan antrian mendorong metrik gabungan ke 55, jauh di atas target 25. Penskalaan dimulai sebelum latensi menurun. The activationTarget of 5 mencegah noise memicu peristiwa skala-dari-nol yang tidak perlu.

Mengevaluasi Kualitas Model untuk Beban Kerja CPU-First

Menyebarkan SLM terkuantisasi pada CPU adalah keputusan biaya dan latensi. Masuk akal jika model masih menghasilkan output yang benar dan berguna untuk beban kerja Anda.

Model yang lebih kecil atau kuantisasi memotong biaya komputasi tetapi dapat mengurangi kualitas. Dampaknya bervariasi. Beban kerja yang bekerja dengan baik pada CPU (klasifikasi, ekstraksi, perutean, ringkasan, penyematan) sering mempertahankan kualitas yang baik dalam B-7B kisaran 3 dengan kuantisasi dan dorongan yang tepat.

Apa yang harus dievaluasi

Beban kerja yang berbeda menurun dengan cara yang berbeda:

Beban kerja Apa yang bisa terdegradasi Apa yang harus diukur

Klasifikasi maksud atau tiket

Kesalahan pada input ambigu

Akurasi, F1 per kelas

Ekstraksi terstruktur (JSON)

Bidang hilang atau skema yang salah

Pencocokan yang tepat, validitas skema

RAG menjawab

Halusinasi atau mengabaikan konteks

Kesetiaan, relevansi jawaban

Ringkasan

Fakta yang hilang atau cakupan yang buruk

ROUGE-L, BertScore, ulasan manusia

Perutean agen

Memilih alat yang salah

Akurasi alat

Embeddings

Kualitas pengambilan yang lebih buruk

Ingat @K, NDCG

Alur kerja evaluasi praktis

Sebaiknya buat pemeriksaan kualitas sebelum produksi, mirip dengan cara Anda menjalankan uji beban sebelum memilih jenis instans. Alur kerja memiliki empat tahap:

  1. Build Eval Dataset — Buat dataset evaluasi kecil (100-300 contoh berlabel) dari beban kerja Anda yang sebenarnya. Hindari tolok ukur generik seperti MMLU yang mengukur penalaran umum daripada tugas Anda yang sebenarnya.

  2. Menetapkan Baseline — Jalankan dataset terhadap model tepercaya (misalnya, LLM besar yang Anda tahu menghasilkan hasil yang benar).

  3. Uji Model CPU - Jalankan kumpulan data yang sama pada SLM terkuantisasi Anda dan bandingkan.

  4. Evaluasi — Tentukan ambang kualitas Anda sebelum pengujian, misalnya, “akurasi SLM dalam 5 poin persentase dari baseline.” Ambang batas yang tepat tergantung pada tugas: pengklasifikasi yang ditinjau oleh manusia dapat mentolerir lebih banyak kesalahan daripada sistem yang membuat keputusan otomatis.

Bagaimana memulihkan kualitas

Jika model berkinerja buruk, cobalah ini dalam urutan upaya:

  • Tambahkan beberapa contoh bidikan dalam prompt: Nol biaya, langsung. Termasuk 3-5 contoh berlabel dalam prompt sering menutup celah untuk tugas klasifikasi dan ekstraksi.

  • Gunakan format kuantisasi berkualitas lebih tinggi: Pindah dari Q4 ke Q8 sering mengembalikan banyak kualitas yang hilang, dengan biaya ~ 2x lebih banyak memori dan throughput yang lebih rendah.

  • Gunakan routing hybrid: Biarkan SLM menangani kasus sederhana dan mengirim input sulit ke model yang lebih besar. Ini adalah perubahan arsitektur tetapi membuat biaya CPU Anda tetap rendah untuk sebagian besar lalu lintas.

  • Fine-tune model di domain Anda: Opsi paling mahal, tetapi yang paling efektif. Penelitian dari LoRa Land (ar Xiv:2405.00732) menemukan bahwa model 7B yang disetel dengan baik mengungguli sebagian besar tugas khusus domain yang GPT-4 diuji.

Referensi