Configure Backend

For release and conformance reporting, the same configuration becomes an explicit statement of supported behavior. Keeping it current makes development runs and release results easier to interpret.

The Minimal Shape

import torch

manifest = {
    "manifest_version": 1,
    "device_name": "my_backend",
    "backend_import": "my_backend_package",
    "supported_dtypes": {
        torch.float32: True,
        torch.float16: False,
    },
    "semantic_level": 2,
    "capabilities": {
        "inference": True,
        "training": False,
        "rng": False,
        "device_api": True,
        "multi_device": False,
    },
}

Use the backend's real device name. For CUDA that is cuda. For MPS that is mps. For PrivateUse1 backends, use the custom name registered by the backend package.

Realistic MPS-Style Excerpt

This example shows how a real in-tree backend configures dtype support, unified-memory hardware settings, resource limits, and a narrow tolerance override.

import torch

manifest = {
    "manifest_version": 1,
    "device_name": "mps",
    "backend_import": None,
    "supported_dtypes": {
        torch.float32: True,
        torch.float16: r"^(add|mul|matmul|mm|bmm)$",
        torch.bfloat16: False,
        torch.float64: False,
        torch.int64: True,
        torch.bool: True,
    },
    "semantic_level": 4,
    "hardware": {
        "memory_model": "unified",
        "device_memory_gb": "auto",
        "system_memory_gb": "auto",
        "oom_recoverable": True,
    },
    "resource_limits": {
        "max_device_memory_mb": 8192,
        "max_tensor_size_mb": 256,
        "cleanup_threshold_pct": 80,
    },
    "capabilities": {
        "inference": True,
        "training": True,
        "rng": True,
        "device_api": True,
        "streams": False,
        "events": False,
        "multi_device": False,
        "sparse": False,
        "compile": False,
        "ieee754": r"^(add|sub|mul|div)$",
    },
    "skip_ops": ["_nested_tensor_from_mask"],
    "tolerance_overrides": {
        "matmul:torch.float16": {"rtol": 1e-2, "atol": 1e-2},
    },
}

Use this as a pattern, not as a configuration for your backend. The exact dtype regexes, capabilities, skipped operators, and tolerances have to match the backend you are validating.

Dtype Configuration

supported_dtypes controls which dtype cases enter the configured support surface.

Set False when the backend does not currently provide the dtype support. Do not change a supported dtype to False only to make an existing regression disappear. The manifest should stay aligned with the behavior the backend intends to provide.

"supported_dtypes": {
    torch.float32: True,
    torch.float16: r"^(add|mul|matmul)$",
    torch.float64: False,
}

Capability Configuration

Capabilities select backend feature families beyond basic tensor operations. Configure the features available in the current backend environment so TorchCTS can include the applicable tests.

Current capability keys are finite. Unknown names fail manifest validation. See Manifest Reference for the exact field rules.

Semantic Level

semantic_level sets the default test depth. It does not declare a backend feature. Use lower levels for fast development feedback and deeper levels for broader regression and release validation. See Semantic Levels for the model and Test Inventory for the current level contents.

Hardware And Resource Limits

Use hardware and resource_limits to keep runs realistic and safe.

hardware describes the memory model, available device memory, system memory, and whether OOM recoveryWhether the backend can catch an out-of-memory error and continue running without corrupting device state. If False, OOM can poison the process. is expected. resource_limits caps device memory, system memory, tensor size, and cleanup behaviorcleanup_threshold_pct sets the memory usage percentage at which TorchCTS triggers garbage collection and cache clearing between tests to prevent OOM. for the run.

"hardware": {
    "memory_model": "unified",
    "device_memory_gb": "auto",
    "system_memory_gb": "auto",
    "oom_recoverable": True,
},
"resource_limits": {
    "max_device_memory_mb": 8192,
    "max_tensor_size_mb": 256,
    "cleanup_threshold_pct": 80,
},

Operator Exclusions And Tolerances

skip_ops is for operator names the backend explicitly does not claim.

tolerance_overrides is for reviewed numerical tolerance differences. Keep it narrow and explainable. A tolerance override must not accept arbitrary drift. See Manifest Reference for accepted tolerance forms.

Quantized And Container Formats

Backends that claim custom quantized decode support must declare the container formats they support and provide decoder specs.

Do not claim custom_quantized_decode without the matching decoder configuration.

Validate The Manifest

torchcts check-manifest
torchcts run --device my_backend --level 1 --report-skips
torchcts show-skips --device my_backend --level 4

A useful manifest is specific and current. It gives developers a focused test surface during implementation and gives release reviewers a clear record of the support that was tested.

TorchCTS 0.4.1 checks configured support against operator contracts for PyTorch 2.7.0 through 2.12.1.