LLM on kenji.blog

Cara Tercepat Melakukan Tuning TinyLLaMA di Lingkungan On-Premises

Fri, 11 Sep 2026 16:00:00 +0900

1. Pendahuluan: Mengapa Harus TinyLLaMA dan On-Premises Saat Ini?

Evolusi Large Language Models (LLM) berlangsung dengan kecepatan yang luar biasa, dan seiring dengan itu, jumlah parameter model terus membengkak hingga skala ratusan miliar. Di satu sisi, model super raksasa seperti GPT-4 dan Claude 3 membanggakan kinerja yang tak tertandingi, namun biaya komputasi yang dibutuhkan untuk inferensi dan pelatihan, serta kekhawatiran tentang keamanan dan privasi data saat menggunakan API eksternal menjadi hambatan besar bagi perusahaan. Terutama dalam tugas-tugas yang menangani data internal yang sangat rahasia dan informasi pribadi, mengirimkan data ke API LLM publik di cloud sering kali tidak dapat diterima dari sudut pandang kepatuhan (seperti GDPR dan APPI).

Oleh karena itu, yang kini menjadi sorotan adalah Small Language Models (SLM) dan pengoperasian lokal di lingkungan on-premises. Di antaranya, “TinyLLaMA” hadir dengan ukuran yang ringkas yaitu hanya 1.1B (1,1 miliar) parameter, namun telah melalui pre-training dengan dataset yang sangat besar yaitu sekitar 3 triliun token, sehingga menunjukkan kinerja yang luar biasa dibandingkan dengan model di kelasnya.

Artikel ini menyediakan panduan lengkap untuk melakukan fine-tuning (penyesuaian) TinyLLaMA agar menjadi “tercepat dan berefisiensi tinggi” untuk tugas-tugas khusus perusahaan Anda di lingkungan on-premises (server lokal atau workstation). Kami akan menjelaskan secara komprehensif mulai dari latar belakang matematis, teknologi optimasi terbaru, hingga kode implementasi PyTorch secara spesifik.

2. Arsitektur dan Karakteristik TinyLLaMA

TinyLLaMA mengikuti arsitektur LLaMA (Large Language Model Meta AI) yang dikembangkan oleh Meta. Meskipun jumlah parameternya ditekan menjadi 1.1B, ia menggunakan tumpukan teknologi yang sama dengan LLaMA 2, sehingga memiliki kompatibilitas ekosistem yang sangat tinggi.

Komponen Arsitektur Utama

RMSNorm (Root Mean Square Normalization): Ini adalah metode normalisasi yang menghilangkan pengurangan rata-rata dari perhitungan LayerNorm konvensional, sehingga meningkatkan efisiensi komputasi. Metode ini menjaga stabilitas pelatihan sekaligus meningkatkan throughput.
Fungsi Aktivasi SwiGLU: Dalam Feed Forward Network (FFN), SwiGLU diadopsi menggantikan ReLU dan GELU konvensional. Secara matematis dapat dinyatakan sebagai berikut: $$ \text{SwiGLU}(x, W, V) = \text{Swish}(xW) \otimes (xV) $$ Di sini, $\otimes$ melambangkan perkalian elemen-demi-elemen (Hadamard product), dan fungsi Swish adalah $\text{Swish}(z) = z \cdot \sigma(\beta z)$. Hal ini secara signifikan meningkatkan daya ekspresi model.
RoPE (Rotary Position Embedding): Ini adalah metode yang menggabungkan keuntungan dari positional encoding absolut dan relatif. Metode ini memiliki kemampuan generalisasi yang tinggi bahkan ketika panjang urutan diperluas.
Grouped Query Attention (GQA): Ini adalah pendekatan perantara antara Multi-Head Attention (MHA) dan Multi-Query Attention (MQA). Dengan mengelompokkan head key dan value, metode ini menghemat bandwidth memori dan secara dramatis meningkatkan kecepatan inferensi.

Diagram Mermaid berikut menunjukkan aliran data keseluruhan dan struktur blok Transformer dari TinyLLaMA.

graph TD A["Teks Input"] --> B["Tokenizer (BPE)"] B --> C["Lapisan Embedding"] C --> D["Blok Transformer (x22 Lapisan untuk TinyLLaMA)"] D --> E["RMSNorm (Akhir)"] E --> F["Proyeksi Linear (Ukuran Kosakata)"] F --> G["Probabilitas Output (Softmax)"] subgraph "Anatomi Blok Transformer" D1["Hidden State Input"] --> D2["RMSNorm"] D2 --> D3["Grouped Query Attention (GQA)"] D3 --> D4["Residual Add"] D4 --> D5["RMSNorm"] D5 --> D6["SwiGLU FFN"] D6 --> D7["Residual Add"] D7 --> D8["Output ke Lapisan Berikutnya"] D1 -.-> D4 D4 -.-> D7 end

3. Terobosan Fine-Tuning: LoRA dan QLoRA

Untuk melakukan fine-tuning pada seluruh parameter di lingkungan on-premises, bahkan untuk model 1.1B, model tersebut akan mengonsumsi puluhan GB VRAM (memori video) untuk menyimpan status optimizer dan gradien. Agar dapat melakukan pelatihan secara efisien dengan sumber daya yang terbatas, teknik PEFT (Parameter-Efficient Fine-Tuning), yaitu “LoRA” dan ekstensi kuantisasinya “QLoRA”, menjadi sangat penting.

3.1 Latar Belakang Matematis LoRA (Low-Rank Adaptation)

LoRA adalah metode yang mengunci (freeze) matriks bobot yang telah dilatih sebelumnya (pre-trained), dan memperkirakan jumlah pembaruan bobot tersebut ($\Delta W$) sebagai hasil perkalian dari dua matriks kecil berpangkat rendah (low-rank).

Misalkan bobot pre-trained adalah $W_0 \in \mathbb{R}^{d \times k}$. Pada full fine-tuning, $W_0$ itu sendiri diperbarui menjadi $W_0 + \Delta W$, namun pada LoRA, matriks pembaruan $\Delta W$ didekomposisi sebagai berikut:

$$ \Delta W = B \times A $$

Di sini, $B \in \mathbb{R}^{d \times r}$ dan $A \in \mathbb{R}^{r \times k}$, di mana $r$ adalah hyperparameter yang disebut rank, dengan nilai yang sangat kecil (biasanya 8, 16, 32, dll.) yang memenuhi $r \ll \min(d, k)$.

Perhitungan forward pass adalah sebagai berikut:

$$ h = W_0 x + \Delta W x = W_0 x + B A x $$

Pada keadaan awal, matriks $A$ diinisialisasi secara acak menggunakan distribusi normal (distribusi Gaussian), dan matriks $B$ diinisialisasi sebagai matriks nol. Akibatnya, nilai $\Delta W$ pada awal pelatihan adalah nol, memungkinkan dimulainya pelatihan dengan output dari model dasar yang dipertahankan sepenuhnya.

graph LR X["Vektor Input x"] --> W0["Bobot Pre-trained Beku (W_0)"] X --> A["Matriks LoRA A yang Dapat Dilatih (r x k)"] A --> B["Matriks LoRA B yang Dapat Dilatih (d x r)"] W0 --> Add["Penambahan Vektor"] B --> Add Add --> Y["Vektor Output h"]

3.2 Inovasi QLoRA (Quantized LoRA)

QLoRA mendorong pendekatan LoRA lebih jauh, dengan melakukan kuantisasi pada model dasar $W_0$ ke dalam presisi 4-bit (NormalFloat 4, NF4) sebelum dimuat ke dalam memori. Hal ini secara dramatis mengurangi konsumsi VRAM.

Ada tiga teknologi penting yang terintegrasi di dalam QLoRA:

Kuantisasi 4-bit NormalFloat (NF4): Tipe data yang secara teoritis optimal untuk bobot yang mengikuti distribusi normal.
Double Quantization (Kuantisasi Ganda): Mengkuantisasi konstanta kuantisasi itu sendiri (scale factor) untuk menghemat memori lebih lanjut.
Paged Optimizers: Menggunakan fitur memori terpadu NVIDIA untuk sementara waktu memindahkan status optimizer ke RAM CPU saat VRAM hampir habis.

Dengan ini, tuning yang biasanya membutuhkan 16GB hingga 24GB VRAM dapat dijalankan dengan nyaman bahkan pada GPU kelas konsumen (seperti RTX 3060 12GB atau RTX 4070).

4. Persyaratan Perangkat Keras dan Pengaturan di Lingkungan On-Premises

Persyaratan perangkat keras untuk melakukan tuning TinyLLaMA (1.1B) dengan QLoRA dapat ditekan sangat rendah.

Spesifikasi Perangkat Keras yang Disarankan

GPU: NVIDIA RTX 3060 (12GB), RTX 3090/4090 (24GB), atau NVIDIA A10G/A100, dll. Meskipun VRAM 8GB adalah batas minimal untuk berjalan, disarankan memiliki 12GB atau lebih untuk mengakomodasi ukuran batch (batch size) yang memadai.
CPU: CPU modern 8 core atau lebih (Intel Core i7/i9, AMD Ryzen 7/9)
RAM: 32GB atau lebih (penting sebagai tujuan pemindahan data dari VRAM saat menggunakan Paged Optimizers)
Penyimpanan: NVMe SSD (untuk mempercepat pemuatan dataset dan penyimpanan model)

Membangun Lingkungan Perangkat Lunak

Langkah-langkah berikut mengasumsikan lingkungan Ubuntu 22.04 LTS. Python 3.10 atau versi yang lebih baru akan digunakan.

1
2
3
4
5
6
7
8
9


# Membuat dan mengaktifkan lingkungan virtual (virtual environment)
python3 -m venv tinyllama_env
source tinyllama_env/bin/activate

# Menginstal PyTorch (untuk CUDA 12.1)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# Menginstal pustaka terkait Transformer
pip install transformers datasets peft trl accelerate bitsandbytes

5. Teknik Optimasi untuk Tuning Tercepat

Untuk menyelesaikan tuning dengan “kecepatan maksimum”, tidak cukup hanya dengan menjalankan skrip; teknik optimasi berikut harus dikombinasikan.

5.1 Flash Attention 2

Mekanisme Attention standar memiliki kompleksitas waktu dan ruang $O(N^2)$ terhadap panjang urutan $N$. Flash Attention 2 mengoptimalkan akses memori antara SRAM dan HBM (High Bandwidth Memory) pada GPU, mengurangi hambatan I/O tanpa mengurangi jumlah komputasi. Ini meningkatkan kecepatan pelatihan beberapa kali lipat dan secara drastis mengurangi konsumsi memori.

5.2 Gradient Checkpointing

Alih-alih menyimpan semua aktivasi perantara yang dihitung selama forward pass ke dalam VRAM, metode ini hanya menyimpan sebagian dan menghitung ulang sisanya jika diperlukan saat backward pass. Meskipun waktu komputasi meningkat sekitar 20%, konsumsi memori berkurang secara drastis. Hasilnya, Anda dapat mengatur ukuran batch yang lebih besar, dan meningkatkan throughput secara keseluruhan.

5.3 Pelatihan Presisi Campuran (Mixed Precision Training) dan Bfloat16

Untuk memaksimalkan penggunaan Tensor Core pada GPU, komputasi selama pelatihan dilakukan dengan tipe data bfloat16 (Brain Floating Point). Dibandingkan dengan float16, bfloat16 memiliki panjang bit eksponen yang sama dengan float32, sehingga risiko overflow dan underflow sangat rendah, menjadikan pelatihan lebih stabil.

6. Praktik: Kode Fine-Tuning QLoRA untuk TinyLLaMA

Selanjutnya, kami akan menjelaskan skrip PyTorch untuk tuning tercepat yang mencakup semua optimasi di atas. Di sini, kami menggunakan SFTTrainer dari pustaka trl (Transformer Reinforcement Learning) oleh Hugging Face.

6.1 Persiapan Dataset dan Pemuatan Model

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


