Laya-CoreML 0.1.0 Release-Artefakte

Installiere die öffentliche Laufzeit auf Apple Silicon:

python -m pip install 'laya-coreml[demo]==0.1.0'

Das Wheel enthält Inferenz, Hub-Laden, die Terminal-Snake-Demo und ihren Replay-Renderer. Modellgewichte werden separat heruntergeladen. PyTorch ist eine optionale Exportabhängigkeit; MLX ist eine optionale Vergleichsabhängigkeit. Keine von beiden ist erforderlich, um die veröffentlichten Modelle auszuführen. Siehe das PyPI-Projekt.

Fixierte Modell-Releases

Alle sechs Repositories sind öffentlich. Jedes enthält das exportierte Core ML-Paket, Tokenizer, Konfiguration, Modellkarte, Lizenz, Attribution und Validierungsbericht. ANE-Pakete enthalten außerdem die exakten Host-Embedding- und Action-Head-Tensoren. Sie sind eigenständige Inferenz-Bundles.

Zum Beispiel:

hf download aac6fef/laya-multilingual-coreml-ane \
  --revision 39d6a9b3d0f67f06da74fbade6121ea134cbdb21 \
  --local-dir models/ane
laya-coreml-snake --model ./models/ane

Oder lade einen fixierten Hub-Snapshot direkt:

import laya_coreml as laya

agent = laya.load(
    "aac6fef/laya-multilingual-coreml-ane",
    revision="39d6a9b3d0f67f06da74fbade6121ea134cbdb21",
)

Das Release-Inventar, die Paket-Hashes, Shapes und vollständigen Bundle-Größen stehen in hub-release.json. Das W8-Bundle ist etwa 557 MB groß einschließlich Host-Embeddings und Tokenizer; 129 MB beschreiben nur seinen Core ML-Body. W8 ist Gewichts-Palettierung mit FP16-Berechnung, keine Integer-Aktivierungsquantisierung.

Modell- und Paketverifizierung

Jedes veröffentlichte Paket wurde vor dem Upload gegen seinen archivierten validierten Export geprüft. Die portablen ANE-Bundles erhalten den ursprünglichen Core ML-Body und extrahieren sechs Host-Tensoren mit exakter Elementgleichheit. Die Inferenz zur Paketierungszeit wiederholte dann die Upstream-Golden-Fixture-Prüfungen:

Die kurzen Exporte weisen Fixtures jenseits ihrer Eingabekapazität zurück. Ihre passenden Teilmengen sind explizit; sie sind keine Äquivalenzaussagen über den vollen Kontext. Alle verwenden dieselbe Wahrscheinlichkeitsabweichungs-Schwelle von 0.02. Die allgemeinen Checkpoints decken 189/189 Fragen ab; die sechs Bundles zusammen decken 319 passende Vergleiche ab, mit Überlappung zwischen den Checkpoints. Siehe release-validation.json.

Eine frische Python 3.12-Umgebung installierte das gebaute Wheel und das Demo-Extra, ohne Torch, MLX oder Transformers. Alle sechs lokalen Bundles wurden geladen und erzeugten stabile Vorhersagen, während Python-Socket-Verbindungen blockiert waren. Danach wurde ein öffentlicher, fixierter ANE-Hub-Snapshot geladen, gefolgt von einem zweiten Ladevorgang aus dem Cache mit blockierten Netzwerkverbindungen. Kein Offline-Abschnitt versuchte eine Verbindung. Diese Prüfung übte auch den in USAGE.md beschriebenen Fix zur Materialisierung von Core ML-Symlinks aus. Ergebnisse: wheel-runtime-smoke.json.

