Lese-Ansicht

Framework Desktop ruhig gestellt

Wie ich hier berichtet habe, ist der Framework Desktop zwar die meiste Zeit leise, aber ca. alle zehn Minute heult der Netzteillüfter für ca. 30 Sekunden — selbst dann, wenn das Gerät mehr oder weniger im Leerlauf läuft. Das ist extrem störend. Es hat zwei Versuche gebraucht, aber jetzt herrscht Ruhe.

Das Problem

Kurz zusammengefasst: Der Framework Desktop hat eine wunderbare CPU-Kühlung mit einem 120mm-Lüfter. Dieser kann aber das eingebaute Netzteil nicht kühlen. Das gekapselte Netzteil besitzt einen eigenen 40mm-Lüfter (PSU), der zwar die meiste Zeit still steht, aber dafür im Betrieb umso unangenehmer heult.

  • Die Luftzufuhr zum Netzteil wird durch eine enge Röhre und das Gitter des Gehäuses behindert.
  • Das Netzteil ist nur mäßig effizient, was sich vermutlich im Leerlaufbetrieb besonders stark auswirkt.

  • Im Netzteil steht die Luft. Diese wird immer heißer.

  • Ca. 1/2 h nach dem Einschalten wird erstmals eine kritische Temperatur erreicht. Nun startet unvermittelt der winzige Lüfter. Eine halbe Minute reicht, um das Netzteil mit frischer Luft etwas abzukühlen — aber nach ca. 10 Minuten beginnt das Spiel von neuem.

  • Der Netzteillüfter kann nicht durch das BIOS gesteuert werden.

Lösungsversuch 1 (unbefriedigend)

Aus dem Framework-Forum stammt die Idee, das Netzteil durch einen normalerweise langsam laufenden externen Lüfter regelmäßig zu kühlen. Diese Idee habe ich aufgegriffen. Im ersten Versuch habe ich einen 60-mm-Lüfter mit 5V-Versorgung verwendet. Diesen habe ich über eine USB-Buchse mit Strom versorgt, mit einem ziemlich hässlichen Poti (amazon-Link) zur Regulierung der Drehzahl. Der Lüfter muss so eingebaut werden, dass er nach außen bläst, die warme Luft aus dem Netzteil also heraussaugt.

Erster Versuch mit USB-Lüfter

Prinziell war bereits dieser erste Versuch von Erfolg gekrönt. Der interne PSU-Lüfter schaltete sich nicht mehr ein.

Allerdings ist die Konstruktion unschön. Die minimale, per Poti einstellbare Drehzahl war so hoch, dass mich das relativ leise Geräusch des externen Lüfters immer noch störte. Aber prinzipiell war bewiesen, dass bereits eine minimale Durchlüftung des Netzteils ausreicht, um bei geringer Belastung das regelmäßige Aufheulen des PSU-Lüfters zu verhindern.

Lösungsversuch 2 (funktioniert)

Zwei Dinge sind beim ersten Versuch nachteilig: Einerseits kann der Lüfter nicht so weit nach unten hin reguliert werden (also mit niedriger Drehzahl betrieben werden), dass er für mich unhörbar ist. Andererseits fehlt dem Lüfter die »Intelligenz«, unter Last höher zu drehen.

Nun bietet der Framework Desktop einen Anschluss für einen zweiten, internen Gehäuselüfter. phoronix hat damit experimentiert, aber der Nutzen ist überschaubar.

Meine Idee war nun, diesen Anschluss für einen externen Lüfter zu verwenden. Die einzige Hürde besteht darin, ein Kabel nach außen zu führen. Dazu muss ein Loch in das Belüftungsgitter gebohrt werden. Am besten wäre es, den Framework Desktop dazu zu zerlegen, bis die Rückwand komplett entfernt werden kann. Das war mir zu mühsam. Ich habe nur den CPU-Lüfter ausgebaut, den Innenraum abgedeckt (damit keine Eisenspäne herumfliegen) und dann mit einem Metallbohrer ein Loch in das Lüftungsgitter gebohrt und mit einem Staubsauger alle Späne sofort weggesaugt. Wirklich elegant ist das Ergebnis nicht, aber es erfüllt seinen Zweck.

Anschluss des externen Lüfters (rechts im Bild, »Sys Fan 2«)

Anschließend habe ich ein 10-cm-Verlängerskabel für den Lüfter nach außen geleitet und den eigentlichen Lüfter dort angeschlossen. Die Lüftermontage habe ich mit einer festen Plastikfolie (ausgeschnitten aus der Rückseite eines Schnellhefters) und viel Klebeband so bewerkstelligt, dass zwischen Gehäuse und Lüfter ein Luftkanal von ca. 1 cm entsteht. Wichtig: Der Lüfter muss so montiert werden, dass er die Luft aus dem Netzteil nach außen saugt/bläst.

