Aus der wilden Welt der digitalen Transformation
Kennen ChatGPT, Claude oder Perplexity eigentlich Ihre Website – oder erfinden sie nur, was plausibel klingt? Genau an dieser Frage setzt ein kleines Textformat an, das gerade zum stillen Standard für die KI-Ära wird. Wir haben dafür ein eigenes, kostenloses Tool gebaut, mit dem Sie in wenigen Minuten Ihre eigene Datei erzeugen können – ganz ohne Programmierkenntnisse.
„Was steckt hinter llms.txt – und wie Sie sie in zwei Minuten selbst erzeugen“ weiterlesen
Wenn Sie einen Server remote steuern müssen, dann reicht dafür SSH völlig aus. Aber wenn es um einen Desktop geht? Und vor allem, wenn der remote Desktop nicht das gleiche Betriebssystem hat wie das System, auf dem Sie arbeiten? Dafür stellen wir Ihnen heute RustDesk vor, eine Open-Source-Lösung, die sehr sicher ist und keine Lizenzkosten verursacht. Sie finden außerdem eine Anleitung, wie Sie RustDesk auf einem eigenen oder gemieteten Server installieren können.
„Remote Desktop für das Homeoffice, sicher und günstig“ weiterlesen
Ihre DGX Spark fühlt sich seit ein paar Tagen komisch träge an, aber Sie können nicht sagen, woran es liegt? Willkommen im Klub – denn genau dieses Gefühl hat uns auf die Spur eines Bugs gebracht, den NVIDIA bisher lieber verschweigt als behebt.
Der Tatort: unser eigener Spark-Cluster. Der Verdacht fiel zunächst auf niemanden- bis eine der Maschinen plötzlich nur noch halb so schnell rechnete wie ihre Nachbarn. Kein Fehlercode, kein Log-Eintrag, keine Warnung. Nur eine Spark, die sich anfühlte, als hätte sie über Nacht die Hälfte ihres Grace-Blackwell-Gehirns verloren.
Die Ermittlung führte zu einem seit Monaten bekannten, aber unbehobenen BIOS-Bug in der DGX Spark (GB10): Unter bestimmten, bislang nicht reproduzierbaren Umständen bleibt der Chip in einem Low-Power-Zustand hängen – der SM-Takt dümpelt bei rund 1000–1200 MHz statt der üblichen ~2400 MHz. Mehr als die Hälfte der Rechenleistung verschwindet spurlos, ohne dass ein normaler Reboot etwas daran ändert. Einziges Gegenmittel: ein Cold Boot – Strom ziehen, mindestens 30 Sekunden warten, neu starten.
Das eigentliche Verbrechen dieses Bugs ist seine Tarnung. Auf einem Einzelsystem bleibt es ein vages Bauchgefühl. Im Cluster fällt es nur im Vergleich auf. Und auf einem unbeaufsichtigten Server merkt es niemand – bis jemand sich fragt, warum das Training ewig dauert, und die Inferenz im Schneckentempo schleicht.
Deshalb haben wir check-gpu-clock gebaut, ein schlankes Python-Tool, das genau diese Frage objektiv beantwortet: Erreicht die GPU unter Last wirklich ihren maximalen Takt? Das Skript jagt kurze, gepulste Lastspitzen über die GPU, misst per nvidia-smi den SM-Takt dazwischen und fällt ein klares Urteil – OK, wenn der gemessene Höchstwert über 1800 MHz liegt, ALERT, wenn nicht. Für Automatisierung gedacht: Exit-Codes nach Nagios/Icinga-Konvention, damit auch ein kaputter Check (UNKNOWN) nicht mit einem echten Alarm verwechselt wird. Läuft am besten alle 30 Minuten aus dem Cron heraus, unauffällig im Hintergrund.
Was das Tool bewusst nicht mitbringt: eine fertige Benachrichtigung. Das ist Absicht – jeder überwacht anders. Wer aber, wie wir, den Alarm per Mail haben möchte, findet dafür bereits ein passendes Werkzeug aus unserem Open-Source-Regal: climb, unser Kommandozeilen-Mail-Bot. Damit haben wir die Überwachung unserer eigenen Sparks automatisiert – ein simpler Cron-Einzeiler prüft den Takt, und bei ALERT verschickt climb sofort eine Mail. Kein Dienst, kein Abo, keine Abhängigkeiten außer der Python-Standardbibliothek.
Den Code, die Konfiguration und alle Details gibt’s wie immer auf GitHub: check-gpu-clock. Apache 2.0, wie gewohnt kostenlos und frei einsetzbar. Cold Case gelöst – bis NVIDIA den Bug fixt.
Im letzten Artikel habe ich (auch) darüber geschrieben, dass Ollama plant, die Kompatibilität zu llama.cpp zu verbessern. Das ist jetzt passiert — und wie. Mit v0.30 (aktuell schon bei v0.30.6) hat Ollama die Architektur grundlegend umgebaut: Statt auf GGML aufzusetzen, wird llama.cpp jetzt direkt unterstützt, GGUF-Kompatibilität inklusive. Für Apple Silicon gibt’s außerdem MLX-Beschleunigung, für NVIDIA-Hardware spürbar mehr Performance. Wer die Änderungen im Detail nachlesen will: Die Release Notes auf GitHub sind überschaubar, aber klar. Nun, das alleine wäre schon eine Meldung wert. Aber was mich wirklich umgehauen hat, kam beim Testen.
Man erhält die Liste der verfügbaren Modelle auf Huggingface mit dem Link https://huggingface.co/models?pipeline_tag=text-generation&library=gguf&sort=trending, das sind über 31K Treffer. Und wie führt man ein Modell aus?
ollama run hf.co/{family}/{model}, zum Beispiel
ollama run hf.co/Qwen/Qwen2.5-3B-Instruct-GGUF. Einfacher geht es nicht. hf.co ist ein Hub, der hier beschrieben ist.
Nach dem initialen run (oder pull) liegt das Modell lokal auf der eigenen Platte und wird künftig direkt von dort geladen. Und Datenschutz und Privatsphäre sind automatisch dabei.
Wer Modelle parametrisieren möchte, kann sie auch per Modelfile importieren. Das hat Ollama hier erklärt. Aber wer das Modell direkt von Huggingface so nutzen will, wie es dort gespeichert ist, kann sich diesen deutlich aufwändigeren Weg sparen.
Auf Ollama zu warten, hat sich also sehr gelohnt. Das neue Interface ist meiner Meinung der direkteste und leichteste Weg, auf die Huggingface-Bibliothek zuzugreifen. Und die bewährte Ollama-Qualität mit Multitasking und ausgefuchster Speicherverwaltung gibt es natürlich dazu. Bravo, Ollama! Bravissimo!
Georgi Gerganov hat still und leise eine Website lanciert: llama.app. Das klingt unspektakulär, ist aber ein bemerkenswertes Signal – denn Gerganov ist der Mann, ohne den lokale KI so, wie wir sie heute kennen, schlicht nicht existieren würde. „Our goal is to make local AI accessible to everyone“, schreibt Gerganov auf seinem X-Account und reißt, wie er es verspricht, mit seiner neuen Website alle Eintrittsbarrieren nieder. Es gibt ja einige Akteure, die freie und lokale KI möglich machen, zum Beispiel Ollama. Aber oft ist es so, dass man hinter deren „Walled Garden“ eingesperrt ist, und so ist es auch bei Ollama. Braucht man es nun nicht mehr?
https://github.com/Cephei-OpenSource/
Unser Freeware-Angebot erfreut sich großer Beliebtheit, worüber wir uns natürlich sehr freuen. Um das auf solidere Füße zu stellen, haben wir nun eine GitHub-Präsenz eingerichtet und bringen dort einige unserer freien Projekte in den Public Domain.
Wir haben zunächst drei Projekte ausgewählt und für die Publikation auf GitHub überarbeitet und erweitert:
genpwd – Passwortgenerator, mit Berechnung der Entropie, und, neu, der Möglichkeit, leichter tippbare Passwörter zu generieren.
climb – Tool für Systemadministratoren, um für vielfältige Anwendungsfälle Mails von der Kommandozeile aus zu senden. Jetzt neu mit Inline-Attachments und mehr und sichereren Möglichkeiten für die Passwort-Übergabe.
dialsynth – Dialektische Synthese, lässt zwei KI-Modelle eine Synthese erstellen aus Antwort und Kritik, gestützt durch eine Faktenrecherche. Pipeline für Open WebUI. Jetzt neu mit der Möglichkeit, die Suche mit SearXNG lokal oder Brave (musste zuvor manuell eingerichtet werden) auszuführen, sowie mit erweiterten Valve-Parametern für Timeouts und die Sprache der Antwort.
Auf GitHub können Sie uns Verbesserungsvorschläge senden, oder Fehler melden. Wenn Sie ein eigenes Projekt von einem unserer Projekte ableiten möchten (Fork), geht das selbstverständlich ebenso. Unsere Projekte stehen unter Apache-2.0-Lizenz (Open Source) und dürfen auch kommerziell verwendet werden.
Wie vermutlich jedes Software-Unternehmen nutzen auch wir eine ganze Reihe von Open Source Projekten. Im Rahmen unserer Möglichkeiten unterstützen wir bereits einige davon. Dennoch möchten wir außerdem eigene freie Software der Community zur Verfügung stellen, GitHub ist die geeignete und etablierte Plattform dafür. Besuchen Sie uns dort, wir würden uns sehr freuen!
Update: Dieses Tool ist in einer verbesserten Version auf unserem Github verfügbar https://github.com/Cephei-OpenSource/dialsynth
Als kritischer und verantwortungsbewusster KI-Anwender, wie gehen Sie vor? Die Gefahr von Halluzinationen und Auslassung wichtiger Details ist sehr real. Man sollte sich also niemals blind auf die Auskunft einer KI verlassen.
Also wird man zunächst eine Websuche durchführen und damit die Antwort der KI sorgfältig gegenprüfen. Tja, ziemlich viel Aufwand, und darum neigt man selbstredend gerne dazu, diese Prüfung auszulassen. Und ist schneller einer KI-Halluzination aufgesessen, als man gucken kann.
Aber wie wäre es, wenn man den Prozess automatisieren könnte? Und zunächst eine KI die grundlegenden Arbeiten übernehmen könnte. Idealerweise nicht die gleiche KI, denn alle KIn haben Stärken und Schwächen, wenn man sie also kombiniert, erhält man deshalb weit robustere Ergebnisse.
„Die schärfsten Kritiker der Elche sind selber welche“ weiterlesen