Version 0.1.0 wurde am 2026-09-20 auf PyPI veröffentlicht. Beide öffentlichen Distributionsdateien wurden heruntergeladen, und ihre SHA256-Digests stimmten mit den lokalen Release-Artefakten überein. Eine zweite neue Umgebung installierte dann laya-coreml[demo]==0.1.0 direkt aus dem öffentlichen PyPI-Index mit deaktiviertem Caching. Das direkte Hub-Ladebeispiel des README lief erfolgreich, gab null Ausgabe-Tokens zurück und lieferte bei drei Wiederholungsaufrufen dieselbe Antwort, während die Netzwerkverbindungen während der Vorhersage blockiert waren. Beide installierten CLI-Einstiegspunkte starteten ebenfalls erfolgreich. Siehe Veröffentlichungsbeleg und Inferenzprüfung der öffentlichen Installation.

Die Release-Prüfungen reproduzieren

Das lokale Release-Gate bestand 64 Tests, Ruff-Lint-/Formatprüfungen und eine strikte Twine-Paketmetadaten-Validierung. Die Tests umfassen Konvertierungssemantik, Bundle-Cache-Integrität, Spielinvarianten, Offline-Modellauflösung und exaktes Replay jedes Boards und jeder Aktion in der veröffentlichten 855-Züge-Aufzeichnung.

Das Build-Backend ist auf Hatchling 1.31.0 fixiert. Seine Core Metadata 2.4-Ausgabe besteht den Twine 6-Prüfer des Releases; ein erster Build mit den neueren Standardmetadaten 2.5 wurde abgelehnt. Siehe Hatchlings Versionsverlauf für die Standardänderung. Die veröffentlichten Artefakte verwenden den kompatiblen Build und werden vor dem Upload erneut geprüft. Die exakten SHA256-Digests von Wheel und Source-Distribution sind in distribution-files.json festgehalten.

Aus einem Quell-Checkout mit den verfügbaren ursprünglichen validierten Artefakten:

uv sync --extra convert --extra dev --extra compare --extra research --extra demo --extra publish
.venv/bin/python scripts/prepare_hub.py
.venv/bin/python -m benchmarks.release_validate models/hub/* \
  --output benchmarks/results/release-validation.json
.venv/bin/ruff check .
.venv/bin/ruff format --check .
.venv/bin/pytest -q
.venv/bin/python -m build
.venv/bin/twine check --strict dist/*

prepare_hub.py weigert sich, vorhandene Bundle-Verzeichnisse zu überschreiben. Die eigenständige Wheel-Prüfung läuft mit scripts/wheel_smoke.py --hub-check in einer frischen Umgebung von außerhalb des Quellbaums, nachdem die sechs Bundles heruntergeladen oder vorbereitet wurden. Siehe SNAKE_BENCHMARKS.md für vollständige Messungen der Spielschleife und LAUNCH.md für die exakten Quellen der aufgezeichneten Medien.

0.2.0 Upstream-Synchronisierung

Dieses Release portiert anwendbare Prompt-Validierung, benutzerdefinierte noul-Labels, Unicode-Anweisungen, Konversationsende-Trunkierung, Optionen-Zusammenfassungs-Diagnosen und Antwortkonfidenz-Berichte über den Upstream 4aa6761. Es veröffentlicht außerdem die Temperaturbegrenzung, die in Quelle 0.1.1 vorhanden, aber in PyPI 0.1.0 nicht enthalten war. Core ML-Graphsignaturen, Gewichte und ANE-Kapazitätsprüfungen bleiben unverändert. Die historischen Benchmark-Ergebnisse oben beschreiben 0.1.0, nicht einen neuen Performancelauf. Latenz bei gemischten Fragen und Intel Mac-Unterstützung wurden durch diese Synchronisierung nicht validiert.

Pushe einen v<version>-Tag, nachdem du pyproject.toml, laya_coreml/__init__.py und uv.lock aktualisiert hast. Der Release-Workflow führt die wiederverwendbaren CI-Prüfungen aus, verifiziert alle drei Versionen gegen den Tag, baut und validiert Wheel/sdist, veröffentlicht auf PyPI unter Verwendung des Repository-Secrets PYPI_API_TOKEN und erstellt ein GitHub-Release mit denselben Distributionen. Ein CI-Fehler verhindert die Veröffentlichung.