Zweiter Versuch mit 12-V-Lüfter, der als »System Fan 2« über das BIOS gesteuert wird
Aus der Rückseite eines Schnellhefters habe ich einen Kanal für den externen Lüfter gebastelt

Zuletzt habe ich das gesamte Gehäuse mit ein paar Filzgleitern höher gestellt, so dass ein Wärmetransport von der Unterseite des Gehäuses möglich ist. Ich vermute, dass diese Maßnahme nur im CPU-intensiven Dauerbetrieb relevant ist. Solange der Framework Desktop nur gelegentlich unter Last läuft, wird die Unterseite nicht besonders warm.

Filzgleiter erhöhen den Bodenabstand

Bleibt noch die Lüftersteuerung: Beim CPU-Lüfter habe ich CPU Fan min duty % auf 25 Prozent eingestellt. Der Lüfter dreht dann so langsam, dass ich ihn nicht höre, sorgt aber dennoch für einen steten Luftzug durch das Gehäuse. Erst unter Last dreht der CPU-Lüfter stärker auf und wird hörbar.

Der externe Lüfter wird über Chassis Fan 2 gesteuert. Ich habe Chassis 2 Fan min duty % auf 30 Prozent gestellt. Wiederum war das Ziel, einen Wert zu wählen, der für mich unterhalb der Hör/Störschwelle ist, aber gleichzeitig für eine dauerhafte Durchlüftung des engen Netzteilkanals zu sorgen. Als Fan Sensor habe ich Mainboard Power eingestellt, aber vermutlich würde jeder andere Temperatursensor ebenso gut funktionieren. Das Netzteil hat keinen eigenen Sensor. Auf jeden Fall ist es sinnvoll, das Netzteil intensiver zu kühlen, wenn die CPU unter Last heiß wird. Naturgemäß sind meine Einstellungen persönliche Erfahrungswerte, abhängig vom eingesetzten Lüfter (ich habe den Noctua NF-A6x25 PWM verwendet, amazon-Link), vom Nutzungsverhalten und vom Aufstellungsort.

BIOS/EFI-Einstellungen für den »System Fan 2«

Ergebnis

Ich bin zufrieden. Im normalen Desktopbetrieb ist der Rechner jetzt (für meine Ohren) lautlos. Wenn ich den Kernel kompiliere oder Sprachmodelle ausführe, die CPU also unter Volllast arbeitet, drehen die beiden Lüfter (CPU-Lüfter intern, mein Netzteil-Lüfter extern) langsam hoch und sind deutlich hörbar, aber auf jeden Fall in einer viel angenehmeren Tonlage als bisher. Den internen PSU-Kühler mit seiner extrem unangenehmen Geräuschkulisse habe ich seit der Inbetriebnahme des externen Lüfters nie mehr gehört.

Der außen befestigte Lüfter ist zugegebenermaßen ein hässlicher Hack für ein 2000-€-Gerät. Bei normalen Aufstellung des Rechners am oder unter dem Schreibtisch stört die Konstruktion aber nicht. Mir ist auf jeden Fall die Akustik wichtiger als die Optik.

Für einen vollständig lautlosen Betrieb müsste das Framework-Mainboard in ein größeres Gehäuse gebaut und mit einem effizienteren, größeren Netzteil versorgt werden. Dazu habe ich keine Zeit/Lust/Geld. Die hier präsentierte Lösung verursacht weniger als 20 € Kosten und lässt sich in einer Stunde bewerkstelligen.

Quellen/Links

  •  

Toolbx

Beim Experimentieren mit KI-Sprachmodellen bin ich über das Projekt »Toolbx« gestolpert. Damit können Sie unkompliziert gekapselte Software-Umgebungen erzeugen und ausführen.

Toolbx hat große Ähnlichkeiten mit Container-Tools und nutzt deren Infrastruktur, unter Fedora die von Podman. Es gibt aber einen grundlegenden Unterschied zwischen Docker/Podman auf der einen und Toolbx auf der anderen Seite: Docker, Podman & Co. versuchen die ausgeführten Container sicherheitstechnisch möglichst gut vom Host-System zu isolieren. Genau das macht Toolbx nicht! Im Gegenteil, per Toolbx ausgeführte Programme können auf das Heimatverzeichnis des aktiven Benutzers sowie auf das /dev-Verzeichnis zugreifen, Wayland nutzen, Netzwerkschnittstellen bedienen, im Journal protokollieren, die GPU nutzen usw.

