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.