Updated 4 days ago
Hugging Face adds a versioned lookup for Trainium model tests

Hugging Face adds a versioned lookup for Trainium model tests

The torch‑neuronx lookup pairs compiler and library versions with test records and scripts. Its PASS, exclusion and short‑generation checks need to be read within their documented scope.

Start with the compiler and library versions

Hugging Face’s [October 23 post](https://huggingface.co/blog/torch‑neuronx‑model‑support) introduces a model‑support lookup for `torch‑neuronx`, the native PyTorch backend for AWS Trainium. The [public Space](https://huggingface.co/spaces/aws‑neuron/torch‑neuronx‑model‑support) pairs model test results with the stack and script used to produce them. Developers can choose the Neuron compiler (`neuronx‑cc`) and Transformers versions before interpreting a result. That version choice matters. The linked [dataset card](https://huggingface.co/datasets/aws‑neuron/torch‑neuronx‑model‑support) says most compiler/library combinations are never tested. A model absent from one version pair was not tested there; its absence does not mean that it failed. The lookup is a record of particular runs, rather than a promise covering every package combination.

The selected view covers a subset of the Hub

The Space opens on a Selected view drawn from models ranked by downloads and trending score. Trending and Downloads views let users search within a task’s ranking, including models without a test result. [The announcement explains](https://huggingface.co/blog/torch‑neuronx‑model‑support) that an omitted model may simply not have been prioritized. The dated post describes a selection limited to text‑generation and image‑text‑to‑text Transformers models. The [dataset card inspected for this report](https://huggingface.co/datasets/aws‑neuron/torch‑neuronx‑model‑support) also documents encoder‑decoder and text‑encoder tests. These documents therefore describe different levels of scope; the card’s current protocol should be checked alongside the versioned result. It also says quantized checkpoints and models requiring `trust_remote_code` are left out. An exclusion from this sweep establishes no general incompatibility claim.

PASS, failure and exclusion have different meanings

Under the card’s result definitions, PASS means the model loaded, generation or an encoder forward pass returned, and the output check passed or could not run. That final condition is material: a PASS label alone does not establish that an output check completed.

EXCLUDED records a selection decision, with the reason in the notes, rather than a failed execution. Failure labels distinguish loading, generation, encoder forward‑pass and output‑check failures; FAIL(other) includes crashes and additional‑package installation failures. Read the notes, stack versions and tested_at time with the label. The project says a model leaving the selection list keeps its earlier results, so an existing record should not be mistaken for a fresh test on every sweep.

The generation check is short and hardware‑bounded

For generative tests, the [card describes](https://huggingface.co/datasets/aws‑neuron/torch‑neuronx‑model‑support) loading a model on a Trainium2 instance and generating 32 tokens greedily from a fixed prompt. In the sharded generation path, it distributes the model’s bf16 weights over the smallest power‑of‑two core count that fits them. Encoder‑decoder models run their encoder once and then generate from the decoder on one NeuronCore. On one NeuronCore, the output check compares tokens with a CPU run of the same checkpoint and prompt, allowing a first difference at a near‑tie. On more cores, or when the CPU run cannot complete, a small instruct model judges whether the text is fluent English. Those are documented checks with different criteria. They do not establish general output quality or the behavior of longer generations. Text‑encoder records use one forward pass on one NeuronCore and their own documented checks, rather than the same 32‑token generation procedure. The card limits the tested models to those fitting on four Trainium2 devices, or at most 16 NeuronCores. That is the dataset’s test ceiling, not a general limit on Trainium hardware. Both the [blog](https://huggingface.co/blog/torch‑neuronx‑model‑support) and card explicitly say PASS establishes nothing about throughput or longer generations.

Reproduce the recorded stack before extending the workload

The [project’s recipe](https://huggingface.co/datasets/aws‑neuron/torch‑neuronx‑model‑support) supplies a standalone `run_py` script whose header identifies the Neuron stack and additional packages. On a Trainium2 instance with that stack, the documented next step is to install those packages and run `python3 run.py`. The script launches its own distributed ranks when more than one NeuronCore is used. The project also points to a public NEFF cache for compiled graphs, keyed by compiler version, as a way to skip compilation in its reproduction recipe. A cached graph or a PASS from one stack should not be treated as evidence for a different compiler, checkpoint or workload. OpenTools has read the project’s documentation; it has not queried individual model results, run these scripts or measured model performance. *AWS Loft in SoHo, New York City, photographed on June 21, 2019. Archive AWS developer‑space context, not a Hugging Face office, Trainium chip or test location. Photo: [Ajay Suresh](https://www.flickr.com/people/83136374@N05), via [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Amazon_Web_Services_(AWS)_Loft_-_NYC_(48129118457).jpg), [CC BY 2.0 Generic](https://creativecommons.org/licenses/by/2.0/deed.en). Resized and cropped for display.*

Share this article

PostShare

Related News