AI Experimente mit Ugreen iDX6011 Pro

[TeeKayEV]

Heute nahm ich endlich mein Ugreen iDX6011 Pro 64 GB in Betrieb. Das BIOS ist von Mitte 2025 und eigentlich für Meteor Lake - schade. BIOS-Updates haben die beiden einzigen verfügbaren UGOS Updates also nicht enthalten. Interessant ist, dass man mit STRG+F1 im BIOS sogar "Übertaktungsoptionen" freischalten kann - in Form von manuellem Anheben der Power Limits. Hab ich nicht gemacht, dafür müsste man sich erstmal anschauen, ob die Energieversorgung auf dem Board ausreichend dimensioniert wurde. Eigentlich wollte ich die Boot-SSD tauschen, aber ein kurzer Blick ins Gerät offenbarte, dass man es dafür offenbar komplett auseinandernehmen muss. Teardowns fand ich im Netz keine und durch ans Gehäuse geklebte WLAN-Antenne und das (für mich nutzlose) OLED ist der Auseinanderbau auch komplexer als bei den alten DXPs. Kurzerhand also die Boot-SSD mit TrueNAS überschrieben. UGOS traue ich nicht und die AI-Funktionen von Ugreen sind ohnehin nutzlos.

Ein erster Test mit llama-server in einer Custom App ist überraschend gut verlaufen. Ziel ist es, dass ich Kommandos mit kurzen Sprach- oder Textnachrichten ans NAS senden kann, die von einem lokalen LLM ausgewertet und dann in Aktionen umgesetzt werden.

Erster LLM-Text-Test​

qwen3-4b schaffte es bei der Textkommandoverarbeitung auf durchschnittlich 18,6 Token/s. Im Mittel brauchte die LLM-Verarbeitung einer Ein-Satz-Nachricht 3,3s.

Qwen3.6-35B-A3B kommt auf 13,8 Token/s und braucht 4,6s für die Verarbeitung.

Zumindest für die 1-Satz-Kommandos reicht das kleinere Modell aber aus, um auf 100% Verständnisquote zu kommen.

Für eine Notebook-iGPU, die laut interner Messung rund 9,1-9,3 W bei der Verarbeitung aufnimmt, finde ich das ausgezeichnet.

Zweiter Test mit Sprachnachrichten​

Nächster Test waren 14s, 30s und 33s lange Sprachnachrichten, die mit Whisper large-v3-turbo und large-v3-turbo q5_0 transkribiert werden sollten. Das dauerte im Mittel 13,8s beim ersten und 10,2s beim zweiten Modell.

Interessant ist, dass das Transkribieren der mehr als doppelt so langen Nachrichten beim großen Modell nur 3-4s länger dauerte und beim kleinen Modell teils genauso schnell war wie die kurze Nachricht.

Bei den komplexeren Kommandos aus den Sprachnachrichten war das kleine Qwen-Modell in der Interpretationsqualität wieder mit dem großen vergleichbar. Es erkannte ein Kommando nicht richtig - die Konsequenz war aber die gleiche, als wenn das Kommando verstanden worden wäre (Im wesentlichen "formatiere nichts"). Das kleine Modell kommt nach durchschnittlich 6,7s mit seiner Interpretation der Kommandos, das große nach 20,9s. Zusammen mit der Transkription also nach rund einer halben Minute. Halte ich immer noch für vertretbar. Zeitkritische Kommandos wie "Schalte Licht im Wohnzimmer an" sind kurz und nach wenigen Sekunden transkribiert und interpretiert. Und längere Kommandos sind zumindest bei mir nicht notwendigerweise sofort umzusetzen.

Dritter Test: Whisper und LLM parallel​

RAM ist ausreichend verfügbar. Und wie der nächste Abschnitt zeigt, ist es sinnvoll, alle verwendeten Modelle gleichzeitig im RAM zu halten und nicht zwischen ihnen zu switchen. Aber können sie auch gleichzeitig laufen? Also dritter Test, bei dem Whisper und das LLM parallel auf der iGPU rechnen. Whisper wird dabei 49% langsamer, das LLM 31%. Sinnvoller ist es also, beide Modelle im Speicher zu halten, aber immer nur eines gleichzeitig zu benutzen.

Übrigens: Bei allen Tests lief parallel der Upload von 6 TB Videodaten über 10 GBit Netzwerk auf das ZFS-Dateisystem.

Problem: Lange Ladezeit für Modelle​

Das Laden des 2,5 GB Qwen-Modells von einer WD SN850x SSD in den RAM bis zur Ausführung dauerte 70s - das sind 35 MB/s. Erster Verdacht war, dass irgendwas mit der SSD-Anbindung nicht stimmt. Aber ne, das Modell ist in 1s im RAM. Danach rechnet die CPU/GPU noch 69s mit niedriger Last rum, bevor es sich mit der Bearbeitung der Nachricht befasst. Was? Keine Ahnung. Prefill ist es nicht, das würde man am steigenden Energieverbrauch sehen. Gut, dass ich die 64 GB RAM wählte - damit müssen Modelle nicht entladen und andere geladen werden, sondern können einfach alle im Speicher bleiben.