import torch
from datasets import load_dataset
from transformers import (
 AutoModelForCausalLM,
 AutoTokenizer,
 BitsAndBytesConfig,
 TrainingArguments
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

# 1. Menentukan model dan tokenizer
model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# 2. Pengaturan kuantisasi 4-bit untuk QLoRA
bnb_config = BitsAndBytesConfig(
 load_in_4bit=True,
 bnb_4bit_use_double_quant=True,
 bnb_4bit_quant_type="nf4",
 bnb_4bit_compute_dtype=torch.bfloat16 # Komputasi dilakukan dalam bfloat16
)

# 3. Memuat model (Mengaktifkan Flash Attention 2)
print("Loading model...")
model = AutoModelForCausalLM.from_pretrained(
 model_id,
 quantization_config=bnb_config,
 device_map="auto",
 use_flash_attention_2=True # Kunci percepatan maksimal
)

# 4. Memuat tokenizer
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right" # Diatur ke right untuk menghindari bug selama pelatihan fp16/bf16

6.2 Penerapan Adaptor LoRA dan Pemformatan Dataset

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# 5. Persiapan untuk pelatihan k-bit dan aktivasi gradient checkpointing
model.gradient_checkpointing_enable()
model = prepare_model_for_kbit_training(model)

# 6. Pengaturan LoRA
peft_config = LoraConfig(
 r=16, # Rank
 lora_alpha=32, # Scaling factor
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] # Menerapkannya ke semua layer Linear meningkatkan kinerja
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()
# Contoh output: trainable params: 14,286,848 || all params: 1,114,335,232 || trainable%: 1.282%

# 7. Memuat dataset (Di sini menggunakan dataset instruksi bahasa Jepang sebagai contoh)
# Dalam praktiknya, Anda memuat file JSONL privat dari on-premises, dll.
dataset = load_dataset("kunishou/databricks-dolly-15k-ja", split="train")

def format_instruction(sample):
 """
 Memformat string agar sesuai dengan format ChatML atau template prompt
 """
 prompt = f"<|im_start|>user\n{sample['instruction']}"
 if sample.get("input", "") != "":
 prompt += f"\n{sample['input']}"
 prompt += f"<|im_end|>\n<|im_start|>assistant\n{sample['output']}<|im_end|>"
 return {"text": prompt}

dataset = dataset.map(format_instruction)

6.3 Pelaksanaan Pelatihan

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


# 8. Pengaturan parameter pelatihan
training_args = TrainingArguments(
 output_dir="./tinyllama-lora-output",
 per_device_train_batch_size=8, # Naikkan jika VRAM Anda memungkinkan
 gradient_accumulation_steps=2, # Ukuran batch efektif = 8 * 2 = 16
 optim="paged_adamw_32bit", # Menghemat VRAM dengan Paged Optimizer
 save_steps=100,
 logging_steps=10,
 learning_rate=2e-4,
 fp16=False,
 bf16=True, # Pelatihan presisi campuran (bfloat16)
 max_grad_norm=0.3,
 max_steps=500, # 500 langkah untuk tujuan pengujian. Pada produksi, tentukan dengan epoch
 warmup_ratio=0.03,
 group_by_length=True,
 lr_scheduler_type="cosine",
)

# 9. Memulai pelatihan menggunakan SFTTrainer
trainer = SFTTrainer(
 model=model,
 train_dataset=dataset,
 peft_config=peft_config,
 dataset_text_field="text",
 max_seq_length=1024, # Sesuaikan dengan panjang input yang diharapkan
 tokenizer=tokenizer,
 args=training_args,
)

print("Starting training...")
trainer.train()

# 10. Menyimpan adaptor LoRA
trainer.model.save_pretrained("./tinyllama-lora-final")
tokenizer.save_pretrained("./tinyllama-lora-final")
print("Training complete and model saved.")

7. Evaluasi Kinerja dan Pemecahan Masalah (Troubleshooting)

Berikut adalah masalah umum yang sering dihadapi saat menjalankan pelatihan di lingkungan on-premises beserta solusinya.

Terjadinya OOM (Out Of Memory):
- Turunkan nilai per_device_train_batch_size menjadi 1.
- Tingkatkan gradient_accumulation_steps untuk mempertahankan ukuran batch efektif.
- Persingkat max_seq_length dari 2048 menjadi 1024 atau 512.
Loss Tidak Menurun atau Mengalami Divergensi:
- Kecepatan pembelajaran (learning_rate) mungkin terlalu besar. Coba turunkan dari 2e-4 menjadi sekitar 5e-5.
- Jika Anda menggunakan Float16 dan bukan Bfloat16, gradien underflow mungkin sedang terjadi. Pastikan nilai bf16=True.
String Aneh Muncul Saat Inferensi:
- Pastikan bahwa padding_side="right" telah diatur dengan benar. Selain itu, Anda perlu memverifikasi apakah format dataset (seperti token khusus <|im_start|>) sejalan dengan yang digunakan selama pre-training model dasar.

8. Penerapan (Deployment) Model Setelah Tuning

Setelah tuning selesai, yang disimpan bukanlah “keseluruhan model dasar”, melainkan hanya “Adaptor LoRA (bobot diferensial)” yang berukuran beberapa MB hingga puluhan MB. Untuk melakukan inferensi berkecepatan tinggi, bobot LoRA ini perlu digabungkan (di-merge) ke dalam model dasar asli dan diekspor sebagai model tunggal.

Skrip Penggabungan Model

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import torch
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer

output_dir = "./tinyllama-lora-final"

# Memuat model dan adaptor dalam FP16/BF16
model = AutoPeftModelForCausalLM.from_pretrained(
 output_dir,
 device_map="auto",
 torch_dtype=torch.bfloat16
)
tokenizer = AutoTokenizer.from_pretrained(output_dir)

# Menggabungkan bobot dan menyimpannya
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./tinyllama-merged", safe_serialization=True)
tokenizer.save_pretrained("./tinyllama-merged")
print("Model merged and saved successfully!")

Meluncurkan Server Inferensi Kecepatan Tinggi Menggunakan vLLM

Untuk penerapan di lingkungan on-premises, guna memaksimalkan kecepatan inferensi (Tokens per second), kami sangat menyarankan untuk tidak menggunakan pipeline bawaan Hugging Face, melainkan menggunakan vLLM atau TGI (Text Generation Inference). vLLM memanfaatkan teknologi PagedAttention untuk mencegah fragmentasi memori GPU, secara drastis meningkatkan kapasitas pemrosesan permintaan bersamaan (concurrent requests).

Diagram Mermaid berikut mengilustrasikan pipeline dari pelatihan hingga penerapan server inferensi.

graph TD A["Data Privat Mentah"] --> B["Pra-pemrosesan & Pemformatan (JSONL)"] B --> C["QLoRA Fine-Tuning (SFTTrainer)"] C --> D["Bobot Adaptor LoRA (.safetensors)"] D --> E["Gabung dengan Base TinyLLaMA 1.1B"] E --> F["Model Gabungan"] F --> G["Terapkan via Server vLLM"] G --> H["Endpoint API / UI (misalnya Chatbot)"]

Menjalankan server API menggunakan vLLM dapat diselesaikan hanya dengan satu perintah berikut.

1
2
3
4
5
6


python -m vllm.entrypoints.openai.api_server \
 --model ./tinyllama-merged \
 --host 0.0.0.0 \
 --port 8000 \
 --max-model-len 2048 \
 --dtype bfloat16

Dengan ini, sebuah endpoint yang kompatibel dengan API OpenAI dibangun di lingkungan on-premises, memungkinkan pemanfaatan AI lokal secara aman dan berkecepatan tinggi.

9. Kesimpulan

Artikel ini menjelaskan metode fine-tuning tercepat dan paling hemat memori di lingkungan on-premises untuk “TinyLLaMA”, sebuah model yang ringan dengan 1.1B parameter namun berkinerja tinggi.

Dengan LoRA / QLoRA, tuning LLM berskala penuh dapat dilakukan bahkan dengan GPU kelas konsumen.
Dengan memanfaatkan Flash Attention 2 dan Gradient Checkpointing secara optimal, waktu pelatihan dan konsumsi VRAM diminimalkan secara ekstrem.
Penerapan yang memanfaatkan vLLM memungkinkan tercapainya throughput yang tinggi bahkan di lingkungan produksi.

Pengoperasian LLM lokal secara on-premises tidak hanya melindungi kerahasiaan data, tetapi juga menjadi senjata terkuat untuk membangun AI khusus pada domain tertentu (hukum, medis, peraturan internal, dll.) dengan biaya rendah. Kami berharap Anda dapat menggunakan panduan ini untuk melatih TinyLLaMA khusus perusahaan Anda.

Panduan Pengembangan Model AI Skala Kecil (seperti TinyLLaMA) Menggunakan C++

Fri, 11 Sep 2026 14:00:00 +0900

Panduan Pengembangan Model AI Skala Kecil (seperti TinyLLaMA) Menggunakan C++

Baru-baru ini, minat terhadap eksekusi model bahasa besar (LLM) di lingkungan lokal telah meningkat secara pesat. Secara khusus, model berskala kecil seperti TinyLLaMA (1.1B parameter) dapat diinferensi dengan kecepatan praktis bahkan pada perangkat edge dengan sumber daya terbatas atau laptop umum (termasuk lingkungan Windows). Sementara pengembangan menggunakan Python dan PyTorch adalah arus utama, ketika mengejar kinerja dan efisiensi memori terbaik, kombinasi C++ dan pustaka tensor berbasis C, “ggml”, telah menjadi standar de facto.

Artikel ini akan menjelaskan secara rinci prosedur pengembangan (atau pemahaman mendalam tentang struktur internal llama.cpp yang sudah ada) untuk membangun mesin inferensi dari awal guna memuat TinyLLaMA dan melakukan pembuatan teks menggunakan C++.

1. Mengapa C++ dan ggml?

Dalam tahap pelatihan AI, Python sangat diuntungkan dengan fleksibilitas dan ekosistemnya yang kaya. Namun, dalam fase penerapan dan “Inferensi”, C++ menjadi pilihan yang kuat karena alasan berikut:

Pengurangan Overhead: Global Interpreter Lock (GIL) Python dan overhead runtime dapat dihilangkan sepenuhnya.
Efisiensi Memori dan Alokasi Arena: Karena alokasi dan dealokasi memori dapat dikontrol secara manual, lonjakan yang tidak dapat diprediksi akibat garbage collection dapat dicegah.
Akses Langsung ke Perangkat Keras: Dapat langsung memanggil fungsi bawaan SIMD (Intrinsics) seperti AVX-512, AVX2, dan ARM NEON untuk memaksimalkan kemampuan komputasi CPU.
Tanpa Dependensi: ggml adalah pustaka C/C++ dengan nol dependensi (Zero dependencies), yang dapat dengan mudah dibangun bahkan di lingkungan MSVC di Windows asalkan ada kompilator.

2. Gambaran Keseluruhan Arsitektur

Alur dari seluruh pipeline inferensi ditunjukkan dalam diagram Mermaid di bawah ini. Ini adalah serangkaian proses mulai dari teks masukan pengguna hingga pembuatan token berikutnya.

graph TD A["Teks Masukan Pengguna"] --> B["BPE Tokenizer"] B --> C["Array ID Token"] C --> D["Pencarian Lapisan Embedding"] D --> E["Blok Transformer"] E --> F["RMSNorm"] F --> G["Lapisan LM Head"] G --> H["Array Logit"] H --> I["Modul Sampler"] I --> J["ID Token Berikutnya"] J --> K["Detokenizer"] K --> L["Potongan Teks Keluaran"] J -.-> |"Tambahkan ke Konteks"| C

Karena ini adalah model auto-regresif, token yang dihasilkan ditambahkan kembali ke konteks dan disirkulasikan sebagai masukan untuk memprediksi token berikutnya (bagian garis putus-putus pada diagram).

3. Format Model dan Pemetaan Memori (mmap)

Kendala terbesar dalam menangani bobot jaringan saraf yang sangat besar adalah operasi I/O disk dan konsumsi memori. Implementasi C++ menyelesaikan masalah ini dengan pemetaan memori (mmap).

3.1 Cara Kerja Pemetaan Memori dan Implementasi di Windows

Menggunakan mmap memungkinkan konten file dipetakan langsung ke dalam ruang memori virtual proses.

Zero-copy (Tanpa Salinan): Data dibaca langsung dari disk ke dalam tembolok halaman kernel, dan tidak ada salinan ekstra ke ruang pengguna yang terjadi.
On-demand Load (Page Fault): Tepat saat CPU mengakses alamat memori tersebut, page fault terjadi, dan hanya chunk yang diperlukan (biasanya 4KB) yang dimuat ke dalam memori fisik.

Di lingkungan Windows, API Win32 CreateFileMapping dan MapViewOfFile digunakan sebagai pengganti POSIX mmap.

sequenceDiagram participant OS["OS Windows"] participant RAM["Memori Fisik"] participant App["Aplikasi C++"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "Penunjuk Alamat Memori Virtual" App->>App: "Baca Data Tensor pada Penunjuk" OS->>RAM: "Page Fault / Muat halaman dari Disk" RAM-->>App: "Data siap untuk Komputasi SIMD"

3.2 Struktur Biner Format GGUF

GGUF (GPT-Generated Unified Format), yang dikonversi dari format seperti .safetensors Hugging Face, adalah format pamungkas untuk inferensi. GGUF memiliki tata letak biner ketat berikut:

Magic Bytes: 0x46554747 (GGUF).
Version: Nomor versi format.
Tensor Count & Metadata Count: Jumlah tensor dan jumlah pasangan kunci-nilai metadata.
Metadata (Key-Value Pairs): Kunci dengan prefiks panjang string, dan nilai yang diketik.
Tensor Info: Nama setiap tensor, jumlah dimensi, tipe data (FP16, Q4_K, dll.), dan posisi offset di dalam file.
Padding: Padding yang dimasukkan agar data tensor sejajar (aligned) pada batas tertentu (biasanya 32 byte atau 64 byte). Ini penting untuk akses memori cepat dalam instruksi SIMD (khususnya AVX).
Tensor Data: Array data bobot aktual yang telah disejajarkan.

4. Basis Matematis TinyLLaMA dan Algoritma C++

TinyLLaMA menggabungkan beberapa penyempurnaan arsitektur tingkat lanjut untuk efisiensi. Ekspresi matematis untuk mengimplementasikan ini dengan benar dalam C++ dijelaskan di bawah ini.

4.1 RMSNorm (Root Mean Square Normalization)

Ini mengurangi biaya komputasi dengan menghilangkan pemusatan rata-rata dari LayerNorm dan hanya melakukan penskalaan varians.

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

$d$ adalah jumlah dimensi, dan $\gamma$ adalah tensor penskalaan yang telah dipelajari. Saat diimplementasikan di C++, ini dioptimalkan dengan terlebih dahulu menghitung jumlah kuadrat array pada kecepatan tinggi menggunakan _mm256_fmadd_ps dari AVX2, dll., dan mengalikannya dengan akar kuadrat terbalik (seperti instruksi _mm256_rsqrt_ps).

4.2 RoPE (Rotary Position Embedding)

Ini adalah teknik yang menerapkan informasi posisi token sebagai rotasi (Rotate) di ruang tensor. Ini dapat dianggap sebagai rotasi pada bidang kompleks, dan rotasi berikut diterapkan ke pasangan dimensi yang berdekatan $(x_1, x_2)$ dari vektor $x$.

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

Di sini, $m$ adalah indeks posisi absolut token, dan $\theta$ adalah frekuensi dasar yang dihitung sebelumnya. Dalam ggml, eksekusi paralel dapat dicapai hanya dengan menambahkan operator ggml_rope selama pembangunan grafik inferensi.

4.3 Grouped-Query Attention (GQA)

Dalam Multi-Head Attention (MHA) reguler, terdapat jumlah head yang sama untuk masing-masing Query, Key, dan Value. Namun, TinyLLaMA mengadopsi Grouped-Query Attention (GQA) untuk secara drastis mengurangi bandwidth memori dan konsumsi tembolok KV (KV Cache).

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d_k}}\right) V $$

Di GQA, beberapa head Query berbagi satu head Key/Value. Dalam implementasi C++, perlu melakukan operasi broadcast pada tensor KV agar sesuai dengan jumlah Query sebelum menjalankan perkalian matriks ggml_mul_mat.

4.4 Fungsi Aktivasi SwiGLU

Pada lapisan Feed-Forward Network (FFN), SwiGLU digunakan sebagai pengganti GELU.

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

Dalam grafik komputasi, ini diekspresikan dengan menggabungkan operator ggml_silu dan ggml_mul.

5. Pembangunan Grafik Komputasi dan Manajemen Memori dengan ggml

ggml mengambil pendekatan “Define-and-Run”, di mana grafik komputasi statis untuk inferensi dibangun dan dievaluasi nanti.

5.1 ggml_context dan Arena Allocator

Fitur ggml yang paling unik adalah “alokasi arena”, yang sama sekali tidak menggunakan alokasi memori dinamis (malloc atau new) dalam putaran inferensi. Area memori (arena) bersebelahan yang besar dialokasikan saat inisialisasi, dan penunjuk area ini dinaikkan nilainya (incremented) setiap kali ggml_new_tensor dll. dipanggil. Ketika satu langkah inferensi selesai, hanya dengan mengatur ulang penunjuk alokasi ke posisi awalnya, alokasi memori untuk langkah inferensi berikutnya selesai secara instan.

