Model yang hanya hidup di notebook belum memberi nilai apa pun bagi pengguna akhir; nilai muncul ketika model bisa dipanggil dari aplikasi lain kapan pun. Proyek penutup section ini membawa model klasifikasi digit hasil pelatihan melalui alur deployment utuh: artefak produksi dipisah dari kode (bobot, konfigurasi, metrik), dibungkus menjadi REST API FastAPI dengan validasi input, diuji klien secara nyata, lalu dioptimasi lewat export ONNX yang memperkecil berkas model hingga separuh dan mempercepat inferensi. Struktur proyeknya pun bergeser: folder data/ digantikan config/ karena sumber kebenaran deployment adalah konfigurasi, bukan dataset.
Seluruh kode berjalan di CPU dengan benih tetap 42 dan dataset digits scikit-learn yang termuat di memori. Pelatihan 40 epoch selesai dalam hitungan detik, dan seluruh artefak ditulis ke /tmp/dl_deploy_demo agar bundle materi tetap bersih namun bisa dibangun ulang identik kapan pun.
Prasyarat #
Sebelum masuk ke pengerjaan, pastikan materi berikut sudah dikuasai:
- Menyimpan Model untuk Produksi — artefak apa saja yang perlu menyertai bobot model.
- REST API untuk Model
— desain endpoint
/healthdan/predict. - ONNX dan Model Export — alur export dan verifikasi kesetaraan keluaran.
- Penyimpanan dan Pemuatan Model
— pola
state_dictyang dipakai di sini.
Perilaku Akhir yang Dituju #
Program terdiri atas empat skrip di src/: latih_model.py melatih model lalu menulis tiga artefak, api.py membungkusnya menjadi aplikasi FastAPI, klien.py menguji endpoint lewat TestClient tanpa membuka port, dan optimasi.py men-export ONNX lalu membandingkan latensi. Setelah artefak siap, sesi uji berjalan sebagai berikut:
python3 src/latih_model.py
python3 src/klien.pyOutput yang Dihasilkan (keluaran klien.py; keluaran latih_model.py dan optimasi.py dibahas pada Bagian 1 dan Bagian 4):
== klien uji: request nyata ke /predict ==
sampel 1: label asli 0 -> 0 (digit_0) [benar], p=0.9985, keyakinan_cukup=True, versi=1.0.0
sampel 4: label asli 5 -> 5 (digit_5) [benar], p=0.9977, keyakinan_cukup=True, versi=1.0.0
sampel 7: label asli 9 -> 9 (digit_9) [benar], p=0.8458, keyakinan_cukup=False, versi=1.0.0
== klien uji: request tidak valid ==
63 nilai -> 422 Value error, fitur harus berisi tepat 64 angka
== klien uji: health check ==
/health -> 200 {'status': 'ok', 'nama_model': 'mlp-digit-mini', 'versi': '1.0.0', 'akurasi_validasi': 0.9511}API mengembalikan prediksi benar untuk tiga gambar uji, menolak input tidak sah dengan status 422, dan menyediakan health check untuk sistem pemantau. Model di baliknya mencapai akurasi validasi 0.9511 dengan hanya 2778 parameter; setelah dioptimasi, berkas ONNX mengecil dari 13757 byte menjadi 6970 byte dengan selisih keluaran nol terhadap PyTorch.
Struktur Berkas #
deployment-model-deep-learning/
├── _index.md
├── bagian/ # empat tahap pengerjaan
│ ├── menyiapkan-model/
│ ├── membuat-inference-api/
│ ├── menguji-api/
│ └── optimasi-dan-deployment/
├── config/
│ └── config.json # kontrak model: arsitektur, preprocessing, ambang
├── src/
│ ├── latih_model.py # pelatihan + penulisan artefak
│ ├── api.py # FastAPI: /health dan /predict
│ ├── klien.py # klien uji TestClient
│ └── optimasi.py # export ONNX + benchmark
└── tests/
├── test_api.py # uji endpoint dan validasi
└── test_onnx.py # uji kesetaraan ONNXSeluruh berkas pada src/, tests/, dan config/ dapat diunduh dari bagian Berkas Sumber di bawah halaman ini dan setiap bagian pengerjaan.
Tahapan Pengerjaan #
Proyek dikerjakan dalam empat bagian berurutan, dan setiap bagian menghasilkan kode yang benar-benar dapat dijalankan:
- Bagian 1 — Menyiapkan Model: melatih model lalu membaca tiga artefak produksi yang ditulisnya.
- Bagian 2 — Membuat Inference API: membangun endpoint FastAPI yang memuat model sekali saat server menyala.
- Bagian 3 — Menguji API: menjalankan request nyata dan tidak valid lewat TestClient.
- Bagian 4 — Optimasi dan Deployment: export ONNX, verifikasi kesetaraan, dan perbandingan latensi.
Mulailah dari Bagian 1 karena berkas config/config.json yang ditulisnya menjadi kontrak yang dipegang API maupun proses optimasi — satu sumber kebenaran untuk seluruh tahap berikutnya.
Latih model digit mini lalu tulis tiga artefak produksi: bobot, konfigurasi, dan metrik hasil evaluasi.
Buka → # Bagian 2: Membuat Inference APIBangun REST API FastAPI dengan endpoint /health dan /predict yang memuat model sekali saat server menyala.
Buka → # Bagian 3: Menguji APIJalankan request nyata dan tidak valid ke /predict lewat TestClient lalu baca respons health check secara menyeluruh.
Buka → # Bagian 4: Optimasi dan DeploymentExport model ke ONNX dengan batch dinamis, verifikasi kesetaraan keluaran, lalu bandingkan ukuran berkas dan latensi PyTorch vs onnxruntime.
Buka →