Menguji batas VRAM 6 GiB di Nitro AN515-57

Setelah Mac dan laptop Ubuntu saya terhubung melalui kabel USB-C, langkah berikutnya adalah menguji AI lokal di laptop Ubuntu tersebut.

Laptop ini saya pakai untuk mengembangkan aplikasi yang membutuhkan LLM, embedding, reranking, TTS, ASR, dan image-to-3D. Dengan VRAM 6 GiB, saya perlu menentukan model yang bisa menetap di GPU dan pekerjaan yang harus dijalankan bergantian. Tulisan ini merangkum hasil pengujiannya; data mentah dan skripnya ada di repositori benchmarks.

Perangkat dan metode pengujian#

Untuk LLM, hanya satu server inference yang aktif pada satu waktu, dan setiap run menunggu GPU dingin lebih dulu karena pengaruh suhu besar pada laptop ini.

Decode menunjukkan kecepatan setelah token pertama keluar. TTFT mengukur latensi dari pengiriman permintaan sampai chunk pertama diterima. Throughput gabungan menghitung seluruh token keluaran dibagi waktu kelompok permintaan, termasuk TTFT.

Qwen3.5-4B pada empat runtime#

Model kecil ini berjalan sepenuhnya di GPU. Kolom decode berasal dari satu permintaan, kolom total dari empat permintaan yang dikirim bersamaan. Semua kecepatan dalam token per detik.

vLLM menghasilkan throughput gabungan tertinggi pada beban ini. Angka 201,1 merupakan total kelompok permintaan; decode per permintaan vLLM pada beban empat permintaan sekitar 66,6 token/detik.

Konfigurasi tiap runtime berbeda, jadi selisihnya tidak dapat dikaitkan hanya dengan nama runtime:

Model besar dengan bantuan CPU#

Qwen3.6-35B-A3B Q4_K_M berukuran sekitar 20,7 GiB. Sebagian tensor expert perlu ditempatkan di CPU agar model dapat digunakan bersama GPU 6 GiB. vLLM dan SGLang tidak diuji untuk model ini karena bobotnya tidak muat di kartu.

Pada llama.cpp, konfigurasi berikut memakai --n-cpu-moe 36, ubatch 4096, tujuh thread CPU, dan context window 32.768 token. Decode dalam token per detik, TTFT dalam detik.

Kecepatan prompt llama.cpp sekitar 638 token/detik. Angka itu dihitung dari jumlah prompt token dibagi TTFT, sehingga mencakup overhead sebelum token pertama, bukan waktu kernel prefill tersendiri.

File Q4_K_M pada perbandingan ini tidak identik: llama.cpp memakai GGUF dari Bartowski karena metadata blob Ollama tidak kompatibel dengan llama.cpp yang diuji. Sebagai pembanding dengan file yang sama, Qwen3-Coder-30B-A3B memakai blob GGUF Ollama pada kedua runtime, dengan --n-cpu-moe 44 dan ubatch 4096 pada llama.cpp:

Pada kedua model, llama.cpp memulai keluaran jauh lebih cepat. Ini relevan untuk aplikasi yang membawa prompt panjang sebelum menghasilkan jawaban.

Simulasi sesi agent#

Pengujian delapan turn memakai riwayat sintetis yang bertambah hingga sekitar 10.300 token. Angka pada tabel menjumlahkan TTFT dari seluruh turn, tanpa waktu menghasilkan jawaban.

SGLang mencatat jumlah TTFT terendah untuk model 4B, tetapi pool KV-nya membatasi panjang prompt: context 32.768 token tidak berarti pool tersebut mampu menampung permintaan sepanjang itu.

Seluruh konfigurasi mencatat tool call valid 5/5. Pengujian ini hanya memeriksa nama tool dan JSON arguments, bukan apakah model berhasil menyelesaikan tugas agent.

TTS, ASR, embedding, reranking, dan PDF#

Qwen3-ASR-1.7B membaca 100 klip pertama FLEURS berbahasa Indonesia (set dev), dengan reranker menetap di kartu. WER dan CER dihitung setelah tanda baca dihapus dan teks dijadikan huruf kecil.

Selisih cold-start dan warm latency ini ikut menentukan latensi saat aplikasi berganti layanan.

Untuk rekaman panjang, saya menggabungkan 26 klip dengan jeda setengah detik menjadi 324 detik audio. Server memotong rekaman sebelum ditranskripsi, dan proses selesai dalam 21,5 detik dengan WER 9,81 % serta puncak kartu 5.650 MiB. Klip yang digabung tidak saling berhubungan, sehingga WER-nya tidak dibandingkan langsung dengan hasil klip pendek.

Uji PDF memakai nist-sp800-73pt2.pdf dengan layout docling_layout_egret_xlarge.

Angka CPU reranker diukur dengan CUDA_VISIBLE_DEVICES dikosongkan. Binary llama.cpp yang dibangun dengan CUDA tetap menitipkan perkalian matriks batch ke GPU walaupun -ngl 0, sehingga tanpa langkah itu 20 kandidat tampak selesai dalam sekitar 1,6 detik.

Image-to-3D#

TRELLIS.2 berjalan melalui trellis2cpp dengan patch low-VRAM: SS flow dilepas setelah digunakan, lalu shape flow dimuat saat dibutuhkan. Dengan cara ini seluruh komponen model tidak perlu ditahan sekaligus di kartu.

Hasil berikut memakai potret yang dipotong menjadi 1.755 piksel di bagian kepala dan bahu:

Skor siluet hanya menilai kecocokan dari depan; kualitas geometri dan tekstur dari sudut lain tetap perlu diperiksa. Pekerjaan selama lima menit juga menahan layanan lain yang menunggu giliran memakai GPU.

Berbagi satu GPU#

Layanan TTS, ASR, image-to-3D, dan konversi PDF bergantian memakai GPU. Model dimuat saat dibutuhkan dan dilepas ketika idle atau ketika layanan lain meminta ruang. Pada pengujian ini, permintaan TTS pertama membuat model ASR dilepas, lalu model TTS dimuat. Reranker tetap menetap di kartu, dan LLM melalui Ollama berjalan di luar mekanisme giliran tersebut.

Mekanisme ini mengatur giliran, tetapi belum menjamin bebas OOM untuk setiap kombinasi layanan. Latensi antrean lintas layanan juga belum diukur.

Kesimpulan#

vLLM unggul untuk beberapa permintaan model kecil, sedangkan llama.cpp dengan pembagian CPU dan GPU unggul untuk model besar yang diuji. Di aplikasi, pilihan itu masih perlu disesuaikan dengan layanan lain yang sedang aktif. Semua angka LLM di atas berasal dari pengujian singkat setelah GPU dingin; beban berkelanjutan memicu thermal slowdown, sehingga ruang model, latensi pemuatan ulang, latensi antrean, dan suhu menentukan apakah kecepatan pada tabel dapat dipertahankan.