5.2 Contoh Konkret Pembangunan Grafik

Untuk setiap langkah inferensi, grafik komputasi berikut dirakit dalam memori.

graph TD A["ID Masukan Token"] --> B["Pencarian Embed"] B --> C["ggml_rms_norm"] C --> D["Proyeksi Q / K / V"] D --> E["Posisi ggml_rope"] E --> F["Simpan Tembolok KV"] E --> G["Muat Tembolok KV"] G --> H["Self Attention"] H --> I["Skala & Softmax"] I --> J["Keluaran Attention"] J --> K["Proyeksi Keluar"] K --> L["Tambah Residual"]

6. Kuantisasi (Quantization) dan Optimisasi Windows / SIMD

Jika Anda menangani TinyLLaMA (1.1B) dalam FP16, Anda membutuhkan sekitar 2,2GB memori, tetapi melalui kuantisasi 4-bit (seperti Q4_K), ini dapat dikompresi secara dramatis menjadi sekitar 600MB.

6.1 Arsitektur Kuantisasi Blok

ggml tidak mengkuantisasi seluruh tensor secara seragam, melainkan dalam satuan “blok”. Dalam format Q4_0, 32 nilai FP16 dikelompokkan ke dalam satu blok.

Faktor Skala: Satu nilai FP16 (2 byte)
Data Terkuantisasi: 32 nilai 4-bit (16 byte) Ini meminimalkan dampak dari outlier lokal.

6.2 Akselerasi Produk Titik dengan AVX2

Saat membangun untuk CPU x86 terbaru di lingkungan Windows, pemrosesan SIMD dilakukan dalam alur berikut, memanfaatkan tanda (flag) kompilator seperti /arch:AVX2.

Muat: Muat data terkuantisasi 4-bit dari memori ke dalam register AVX 256-bit.
Ekspansi dan Buka Paket: Ekspansi nilai 4-bit menjadi Int8 atau Int16 dengan bit mask dan operasi pergeseran (shift).
Dikuantisasi Balik (Dequantization): Kalikan faktor skala untuk mengonversi ke angka floating-point.
Operasi FMA: Jalankan operasi perkalian-penjumlahan secara paralel dengan nilai aktivasi dan _mm256_fmadd_ps (Fused Multiply-Add).

7. Detail Implementasi Tembolok KV (KV Cache)

Dalam generasi auto-regresif, “Tembolok KV” (KV Cache) adalah fitur penting untuk mengabaikan penghitungan Key dan Value dari token masa lalu.

Poin-poin penting saat menerapkan dalam C++ adalah sebagai berikut:

Prapengalokasian Tensor: Inisialisasi tensor yang sangat besar untuk ukuran konteks maksimum (misalnya: 2048 token) untuk tembolok KV (FP16 disarankan).
Salinan Offset: Saat komputasi dilakukan untuk posisi token $N$, simpan vektor K dan V yang diperoleh pada langkah tersebut di baris ke-$N$ dari tensor tembolok KV menggunakan ggml_cpy atau sejenisnya.
Pembuatan Tampilan Saat Attention: Saat menghitung Attention, buat “tampilan” (view) yang hanya menunjuk ke bagian dari token ke-0 hingga ke-$N$ dan teruskan ke perkalian matriks.

8. BPE Tokenizer dan Decoding

String masukan diperlakukan sebagai urutan byte UTF-8 dan dicocokkan dengan kosakata yang telah ditentukan sebelumnya. Di C++, algoritma menggunakan Pohon Trie (Pohon Prefiks) atau antrean prioritas (priority queue) diimplementasikan untuk mempercepat pencarian kosakata.

Dari logit yang dikeluarkan dari LM Head, probabilitas diskalakan menggunakan parameter Temperature, kandidat dipersempit dengan metode ekstraksi Top-K atau Top-P (Nucleus Sampling), dan token berikutnya pada akhirnya ditentukan menggunakan angka acak.

9. Mempersiapkan Proyek C++ (Lingkungan Windows / PowerShell)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# Pengaturan Optimisasi dan bendera AVX2 untuk Windows (MSVC)
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

Contoh perintah pembuatan (build) di PowerShell:

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. Kesimpulan

Membangun mesin inferensi dari awal untuk model AI berskala kecil seperti TinyLLaMA menggunakan C++ dan ggml adalah kesempatan bagus untuk mengungkap kotak hitam (black box) pembelajaran mendalam dan mempelajari keindahan kontrol perangkat keras tingkat rendah. Mari kita membuka masa depan Edge AI sambil menikmati sepenuhnya esensi pemrograman sistem, seperti pemuatan zero-copy menggunakan pemetaan memori, optimisasi SIMD, dan pembangunan tembolok KV.

【Pengantar Implementasi RAG】 Cara Membuat AI Lokal Membaca Dokumen Anda Sendiri

Fri, 11 Sep 2026 13:00:00 +0900

Pendahuluan

Dalam beberapa tahun terakhir, evolusi Large Language Models (LLM) sangat luar biasa, dengan banyak AI seperti ChatGPT dan Claude menyusup ke kehidupan dan pekerjaan kita. Namun, LLM umum memiliki kelemahan yang jelas. Yaitu mereka hanya mengetahui “informasi publik pada saat pelatihan”. Secara alami, mereka tidak dapat menjawab pertanyaan mengenai “dokumen pribadi” seperti peraturan internal perusahaan, catatan pribadi, dan materi proyek yang belum dipublikasikan. Jika Anda memaksanya untuk menjawab, ada risiko tinggi bahwa ia akan menghasilkan kebohongan yang masuk akal tetapi bertentangan dengan fakta (halusinasi).

Oleh karena itu, arsitektur teknologi yang saat ini meledak dalam popularitas di seluruh dunia adalah RAG (Retrieval-Augmented Generation). Dengan menggunakan RAG, dimungkinkan untuk secara dinamis memberikan pengetahuan unik dari basis data eksternal ke LLM, memungkinkannya untuk menghasilkan jawaban yang akurat dan berdasar berdasarkan pengetahuan tersebut.

Selain itu, ketika menangani area perusahaan atau informasi rahasia pribadi, mengirim data ke API berbasis cloud seperti OpenAI seringkali tidak diizinkan berdasarkan kebijakan keamanan. Di sinilah dibutuhkan pembangunan “RAG lokal” yang dikombinasikan dengan AI lokal (LLM yang beroperasi secara mandiri di PC Anda sendiri atau server on-premise).

Dalam artikel ini, kami akan menjelaskan secara mendalam mulai dari teori dasar RAG, metode implementasi spesifik dari RAG lokal menggunakan Python, latar belakang matematis (mekanisme pencarian vektor), hingga teknik lanjutan untuk menjalankan sistem di lingkungan produksi.

1. Arsitektur Keseluruhan RAG

RAG bukanlah model AI tunggal, melainkan arsitektur sistem tempat berbagai komponen bekerja sama. Secara garis besar, ia terdiri dari dua fase: “Fase Ingestion (Pemasukan Data)” dan “Fase Retrieval & Generation (Pencarian dan Pembuatan)”.

Diagram Mermaid berikut menunjukkan gambaran keseluruhan sistem RAG.

graph TD subgraph "Fase Ingestion (Persiapan Awal)" Doc["Dokumen Milik Sendiri (PDF, TXT, dll.)"] --> Loader["Pemuat Dokumen"] Loader --> Splitter["Pemisahan Teks (Chunking)"] Splitter --> EmbedModel1["Model Embedding"] EmbedModel1 --> VectorDB["Database Vektor"] end subgraph "Fase Inferensi (Saat Pengguna Bertanya)" User["Pertanyaan dari Pengguna (Kueri)"] --> EmbedModel2["Model Embedding"] EmbedModel2 --> QueryVector["Vektor Kueri"] QueryVector --> Search["Pencarian Kemiripan (Pencarian Vektor)"] VectorDB --> Search Search --> Context["Ekstraksi Chunk Terkait (Konteks)"] User --> PromptBuilder["Pembangun Prompt"] Context --> PromptBuilder PromptBuilder --> LocalLLM["LLM Lokal"] LocalLLM --> Answer["Pembuatan Jawaban Akhir"] end

Fase Ingestion (Persiapan Awal)

Pemuatan Dokumen: Memuat data tidak terstruktur seperti PDF, Word, dan file teks.
Chunking (Pemisahan Teks): Untuk menyesuaikan batasan input LLM (jendela konteks) dan untuk meningkatkan akurasi pencarian, teks panjang dipisahkan menjadi bagian-bagian (chunk) yang bermakna.
Embedding (Vektorisasi): Chunk yang telah dipisahkan dimasukkan ke dalam model embedding (Embedding Model) dan diubah menjadi array numerik (vektor) dengan dimensi ratusan hingga ribuan.
Penyimpanan ke Database: Menyimpan vektor yang telah diubah beserta data teks aslinya ke dalam database vektor (Vector DB) dengan saling menautkan satu sama lain.

Fase Inferensi (Saat Dijalankan)

Vektorisasi Kueri: Kalimat pertanyaan dari pengguna divektorisasi menggunakan model embedding yang sama dengan yang digunakan saat persiapan awal.
Pencarian Kemiripan: Perhitungan kemiripan dilakukan antara vektor kueri dan vektor dokumen di dalam database, dan sejumlah kecil teks chunk teratas yang secara semantik dekat (relevansi tinggi) akan diambil.
Pembangunan Prompt: Teks terkait yang diambil akan digabungkan dengan kalimat pertanyaan pengguna sebagai “konteks (pengetahuan latar belakang)” untuk membuat prompt input bagi LLM.
Pembuatan Jawaban: LLM, yang menerima prompt yang telah diperluas, akan menghasilkan jawaban berdasarkan informasi konteks yang diberikan.

2. Pemahaman Mendalam tentang Pencarian Vektor dan Embeddings

Inti dari RAG adalah “pencarian vektor (pencarian semantik)”. Sementara pencarian kata kunci tradisional (seperti BM25) didasarkan pada kecocokan kata yang tepat atau frekuensi, pencarian vektor didasarkan pada “kemiripan makna”. Misalnya, kata yang berbeda seperti “anjing” dan “anak anjing”, atau “PC” dan “komputer pribadi” akan cocok dalam pencarian jika maknanya mirip.

Apa itu Model Embedding (Embedding Model)?

Model embedding adalah jaringan saraf yang menerima teks bahasa alami sebagai input dan mengeluarkan vektor padat (Dense Vector) dengan panjang tetap. Model umum (misalnya text-embedding-3-small atau sumber terbuka multilingual-e5-large) memetakan teks ke dalam vektor bilangan real berdimensi 384 atau 1024.

Dalam ruang multidimensi (ruang laten) ini, telah dipelajari bahwa kalimat dengan makna yang mirip akan memiliki jarak spasial yang lebih dekat di ruang koordinat.

Latar Belakang Matematis Perhitungan Kemiripan: Kesamaan Kosinus

Ketika database vektor mencari dokumen yang relevan, metrik jarak yang paling umum digunakan adalah Kesamaan Kosinus (Cosine Similarity). Berbeda dengan jarak Euclidean (jarak spasial absolut), Kesamaan Kosinus berfokus pada “sudut antara dua vektor”. Karena tidak terlalu terpengaruh oleh panjang kalimat (norma vektor), metrik ini sangat cocok untuk menghitung kemiripan teks.

Dinyatakan secara matematis, Kesamaan Kosinus dari vektor $\mathbf{A}$ dan $\mathbf{B}$ adalah sebagai berikut.

$$ \text{Cosine Similarity}(\mathbf{A}, \mathbf{B}) = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}} $$

$\mathbf{A} \cdot \mathbf{B}$ merepresentasikan produk titik (Dot Product).
$\|\mathbf{A}\|$ merepresentasikan norma L2 (panjang) dari vektor $\mathbf{A}$.
$n$ adalah jumlah dimensi vektor.

Kesamaan kosinus mengambil nilai dari -1 hingga 1.

Mendekati 1: Arah kedua vektor hampir sama (maknanya sangat mirip)
Mendekati 0: Kedua vektor ortogonal (tidak berhubungan)
Mendekati -1: Kedua vektor menghadap ke arah yang berlawanan (maknanya berlawanan)

Database vektor terbaru (seperti Chroma, FAISS, Qdrant) mengadopsi algoritma Approximate Nearest Neighbor (ANN) yang disebut HNSW (Hierarchical Navigable Small World), yang dioptimalkan untuk dapat mencari dokumen dengan kesamaan kosinus tinggi dalam hitungan milidetik, bahkan dari jutaan data vektor.

3. Tumpukan Teknologi untuk Membangun RAG Lokal

Untuk membangun RAG lokal sepenuhnya yang tidak bergantung pada cloud, kita memanfaatkan ekosistem sumber terbuka (open source). Berikut ini adalah tumpukan teknologi yang direkomendasikan.

Model Bahasa (LLM)
- Alat: Ollama atau Llama.cpp
- Model: Model terbuka yang ringan dan berkinerja tinggi seperti Llama-3-8B-Instruct, Gemma-2-9B-It, Qwen2-7B-Instruct. Untuk tugas bahasa Jepang, model yang disetel untuk bahasa Jepang seperti Llama-3-ELYZA-JP-8B cukup sesuai.
Model Embedding (Embedding)
- Model: intfloat/multilingual-e5-large atau BAAI/bge-m3. Saat berjalan secara lokal, umumnya model ini diunduh dari Hugging Face dan dijalankan dengan Sentence-Transformers.
Database Vektor (Vector DB)
- ChromaDB: Berbasis Python dan sangat mudah diatur. Ideal untuk pengembangan lokal.
- FAISS: Pustaka pencarian vektor berkecepatan tinggi yang dikembangkan oleh Meta.
- Qdrant / Milvus: Untuk lingkungan produksi skala besar.
Kerangka Kerja Orkestrasi
- LangChain: Standar de facto untuk menghubungkan komponen (Chain).
- LlamaIndex: Kerangka koneksi data yang dikhususkan terutama untuk RAG.

Kali ini, kita akan mengimplementasikannya dengan kombinasi yang paling mudah diperkenalkan: LangChain + ChromaDB + Ollama + HuggingFaceEmbeddings.

4. Tutorial Implementasi: Membangun RAG Lokal Lengkap dengan Python

Mulai dari sini, kita akan membangun RAG lokal sambil menulis kode Python yang sebenarnya. Pastikan Anda telah menginstal Ollama di PC Anda dan menjalankannya di latar belakang. Juga, pastikan untuk menarik (pull) model di Ollama terlebih dahulu (misalnya: ollama run llama3).

