Apakah memungkinkan untuk memisahkan instalasi untuk perbaikan keamanan dan pembaruan firmware saja, jika itu alasan utama mengapa downgrade sekarang tidak diperbolehkan? Dengan begitu, kita bisa downgrade firmware dan menginstal perbaikan keamanan yang diperlukan.
Penjelasan yang bagus, Sam, dan ini masuk akal dari sudut pandang kepatuhan. Saya hanya ingin memastikan bahwa opsi roll-back memang valid dengan tim dukungan, dan bahwa saya tidak harus naik ke “level 5” dukungan selama berminggu-minggu untuk menemukan seseorang yang cukup teknis untuk melakukan roll-back. Semoga saja roll-back jarang terjadi, dan terima kasih sekali lagi telah meluangkan waktu untuk menjelaskannya.
Ada yang tahu kapan kita akhirnya akan melihat QTS 6?
Terima kasih atas klarifikasinya, Sam, tetapi akan lebih baik jika opsi untuk menghubungi dukungan demi rollback dijelaskan — faktanya tidak.
Tidak semua orang berada di UE, jadi regulasi keamanan siber tidak berlaku untuk semua pelanggan Anda. Saya paham bahwa ini bisa saja terjadi di negara lain di masa depan, jadi saya mengerti alasan di balik keputusan tersebut.
Waktu respons tim Dukungan Anda masih banyak yang kurang, namun satu-satunya kanal yang tersedia hanya melalui email. Di banyak organisasi, tingkat layanan untuk respons email biasanya dalam 12-24 jam. Tapi tidak demikian untuk dukungan teknis komputer, di mana ada kanal dukungan lain. Tidak demikian dengan QNAP. Bisa memakan waktu 6-8 jam untuk respons awal jika Anda beruntung ada masalah di hari kerja, tetapi jika sudah larut hari Jumat atau akhir pekan, Anda kurang beruntung. Respons lanjutan setelah pelanggan membalas bisa dan memang memakan waktu sama lama. Hal itu jelas tidak layak untuk banyak orang. Tiket yang saya buka pada 14 Juli? Hari ini, 21 Juli, mereka akhirnya memutuskan untuk meminta akses ke sistem saya melalui HelpDesk. Untungnya saya sudah berhasil mengatasi masalahnya sendiri, tetapi mereka ingin menyelidiki lebih lanjut.
Saya punya firasat bahwa saat basis pelanggan Anda beralih ke QuTS Hero 6 dan mulai mengalami masalah, ketidakpuasan soal ini akan semakin membesar.
Ini adalah hal yang biasa terjadi pada undang-undang yang dibuat oleh orang yang tidak terlibat dalam industri tersebut. Ketidakmampuan untuk melakukan rollback membuat orang ingin bertahan dengan firmware yang sudah berjalan lama. Akibatnya, mereka tidak mendapatkan pembaruan keamanan terbaru. Jika kamu melakukan update firmware pada Jumat malam atau akhir pekan di mesin produksi lalu ada yang rusak, apa yang akan kamu katakan kepada staf pada hari Senin?
Sejujurnya, aku mungkin akan bilang cukup banyak, dan tidak satupun yang positif!
Di pengaturan daya, ada opsi untuk mode tidur EU. Kenapa tidak mengaitkan pengaturan itu dengan kemampuan untuk mengembalikan? Diasumsikan, pengguna di EU wajib mencentang kotak tersebut. Jika mereka tidak melakukannya, itu bukan masalah QNAP. Sebagai alternatif, negara lain bisa membuat undang-undang yang mengharuskan pengembalian.
Atau, ketika kamu mengatur NAS, daripada hanya memilih China atau seluruh dunia, tambahkan juga opsi EU sebagai pilihan.
Karena penasaran saja, saya mencari mode tidur UE ini — saya tidak melihatnya di pengaturan daya untuk QuTS Hero. Mungkin memang hanya untuk QTS, atau mungkin perangkat keras saya tidak mendukungnya. Ini TS-h1887XU-RP, jadi kemungkinan memang tidak didukung karena ini unit rack-mount.
“Control Panel”, “power”, “Eup mode” di QTS dan QuTS.
Kemungkinan berarti perangkatmu selalu menggunakan kurang dari 1 watt saat mode power down.
TVS-AIH1688ATX upgrade dari QuTS Hero h6.0.0.3500 ke QuTS Hero 6.0.1.3550 tanpa masalah.
Nvidia 4000 Blackwell GPU
QXP-800S
192 GB Ram
Upgrade dilakukan melalui control panel. Saya sudah mengunduh firmware OS baru, kernel Nvidia, dan file Advanced Network sebelum melakukan upgrade. Saya menggunakan update firmware dari control panel untuk memulai upgrade. Firmware upgrade menggunakan file firmware yang sudah saya unduh dari QNAP. Proses instalasi berjalan lancar, kemudian perangkat reboot dua kali dan muncul error instalasi Nvidia serta masalah adapter jaringan.
Saya akhirnya menghapus driver NVIDIA yang lama (bukan kernel), lalu memasang driver kernel yang baru dan driver advanced network. Setelah reboot, ketika perangkat sudah menyala, saya menginstal ulang driver NVIDIA dari store dan reboot lagi. Setelah perangkat menyala kembali, semuanya berjalan dengan baik. QWEN, Plex, JellyFin dll semua berfungsi dan memakai 4000 seperti sebelumnya.
Halo, apakah kamu sedang membuat AI dengan ini? Karena aku belum bisa memastikan apakah masalahnya berasal dari sini, tapi model seperti Gemma 4 (quantified) atau Qwen3.6 (quantified, memakai 17GB RAM di RTX Pro 4000) yang sebelumnya bisa loading di GPU sekarang sudah tidak bisa lagi (di Ollama).
Aku sudah downgrade Ollama ke versi 0.30.8, tapi masalahnya tetap sama.
Halo,
Terima kasih atas respons Anda.
Saya telah mengikuti metode dengan menghapus driver Nvidia, memperbarui driver kernel dari situs QNAP, lalu menginstal ulang driver.
Setelah itu, saya sempat bisa menggunakan Ollama, dengan beban pada GPU. Tapi beberapa hari terakhir, tidak bisa sama sekali, hanya berjalan di CPU saja (perintah: ollama ps), meskipun kartu tetap terdeteksi di container (nvidia-smi) di dalamnya.
Saya terpaksa menunggu proses pengecekan hard disk yang sedang error selesai, agar bisa melakukan operasi perawatan (menghapus driver lagi).
Selain itu, saya juga menemukan masalah lain: beberapa parameter yang seharusnya bisa disinkronkan secara internal di OS ternyata tidak berjalan (hal ini saat ini menghalangi instalasi versi baru RClone dalam qpkg): QNAP - [RClone] The system volume is missing | Forum des NAS : Synology, Qnap, Asustor...
Namun, masalah ini sudah bergeser dari topik awal.
Halo,
Terima kasih atas detailnya. Informasi ini sangat berguna karena menunjukkan masalahnya bukan pada driver.
Ini detail kunci dari pesan Anda: nvidia-smi mendeteksi kartu di dalam container, tapi ollama ps melaporkan CPU. Kombinasi ini berarti driver dan container runtime Anda berjalan dengan benar. Jika driver atau NVIDIA container runtime bermasalah, nvidia-smi juga akan gagal di dalam container. Tapi itu tidak terjadi, kartu GPU terlihat dan benar-benar berhasil dilewatkan ke container.
Masalah sebenarnya adalah inisialisasi CUDA saat Ollama memuat model. Ini adalah masalah yang sudah dikenal, dan saya sendiri juga mengalaminya di mesin saya. Setelah GPU diam (idle) dalam waktu tertentu, inisialisasi CUDA gagal dan Ollama secara otomatis beralih ke CPU tanpa pesan error. Model masih merespon, tapi sekitar 20 kali lebih lambat.
Jangan tunggu pemeriksaan disk. Anda tidak perlu uninstall driver lagi. Solusinya cukup restart container Ollama saja. Proses ini hanya butuh beberapa detik dan tidak mempengaruhi driver, paket, atau penyimpanan Anda:
docker restart ollama
docker exec ollama ollama ps
Setelah restart, muat model Anda dan cek lagi ollama ps. Jika kolom PROCESSOR sekarang menunjukkan GPU, berarti kita punya masalah yang sama dan inilah solusi sementara Anda. Jika masih menunjuk CPU, berarti masalahnya berbeda dan hal ini penting untuk diperhatikan.
Timeline Anda juga mendukung ini. Setelah reinstall driver, semuanya berfungsi, tapi masalah muncul lagi setelah beberapa hari. Driver yang rusak akan gagal langsung setiap saat, bukan berjalan normal dulu lalu memburuk.
Untuk mencegahnya, atur OLLAMA_KEEP_ALIVE=24h di environment container Ollama. Pengaturan ini membuat model tetap berada di VRAM, sehingga periode idle yang memicu kegagalan tidak terjadi.
Saran terakhir, dengan hormat. Anda menyebutkan hard drive bermasalah dan volume sistem yang hilang. Itu lebih serius dari masalah GPU. Saya sarankan memperbaiki disk dan volume sistem dulu. Driver NVIDIA diinstal sebagai paket QPKG, sehingga volume sistem yang rusak juga bisa berdampak pada sistem paket. Diagnosa GPU akan sulit jika lapisan storage bermasalah.
Silakan beritahu kami hasil ollama ps setelah container direstart.
Saya sudah beberapa kali merestart container lewat Container Station, tapi belum berhasil mengembalikan operasi ke kondisi optimal (hanya GPU, tidak CPU). Sering kali, cuma restart NAS yang membuat model bisa berjalan lagi di GPU.
Bagaimanapun, akhirnya saya berpikir untuk melakukan reset NAS dengan instalasi firmware yang benar demi mengatasi masalah-masalah yang terus bertumpuk ini (mungkin terkait penggunaan QuTS hero 6 beta atau karena saya membangun ulang system pool saat NAS masih menyala dengan bantuan support).
achimede333,
Maaf kamu mengalami masalah seperti ini. Sebenarnya, aku termotivasi mencoba RAG lokal karena postinganmu tentang RAG dan 4000 Blackwell. Aku masih menyempurnakan Qwen, tapi sejauh ini komprominya lebih lambat dari yang aku suka, tapi tetap privat.
Dashboard yang aku pakai untuk memantau server adalah desainku sendiri. Dashboard itu juga memantau semua container dan layanan serta memungkinkan aku mengelola semuanya; start/stop/status/abaikan (kasus penggunaan khusus). Aku tidak pakai container station. Semua file Docker Compose aku buat sendiri dan aku jalankan container dengan cara itu.
Snapshot di bawah ini sudah memuat semua widget. Yang tidak kelihatan adalah semua pelaporan error yang dibangun di dalamnya. Aku mengalami masalah memori dengan NAS sejak membelinya (fault MCE) dan akhirnya terisolasi ke controller memori motherboard. Besok, NAS akan masuk untuk diperbaiki. Karena sering reboot spontan akibat masalah ini, aku harus membuat cara agar bisa langsung melihat apa yang terjadi di NAS. Itulah awal dashboard ini, tapi sekarang aku pakai tiap hari untuk memantau NAS dan cepat mengenali masalah pada container, masalah jaringan, dsb.
Hal lain yang aku pelajari: driver NIC untuk chip atlantic di TVS-AIH1688ATX dulu diurus alantic, lalu diambil alih Marvell, dan repo gitHub aslinya ditinggal. Aku tidak tahu siapa yang merawat driver sekarang, tapi ada beberapa masalah yang aku temukan dan menyebabkan setidaknya 2 reboot spontan yang tidak terkait masalah memori.
Aturan praktis: Jangan ubah pengaturan driver NIC saat ada hal penting yang sedang berjalan. Kemungkinan menyebabkan reboot sekitar 50/50. Perubahan ring-resize pasti bikin reboot setiap kali. Aku juga sudah memantau NIC membuang paket. Kalau kamu lihat di bagian Network, tracker-ku sudah di 192 paket yang terbuang. Itu baseline-ku saat ini; kalau mulai naik, aku tahu koneksi jaringan perlu direstart. Membuat MB lebih dingin tampaknya membantu. Kipas casing aku jalankan di 55% dan CPU di 50% setiap saat.
Aku terus melaporkan masalah tiap kali nemu, dan aku yakin QNAP sedang berupaya memperbaiki bug seiring kita laporkan, tapi memang menantang kadang-kadang. Bagian dari serunya menjalankan firmware beta. 
Ya, saya sudah mencatat fakta bahwa kamu ikut dalam percakapan lain dan fakta bahwa kamu juga punya RTX Pro 4000 membuat saya bertanya-tanya apakah kamu juga langsung terjun seperti saya :).
Saya sedang mencoba Ollama dengan Open WebUI sebagai antarmuka, dan saya beralih dari Gemma 4 ke Qwen3.6 untuk pengujian.
Memang butuh waktu lama untuk menyempurnakan elemen-elemennya, dan saya masih harus mengatur banyak hal lain sekaligus. Jadi gangguan dari driver benar-benar mengganggu dan membuat saya membuang waktu (dan saya ragu untuk beralih ke llama.cpp, tapi itu malah makin menyita waktu…, walaupun performanya bakal lebih baik).
Antarmuka kamu benar-benar keren, dan terutama, menemukan masalah terkait memori NAS…
Saat ini, NAS yang dipakai Seagate 28T, menunjukkan smart sedang waspada… Umurnya masih baru, saya akan menunggu hasil pemindaian, lalu lihat apa firmware baru bisa mengubah sesuatu, kalau tidak, RMA…
Terima kasih atas feedback soal antarmuka jaringan. Masalah yang kamu laporkan memang cukup merepotkan.
Untuk sekarang, saya belum menemukan masalah dengan NAS saya, tapi memang slot RAM belum terisi semua (mahal :P, dan untuk saat ini belum perlu)