Eine GPU-Konfiguration im Team abnehmen

Die Entscheidung vor der Bereitstellung vorbereiten

Beginnen Sie mit einer abgeschlossenen Arbeitseinheit: einem angereicherten und exportierten Ordner, einem Satz von Rendern, der von seinem Empfänger geöffnet wurde, oder einer Evaluierung samt ihren Ausgaben. Schreiben Sie das fachliche Kriterium neben das technische Kriterium. Ein Programm kann fehlerfrei enden und dennoch unbrauchbare Ergebnisse liefern. Umgekehrt belegt ein einmalig erzieltes korrektes Ergebnis noch nicht, dass das Team die Arbeit neu starten und seine Dateien wiederherstellen kann.

Behalten Sie die Parameter bei, die die Last beeinflussen: Eingabevolumen, Präzision, Batch-Größen, Parallelität und Abhängigkeiten. Unterscheiden Sie eine Warteschlange unabhängiger Aufgaben, eine Aufgabe, die ihre Berechnung auf mehrere Karten verteilt, und einen Dienst, der kontinuierlich Anfragen erhält. Diese drei Organisationsformen haben nicht dieselben Abnahmekriterien. Eine Zeile „leistungsstarke GPU" gibt niemandem ein Mittel, um zu entscheiden.

Der Projektverantwortliche legt die Kriterien vor den Tests fest. Der Betreiber bereitet die Zugänge vor, der Anwendungsverantwortliche liefert den bekannten Start und der Empfänger validiert die Ausgaben. Dieselbe Person kann mehrere Rollen tragen; jede Rolle muss dennoch einen Inhaber und einen Vertreter haben. Reservieren Sie im gewählten Zeitraum die Installation, die Tests, eine mögliche Korrektur und den finalen Export, zusätzlich zur Nutzberechnung.

Hersteller, Zuteilung und tatsächliche Aufgabe trennen

Das Datenblatt einer GPU beschreibt eine Referenzhardware. Die zugeteilte Maschine bringt weitere Eigenschaften mit: Anzahl der sichtbaren Geräte, gewährte Zugänge, Softwareversionen, nutzbare Volumes und Pfade. Die Referenzaufgabe bringt eine dritte Ebene mit: das mit Ihren Daten und Ihren Einstellungen erzielte Ergebnis. In der Tabelle ordnen Sie jede Zeile genau einer Ebene zu, damit nicht ein Merkmal des Herstellers als Messgröße Ihres Dienstes behandelt wird.

Leiten Sie weder NVLink noch eine bestimmte Topologie noch einen Festplattendurchsatz allein aus dem Kartenmodell ab. Wenn Ihre Anwendung von diesen Eigenschaften abhängt, machen Sie sie zu ausdrücklichen Anforderungen, lassen Sie den Umfang präzisieren und prüfen Sie ihn dann auf dem Zielsystem. Wenn sie für Ihre Last nicht nötig sind, fügen Sie sie nicht als künstliche Abnahmebedingungen hinzu.

Der Speicher pro GPU und die Anzahl der Karten bleiben zwei verschiedene Spalten. Ein B200-Kontingent bei Capordia umfasst zwei GPUs; das genügt nicht, um einem für eine einzelne Karte vorgesehenen Programm einen einzigen Speicher zu geben. Dokumentieren Sie den Verteilungsmechanismus der Software, bevor Sie einen Nutzen daraus erwarten.

Das Inventar erstellen, ohne die Einstellungen zu ändern

Unter NVIDIA erfassen die untenstehenden Befehle die Version des Werkzeugs, die Liste der GPUs und einige Attribute im CSV-Format. Konsultieren Sie zunächst die installierte Hilfe: die verfügbaren Felder und Funktionen hängen von der Version ab. Die NVIDIA-Dokumentation empfiehlt Kennungen wie die UUID zur Verfolgung eines Geräts, da sich die Reihenfolge der Indizes ändern kann. Behalten Sie die vom Werkzeug geschriebenen Einheiten bei. Diese Erhebungen starten keine GPU-Aufgabe und qualifizieren nicht deren Leistung.

Erfassen Sie bei AMD die Version mit „amd-smi version", dann das Inventar und die statischen Eigenschaften mit „amd-smi list --json" und „amd-smi static --json". Prüfen Sie die Optionen über die Hilfe Ihrer Installation. AMD SMI setzt eine AMD-GPU und deren Treiber voraus; die herangezogene Dokumentation ist die von AMD SMI 27.0.0. Ein nicht verfügbares Feld muss „nicht ermittelt" bleiben, mit seiner Begründung, statt einen geschätzten Wert zu erhalten.

Archivieren Sie anschließend die Versionen der Anwendung und ihrer Bibliotheken. Das CUDA-Banner von NVIDIA SMI belegt allein nicht die Version des installierten Toolkits. Bei ROCm vergleichen Sie die Kombination aus GPU, System und Version mit der entsprechenden Matrix. In beiden Fällen bleibt der entscheidende Test der Start Ihrer Anwendung in der tatsächlich vorgesehenen Umgebung.