Toolbx wurde ursprünglich als Werkzeug zur Software-Installation in Distributionen auf der Basis von OSTree konzipiert (Fedora CoreOS, Siverblue etc.). Dieser Artikel soll als eine Art Crash-Kurs dienen, wobei ich mit explizit auf Fedora als Host-Betriebssystem beziehe. Grundwissen zu Podman/Docker setze ich voraus.

Mehr Details gibt die Projektdokumentation. Beachten Sie, dass die offizielle Bezeichnung des Projekts »Toolbx« ohne »o« in »box« lautet, auch wenn das zentrale Kommando toolbox heißt und wenn die damit erzeugten Umgebungen üblicherweise Toolboxes genannt werden.

Hello, Toolbx!

Das Kommando toolbox aus dem gleichnamigen Paket wird ohne sudo ausgeführt. In der Minimalvariante erzeugen Sie mit toolbox <name> eine neue Toolbox, die als Basis ein Image Ihrer Host-Distribution verwendet. Wenn Sie also wie ich in diesen Beispielen unter Fedora arbeiten, fragt toolbox beim ersten Aufruf, ob es die Fedora-Toolbox herunterladen soll:

toolbox create test1

  Image required to create Toolbx container.
  Download registry.fedoraproject.org/fedora-toolbox:43 (356.7MB)? [y/N]: y
  Created container: test1

Wenn Sie als Basis eine andere Distribution verwenden möchten, geben Sie den Distributionsnamen und die Versionsnummer in zwei Optionen an:

toolbox create --distro rhel --release 9.7 rhel97

Das Kommando toolbox list gibt einen Überblick, welche Images Sie heruntergeladen haben und welche Toolboxes (in der Podman/Docker-Nomenklatur: welche Container) Sie erzeugt haben:

toolbox list

  IMAGE ID      IMAGE NAME                                    CREATED
  f06fdd638830  registry.access.redhat.com/ubi9/toolbox:9.7   3 days ago
  b1cc6a02cef9  registry.fedoraproject.org/fedora-toolbox:43  About an hour ago

  CONTAINER ID  CONTAINER NAME     CREATED         STATUS   IMAGE NAME
  695e17331b4a  llama-vulkan-radv  2 days ago      exited   docker.io/kyuz0/amd-strix-halo-toolboxes:vulkan-radv
  dc8fd94977a0  rhel97             22 seconds ago  created  registry.access.redhat.com/ubi9/toolbox:9.7
  dd7d51c65852  test1              18 minutes ago  created  registry.fedoraproject.org/fedora-toolbox:43

Um eine Toolbox aktiv zu nutzen, aktivieren Sie diese mit toolbox enter. Damit starten Sie im Terminal eine neue Session. Sie erkennen nur am veränderten Prompt, dass Sie sich nun in einer anderen Umgebung befinden. Sie haben weiterhin vollen Zugriff auf Ihr Heimatverzeichnis; die restlichen Verzeichnisse stammen aber überwiegend von Toolbox-Container. Hinter den Kulissen setzt sich der in der Toolbox sichtbare Verzeichnisbaum aus einer vollkommen unübersichtlichen Ansammlung von Dateisystem-Mounts zusammen. findmnt liefert eine über 350 Zeilen lange Auflistung!

toolbox enter test1

[kofler@toolbx ~]$ cat /etc/os-release 

  NAME="Fedora Linux"
  VERSION="43 (Toolbx Container Image)"
  RELEASE_TYPE=stable
  ID=fedora
  VERSION_ID=43
  ...

[kofler@toolbx ~]$ findmnt | wc -l

  359

Innerhalb einer Fedora-Toolbox können Sie wie üblich mit rpm und dnf Pakete verwalten. Standardmäßig ist nur ein relativ kleines Subset an Paketen installiert.

[kofler@toolbx ~]$ rpm -qa | wc -l

  340

Innerhalb der Toolbox können Sie mit sudo administrative Aufgaben erledigen, z.B. sudo dnf install <pname>. Dabei ist kein Passwort erforderlich.

ps ax listet alle Prozesse auf, sowohl die der Toolbox als auch alle anderen des Hostsystems!

Mit exit oder Strg+D verlassen Sie die Toolbox. Sie können Sie später mit toolbox enter <name> wieder reaktivieren. Alle zuvor durchgeführten Änderungen gelten weiterhin. (Hinter den Kulissen verwendet das Toolbx-Projekt einen Podman-Container und speichert Toolbox-lokalen Änderungen in einem Overlay-Dateisystem.)

