Dokumentation

ARM64- und DGX-Spark-Container

Das Dockerfile baut für Linux AMD64 und ARM64. Die CPU bleibt auf beiden die Voreinstellung; eine ARM64-CPU impliziert keine NVIDIA-GPU.

Host Konfiguration Validierung
Linux AMD64 CPU compose.yaml CI-Build und -Prüfungen; CPU-Inferenz
Linux ARM64 CPU compose.yaml, auf dem ARM64-Host gebaut CI-Build und -Prüfungen auf einem nativen ARM64-Runner; CPU-Inferenz
Linux AMD64 NVIDIA compose.cuda.yaml hinzufügen (CUDA 12.8) CUDA-Inferenz auf einer RTX 4070 Ti mit dem Basis-Schnellstart
DGX Spark compose.spark.yaml hinzufügen (ARM64, CUDA 13.0), mit oder ohne compose.http.yaml CI baut und lädt die CUDA-Bibliotheken ohne GPU; Spark-Inferenz noch nicht gemeldet
Apple Silicon Linux-ARM64-Container auf der CPU Siehe Apple Silicon

ARM64-CPU

Baue auf dem Zielhost. Docker wählt seine native Architektur:

docker compose run --build --rm laya

Cross-Builds mit docker buildx build --platform linux/arm64 --load -t laya:arm64 . brauchen einen ARM64-Builder oder konfigurierte Emulation. Ein emulierter Build zeigt keine native Inferenzleistung.

DGX Spark

Nutze den Linux-Host des Spark mit seinem unterstützten NVIDIA-Treiber und dem NVIDIA Container Toolkit. Das Override wählt ARM64, CUDA-13.0-Wheels und GPU 0. Verwende es anstelle von compose.cuda.yaml, nicht damit zusammen:

docker compose -f compose.yaml -f compose.spark.yaml run --build --rm laya

Um die HTTP-API auf dem Spark bereitzustellen, füge compose.http.yaml hinzu. Die Einstellungen unter HTTP-Bereitstellung gelten unverändert:

docker compose -f compose.yaml -f compose.http.yaml -f compose.spark.yaml up --build laya-serve

Setze LAYA_GPU_ID, um ein anderes Gerät auszuwählen.

TORCH_VERSION fixiert PyTorch für jeden Build, CPU wie CUDA. Compose liest LAYA_TORCH_VERSION; direkte Builds nehmen --build-arg TORCH_VERSION=2.14.0 --build-arg TORCH_INDEX=cu130. Eine Änderung an einem von beiden erfordert einen Neubau, weil eine Laufzeit-Umgebungsvariable das installierte Wheel nicht ersetzen kann.

PyTorchs CUDA-13.0-Builds für ARM64 hängen von cuSPARSELt 0.8.0 (PyTorch 2.11) oder 0.8.1 (PyTorch 2.14) ab. NVIDIAs AArch64-Wheels für diese beiden Versionen deklarieren manylinux2014_sbsa in ihrer WHEEL-Datei, was pip check ablehnt; 0.9.0 korrigiert das. Der Build prüft, dass die Bibliothek ELF64 AArch64 ist und sich laden lässt, und korrigiert dann dieses Tag und seinen RECORD-Hash. Jede andere Version mit demselben Defekt lässt den Build fehlschlagen, statt die Reparatur zu erhalten, und pip check läuft weiterhin. Das folgt dem Kompatibilitätsbefund von @TheIrritainer in FastLaya.

Spark-Ergebnisse melden

CI hat keine GPU, also braucht die Spark-Inferenz einen Bericht von echter Hardware. Führe dies auf dem Spark aus und gib seine Ausgabe zusammen mit nvidia-smi, den OS- und Treiberversionen und der Image-Revision an:

docker compose -f compose.yaml -f compose.spark.yaml run --build --rm laya python -c '
import json, platform, torch
from pathlib import Path
from laya import load
assert platform.machine() == "aarch64"
assert torch.cuda.is_available()
print(torch.__version__, torch.version.cuda, torch.cuda.get_device_name(0))
print(torch.cuda.get_device_capability(0), torch.cuda.get_arch_list())
agent = load("convaiinnovations/laya", device="cuda")
request = json.loads(Path("/opt/laya/examples/request.json").read_text())
result = agent.predict(request["state"], request["questions"])
assert next(agent.model.parameters()).device.type == "cuda", "fell back to CPU"
assert set(result["answers"]) == set(request["questions"])
print("CUDA inference passed", torch.cuda.max_memory_allocated())
'

Wiederhole das mit jedem Checkpoint, den du ausführen willst. Ein nativer ARM64-CPU-Test belegt keine Unterstützung für Blackwell-Kernel oder GPU-Inferenz. Der plattformspezifische CUDA-Stack von Jetson wird vom Spark-Override nicht abgedeckt.

Apple Silicon

Apples GPU-Beschleunigung braucht natives macOS-PyTorch mit MPS. Docker Desktop führt einen Linux-Container aus, der kein MPS-Backend hat, also nutzt der Container die CPU. Laya hat bereits einen MPS-Gerätepfad, und PR #51 und PR #109 adressieren MPS-Kompatibilität und Leistung außerhalb von Docker.