Di Bagian III, kami membangun pipeline 5 tingkat untuk grav-ai-chatbot — mesin pencari AI lokal yang berjalan di laptop Intel Celeron 6-Watt.
Begitu chatbot itu mulai menerima lalu lintas nyata dari perangkat-perangkat di jaringan berbeda — LAN lokal dan jaring VPN Tailscale untuk akses dari luar rumah — satu pertanyaan langsung muncul: apakah jalur jaringannya sendiri menambah latensi, di atas semua yang sudah kami perbaiki?
Jawaban singkatnya: hampir tidak. Tapi membuktikannya butuh telemetri asli, skrip benchmark khusus, dan beberapa pelajaran soal failover serta caching di sepanjang jalan. Ini dia hasilnya.
Ada anggapan umum bahwa semua trafik lewat Tailscale pasti singgah dulu di server relay di internet, sehingga menambah latensi. Itu memang benar — tapi hanya kalau dua perangkat tidak bisa saling terhubung langsung. Kalau kedua perangkat berada di jaringan lokal yang sama, ceritanya beda.
Yang menentukan cepat-lambatnya koneksi sebenarnya bukan Tailscale itu sendiri — overhead protokolnya sangat kecil, di mana pun posisi kedua perangkat. Ada dua faktor yang lebih menentukan:
Dua perangkat di LAN yang sama menghilangkan kedua faktor itu sepenuhnya. Itu sebabnya angka-angka di bawah terlihat sebagus itu:
Client / Server Web Grav
│
├────► Primer: Alamat mesh Tailscale (~0.09 ms)
│
└────► Cadangan: Alamat LAN Fisik (~0.09 ms)(Angka 100.x.x.x untuk antarmuka Tailscale dan 192.168.x.x untuk LAN di atas cuma ilustrasi — alamat sebenarnya tentu spesifik untuk jaringan masing-masing.)
Karena kedua jalur sama-sama cepat, kami tetap membangun failover dua endpoint otomatis di OpenAiCompatibleClient.php. Jadi kalau alamat utama tidak merespons dalam 3 detik — misalnya perangkat baru saja bangun dari tidur dan antarmuka jaringannya butuh waktu sejenak untuk rebind — klien diam-diam mencoba alamat cadangan sebelum pengunjung sempat menyadari ada yang lambat.
Menggunakan telemetri yang ditarik langsung dari log server Ollama, kami menguji tiga skenario prompt — pertanyaan singkat, permintaan ringkasan sedang, dan kueri konteks RAG yang panjang. Masing-masing diuji dua kali: sekali tanpa cache, sekali dengan prompt cache yang sudah hangat.
| Metrik | Tanpa Cache | Dengan Cache | Perubahan |
|---|---|---|---|
| Waktu evaluasi prompt | 2.020,80 ms | 205,40 ms | 🚀 89,8% lebih cepat |
| Kecepatan generasi | 5,57 token/detik | 5,62 token/detik | ~tetap |
| Latensi total | 13,04 s | 6,74 s | 48,3% lebih cepat (hemat 6,3 s) |
| Metrik | Tanpa Cache | Dengan Cache | Perubahan |
|---|---|---|---|
| Waktu evaluasi prompt | 3.883,38 ms | 3.868,64 ms | ~tetap |
| Kecepatan generasi | 3,75 token/detik | 4,15 token/detik | 10,6% lebih cepat |
| Latensi total | 38,71 s | 35,37 s | 8,6% lebih cepat (hemat 3,34 s) |
| Metrik | Tanpa Cache | Dengan Cache | Perubahan |
|---|---|---|---|
| Waktu evaluasi prompt | 13.604,23 ms | 232,82 ms | 🚀 98,3% lebih cepat |
| Kecepatan generasi | 3,58 token/detik | 3,58 token/detik | stabil |
| Latensi total | 50,17 s | 36,65 s | 26,9% lebih cepat (hemat 13,52 s) |
Polanya sama di ketiga skenario: jaringan cuma faktor kecil yang nyaris tidak berpengaruh (rounding error). Setiap peningkatan berarti di sini datang dari prompt cache — bukan dari lewat alamat IP mana permintaan itu berjalan.
Pada kueri konteks RAG panjang, waktu evaluasi prompt turun dari 13,6 detik menjadi 0,23 detik — pemotongan 98,3%. Ini murni berkat KV-cache Ollama yang menjaga awalan system-prompt yang sama tetap "hangat" di RAM. Artinya, siapa pun yang mengajukan pertanyaan lanjutan — atau dua pengunjung berbeda yang kebetulan menyentuh konteks serupa — bisa melewati hampir seluruh jeda "berpikir". Ini trik prefix-caching yang sama dari Bagian I, hanya kali ini diukur di bawah lalu lintas produksi yang nyata dan berantakan, bukan benchmark yang bersih dan terkontrol.
Saat beban sedang tinggi, atau tepat setelah cold start ketika model masih "memanas", pengunjung kadang melihat pesan seperti Operation timed out after 120002 ms. Pesan itu sangat akurat secara teknis, tapi sama sekali tidak ramah untuk manusia biasa. Sekarang, OpenAiCompatibleClient.php menangkap kegagalan transportasi ini dan menampilkan pesan yang lebih bersahabat: "Asisten AI kami sedang memanas…" — sementara kesalahan aslinya tetap dicatat ke file log untuk keperluan debugging. Perbaikan kecil, tapi kesan pertama jadi jauh lebih baik.
Ringkasan halaman yang kompleks kadang menabrak batas anggaran token dan berhenti tiba-tiba, di tengah pemikiran. Solusinya dua hal: menaikkan max_tokens dari 128 menjadi 256 di ai-chatbot.yaml, dan menambahkan batas pemotongan konteks yang lebih tepat di ContextIndexer.php. Hasilnya, jawaban tidak lagi terpotong mendadak, tanpa mengorbankan kecepatan respons secara signifikan — ternyata sebagian besar jawaban cuma butuh sedikit ruang ekstra untuk menyelesaikan kalimatnya.
Pelacakan biaya per token yang sebenarnya. Rencananya, angka prompt_eval_count dan eval_count yang dilaporkan Ollama akan langsung di-parsing ke log interaksi, supaya dasbor admin menampilkan biaya dan throughput yang akurat — bukan sekadar perkiraan.
