Ollama di Intel Celeron, Bagian I: Dari 120 Detik Menjadi Kurang dari 1 Detik

ollama llm grav-cms rag self-hosting

Ollama di Intel Celeron, Bagian I: Memaksimalkan LLM Lokal dari Laptop Murah

Ollama di Intel Celeron Mini PC

Bayangkan setup "AI lokal" yang sering dibicarakan orang: PC gaming dengan GPU NVIDIA gemerlap yang harganya lebih mahal dari mobil bekas. Sekarang bayangkan kebalikannya — sebuah mini PC Intel Celeron N4100 dengan RAM kurang dari 8 GB, jenis mesin yang biasanya hanya dipakai untuk mengecek rekening bank. Apa yang terjadi jika kita menjalankan LLM lokal di mesin seperti itu?

Awalnya tidak ada yang indah. Saya mengajukan satu pertanyaan dan harus menunggu 120+ detik tanpa kepastian — tanpa kedipan kursor, tanpa status "berpikir...", hanya keheningan. Ketika akhirnya merespons, kecepatan mengetiknya sangat lambat: di bawah 2 kata per detik.

Namun inilah kejutannya: hampir seluruh penantian 120 detik tersebut bukan karena AI sedang "berpikir". Itu adalah CPU yang melakukan pekerjaan berulang yang tidak perlu pada setiap pertanyaan. Setelah saya menemukan alasan di balik kelambatan tersebut dan menerapkan trik pencarian berbasis Grav CMS, masa tunggu 120 detik itu pangkas menjadi kurang dari 1 detik. Berikut cerita lengkapnya.

1. Kenali Dua Musuh Utama Anda

Menjalankan model AI pada CPU murah tanpa kartu grafis berarti Anda melawan dua musuh yang berbeda. Jika Anda salah mengidentifikasi, Anda akan "memperbaiki" hal yang salah.

Musuh #1: Memori Lambat (Mengatur Kecepatan Mengetik)

Setiap kata yang dihasilkan AI memaksa CPU untuk membaca seluruh model dari RAM secara berulang. Ini bukan sekadar "berpikir", melainkan seperti "membaca ulang seluruh buku teks hanya untuk menulis satu kalimat".

Processor N4100 hanya mampu mentransfer data dari RAM sekitar 19.2 GB/s pada mode single-channel — bukan bandwidth yang cepat. Ini memberikan batas atas pada kecepatan mengetik, sekitar 2.8 hingga 4 kata per detik, dan tidak ada trik perangkat lunak yang bisa menembusnya. Ini adalah batasan fisik hardware.

Musuh #2: Kurangnya Instruksi Matematika Cepat (Mengatur Waktu Jeda Sebelum Menjawab)

Mesin AI modern sangat mengandalkan instruksi CPU khusus (AVX2/AVX-512) untuk memproses banyak angka sekaligus.

Generasi chip N4100 (Goldmont Plus) tidak memiliki fitur tersebut — chip ini memproses matematika satu per satu secara konvensional. Berikan pertanyaan sepanjang 500 kata, dan CPU akan tenggelam dalam kalkulasi selama 30 hingga 45 detik sebelum menghasilkan kata pertama.

Kesimpulan: memori yang lambat membatasi kecepatan mengetik, sedangkan ketiadaan instruksi AVX2 membatasi seberapa lama Anda menunggu sebelum AI mulai merespons.

2. Bukti Log Eksekusi

Berikut adalah log aktual dari Ollama yang berjalan pada chip Celeron ini.

Eksperimen A: Pertanyaan Langsung Tanpa Optimasi

AI harus memproses 191 kata baru tanpa bantuan cache:

prompt eval time = 30776.58 ms / 191 tokens (161.13 ms per token, 6.21 tokens/s)
eval time        = 59510.49 ms / 170 tokens (350.06 ms per token, 2.86 tokens/s)
total time       = 90287.07 ms / 361 tokens

Hasil: 30.7 detik waktu jeda sebelum kata pertama muncul, kemudian respons diketik dengan kecepatan di bawah 3 kata/detik. Total waktu: sekitar 90 detik.

Eksperimen B: Permintaan yang Sama Dengan Caching

Kali ini, 400 kata konteks sudah tersimpan di memori sebelumnya, sehingga CPU tidak perlu mengulang kalkulasi:

cached n_tokens  = 400
prompt eval time =   230.65 ms /   1 tokens (230.65 ms per token, 4.34 tokens/s)
eval time        = 40079.61 ms / 144 tokens (278.33 ms per token, 3.59 tokens/s)
total time       = 40310.25 ms / 145 tokens

Waktu jeda awal berkurang dari 30.7 detik menjadi 0.23 detik — hampir instan. Kecepatan mengetik tetap sama karena dibatasi fisik memori, tetapi waktu tunggu awal yang membosankan telah hilang.

3. Solusi: Berikan Potongan Teks Ringkas

Trik di atas dapat bekerja jika Anda berhenti mengirimkan teks yang terlalu panjang pada setiap permintaan. Solusi sebenarnya adalah: berikan potongan teks ringkas yang relevan saja.

Ini adalah konsep Retrieval-Augmented Generation (RAG) — cari bagian yang relevan terlebih dahulu, lalu berikan hanya bagian tersebut kepada AI.

Arsitektur Alur Kerja RAG

Sebagian besar panduan RAG menyarankan penggunaan "vector database" seperti ChromaDB yang membutuhkan RAM dan CPU tinggi. Pada mesin hemat daya, itu bukanlah pilihan bijak.

Oleh karena itu, saya memanfaatkan Grav CMS yang menyimpan seluruh konten dalam bentuk file Markdown sederhana tanpa database SQL. Hal ini sangat cocok untuk mesin pencari lokal.

Berikut alur kerjanya:

[Pengunjung mengajukan pertanyaan]
       │
       â–¼
[Skrip menghapus kata penghubung]    →  kata seperti "jelaskan", "apa" dihapus
       │
       â–¼
[Cari Indeks Markdown Grav]         →  instan, tanpa AI tambahan
       │
       â–¼
[Ambil ~150 kata paling relevan]
       │
       â–¼
[Kirim *hanya bagian itu* ke Ollama] →  jawaban cepat, bahkan di hardware lama

4. Perbandingan Sebelum vs Sesudah

Metrik Sebelum (Prompt Mentah) Sesudah (Grav CMS + Caching)
Teks yang dikirim ke AI 500+ kata, tanpa cache ~150 kata (atau 400+ reused)
Jeda sebelum AI merespons 30.7 detik 0.23 detik
Kecepatan mengetik 2.86 kata/detik 3.59–4.34 kata/detik
Total waktu per jawaban ~90 detik ~40 detik
Penggunaan memori tambahan Sangat tinggi Sangat minimal

5. Ringkasan Tips Optimasi

  1. Gunakan RAM Dual-Channel jika memungkinkan. Dua keping RAM dapat meningkatkan kecepatan transfer data secara signifikan.
  2. Hindari Vector Database berat di prosesor Celeron. Ketiadaan AVX2 membuat model embedding berat menjadi sangat lambat. Indeks teks berbasis SQLite jauh lebih efisien.
  3. Manfaatkan Caching. Pertahankan sistem prompt yang konsisten agar AI dapat menggunakan kembali kalkulasi sebelumnya.
  4. Kirim konteks secukupnya. Potongan teks 150 kata yang tepat jauh lebih efektif daripada memasukkan seluruh halaman situs.

Previous Post Next Post