Bei ersten Experimenten mit Toolbx ist mitunter schwer nachzuvollziehen, welche Dateien/Einstellungen Toolbox-lokal sind und welche vom Host übernommen werden. Beispielsweise ist /etc/passwd eine Toolbox-lokale Datei. Allerdings wurden beim Erzeugen dieser Datei die Einstellungen Ihres lokalen Accounts von der Host-weiten Datei /etc/passwd übernommen. Wenn Sie also auf Host-Ebene Fish als Shell verwenden, ist /bin/fish auch in der Toolbox-lokalen passwd-Datei enthalten. Das ist insofern problematisch, als im Standard-Image für Fedora und RHEL zwar die Bash enthalten ist, nicht aber die Fish. In diesem Fall erscheint beim Start der Toolbox eine Fehlermeldung, die Bash wird als Fallback verwendet:

toolbox enter test1

  bash: Zeile 1: /bin/fish: Datei oder Verzeichnis nicht gefunden
  Error: command /bin/fish not found in container test1
  Using /bin/bash instead.

Es spricht aber natürlich nichts dagegen, die Fish zu installieren:

[kofler@toolbx ~]$ sudo dnf install fish

Auf Host-Ebene liefern die Kommandos podman ps -a und podman images sowohl herkömmliche Podman-Container und -Images als auch Toolboxes. Aus Podman-Sicht gibt es keinen Unterschied. Der Unterschied zwischen einem Podman-Container und einer Toolbox ergibt sich erst durch die Ausführung (bei Podman mit sehr strenger Isolierung zwischen Container und Host, bei Toolbox hingegen ohne diese Isolierung).

Eigene Toolboxes erzeugen

Eigene Toolboxes richten Sie ein wie eigene Podman-Images. Die Ausgangsbasis ist ein Containerfile, das die gleiche Syntax wie ein Dockerfile hat:

# Datei my-directory/Containerfile
FROM registry.fedoraproject.org/fedora-toolbox:43

# Add metadata labels
ARG NAME=my-toolbox
ARG VERSION=43
LABEL com.github.containers.toolbox="true" \
      name="$NAME" \
      version="$VERSION" \
      usage="This image is meant to be used with the toolbox(1) command" \
      summary="Custom Fedora Toolbx with joe and fish"

# Install your software
RUN dnf --assumeyes install \
    fish \
    joe

# Clean up
RUN dnf clean all

Mit podman build erzeugen Sie das entsprechende lokale Image:

cd my-directory

podman build --squash --tag localhost/my-dev-toolbox:43 .

Jetzt können Sie auf dieser Basis eine eigene Toolbox einrichten:

toolbox create --image localhost/my-toolbox:43 test2

toolbox enter test2

KI-Sprachmodelle mit Toolbx ausführen

Das Toolbx-Projekt bietet eine großartige Basis, um GPU-Bibliotheken und KI-Programme auszuprobieren, ohne die erforderlichen Bibliotheken auf Systemebene zu installieren. Eine ganze Sammlung von KI-Toolboxes zum Test diverser Software-Umgebungen für llama.cpp finden Sie auf GitHub, beispielsweise hier:

https://github.com/kyuz0/amd-strix-halo-toolboxes

toolbox create erzeugt eine Toolbox mit dem Namen llama-vulkan-radv auf Basis des Images vulkan-radv, das der Entwickler kyuz0 im Docker Hub hinterlegt hat. Das alleinstehende Kürzel -- trennt die toolbox-Optionen von denen für Podman/Docker. Die folgenden drei Optionen sind erforderlich, um der Toolbox direkten Zugriff auf das Device der GPU zu geben.

toolbox create llama-vulkan-radv \
  --image docker.io/kyuz0/amd-strix-halo-toolboxes:vulkan-radv \
  -- --device /dev/dri \
     --group-add video \
     --security-opt seccomp=unconfined

Mit toolbox enter starten Sie die Toolbox. Innerhalb der Toolbox steht das Kommando llama-cli zur Verfügung. In einem ersten Schritt können Sie testen, ob diese Bibliothek zur Ausführung von Sprachmodellen eine GPU findet.

toolbox enter llama-vulkan-radv

llama-cli --list-devices

  ggml_vulkan: Found 1 Vulkan devices:
  ggml_vulkan: 0 = Radeon 8060S Graphics (RADV GFX1151) (radv) | 
    uma: 1 | fp16: 1 | bf16: 0 | warp size: 64 | 
    shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
  Available devices:
    Vulkan0: Radeon 8060S Graphics (RADV GFX1151) 
    (107008 MiB, 99195 MiB free)

