01
Eine Flotte, zu schwach für das benötigte Modell
Das Gerät wurde für das Modell ausgewählt, das damals vorlag. Das Modell, das am Ende funktionierte, passte nicht mehr darauf.
Technologien
Edge- und On-Premise-KI
Die Hardwarefrage ist die letzte, die Sie beantworten, nicht die erste. Klären Sie zuerst, was das System leisten muss und unter welchen Bedingungen. Prüfen Sie dann, ob das auf Edge-Hardware überhaupt erreichbar ist, und wählen Sie die passende Hardwareklasse. Erst danach lohnt sich die Diskussion über Teilenummern.
Ebenen
Maschine · Standort · Rechenzentrum
Entschieden durch
Sechs Fragen, kein Datenblatt
Hardwareverkauf
Keiner, keine Reseller-Bindung
Erster Schritt
Zwei bis drei Wochen
Die falsche Reihenfolge
Die meisten Gespräche über Edge-KI beginnen mit einem Gerät und arbeiten sich rückwärts vor.
So landen Unternehmen bei einer Flotte von Modulen, die für das später benötigte Modell zu schwach sind, oder bei Stückkosten, an denen der Business Case bei der hundertsten Installation zerbricht. Wir begleiten unsere Kunden durch die umgekehrte Reihenfolge. In etwa einem Drittel der Fälle besteht das nützliche Ergebnis darin, dass der Workload gar nicht auf ein Gerät gehört.
02
Stückkosten, die beim Skalieren kippen
Der Unterschied zwischen einem Modul für vierzig Euro und einem für zweitausend Euro ist im Pilotprojekt ein Rundungsfehler. Über tausend Installationen hinweg ist er der gesamte Business Case.
03
Ein Workload, der nie auf ein Gerät gehörte
Hohe Parallelität, langer Kontext, häufiges Nachtrainieren oder eine Genauigkeitsanforderung, die nur ein Frontier-Modell erfüllt. Solche Workloads gehören auf einen Server, und das früh herauszufinden ist bereits ein Ergebnis.
In etwa einem Drittel der Fälle besteht das nützliche Ergebnis einer Edge-Bewertung darin, dass der Workload nicht auf ein Gerät gehört.
Was heute geht
Was Edge-KI heute tatsächlich leisten kann
Die Leistungsgrenze hat sich in drei Jahren weit verschoben, und vieles, was als gesichert gilt, ist überholt. Ein grobes Bild davon, was heute problemlos läuft und was noch nicht.
- Klassische Wahrnehmung ist gelöstes Terrain
- Objekterkennung, Segmentierung, Tracking, OCR, Anomalieerkennung und Multikamera-Pipelines laufen mit Echtzeit-Bildraten bei wenigen Watt bis einigen zehn Watt. Wenn Ihr Problem ein Bildverarbeitungsproblem ist, läuft es so gut wie sicher auf einem Gerät.
- Audio und Zeitreihen kommen mit noch weniger aus
- Keyword Spotting, akustische Anomalieerkennung, Schwingungsanalyse und vorausschauende Wartung passen auf Hardware der Mikrocontroller-Klasse im Bereich von Milliwatt bis zu einstelligen Watt, oft direkt auf den Sensor.
- Kleine Sprach- und Vision-Language-Modelle laufen inzwischen auf dem Gerät
- Ein Modell mit 7 bis 13 Milliarden Parametern erreicht auf Embedded-Hardware der Mittelklasse einen brauchbaren Durchsatz. Das reicht für strukturierte Extraktion, Klassifikation, kurze Anweisungen und eng geführte Dialoge. Module der Spitzenklasse fassen deutlich größere Modelle, meist begrenzt aber der Durchsatz und nicht die Kapazität.
- Was weiterhin schwierig bleibt
- Hohe Parallelität, lange Kontextfenster, alles, was häufiges Nachtrainieren auf dem Gerät erfordert, und Workloads, bei denen nur ein Frontier-Modell die Genauigkeitsanforderung erfüllt. Das sind Signale, dass die Arbeit auf einen Server gehört.
Die Anforderung ableiten
Sechs Fragen entscheiden fast jede Edge-Architektur
Beantworten Sie diese Fragen, bevor jemand ein Datenblatt öffnet. Einige davon entscheiden die Sache schon für sich allein.
01
Wie schnell muss die Antwort da sein, und zwar beim relevanten Perzentil statt im Durchschnitt? Ein Regelkreis, der in unter zehn Millisekunden schließen muss, entscheidet die Frage allein. Ein Qualitätsbericht innerhalb von zwei Sekunden tut das nicht.
02
Dürfen die Daten den Standort verlassen? Exportkontrolle, Verschlusssachen, DSGVO, Betriebsvereinbarungen und schlicht der fehlende Wille, Prozessdaten oder Konstruktions-IP auf fremde Infrastruktur zu legen, sind harte Randbedingungen. Und sie betreffen das Gebäude, nicht die Maschine.
03
Was passiert, wenn das Netz weg ist? Instabile Verbindungen sind auf Schiffen, in Bergwerken, in Umspannwerken und in Fahrzeugen der Normalfall. Ein System, das ohne Verbindung auf nichts zurückfällt, ist meist falsch konzipiert.
04
Wie sieht der Rahmen für Energie, Wärme und Bauraum aus? Mehr Edge-Designs scheitern an Wärme und Gehäuse als an der Rechenleistung.
05
Was kostet das im Flottenmaßstab? Ein Modulpreis, der im Pilotprojekt ein Rundungsfehler ist, ist über tausend Installationen hinweg der gesamte Business Case.
06
Wie lange muss das Produkt im Einsatz bleiben, und braucht es eine Zertifizierung? Eine Servicezusage über fünf Jahre, Anforderungen an die funktionale Sicherheit oder ein reguliertes Umfeld schränken Hardware und Update-Mechanismus weit stärker ein als die Leistung.
Drei Ebenen
Auf der Maschine, am Standort oder im eigenen Rechenzentrum
Die teure Verwechslung passiert zwischen den ersten beiden Ebenen. Wer ein Feldgerät für Arbeit spezifiziert, die in ein Rack gehört, treibt die Kosten über die gesamte Flotte. Wer eine Desktop-Box als Produktivinfrastruktur einplant, bekommt ein System, das sich weder warten noch zertifizieren lässt. Beide Fehler sind häufig, und beide lassen sich mit einer Woche Analyse vermeiden.
-
01Auf der Maschine
Ein Embedded-Modul oder ein Beschleuniger in der Anlage selbst. Die richtige Wahl, wenn Latenz, Energie, Bauraum, Konnektivität oder die Wirtschaftlichkeit der Flotte es verlangen.
-
02Am Standort
Ein lokaler Server, Industrie-PC oder eine Workstation im Werk, auf dem Schiff, im Umspannwerk. Hierhin gehören die meisten Anforderungen, die als „wir brauchen ein Edge-LLM“ beschrieben werden. Zugleich ist es der günstigste Weg, eine Vorgabe zur Datenresidenz zu erfüllen.
-
03Im eigenen Rechenzentrum
Wenn Skalierung, Mandantenfähigkeit oder Modellgröße alles Kleinere unwirtschaftlich machen.
Deployment vs. Entwicklung
Deployment-Hardware und Entwicklungshardware gehören nicht in dieselbe Klasse. Das aktuelle NVIDIA-Portfolio zeigt das gut.
Jetson-Module sind Deployment-Hardware: industrielle Temperaturbereiche, lange Produktionslebenszyklen, Optionen für robuste Ausführungen und eine Lieferzusage, auf die Sie ein Produkt bauen können.
DGX Spark ist Entwicklungshardware: ein Desktop-Rechner mit einem großen gemeinsamen Arbeitsspeicher (Unified Memory), gebaut, damit ein Engineer ein Modell beachtlicher Größe lokal ausführen und per Fine-Tuning anpassen kann, ohne Daten an einen Cloud-Anbieter zu senden. Für eine Organisation, die keine Daten in die Cloud geben darf, ist das ein echter Gewinn. Ein Inferenzserver für den Produktivbetrieb ist DGX Spark aber nicht: Es fehlt eine industrielle Umgebungsspezifikation, und unter realer Parallelität wird die Speicherbandbreite zum Engpass.
Deployment-Hardware bietet
Industriellen Temperaturbereich Langen Produktionslebenszyklus Robuste Ausführungen Eine Lieferzusage
Eine Entwicklungsbox bietet nicht
Eine industrielle Umgebungsspezifikation
Einen langen Embedded-Lebenszyklus
Reserven unter realer Parallelität
Eine Grundlage, auf der Sie ein Produkt zertifizieren können
Dafür hält sie Ihre Daten von Cloud-Anbietern fern
Make-or-Buy
Können Sie Ihr eigenes Edge-KI-System bauen?
Meist ja, und günstiger als erwartet. Vorausgesetzt, Sie sind ehrlich, welche Schicht Sie eigentlich bauen. Die pragmatische Antwort für die meisten Industrieunternehmen: Modul und Basisplattform kaufen, bei anspruchsvollem Gehäuse mit einem Partner integrieren und Modell sowie Betrieb vollständig selbst verantworten.
-
01Silizium: fast niemand sollte selbst bauen
Eigene Beschleuniger und ASICs rechnen sich nur bei sehr hohen Stückzahlen und einer festen, stabilen Funktion. Entwicklungskosten und Terminrisiko sind erheblich.
-
02Board und System: abhängig von der Stückzahl
Standard-Carrier-Boards und Industrierechner sind der richtige Ausgangspunkt für Pilotprojekte und Stückzahlen im dreistelligen Bereich. Ein eigenes Carrier-Board lohnt sich, wenn Bauraum, Steckverbinder, Sensorschnittstellen oder die Stückkosten bei hohem Volumen den Entwicklungsaufwand und die anschließende Zertifizierung rechtfertigen.
-
03Modell und Anwendung: sollten Sie selbst bauen
Hier erzeugen Ihre Daten, Ihr Prozesswissen und Ihre Sensorik etwas, das Ihnen kein Zulieferer verkaufen kann. Hier liegt auch die langfristige Betriebsarbeit: Modelle im Feld aktualisieren, ein fehlerhaftes Release zurückrollen, Drift erkennen, ohne Daten nach Hause zu schicken, und das Ganze reproduzierbar halten.
Wie wir helfen
Die Analyse, nach der die Hardwareentscheidung der einfache Teil ist.
Ein Edge-Design scheitert selten an der Rechenleistung. Es scheitert an Energie, Wärme, Gehäuse, Update-Pfaden und Lieferlebenszyklus, und das meiste davon wird entschieden, lange bevor jemand ein Modell benchmarkt.
Quantisierung ist ein Tauschgeschäft und keine kostenlose Optimierung. Beantworten lässt sich die Frage deshalb nur, wenn man sie an Ihrer Aufgabe misst, gegen den Durchsatz, den sie bringt.
Zuerst charakterisiert
Reale Eingangsraten Reale Parallelität Das relevante Latenz-Perzentil
Was die Zusammenarbeit abdeckt
Charakterisierung des Workloads gegenüber dem, was jede Ebene leisten kann
Die Genauigkeitskosten kleinerer Modelle oder geringerer Präzision
Budgets für Energie, Wärme und Gehäuse, früh dimensioniert
Modell-Updates und Rollback über eine ganze Flotte
Drift-Erkennung ohne Datenverbindung nach Hause und Air-Gapped-Betrieb
Liefer- und Lebenszyklusrisiken über Modulgenerationen hinweg
Wir verkaufen keine Hardware und haben keine Reseller-Verträge. Deshalb ist unsere Empfehlung die, die wir auch mit eigenem Kapital treffen würden.
Einsatzfelder
Programme, bei denen die Berechnung an einem bestimmten Ort stattfinden muss
Ob Edge oder On-Premise, entscheidet sich daran, wo die Daten entstehen, wohin sie dürfen und was weiterlaufen muss, wenn die Verbindung weg ist.
Produktion und industrielle Inspektion
Inline-Entscheidungen im Linientakt, in einem Gehäuse an der Maschine, mit einem Produktlebenszyklus, der in Jahren gemessen wird statt in Release-Zyklen.
Vorteile:
Entscheidungen im Linientakt, ohne Umweg über das Netz
Hardware passend zu Gehäuse und Wärme dimensioniert
Ein Lebenszyklus in Jahren
Luft- und Raumfahrt & Verteidigung
Exportkontrollierte und eingestufte Programme, bei denen die Grenze, die die Daten nicht überschreiten dürfen, die erste architektonische Randbedingung ist.
Vorteile:
Daten bleiben innerhalb der Grenze
Robuste, programmkonforme Hardware
Betrieb ohne Netzverbindung
Energie und kritische Infrastruktur
Umspannwerke, Schiffe und abgelegene Standorte, an denen instabile Verbindungen normal sind und ein System, das ohne Verbindung stehen bleibt, falsch konzipiert ist.
Vorteile:
Daten bleiben innerhalb der Grenze
Robuste, programmkonforme Hardware
Betrieb ohne Netzverbindung
Fernerkundung
Verarbeitung an Bord und im Bodensegment, abgewogen gegen die Downlink-Bandbreite, die meist die knappste Ressource im System ist. Wo die Mission es zulässt, werden Ergebnisse übertragen statt Rohszenen.
Vorteile:
Verarbeitung passend zum Downlink-Budget platziert
Ergebnisse statt Rohszenen, wo es passt
Verarbeitung im Bodensegment, wo es sich lohnt
Review der Deployment-Architektur
So läuft eine erste Zusammenarbeit ab
Zwei bis drei Wochen. Sie bringen den Workload, die Randbedingungen und die angestrebten Stückkosten mit.
1
Den Workload charakterisieren
Reale Eingangsraten, reale Parallelität, die tatsächliche Latenzanforderung, und zwar beim relevanten Perzentil statt im Durchschnitt.
2
Klären, was jede Ebene leisten kann
Ob sich die Anforderung auf der Maschine, am Standort oder nur im Rechenzentrum erreichen lässt. Eingeschlossen ist der Fall, dass die Antwort lautet: Das gehört nicht auf ein Gerät.
3
Hardware-Shortlist mit klar benannten Folgen
Eine Hardware-Shortlist, bei der die Folgen für Genauigkeit und Durchsatz offen benannt sind, einschließlich dessen, was kleinere Modelle oder geringere Präzision bei Ihrer Aufgabe kosten.
4
Make und Buy trennen, den Betrieb konzipieren
Eine Make-or-Buy-Aufteilung über Silizium, Board und Modell, mit dem passenden Konzept für Updates, Rollback und Drift-Erkennung.
Verwandte Themen
Die Workloads auf dieser Hardware und die Entscheidungen rund um sie
Technologien
Computer Vision
Die Wahrnehmungs-Workloads, die am häufigsten in einem Gehäuse an der Maschine landen statt in einem Rack.
Technologien
Multimodale Sensorfusion
Mehrere Wahrnehmungsketten in Echtzeit plus ein fusionierter Schätzer. Bei diesem Workload ist die Wahl der Geräteklasse kein Detail mehr.
Technologien
KI-Agenten & Workflow-Automatisierung
Was sich ändert, wenn das Modell, das Aktionen ausführt, innerhalb Ihrer eigenen Infrastruktur laufen muss statt hinter einer API.
Technologien
Synthetische Daten & Simulation
Woher Trainings- und Evaluierungsdaten kommen, wenn gerade die echten Daten den Standort nicht verlassen dürfen.
Leistungen
KI-Deployment-Architektur
Die Architektur rund um die Geräteentscheidung: wo die Inferenz läuft, wie sie betrieben wird und was ihr laufender Betrieb kostet.
Leistungen
Make-or-Buy-Entscheidung für KI
Die Make-or-Buy-Aufteilung über Silizium, Board und Modell, entschieden anhand Ihrer Anforderungen statt anhand von Anbieterfolien.
Strategie- & Architektur-Review vereinbaren
Bringen Sie uns zuerst den Workload und erst dann eine Teilenummer.
Sie bringen den Workload, die Randbedingungen und die angestrebten Stückkosten mit. Sie erhalten eine Empfehlung für die passende Ebene, eine Hardware-Shortlist mit offen benannten Folgen, eine Make-or-Buy-Aufteilung und das passende Betriebskonzept.
Strategie- & Architektur-Review vereinbaren nAIxt Technologies GmbH
Am Forst 2
82166 Gräfelfing, Deutschland
+49 89 54196515
info@naixt-technologies.de