Self-Host Ollama pada Server LLM dan Ambil Kontrol atas Sensor AI
Kata Kunci
Sebelum memulai setup, berikut adalah istilah yang paling mungkin membingungkan pembaca dalam panduan ini. Glosarium cepat ini menjaga kosakata Linux, GPU, dan model lokal tetap jelas sejak awal.
| Kata Kunci | Penjelasan Singkat |
|---|---|
| 🤖 LLM | Large Language Model; model AI yang menghasilkan teks dari prompt. |
| 🦙 Ollama | Penjalankan model lokal dan server untuk mengunduh, melayani, dan memanggil LLM di mesin Anda sendiri. |
| 🖥️ GPU | Prosesor grafis yang digunakan di sini untuk mempercepat inference model. |
| 💾 VRAM | Memori pada GPU; ini adalah salah satu batasan utama seberapa besar model dapat muat di kartu. |
| ⚡ Inference | Tindakan menjalankan model untuk menghasilkan jawaban. |
| 🔄 systemd | Manajer layanan Linux yang digunakan untuk memulai, menghentikan, memulai ulang, dan mengaktifkan layanan seperti Ollama. |
| 🧩 NVIDIA driver | Lapisan perangkat lunak yang memungkinkan Ubuntu berkomunikasi dengan GPU NVIDIA dengan benar untuk beban kerja komputasi. |
| 🚫 nouveau | Driver grafis Linux open-source yang dapat mencegah setup komputasi NVIDIA yang tepat jika digunakan sebagai pengganti driver NVIDIA resmi. |
| 📊 nvidia-smi | Alat baris perintah NVIDIA untuk memeriksa visibilitas GPU, penggunaan VRAM, dan kesehatan driver. |
| 🔌 API endpoint | URL yang dipanggil alat atau skrip untuk mengirim prompt ke Ollama dan menerima respons. |
| ☁️ Vendor-controlled serving layer | Lapisan API yang dikelola penyedia yang dapat menambahkan moderasi, logging, penegakan kebijakan, atau kontrol lainnya sebelum model merespons. |
| 🧬 Fine-tune | Versi yang dimodifikasi dari model dasar yang disesuaikan untuk nada, perilaku, atau tugas khusus yang berbeda. |
| ⚖️ Model weights | Parameter internal yang dipelajari dari model; self-hosting tidak secara otomatis mengubahnya. |
| 📝 Modelfile | File Ollama yang digunakan untuk membuat varian model lokal kustom dengan prompt sistem Anda sendiri dan parameter runtime. |
| 🪪 UUID | Pengenal perangkat keras yang stabil untuk GPU; sering lebih aman daripada ID GPU numerik karena urutan perangkat dapat berubah. |
| 🔒 TLS | Enkripsi yang digunakan oleh HTTPS dan reverse proxy untuk mengamankan lalu lintas antara klien dan server. |
| 🌐 Reverse proxy | Layanan front-end yang dapat menambahkan TLS, autentikasi, dan akses publik terkontrol sebelum meneruskan permintaan ke Ollama. |
| 🎛️ Temperature / seed | Pengaturan generasi; temperature mempengaruhi keacakan, sementara seed tetap membantu membuat tes berulang lebih dapat dibandingkan. |
| 🧱 CPU spill / mixed path | Situasi di mana bagian dari model atau beban kerja jatuh di luar memori GPU dan menggunakan sumber daya CPU, yang dapat memperlambat inference. |
| 🔧 nvidia_uvm | Modul kernel NVIDIA yang terkait dengan manajemen memori GPU yang kadang-kadang perlu dimuat ulang selama pemecahan masalah. |
Mengapa Self-Hosting LLM Layak Dilakukan

Jika Anda sudah melakukan bagian yang sulit — menyewa server GPU, menginstal Ubuntu, belajar menggunakan SSH, dan menjaga layanan Anda sendiri tetap berjalan — akan menjadi frustrasi dengan cepat ketika AI yang di-host masih mengendalikan mile terakhir. Ini dapat menolak permintaan yang sangat biasa, menguburkan jawaban di bawah penafian, mengubah gaya respons tanpa peringatan, dan menjaga setiap prompt mengalir melalui batasan milik orang lain. Bagi banyak pengguna teknis, itulah frustrasi sebenarnya: bukan hanya apa yang dikatakan model, tetapi siapa yang mengendalikan lapisan serving ketika model itu berbicara.
Panduan ini tentang memperbaiki itu dengan model terbuka dan lokal, bukan tentang trik bypass untuk API proprietary. Anda akan self-host Ollama di server GPU Ubuntu, menjalankan inference secara lokal, memverifikasi bahwa jalur GPU benar-benar ada, dan melihat apa yang berubah ketika Anda memilih keluarga model yang berbeda. Satu kesalahpahaman yang perlu dijelaskan sejak awal: self-hosted tidak secara otomatis berarti tidak terbatas. Ini berarti Anda mengendalikan lebih banyak dari stack — dan Anda berhenti bergantung pada jalur serving yang dikontrol vendor — tetapi model yang Anda jalankan masih dapat membawa perilaku alignment-nya sendiri.
📝 Catatan: Perintah dalam panduan ini divalidasi terhadap dokumentasi Ollama saat ini, tetapi output terminal yang ditampilkan di bawah adalah contoh representatif daripada tangkapan benchmark langsung. Gunakan mereka sebagai pola kesuksesan, bukan sebagai klaim kinerja.
Di akhir, Anda akan memiliki layanan Ollama yang berfungsi di Ubuntu, API lokal yang diverifikasi di 127.0.0.1:11434, bukti bahwa inference yang didukung GPU benar-benar terjadi, dan perbandingan yang berdasar antara model aligned mainstream dan alternatif yang kurang terbatas. Tutorial ini ditulis untuk pembaca yang nyaman dengan SSH, Ubuntu, sudo, dan systemd, tetapi yang tidak memerlukan pengalaman Ollama sebelumnya.
Server GPU Ubuntu Tepat yang Digunakan untuk Panduan Ini