Wenn Sie auf Ihrem Rechner noch keine Sprachmodelle heruntergeladen haben, finden Sie geeignete Modelle unter https://huggingface.co. Ich habe stattdessen im folgenden Kommando ein Sprachmodell ausgeführt, das ich zuvor in LM Studio heruntergeladen haben. Wie gesagt: In der Toolbox haben Sie vollen Zugriff auf alle Dateien in Ihrem Home-Verzeichnis!

llama-server \
  -m  /home/kofler/.lmstudio/models/lmstudio-community/gpt-oss-20b-GGUF/gpt-oss-20b-MXFP4.gguf \
  -c 32000 -ngl 999 -fa 1 --no-mmap

Dabei gibt -c die maximale Kontextgröße an. -ngl bestimmt die Anzahl der Layer, die von der GPU verarbeitet werden sollen (alle). -fa 1 aktiviert Flash Attention. Das ist eine Grundvoraussetzung für eine effiziente Ausführung moderner Modelle. --no-mmap bewirkt, dass das ganze Modell zuerst in den Arbeitsspeicher geladen wird. (Die Alternative wären ein Memory-Mapping der Datei.) Der Server kann auf der Adresse localhost:8080 über eine Weboberfläche bedient werden.

Weboberfläche zu llama.cpp. Dieses Programm wird in einer Toolbox ausgeführt.

Anstatt erste Experimente in der Weboberfläche durchzuführen, können Sie mit dem folgenden Kommando einen einfachen Benchmarktest ausführen. Die pp-Ergebnisse beziehen sich auf das Prompt Processing, also die Verarbeitung des Prompts zu Input Token. tg bezeichnet die Token Generation, also die Produktion der Antwort.

llama-bench \
  -m /home/kofler/.lmstudio/.../gpt-oss-20b-MXFP4.gguf \
  -ngl 999 -fa 1

  model                       size  params ...  test   t/s
  gpt-oss 20B MXFP4 MoE  11.27 GiB   20.91     pp512  1219
  gpt-oss 20B MXFP4 MoE  11.27 GiB   20.91     tg128    78

Quellen/Links

  •  

Red Hat setzt auf KI Sicherheit und übernimmt Chatterbox Labs

Red Hat hat eine weitere Akquisition im Bereich künstliche Intelligenz bekanntgegeben. Nach Neural Magic im vergangenen Jahr folgt nun Chatterbox Labs, ein Unternehmen mit Spezialisierung auf Testverfahren für KI Modelle und Schutzmechanismen für generative Systeme. Chatterbox Labs wurde 2011 gegründet und entwickelte die AIMI Plattform. Diese liefert quantitative Risikometriken für KI und bietet zusätzliche Funktionen […]

Der Beitrag Red Hat setzt auf KI Sicherheit und übernimmt Chatterbox Labs erschien zuerst auf fosstopia.

  •  

Calibre-Community diskutiert über KI

Die beliebte E-Book-Verwaltungssoftware Calibre erhielt Anfang Dezember mit Version 8.16 Zugang zu KI. Über lokale oder externe LLMs können unter anderem Fragen beantwortet werden - oder auch nicht.

  •  

Waterfox entscheidet sich gegen KI

Der beliebte Firefox-Fork Waterfox bezieht Stellung zu KI. LLMs sollen in Waterfox keinen Platz haben. Waterfox soll auch künftig für Vertrauenswürdigkeit, Transparenz und Nutzerkontrolle stehen.

  •  

Framework Desktop

Die Kinder bekommen ihre Weihnachtsgeschenke am 24.12., bei mir war diesmal zufällig schon eine Woche vorher Bescherung. Direkt von Taiwan versendet traf gestern ein Framework Desktop ein (Batch 17). Wobei von »Geschenk« keine Rede ist, ich habe den Rechner ganz regulär bestellt und bezahlt. Über das Preis/Leistungs-Verhältnis darf man gar nicht nachdenken … Aber für die Überarbeitung des Buchs Coding mit KI will ich nun mal moderat große Sprachmodelle (z.B. gpt-oss-120b) selbst lokal ausführen.

Dieser Blog-Beitrag fasst meine ersten Eindrücke zusammen. In den nächsten Wochen werden wohl noch ein paar Artikel rund um Ollama und llama.cpp folgen.

Framework Desktop

Auswahl