Overall sehr geringe CPU-Nutzung​

Ich hab bestimmt 2h weitgehend automatisiert verschiedenste Szenarien durchtesten lassen. Immer wieder Modelle geladen, neue Inputs geliefert, Modelle entladen etcpp - mit im Hintergrund laufenden Videouplod über 10G LAN. Am Ende stand eine durchschnittliche CPU-Nutzung von 9,92% und eine CPU-Temperatur von 45°C im Report. TrueNAS weist GPU-Nutzung nicht separat aus.
Für ein AI-NAS hätte ich mir gewünscht, dass Ugreen eine CPU mit weniger CPU und mehr GPU-Leistung wählt. Der 358H hätte 50% mehr GPU-Cores gehabt, dafür weniger Power-CPU-Cores. Aber verglichen mit dem veralteten Schrott, den die Konkurrenz in ihre NAS baute, ist die verwendete CPU natürlich traumhaft.

Netzteil wirklich nervend​

Wer den in Tests angemerkten ständig an und ausgehenden Netzteillüfter nicht mag, kann problemlos ein anderes FlexATX Netzteil montieren. Da ist auch genug Platz im Gehäuse, wenn man längere Netzteile als die üblichen 15cm montieren will. Wenn man eine etwas leistungsfähigere GPU oder z.B. eine Highpoint RAID-Karte für 8-16 SSD einsetzen will, braucht man eh ein neues Netzteil mit PCIe-Stecker - denn den hat das von Ugreen verbaute Netzteil nicht. Problem ist dann, dass man das Gehäuse doch irgendwie aufbekommen muss, um die Stecker am Netzteil abzuziehen.

Lustige Beobachtung: Display als Ausgabe für die Shell​

TrueNAS nutzt das kleine Display auf dem NAS als Ausgabe für die Shell. Mit angeschlossener Tastatur kann man das Ding also sogar für irgendetwas rudimentär benutzen. Sonderlich praktisch ist es aber nicht, da rechts Zeichen abgeschnitten statt Zeilen umgebrochen werden.

Fazit: Zum Kickstarter-Preis zufrieden, zum aktuellen Preis überteuert​

Für die 1.560 Euro, die das Gerät für Reservierer bei Kickstarter kostete, würde ich es immer wieder kaufen. Auch für 2.000 Euro, vielleicht sogar für die ursprünglich genannten 2.600 Euro UVP. 64 GB LPCAMM2 Speicher kosten inzwischen, wenn man sie kriegt, auch 1.500 Euro. Aber 6.000 Euro, die Ugreen inzwischen haben will, sind gnadenlos überteuert. Für den Preis würde ich eher ein eigenes System mit richtiger GPU zusammenbauen.

 

[TeeKayEV]

Ergänzung zu meinem Wunsch, Ugreen hätte den 358H Prozessor gewählt. Der hat zwar mehr GPU-Kerne, dafür aber deutlich weniger PCIe Lanes und kein DMI zum Anschluss eines Chipsatzes. Ugreen hätte hier also Erweiterungsmöglichkeiten gegen mehr GPU-Leistung getauscht. Nach dem 358H hat der gewählte 255H schon die nächstbeste GPU, deutlich mehr PCIe Lanes und DMI zum Anschluss eines Chipsatzes für weitere Peripherie. Mit dem 358H hätte man das NAS wohl nicht in der Form realisieren können, wie es geschah.

 

[TeeKayEV]

Heute habe ich eine RTX 4090 über das von Ugreen zusammen mit dem NAS angebotenen Oculink eGPU Gehäuse verbunden. TrueNAS erkennt das Gerät problemlos. Erkenntnis 1: Der Netzteillüfter des 80 Plus Gold-zertifizierten Netzteils läuft dauerhaft und macht etwas Lärm. Da werd ich wohl demnächst ein besseres Titanium Netzteil einbauen. Da es Standard-ATX und das ganze Gehäuse verschraubt ist, stellt der Austausch kein Problem dar. Dank MSI geben die Spulen der GPU aber ohnehin hörbar Feedback über jede verarbeitete Datei.

RAG-Datenbank für LLM bauen​

Neuer Test war heute Chunking und Embedding. Ziel ist es, einen Bestand von rund 5000 PDFs, 120 GB, als RAG-Kontext einem lokal laufenden LLM zur Verfügung zu stellen. Da man nicht 120 GB Kontext einbinden kann - jedenfalls nicht mit meiner Hardware - werden die PDFs zuerst von der CPU in Chunks zerlegt - seitenweise, alternativ abschnittsweise, alternativ 2000-Token-weise. Wenn nun ein Prompt geschrieben wird, sucht das System nach Chunks, die die passenden Suchworte enthalten und lädt nur die in den Kontext, nicht komplette PDFs.

