Ist es möglich, die Installation von Sicherheitsupdates und Firmware-Upgrades einfach zu trennen, wenn das der Hauptgrund dafür ist, dass Downgrades jetzt nicht mehr erlaubt sind? Dadurch könnten wir die Firmware downgraden und die notwendigen Sicherheitsupdates installieren.
Tolle Erklärung, Sam, und das ergibt aus Compliance-Sicht wirklich Sinn. Ich wollte nur sicherstellen, dass der Rollback-Weg eine gültige Option beim Support-Team ist und dass ich mich nicht über mehrere Wochen bis zum „Level 5“-Support hocharbeiten muss, um jemanden zu finden, der technisch versiert genug ist, einen Rollback durchzuführen. Hoffen wir mal, dass die Rollbacks selten nötig sind. Vielen Dank nochmal, dass du dir die Zeit genommen hast, das zu erklären.
Hat jemand eine Idee, wann wir endlich QTS 6 zu sehen bekommen?
Danke für die Klarstellung, Sam, aber es wäre schön gewesen, wenn die Möglichkeit, den Support wegen eines Rollbacks zu kontaktieren, erklärt worden wäre – das war nicht der Fall.
Nicht jeder ist in der EU, daher gilt die Cybersicherheits-Regulierung nicht für alle eure Kunden. Ich verstehe, dass dies in anderen Ländern in Zukunft sehr wahrscheinlich ebenfalls der Fall sein wird, und sehe deshalb den Grund hinter der Entscheidung ein.
Die Antwortzeit eures Support-Teams lässt oft zu wünschen übrig, wobei der einzige verfügbare Kanal die E-Mail ist. In vielen Organisationen liegen die Service-Level für E-Mail-Antworten im Allgemeinen zwischen 12 und 24 Stunden. Das gilt aber nicht für technischen Support im Computerbereich, wo andere Support-Kanäle existieren. Bei QNAP ist das nicht der Fall. Es kann 6–8 Stunden dauern, bis man eine erste Antwort bekommt – wenn man das Glück hat, das Problem unter der Woche zu haben. Am späten Freitag oder am Wochenende hat man Pech. Folgeantworten nach einer Reaktion des Kunden können genauso lange dauern. Das ist für viele einfach nicht praktikabel. Das Ticket, das ich am 14. Juli eröffnet habe? Heute, am 21. Juli, wurde endlich beschlossen, über HelpDesk Zugriff auf mein System anzufordern. Zum Glück konnte ich das Problem schon selbst lösen, aber sie wollen trotzdem weiter untersuchen.
Ich habe das Gefühl, wenn sich eure Kundenbasis zu QuTS Hero 6 bewegt und die ersten Probleme auftreten, wird die Unzufriedenheit in diesem Punkt noch weiter zunehmen.
Das ist typisch für Gesetze, die von Leuten gemacht werden, die nicht in einer Branche involviert sind. Die fehlende Möglichkeit, ein Downgrade durchzuführen, führt dazu, dass viele lieber lange bei einer funktionierenden Firmware bleiben und dadurch die neuesten Sicherheitsupdates verpassen. Wenn du an einem Freitagabend oder am Wochenende ein Firmware-Update auf eine Produktionsmaschine aufspielst und dabei etwas kaputtgeht, was willst du am Montag den Mitarbeitern sagen?
Um ehrlich zu sein, würde ich wahrscheinlich einiges sagen – und nichts davon wäre schmeichelhaft!
In den Energieeinstellungen gibt es eine Option für den EU-Schlafmodus. Warum sollte man diese Einstellung nicht mit der Möglichkeit zum Zurücksetzen verknüpfen? Vermutlich wären diejenigen in der EU verpflichtet, dieses Kästchen zu aktivieren. Falls sie das nicht tun, ist das nicht QNAPs Problem. Alternativ könnte der Rest der Welt Gesetze erlassen, die eine Rücksetzung vorschreiben.
Oder wenn du das NAS einrichtest, füge statt China oder Rest der Welt die EU als Auswahlmöglichkeit hinzu.
Aus reiner Neugier habe ich nach diesem EU-Schlafmodus gesucht – ich finde ihn jedoch nicht in den Energieeinstellungen von QuTS Hero. Vielleicht gibt es ihn nur für QTS, oder meine Hardware unterstützt ihn einfach nicht. Es handelt sich um ein TS-h1887XU-RP, also wird er wohl nicht unterstützt, da es sich um ein Rackmount-Gerät handelt.
„Systemsteuerung“, „Stromversorgung“ , „Eup-Modus“ sowohl in QTS als auch in QuTS.
Wahrscheinlich bedeutet das, dass dein Gerät im Energiesparmodus immer weniger als 1 Watt verbraucht.
TVS-AIH1688ATX Upgrade von QuTS Hero h6.0.0.3500 auf QuTS Hero 6.0.1.3550 ohne Probleme.
Nvidia 4000 Blackwell GPU
QXP-800S
192 GB RAM
Upgrade erfolgte über das Control Panel. Ich habe das neue OS-Firmware, den Nvidia-Kernel und die Advanced Network-Dateien heruntergeladen, bevor ich das Upgrade durchgeführt habe. Um das Upgrade zu starten, nutzte ich das Control Panel Firmware-Update und die Firmware-Datei, die ich von QNAP heruntergeladen hatte. Installation verlief problemlos, dann hat das Gerät zweimal neu gestartet und kam mit einer fehlgeschlagenen Nvidia-Installation und Problemen mit dem Netzwerkadapter wieder hoch.
Ich habe nun den bestehenden NVIDIA-Treiber deinstalliert (nicht den Kernel) und anschließend den neuen Kernel-Treiber sowie den Advanced Network-Treiber installiert. Nach einem weiteren Neustart habe ich aus dem Store den NVIDIA-Treiber erneut installiert und wieder neu gestartet. Als das Gerät wieder hochfuhr, hat alles funktioniert. QWEN, Plex, JellyFin etc. laufen und nutzen die 4000 wie vorher.
Hallo, baust du damit KI? Ich kann noch nicht sagen, ob es daran liegt, aber Modelle wie Gemma 4 (quantifiziert) oder Qwen3.6 (quantifiziert, nutzt 17 GB RAM auf meiner RTX Pro 4000), die vorher auf der GPU geladen wurden, können das jetzt nicht mehr (bei Ollama).
Ich bin von Ollama zurück auf Version 0.30.8 gegangen, aber das Problem bleibt das gleiche.
Hallo,
vielen Dank für deine Antwort.
Ich hatte die Methode angewendet, Nvidia-Treiber zu deinstallieren, die Kernel-Treiber von der QNAP-Website zu aktualisieren und dann die Treiber erneut zu installieren.
Danach konnte ich Ollama eine Weile mit Auslastung auf der GPU nutzen. Aber seit einigen Tagen ist das nicht mehr möglich, nur noch auf der CPU (Befehl: ollama ps), obwohl die Karte im Container (nvidia-smi) vorhanden ist.
Ich bin gezwungen, das Ende einer Überprüfung einer Festplatte abzuwarten, die gerade einen Fehler zeigt, bevor ich Wartungsmaßnahmen durchführen kann (erneute Deinstallation der Treiber).
Außerdem stelle ich bei einem anderen Problem fest, dass manche Einstellungen, die intern im OS synchronisiert werden sollten, es nicht tun (das verhindert aktuell die Installation einer neuen Version von RClone als qpkg): QNAP - [RClone] The system volume is missing | Forum des NAS : Synology, Qnap, Asustor...
Aber dieses Thema weicht vom ursprünglichen Thema ab.
Hallo,
vielen Dank für die Details. Sie sind sehr hilfreich, da sie darauf hindeuten, dass die Ursache nicht bei den Treibern liegt.
Der entscheidende Punkt in deiner Nachricht ist: nvidia-smi erkennt die Karte im Container, aber ollama ps meldet CPU. Diese Kombination bedeutet, dass deine Treiber und dein Container-Runtime korrekt funktionieren. Wenn der Treiber oder die NVIDIA-Container-Runtime fehlerhaft wären, würde nvidia-smi im Container scheitern. Das ist aber nicht der Fall. Die Karte ist sichtbar und wird korrekt durchgeleitet.
Was fehlschlägt, ist die CUDA-Initialisierung, wenn Ollama das Modell lädt. Das ist ein bekanntes Problem, das auch auf meinem Rechner auftritt. Wenn die GPU einige Zeit im Leerlauf ist, scheitert die CUDA-Initialisierung und Ollama weicht stillschweigend auf die CPU aus. Es gibt keine Fehlermeldung. Das Modell antwortet weiterhin, aber etwa 20 Mal langsamer.
Bitte warte nicht auf die Plattenprüfung. Du musst die Treiber nicht erneut deinstallieren. Die Lösung ist lediglich, den Ollama-Container neu zu starten. Das dauert nur wenige Sekunden und betrifft weder deine Treiber, Pakete noch deinen Speicher:
docker restart ollama
docker exec ollama ollama ps
Nach dem Neustart lade dein Modell und prüfe erneut ollama ps. Zeigt die Spalte PROCESSOR jetzt GPU an, haben wir das gleiche Problem und das ist dein Workaround. Zeigt sie weiterhin CPU, ist dein Problem anders gelagert, und das ist eine wichtige Information.
Auch dein zeitlicher Verlauf passt dazu. Nach der Treiber-Neuinstallation funktionierte es, dann wurde es nach ein paar Tagen schlechter. Eine fehlerhafte Treiberinstallation schlägt immer sofort und permanent fehl. Sie funktioniert nicht erst korrekt und verschlechtert sich dann.
Um das Problem zu verhindern, setze OLLAMA_KEEP_ALIVE=24h in der Ollama-Container-Umgebung. Dadurch bleibt das Modell im VRAM vorhanden und die Leerlaufphase, die die Fehler auslöst, tritt nicht auf.
Noch ein letzter, respektvoll gemeinter Hinweis: Du erwähnst eine Festplatte mit Fehlern und ein fehlendes Systemvolume. Das sind ernstere Probleme als das GPU-Problem. Ich würde die Festplatte und das Systemvolume zuerst reparieren. Der NVIDIA-Treiber ist als QPKG-Paket installiert, sodass ein beschädigtes Systemvolume auch das Paket-System beeinträchtigen kann. Es ist schwierig, die GPU zu diagnostizieren, solange die Speicherverwaltung fehlerhaft ist.
Sag uns bitte, was ollama ps nach dem Container-Neustart anzeigt.
Ich habe den Container mehrmals über Container Station neu gestartet, allerdings ohne Erfolg, um den optimalen Betrieb wiederherzustellen (nur GPU und nicht CPU). Häufig konnte das Modell nur durch einen Neustart des NAS wieder auf der GPU ausgeführt werden.
Jedenfalls überlege ich mittlerweile, einen NAS-Reset mit einer ordentlichen Neuinstallation der Firmware durchzuführen, um diese sich häufenden Probleme zu lösen (möglicherweise hängen sie mit der Nutzung der QuTS hero 6 Beta oder damit zusammen, dass ich den Systempool im laufenden Betrieb mit dem Support neu erstellt habe).
achimede333,
Es tut mir leid, dass du Probleme damit hast. Um ehrlich zu sein, haben mich deine ursprünglichen Beiträge über RAG und den 4000 Blackwell überhaupt erst motiviert, lokal RAG auszuprobieren. Qwen feile ich noch immer weiter; bisher ist der Kompromiss für mich, dass es langsamer läuft als mir lieb ist, aber dafür privat.
Das Dashboard, das ich zur Überwachung des Servers nutze, ist meine eigene Entwicklung. Es überwacht alle Container und Dienste und gibt mir zusätzlich die Möglichkeit, sie zu steuern: starten, stoppen, Status abfragen und ignorieren (für Spezialfälle). Container Station verwende ich nicht. Ich schreibe alle Docker Compose Dateien selbst und starte die Container darüber.
Im Snapshot unten sind alle Widgets geladen. Was du nicht sehen kannst, ist das eingebaute Fehler-Reporting. Seit dem Kauf habe ich Speicherprobleme mit dem NAS gehabt (MCE-Fehler), die schließlich auf den Speichercontroller des Motherboards zurückgeführt werden konnten. Morgen kommt es zur Reparatur. Wegen ständiger, spontaner Neustarts durch das Problem musste ich einen Weg entwickeln, um sofort einen Überblick über das Geschehen auf dem NAS zu bekommen. So ist das Dashboard entstanden, und mittlerweile nutze ich es täglich, um das NAS zu überwachen und schnell Probleme mit Containern, dem Netzwerk usw. zu erkennen.
Das andere, was ich gelernt habe: Die NIC-Treiber für den atlantic-Chip, der im TVS-AIH1688ATX verbaut ist, wurden von Atlantic an Marvell abgegeben und das ursprüngliche GitHub-Repo wurde aufgegeben. Ich weiß nicht, wer die Treiber jetzt pflegt, aber es gibt Probleme, die zu mindestens zwei spontanen Neustarts geführt haben – unabhängig von den Speicherproblemen.
Faustregel: NIC-Treibereinstellungen nicht ändern, solange etwas Wichtiges läuft. Es besteht eine 50/50 Chance auf einen Neustart bei mir. Änderungen wie Ring-resize bringen immer einen Neustart. Ich habe auch verfolgt, dass das NIC Pakete verliert. Unter Netzwerk sieht man meinen Tracker bei 192 verlorenen Paketen. Das ist mein aktueller Ausgangswert; wenn der zunimmt, weiß ich, dass ich die Netzwerkverbindung resetten muss. Die Mainboard-Kühlung hilft scheinbar, deshalb laufen meine Gehäuselüfter dauerhaft auf 55%, die CPU auf 50%.
Ich melde weiter alles, was ich finde, und bin zuversichtlich, dass QNAP die Bugs nach und nach behebt, wenn wir sie melden – aber manchmal macht es das eben schwierig. Teil des Spaßes mit Beta-Firmware. 
Ja, ich hatte bemerkt, dass du an dem anderen Gespräch teilgenommen hast, und dass du auch eine RTX Pro 4000 hast, hat mich schon gewundert, ob du nicht genauso hineingesprungen bist wie ich :).
Ich teste Ollama mit Open WebUI als Oberfläche und bin zur Testphase von Gemma 4 zu Qwen3.6 gewechselt.
Es dauert lange, die Elemente richtig zu verfeinern, und ich muss gleichzeitig noch viele andere Dinge verwalten. Die Unannehmlichkeiten der Treiber nerven mich deshalb und kosten mich Zeit (ich spiele mit dem Gedanken, auf llama.cpp umzusteigen, aber das dauert noch länger…, die Leistung wäre allerdings besser).
Deine Oberfläche ist wirklich nice, und vor allem, die Probleme beim NAS-Speicher zu finden…
Momentan ist es eine Seagate mit 28TB, und SMART meldet schon eine Warnung… Sie ist nicht alt, ich warte jetzt erstmal die Scan-Ergebnisse ab, sehe, ob das neue Firmware irgendwas ändert, und ansonsten: RMA…
Danke für dein Feedback zur Netzwerkschnittstelle. Echt nervig, was du da als Problem beschreibst.
Bisher habe ich bei meinem NAS keine Probleme bemerkt, aber ich habe auch nicht alle RAM-Slots belegt (viel zu teuer :P, und im Moment auch nicht nötig).