Langkah 1: Menginstal Pustaka yang Diperlukan

1
2


pip install langchain langchain-community langchain-huggingface
pip install chromadb sentence-transformers pypdf

Langkah 2: Gambaran Keseluruhan Kode Implementasi

Berikut adalah skrip Python lengkap untuk memuat file PDF, mengubahnya menjadi vektor, dan meminta LLM lokal untuk menjawab pertanyaan.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93


import os
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.llms import Ollama
from langchain_core.prompts import PromptTemplate
from langchain.chains import RetrievalQA

def main():
 # 1. Memuat dokumen
 print("Memuat dokumen...")
 # Tentukan jalur PDF yang ingin dibaca
 file_path = "sample_company_policy.pdf"
 loader = PyPDFLoader(file_path)
 documents = loader.load()

 # 2. Pemisahan Chunk (Text Splitting)
 # Pisahkan ke ukuran yang sesuai agar tidak merusak makna kalimat
 text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500, # Jumlah karakter maksimum per chunk
 chunk_overlap=50, # Jumlah karakter tumpang tindih antara chunk sebelumnya dan berikutnya (mencegah putusnya konteks)
 separators=["\n\n", "\n", "。", "、", " ", ""]
 )
 chunks = text_splitter.split_documents(documents)
 print(f"Dibagi menjadi {len(chunks)} chunk.")

 # 3. Inisialisasi Model Embedding (Local HuggingFace Model)
 # Menggunakan model multibahasa
 print("Memuat model embedding...")
 embeddings = HuggingFaceEmbeddings(
 model_name="intfloat/multilingual-e5-large",
 model_kwargs={'device': 'cpu'} # Jika ada GPU, gunakan 'cuda' atau 'mps'
 )

 # 4. Membangun Database Vektor (Chroma)
 print("Membangun database vektor...")
 persist_directory = "./chroma_db"
 vectorstore = Chroma.from_documents(
 documents=chunks,
 embedding=embeddings,
 persist_directory=persist_directory
 )
 # Membuat pencari (Retriever). Diatur untuk mengambil 3 dokumen terkait teratas
 retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

 # 5. Inisialisasi LLM Lokal (Ollama)
 print("Terhubung ke LLM lokal...")
 # Pastikan Anda telah mengambil model terlebih dahulu dengan 'ollama pull llama3' atau semacamnya
 llm = Ollama(model="llama3")

 # 6. Definisi Template Prompt
 prompt_template = """Anda adalah asisten cerdas yang mengetahui peraturan perusahaan dan informasi internal.
Gunakan hanya konteks (informasi latar belakang) berikut untuk menjawab pertanyaan pengguna secara rinci.
Jika Anda tidak dapat menemukan jawaban dari konteks, jujurlah dan jawab "Saya tidak tahu dari informasi yang diberikan" tanpa menebak-nebak.

【Konteks】
{context}

【Pertanyaan】
{question}

【Jawaban】:
"""
 PROMPT = PromptTemplate(
 template=prompt_template,
 input_variables=["context", "question"]
 )

 # 7. Membangun Rantai RAG
 qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=retriever,
 return_source_documents=True, # Atur apakah akan mengembalikan sumber informasi
 chain_type_kwargs={"prompt": PROMPT}
 )

 # 8. Eksekusi Pertanyaan
 query = "Tolong beri tahu saya tentang persyaratan penggantian biaya transportasi untuk kerja jarak jauh."
 print(f"\nPertanyaan: {query}\n")

 result = qa_chain.invoke({"query": query})

 print("【Jawaban】")
 print(result['result'])
 print("\n---")
 print("【Sumber Informasi Referensi】")
 for doc in result['source_documents']:
 print(f"- Halaman {doc.metadata.get('page', 'Tidak diketahui')}: {doc.page_content[:50]}...")

if __name__ == "__main__":
 main()

Penjelasan Poin-Poin Kode

RecursiveCharacterTextSplitter: Ini adalah pemisah yang paling direkomendasikan dalam pemisahan bahasa alami. Ia mencoba untuk membagi dalam urutan paragraf (\n\n), baris (\n), dan tanda baca titik (。), berusaha untuk mempertahankannya dalam chunk_size yang ditentukan sambil sebisa mungkin menjaga kesatuan makna. Dengan mengatur chunk_overlap, ini mencegah terputusnya batas konteks yang menyebabkan hilangnya informasi.
HuggingFaceEmbeddings: intfloat/multilingual-e5-large adalah model embedding sumber terbuka yang sangat kuat dan mendukung banyak bahasa. Teks dapat divektorisasi secara offline dalam memori lokal tanpa menggunakan API cloud (seperti text-embedding-ada-002 milik OpenAI).
ChromaDB: Karena beroperasi dalam memori atau penyimpanan lokal (berbasis SQLite), tidak perlu menyiapkan server database yang rumit. Dengan menentukan persist_directory, Anda dapat melompati proses vektorisasi pada saat dijalankan ulang dan memuat DB dari disk.

5. Teknik RAG Lanjutan (Advanced RAG Techniques)

Sistem RAG dasar (Naive RAG) yang dibangun dalam tutorial di atas sudah dapat beroperasi, tetapi ketika akurasi respons yang tinggi diwajibkan di lingkungan produksi, pengenalan teknik tingkat lanjut berikut ini diperlukan.

5.1 Pencarian Hibrida (Hybrid Search)

Meskipun pencarian vektor mahir menangkap “makna”, terkadang pencarian ini buruk pada pencarian kata kunci yang ketat seperti “kata benda khusus”, “nomor model produk”, atau “ID karyawan”. Oleh karena itu, dengan melakukan pencarian semantik melalui pencarian vektor secara paralel dengan pencarian kata kunci menggunakan algoritma seperti BM25, lalu memberikan skor dan mengintegrasikan hasil dari keduanya (menggunakan metode seperti Reciprocal Rank Fusion; RRF), kita dapat secara dramatis mengurangi kelalaian dalam pencarian.

5.2 Pemeringkatan Ulang (Re-ranking)

Meskipun pencarian vektor cepat, hal tersebut tidak selalu mengevaluasi relevansi kontekstual yang tepat dari konteks tersebut. Alur pipa umum untuk meningkatkan akurasi pencarian adalah sebagai berikut.

Pencarian Awal (First-stage Retrieval): Mengambil sekitar 20 hingga 30 chunk terkait secara luas dan dangkal dari database vektor.
Evaluasi Ulang (Re-ranking): Menggunakan model pembelajaran mesin lain yang lebih berat yang disebut Cross-Encoder (contoh: bge-reranker), kita memasukkan pasangan kueri pengguna dan chunk yang diambil untuk menghitung ulang skor kesesuaian semantik.
Penyaringan: Hanya 3 hingga 5 teratas dengan skor tinggi yang akan diteruskan ke prompt LLM sebagai konteks akhir.

Metode ini mencegah informasi noise yang tidak relevan masuk ke LLM dan dapat sangat meningkatkan presisi (Precision) jawaban.

graph LR Query["Kueri"] --> VSearch["Pencarian Vektor (20 Teratas)"] VSearch --> Reranker["Model Reranker (Cross-Encoder)"] Query --> Reranker Reranker --> TopK["3 Teratas Akurasi Tinggi"] TopK --> LLM["Pembuatan LLM"]

5.3 Chunking Semantik dan Pencarian Dokumen Induk

Alih-alih memisahkan teks secara mekanis dengan jumlah karakter tetap, ada teknik yang disebut “Semantic Chunking” yang mendeteksi perubahan makna kalimat dengan AI dan memisahkannya. Selain itu, dalam teknik yang disebut “Parent Document Retriever (Pencarian Dokumen Induk)”, vektorisasi dilakukan dalam unit yang sangat kecil (seperti kalimat) untuk pencarian guna mencapai pencarian presisi tinggi, dan saat diteruskan ke LLM, “paragraf besar asli (dokumen induk)” yang berisi kalimat tersebut diserahkan kepada LLM, sehingga menyediakan konteks yang memadai untuk LLM.

6. Tantangan dan Solusi saat Mengoperasikan RAG Lokal

Saat membangun dan mengoperasikan RAG di lingkungan lokal, terdapat beberapa hambatan tertentu.

Kehabisan VRAM (Memori Video): Untuk menjalankan LLM lokal pada kecepatan praktis (puluhan token per detik), model tersebut harus dimuat ke dalam VRAM GPU. Menjalankan model kelas 8B dalam fp16 (titik kambang 16-bit) memerlukan sekitar 16GB VRAM, tetapi dengan menggunakan teknologi Kuantisasi (Quantization) (teknologi kompresi menjadi 4-bit atau 8-bit, seperti format GGUF atau AWQ), kecepatan operasi yang memadai dapat dicapai bahkan pada 8GB VRAM (seperti pada PC gaming biasa). Llama.cpp dan Ollama mendukung format kuantisasi ini secara standar.
Batasan Jendela Konteks: Jika jumlah konteks yang diperoleh melalui pencarian terlalu banyak, dapat melampaui batas input LLM (batas token) atau menyebabkan model melupakan bagian tengah dari informasi tersebut (fenomena Lost in the middle). Menyesuaikan jumlah chunk yang diekstrak dan menyeleksinya secara ketat dengan teknik pemeringkatan ulang (re-ranking) yang disebutkan sebelumnya adalah suatu keharusan.
Manajemen Kesegaran Data: Saat dokumen sumber diperbarui, vektor dokumen yang bersangkutan di dalam database vektor juga harus diperbarui atau dihapus (operasi CRUD). Karena ChromaDB mendukung pembaruan berbasis ID dokumen, mengelola nilai hash file dan mengatur pemrosesan batch yang hanya menyinkronkan perbedaannya adalah langkah yang praktis.

Kesimpulan

RAG (Retrieval-Augmented Generation) adalah paradigma kuat yang mengubah AI dari sekadar asisten serbaguna biasa menjadi “pakar pribadi Anda” atau “pakar spesialis dalam operasi internal perusahaan”.

Bahkan dengan persyaratan kerahasiaan tingkat tinggi yang tidak dapat menggunakan layanan cloud, terbukti bahwa dengan menggabungkan ekosistem sumber terbuka seperti Ollama, LangChain, dan ChromaDB, sebuah lingkungan “RAG Lokal” yang lengkap dapat dibangun dengan relatif mudah.

Berdasarkan pemahaman matematis tentang ruang vektor dan pendekatan lanjutan seperti pemisahan teks dan pemeringkatan ulang yang dijelaskan dalam artikel ini, silakan coba kembangkan sistem AI orisinal Anda menggunakan data Anda sendiri. Kecepatan evolusi AI lokal sangat mencengangkan, dan sistem yang Anda bangun hari ini dapat secara instan ditingkatkan kinerjanya pada hari esok hanya dengan menukarnya ke model ringan yang lebih cerdas saat model tersebut dirilis.

Di blog ini, kami akan terus menerbitkan artikel mendalam tentang teknologi AI dan RAG di masa mendatang. Jika Anda memiliki pertanyaan atau masukan, jangan ragu untuk meninggalkannya di kolom komentar.

Perbandingan Lengkap API ChatGPT, Gemini, dan Claude! Mana yang Harus Dipilih?

Fri, 11 Sep 2026 12:00:00 +0900

Perbandingan Lengkap API ChatGPT, Gemini, dan Claude! Mana yang Harus Dipilih?

Evolusi teknologi AI sangat luar biasa, khususnya di bidang Model Bahasa Besar (LLM: Large Language Model), di mana ChatGPT (seri GPT) dari OpenAI, Gemini dari Google, dan Claude dari Anthropic sedang bersaing sengit untuk supremasi. Pada tahun 2026 ini, setiap perusahaan merilis model dan fitur API baru dalam hitungan bulan, bahkan minggu. Bagi pengembang dan arsitek TI perusahaan, pertanyaan “API mana yang harus diintegrasikan ke dalam produk?” telah menjadi keputusan krusial yang menentukan kesuksesan sebuah proyek.

Dalam artikel ini, kita tidak hanya akan menyebutkan spesifikasi dari ketiga API penyedia AI besar ini, tetapi juga akan membandingkan dan menjelaskannya secara komprehensif dari sudut pandang pengembang. Kita akan membahas arsitektur desain, struktur harga yang detail, analisis matematis dari latensi, contoh implementasi konkret menggunakan Python dan Node.js, hingga metode optimasi biaya terbaru seperti prompt caching.

Kami berharap artikel ini dapat menjadi panduan lengkap bagi para pembaca untuk memilih API LLM yang paling sesuai dengan kasus penggunaan (use case) mereka, serta membangun aplikasi AI yang skalabel dan hemat biaya.

1. Filosofi dan Konsep Desain Masing-masing API LLM

Dalam pemilihan teknologi, sangat penting untuk memahami terlebih dahulu filosofi dasar bagaimana setiap perusahaan membangun model dan API mereka.

1.1 OpenAI (ChatGPT)

OpenAI mengusung misi “mewujudkan Kecerdasan Buatan Umum (AGI)” dan selalu memimpin sebagai standar de facto di industri ini. Mereka menawarkan berbagai macam model yang disesuaikan dengan kasus penggunaan, seperti GPT-4o, GPT-4o-mini, dan model khusus penalaran yaitu o1. Ekosistemnya adalah yang paling matang, dengan pustaka dan dokumentasi terbanyak, baik yang resmi maupun tidak resmi.

1.2 Google (Gemini)

Google mengedepankan prinsip “AI First”, menggunakan skalabilitas infrastruktur mereka sendiri (jaringan TPU) secara maksimal sebagai senjata utamanya. Gemini 1.5 Pro/Flash memiliki context window (panjang konteks) yang luar biasa hingga 2 juta token, menjadikannya sangat unggul dalam memproses dokumen panjang atau video/audio berjam-jam sekaligus. Integrasi yang kuat dengan Google Cloud (Vertex AI) juga sangat menarik bagi kalangan perusahaan (enterprise).

1.3 Anthropic (Claude)

Anthropic adalah perusahaan yang didirikan oleh mantan anggota OpenAI dan mengadopsi pendekatan keamanan unik yang disebut “Constitutional AI”. Claude 3.5 Sonnet dan Opus mendapatkan dukungan antusias dari banyak pengembang karena kemampuan penalaran yang tinggi, kemampuan menghasilkan kode, dan yang terpenting, “dialog alami layaknya manusia” serta “minimnya halusinasi”.

2. Perbandingan Spesifikasi Keluarga Model secara Komprehensif

Berikut adalah perbandingan spesifikasi dari model-model andalan per tahun 2026.