Ich war auf der Suche nach einem Rechner mit 128 GByte RAM, das von der GPU genutzt werden kann. Dafür gibt es aktuell drei Plattformen (Intel glänzt durch Abwesenheit):

  • AMD Ryzen AI Max+ 395 (»Strix Halo«): Dieser Prozessor kombiniert 16 Zen-5-CPU-Cores und 40 GPU-Cores (Radeon 8060S). Die Speicherbandbreite (LPDDR5X) beträgt bis zu 250 GiB/s. Desktop-PCs mit 2 TB SSD kosten zwischen 2.000 und 3.000 €, Notebooks ca. 4.000 €.
  • Apple Max CPUs: Der Prozessor M4 Max vereint 16 CPU-Cores mit 40 GPU-Cores. Die Speicherbandbreite erreicht beeindruckende 550 GiB/s. Ein entsprechender Mac Studio mit 2 TB SSD kostet ca. 5000 €, ein MacBook mit vergleichbarer Ausstattung ca. 6000 €.

  • NVIDIA DGX Spark: Diese Plattform besteht aus einer 20-Core ARM-CPU plus NVIDIA Blackwell GPU mit 48 Compute Units. Wegen des LPDDR5X-RAMs ist die Speicherbandbreite wie bei Strix Halo auf ca. 250 GiB/s limitiert. Komplettsysteme kosten ca. 4000 € (Asus, Dell, NVIDIA).

Was die Rechenleistung betrifft, spielen alle drei Plattformen in der gleichen Liga, vielleicht mit kleinen Vorteilen bei Apple, vor allem was Effizienz und Lautstärke betrifft. Gegen die NVIDIA-Lösung spricht, dass diese Rechner dezidiert für KI-Aufgaben gedacht sind; eine »normale« Desktop-Nutzung ist nur mit großen Einschränkungen möglich.

Generell darf man sich von der KI-Geschwindigkeit der aufgezählten Geräten keine Wunder erwarten: GPU-Leistung und Speicherbandbreite sind nur mittelprächtig. Praktisch jede dezidierte Grafikkarte kann kleine Sprachmodelle schneller ausführen — aber nur, solange das Sprachmodell komplett im dezidierten VRAM Platz hat. (Bei Desktop-PCs können Sie mehrere Grafikkarten einbauen und kombinieren, aber das ist teuer und kostet viel Strom.) Die oben aufgezählten CPUs mit integrierter GPU können dagegen das gesamten RAM nutzen. Das ist langsamer als bei dezidierten GPUs, aber es macht immerhin die Ausführung von relativ großen Modellen möglich.

Apple ist wie üblich bei vergleichbarer Ausstattung am teuersten. Umgekehrt muss man anerkennen, dass von allen hier aufgezählten Geräten ein Mac Studio vermutlich der einzige Computer ist, der in drei Jahren noch einen nennenswerten Wiederverkaufswert hat.

Am anderen Ende des Preisspektrums befindet sich die AMD-Variante. Es gibt diverse chinesische Mini-PCs mit der AMD-395-CPU: z.B. Bosgame (aktuell am billigsten), GMKtec EVO-X2, Beelink GTR9 (instabil, Probleme mit Intel-Netzwerkadapter) und Minisforum MS-S1 MAX. HP bietet den Z2 Mini G1a zu einem relativ vernünftigen Preis an, aber das Gerät ist anscheinend sehr laut. Schließlich gibt es den Framework Desktop, der ansprechend aussieht, in Tests gut abgeschnitten hat und die beste/leiseste Kühlung hat (leider ein Irrtum, siehe unten).

Ich habe mich nach wochenlanger Recherche für das Framework-Angebot entschieden. Das Konzept der Framework-Geräte ist sympathisch. Außerdem gibt es eine große Community rund um das Gerät. Zum Zeitpunkt der Bestellung kostete der Rechner mit 128 GByte RAM, ein paar Adaptern, Kacheln und Lüfter knapp 2.500 € (inkl. USt). Eine SSD habe ich anderswo besorgt.

Lieferung

Der Rechner wurde am 12.12. von Taiwan versendet und kam sechs Tage später bei mir an. Faszinierend. (Ich habe noch nie bei Temu & Co. bestellt, habe diesbezüglich auch keine Ambitionen. Insofern war die Verfolgung des Pakets rund um die halbe Welt für mich Neuland.)

In sechs Tagen um die halbe Welt. Ökologisch ein Alptraum, logistisch ein Wunder.

Bis zum Schluss wusste ich nicht, ob nun Zoll zu zahlen ist oder nicht. Offenbar nicht. Ich kann nicht sagen, ob sich Framework bei EU-Lieferungen um die ganze Abwicklung kümmert oder ob es Zufall/Glück war. (Das Gerät ist weiß Gott auch ohne Zoll teuer genug …)

