Deploying Community Models with the Tenstorrent CLI
The Tenstorrent CLI is a single entry point to the Tenstorrent stack for updating, inspecting, serving, and reporting issues. It turns model bring-up into a bundle anyone can serve with one command.
Today, we’re announcing a single command-line interface (CLI) to package and deploy state-of-the-art models on Tenstorrent hardware in three commands. Update, inspect, serve, benchmark, and report issues through one interface. Pull down a model from Hugging Face and get it running on a Blackhole® p150a PCIe card or TT-QuietBox® 2 on day one. Build your own model or modify an existing open source model and push it to Hugging Face for others to use.
With three commands, you can build with any frontier open source model:
- Install the Tenstorrent CLI
- Update to the latest version of the software
- Serve a model
Who should care: Anyone with Tenstorrent hardware who wants to run models like Qwen3.8, Gemma4, Muse-Glimmer, Flux 2 and more, anyone who has lost an afternoon diving deep into low-level libraries to run a model, or anyone who has brought up a model and lacked a way to share it with the community.
What you'll learn: How to go from fresh Tenstorrent hardware to serving a model, and how to turn model bring-up into a bundle someone else can run.
Hour zero: a card and a terminal
Until now, new developers had to clone tt-installer, check the driver against tt-kmd, flash firmware with tt-flash, sanity-check with tt-smi, find a model repo and hope it's compatible with their hardware. Today, the workflow is much simpler, with two commands:
uv tool install tenstorrent
tt updateExample output:
The first command uses uv to install the TT CLI, and the second command brings your machine onto a golden version set: driver, firmware, and stack that were tested together in CI. You no longer have to work out whether your driver, firmware, and TT-Metalium™ versions are compatible. We check that for you before each release.
Next, you check your hardware:
tt device statusExample output:
The output shows every detected card, driver state, firmware, temperature, and utilization. If you’re familiar with tt-smi, this output is the same.
Hour one: first tokens
You didn't buy this hardware to admire telemetry. See what models you can run with a single command:
tt model list
The TT CLI recognizes your hardware, so the list is filtered to the models that you can run. Before you commit to downloading model weights, you can check what you're getting into:
tt model info Qwen/Qwen3.8-Flash-Next # architecture, supported hardware, benchmark numbers
tt model pull Qwen/Qwen3.8-Flash-Next
tt serve Qwen/Qwen3.8-Flash-Next # OpenAI-compatible endpoint
The last command starts an inference endpoint on your own silicon. It’s OpenAI-compatible, so you can curl it, or point opencode or another agent framework at it.
We now support frontier models across modalities: agentic coding, image and video gen, robotics, decision models, and music gen. Run models from Qwen, Muse, Nemotron, Flux, MiniMax, Fishaudio and more.
When something breaks
Software changes quickly, and our goal is to unblock you when issues inevitably come up. We’ve designed error messages so they say what failed and why (when we know). They link to the raw stack trace instead of dumping it. Exit codes are documented so scripts can handle failures too.
Reporting a bug now takes one command:
tt report issueIt prompts you for details, works out which repo the issue belongs to and opens a prefilled GitHub issue with general and repo-specific debug output attached. To keep your data safe, we collect only the Tenstorrent software versions you have installed, and what OS and version of Python you’re running. This is all included in the GitHub issue, so you can edit before submitting.
From consumer to contributor
Model bring-up on new silicon has always had an awkward afterlife. Someone does the hard part - they build custom kernels, patch the tt-metal tree, choose the right vLLM incantation - and the work survives as a branch, a HANDOFF.md, or a dev.to post. The next person can read about the journey, but they can’t run it themselves.
The CLI packages a finished bring-up as a self-contained bundle on the Hugging Face Hub: the tt-nn wheel you built with your custom kernels compiled in, the vLLM plugin, your model code, and an installer that rebuilds the environment in a fresh per-model venv on the consumer's machine. The bundle doesn’t include model weights. It points to the model’s Hugging Face repo,making weights shared, never embedded.
What that buys the next developer is a lightweight contract, not your tt-metal branch:
tt model package you/yourmodel # author + push a bundle
tt model publish you/yourmodel # list it in the community catalog
tt model pull you/yourmodel # pull down any community modelThese bundles serve the engine you built, and your kernels ride along inside the wheel. After a pull, everything lives under one directory; only tt model pull touches the network. The idea is to turn an afternoon of setup into a 90-second download.
This isn't a submission queue. You publish to your own Hugging Face account under your own governance, catalog listing is a separate, explicit opt-in, and the catalog is a static index that stores nothing. Every entry points back to your repo. You don’t need anyone’s permission to publish a model for Tenstorrent hardware, including ours.
A bring-up used to end at "it works on my system." Now it ends at a repo ID anyone can serve from the TT CLI. If you've brought up a model yourself, you'll recognize what this is: the missing last mile.
Some clarifications
In the spirit of a good bring-up log, here are some caveats:
- tt-model-manager sits beneath TT CLI. Use this repo directly for control over your bundles. The bundle format may change as we continue to improve on the functionality.
- We do not maintain community models that are brought up and posted on Hugging Face. We make them easily accessible to the community.
- Compatibility is checked, but not guaranteed. We fail hard when needed (like with architectural mismatches), otherwise, we warn you and let you proceed.
- The TT CLI has opt-in telemetry that is off by default. When telemetry is turned on, it reports which commands are used and where installs fail. We use that to improve the CLI. It doesn’t send personally identifiable information (PII) or secrets. Change this at any time with this command:
tt config set telemetry.enabled true|falseTry it yourself!
If you have a card or TT-QuietBox 2, run these three commands:
uv tool install tenstorrent
tt update
tt serve [model name]then tell us what you find! Join our Discord server here.
If you've brought up a model, even partially, package it. The end-to-end recipe (model → package → push → pull → serve) is in the tt-CLI docs.
