XProf replaces the TensorBoard profiler plugin with a standalone web UI

Four tools over the same profile data, served by one binary

The toolset is what makes XProf more than a trace viewer. The overview page gives a high-level view of the performance of your model, aggregated for the host and all devices together, and it includes a performance summary and breakdown of step times, a graph of individual step times, and high level details of the run environment. The trace viewer shows a timeline of the execution of the model with the duration of each op, which part of the system, host or device, executed an op, and the communication between devices. The memory profile monitors the memory usage of the model, and the graph viewer is a visualization of the graph structure of the HLOs of the model. The HLO graph view is the one that makes it a profiler for the JAX and TensorFlow era rather than a generic tracing tool, since HLO is the intermediate operation graph those stacks compile to. All four read the same profile data, so the question of which one to open is a question about which question you are asking.

The profile data is xplane, and the logdir is where it lands

The data format is the one constraint that matters most in practice. The --logdir option takes the directory containing XProf profile data, described as files ending in .xplane.pb, and if the option is omitted XProf will start without loading any profiles. That single sentence shapes the workflow, because the tool reads files that some other part of your stack produced. The command line table also gives the default port for the XProf web server as 8791, while the usage examples serve on port 6006, which is the TensorBoard port, so that switching between the two servers does not change the URL. The xplane format is the current interchange format for profiler data in this stack, and a team with legacy tensorboard-plugin-profile trace files rather than xplane files has a conversion problem to solve before XProf is useful to them.

Standalone server or TensorBoard plugin, and the two are not identical

There are two ways to view profiles, and the documentation treats them as equals. Standalone, you point the server at a directory of profile data and it serves the UI.

$ xprof --logdir=profiler/demo --port=6006

The optional command name form does the same thing.

$ xprof server --logdir=profiler/demo --port=6006

With TensorBoard installed, the plugin is mounted inside the TensorBoard server instead.

$ tensorboard --logdir=profiler/demo

In the TensorBoard case the profile page lives at localhost:6006/#profile, and if you are behind a corporate firewall you may need to add the --bind_all tensorboard flag. The two paths differ in more than the URL. The standalone server exists so that you can profile without TensorBoard in the environment at all, and the pip install instructions for the TensorBoard route install both packages together, which tells you the plugin is a TensorBoard extension rather than a separate product. Which one you pick is mostly about what is already running in your infrastructure.

Installing from PyPI is one line, and the nightly package is a swap

The standard install is the shortest thing in the readme.

$ pip install xprof

If you want the TensorBoard plugin the two packages go in together.

$ pip install xprof tensorboard

The nightly route is worth reading because of what it uninstalls, since the instructions begin by removing the released packages before installing the nightly one.

$ pip uninstall xprof tensorboard-plugin-profile
$ pip install xprof-nightly

That uninstall step is not a detail. The released package and the nightly package are different distributions with a different name, and the plugin in the release is registered as tensorboard-plugin-profile, so leaving the released plugin installed while adding the nightly one gives you two profilers and a confusing result. The nightly package contains the latest changes made by the XProf developers, and for a project on a release cadence that lands roughly every six to eight weeks based on the version history, a nightly build is the way to see a fix before the next tagged release.

Google Cloud users get a separate tool for the collection side

There is a third installation path that is not really an installation path. If you use Google Cloud to run your workloads, the documentation recommends the xprofiler tool from the cloud-diagnostics-xprof repository, which provides a streamlined profile collection and viewing experience using virtual machines running XProf. That is a meaningful separation of concerns. XProf is the analysis surface, and xprofiler is the collection and deployment story for a managed environment where the profiling agents run alongside the training job on virtual machines. If you are on Google Cloud, the practical advice is to use xprofiler for the plumbing and XProf for the analysis, rather than hand-assembling a collection setup on your own cluster. The repository also points at the XProf documentation site at openxla.org/xprof for the details of the individual tools, and a Colab demo for people who are new to profiling.

Building from source means Bazel, and macOS needs explicit flags

The source build is for people the pip packages do not work for, and it is a Bazel build with a specific set of steps. Bazelisk is the wrapper that simplifies Bazel version management, and the documented install is the downloaded .deb package.

sudo apt install ~/Downloads/bazelisk-amd64.deb

You clone the repository and build the pip package with Bazel.

git clone https://github.com/openxla/xprof.git
cd xprof

bazel run --config=public_cache plugin:build_pip_package

The output lands in the Bazel output directory, and you install it from there.

cd /tmp/profile-pip
pip install .

The macOS case is the one with a documented failure, and the reason is worth stating precisely. On macOS the native profiler extension must be built explicitly, pinning the SDK and minimum OS version, and building without those flags fails with errors such as an xcrun SDK macosx10.11 that cannot be located and undefined symbols like _PyModule_Create2. The invocation verified on Apple Silicon passes the macos config along with the SDK version read from xcrun and a minimum OS of 13.0.

The repository is a mixed C++ and TypeScript tree with a Bazel spine

The layout tells you what kind of project this is. The top level carries .bazelrc and .bazelversion for the build, a WORKSPACE file and a BUILD file, config.bzl and a defs directory for build configuration, and a patch_keys.py script. The implementation is split across a plugin directory, an xprof directory for the core, a frontend directory for the web UI, a tbp_package directory for the TensorBoard plugin, and labs, demo, docs, skills, tests, third_party and scripts directories. The frontend is TypeScript and Angular, with the package.json listing the Angular toolchain, a prettier lint step over the tensorboard assets and the .github workflow files, and a test run that uses ibazel to re-run tests as files change. There are lock files for Python 3.10 through 3.13, which tells you the supported interpreter range, and a pytest.ini. The C++ is the profiler core, the TypeScript is the interface, and Bazel ties them together.

Where XProf is the wrong choice

The first wrong case is the one the documentation flags itself, a machine that cannot reach the internet. XProf requires internet access to load the Google Chart library, and some charts and tables may be missing if you run it entirely offline on your local machine, behind a corporate firewall, or in a datacenter. That is not a hypothetical constraint for a lot of ML teams, whose profiling machines sit in exactly those places. The second wrong case is a team whose profile data is in a different format, since the logdir loads files ending in .xplane.pb and there is no documented import path from older trace formats. The third is a team that wants a single lightweight binary to drop on a node, because XProf is a web application with a frontend build and, in the TensorBoard case, a plugin that has to match the TensorBoard version. The fourth is a project that has to keep a stable dependency set, since the nightly package is distributed under a different name and requires uninstalling the released one first, so mixing them is easy to get wrong. The fifth is a team that only needs a memory profile of a single device, because the whole design is built around the multi-device distributed case and that machinery is overhead for a small job.

Editorial conclusion

Teams profiling machine learning workloads, especially distributed ones, who want a trace viewer and a graph viewer in one web interface and who can reach the internet from the machine that renders the page are the people XProf is for, and the fact that it ships both a standalone server and a TensorBoard plugin means it fits either habit. It is the wrong choice for a team profiling on an air gapped network or behind a corporate firewall, because the documentation states plainly that XProf requires internet access to load the Google Chart library and that some charts and tables may be missing if you run it entirely offline. Check three things before adopting it: that the profile data you have is in the xplane format, since the logdir option loads files ending in .xplane.pb, that your TensorBoard version still accepts the plugin, since the install instructions pair the two packages and the nightly route explicitly uninstalls both xprof and tensorboard-plugin-profile, and that the machine rendering the UI can reach the chart library. The licence is Apache-2.0, the newest release is XProf v2.23.2 from 2026-09-16, and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. openxla/xprof on GitHub
4. README
5. Releases