Panduan ini didasarkan pada mesin Ubuntu dengan GPU tunggal yang nyata, karena saran vague “seharusnya bekerja di sebagian besar server” adalah bagaimana panduan self-hosting menjadi menyesatkan. Kotak referensi di sini adalah kelas host aktual yang digunakan untuk panduan ini: jenis mesin yang akan benar-benar disewa oleh individu lanjutan, lab, atau tim kecil ketika mereka menginginkan inferensi lokal pribadi tanpa langsung melompat ke rak akselerator enterprise. Panduan ini masih akan membahas perilaku multi-GPU nanti, karena Ollama memang berubah setelah model melampaui satu kartu, tetapi perlakukan bagian itu sebagai konteks yang berorientasi ke depan daripada bukti dari server yang tepat ini.
Server GPU — Ryzen 9 3950X + RTX 4070 Ti Super
| Komponen | Detail |
|---|---|
| CPU | AMD Ryzen 9 3950X (16 cores / 32 threads) |
| GPU | 1× NVIDIA RTX 4070 Ti Super |
| VRAM | 16GB |
| Capability | Kuat untuk model kelas 8B; model yang lebih besar menjadi keputusan spill-or-upgrade |
Dalam praktiknya, ini adalah setup yang sangat kuat untuk model kelas 8B sehari-hari dan masih berguna untuk pekerjaan lokal yang lebih besar hingga titik di mana 16GB VRAM menjadi kendala nyata. Model seperti llama3.1:8b pada sekitar 4.9GB cocok dengan mudah di kartu ini. Model seperti gpt-oss:20b pada sekitar 14GB adalah jenis tes single-GPU ujung atas yang masih masuk akal di sini. Model seperti qwen3:30b pada sekitar 19GB lebih baik diperlakukan sebagai titik referensi untuk apa yang berubah di host yang lebih besar atau dual-GPU daripada sebagai kecocokan bersih untuk mesin yang tepat ini.
Perbedaan itu penting karena poin artikel ini bukan untuk memeras angka terbesar yang mungkin ke dalam headline. Ini adalah untuk menunjukkan seperti apa server LLM self-hosted yang masuk akal ketika Anda menginginkan privasi, kontrol lokal, dan cukup memori GPU untuk menjalankan model yang berguna tanpa kompromi konstan. Kelas hardware ini adalah di mana inferensi self-hosted menjadi realistis, bukan teoritis.
Ini juga menjelaskan beberapa pilihan yang akan Anda lihat nanti: mistral digunakan terlebih dahulu karena memberikan bukti cepat dan rendah gesekan bahwa stack bekerja, sementara perbandingan perilaku tetap di kelas 8B di mana mesin ini nyaman. qwen3:30b masih muncul nanti, tetapi sebagai contoh teoritis dari jenis model yang dapat memicu penempatan multi-GPU di host yang lebih besar daripada sebagai bukti langsung dari server ini. Dengan ekspektasi yang ditetapkan, langkah berikutnya adalah memvalidasi host sebelum Ollama menyentuhnya.
Jalankan Pemeriksaan Pra-Instalasi Ini Sebelum Anda Menyentuh Ollama

Mulai dengan nvidia-smi. Jika perintah ini hilang atau gagal, berhentilah di sana dan perbaiki driver NVIDIA terlebih dahulu. Jangan instal Ollama dulu, karena stack NVIDIA yang rusak akan membuat setiap gejala berikutnya terlihat seperti kegagalan aplikasi padahal sebenarnya adalah kegagalan platform.
Jalankan pemeriksaan GPU terlebih dahulu:
nvidia-smi
❗Jika Ubuntu mengatakan nvidia-smi hilang, jangan asumsikan server tidak memiliki GPU. Mode kegagalan umum pada kotak Ubuntu yang disewa adalah kartu ada tetapi masih terikat pada nouveau bukan driver NVIDIA. Periksa bagian “Perbaiki Masalah Driver Nvidia di Ubuntu” terlebih dahulu.
Hasil yang sehat pada kelas server ini seharusnya terlihat kurang lebih seperti ini:

Setelah nvidia-smi berfungsi dan GPU terlihat, lanjutkan dengan pemeriksaan di bawah ini.
Yang ingin Anda konfirmasi sangat sederhana: GPU yang diinstal terlihat, melaporkan kira-kira 16GB VRAM di host ini, dan driver dimuat dengan bersih. Jika Anda berada di server multi-GPU, perintah yang sama harus mencantumkan setiap kartu.
nvidia-smi -L