Die Datei enthält die NVIDIA- und AMD-Befehle, die auf Ihrer Maschine auszuführen und dann dem Protokoll beizufügen sind. Sie stützen sich auf die offiziellen Dokumentationen; im vorliegenden Beispiel wurde kein CUDA- oder ROCm-Ergebnis gemessen. Die herunterladbare Befehlsdatei enthält beide Zweige und die dem Protokoll beizufügenden Felder.

nvidia-smi --version
nvidia-smi --help-query-gpu
nvidia-smi -L
nvidia-smi --query-gpu=index,name,uuid,memory.total --format=csv

Jede Anforderung in eine beobachtbare Prüfung verwandeln

Eine gute Abnahmezeile verbindet ein Kriterium, eine Methode und einen Beleg. „Genug Speicher“ wird zum Beispiel zu: Arbeitsverzeichnis identifiziert, verfügbarer Speicherplatz vor dem Start erfasst und Export vom Zielort aus geöffnet. Die benötigte Menge ist die Ihres Arbeitsauftrags, einschließlich der Zwischendateien; dieser Leitfaden setzt keine an jede GPU gebundene Festplattenkapazität voraus.

Legen Sie die Einheiten fest, bevor Sie zwei Messwerte vergleichen. Ein dezimales GB entspricht einer Milliarde Byte; ein GiB entspricht 2 hoch 30 Byte. Die Werkzeuge können die englischen Schreibweisen GB und GiB anzeigen, oder MiB für eine kleinere Einheit. Behalten Sie den Rohwert und seine Einheit bei und geben Sie die eventuelle Umrechnung an. Verwerfen Sie eine Konfiguration nicht allein wegen der unterschiedlichen Schreibweise zwischen einem Datenblatt und einem Messwert.

Testen Sie beim Netzwerk den Datenfluss des Projekts: gleiches Ziel, gleiche Berechtigungen und ein repräsentativer Dateityp. Ein einzelner Download qualifiziert nicht den Export von Tausenden kleiner Ergebnisse. Messen und dokumentieren Sie den Transfer in beide Richtungen, wenn das Projekt ihn nutzt, und halten Sie dann den Schwellenwert fest, den Ihr Zeitplan verlangt. Ohne einen vor dem Test festgelegten Schwellenwert bleibt eine beobachtete Dauer eine bloße Beobachtung.

Der Status „nicht ausgeführt“ ist besser als ein Erfolg ohne Beleg. Das CSV-Raster lässt die Spalten für Beobachtung, Datum und Nachweis leer. Sie können eine Prüfung außerhalb des Geltungsbereichs nur streichen, wenn Sie begründen, warum, und die Zustimmung des Entscheiders aufbewahren.

Die Referenzaufgabe zu einer Übergabe machen

Wählen Sie ein zulässiges Beispiel, das die Einschränkungen der tatsächlichen Arbeit sichtbar macht. Eine winzige Demonstration ist nützlich, um den Start zu prüfen; sie ersetzt jedoch keinen Fall, der den Speicherspitzenwert, die Zwischendateien oder den endgültigen Export offenlegt. Halten Sie die Kennung des Testsatzes, die Versionen und die Parametrierung fest. Die gemeinsame Ablage verweist auf die Methode zur Bereitstellung der Secrets, ohne deren Wert zu speichern.

Der Anwendungsverantwortliche führt einen vollständigen Zyklus von einem bekannten Start bis zum Öffnen der Ausgaben durch. Anschließend wiederholt die Betriebsperson den Ablauf anhand der Prozedur, ohne von einem verborgenen Zustand im Terminal der ersten Person abhängig zu sein. Ziel ist es, eine nutzbare Übergabe zu prüfen: Pfade, Rechte, Start, Speicherort der Protokolle und Wiederherstellung.

Legen Sie außerdem fest, was nach einem beherrschten Fehlschlag geschieht. Eine temporäre Ausgabe muss von einem akzeptierten Ergebnis unterscheidbar sein. Die Abnahmeakte darf keinen Wiederaufnahmemechanismus erfinden, den die Anwendung nicht besitzt: Sie stellt den vorhandenen fest und verweist auf die Migrationsprozedur, um unterbrochene Stapel zu organisieren. Ist die Berechnung numerisch, gehört die Toleranz zum fachlichen Protokoll; Bit-für-Bit-Identität ist keine universelle Anforderung.

Wenn Sie mehrere Konfigurationen vergleichen, halten Sie dieses Protokoll konstant. Notieren Sie auch Fehler und zu wiederholende Tests. Die endgültige Entscheidung kann eine Option bevorzugen, weil sie die Arbeitswarteschlange, die Abnahme oder den Zeitplan vereinfacht; sie muss nicht aus einem einzelnen Messwert eine allgemeine GPU-Rangliste machen.

