Artefactos da versão 0.1.0 do Laya-CoreML

Instala o runtime público em Apple Silicon:

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

O wheel contém a inferência, o carregamento do Hub, a demonstração de terminal do Snake e o seu renderizador de replay. Os pesos do modelo são descarregados em separado. O PyTorch é uma dependência de exportação opcional; o MLX é uma dependência de comparação opcional. Nenhum deles é necessário para executar os modelos distribuídos. Vê o projeto no PyPI.

Versões de modelo fixadas

Os seis repositórios são públicos. Cada um inclui o pacote Core ML exportado, o tokenizer, a configuração, o cartão de modelo, a licença, a atribuição e o relatório de validação. Os pacotes ANE contêm ainda os tensores exatos de embedding e de cabeça de ação do anfitrião. São pacotes de inferência autónomos.

Por exemplo:

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

Ou carrega diretamente um snapshot fixado do Hub:

import laya_coreml as laya

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

O inventário da versão, os hashes dos pacotes, as formas e os tamanhos completos dos pacotes estão em hub-release.json. O pacote W8 tem cerca de 557 MB, incluindo os embeddings do anfitrião e o tokenizer; 129 MB descrevem apenas o seu corpo Core ML. O W8 é paletização de pesos com cálculo em FP16, não quantização inteira de ativações.

Verificação do modelo e do pacote

Cada pacote publicado foi verificado face à sua exportação validada arquivada antes do upload. Os pacotes ANE portáteis preservam o corpo Core ML original e extraem seis tensores do anfitrião com igualdade exata de elementos. A inferência no momento do empacotamento repetiu depois as verificações do fixture golden do upstream:

As exportações curtas rejeitam fixtures que excedam a sua capacidade de entrada. Os seus subconjuntos compatíveis são explícitos; não são afirmações de equivalência de contexto completo. Todas usam o mesmo limiar de desvio de probabilidade de 0.02. Os checkpoints de uso geral cobrem 189/189 perguntas; os seis pacotes juntos cobrem 319 comparações compatíveis, com sobreposição entre checkpoints. Vê release-validation.json.

Um ambiente novo de Python 3.12 instalou o wheel construído e o extra de demonstração, sem Torch, MLX nem Transformers. Os seis pacotes locais carregaram e produziram predições estáveis enquanto as ligações de socket do Python estavam bloqueadas. Foi depois carregado um snapshot ANE do Hub público e fixado, seguido de um segundo carregamento a partir da cache com as ligações de rede bloqueadas. Nenhuma secção offline tentou uma ligação. Esta verificação também exercitou a correção de materialização de ligações simbólicas do Core ML descrita em USAGE.md. Resultados: wheel-runtime-smoke.json.

A versão 0.1.0 foi publicada no PyPI em 2026-09-20. Ambos os ficheiros de distribuição públicos foram descarregados e os seus resumos SHA256 coincidiram com os artefactos da versão locais. Um segundo ambiente novo instalou depois laya-coreml[demo]==0.1.0 diretamente do índice público do PyPI com a cache desativada. O exemplo de carregamento direto do Hub do README correu com êxito, devolveu zero tokens de saída e produziu a mesma resposta em três chamadas repetidas com as ligações de rede bloqueadas durante a predição. Ambos os pontos de entrada CLI instalados também arrancaram com êxito. Vê recibo de publicação e verificação de inferência em instalação pública.

Reproduzir as verificações da versão

O gate de versão local passou 64 testes, verificações de lint/formatação do Ruff e validação estrita dos metadados de pacote do Twine. Os testes incluem semântica de conversão, integridade da cache de pacotes, invariantes do jogo, resolução offline de modelos e replay exato de cada tabuleiro/ação na gravação publicada de 855 movimentos.

O backend de construção está fixado no Hatchling 1.31.0. A sua saída Core Metadata 2.4 passa o verificador Twine 6 da versão; uma construção inicial que usava os metadados 2.5 predefinidos mais recentes foi rejeitada. Vê o histórico de versões do Hatchling para a alteração da predefinição. Os artefactos publicados usam a construção compatível e são verificados novamente antes do upload. Os resumos SHA256 exatos do wheel e da distribuição de origem são registados em distribution-files.json.

A partir de um checkout do código-fonte com os artefactos validados originais disponíveis:

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/*

O prepare_hub.py recusa-se a sobrescrever diretórios de pacote existentes. A verificação autónoma do wheel corre com scripts/wheel_smoke.py --hub-check num ambiente novo, fora da árvore do código-fonte, depois de descarregar ou preparar os seis pacotes. Vê SNAKE_BENCHMARKS.md para as medições completas do ciclo de jogo e LAUNCH.md para as fontes exatas dos media gravados.

Sincronização com o upstream 0.2.0

Esta versão porta a validação de prompt aplicável, as etiquetas noul personalizadas, as instruções Unicode, o truncamento da cauda de conversa, os diagnósticos de colapso de opções e o relato de confiança da resposta através do upstream 4aa6761. Publica também o clamp de temperatura que estava presente na fonte 0.1.1 mas ausente do PyPI 0.1.0. As assinaturas de grafo, os pesos e as verificações de capacidade do ANE do Core ML estão inalterados. Os resultados históricos de benchmark acima descrevem a 0.1.0, não uma nova execução de desempenho. A latência de perguntas mistas e o suporte de Mac Intel não foram validados por esta sincronização.

Empurra uma tag v<version> depois de atualizar pyproject.toml, laya_coreml/__init__.py e uv.lock. O workflow Release executa as verificações de CI reutilizáveis, verifica as três versões face à tag, constrói e valida o wheel/sdist, publica no PyPI usando o segredo do repositório PYPI_API_TOKEN e cria uma release do GitHub com as mesmas distribuições. Uma falha de CI impede a publicação.