❗ Penting: Dokumentasi dukungan GPU Ollama saat ini menggunakan driver NVIDIA 531+ sebagai dasar nyata untuk inferensi NVIDIA yang didukung. Perlakukan 531+ sebagai persyaratan untuk panduan ini, bahkan jika Anda telah melihat catatan komunitas yang lebih lama mengutip versi yang lebih rendah.
Sekarang konfirmasi bahwa host benar-benar lingkungan Ubuntu yang diasumsikan panduan ini:
lsb_release -a

Terakhir, periksa ruang disk gratis sebelum Anda mulai mengunduh model. Instalasi itu sendiri kecil; modelnya tidak. Setelah Anda melampaui tes kecil, perpustakaan 20B-30B dapat menghabiskan puluhan gigabyte dengan cepat, jadi 100GB+ gratis adalah pola pikir yang tepat sebelum pekerjaan model lokal yang serius.
df -h /

Jika pemeriksaan ini lulus, Anda telah menghapus ketidakpastian infrastruktur utama: GPU ada, baseline driver masuk akal, Ubuntu dikonfirmasi, dan disk memiliki ruang untuk pull model nyata. Itulah titik di mana menginstal Ollama menjadi langkah berikutnya yang bersih bukan tebakan.
Perbaiki Masalah Driver Nvidia di Ubuntu
Ikuti langkah-langkah di bawah ini untuk memperbaiki masalah dengan perintah “nvidia-smi”.
lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'
Jika output itu menunjukkan kartu NVIDIA dan baris seperti Kernel driver in use: nouveau, instal paket driver Ubuntu yang direkomendasikan bukan hanya menginstal nvidia-utils.
Instal paket ubuntu-drivers-common (diperlukan untuk manajemen driver) dan header kernel untuk kernel yang sedang berjalan saat ini.
apt update
apt install -y ubuntu-drivers-common linux-headers-$(uname -r)Pindai sistem Anda dan buat daftar driver proprietary yang tersedia (misalnya, driver GPU NVIDIA) yang dapat diinstal.
ubuntu-drivers devices
Kemudian instal paket driver yang direkomendasikan. Dalam kasus kami adalah: nvidia-driver-595-open:
apt install -y nvidia-driver-595-open
rebootSetelah reboot, jalankan kembali:
nvidia-smi
nvidia-smi -LInstal Ollama dan Konfirmasi Layanan Sehat

Path Ubuntu yang didukung adalah installer Ollama resmi, bukan alur tarball khusus dan bukan jalan pintas Docker. Itu penting karena panduan ini tentang mendapatkan layanan lokal yang andal dengan default yang dapat diprediksi, integrasi systemd, dan perilaku kepemilikan yang masuk akal di Linux.
Jalankan installer persis seperti yang didokumentasikan:
curl -fsSL https://ollama.com/install.sh | sh
Pada sistem yang sehat, skrip menginstal biner, membuat pengguna layanan ollama, menambahkan keanggotaan grup yang tepat saat tersedia, menulis unit systemd, dan memulai layanan yang terikat ke 127.0.0.1:11434.

Setelah skrip selesai, validasi layanan alih-alih menganggap kesuksesan:
sudo systemctl status ollama --no-pager

Anda mencari tiga hal di sini: file unit ada, layanan diaktifkan untuk boot, dan Active: active (running) mengonfirmasi server benar-benar aktif.
Pertama, tetapkan akun pengguna layanan Linux secara konkret, dan hanya setelah itu pikirkan tentang bagaimana dan di mana penyimpanan model akan ditangani.
getent passwd ollama

Baris tunggal itu menjelaskan banyak perilaku di masa depan. Model di Linux hidup di bawah kepemilikan layanan, dan jika Anda kemudian memindahkannya ke disk lain tanpa memperbaiki izin untuk pengguna ollama, Anda membuat kerusakan sendiri.
Satu pemeriksaan lagi menutup loop pada bind default:
ss -tlnp | grep 11434