Penyedia	Model Andalan	Panjang Konteks Maksimal	Keunggulan Utama	Rekomendasi Kasus Penggunaan
OpenAI	GPT-4o	128K	Kecepatan, pengenalan visual, dukungan suara	Aplikasi interaktif, tugas umum
OpenAI	o1-preview	128K	Penalaran logis tingkat tinggi, matematika, pengkodean (coding)	Pembuatan algoritma kompleks, tujuan penelitian
Google	Gemini 1.5 Pro	2.000K	Pemrosesan teks super panjang, multimodal (video/audio)	Analisis basis kode (codebase) raksasa, ringkasan video
Google	Gemini 1.5 Flash	2.000K	Latensi rendah, throughput tinggi, biaya sangat murah	Pemrosesan real-time, pemrosesan batch data dalam jumlah besar
Anthropic	Claude 3.5 Sonnet	200K	Kemampuan coding, pembuatan teks alami	Bantuan pengembangan perangkat lunak, dukungan pelanggan tingkat lanjut
Anthropic	Claude 3.5 Haiku	200K	Respons super cepat, efektivitas biaya	Edge AI, chatbot real-time

3. Mendalami Arsitektur: Di Balik Layar Permintaan API

Saat kita memanggil API LLM, proses apa yang sebenarnya terjadi di backend? Untuk mengoptimalkan performa, kita perlu memahami arsitektur ini.

Diagram Mermaid berikut menunjukkan gambaran keseluruhan mulai dari permintaan API dikirim oleh klien, hingga token dikembalikan secara streaming.

graph TD A["Aplikasi Klien"] -->|HTTP/REST atau gRPC| B["API Gateway"] B --> C["Load Balancer"] C --> D["Klaster Inferensi"] D --> E["Tokenizer (BPE / SentencePiece)"] E --> F["KV Cache & Mekanisme Perhatian (Attention)"] F --> G["Blok Transformer (Forward Pass)"] G --> H["Lapisan Output (Logits)"] H --> I["Sampler (Temperature, Top-p, Top-k)"] I --> J["Detokenizer"] J -->|Respons Streaming (Chunk)| A

3.1 Algoritma Tokenization (Tokenisasi)

Teks yang dimasukkan ke dalam API secara internal dibagi menjadi unit-unit yang disebut “token”.

OpenAI (tiktoken): Mengadopsi Byte-Pair Encoding (BPE). Ini sangat efisien dalam mengompresi bahasa Inggris, tetapi jumlah token cenderung membengkak untuk bahasa non-alfabet seperti bahasa Jepang.
Google (Gemini): Mengadopsi SentencePiece (Unigram Language Model). Kuat dalam berbagai bahasa, dan cenderung mampu merepresentasikan teks dengan jumlah token yang relatif sedikit bahkan dalam teks bahasa Jepang.
Anthropic (Claude): Menggunakan versi kustom dari BPE. Dukungan multibahasa telah ditingkatkan, dan mulai Claude 3 ke atas, efisiensi token untuk bahasa Jepang juga telah diperbaiki secara signifikan.

4. Analisis Matematis tentang Latensi dan Performa

Dalam aplikasi real-time, latensi berdampak langsung pada pengalaman pengguna (UX). Latensi API LLM $T_{total}$ dapat dimodelkan secara matematis sebagai berikut.

$$ T_{total} = T_{network} + T_{TTFT} + (N \times T_{TPOT}) $$

Di sini, masing-masing variabel memiliki arti sebagai berikut:

$T_{network}$: Round Trip Time (RTT) jaringan.
$T_{TTFT}$ (Time To First Token): Waktu yang dibutuhkan hingga karakter pertama dihasilkan. Sangat bergantung pada biaya komputasi attention yang proporsional dengan kuadrat dari panjang prompt (jumlah token input).
$N$: Jumlah total token yang dihasilkan (output).
$T_{TPOT}$ (Time Per Output Token): Waktu pembuatan per token. Karena merupakan model autoregresif, token dihitung secara seri dengan bergantung pada output sebelumnya.

4.1 Kompleksitas Komputasi dari Mekanisme Self-Attention

Kompleksitas komputasi dari Self-Attention dalam arsitektur Transformer meningkat secara kuadratik terhadap panjang urutan input $L$.

$$ \text{Complexity} = O(L^2 \cdot d) $$

Di mana $d$ adalah jumlah dimensi dari vektor embedding. Karena batasan ini, biasanya $T_{TTFT}$ akan memburuk secara drastis saat prompt menjadi lebih panjang. Namun, Gemini 1.5 dari Google mengadopsi arsitektur optimasi inovatif seperti “Ring Attention” dan “Block-wise Compute”, yang berhasil menghasilkan token pertama dalam waktu yang realistis (beberapa detik hingga puluhan detik) meskipun diberikan input teks panjang sebesar 2 juta token.

5. Struktur Harga dan Strategi Optimasi Biaya

Biaya API pada dasarnya dihitung berdasarkan jumlah token input dan jumlah token output.

$$ Cost = (Tokens_{in} \times Rate_{in}) + (Tokens_{out} \times Rate_{out}) $$

Namun, API terbaru telah memperkenalkan mekanisme baru untuk menekan biaya secara drastis.

5.1 Prompt Caching (Cache Prompt)

Mengirimkan sistem prompt yang panjang atau sejumlah besar dokumen hasil pencarian RAG setiap kali permintaan dibuat akan memakan biaya yang sangat besar. Untuk mengatasinya, masing-masing perusahaan menyediakan fitur caching.

Di Anthropic (Claude) dan Google (Gemini), biaya input dapat dikurangi secara signifikan (hingga 90%) dengan melakukan caching pada blok teks tertentu.

Model biaya saat menggunakan cache adalah sebagai berikut:

$$ Cost_{cached} = (Tokens_{cache\_write} \times Rate_{cache\_write}) + (Tokens_{cache\_read} \times Rate_{cache\_read}) + (Tokens_{out} \times Rate_{out}) $$

Di sini, $Rate_{cache\_read}$ biasanya ditetapkan sekitar 10% hingga 25% dari $Rate_{in}$ normal. Hal ini memungkinkan pengoperasian chatbot dengan biaya rendah, sambil terus menyimpan puluhan ribu baris basis kode sebagai latar belakang pengetahuan.

5.2 Batch API (API Batch)

Untuk tugas-tugas yang tidak memerlukan respons real-time (analisis log, klasifikasi data dalam jumlah besar, dll.), OpenAI dan Anthropic menyediakan Batch API. Ini adalah mekanisme luar biasa di mana Anda dapat mengirimkan permintaan sekaligus dan menerima hasilnya dalam waktu 24 jam dengan setengah harga (diskon 50%) dari tarif API normal.

6. Pengalaman Pengembang (DX) dan Perbandingan SDK

Dari perspektif efisiensi pengembangan, mari kita bandingkan SDK (Software Development Kit) yang disediakan oleh setiap perusahaan.

6.1 OpenAI API

Paling banyak digunakan, dan dukungan dari pustaka pihak ketiga (seperti LangChain, LlamaIndex) adalah yang tercepat. Selain itu, dengan fitur Structured Outputs, ia menjamin pengembalian respons yang mematuhi skema JSON dengan akurasi 100%, sehingga integrasi sistem menjadi sangat mudah.

6.2 Anthropic API (Claude)

Antarmuka SDK-nya dirancang dengan rapi, dan definisi tipe TypeScript-nya dikenal sangat mudah digunakan. Secara khusus, struktur Message API-nya sangat intuitif, sehingga permintaan multimodal yang mencakup banyak gambar dapat ditulis dengan sederhana.

6.3 Google Gemini API

Terdapat dua jenis akses: melalui Google Cloud Vertex AI dan melalui AI Studio (Google Gen AI SDK), yang mungkin sedikit membingungkan bagi pemula. Namun, Vertex AI SDK yang ditujukan untuk enterprise terintegrasi penuh dengan IAM (Sistem Otentikasi dan Otorisasi) GCP, sehingga memungkinkan Anda membangun lingkungan pengembangan yang aman.

7. Praktik! Implementasi Pengujian Terpadu Berbagai API Menggunakan Python

Di sini, kita akan mencoba mengimplementasikan skrip menggunakan Python untuk mengirim permintaan asinkron secara bersamaan ke ketiga API (OpenAI, Anthropic, Gemini) guna membandingkan latensinya.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


import asyncio
import time
import os
from openai import AsyncOpenAI
from anthropic import AsyncAnthropic
import google.generativeai as genai

# Inisialisasi Klien
openai_client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
anthropic_client = AsyncAnthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
genai.configure(api_key=os.environ.get("GEMINI_API_KEY"))

prompt = "Tolong jelaskan dasar-dasar komputer kuantum dan dampaknya terhadap teknologi kriptografi saat ini dengan cara yang mudah dipahami oleh pemula."

async def fetch_openai():
 start_time = time.time()
 response = await openai_client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "OpenAI (GPT-4o)", elapsed, response.choices[0].message.content