Ein ausgefülltes Beispiel lesen, ohne es für eine Messung zu halten

Das herunterladbare Beispiel „Atelier des plans“ ist vollständig fiktiv. Ein Team möchte einen Testkorpus aus zwölf technischen Dokumenten verarbeiten und anschließend einen von den Prüfern nutzbaren Index abrufen. Die zwölf Dokumente sind eine Organisationsannahme; es werden keine Geschwindigkeit, kein Speicherverbrauch und keine GPU-Messwerte angegeben. Das Ziel H100 ist eine Kandidatin für die Rahmenplanung, die nach Prüfung der Software und der Last noch zu bestätigen ist.

Der Anwendungsverantwortliche bereitet den Start und die erwarteten Zugangsdaten vor. Der Betrieb kontrolliert die Zugriffe und die Rückgabe der Dateien. Die für die Ergebnisse zuständige Person muss bestätigen, dass jedes Dokument eine lesbare Ausgabe und eine Referenz im Index besitzt. In diesem Szenario konnte sie den Export von ihrem Zielort noch nicht öffnen. Die Hardware- und Anwendungszeilen bleiben nicht ausgeführt; die fiktive Entscheidung lautet daher „Inbetriebnahme blockiert“.

Dieses Beispiel zeigt, wie man Verantwortlichkeiten ausfüllt und eine nachvollziehbare Entscheidung trifft, ohne einen Erfolg zu konstruieren. Das Fehlen eines Exportnachweises ist keine bloße Randnotiz: Es blockiert genau die Nutzung, die abrufbare Ergebnisse erfordert. Der neue Versuch muss diese Kontrolle wieder aufnehmen, seinen Nachweis beifügen und die Entscheidung datieren lassen. Es genügt nicht, den Kommentar in der Tabelle zu löschen.

Ablehnen, unter Vorbehalt annehmen oder Entscheidung vertagen

Ein nicht erfülltes blockierendes Kriterium stoppt die Abnahme des betroffenen Umfangs. Eine unmögliche Kontrolle wird nicht automatisch als bestanden gewertet: Sie erzeugt einen Status „blockiert“ oder „nicht ausgeführt“, eine Aktion und einen Verantwortlichen. Vermeiden Sie es, „Vorbehalt“ zu verwenden, um eine Arbeitsvoraussetzung zu verschleiern. Wenn eine Ausgabe nicht abgerufen werden kann, erlaubt die Annahme der Berechnung allein nicht die vollständige Kette.

Ein Vorbehalt kann für einen zweitrangigen Punkt geeignet sein, wenn die zulässige Nutzung klar begrenzt ist, eine vorläufige Lösung geprüft wurde und jemand diesen Umfang akzeptiert. Vermerken Sie eine Frist für die Nachkontrolle und was geschieht, wenn sie nicht eingehalten wird. Eine auf einen Test beschränkte Abnahme gilt nicht als Produktionsabnahme.

Das Protokoll hält die Entscheidung fest, die Kontrollen, die sie begründen, und diejenigen, die offen bleiben. Die technische Abnahme bestätigt weder eine Zahlung noch einen vertraglichen Termin: Diese Vorgänge behalten ihre eigenen Referenzen. Sobald die Kriterien erfüllt sind, übergibt das Team dem Betrieb den Start, die Versionen, die Speicherorte der Daten und das Verfahren für die Ausgabe.

Das Abnahmedossier Version 1 herunterladen und verwenden

Die Markdown-Vorlage dient als Deckblatt und Protokoll. Die CSV-Tabelle liefert die anzupassenden Kontrollen, mit Spalten für die Nachweisstufe, den Verantwortlichen, das vor dem Test festgelegte Kriterium, die Methode, die Beobachtung, den Nachweis und den Status. Öffnen Sie die CSV in UTF-8 mit dem Komma als Trennzeichen; die Ergebnisfelder sind bewusst leer. Bewahren Sie vor der Bearbeitung eine leere Kopie auf.

Öffnen Sie die Vorlage mit einem Texteditor und die Tabelle mit einer Tabellenkalkulation. Passen Sie das fiktive Beispiel an Ihre Anforderungen an und erfassen Sie dann die Beobachtungen auf Ihrer eigenen Maschine. Die bereitgestellte Lizenz erlaubt die Nutzung und Anpassung unter Beibehaltung des Hinweises; die Namen von Produkten und externen Dokumentationen behalten ihre jeweiligen Rechte.

Nutzen Sie diese Abnahme, um einen präzisen Umfang freizugeben, und ergänzen Sie sie bei einem Wechsel von Versionen, Daten oder Betriebsart. Sie ist weder ein universeller Benchmark noch eine Garantie für Unterbrechungsfreiheit. Der Migrationsleitfaden übernimmt, sobald ein Arbeitszustand verschoben und das Schicksal jedes Stapels erklärt werden muss.