⚠️ Peringatan: Ollama tidak memerlukan autentikasi pada API lokal secara default. Itu baik-baik saja ketika terikat ke 127.0.0.1, tetapi tidak aman untuk mengekspos port 11434 langsung ke internet seolah-olah itu adalah layanan publik yang diperkuat.
Jika layanan tidak aktif dengan bersih, buka log terlebih dahulu alih-alih menginstal ulang secara membabi buta:
journalctl -u ollama -n 100 --no-pager
Itu adalah cara tercepat untuk menangkap masalah izin, kesalahan startup, masalah deteksi driver, atau masalah bind. Setelah layanan sehat di localhost, hal berikutnya yang perlu dipahami adalah bagaimana penempatan GPU berperilaku saat runtime.
Bagaimana Ollama Benar-Benar Menggunakan Satu atau Beberapa GPU
Meskipun server yang digunakan untuk panduan ini memiliki satu GPU, perilaku multi-GPU masih layak dipahami karena banyak pengguna dapat berada di kotak yang lebih besar atau mungkin berkembang nanti. Banyak kebingungan dua-GPU dimulai dengan ekspektasi yang salah: “Saya memiliki dua kartu, jadi keduanya harus menyala sepanjang waktu.” Itulah bukan cara Ollama bekerja. Aturan praktis jauh lebih sederhana: jika model cocok di satu GPU, Ollama biasanya akan menyimpannya di satu GPU. Ini hanya menyebar di beberapa GPU ketika model tidak cocok dengan nyaman di satu kartu.
Gunakan dua pemeriksaan ini bersama-sama setiap kali Anda ingin melihat kinerja GPU:
ollama ps
watch -n 1 nvidia-smi
ollama ps memberi tahu Anda bagaimana model yang dimuat diproses. 100% GPU berarti model sepenuhnya berada di memori GPU. 100% CPU berarti akselerasi GPU tidak digunakan. Keadaan campuran memberi tahu Anda beberapa bagian dari beban kerja atau residensi tumpah di luar jalur GPU. watch -n 1 nvidia-smi melengkapi itu dengan menunjukkan penggunaan VRAM langsung per kartu saat model dimuat.
Cara tercepat untuk menjaga peran-peran itu tetap lurus adalah ini:
| Perintah | Apa yang terbukti | Apa yang tidak terbukti |
|---|---|---|
| ollama ps | Apakah model berjalan di GPU, CPU, atau jalur campuran | Kartu mana yang tepat atau kartu yang membawa beban |
| watch -n 1 nvidia-smi | Aktivitas VRAM real-time per GPU | Apakah penggunaan dual-GPU secara otomatis berarti pilihan model yang lebih baik |
📝 Catatan: CUDA_VISIBLE_DEVICES adalah kontrol visibilitas, bukan saklar “gunakan kedua GPU”. Jika Anda pernah membatasi akses GPU, lebih suka UUID dari nvidia-smi -L daripada ID numerik karena urutan GPU dapat bervariasi antara lingkungan dan boot ulang.
Jalankan Model Lokal Pertama Anda dan Verifikasi Inferensi GPU
Pada titik ini, Anda tidak memerlukan model raksasa untuk membuktikan bahwa server berfungsi. Anda memerlukan kesuksesan yang cepat dan jujur. mistral adalah pull pertama yang baik karena kecil, cepat diunduh, dan mudah dimuat, meskipun llama3.1:8b akan menjadi baseline nanti untuk perbandingan perilaku.
Mulai dengan menarik model:
ollama pull mistral

Sekarang jalankan prompt kecil melaluinya sehingga mesin melakukan sesuatu yang berguna, bukan hanya administratif. Respons mungkin membutuhkan beberapa detik.
ollama run mistral "In one sentence, explain why people self-host LLMs."

Untuk membuktikan bahwa ini adalah inferensi yang didukung GPU daripada fallback CPU, periksa status runtime:
ollama ps

Dan untuk melihat apa yang sudah ada di disk, buat daftar inventaris lokal:
ollama list

mistral adalah bukti pertama yang tepat karena memberikan Anda jawaban cepat tanpa mengubah validasi setup menjadi tunggu lama. Nanti, llama3.1:8b menjadi lebih berguna karena merupakan baseline yang selaras lebih kuat untuk membandingkan perilaku model.
Terakhir, periksa di mana instalasi Linux menyimpan model:
sudo du -sh /usr/share/ollama/.ollama/models

Jalur itu — /usr/share/ollama/.ollama/models — adalah penyimpanan model Linux standar yang didokumentasikan oleh Ollama.
Setelah Anda melihat respons yang berhasil, 100% GPU di ollama ps, dan penggunaan disk meningkat di lokasi yang diharapkan, Anda memiliki bukti pertama yang bermakna bahwa stack lokal berfungsi.
Buktikan Ini adalah Server, Bukan Hanya Pembungkus CLI

Prompt baris perintah memang bagus, tetapi alasan untuk self-host Ollama bukan hanya untuk mengobrol di dalam terminal. Ini adalah untuk menjalankan server inferensi lokal yang dapat dipanggil oleh alat, skrip, dan aplikasi lain tanpa mengirim prompt melalui batas API orang lain. Bukti tercepat adalah satu permintaan HTTP yang bersih ke endpoint Ollama asli.
Kirim permintaan generate lokal dengan streaming dinonaktifkan sehingga respons pertama mudah diperiksa:
curl http://localhost:11434/api/generate -d '{
"model": "mistral",
"prompt": "Say hello from a self-hosted Ollama server in one sentence.",
"stream": false
}'Balasan yang berhasil harus kembali sebagai JSON dan terlihat kurang lebih seperti ini:
{
"model": "mistral",
"created_at": "2026-05-13T12:45:12.000000Z",
"response": "Hello from a self-hosted Ollama server running locally on Ubuntu.",
"done": true,
"done_reason": "stop",
"total_duration": 812345678,
"load_duration": 12345678,
"prompt_eval_count": 14,
"eval_count": 12
}
Daftar periksa kesuksesan sangat sederhana: permintaan HTTP bekerja secara lokal, JSON yang valid kembali, done: true ada, dan jawaban model ada di response. Itulah titik di mana Ollama berhenti menjadi “CLI yang kebetulan mengunduh model” dan menjadi infrastruktur yang dapat Anda integrasikan ke dalam alat dan otomasi lokal.
Jika Anda menginginkan kompatibilitas dengan perangkat lunak yang mengharapkan bentuk permintaan gaya OpenAI, Ollama juga mengekspos endpoint /v1 secara lokal:
curl -X POST http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "mistral",
"messages": [
{"role": "user", "content": "Say this is a test."}
]
}'
📝 Catatan: Label “kompatibel dengan OpenAI” itu mudah disalahartikan. Ini tidak berarti Anda berbicara dengan OpenAI, dan itu tidak mengubah fakta bahwa server masih lokal. Ini hanya berarti bentuk permintaan cukup familiar untuk alat dan SDK yang dibangun di sekitar pola API OpenAI. URL dasar tetap http://localhost:11434/v1/, dan kunci API placeholder apa pun yang beberapa pustaka klien настаивают dapat diabaikan untuk penggunaan Ollama lokal.
Dari Mana Pembatasan Model Benar-Benar Berasal