Der Zusammenbau ist unkompliziert und gelingt in einer halben Stunde. Ich habe dann Fedora 43 installiert (weitere zehn Minuten). Alles funktionierte auf Anhieb, das Gerät lief die erste halbe Stunde praktisch lautlos.

Der Framework Desktop wird als Bastel-Set geliefert
Systemzusammenfassung von Gnome

Benchmark-Tests

Ich habe mich nicht lange mit Benchmark-Tests aufgehalten. BIOS in Grundzustand, Fedora 43 mit Gnome im Energiemodus Ausgeglichen.

Geekbench lieferte 2790 Single / 20.700 Multi-Core

Kernel kompilieren (Version 6.18.1): 9:08 Minuten

Systemüberwachung während der Kernel kompiliert wird

BIOS

F2 bzw. je nach Tastatur Fn+F2 führt in die BIOS/EFI-Einstellungen. Dort gibt es eine Menge Optionen zur Steuerung des CPU-Lüfters. Der GPU kann ein fixer Speicher (bis zu 96 GiB) zugewiesen werden. Für die meisten Anwendungen ist das aber nicht sinnvoll. Viele Bibliotheken sind in der Lage, den GPU-Speicher dynamisch anzufordern. Insofern ist es zweckmäßig, den fix reservierten GPU-Speicher möglichst klein einzustellen.

Es gibt keine Optionen, die die CPU/GPU-Leistung beeinflussen.

Achtung: Es gibt ein BIOS-Update von Version 0.03.03 auf 0.03.04. Gnome Software bietet das Update zur Installation an. Allerdings bereitet die neue BIOS-Version Probleme und verlangsamt den Boot-Prozess massiv. Das Update sollte daher nicht installiert werden!

Mit F2 gelangen Sie in die BIOS-Einstellungen

Stromverbrauch

Ich habe den Stromverbrauch am Netzstecker mit einem uralten Haushalts-Strommessgerät gemessen. Dessen Genauigkeit ist sicher nicht großartig, aber die Größenordnung meiner Messwerte klingt plausibel: Demnach beträgt die Leistungsaufnahme im Ruhezustand ca. 12 bis 13 Watt (wieder: Fedora mit Gnome Desktop, Energie-Modus ausgeglichen, keine rechenintensiven Vorgänge, BIOS im Grundzustand). Beim Kompilieren des Kernels steigt die Leistung kurz auf 160 Watt und pendelt sich dann ziemlich stabil rund um 140 Watt ein.

Geräuschentwicklung

Der Rechner hat zwei Lüfter: einen großen für die CPU (kann beim Bestellprozess konfiguriert werden, ich habe mich für das etwas teurere Noctua-Modell entschieden) und einen kleinen, der unsichtbar aber unüberhörbar im Netzteil am Boden des Rechners eingebaut ist.

Der CPU-Lüfter läuft standardmäßig nur unter Last und produziert dann ein gut erträgliches Geräusch (mehr Brummen als Surren). Die Steuerung des CPU-Lüfters kann im BIOS verändert werden. Ich habe probeweise einen Dauerbetrieb mit 25 % eingestellt. Der Lüfter bleibt dann für meine Ohren bei knapp einem Meter Abstand immer noch lautlos, sorgt aber für eine stetige leichte Kühlung.

Das Problem ist das äußerst schmale Netzteil, das sich im unteren Teil des Gehäuses befindet. Framework ist auf das Netzteil ziemlich stolz, aber viele Desktop-Besitzer können diese Begeisterung nicht teilen. Ein schier endloser Forum-Thread dokumentiert den Frust über das Netzteil. Im Prinzip ist es einfach:

  • Das Netzteil ist komplett gekapselt. Der große CPU-Lüfter kann es daher nicht kühlen.
  • Die Luftzufuhr wird durch eine enge Röhre und das Gitter des Gehäuses enorm behindert.

  • Das Netzteil ist mit 80 Plus Silver nur mäßig effizient, was sich vermutlich im Leerlaufbetrieb besonders stark auswirkt.

  • Im Netzteil steht die Luft. Dieses wird durch die Abwärme immer heißer.

  • Ca. 1/2 h nach dem Einschalten wird eine kritische Temperatur erreicht. Nun startet unvermittelt der winzige Lüfter. Eine halbe Minute reicht, um das Netzteil mit frischer Luft etwas abzukühlen — aber nach ca. 10 Minuten beginnt das Spiel von neuem. (Unter Last läuft natürlich auch der Netzteillüfter häufiger.)