async def fetch_anthropic():
 start_time = time.time()
 response = await anthropic_client.messages.create(
 model="claude-3-5-sonnet-20240620",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "Anthropic (Claude 3.5 Sonnet)", elapsed, response.content[0].text

async def fetch_gemini():
 start_time = time.time()
 model = genai.GenerativeModel('gemini-1.5-pro')
 # Menggunakan metode asinkron dari Gemini Python SDK
 response = await model.generate_content_async(prompt)
 elapsed = time.time() - start_time
 return "Google (Gemini 1.5 Pro)", elapsed, response.text

async def main():
 print("Mengirim permintaan ke masing-masing API LLM...")

 # Menjalankan ke-3 API secara paralel
 results = await asyncio.gather(
 fetch_openai(),
 fetch_anthropic(),
 fetch_gemini()
 )

 for provider, latency, text in results:
 print(f"--- {provider} ---")
 print(f"Latency: {latency:.2f} detik")
 print(f"Response (Kutipan): {text[:100]}...\n")

if __name__ == "__main__":
 asyncio.run(main())

Dengan menjalankan skrip ini, Anda dapat dengan mudah mengukur model mana yang merespons paling cepat (meminimalkan $T_{total}$) di lingkungan jaringan nyata.

8. Implementasi Tool Calling (Function Calling) Menggunakan Node.js

Untuk membuat LLM berfungsi sebagai “Agen AI” yang berintegrasi dengan sistem eksternal (bukan sekadar chatbot), Tool Calling (atau Function Calling) sangatlah penting. Berikut adalah contoh penggunaan Node.js (TypeScript) agar API OpenAI dapat memanggil API cuaca.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


import OpenAI from "openai";

const openai = new OpenAI({
 apiKey: process.env.OPENAI_API_KEY,
});

async function runAgent() {
 const tools = [
 {
 type: "function",
 function: {
 name: "get_weather",
 description: "Mendapatkan cuaca saat ini untuk kota yang ditentukan.",
 parameters: {
 type: "object",
 properties: {
 location: {
 type: "string",
 description: "Nama kota (contoh: Tokyo, New York)",
 },
 },
 required: ["location"],
 },
 },
 },
 ];

 const response = await openai.chat.completions.create({
 model: "gpt-4o",
 messages: [{ role: "user", "content": "Bagaimana cuaca di Tokyo hari ini? Apakah saya perlu membawa payung?" }],
 tools: tools,
 tool_choice: "auto",
 });

 const message = response.choices[0].message;

 if (message.tool_calls) {
 const toolCall = message.tool_calls[0];
 console.log(`LLM meminta pemanggilan tool: Nama Fungsi = ${toolCall.function.name}`);

 const args = JSON.parse(toolCall.function.arguments);
 console.log(`Argumen: ${args.location}`);

 // Di sini implementasikan proses untuk memanggil API cuaca yang sebenarnya (contoh: OpenWeatherMap)
 // const weather = await fetchWeatherFromAPI(args.location);

 // Setelah mendapatkan hasil, berikan kembali ke LLM untuk menghasilkan jawaban akhir
 }
}

runAgent().catch(console.error);

Claude 3.5 Sonnet dan Gemini 1.5 Pro juga memiliki fitur Tool Calling yang setara. Meskipun ada sedikit perbedaan dalam cara mendefinisikan skema, alur dasarnya tetap sama.

9. RAG vs Long Context Window: Mana yang Harus Diadopsi?

Saat ini, salah satu perdebatan terbesar dalam arsitektur AI perusahaan adalah: “Untuk memasukkan pengetahuan eksternal, haruskah kita menggunakan RAG (Retrieval-Augmented Generation), atau haruskah kita melemparkan semuanya ke dalam Context Window yang sangat besar (Long Context)?”

Kelebihan dan Tantangan RAG (Retrieval-Augmented Generation)

Kelebihan: Biaya lebih murah (karena hanya memasukkan bagian/chunk yang diperlukan ke dalam prompt), lebih mudah mengidentifikasi sumber (dasar) dari jawaban.
Tantangan: Karena bergantung pada akurasi pencarian semantik, ini tidak cocok untuk tugas penalaran tingkat lanjut di mana konteksnya tersebar di beberapa dokumen (Contoh: “Berdasarkan seluruh notulen rapat tahun lalu, tolong analisis akar penyebab keterlambatan proyek A secara kronologis.”).

Long Context (seperti 2 juta token pada Gemini 1.5 Pro)

Kelebihan: Tidak ada informasi yang terlewat akibat proses pencarian. Bahkan dalam uji “mencari jarum di tumpukan jerami” (Needle In A Haystack: NIAH), Gemini 1.5 Pro dan Claude 3.5 Sonnet mampu mengekstraksi informasi dengan akurasi di atas 99%.
Tantangan: Menghabiskan jumlah token yang sangat besar sehingga biayanya membengkak, serta latensi ($T_{TTFT}$) meningkat.

Kesimpulan: Praktik terbaik (best practice) di tahun 2026 adalah “Pendekatan Hibrida”. Desain utama (mainstream) saat ini menggunakan RAG dengan basis data vektor untuk Q&A sehari-hari, dan menggunakan Long Context dengan fitur prompt caching untuk tugas khusus yang memerlukan analisis kompleks atau peninjauan keseluruhan kode.

10. Perbandingan Kemampuan Pemrosesan Multimodal

Dalam aplikasi AI generasi berikutnya, kemampuan untuk memahami tidak hanya teks, tetapi secara langsung juga memahami gambar, audio, dan video akan sangat dibutuhkan.

sequenceDiagram participant User as "Pengguna" participant Client as "Aplikasi Frontend" participant API as "API LLM (Multimodal)" User->>Client: Unggah Video & Prompt Teks Client->>API: Kirim Byte/URI Video + Teks Note over API: Pemisahan Audio & Pemotongan Video Note over API: Model Embedding Multimodal API-->>Client: Kembalikan Ringkasan Teks & Stempel Waktu Client-->>User: Tampilkan Wawasan

OpenAI (GPT-4o): Memiliki akurasi pengenalan gambar yang sangat tinggi, unggul dalam membaca gambar tulisan tangan atau grafik yang rumit. Selain itu, percakapan suara asli (native) dengan latensi sangat rendah (ratusan milidetik) menggunakan Realtime API juga sangat kuat.
Google (Gemini 1.5 Pro): Sangat mendominasi dalam analisis video. Anda dapat memasukkan file video berdurasi 1 jam (kumpulan frame + audio) apa adanya, dan menanyakan pertanyaan spesifik seperti “Apa judul dokumen yang dipegang oleh orang di sisi kanan layar pada menit 12:45?”, lalu mendapatkan jawabannya.
Anthropic (Claude 3.5 Sonnet): Kemampuan pengenalan gambar (Vision)-nya setara dengan GPT-4o dan sangat luar biasa. Model ini menunjukkan kekuatan tak tertandingi dalam mendukung pengembangan frontend, seperti ketika diberikan tangkapan layar UI lalu diminta “Tolong buatkan kode komponen React untuk layar ini.”

11. Keamanan dan Kepatuhan Tingkat Perusahaan (Enterprise)

Saat perusahaan menggunakan API LLM di lingkungan produksi (production), kekhawatiran terbesar adalah “Apakah data kami akan digunakan untuk melatih AI?” dan “Apakah ini memenuhi persyaratan kepatuhan (compliance)?”

Ketiga penyedia secara tegas menyatakan bahwa data yang dikirim melalui API (prompt dan respons) tidak digunakan untuk pelatihan model (Zero Data Retention / No Training on Customer Data) (*Hal ini berbeda dari UI obrolan web gratis yang ditujukan untuk konsumen).

Jika tingkat keamanan yang lebih tinggi diperlukan:

OpenAI: Melalui Azure OpenAI Service, Anda dapat memanfaatkan koneksi jaringan tertutup (private network) via Azure Private Link, tingkat SLA (Service Level Agreement), dan keamanan tingkat perusahaan dari Microsoft.
Google: Melalui Google Cloud Vertex AI, Anda dapat mengaktifkan perlindungan data via CMEK (Customer-Managed Encryption Keys) dan pemisahan jaringan secara ketat menggunakan VPC Service Controls.
Anthropic: Dengan menggunakannya melalui AWS Bedrock atau Google Cloud Vertex AI, Anda dapat memanfaatkan infrastruktur keamanan yang kokoh dari penyedia cloud tersebut.

12. Kesimpulan: Panduan Pilihan Utama Berdasarkan Kasus Penggunaan

Sejauh ini kita telah membandingkan dari berbagai sudut, tetapi pada akhirnya, jawaban untuk “Mana yang harus dipilih?” akan bergantung pada kasus penggunaan Anda.

Pengembangan Perangkat Lunak Kompleks, Pembuatan Kode, dan Penalaran Tingkat Lanjut: 👑 Pemenang: Claude 3.5 Sonnet (Anthropic) Saat ini, model ini memberikan performa terbaik dalam pemahaman konteks kode, refactoring, dan penulisan teks yang alami layaknya manusia. Kemudahan penggunaan API dan efisiensi biayanya berkat prompt caching juga sangat luar biasa.
Analisis Dokumen Super Panjang, Pemrosesan Batch Video/Audio: 👑 Pemenang: Gemini 1.5 Pro (Google) Context window sebesar 2 juta token adalah senjata unik yang tak tertandingi. Untuk tugas-tugas yang memerlukan pemahaman keseluruhan data, seperti menganalisis panduan PDF setebal ratusan halaman atau merangkum rekaman rapat berdurasi panjang, tidak ada yang bisa mengalahkan Gemini.
Fleksibilitas, Kecepatan Eksekusi, dan Output Terstruktur yang Stabil (JSON): 👑 Pemenang: GPT-4o / GPT-4o-mini (OpenAI) Model ini menangani hampir semua tugas dengan baik dan memiliki dukungan alat (tool) pihak ketiga yang paling banyak. Jika Anda memerlukan parsing JSON yang andal menggunakan Structured Outputs, atau penalaran logis tingkat sangat tinggi menggunakan model o1, maka ekosistem OpenAI sangat diperlukan.

Rekomendasi Routing Multi-Model

Tren masa depan bukanlah bergantung pada API tunggal (vendor lock-in), melainkan arsitektur “LLM Routing” di mana Anda dapat secara dinamis mengganti model tergantung pada tingkat kesulitan dan pentingnya tugas. Misalnya, untuk merespons pertanyaan sederhana dari pengguna, Anda dapat menggunakan GPT-4o-mini atau Gemini 1.5 Flash yang murah dan cepat. Namun, jika dinilai memerlukan pemrosesan yang lebih kompleks, barulah tugas tersebut diserahkan ke Claude 3.5 Sonnet. Dengan cara ini, keseimbangan optimal antara biaya dan performa dapat tercapai.

Evolusi AI tidak akan berhenti. Pahami secara mendalam kelebihan dan kekurangan dari masing-masing API, serta karakteristik arsitekturnya, agar Anda dapat membangun aplikasi AI yang fleksibel dan skalabel.

Panduan Menggunakan llama.cpp dan Pengenalan Kustomisasi dengan C++

Fri, 11 Sep 2026 11:00:00 +0900

Dalam beberapa tahun terakhir, evolusi Large Language Models (LLM) sangat luar biasa, dan jangkauan aplikasinya meluas dari hari ke hari. Namun, menjalankan model dengan miliaran atau puluhan miliar parameter di lingkungan lokal biasanya membutuhkan GPU high-end dengan VRAM yang sangat besar. llama.cpp hadir untuk menerobos “dinding perangkat keras” ini, memungkinkan inferensi LLM secara praktis pada PC umum, Mac, dan bahkan perangkat seperti Raspberry Pi.

Pada artikel ini, kita tidak hanya membahas cara menggunakan alat baris perintah (CLI), tetapi juga menjelaskan secara sangat rinci bagi para engineer mengenai arsitektur ggml yang menjadi teknologi dasarnya, latar belakang matematis dari Transformer dan kuantisasi, serta cara menggunakan API C++ untuk mengintegrasikan dan menyesuaikan LLM ke dalam aplikasi Anda sendiri.

1. Ikhtisar llama.cpp dan ggml

llama.cpp adalah mesin inferensi LLM ringan yang ditulis dalam bahasa C/C++, dikembangkan oleh Georgi Gerganov. Awalnya dibuat dengan tujuan agar model LLaMA dari Meta dapat berjalan cepat di Apple Silicon (Mac M1/M2), tetapi kini telah mendukung berbagai arsitektur dan model.

Fitur terbesarnya adalah merupakan implementasi murni C/C++ tanpa dependensi eksternal. Ia tidak membutuhkan ekosistem besar seperti Python atau PyTorch, dan karena dapat dikompilasi menjadi satu file executable, proses deployment menjadi sangat mudah.

Jantung dari llama.cpp ini adalah library komputasi tensor bernama ggml. ggml dirancang dari nol untuk mengoptimalkan operasi matriks dalam machine learning ke batas maksimal di CPU (dan sebagian GPU).

1.1 Mengapa llama.cpp Cepat?

Pemanfaatan Memory Mapping (mmap): Saat memuat bobot (weights) model ke memori, penggunaan mmap dari OS menghindari pemuatan penuh ke RAM, sehingga menghasilkan startup yang cepat dan hemat memori.
Optimasi Ekstensif Instruksi SIMD: Memanfaatkan set instruksi khusus CPU seperti AVX2, AVX-512, ARM NEON, dan Apple AMX untuk sangat mempercepat perkalian matriks.
Kuantisasi (Quantization): Mengompresi bobot floating-point 16-bit (FP16) menjadi bilangan bulat 4-bit, 5-bit, dan 8-bit untuk mengatasi bottleneck pada bandwidth memori (detail lebih lanjut akan dijelaskan nanti).

2. Latar Belakang Matematis: Transformer dan Kuantisasi (Quantization)

Untuk memahami llama.cpp secara mendalam, kita perlu mengetahui rumus matematika yang dihitungnya dan bagaimana komputasi tersebut diaproksimasi.

2.1 Proses Inferensi Transformer

Model seperti LLaMA menggunakan arsitektur Transformer decoder yang bersifat auto-regressive. Inti dari pembuatan teks adalah mekanisme Self-Attention.

Untuk matriks keadaan tersembunyi (hidden state) $X \in \mathbb{R}^{N \times d}$ sebagai input, Query $Q$, Key $K$, dan Value $V$ dihitung dengan perkalian bersama matriks bobot (weights matrix):

$$ Q = X W_Q, \quad K = X W_K, \quad V = X W_V $$

Di sini, keluaran dari Attention didefinisikan sebagai berikut:

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

Dalam loop inferensi llama.cpp, yang menjadi hambatan (bottleneck) adalah perkalian antara matriks bobot raksasa $W_Q, W_K, W_V$ atau matriks bobot Feed Forward Network (FFN) dengan vektor $X$ (pada fase generasi teks, vektor diproses token demi token sehingga $N=1$), yang juga dikenal sebagai GEMV (General Matrix-Vector Multiplication).

2.2 Dasar Matematis Kuantisasi (Quantization)

Dalam inferensi di mana bandwidth akses memori menjadi hambatan, kuantisasi yang merepresentasikan parameter bobot dengan jumlah bit kecil sangatlah penting. Berikut adalah penjelasan prinsip dasar dari kuantisasi berbasis blok (seperti Q4_K atau Q4_0) yang banyak digunakan di llama.cpp.

Misalkan kita memiliki blok $w = [w_1, w_2, \dots, w_B]$ dengan panjang $B$ (biasanya 32 atau 64) yang merupakan bagian dari matriks bobot FP16 $W$. Blok ini diaproksimasikan menjadi bilangan bulat 4-bit $q_i \in [-8, 7]$ dan sebuah faktor penskalaan (scaling factor) tunggal $\Delta$ (FP16 atau FP32).

$$ w_i \approx \Delta \times q_i $$

Nilai $\Delta$ ditentukan berdasarkan nilai absolut maksimum di dalam blok tersebut:

$$ \Delta = \frac{\max_i |w_i|}{7} $$

Ketika menghitung perkalian titik (dot product) $y = w \cdot x$ menggunakan bobot yang telah dikuantisasi, jika vektor masukan $x$ juga dikuantisasi menjadi $x_i \approx \Delta_x \times q_{x, i}$, maka:

$$ y = \sum_{i=1}^{B} w_i x_i \approx \Delta \Delta_x \sum_{i=1}^{B} q_i q_{x, i} $$

Bagian $\sum q_i q_{x, i}$ ini sepenuhnya merupakan operasi bilangan bulat murni (pure integer arithmetic), yang dapat dikomputasi secara paralel dengan sangat cepat menggunakan instruksi SIMD. Inilah rahasia matematis di balik kecepatan llama.cpp yang luar biasa di CPU.

3. Arsitektur dan Alur Inferensi

Untuk memahami operasi internal llama.cpp, diagram Mermaid berikut menunjukkan arsitektur keseluruhan sistem dan aliran datanya.

graph TD A["Input Pengguna (String)"] --> B["Tokenizer llama.cpp"] B --> C["Token ID (array int32)"] C --> D["Buffer Konteks (KV Cache)"] D --> E["Grafik Komputasi ggml"] E --> F["Lapisan Transformer"] subgraph "Mesin ggml" F --> G["Self-Attention (RoPE)"] G --> H["Jaringan Feed Forward"] H --> F end F --> I["Logits (Ukuran Kosakata)"] I --> J["Sampler (Suhu, Top-K, Top-P)"] J --> K["ID Token Terpilih"] K --> L["Detokenizer llama.cpp"] L --> M["String Output"] K -. "Loop Auto-regressive" .-> D

Generasi teks adalah loop auto-regressive di mana setiap kali satu token dihasilkan, token tersebut ditambahkan ke KV Cache sebagai input berikutnya, lalu melewati grafik komputasi lagi.

4. Pengaturan Lingkungan dan Cara Build

Sebelum mengintegrasikan llama.cpp ke dalam proyek C++, mari kita mulai dengan mem-build kode sumbernya.

4.1 Kloning Repositori

1
2


git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp

4.2 Build Menggunakan CMake

Ketika mengintegrasikannya ke aplikasi lain sebagai proyek C++, menggunakan CMake adalah pendekatan yang paling standar. Anda dapat mempercepat komputasi dengan mengaktifkan akselerator (backend) yang sesuai dengan platform masing-masing.

Hanya CPU (Build Dasar):

1
2
3


mkdir build && cd build
cmake ..
cmake --build . --config Release -j 8

Jika Menggunakan NVIDIA GPU (CUDA):

1
2
3


mkdir build && cd build
cmake .. -DGGML_CUDA=ON
cmake --build . --config Release -j 8

Jika Menggunakan Apple Silicon (Metal):

1
2
3


mkdir build && cd build
cmake .. -DGGML_METAL=ON
cmake --build . --config Release -j 8

Jika proses build berhasil, file eksekusi seperti llama-cli dan pustaka llama (serta pustaka ggml) yang akan di-link melalui API C++ yang dijelaskan nanti, akan dibuat di direktori build/bin/.

5. Pengenalan Kustomisasi dengan C++: Menggunakan API llama.cpp

Mulai dari sini, kita akan membahas topik utama yaitu mengendalikan llama.cpp dari kode C++. Untuk tidak sekadar menggunakan alat baris perintah (CLI), melainkan mengintegrasikan LLM ke dalam aplikasi Anda sendiri (seperti game engine, aplikasi desktop, sistem embedded, dll.), Anda perlu memanggil langsung API C++.

llama.cpp menyediakan antarmuka bahasa C terutama melalui header file bernama llama.h. Antarmuka ini juga digunakan ketika dipanggil dari C++.

5.1 Include dan Pengaturan Minimal yang Diperlukan

Jika Anda menggunakan llama.cpp di proyek Anda sendiri, masukkan pustaka berikut.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#include "llama.h"
#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>

// Makro untuk error handling
#define LLAMA_ASSERT(x) \
 do { \
 if (!(x)) { \
 std::cerr << "Assertion failed: " << #x << std::endl; \
 std::terminate(); \
 } \
 } while (0)

5.2 Memuat Model dan Inisialisasi Konteks

Pertama, kita muat file model berformat .gguf dan menyiapkan konteks (ruang memori dan KV Cache) untuk inferensi.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


int main(int argc, char ** argv) {
 if (argc < 2) {
 std::cerr << "Usage: " << argv[0] << " <model.gguf>" << std::endl;
 return 1;
 }
 std::string model_path = argv[1];

 // 1. Inisialisasi backend (Pengaturan lingkungan seperti CPU/GPU)
 llama_backend_init();

 // 2. Mendapatkan pengaturan default parameter model
 llama_model_params model_params = llama_model_default_params();
 model_params.n_gpu_layers = 35; // Jumlah layer yang dialihkan ke GPU

 // 3. Memuat model
 llama_model * model = llama_load_model_from_file(model_path.c_str(), model_params);
 if (model == nullptr) {
 std::cerr << "Failed to load model" << std::endl;
 return 1;
 }

 // 4. Pengaturan parameter konteks
 llama_context_params ctx_params = llama_context_default_params();
 ctx_params.n_ctx = 2048; // Ukuran konteks maksimum (jumlah token)
 ctx_params.n_threads = 8; // Jumlah thread CPU yang digunakan untuk inferensi

 // 5. Membuat konteks
 llama_context * ctx = llama_new_context_with_model(model, ctx_params);
 if (ctx == nullptr) {
 std::cerr << "Failed to create context" << std::endl;
 llama_free_model(model);
 return 1;
 }

 std::cout << "Model and context loaded successfully!" << std::endl;
 // ... Pemrosesan selanjutnya

5.3 Tokenisasi Prompt (Tokenization)

LLM tidak secara langsung memahami teks, melainkan memprosesnya sebagai urutan ID integer (token). String input perlu dikonversi ke token.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 std::string prompt = "Q: Apa ibu kota Jepang?\nA:";
 std::vector<llama_token> tokens_list;
 tokens_list.resize(prompt.length() + 4); // Ukuran buffer dengan ruang ekstra

 // Apakah akan menambahkan token khusus (seperti BOS: Begin of Sequence) di awal
 bool add_special = true;
 // Mengonversi string menjadi array ID token
 int n_tokens = llama_tokenize(
 model,
 prompt.c_str(),
 prompt.length(),
 tokens_list.data(),
 tokens_list.size(),
 add_special,
 false // parse_special
 );

 if (n_tokens < 0) {
 // Jika buffer tidak cukup, diperlukan proses untuk realokasi dan mencoba ulang (dihilangkan untuk penyederhanaan)
 std::cerr << "Failed to tokenize prompt" << std::endl;
 return 1;
 }
 tokens_list.resize(n_tokens);

5.4 Loop Inferensi dan Sampling

Kita membangun sebuah loop di mana token dimasukkan ke model untuk mendapatkan distribusi probabilitas (Logits) token berikutnya, lalu melakukan sampling dari sana untuk menentukan token selanjutnya.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72


 // Jumlah token maksimum yang dihasilkan
 const int max_gen_tokens = 100;

 // Inisialisasi struktur untuk evaluasi batch
 llama_batch batch = llama_batch_init(512, 0, 1);

 // Menambahkan token prompt ke dalam batch
 for (size_t i = 0; i < tokens_list.size(); i++) {
 llama_batch_add(batch, tokens_list[i], i, { 0 }, false);
 }
 // Diatur agar hanya mengeluarkan logit (hasil prediksi) di token terakhir prompt
 batch.logits[batch.n_tokens - 1] = true;

 // Evaluasi awal (memasukkan prompt ke model)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "llama_decode() failed" << std::endl;
 return 1;
 }

 int n_cur = batch.n_tokens; // Panjang konteks saat ini
 int n_decode = 0;

 std::cout << "\nOutput: ";

 // Inisialisasi konteks sampler (Pengaturan Temperature, Top-K, Top-P, dll.)
 llama_sampler * smpl = llama_sampler_chain_init(llama_sampler_chain_default_params());
 llama_sampler_chain_add_top_k(smpl, 40);
 llama_sampler_chain_add_top_p(smpl, 0.9f, 1);
 llama_sampler_chain_add_temp(smpl, 0.7f);
 llama_sampler_chain_add_dist(smpl, 1234); // Nilai seed

 while (n_decode < max_gen_tokens) {
 // 1. Sampling: memprediksi token berikutnya berdasarkan konteks saat ini
 llama_token new_token_id = llama_sampler_sample(smpl, ctx, -1);

 // 2. Jika token adalah EOS (End of Sequence), hentikan loop
 if (llama_token_is_eog(model, new_token_id)) {
 break;
 }

 // 3. Dekode token menjadi string (teks) untuk ditampilkan
 char buf[128];
 int n_chars = llama_token_to_piece(model, new_token_id, buf, sizeof(buf), 0, false);
 if (n_chars > 0) {
 std::cout << std::string(buf, n_chars) << std::flush;
 }

 // 4. Persiapkan token baru yang dihasilkan sebagai batch berikutnya
 llama_batch_clear(batch);
 llama_batch_add(batch, new_token_id, n_cur, { 0 }, true);

 // 5. Evaluasi model (memperbarui KV Cache dan memprediksi selanjutnya)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "Failed to evaluate" << std::endl;
 break;
 }

 n_cur += 1;
 n_decode += 1;
 }

 std::cout << std::endl;

 // Bersihkan
 llama_sampler_free(smpl);
 llama_batch_free(batch);
 llama_free(ctx);
 llama_free_model(model);
 llama_backend_free();

 return 0;
}

