Dies ist der zweite Beitrag einer Beitragsreihe auf diesem Blog, in der ich meinen Versuch beschreibe, eine eigene neuronale Engine für Maschinenübersetzung einzurichten. Im ersten Beitrag stellte ich mich und das Projekt vor.
Für die Einrichtung von neuronalen Netzen ist die richtige Wahl der Hardware ebenso wichtig wie die Wahl der Software und der Algorithmen, da das Training neuronaler Netze im Grunde aus einer Unzahl an Matrixmultiplikationen besteht, die am besten parallel erfolgen. Das ist auch der Grund für die raschen Fortschritte bei künstlichen neuronalen Netzen in den letzten Jahren, da aufgrund der Erfindung von LCD-Monitoren und der wachsenden Beliebtheit von Spielen mit virtueller Realität mehr und bessere dedizierte Grafikprozessoren (GPUs) auf den Markt gekommen sind. Das Konzept eines neuronalen Netzes ist nicht neu. Künstliche neuronale Netze wurden bereits in den 40er Jahren konzipiert. Bis vor Kurzem konnte man damit jedoch keine praktischen Aufgaben lösen, da normale CPUs mit seriellen Rechenvorgängen für die damit verbundenen Berechnungen nicht ausreichen. Erst die Markteinführung von ausreichend rechenstarken GPUs brachte den Durchbruch, da GPUs eigens für intensive parallele Rechenaufgaben und Matrixmultiplikationen konstruiert sind.
Aber ich schweife vom Thema ab. Dieser Beitrag befasst sich mit der Einrichtung der richtigen Hardware für ein neuronales Netz für maschinelle Übersetzung (NMÜ). Die Entwickler der verschiedenen Open-Source-NMÜ-Toolkits empfehlen eine leistungsstarke GPU mit mindestens 6 GB an dediziertem, internem GPU-Arbeitsspeicher. Deshalb habe ich sofort zugeschlagen, als mein lokaler Händler in Sachen Gadgets für Nerds, Fry’s, einen sogenannten Gaming-PC von Asus mit einer Nvidia GeForce GTX-1070-Grafikkarte mit 8 GB Grafikspeicher stark reduziert im Angebot hatte. Die 1070 ist eine Leistungsstufe niedriger als das derzeitige Top-Produkt von Nvidia, die GTX 1080 Ti, kostet jedoch nur ungefähr die Hälfte der 1080 Ti. AMD stellt mit seiner Radeon-Serie ebenfalls gute GPUs her, aber da dieser Asus-PC als Ausstellungsstück extrem günstig war, war die Wahl getroffen. Leider ist das BIOS von Asus mit seinen eigenen Problemen verbunden, die ich nun beschreiben werden. Wenn Sie also an den (allzu) technischen Details der Einrichtung des PCs interessiert sind, lesen Sie bitte weiter.
Auf dem PC war Windows 10 vorinstalliert, was aber für rechenintensive Anwendungen wie neuronale Netze eher ungeeignet ist. Alle oben erwähnten Open-Source-Toolkits laufen standardmäßig auf Linux. Ich entschloss mich, Windows 10 auf der Maschine zu belassen, da der PC ohne Installationsmedium geliefert wurde, obwohl ich nicht die Absicht habe, je auf dem Gaming-PC Computerspiele zu spielen. Deshalb partitionierte ich die Festplatte neu, was mit Windows 10 erstaunlich einfach war. Dann installierte ich mithilfe eines USB-Flashspeichers Ubuntu in einer Dual-Boot-Konfiguration. Anleitungen hierzu gibt es im Web zuhauf. Alles schien glatt zu laufen, bis ich bemerkte, dass Ubuntu nicht den Treiber von Nvidia verwendete, sondern einen anderen Treiber. Das verfehlt jedoch den ganzen Sinn der 1070-Karte, da dieser andere Treiber nicht alle Funktionen der Karte nutzen kann. Und damit begannen die Probleme.
Ich installierte also den neuesten Nvidia-Treiber für Ubuntu mit den folgenden Befehlen (lassen Sie „sudo“ weg, wenn Sie als root eingeloggt sind):
sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt-get update
sudo apt-get install nvidia-384
384 ist die neueste Treiberversion zum Zeitpunkt der Abfassung dieses Beitrags. Nach dem Neustart, um den Treiber zu aktivieren, begann die Sache jedoch schief zu laufen. Ich konnte mich nicht einloggen und wurde immer wieder zum Login-Bildschirm zurückgeworfen, egal, was ich versuchte.
Die Ursache des Problems schien die sogenannte Secure-Boot-Einstellung im Asus UEFI BIOS zu sein, die so viel Sinn macht wie ein Sandkasten in der Sahara. Diese Einstellung soll verhindern, dass Nicht-Windows-Betriebssysteme bestimmte Firmware verwenden, die vom Systemhersteller nicht geprüft wurde, auch wenn diese Firmware von einem Hersteller einer der Systemkomponenten stammt — in meinem Fall vertraut also Asus Nvidia nicht. Nach einem weiteren Neustart gelangte ich mithilfe von F2 ins UEFI BIOS zu den Secure-Boot-Einstellungen. Ich konnte die Funktion nicht deaktivieren, da „Enabled“ grau unterlegt und fixiert war. Also wählte ich stattdessen die Option „Other OS“ statt „Windows OS“, siehe die Screenshots unten. Dadurch löste ich zumindest eines der Probleme.

