Peranan Baru CPU Dalam AI Untuk Kilang Pintar

CPU Bukan Lagi Pelakon Sampingan Dalam AI Kilang Pintar

Dalam banyak kilang elektronik dan automotif di Malaysia, purata jurutera proses masih menghabiskan 20–30 minit hanya untuk mencari satu nombor dalam spesifikasi: nilai tork skru, parameter reflow, atau had arus maksimum pada board tertentu. Dokumen berselerak di SharePoint, folder lama di NAS, atau email lama supplier.

Sekarang bayangkan ratusan keputusan seperti itu dibuat setiap hari di Bayan Lepas, Kulim atau Senai. Kelewatan 20 minit itu bertukar jadi jam downtime terselindung yang langsung tak nampak dalam OEE dashboard.

Di sinilah AI jenis Retrieval-Augmented Generation (RAG) mula menjadi menarik. Bukan chatbot generik di awan, tetapi sistem AI yang duduk terus di lantai produksi, membaca dokumen dalaman kilang, dan jawab soalan teknikal dengan tepat dalam beberapa saat – tanpa hantar satu byte pun data proses ke luar negara. Dan kuncinya? Bukan GPU semata-mata, tetapi cara kita guna CPU.

Artikel ini kupas semula idea dari projek RAG atas platform DGX Spark (Grace–Blackwell), kemudian saya kaitkan terus dengan konteks pembuatan elektronik, automotif dan semikonduktor di Malaysia – apa yang praktikal untuk kilang, apa perangkap biasa, dan bagaimana nak mula.

---

Kenapa RAG Penting Untuk Kilang Elektronik & Automotif

RAG ialah seni bina AI yang menggabungkan dua dunia:

1. Retrieval – cari semula maklumat tepat daripada dokumen (SOP, spec sheet, FMEA, laporan QA, datasheet mesin)
2. Generation – guna model bahasa (LLM) untuk terangkan jawapan dalam bahasa semula jadi

Dalam konteks kilang:

• Jurutera tanya: “Apa had suhu reflow maksimum untuk PCB projek ABC?”
• Penyelia tanya: “Apa tindakan containment dalam 8D report untuk defect solder void Q3 tahun lepas?”
• Operator tanya (melalui HMI): “Apa prosedur bila mesin AOI detect false call lebih 5%?”

Tanpa RAG, LLM akan cuba “meneka” dari pengetahuan umum. Di sinilah masalah hallucination berlaku: jawapan yakin, nampak profesional, tetapi salah. Dalam pembuatan, jawapan salah boleh bermakna:

• scrap wafer bernilai ratusan ribu ringgit
• field failure automotif dan recall mahal
• audit pelanggan yang tak lulus

Dengan RAG, model dipaksa merujuk dokumen sebenar sebelum menjawab. Ia bukan pandai mengarang, tetapi pandai memetik rujukan yang betul.

---

Peranan Tersembunyi CPU Dalam RAG: Di Sini Banyak Syarikat Silap

Kebanyakan orang menganggap “AI = GPU”. Untuk latihan model besar, ya. Tapi untuk sistem RAG dalam kilang, corak bebannya berbeza.

Dalam pipeline RAG tipikal, alirannya ringkas:

1. Soalan pengguna → ditukar kepada embedding vektor
2. Vektor ini cari rekod paling hampir dalam vector database (FAISS, dsb.)
3. LLM jana jawapan berdasarkan petikan dokumen yang ditemui

Bahagian yang ramai tak ambil berat ialah langkah embedding tadi. Pada dunia sebenar di kilang:

• Soalan pendek (satu baris, bukan esei 10 perenggan)
• Beban throughput rendah tetapi latensi kritikal (jawapan perlu <1 saat jika mahu digunakan di lantai produksi)

Menghantar permintaan kecil sebegini ke GPU setiap kali membawa beberapa isu:

• overhead penjadualan GPU
• latensi pemindahan data (contoh melalui PCIe pada sistem biasa)
• penggunaan GPU jadi tak cekap – GPU menunggu kerja kecil-kecilan yang sepatutnya CPU boleh selesaikan

Dalam projek DGX Spark, embedding ini dipindahkan ke CPU Arm Cortex-X/A dan digabung dengan model embedding int8 yang kuantized. Hasilnya:

• masa embedding tipikal 70–90 ms per soalan
• tenaga lebih rendah berbanding jika GPU dipaksa bangun untuk kerja kecil
• pengalaman interaktif yang lebih lancar untuk pengguna

Dalam erti kata lain, CPU sangat sesuai untuk kerja AI yang kecil tetapi kritikal masa – tepat jenis beban yang wujud dalam sistem carian dokumen kilang, sistem QA berasaskan teks, dan smart helpdesk dalaman.

---

Unified Memory: Kesan Besar Bila Data Proses Tak Boleh Keluar Kilang

Untuk kilang E&E dan semikonduktor, satu isu yang selalu menghantui ialah data sovereignty:

• paramater proses SMT dan backend sering diklasifikasikan “confidential”
• yield report, analisis defect, dan recipe mesin tak boleh tinggalkan premis mengikut polisi pelanggan global

Ini menyebabkan ramai pengeluar di Malaysia beralih kepada on-device AI / edge AI. Tapi bila CPU dan GPU dipisahkan memori (senario tradisional), pipeline jadi berat:

• embedding di CPU → salin ke memori GPU
• hasil inference di GPU → salin balik ke CPU
• setiap salinan = latensi + penggunaan bandwidth

Dalam seni bina seperti Grace–Blackwell (DGX Spark), CPU & GPU berkongsi Unified Memory:

• hanya satu ruang DRAM dikongsi
• embedding yang dijana CPU boleh terus dibaca GPU tanpa salinan eksplisit
• lonjakan penggunaan memori dari idle ke beban penuh RAG hanya sekitar +10 GiB dan kekal stabil

Untuk senario kilang:

• LLM dan index vektor boleh kekal duduk dalam memori untuk sesi panjang – tiada reload model berulang
• latensi respons kekal konsisten sepanjang syif operasi
• lebih mudah untuk merancang kapasiti RAM bila nak scale ke beberapa line atau beberapa kilang

Bagi saya, unified memory bukan sekadar konsep seni bina. Ia memudahkan pasukan IT/OT yang perlu pastikan sistem AI on-prem beroperasi 24/7 tanpa drama.

---

Dari Demo Raspberry Pi Ke Kilang SMT & FAB Sebenar

Dalam artikel asal, contoh yang digunakan ialah dokumentasi Raspberry Pi: datasheet panjang, jadual GPIO, nota aplikasi. Cabarannya sangat serupa dengan apa yang berlaku di:

• kilang papan litar bercetak (PCB & PCBA)
• kilang automotif yang penuh SOP dan spesifikasi komponen
• fab semikonduktor dengan process of record (POR) ratusan halaman

Contoh senario di Malaysia

1. SMT & box-build elektronik
Soalan lazim jurutera proses:

• “Apa spec maksimum coplanarity connector XYZ dari supplier Jepun?”
• “Apa parameter reflow oven yang digunakan masa NPI projek DEF tahun 2023?”

Dengan RAG setempat:

• Sistem baca semua datasheet supplier, NPI report, dan golden recipe
• Jurutera tanya dalam Bahasa Melayu atau Inggeris
• Jawapan datang dengan rujukan jelas: nombor halaman, seksyen dokumen, dan nilai numerik yang boleh terus dipakai

2. Automotif – pengurusan FMEA & 8D
Bagi OEM atau Tier-1 di Gurun, Pekan atau Tanjung Malim:

• ribuan FMEA, 8D, dan laporan audit pelanggan terkumpul bertahun-tahun
• pengalaman lepas selalunya terperangkap dalam folder dan “kepala orang lama”

RAG boleh:

• jadikan semua laporan ini vector database dalaman
• jawab: “Punca akar (‘root cause’) paling kerap untuk paint defect jenis orange peel?”
• cadangkan langkah containment berdasarkan kes sebenar yang pernah berjaya

3. Fab semikonduktor – parametric & SPC
Walaupun data proses wafer biasanya berstruktur (SQL, historian), nota teknikal, POR, guideline perubahan proses semuanya teks.

• Jurutera proses ingin tahu: “Apa syarat mutlak bila tukar gas pembawa untuk proses etch layer M3?”
• RAG carikan jawapan daripada POR, guideline HQ, dan lesson learnt terdahulu – bukan dari internet.

Dalam semua contoh ini, CPU menjalankan embedding dan carian dengan latensi rendah, sementara GPU (jika ada) fokus kepada penjanaan bahasa yang lebih berat.

---

Reka Bentuk RAG Praktikal Untuk Kilang: Apa Yang Perlu Ada

Mengambil inspirasi dari implementasi DGX Spark, satu pipeline RAG kilang yang sihat biasanya ada beberapa ciri berikut.

1. Embedding di CPU, model generatif di GPU

Model embedding ringan + CPU pantas:

• gunakan model embedding int8 yang dioptimumkan
• jalankan di CPU berprestasi tinggi (contoh kelas Cortex-X / Xeon / EPYC)
• sasarkan latensi embedding sekitar <100 ms per soalan

Model bahasa (LLM) di GPU atau CPU kuat:

• untuk kilang, model 7B–8B sudah mencukupi jika digandingkan dengan RAG yang bagus
• jalankan dengan rangka kerja ringan seperti llama.cpp di GPU atau CPU berganda jika GPU terhad

2. Index vektor tempatan (contoh FAISS)

• semua embedding dokumen disimpan dalam index di pelayan on-prem
• tiada carian dihantar ke luar; sesuai dengan keperluan pelanggan E&E global yang sensitif data
• penyelenggaraan index boleh di-schedule luar waktu puncak (contoh shift malam)