Mit diesen Chunks/Textschnipseln könnte ein LLM zwar etwas anfangen. Aber das denkt und rechnet ja nicht mit Wörtern, sondern Vektoren/Token. Damit der Text nicht jedesmal neu tokenisiert werden muss, kann man das einmalig tun - und die generierten Vektoren in einer Datenbank speichern. Das nennt sich dann Embedding. Das Embedding läuft auf der GPU.

Soweit mein Laien-Verständnis des Ganzen. Wenn da jemand mehr weiß oder etwas zu korrigieren hat, immer her damit.

iGPU war der Engpass, RTX 4090 langweilt sich​

Der Test ergab, dass die CPU das Embedding mit 0,7 Chunks pro Sekunde erledigt. Die iGPU kommt auf 13 Chunks pro Sekunde. Und die per Oculink angebundene RTX 4090 kommt auf 222. Die CPU kam während des Prozesses auf 6-25% Auslastung, wobei die 25% immer nur für Sekundenbruchteile anlagen (vermutlich beim Chunking einer neuen Datei).

Zum Start zeigte sich, dass die Auslastung der RTX 4090 nur bei 12% lag mit dem für die iGPU gebauten Skript.

Da musste Claude erstmal das Programm umschreiben, um die RTX mit mehr Daten zu versorgen. Mit einer Queue von 256 Chunks und 8 gleichzeitig zu verarbeitenden Chunks war das vorläufige Optimum von 222 Chunks/s erreicht (17x schneller als iGPU). Mehr gleichzeitige Prozesse verarbeite Ollama in der Standardconfig nicht. Da müssen morgen mal mehr Tests folgen.

iGPU, GPU und CPU arbeiten wunderbar parallel - und haben Reserven​

Also gabs noch einen zweiten Task: 4,5h Videomaterial transkribieren, während nebenbei das Chunking & Embedding läuft. Funktioniert erstaunlich gut - für die 4,5h braucht die iGPU rund 45min, während auf einem CPU-Kern das Chunking läuft und die Daten zum Embedding an die RTX weiterreicht.

Um den Test auf die Spitze zu treiben, wurde die Transkription auch noch auf die RTX geschoben, während dort parallel das Embedding lief. Die RTX war bei der Transkription rund 20x schneller als die iGPU. 4,5h Videos sind in 2min transkribiert. Das Embedding wurde 5,5% langsamer, weil eh das vorherige Chunking performancelimitierend war. Von den 24 GB VRAM waren nur 2,4 GB belegt. Und ich hatte das Gefühl, dass noch eher das Abrufen der Videos von den HDDs bremste, als dass die GPU limitierte. Claude sagt zu der Messung: "Whisper war während der Messung überwiegend im Leerlauf und hat nur gelegentlich gearbeitet." und "während dieser Transkriptionsschübe stehen unsere Einbettungsanfragen im CUDA-Zeitscheibenverfahren hinten an". Das fühlte sich also nur wie paralleles Arbeiten an. In der Realität liefen Whisper und Embedding abwechselnd - und trotzdem 20x schneller als die iGPU ohne nennenswerten Performanceverlust im 2. Task. Morgen muss ich die Videos mal von der SSD ausliefern lassen.

Für mich zeigt der Test, dass die RTX 4090 für diese Aufgaben overkill ist. Nach dem einmaligen Embedding des Bestands, der an einem Wochenende laufen könnte, ist die iGPU im Tagesbetrieb schnell genug, um die wenigen täglich hinzukommenden PDFs nebenbei zu verarbeiten, ohne dass dadurch Ressourcen für andere Tasks blockiert werden würden. Spracherkennung läuft auch schnell - durch, sogar besser als bei den vielen sehr kurzen Sprachkommandos, die gestern getestet wurden.

Mein vorläufiges Fazit ist, dass Ugreen mit NAS + eGPU-Gehäuse ein echtes Powerbundle baute, das out-of-the-box sogar mit einem Fremd-Betriebssystem problemlos läuft und für kleinere Automatisierungstasks eher Overkill ist. Zusammen mit einer starken externen GPU kann man sehr viel parallel machen, und hat trotzdem noch Leistungsreserven, für deren Ausnutzung mir derzeit die Ideen fehlen. Ausstehend ist natürlich noch der Test der aufgebauten RAG-Datenbank im Chatbot.

Noch gar nicht getestet habe ich den internen PCIe Port. Wie gesagt hat Highpoint PCIe Karten im Angebot, auf denen man 8-16 M.2 SSDs unterbringen kann. Ich hab jetzt nur eine PCIe3 Karte mit 8 Slots. Mit 8 TB SSDs kriegt man dann weitere 64 TB Speicher ins Gehäuse. Oder eine kleine GPU. Da das heute schon über die nur 4 Lanes am Oculink hervorragend lief, wird es mit den 8 Lanes am PCIe Slot erst Recht keine Überraschungen geben.