Ini adalah bagian yang biasanya diratakan menjadi satu ide samar tentang “sensor”, tetapi secara teknis ada tiga lapisan berbeda yang terlibat: lapisan serving yang dikendalikan vendor, alignment model dan instruction tuning, dan perilaku prompt/runtime yang Anda kontrol sendiri. Self-hosting mengubah beberapa lapisan tersebut secara dramatis. Ini tidak menghapus semuanya.
Cara sederhana untuk membayangkannya adalah ini:
Cloud API request:
You -> Vendor API gateway -> Vendor moderation / policy layer -> Model -> Response
Self-hosted Ollama request:
You -> Local Ollama server on 127.0.0.1 -> Model -> Response
Hasil:
– Lapisan serving yang dikendalikan vendor menghilang dari jalur lokal
– Batas jaringan lokal dan logging menjadi milik Anda
– Pelatihan dan alignment model itu sendiri masih datang dengan model
Setelah Anda memisahkan lapisan-lapisan tersebut, langkah-langkah setup sebelumnya menjadi jauh lebih bermakna:
| Lapisan | Dikendalikan secara lokal setelah setup ini? | Titik bukti | Apa yang masih tetap benar |
|---|---|---|---|
| Proses server | Ya | ollama.service berjalan di Ubuntu | Anda sekarang mengontrol uptime, log, update, dan bind address |
| Batas jaringan | Ya | Pemeriksaan bind 127.0.0.1:11434 | Permintaan lokal tidak lagi memerlukan lompatan moderasi vendor |
| System prompt / default runtime | Ya | Modelfile untuk pesan sistem yang terkontrol | Anda dapat mengarahkan perilaku, tetapi tidak menulis ulang pelatihan |
| Lapisan moderasi sisi vendor | Biasanya dihapus untuk inferensi lokal saja | Panggilan API lokal native berhasil di localhost | Ini adalah salah satu pergeseran kontrol terbesar yang diberikan self-hosting |
| Alignment model dalam bobot | Tidak, tidak secara otomatis | Tuning model berbeda, memberikan hasil berbeda | Model lokal masih dapat ragu, menolak, atau memberikan nasihat moral |
| Pilihan keluarga model | Ya | llama3.1:8b vs dolphin3 | Pilih yang paling sesuai dengan kebutuhan Anda |
Anda dapat menganggapnya seperti produksi panggung. Self-hosting mengubah panggung, pencahayaan, mikrofon, dan catatan sutradara. Ini tidak melatih ulang aktor. Jika model disetel untuk menjawab dengan hati-hati, sering ragu, atau menolak jenis framing tertentu, menjalankannya secara lokal tidak akan secara ajaib membatalkan pelatihan tersebut.
Apa yang telah dibuktikan oleh setup Anda saat ini lebih sempit, tetapi tetap penting: Anda mengontrol proses server, Anda mengontrol batas API, dan Anda tidak lagi merutekan prompt lokal melalui lapisan moderasi milik vendor. Itu adalah pergeseran nyata dalam privasi dan kontrol. Apa yang belum dibuktikan adalah bahwa setiap model lokal akan berperilaku sama atau bahwa setiap penolakan di masa depan disebabkan oleh penyedia cloud.
Di situlah pilihan model masuk. Jika Anda menginginkan efek praktis dari lebih sedikit penafian, jawaban yang lebih langsung, atau perilaku yang kurang berat penolakan, Anda tidak sampai di sana dengan mengatakan “self-hosted” lebih keras. Anda sampai di sana dengan memilih keluarga model atau fine-tune yang berbeda — dan dengan memahami tradeoff yang menyertainya.
Pilih Model Lokal Dengan Pembatasan Lebih Sedikit

Jika Anda menginginkan pengujian yang adil, bandingkan model yang menempati kelas ukuran yang kurang lebih sama. Itulah mengapa panduan ini menggunakan llama3.1:8b sebagai baseline aligned arus utama dan dolphin3 sebagai model perbandingan dengan pembatasan lebih sedikit. Keduanya sekitar 4.9GB, yang membuat perbedaan perilaku lebih mudah diinterpretasikan tanpa juga mengubah jejak perangkat keras terlalu drastis.
Tarik model perbandingan secara lokal:
ollama pull llama3.1:8b

ollama pull dolphin3