3. Unified Memory atau pipeline data yang disiplin

Jika platform menyokong unified memory:

• kurangkan copy data antara CPU dan GPU
• pastikan model kekal di DRAM sepanjang operasi

Jika tidak:

• minimakan saiz batch
• guna pinned memory dan pipeline yang jelas supaya tiada salinan berganda

4. Pengurusan dokumen yang serius

RAG sebaik mana pun tak boleh selamatkan dokumen yang bersepah. Beberapa amalan yang saya nampak berkesan di kilang:

• standardkan naming convention dokumen projek dan produk
• asingkan dokumen mengikut status (draft vs released)
• log versi supaya model hanya gunakan dokumen yang telah diluluskan QA/PE

---

CPU-First AI: Implikasi Untuk Strategi Perkakasan Kilang Di Malaysia

Ada satu kesan besar daripada semua ini: pelaburan AI di kilang tak semestinya bermula dengan GPU farm besar.

Untuk kebanyakan pengeluar elektronik dan automotif Malaysia, keutamaan sekarang ialah:

• tingkatkan kecekapan jurutera
• percepatkan troubleshooting di line
• permudahkan knowledge transfer di antara shift dan antara plant

Kesemuanya boleh dicapai dengan:

• satu pelayan x86 atau Arm kelas sederhana–tinggi
• CPU multi-core yang baik, RAM yang mencukupi (contoh 64–128 GiB)
• GPU tunggal (atau tiada langsung, bergantung keperluan model)

Strategi yang lebih bijak untuk 6–12 bulan akan datang:

1. Mulakan dengan pilot RAG dalaman fokus kepada satu domain: contohnya hanya dokumen SMT, atau hanya FMEA automotif.
2. Pastikan embedding + retrieval dioptimumkan di CPU dahulu. Capai SLA latensi yang boleh diterima oleh jurutera (biasanya <1 s jawapan awal).
3. Barulah pertimbang tambah GPU untuk bahasa natural yang lebih canggih, terutamanya jika mahu
   • sokongan dwi-bahasa penuh (BM/EN)
   • penjanaan laporan automatik
   • multi-turn conversation yang panjang

Realitinya, CPU yang diurus dengan baik boleh menangani sebahagian besar kerja AI harian dalam kilang.

---

Cara Praktikal Untuk Mula Di Kilang Anda

Jika anda berada di IT, OT, atau pasukan kejuruteraan proses, beberapa langkah ringkas ini boleh dijadikan pelan permulaan:

1. Pilih satu kes guna bernilai tinggi
   Contoh: carian dokumen untuk jurutera proses SMT, atau bantuan SOP untuk operator automotif.

2. Kumpulkan 200–500 dokumen pertama
   Pastikan fokus pada satu produk/line dahulu. Bersihkan nama fail, buang versi lapuk.

3. Guna stack perisian ringan

   • Python untuk orkestrasi
   • FAISS untuk index vektor
   • llama.cpp atau setara untuk model bahasa quantized

4. Kunci polisi data sejak awal
   Tegaskan bahawa semua model dan index berjalan sepenuhnya on-prem; tiada dokumen projek dihantar ke awan pihak ketiga.

5. Ukur latensi di CPU sebelum tambah GPU
   Jika embedding <100 ms dan keseluruhan respons <1.5 s, anda sudah cukup baik untuk kebanyakan kes guna.

---

Menjayakan AI Kilang Pintar: CPU Sebagai Enjin Senyap

RAG yang dijalankan secara setempat memberi tiga benda yang sangat sukar diperoleh sekali gus melalui cloud sahaja: privasi, latensi, dan kesetiaan teknikal. Projek DGX Spark menunjukkan bahawa CPU – khususnya seni bina Arm berkecekapan tinggi – bukan sekadar tukang pra-proses, tetapi enjin utama untuk embedding, carian, dan orkestrasi pipeline AI.

Untuk ekosistem E&E dan semikonduktor Malaysia yang sedang bergerak ke arah kilang pintar, mesejnya jelas:

“GPU penting, tetapi kejayaan harian AI di kilang banyak bergantung kepada sejauh mana anda mengoptimumkan penggunaan CPU dan memori.”

Jika kilang anda sudah ada pelayan moden tetapi belum pasti bagaimana mahu bermula dengan AI, RAG berasaskan CPU ialah titik mula yang praktikal dan kos efektif. Mulakan dengan satu kes guna sempit, jadikan dokumen anda ‘boleh dibaca mesin’, dan benarkan CPU anda menunjukkan yang ia sebenarnya jauh lebih penting daripada yang selalu kita anggap.

Soalannya sekarang: adakah semua pengetahuan kritikal dalam kilang anda kekal terperangkap dalam PDF dan kepala pakar, atau sudah sedia untuk dihidupkan semula melalui AI di atas CPU yang anda sudah miliki?