Kode ini merupakan implementasi dari loop inferensi kustom yang menggunakan API dasar llama.cpp. Kode ini menggunakan struktur llama_batch untuk mengelola sekumpulan token, dan menggunakan llama_decode untuk menjalankan forward pass dari jaringan saraf.

6. Contoh Kustomisasi Lanjutan: Manipulasi Logit dan Kontrol Penalti dengan C++

Jika kita tidak hanya melakukan pembuatan teks sederhana, tetapi ingin memaksakan format output tertentu (seperti hanya JSON), atau mencegah dihasilkannya kata-kata terlarang tertentu, kita bisa secara langsung memanipulasi Logit dari sisi C++ sebelum sampling dilakukan.

Anda bisa mendapatkan array dari skor mentah (nilai sebelum dikonversi menjadi probabilitas) yang dihasilkan model tepat sebelum setiap token dikeluarkan.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Dapatkan array logit mentah tepat setelah inferensi, sebelum sampling dilakukan
float * logits = llama_get_logits_ith(ctx, batch.n_tokens - 1);
int n_vocab = llama_n_vocab(model);

// Daftar ID token terlarang (sebagai contoh 1234, 5678)
std::vector<llama_token> forbidden_tokens = { 1234, 5678 };

// Mengatur probabilitas kemunculan token terlarang menjadi 0 (Logit menjadi minus tak terhingga)
for (llama_token bad_tok : forbidden_tokens) {
 logits[bad_tok] = -INFINITY;
}

Dengan mengelola API C++ secara langsung, “intervensi berskala mikromilidetik pada setiap siklus inferensi” bisa dilakukan, sesuatu yang mungkin sulit dicapai atau memakan overhead yang terlalu besar jika dilakukan melalui LangChain atau Python.

7. Rahasia Penyetelan Kinerja (Performance Tuning)

Setelah implementasi di C++ selesai, berikut adalah beberapa poin untuk diperiksa guna meningkatkan kecepatan hingga batas maksimal untuk produksi yang sebenarnya.

Optimasi Pemrosesan Batch: Jika Anda memproses permintaan dari beberapa pengguna secara bersamaan, sertakan beberapa sequence dalam llama_batch dan panggil llama_decode sekaligus (Continuous Batching). Hal ini memungkinkan akses memori untuk dibagikan sehingga dapat meningkatkan throughput secara dramatis.
Mengaktifkan Flash Attention: Dengan menetapkan ctx_params.flash_attn = true; pada parameter konteks, komputasi Attention bisa dipercepat sembari mengurangi penggunaan memori. Ini merupakan pengaturan yang diwajibkan bila menangani konteks yang panjang (puluhan ribu token).
Dukungan NUMA: Di lingkungan server multi-socket, konfigurasi NUMA yang tepat sebelum memanggil llama_backend_init() dapat mengurangi latensi dari akses memori.

8. Kesimpulan

Pada artikel ini, kita telah membahas secara mendalam mulai dari latar belakang matematis llama.cpp, penjelasan arsitektur, hingga cara membangun mesin inferensi kustom menggunakan API C++.

Ekosistem Python sangat berguna untuk pembuatan prototype, namun untuk deployment di perangkat edge, integrasi ke dalam game, atau dalam lingkungan produksi yang menuntut pemrosesan secara real-time, pengontrolan langsung llama.cpp berbasis C/C++ menunjukkan kekuatan yang luar biasa.

Kami sangat menyarankan Anda untuk mencoba menulis kode C++ dengan tangan Anda sendiri dan merasakan serunya mengendalikan LLM secara bebas di lingkungan lokal.

Tautan Referensi

Repositori Resmi llama.cpp

ggml - Tensor Library

Attention Is All You Need (Vaswani et al., 2017)

【Terbaru 2026】Panduan Lengkap Menjalankan LLM Lokal di Lingkungan Windows

Fri, 11 Sep 2026 10:00:00 +0900

1. Pendahuluan: Mengapa LLM Lokal di Windows Sekarang?

Pada tahun 2026, evolusi AI Generatif dan Large Language Models (LLM) menunjukkan pergeseran paradigma besar dari layanan API raksasa di cloud ke “LLM lokal” yang berjalan di PC pribadi atau lingkungan on-premise. AI cloud seperti GPT-5 dari OpenAI dan Claude 3.5 dari Anthropic sangat kuat, namun tidak semua perusahaan atau individu dapat mengirimkan seluruh data mereka ke cloud. Dari perspektif privasi, keamanan, latensi, serta biaya jangka panjang dan berkelanjutan, permintaan untuk LLM lokal meningkat pesat seperti yang belum pernah terjadi sebelumnya.

Khususnya di lingkungan Windows, evolusi ekosistem LLM lokal sangat luar biasa. Hingga beberapa tahun yang lalu, menjadi rahasia umum bahwa “pengembangan dan eksekusi AI sama dengan Linux”, tetapi pada tahun 2026, Windows telah bertransformasi menjadi platform AI yang sangat kuat dan mudah digunakan.

Artikel ini memberikan panduan lengkap untuk membangun, mengoperasikan, dan mengoptimalkan LLM lokal di lingkungan Windows, berdasarkan tren teknologi terbaru tahun 2026. Mulai dari pengaturan sederhana menggunakan Ollama untuk pemula, optimasi ekstrem memanfaatkan llama.cpp untuk pengguna tingkat lanjut, hingga pemahaman mendalam tentang arsitektur dan pendekatan matematis perhitungan VRAM, serta fine-tuning lokal, kami akan menjelaskannya secara menyeluruh dengan volume yang melimpah.

1.1 Tren Teknologi Seputar LLM Lokal Tahun 2026

Tren utama yang membentuk ekosistem LLM lokal saat ini adalah sebagai berikut:

Adopsi Penuh Format GGUF: GGUF (GPT-Generated Unified Format), yang mengintegrasikan metadata dan tensor ke dalam satu file, telah sepenuhnya menjadi standar de facto. Ini memungkinkan eksekusi di lingkungan mana pun hanya dengan mengunduh satu file dari Hugging Face.
Demokratisasi Arsitektur MoE (Mixture of Experts): Banyak model MoE berskala kecil namun berkinerja tinggi telah dirilis. Dengan hanya mengaktifkan beberapa “ahli” selama inferensi, ini mencapai kinerja yang sebanding dengan model raksasa sambil menekan beban komputasi PC konsumen.
Abstraksi dan Optimasi Lanjutan dari Mesin Inferensi: Alat seperti Ollama, LM Studio, dan AnythingLLM telah disempurnakan, sehingga pengguna tidak perlu lagi peduli dengan dependensi kompleks seperti instalasi driver CUDA. Selain itu, dengan dukungan asli Windows untuk FlashAttention 3, kecepatan inferensi meningkat secara dramatis.
Pemanfaatan NPU dan Kemunculan PC Windows Copilot+: Bahkan pada laptop tanpa GPU, teknologi yang menggunakan NPU (Neural Processing Unit) bawaan untuk menjalankan LLM skala kecil (SLM: Small Language Models) dengan konsumsi daya rendah telah mencapai tahap praktis.

2. Persyaratan Perangkat Keras dan Persiapan OS

Untuk menjalankan LLM lokal pada kecepatan yang praktis (15-30 token atau lebih per detik), pemilihan perangkat keras adalah yang paling penting.

2.1 Konfigurasi Perangkat Keras yang Disarankan

Seiring dengan evolusi PC AI, spesifikasi yang dibutuhkan juga berubah.

OS: Windows 11 Pro (24H2 atau lebih baru). Diperlukan untuk memanfaatkan fungsionalitas penuh WSL2, manajemen memori tingkat lanjut, dan API terbaru dari DirectML.
CPU: Intel Core Ultra seri 200 ke atas, atau AMD Ryzen seri 9000 ke atas. Saat menggunakan inferensi CPU bersama-sama, komunikasi memori bandwidth tinggi sangat penting.
RAM: Minimal 32GB, disarankan 64GB atau lebih. Bandwidth memori utama (MB/s) menjadi bottleneck penentu selama inferensi CPU atau offloading. Memori berkecepatan tinggi DDR5-6000 atau lebih adalah ideal.
GPU: NVIDIA seri RTX 4000/5000. Dalam LLM lokal, yang paling penting bukanlah kinerja komputasi melainkan “kapasitas VRAM”.
- Entry level: RTX 4060 Ti (versi 16GB) - Kinerja biaya (cost-performance) terbaik. Sangat cocok untuk model kelas 8B-14B.
- Menengah (Mid-range): RTX 4070 Ti SUPER (16GB) / RTX 4080 SUPER (16GB)
- High-end: RTX 4090 (24GB) / RTX 5090 (32GB) - Diperlukan untuk menjalankan model terkuantisasi kelas 30B-70B.
Penyimpanan: SSD NVMe PCIe Gen4 atau Gen5. Mengurangi waktu pemuatan model puluhan GB secara dramatis.

2.2 Pengaturan WSL2 (Windows Subsystem for Linux 2)

Meskipun banyak alat GUI berjalan secara native di Windows, WSL2 sangat praktis untuk pengembangan menggunakan Python, kompilasi alat terbaru, dan fine-tuning LoRA yang akan dijelaskan nanti. Di lingkungan Windows 11 terbaru, hanya dengan menginstal driver NVIDIA di sisi host, GPU (CUDA) dapat digunakan secara transparan dari WSL2.