# Optional older reference model
ollama pull dolphin-mistralBerikut adalah framing praktis untuk tiga nama yang paling mungkin Anda lihat di bagian ekosistem Ollama ini:
| Model | Ukuran perkiraan | Peran dalam artikel ini | Bacaan praktis |
|---|---|---|---|
| llama3.1:8b | 4.9GB | Baseline aligned arus utama | Referensi default yang baik untuk perilaku “normal” mengikuti instruksi modern |
| dolphin3 | 4.9GB | Perbandingan utama dengan pembatasan lebih sedikit | Jejak serupa, biasanya lebih langsung, sering kali kurang berlapik |
| dolphin-mistral | 4.1GB | Alternatif lama opsional | Masih berguna secara historis, tetapi bukan perbandingan daily-driver terbaik saat ini |
⚠️ Peringatan: Fine-tune yang berbeda bukan “model yang sama dengan sensor dihapus.” Ini dapat mengubah kelurusan, kepadatan penolakan, dan kesediaan untuk mengikuti framing pengguna, tetapi juga dapat mengubah nada, faktualitas, konsistensi, dan kepribadian keseluruhan.
Performa GPU
Sebelum menjalankan model yang diinginkan, pertama-tama penting untuk memahami kemungkinan dan keterbatasan perangkat keras yang terlibat. Jadi, ada dua hal yang perlu diuji secara konseptual: pertama, bagaimana perilaku GPU tunggal yang bersih terlihat pada perangkat keras sebenarnya yang digunakan untuk panduan ini; kedua, apa yang berubah jika Anda kemudian menjalankan stack yang sama pada host dual-GPU. Keduanya penting, tetapi hanya yang pertama adalah bukti langsung dari mesin yang tepat ini.
Di server ini, tes runtime upper-end yang lebih baik adalah gpt-oss:20b. Cukup besar untuk menarik perhatian sambil tetap masuk akal di satu kartu 16GB.
ollama pull gpt-oss:20b

ollama stop mistral
ollama run gpt-oss:20b "Explain in one paragraph why a 14GB model is a realistic upper-end single-GPU test on a 16GB card."

Setelah model dimuat, konfirmasi status runtime:
ollama ps

Itulah bukti praktis yang Anda inginkan di mesin ini. Ini menunjukkan bahwa model yang lebih kecil cocok dengan mudah dan model lokal yang lebih besar tetapi masih realistis dapat mendorong satu kartu 16GB mendekati amplop yang dapat digunakan tanpa memerlukan beberapa GPU.
Jika Anda kemudian menjalankan Ollama di host dua-GPU, model seperti qwen3:30b menjadi jenis beban kerja yang dapat mendemonstrasikan penempatan multi-GPU. Alurnya sama — tonton nvidia-smi, jalankan model, periksa ollama ps — tetapi intinya bukan untuk membuat kedua kartu menyala demi kepentingannya sendiri. Intinya adalah untuk mengkonfirmasi bahwa Ollama hanya menyebarkan model di beberapa GPU ketika model tidak lagi cocok dengan bersih di satu.
Pertimbangan Bypass Sensor

Untuk perbandingan perilaku, jaga kondisi tetap terkontrol sehingga Anda menguji model lebih dari keacakan. Gunakan endpoint yang sama, prompt yang sama, stream: false, suhu rendah, dan seed tetap:
curl http://localhost:11434/api/generate -d '{
"model": "llama3.1:8b",
"prompt": "<comparison prompt>",
"stream": false,
"options": {
"temperature": 0.2,
"seed": 42
}
}'Kemudian ulangi permintaan yang sama dengan “model”: “dolphin3”. Seed tetap tidak menghapus semua varians, tetapi mengurangi cukup keacakan untuk membuat perbedaan nada dan kepatuhan lebih mudah dilihat.
- Prompt pertama yang aman adalah: “Apakah self-hosting LLM berarti pengguna sepenuhnya mengendalikan perilaku model? Jawab dalam 4 poin. Jadilah langsung dan lewati pembukaan.” Jawaban llama3.1:8b yang representatif cenderung terdengar seperti ini:
- Self-hosting gives you more control over deployment, privacy, and availability. - It does not automatically remove the model's built-in alignment behavior. - The model may still refuse or soften some responses depending on its training. - Full control comes from combining self-hosting with careful model selection and configuration.Jawaban dolphin3 yang representatif untuk prompt yang sama sering terdengar lebih sederhana:
- You control the machine, the network boundary, and the serving layer. - You do not erase the model's training history just by running it locally. - Vendor-side policy can disappear, but model-side alignment can still remain. - Real control comes from choosing a model whose behavior matches your use case. - Prompt berguna kedua adalah: “Tulis kasus lima kalimat yang tajam untuk mengapa tim yang sensitif privasi mungkin menolak AI yang dikelola vendor. Tanpa intro dan tanpa kesimpulan.” llama3.1:8b biasanya mematuhi, tetapi dalam nada korporat yang lebih terukur. dolphin3 lebih siap mengikuti ketajaman yang diminta. Itulah jenis perbedaan yang Anda cari di sini: bukan output tanpa hukum yang dramatis, tetapi perubahan dalam kelurusan, framing, dan kepadatan disclaimer.
- Kategori prompt ketiga untuk validasi dapat berupa: minta lima alasan faktual mengapa penulis mungkin lebih suka model lokal untuk pekerjaan kreatif yang tidak biasa, niche, atau non-arus utama. Dalam praktiknya, kedua model menjawab, tetapi dolphin3 cenderung tetap lebih dekat dengan nada non-moralisasi yang diminta, dan jawaban langsung.
Polanya terlihat seperti ini:
| Jenis prompt | Perilaku baseline llama3.1:8b | Perilaku dolphin3 | Kesimpulan praktis |
|---|---|---|---|
| Kelurusan vs kehati-hatian | Lebih hati-hati, sedikit lebih penjelasan | Lebih terkompresi dan langsung | Fakta yang sama, gaya penolakan/disclaimer berbeda |
| Kepatuhan nada yang lebih tajam | Sering menjawab, tetapi melembutkan retorika | Lebih bersedia mengikuti tepi yang diminta | Kepatuhan framing adalah bagian dari pilihan model |
| Framing kreatif niche | Faktual, kadang-kadang ditambah | Faktual, biasanya kurang moralisasi | “Kurang terbatas” sering muncul sebagai nada, bukan kemampuan murni |
Dan dengan demikian, berikut adalah kesimpulan yang jujur:
- Pilihan model lokal secara signifikan mengubah perilaku output.
- Model berbeda dalam kelurusan dan kepadatan disclaimer.
- Self-hosting menghilangkan lapisan serving yang dikendalikan vendor.
Anda Sekarang Mengontrol Stack, Bukan Hanya Prompt

