先看证据
先把“可能能跑”变成可查记录
Hugging Face 在博客中介绍了一个面向 AWS Trainium 的 torch-neuronx 模型支持 Space，用来查询 Hub 上的模型能否在 Trainium 上不经修改运行，并提供对应的运行脚本。它建立在 TorchNeuron 这一 PyTorch 后端之上：Transformers 使用自身的模型实现代码在 Trainium 上运行，而不是要求每个模型都先改写成另一套专用实现。
这项工具回应的是一个容易被“支持 PyTorch”掩盖的工程问题：框架具备后端，并不等于模型、编译器和依赖组合已经验证可用。Space 把检查对象落到具体模型和版本上，展示运行结果、分片使用的 Trainium 核数、包含编译时间的总耗时，以及设备峰值内存。对负责选型的人来说，这比笼统的硬件兼容声明更接近真正需要做的判断。
支持结果必须连同测试边界一起读
Space 默认展示精选模型，这些模型从 Hub 下载量和趋势分数靠前的模型中选出。用户也可以切换到 Trending 或 Downloads 视图，按任务查看 Hub 排名并搜索模型名称；这两种视图会列出排名中的模型，即使它们尚未测试。若某个模型被有意略过，页面会说明原因，通常是暂未优先处理，也可能是确实不兼容。用户还可以选择要查看的 Neuron 编译器 neuronx-cc 和 Transformers 版本，因此“支持”不是脱离软件版本的单一标签。
每项测试是在 Trainium2 实例上进行的，模型会分片到能够容纳其权重的最少核数；大多数模型采用张量并行，没有张量并行方案的混合专家模型则只采用专家并行。当前测试范围最多是 4 台 Trainium2 设备，也就是至多 16 个核心。测试生成 32 个 token：单核运行会与同一检查点的 CPU 输出比较，分片运行则由一个小型评判模型检查生成文本是否为流畅英语。这套验证能说明模型在有限条件下可运行，却不能证明更长生成也正确，或系统具有足够的吞吐量。
脚本把兼容性结果接到部署路径上
查到模型之后，页面会给出测试时使用的 Neuron 软件栈、需要额外安装的软件包，以及实际运行的 run.py。脚本按 TorchNeuron 的既定方式加载模型，必要时进行分片，再用静态缓存和 torch.compile(backend="neuron") 生成文本。部署者可以在装有相同软件栈的 trn2 实例上运行它，例如使用 AWS Neuron Deep Learning Container；模型分片时，脚本会自行启动 torch.distributed ranks，不需要额外用 torchrun 启动。
第一次运行会编译模型计算图，因此测试记录里的耗时包含了编译成本，但之后的运行不一定需要重复承担这一步。Space 还提供从公开 NEFF 缓存桶取回相应编译器版本图文件的命令，形式为 `hf buckets sync hf://buckets/aws-neuron/torch-neuronx-neff-cache/neuronxcc-<version> /tmp/neff_cache`。这让测试结果不只是一个“通过”标记，而是带有版本和执行入口的复现线索；不过，复现仍以使用匹配的编译器和软件栈为前提。
它适合筛兼容性，不适合替代性能评估
支持结果还可以从公开的 aws-neuron/torch-neuronx-model-support 数据集中检查。数据按 neuronx-cc 与库版本的组合保存为 Parquet 文件，每行记录模型结果、失败时的错误、完整软件栈版本和实际运行脚本。团队既可以在 Space 中查，也可以用 pandas 读取数据集后按模型筛选；这使一次模型运行留下的证据能够被程序化整理，而不只是一张网页上的状态说明。
但目前测试只覆盖 Transformers 模型中的文本生成和图文到文本任务，Diffusers、Sentence Transformers 和其他 Transformers 任务仍在计划扩展之列。更重要的是，PASS 不代表吞吐达标，也没有覆盖更长的生成。合理的用法是先用它缩小候选范围，再在自己的实例、软件版本和负载下测性能与稳定性；如果任务超出已测试的模型、设备规模或生成长度，就应把页面结果视为兼容性线索，而不是上线承诺。