Das Geräusch des Netzteil-Lüfters ist leider wesentlich unangenehmer als das des CPU-Lüfters. Der kleine Lüfter hat eine unangenehme Frequenz, und das regelmäßige Ein/Aus stört. Eine BIOS-Steuerung ist nicht vorgesehen. Vermutlich wäre es gescheiter, den Netzteil-Lüfter ständig bei niedriger Frequenz laufen zu lassen, um ohne viel Lärm einen andauernden Luftaustausch zu gewährleisten. Aber diese Möglichkeit besteht nicht.

Blick in das Innenleben. Der große Lüfter kühlt die CPU. Das Netzteil ist ganz unten und hat einen weiteren, nicht sichtbaren Lüfter
Die Luftzufuhr wird durch die Abdeckung weiter behindert

Um es klar zu stellen: Selbst wenn der Netzteillüfter läuft, ist das Gerät nicht wirklich laut — und vermutlich immer noch leiser als Konkurrenzprodukte (die ich aber nicht ausprobiert habe). Und dass der Computer unter Last nicht lautlos ist, war sowieso zu erwarten.

Ärgerlich ist, dass das Gerät trotz seines ausgezeichneten CPU-Kühler-Designs im Leerlauf bzw. bei geringer Belastung nicht leiser ist. Technisch wäre das möglich. Da wurde rund um das Netzteil viel Potenzial verschenkt.

Fazit

Der Framework Desktop wurde offensichtlich mit viel Liebe zum Detail entwickelt. Der Rechner ist optisch ansprechend und liegt preislich im Vergleich zu seinen Konkurrenzprodukten im Mittelfeld. (Generell ist leider zu befürchten, dass die Preise von Computern in den nächsten Monaten steigen werden, weil sowohl RAM als auch SSDs fast täglich teurer werden.)

Die CPU-Kühlung ist vermutlich die beste aller aktuellen Strix-Halo-Angebote. Bei meinen bisherigen Tests lief der Rechner absolut stabil.

Extrem schade, dass das Netzteil so ein Murks ist. Wenn das Netzteil intelligenter gekühlt würde, wäre im Leerlauf bzw. bei moderater Nutzung ein weitgehend lautloser Betrieb möglich. Stattdessen nervt das Gerät mit einem hochfrequenten Gesurre, das alle paar Minuten startet und eine halbe Minute später wieder aufhört. Ärgerlich!

Quellen/Links

Netzteil

Andere Geräte

  •  

Neuer Mozilla CEO: Firefox soll zu einem modernen KI-Browser werden

Anthony Enzor DeMeo übernimmt offiziell die Führung von Mozilla. Der neue CEO stellt Vertrauen und Transparenz ins Zentrum seiner Strategie. Nutzer sollen jederzeit Kontrolle über Funktionen behalten und Entscheidungen bewusst treffen können. In seiner ersten Botschaft betonte er die zentrale Rolle des Vertrauens. Künstliche Intelligenz verändert bereits Suche, Einkauf und digitale Entscheidungen. Der Browser wird […]

Der Beitrag Neuer Mozilla CEO: Firefox soll zu einem modernen KI-Browser werden erschien zuerst auf fosstopia.

  •  

GNOME verschärft die Richtlinien für KI‑basierten Code in Shell‑Erweiterungen.

Das GNOME Projekt verschärft seine Regeln für GNOME-Erweiterungen. Die Verantwortlichen reagieren damit auf eine wachsende Zahl von Einsendungen, die deutliche Spuren automatischer Codeerzeugung tragen. Viele dieser Erweiterungen enthalten große Mengen unnötiger Logik und erschweren die Arbeit der Prüfer. Nach Angaben eines erfahrenen Entwicklers müssen an manchen Tagen mehr als fünfzehntausend Zeilen Code bewertet werden. Häufig […]

Der Beitrag GNOME verschärft die Richtlinien für KI‑basierten Code in Shell‑Erweiterungen. erschien zuerst auf fosstopia.

  •  

Intel NPU Treiber erreicht openSUSE Ökosystem

Die openSUSE Innovator Initiative bringt frischen Schwung in die Hardwareunterstützung von openSUSE. Erstmals steht ein Paket für den Intel Neural Processing Unit Treiber bereit. Eine NPU dient der Beschleunigung von KI Berechnungen wie Bilderkennung und Sprachverarbeitung. Damit beginnt die Integration dieser Technologie in die openSUSE Welt. Die neuen Pakete sind aktuell experimentell und für mehrere […]

Der Beitrag Intel NPU Treiber erreicht openSUSE Ökosystem erschien zuerst auf fosstopia.

  •  
❌