Boot-Einstellungen im Asus UEFI BIOS

Detailansicht der Boot-Einstellungen im Asus UEFI BIOS
Nach einem weiteren Neustart wurde ich von einem Bildschirm voller Fehlermeldungen über einen PCIe-Busfehler, pcieport usw. begrüßt, der ununterbrochen scrollte. Dazu wurden die Dateien syslog
und kern.log
mit ebendiesen Fehlermeldungen so vollgeschrieben, dass sie meine gesamte TB-Festplatte füllten und das System einfror. Hier schaffte die Einfügung einer weiteren Option in das Grub-Boot-Menü Abhilfe:
- Ich gelangte mit
Strg + Alt + F1
zur Befehlszeile. - Dort leerte ich die Dateien
syslog
und kern.log
, die meine gesamte Festplatte füllten, mit den folgenden Befehlen:
sudo truncate -s0 syslog
sudo truncate -s0 kern.log
- Danach erstellte ich eine Sicherungskopie der grub-Datei und öffnete die Originaldatei folgendermaßen:
sudo cp /etc/default/grub /etc/default/grub.bak
sudo -H gedit /etc/default/grub
In gedit ersetzte ich die Zeile
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”
durch
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash pci=nomsi”
MSI bedeutet Message Signaled Interrupts, die das System vor Einfrierungen bei Interrupts schützen sollen. Es ist jedoch bekannt, dass bestimmte Hardwarekombinationen MSI nicht unterstützen und das System dabei einfriert, was MSI eigentlich verhindern sollen. Scheinbar ist mein PC mit Asus-Motherboard mit Intel-Chipset und einer Nvidia GeForce-GPU auf Ubuntu 16.04 ein Beispiel dafür.
- Ich speicherte die bearbeitete grub-Konfiguration und verließ gedit. Danach aktualisierte ich grub und startete das System neu:
sudo update-grub
sudo reboot
Seither habe ich einige GPU-intensive Berechnungen (ohne künstliche neuronale Netze) durchgeführt und das System scheint stabil zu laufen. Keine überlaufenden Log-Dateien, keine PCIe-Fehler und keine Probleme beim Neustarten oder Einloggen. Die Windows-Seite scheint ebenfalls stabil zu sein.
Im nächsten Beitrag befasse ich mich mit der schwierigen Wahl des Toolkits — OpenNMT oder Tensorflow von Google?