Focused Testing for PyTorch Backends
TorchCTS gives backend engineers a practical test suite for operator bring-up, focused debugging, regression testing, and release validation.
It builds on PyTorch operator metadata, dispatcher behavior, reference behavior, and testing conventions, then adds backend-focused selection, generated coverage, structured results, and reusable artifacts.
Built For Backend Development
PyTorch provides a deep testing foundation for the framework as a whole. An individual backend team needs a smaller test surface centered on the behavior its backend implements.
TorchCTS organizes that work into focused runs that can start during implementation and grow into regression and release coverage.
Start With Ready-Made Tests
Use PyTorch-sourced operator data, generated dispatcher cases, and hand-authored backend tests instead of creating an entire test program from scratch.
Work In Focused Slices
Narrow a run by dtype, semantic level, suite, operator selection, or path-shape family while implementing a feature.
Expand Support Deliberately
Start with the behavior that works today. Expand the manifest and test surface as the backend implementation grows.
Keep Fixes Covered
The same focused tests become regression coverage in local development and CI.
Release With Evidence
Broader runs produce result artifacts, coverage audits, runlogs, and crash records for release review.
Finding gaps during development helps teams release more complete backends and rely less on downstream users to discover the long tail of unsupported behavior.
How TorchCTS Fits With PyTorch
PyTorch and TorchCTS have different scopes in the same ecosystem. PyTorch defines the framework behavior. TorchCTS helps backend teams apply that behavior throughout an external backend's development lifecycle.
PyTorch Provides The Foundation
PyTorch defines operator schemas, dispatcher semantics, dtype behavior, reference implementations, OpInfo metadata, and upstream framework tests.
TorchCTS Provides A Backend Workflow
TorchCTS uses those foundations to build focused backend runs, track configured and filtered behavior, measure dispatcher coverage, preserve crash evidence, and write reusable result artifacts.
TorchCTS does not define an alternative version of PyTorch behavior and does not replace PyTorch's upstream tests. PyTorch remains the source of truth for the semantics a backend implements.
From Development To Evidence
Focused development runs grow into broader regression coverage and release evidence.
Set the device, import path, implemented dtypes, capabilities, semantic level, and resource limits.
Choose the dtype, level, suite, operator selection, or path-shape family under development.
TorchCTS selects the versioned operator expectations for the installed PyTorch release.
Use the result, report, and runlog to identify the implementation gap and rerun the focused slice.
Add dtypes, capabilities, operators, suites, or deeper semantic levels as support grows.
Broader CI runs produce coverage audits, reports, runlogs, and crash records.
Current Focused Suite
TorchCTS keeps the backend test surface practical for repeated development and CI runs while measuring coverage of backend-relevant dispatcher behavior.
Stats generated July 20, 2026 at 21:07 UTC with Python 3.14.2 and PyTorch 2.12.1 using: python -m pytest --collect-only -q torchcts --validation --level 8
Test count and dispatcher coverage describe different things. The suite also includes generated and hand-authored tests for dtype, layout, aliasing, mutation, autograd, device APIs, workloads, memory behavior, and crashes.
Who TorchCTS Is For
TorchCTS supports backend work from the first implementation slice through release review.
Backend developers
Use focused tests while implementing operators, dtypes, device behavior, and compiler paths.
Backend maintainers
Keep fixes covered, review regressions, and expand support without losing visibility into filtered work.
Accelerator vendors
Validate backend behavior on target hardware and preserve release evidence.
Compiler and runtime teams
Exercise dispatch, dtype, shape, layout, mutation, aliasing, compilation, and workload behavior.
CI and release owners
Run repeatable gates and retain structured artifacts when a job fails.
Backend evaluators
Review what passed, failed, crashed, remained filtered, or still needs coverage work.
First Run
Install TorchCTS in the Python environment used for backend development, create a starter manifest, and run the smallest useful test surface.
python -m pip install torchcts
torchcts init --template smoke --non-interactive
torchcts check-manifest
torchcts run --device cuda --level 1 --report-skipsIf you are working on a backend, run these commands in the virtual environment you use for backend development. That gives TorchCTS the same PyTorch wheel and backend package you are validating.
Replace cuda with the backend you are validating. For PrivateUse1 backends, set backend_import and device_name in the manifest.
This first run can become the starting point for a backend TDD loop. Keep the selection focused while implementing the behavior, then retain the broader run in CI after it passes.
For a complete first-run walkthrough, see Run The Suite.
Not a backend engineer, but want to try TorchCTS?
Use the online installer when you want a separate TorchCTS install without changing a backend development environment.
curl -fsSL https://torchcts.ai/scripts/install.sh | shirm https://torchcts.ai/scripts/install.ps1 | iexChoose A Workflow
Start with the engineering task in front of you.
Implement A Backend Feature
Run a focused dtype, suite, operator, semantic-level, or path-shape selection while developing the implementation.
Configure Backend Support
Describe the device and the support surface currently available in the backend environment.
Add Regression Coverage
Keep a focused fix covered locally, then add the appropriate broader run to CI.
Prepare A Release
Run coverage checks and release-depth validation, then retain the complete result artifacts.
Review Exact Fields And Flags
Use the reference pages for manifest fields, CLI values, test inventory, backend notes, and artifact paths.