Buka PowerShell dengan hak administrator dan jalankan berikut ini:

1
2
3
4
5


# Instalasi WSL2 dan Ubuntu terbaru
wsl --install -d Ubuntu-24.04

# Pembaruan kernel
wsl --update

Setelah instalasi, jalankan nvidia-smi di terminal WSL2. Jika GPU terdeteksi secara normal, instalasi berhasil.

3. Arsitektur LLM Lokal dan Mekanisme Inferensi

Memahami struktur internal bagaimana model menghasilkan teks di lingkungan lokal sangat berguna untuk pemecahan masalah dan pengoptimalan.

Diagram Mermaid di bawah ini menunjukkan alur (pipeline) inferensi LLM lokal yang umum.

graph TD User["Input Pengguna (Prompt)"] --> Tokenizer["Tokenizer (Tokenizer)"] Tokenizer --> Embedding["Lapisan Penyematan (Embedding)"] subgraph "Transformer Block (x Layers)" Embedding --> Attn["Perhatian Diri (Self-Attention)"] Attn --> KVCache["Cache KV (Penyimpanan Key/Value)"] Attn --> FFN["Jaringan Feed-Forward (FFN)"] end FFN --> Logits["Perhitungan Logit (Logits)"] Logits --> Sampler["Sampler (Temperature, Top-K, Top-P)"] Sampler --> OutputToken["Token Output"] OutputToken --> |"Pembuatan Autoregresif"| Tokenizer OutputToken --> Decoder["Detokenizer (Detokenizer)"] Decoder --> FinalOutput["Teks Output Akhir"]

3.1 Dua Fase: Prefill dan Decode

Pembuatan teks LLM dibagi menjadi dua fase dengan karakteristik komputasi yang berbeda.

Fase Prefill (Pemrosesan Prompt): Ini adalah fase untuk memproses dan memahami seluruh prompt input sekaligus. Karena komputasi paralel memungkinkan, kapasitas komputasi GPU (FLOPS) berbanding lurus dengan kecepatan. Jika prompt panjang, fase ini bisa memakan waktu beberapa detik.
Fase Decode (Pembuatan Token): Fase ini memprediksi token demi token dan memasukkannya kembali sebagai input berikutnya (autoregresif). Karena komputasi paralel terbatas dalam fase ini, bandwidth VRAM GPU (Memory Bandwidth) menjadi bottleneck penentu.

4. Perhitungan Konsumsi VRAM dan Pemahaman Matematis Ukuran Model

Untuk menilai dengan tepat “model mana yang dapat berjalan di PC saya?”, Anda perlu memahami rumus perhitungan VRAM. Jika fallback ke memori sistem (RAM) terjadi karena kekurangan VRAM, kecepatan inferensi akan melambat 10 hingga 100 kali lipat.

4.1 VRAM Dasar Berdasarkan Ukuran Parameter

Ini adalah jumlah memori untuk memuat bobot (weights) model ke dalam VRAM. Dihitung menggunakan ukuran model $P$ (jumlah parameter, satuan: 1 Miliar = 1B) dan jumlah byte per parameter $B$.

$$ V_{base} = P \times B \quad \text{(GB)} $$

Misalnya, jika memuat model parameter 8B (8 miliar) dalam FP16 (titik mengambang presisi setengah, 16-bit = 2 byte):

$$ V_{base} = 8 \times 2 = 16 \text{ GB} $$

Dengan kata lain, meskipun GPU memiliki VRAM 16GB, batasnya sudah hampir tercapai hanya dengan memuat model.

4.2 Keajaiban Kuantisasi (Quantization)

Di sinilah “kuantisasi” muncul. Ini secara dramatis mengurangi ukuran model dengan menurunkan presisi parameter. Pada kuantisasi 4-bit yang paling umum (contoh: Q4_K_M), rata-rata adalah sekitar 0,55 byte per parameter.

$$ V_{base\_4bit} = 8 \times 0.55 = 4.4 \text{ GB} $$

Dengan demikian, jika Anda memiliki 16GB VRAM, Anda dapat menjalankan model 8B dengan kelonggaran yang cukup.

4.3 Perhitungan Cache KV (Versi Kompatibel GQA)

Selama inferensi, “Cache KV” untuk mempertahankan konteks masa lalu akan mengonsumsi VRAM. Pada model terbaru seperti Llama 3, GQA (Grouped Query Attention) diadopsi untuk menghemat memori.

Konsumsi Cache KV $V_{kv}$ (Gigabyte) direpresentasikan oleh rumus berikut.

$$ V_{kv} = 2 \times b \times s \times l \times \left( \frac{h_{kv}}{h_q} \right) \times h_q \times d \times B_{kv} \div 10^9 $$

Disederhanakan, ini dapat dihitung dengan mudah menggunakan jumlah head key dan value $h_{kv}$.

$$ V_{kv} = 2 \times b \times s \times l \times h_{kv} \times d \times B_{kv} \div 10^9 $$

Di mana:

$b$: Ukuran batch (biasanya 1 untuk penggunaan lokal pribadi)
$s$: Panjang sekuens (panjang konteks, contoh: 8192)
$l$: Jumlah lapisan (contoh: 32)
$h_{kv}$: Jumlah head KV (contoh: 8)
$d$: Jumlah dimensi per head (contoh: 128)
$B_{kv}$: Jumlah byte dari Cache KV (2 untuk FP16)

Contoh perhitungan (Llama 3 8B, konteks 8192, Cache FP16): $V_{kv} = 2 \times 1 \times 8192 \times 32 \times 8 \times 128 \times 2 \div 10^9 \approx 1.07 \text{ GB}$

Perhatikan bahwa semakin panjang panjang konteks $s$, VRAM yang dibutuhkan akan meningkat secara linier.

5. Praktik 1: Pengaturan Tercepat & Tersingkat Menggunakan Ollama

Setelah memahami teorinya, mari kita coba menjalankan LLM di lingkungan Windows secara nyata. Hingga tahun 2026, alat yang paling ramah pengguna adalah “Ollama”. Ia menyediakan CLI intuitif yang mirip Docker.

5.1 Instalasi dan Eksekusi

Unduh penginstal versi Windows dari Situs Resmi Ollama dan jalankan.
Buka PowerShell dan masukkan perintah berikut. Di sini, kita akan menggunakan llama3:8b yang mendukung bahasa Jepang.

1

ollama run llama3:8b

Pada percobaan pertama, model akan diunduh. Setelah selesai, Anda dapat langsung berinteraksi di terminal.

5.2 Pembuatan AI Kustom dengan Modelfile

Anda dapat dengan mudah membuat AI yang memiliki persona tertentu. Buat Modelfile di lokasi yang diinginkan.

1
2
3
4
5
6
7
8
9


FROM llama3:8b

SYSTEM """
Anda adalah insinyur perangkat lunak senior yang sangat hebat.
Untuk pertanyaan pengguna, selalu jawab secara logis dan ringkas, dengan menyertakan contoh kode.
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

Bangun model kustom Anda sendiri dan jalankan dengan perintah berikut.

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 Penggunaan dari Aplikasi Eksternal (AI Editor)

Ollama mengekspos endpoint API yang kompatibel dengan OpenAI di http://localhost:11434. Hanya dengan mengatur URL ke atas di pengaturan backend ekstensi VS Code seperti Cursor atau Continue.dev, dan menetapkan nama model ke SeniorDev dll, Anda mendapatkan asisten pengkodean lokal yang kuat secara gratis.

6. Praktik 2: Penyesuaian Kinerja Ekstrem dengan llama.cpp

Jika Anda ingin mencoba manajemen memori yang mendetail atau format terbaru (seperti kuantisasi EXL2 atau IQ) sesegera mungkin, operasikan langsung mesin intinya llama.cpp.

6.1 Langkah Build llama.cpp

Di lingkungan Windows, yang terbaik adalah membangun dari sumber menggunakan CUDA Toolkit dan CMake.

1
2
3
4
5
6
7
8


git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build
cd build

# Konfigurasi dan kompilasi untuk dukungan CUDA
cmake .. -DLLAMA_CUBLAS=ON -DBUILD_SHARED_LIBS=OFF
cmake --build . --config Release -j 16

6.2 Peluncuran Lanjutan dalam Mode Server

Gunakan llama-server.exe yang telah dibangun untuk meng-host model.

1
2
3
4
5
6
7


.\bin\Release\llama-server.exe `
 --model "C:\models\Llama-3-8B-Instruct.Q4_K_M.gguf" `
 --ctx-size 8192 `
 --n-gpu-layers 99 `
 --threads 8 `
 --flash-attn `
 --port 8080

--n-gpu-layers 99: Membongkar (offload) semua lapisan yang memungkinkan ke VRAM GPU.
--flash-attn: Mengaktifkan FlashAttention 3, mencapai peningkatan kecepatan inferensi dan pengurangan konsumsi VRAM dari Cache KV.

7. GUI Frontend: LM Studio dan Membangun RAG Lokal

Jika Anda tidak nyaman dengan baris perintah, atau jika Anda ingin melakukan RAG (Retrieval-Augmented Generation) secara intuitif, gunakan GUI.

7.1 LM Studio

LM Studio adalah aplikasi brilian yang menggabungkan pencarian model, pengunduhan, pemeriksaan awal persyaratan sistem, dan bahkan UI obrolan menjadi satu. Cukup dengan menekan tombol “Local Server” di dalam aplikasi, API yang kompatibel dengan OpenAI akan dimulai.

7.2 Arsitektur RAG menggunakan AnythingLLM

Berikut adalah diagram arsitektur lingkungan RAG untuk membaca dokumen internal perusahaan atau catatan pribadi.

graph LR Document["Dokumen (PDF, MD)"] --> Chunking["Pembagian Potongan (Chunking)"] Chunking --> EmbedModel["Model Penyematan"] EmbedModel --> VectorDB["Database Vektor"] UserQuery["Pertanyaan Pengguna"] --> EmbedQuery["Penyematan Pertanyaan"] EmbedQuery --> VectorDB VectorDB --> |"Pencarian Kemiripan"| RetrievedDocs["Ekstraksi Dokumen Terkait"] UserQuery --> PromptBuilder["Pembuatan Prompt"] RetrievedDocs --> PromptBuilder PromptBuilder --> LocalLLM["LLM Lokal"] LocalLLM --> Answer["Jawaban Akhir"]

Dengan AnythingLLM versi desktop (Windows), Anda hanya perlu menentukan Ollama (LLM dan Embedding) dari layar pengaturan, dan mengaturnya untuk menggunakan VectorDB lokal (LanceDB), dan arsitektur ini selesai dalam beberapa menit. Lahirlah AI privat yang tidak mengirimkan data apa pun ke luar.

8. Fine-tuning (LoRA) di Windows WSL2

Jika Anda tidak hanya ingin menjalankannya secara lokal, tetapi juga ingin membuat model Anda lebih pintar dengan data Anda sendiri, fine-tuning menggunakan LoRA (Low-Rank Adaptation) dimungkinkan. Hingga tahun 2026, menggunakan pustaka bernama “Unsloth”, pelatihan model 8B dapat diselesaikan dalam beberapa jam bahkan dengan VRAM 16GB di lingkungan Windows WSL2.

Jalankan berikut ini di dalam Ubuntu WSL2 untuk mengatur lingkungan.

1
2
3
4


conda create --name unsloth_env python=3.11
conda activate unsloth_env
pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git"
pip install --no-deps trl peft accelerate bitsandbytes

Unsloth mengoptimalkan kernel CUDA hingga batasnya, mencapai kecepatan pelatihan sekitar 2 kali lipat dan mengurangi konsumsi VRAM hingga separuhnya dibandingkan dengan pustaka Hugging Face standar. Hanya dengan meluncurkan Jupyter Notebook dan memuat kumpulan data (format JSONL), Anda dapat melakukan pelatihan beberapa epoch bahkan pada RTX 4060 Ti dll dengan VRAM 12GB hingga 16GB.

9. Pemecahan Masalah Kinerja

Ini adalah masalah umum dan solusinya.

1. Kecepatan inferensi sangat lambat (1-2 token/s)

Penyebab: Model tidak muat sepenuhnya di VRAM dan sedang dibongkar (offload) ke memori sistem (RAM). Solusi: Periksa “Memori GPU Khusus” di Task Manager. Jika mencapai batas, kurangi ukuran konteks (-c) atau gunakan model kuantisasi dengan bit yang lebih rendah (seperti Q4_K_M).

2. Kesalahan “CUDA out of memory”

Penyebab: VRAM telah habis sepenuhnya. Ini terutama terjadi ketika percakapan diperpanjang dan Cache KV membengkak. Solusi: Secara sengaja batasi nilai num_ctx untuk Ollama atau -c untuk llama.cpp menjadi lebih kecil.

3. Pembuatan teks bahasa Jepang/Indonesia aneh

Penyebab: Ketidaksesuaian template prompt, atau model yang tidak didukung. Solusi: Gunakan model yang menyertakan Instruct dalam namanya, dan pastikan template yang benar yang ditentukan oleh pembuat model, seperti format ChatML atau Llama3, dipilih di sisi alat.

10. Kesimpulan dan Prospek Masa Depan

Pada tahun 2026, membangun LLM lokal di lingkungan Windows tidak lagi menjadi hak istimewa eksklusif segelintir insinyur. Melalui standar de facto format GGUF, munculnya ekosistem yang disempurnakan seperti Ollama dan LM Studio, serta pengoptimalan perangkat keras termasuk FlashAttention, siapa pun kini dapat dengan mudah memperoleh lingkungan AI tingkat perusahaan (enterprise).

Silakan manfaatkan poin-poin yang dijelaskan dalam artikel ini:

Gunakan perhitungan matematis VRAM untuk secara logis memilih ukuran model dan tingkat kuantisasi yang paling sesuai dengan spesifikasi PC Anda.
Gunakan Ollama untuk membangun lingkungan tercepat dan meningkatkan produktivitas secara dramatis dengan menghubungkannya ke editor AI.
Gunakan kontrol parameter lanjutan dari llama.cpp untuk memaksimalkan kinerja batas perangkat keras Anda.
Gunakan AnythingLLM untuk membangun sistem RAG lokal yang aman yang menangani data rahasia.
Manfaatkan Unsloth (WSL2) untuk melatih AI kustom yang memiliki pengetahuan khusus Anda sendiri.

“Demokratisasi” AI tidak lagi sekadar buzzword, tetapi sistem nyata yang berjalan di desktop Windows Anda. Bebaskan diri Anda dari biaya penggunaan API cloud dan risiko kebocoran informasi, serta melangkahlah sekarang ke dunia AI privat yang bebas dan kuat.