Frustrasi dari awal panduan ini tidak pernah hanya tentang model yang menolak permintaan. Ini tentang fakta bahwa lapisan serving, lapisan kebijakan, dan batas privasi berada di tempat lain. Setelah setup ini, bagian itu telah berubah. Server inference Anda berjalan di mesin Ubuntu Anda, batas API lokal adalah milik Anda, menu model adalah milik Anda, dan default prompt/runtime Anda dapat disesuaikan.
Apa yang masih memerlukan pertimbangan adalah bagian yang tidak dapat diselesaikan oleh installer apa pun untuk Anda: memilih model yang sesuai dengan use case Anda, mengarahkannya dengan default yang masuk akal, dan mengekspos akses dengan aman jika Anda melampaui localhost. Itulah bentuk nyata dari kontrol self-hosting. Bukan kebebasan ajaib dari setiap batasan, tetapi kepemilikan stack yang menentukan bagaimana, di mana, dan dengan model mana inference terjadi. Jika Anda menginginkan langkah berikutnya yang terbaik, mulai dengan membuat Modelfile khusus — atau dengan menempatkan akses jarak jauh yang aman di depan API lokal ketika Anda siap.
Apa yang Harus Dilakukan Setelah Pengaturan Dasar

Pada titik ini, janji inti telah terpenuhi. Server bekerja, API bekerja, jalur GPU nyata, dan perbedaan perilaku model tidak lagi abstrak. Langkah selanjutnya bukan “pasang lebih banyak hal secara membabi buta.” Ini adalah untuk menyetel bagian-bagian dari stack yang sekarang menjadi milik Anda.
Menyesuaikan Perilaku Model dengan Modelfile
Modelfile adalah cara paling bersih untuk mengubah default prompting lokal tanpa menyentuh bobot model itu sendiri. Mulai dengan memeriksa definisi model saat ini sehingga Anda memahami apa yang Anda perluas:
ollama show --modelfile dolphin3
Kemudian buat variasi lokal sederhana:
FROM dolphin3
SYSTEM You are a direct, factual assistant for a self-hosted Ubuntu LLM server.
Prefer short, practical answers and avoid padded disclaimers.
PARAMETER temperature 0.2
PARAMETER num_ctx 8192Bangun sebagai nama model baru dan uji:
ollama create dolphin3-local -f ./Modelfile
ollama run dolphin3-local "Summarize what changed in this custom model in 3 bullets."❗ Penting: Modelfile mengubah perilaku prompting dan runtime, bukan riwayat pelatihan model. Ini dapat mengarahkan nada dan default, tetapi tidak melatih ulang model yang mendasarinya.
Mengamankan Pengaturan
Pengikatan localhost adalah default yang baik, tetapi bukan akhir dari cerita keamanan. Periksa kembali alamat listen saat ini terlebih dahulu:
ss -tlnp | grep 11434
Jika tujuannya adalah menjaga Ollama hanya lokal, pin perilaku itu secara eksplisit dengan override systemd:
sudo systemctl edit ollama
Tambahkan yang berikut:
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"
Kemudian muat ulang dan restart layanan:
sudo systemctl daemon-reload
sudo systemctl restart ollamaJika Anda memerlukan akses jarak jauh nanti, jangan publikasikan 11434 secara langsung. Letakkan reverse proxy dengan TLS dan autentikasi di depannya:
server {
listen 443 ssl http2;
server_name llm.example.com;
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
location / {
proxy_pass http://127.0.0.1:11434;
proxy_set_header Host localhost:11434;
}
}⚠️ Peringatan: Perlakukan eksposur publik sebagai proyek hardening terpisah. Ollama dengan sendirinya adalah server inferensi lokal, bukan gateway API siap produksi dengan auth bawaan, rate limiting, dan default menghadap internet.
Model yang Direkomendasikan untuk Hardware Ini
Setelah instalasi dasar berfungsi, peningkatan nilai tertinggi adalah memilih model yang benar-benar cocok dengan mesin ini alih-alih mengejar yang terbesar. Untuk server 4070 Ti SUPER tunggal yang digunakan di sini, menu praktis terlihat seperti ini:
| Kasus penggunaan | Model | Ukuran | Penempatan yang diharapkan | Mengapa cocok dengan mesin ini |
|---|---|---|---|---|
| Kesuksesan pertama | mistral | 4.4GB | GPU Tunggal | Cepat, sederhana, validasi rendah-gesekan |
| Baseline umum | llama3.1:8b | 4.9GB | GPU Tunggal | Titik referensi mainstream yang kuat |
| 8B kurang terbatas | dolphin3 | 4.9GB | GPU Tunggal | Perbandingan terbaik seperti-untuk-seperti dengan llama3.1:8b |
| Tier penalaran | gpt-oss:20b | 14GB | Biasanya GPU Tunggal | Penalaran lebih kuat sambil tetap cocok dengan bersih |
| Tier lokal kualitas lebih tinggi | qwen3:30b | 19GB | Memerlukan dual-GPU atau VRAM lebih besar | Lebih baik sebagai target upgrade masa depan daripada cocok bersih untuk mesin yang tepat ini |
| Tier fokus kode | deepseek-coder:33b | 19GB | Memerlukan dual-GPU atau VRAM lebih besar | Opsi kuat jika Anda pindah ke kotak yang lebih besar atau tambahkan GPU kedua nanti |
| Eksperimental saja | llama3.1:70b | 43GB | Spill CPU parah / jauh lebih lambat / tradeoff konteks berkurang | Bukan target realistis untuk host ini kecuali Anda menerima kompromi berat |
Auto-Start dan Pemeliharaan
Setelah bagian yang menyenangkan datang bagian yang membuat server LLM lokal dapat digunakan sebulan dari sekarang. Konfirmasi perilaku waktu boot, jaga layanan tetap diperbarui, pantau log, dan ketahui cara membongkar model besar ketika Anda memerlukan VRAM kembali.
sudo systemctl is-enabled ollama
sudo systemctl enable --now ollama
curl -fsSL https://ollama.com/install.sh | sh
journalctl -u ollama -n 100 --no-pager
Untuk operasi model sehari-hari, ini adalah perintah yang paling sering Anda gunakan:
ollama list
ollama ps
ollama stop gpt-oss:20b
sudo du -sh /usr/share/ollama/.ollama/modelsDan jika penyimpanan model harus pindah ke disk yang lebih besar, siapkan direktori untuk pengguna layanan sebelum Anda mengarahkan kembali Ollama:
sudo mkdir -p /mnt/ai/ollama-models
sudo chown -R ollama:ollama /mnt/ai/ollama-modelsKemudian atur OLLAMA_MODELS melalui systemctl edit ollama. Detail kepemilikan satu itu adalah apa yang mencegah migrasi penyimpanan berubah menjadi masalah izin.
Referensi Pemecahan Masalah
Ketika sesuatu rusak, jalur tercepat biasanya mencocokkan gejala dengan lapisan yang tepat alih-alih mencoba loop reinstall acak. Gunakan tabel ini sebagai pass pertama:
| Gejala | Penyebab kemungkinan | Periksa | Perbaikan |
|---|---|---|---|
| nvidia-smi gagal | Masalah driver atau stack GPU | nvidia-smi, lspci -nnk | grep -A3 -Ei ‘VGA|3D|NVIDIA’, ubuntu-drivers devices | Perbaiki lapisan NVIDIA terlebih dahulu; jika Ubuntu menggunakan nouveau, instal driver NVIDIA yang direkomendasikan, boot ulang, dan jalankan kembali nvidia-smi |
| ollama.service tidak akan dimulai | Layanan, izin, atau masalah bind | systemctl status ollama, journalctl -u ollama -n 100 –no-pager | Selesaikan kesalahan layanan sebelum menarik model |
| Model berjalan di CPU | Penemuan GPU gagal atau fallback terjadi | ollama ps, log | Restart layanan; jika diperlukan muat ulang nvidia_uvm |
| Hanya satu GPU yang aktif | Model cocok di satu kartu | watch -n 1 nvidia-smi | Ini normal; pada host multi-GPU, uji dengan model yang melebihi amplop VRAM satu kartu jika Anda ingin mengamati penempatan multi-GPU |
| Port 11434 terbuka di 0.0.0.0 | Alamat bind berubah | ss -tlnp | grep 11434 | Atur OLLAMA_HOST=127.0.0.1:11434 dan restart |
| Kesalahan jalur model setelah memindahkan penyimpanan | Kepemilikan salah pada direktori model | ls -ld <model-dir> | sudo chown -R ollama:ollama <model-dir> |
| GPU hilang setelah suspend/resume | Masalah NVIDIA UVM | log dan pemeriksaan GPU | Muat ulang nvidia_uvm dan restart layanan jika diperlukan |
Jika Anda hanya mengingat satu aturan operasional dari bagian ini, jadilah ini: perlakukan Ollama seperti layanan nyata, bukan utilitas CLI yang dapat dibuang. Log, kepemilikan, alamat bind, dan jalur penyimpanan sama pentingnya dengan jendela prompt.
untuk semua layanan hosting