Bagian 4: Optimasi dan Deployment

Bagian terakhir proyek ini menjawab dua pertanyaan penutup setiap deployment: bisakah model dibungkus tanpa PyTorch, dan lebih cepatkah ia berjalan setelah dibungkus. Skrip src/optimasi.py men-export model ke format ONNX — standar pertukaran model lintas runtime yang dibahas pada chapter ONNX dan Model Export — lalu memverifikasi bahwa keluaran onnxruntime identik dengan PyTorch dan mengukur latensi keduanya.

Export dengan Batch Dinamis #

Fungsi ekspor menyerahkan satu contoh masukan kepada torch.onnx.export:

def ekspor_onnx(model) -> Path:
    contoh = torch.zeros(1, 64, dtype=torch.float32)
    torch.onnx.export(
        model,
        (contoh,),
        str(JALUR_ONNX),
        input_names=["fitur"],
        output_names=["logits"],
        dynamic_shapes={"input": {0: "jumlah_sampel"}},
        verbose=False,
    )
    return JALUR_ONNX

Tiga argumen menentukan mutu hasil. input_names dan output_names memberi nama pada tensor sehingga sesi onnxruntime bisa memanggil run dengan kunci "fitur" alih-alih indeks. dynamic_shapes={"input": {0: "jumlah_sampel"}} menandai dimensi pertama sebagai dinamis, jadi berkas yang diekspor dari contoh batch 1 tetap sah untuk batch 64 maupun 450 — keluwahan yang dibutuhkan endpoint serving dengan beban berubah-ubah, sebagaimana dibahas pada chapter Batch Inference . Contoh masukan torch.zeros(1, 64) hanya menjadi acuan bentuk, bukan data sungguhan.

Verifikasi dan Pengukuran #

Skrip utama membandingkan kedua runtime pada seluruh 450 sampel validasi, lalu mengukur latensi batch 64 dengan metodologi warm-up 5 kali diikuti median 30 pengulangan — protokol pengukuran yang dibahas pada chapter Optimasi Latensi :

python3 src/optimasi.py

Output yang Dihasilkan:

== 1. export ONNX ==
berkas       : /tmp/dl_deploy_demo/model.onnx
ukuran .pt   : 13757 byte
ukuran .onnx : 6970 byte

== 2. perbandingan keluaran torch vs onnxruntime ==
sampel dibandingkan : 450
selisih maksimum    : 0.00e+00
kelas sama          : 1.0000

== 3. latensi batch 64 (median 30x, warm-up 5x) ==
torch         : 0.033 ms
onnxruntime   : 0.016 ms
rasio ort/torch : 0.47
catatan: angka waktu berubah-ubah antar eksekusi; bandingkan
pola relatifnya, bukan angka absolutnya.

Catatan proses export: torch.onnx.export versi PyTorch 2.14 bisa mencetak peringatan bahwa operator opsional torchvision (misalnya torchvision::nms) dilewati karena torchvision tidak terpasang di lingkungan ini — peringatan tersebut tidak memengaruhi MLP kita sama sekali karena arsitektur ini tidak memakai operator bersangkutan.

Membaca Hasil Optimasi #

Tiga temuan perlu dilafalkan apa adanya. Berkas ONNX mengecil hampir separuh karena format ini hanya menyimpan graf komputasi dan bobot, tanpa struktur checkpoint PyTorch. Keluaran kedua runtime identik sampai selisih 0.00e+00 dan seluruh 450 prediksi kelas sama — akurasi validasi 0.9511 dari Bagian 1 terjaga penuh, juga diverifikasi oleh python3 tests/test_onnx.py. Latensi onnxruntime untuk batch 64 tercatat berkisar dari sepertiga hingga setengah waktu PyTorch pada eksekusi kami (rasio 0.31-0.47); angka absolutnya memang berubah antar eksekusi dan antar mesin, dan yang stabil untuk dilaporkan adalah pola relatifnya, sebagaimana dicetak skripnya sendiri.

Pengujian otomatis python3 tests/test_onnx.py merangkum keempat jaminan export dalam empat pemeriksaan: berkas ONNX benar-benar tertulis, selisih logits terhadap PyTorch di bawah 1e-4 dengan seluruh kelas sama pada 450 sampel, dimensi batch dinamis bekerja untuk 1, 8, dan 64 sampel, dan akurasi onnxruntime pada validasi tetap 0.9511 — persis angka Bagian 1. Manfaat praktisnya juga melebihi angka: server yang memakai onnxruntime tidak perlu memasang PyTorch sama sekali, cukup pustaka runtime yang jauh lebih ramping, sehingga citra deployment (container, edge device) bisa mengecil drastis — alur lengkapnya dibahas pada chapter Inference pada CPU .

Dengan export ONNX tervalidasi, proyek ini menuntaskan perjalanan sembilan proyek Course: dari MLP digit dan CNN gambar pada awal section, melalui NLP, deret waktu, transfer learning, LoRA, hingga deteksi objek — semuanya bermuara di sini, model yang hidup sebagai layanan. Langkah lanjutannya berada di section Production dan Operasional : versioning model, pipeline reproducible, canary release, dan pemantauan drift yang menjaga layanan tetap sehat berbulan-bulan setelah rilis.