# Accel-Sim replays real NVIDIA traces on a cycle level model > Accel-Sim is a validated GPU simulation framework that traces real SASS execution from NVIDIA hardware with NVBit and replays it on GPGPU-Sim 4.x, with the 2.0 release adding full Hopper support including TMA, WGMMA and threadblock clusters, plus a separate power model. It is a research tool for reasoning about GPU behaviour, not a performance predictor for shipping code. **accel-sim/accel-sim-framework** — This is the top-level repository for the Accel-Sim framework. - Repository: https://github.com/accel-sim/accel-sim-framework - Website: https://accel-sim.github.io - Stars: 716 · Forks: 250 - Language: HTML - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/accel-sim-accel-sim-framework ## What the framework actually does Accel-Sim is an extensible, validated framework for cycle-level GPU simulation. The mechanism is a trace and replay loop. It traces real SASS execution from NVIDIA hardware with NVBit and replays it on a detailed performance model, which is GPGPU-Sim 4.x, together with the AccelWattch power model. That distinction is what separates Accel-Sim from a profiler. A profiler tells you what happened on the silicon you happened to own. Accel-Sim gives you a model you can interrogate about counters the hardware does not expose, replay a trace through a modified model, or use to reason about an architecture you cannot access. The GPGPU-Sim lineage goes back to the ISPASS 2009 paper, and the Accel-Sim framework itself to ISCA 2020, so the model underneath is well established. The homepage is accel-sim.github.io, the default branch is dev, and the licence is recorded as a custom one that GitHub cannot classify, so the LICENSE file at the root is the authoritative statement. The repository has a .devcontainer directory, a .pre-commit-config.yaml, a GPU simulator directory at gpu-simulator/, a util/ directory, a get-accel-sim-traces.py script, a short-tests.sh script, and a separate mlperf.md document, so MLPerf work is a recognised part of the project rather than an afterthought. ## What version 2.0 added for Hopper The 2.0 release is the reason to look at this project now, because the hardware generation it targets is the one people actually have. Accel-Sim 2.0 adds full NVIDIA Hopper support, covering H100 and H200. The specific features named are the Tensor Memory Accelerator, asynchronous Warp Group MMA, mbarrier producer and consumer synchronization, threadblock clusters, and a chiplet or uGPU partitioned memory subsystem. The tracer was rebuilt as well, with compressed traces and PyTorch per-layer hooks, and GPUVision was added for cycle-level hardware correlation. The list of GPU features matters more than it looks, because each one corresponds to a piece of Hopper's programming model that an older simulator simply could not represent. A simulator that lacks threadblock cluster support cannot model the launch and scheduling behaviour of a cluster launch, so any kernel using it produces numbers that are not merely imprecise but structurally wrong. Adding TMA and WGMMA means the common paths of contemporary LLM kernels can be simulated at all. The release history shows v2.0.0 on 2026-08-25, v1.3.0 on 2025-02-12 and v1.2.0 on 2021-10-20. The last push was on 2026-10-21, and the project is not archived, so this is live work. The roadmap names the next step explicitly, with experimental Blackwell support covering B200 and RTX 5090, and multi-GPU with NVLink support, described as incoming shortly. For an evaluator, that is a signal about where the model's coverage stops today. ## The validation claim and the LLM tracing path The README makes two claims that need to be read carefully, because they are the basis of any decision to use the tool. The first is accuracy. It says Accel-Sim 2.0 is validated across 34,000+ kernel instances from 22 benchmark suites, achieves a 99% Pearson correlation and just 13.4% mean absolute cycle error against real NVIDIA H100 silicon, and that the accompanying chart compares simulated and real H100 across those kernels for GPC cycles, warp instructions, and L1/L2 accesses and misses, with each panel showing the Pearson correlation and mean absolute percentage error for that metric. The framing to note is per metric. A correlation figure for GPC cycles and a separate one for L1 and L2 misses are different claims, and a tool can be highly correlated on one counter and much less so on another. The README says the 2.0 paper and Table 1 in release.notes.md carry the full changelog and the detail. The second claim is scope. The README states that Accel-Sim 2.0 fully supports vLLM inference and PyTorch training, so you can take a model from Hugging Face, trace inference or a full training step including forward, backward and optimizer, with a few lines of Python, and run it on a cycle-level model of an H100, with no hand-written kernels and no unsupported-op workarounds, and that modern async Hopper kernels such as FlashAttention-3, cuBLAS/CUTLASS and NCCL run out of the box. That is a meaningful narrowing of the classic complaint about simulators, that a real kernel uses an operator the model does not implement. The per-layer PyTorch hooks in the rebuilt tracer are what make a full training step traceable, since the trace is captured per layer rather than only at the kernel launch boundary. ## The four components and what each one contributes The README organises the framework into four components, and the division tells you how the work is done. The tracer is the capture side, and it runs on real NVIDIA hardware. In version 2.0 it was rebuilt with compressed traces, stored as .tracez files, and PyTorch per-layer hooks, and there is a separate traceDsm tool mentioned alongside the compressed trace format. The repository ships get-accel-sim-traces.py at the root, which is the entry point for getting traces. The SASS frontend and simulation engine is the replay side, GPGPU-Sim 4.x, which interprets the recorded SASS instructions cycle by cycle and produces the counter data. This is where the fidelity lives, and it is also the part that has to be taught about every new hardware feature, which is why the Hopper list in the 2.0 notes is so long. The correlator is the validation component. It compares the simulated output against hardware measurements, and that comparison is what produces the correlation and error numbers quoted for the release. The component exists because a simulator with no feedback loop into hardware is a model of an imagined machine, and the correlation figures in the README are the output of this component against 22 benchmark suites. The tuner is the optimisation component, and the README describes parallel tracing and simulation as a 2.0 feature guide alongside the compressed traces and the GPUVision work. GPUVision is separately described as cycle-level CUPTI profiling, so the framework can pull counters from the real device with the same kind of measurement it compares the model against. That last piece is worth separating out. Cycle-level CUPTI profiling on the hardware gives ground truth at the same granularity as the simulator, which is what makes a per-counter correlation meaningful rather than a comparison of two different quantities. ## Getting it running: the container is the sane route The dependencies section is short, and the practical advice is to use the container rather than building locally. The package runs on a modern Linux distro, and a prebuilt Docker image is available, built on nvidia/cuda:12.8.0-cudnn-devel-ubuntu24.04, with its Dockerfile in the separate accel-sim/Dockerfile repository. The README gives a local build example for Ubuntu 24.04 with CUDA 12.8. The Python side is a short requirements list: ```text pyyaml pandas plotly kaleido psutil tqdm ``` Those are the analysis and plotting dependencies rather than the simulation itself. pandas and plotly with kaleido handle the counter data and the charts, psutil is for process and resource inspection during a long simulation, and tqdm is the progress bar you will stare at while a cycle level replay runs. pyyaml is for the configuration and trace metadata. For a first run, the practical sequence is to pull the prebuilt image, copy the repository into it or mount it, install the requirements, and trace a kernel on a machine with the target hardware before replaying it. The CI workflow badge in the README points at the main.yml workflow with branch dev and event push, so the dev branch is what the CI runs against, and the Codespaces badge offers a hosted environment if you do not have a suitable local machine. The repository also ships short-tests.sh at the root, which is the quickest way to confirm the installation works before committing to a long simulation run. ## The power model and the citation requirements The power modelling side is a separate framework layered on top, and the README is careful to keep the two apart. AccelWattch is a power modeling framework for modern GPUs, introduced at MICRO 2021, and it works alongside the GPUWattch work from ISCA 2013. There is a separate AccelWattch.md document in the repository root for it, described as the AccelWattch MICRO'21 Artifact Manual. The topics list includes GPUWattch and AccelWattch as distinct entries, so they are separate pieces of work that happen to share a lineage. The citation rules are the part with teeth. The README says to cite Accel-Sim cumulatively: if you use anything in the repo, cite the base papers, and add the power papers on top only if you use AccelWattch or GPUWattch. The base set is Accel-Sim 2.0 from 2026, Accel-Sim 1.0 from ISCA 2020, and GPGPU-Sim from ISPASS 2009, and the README states that this is required for any use of Accel-Sim, covering the tracer, the trace-driven frontend, the tuner, the correlator and the Hopper model. So a paper that uses only the correlator still has to cite the 2009 GPGPU-Sim paper, because the model underneath is that work. And the power papers are additive rather than alternative. The repository ships the metadata so you do not have to assemble it by hand. There is a CITATION.bib with every entry, described as copy-pasteable, and a CITATION.cff, the machine-readable version, which drives the GitHub Cite this repository button. The README notes that the button exports only the Accel-Sim 2.0 entry, so for the full cumulative set you need the bib file, and that the Accel-Sim 2.0 paper is on arXiv. ## Where Accel-Sim fits, and where it stops The realistic comparison is with profilers and with other simulators, and the honest answer is that Accel-Sim is a different category of tool. Against a hardware profiler, the difference is that the profiler needs the hardware and Accel-Sim needs a trace. A profiler on an H100 gives you real counters for a kernel you can run there. Accel-Sim gives you counters for a kernel you have run somewhere, and it gives you the ability to ask questions the hardware cannot answer, because you own the model. The cost is a long simulation time and the discipline of tracing correctly. Against a different simulator, the difference is the validation and the trace-driven design. A model that runs your own synthetic kernel tells you about the model. Accel-Sim replays what the hardware actually did, which is what makes the correlation numbers meaningful, and the correlator component plus the 22 benchmark suites are how that claim is checked. The limits are clear from the README. The roadmap places Blackwell and multi-GPU NVLink support in the future, so today the coverage is Hopper. The 2.0 paper and release.notes.md are where the detailed validation lives, so a reader who wants to interrogate the 99% correlation figure has to go to those. The framework is validated against NVIDIA hardware, which means the trace source is NVIDIA SASS and the model is a CUDA machine, not a general GPU architecture. For LLM work specifically, the vLLM and PyTorch path removes a real barrier, since tracing a real model is the only way the model meets a real workload. But a cycle level simulation of a traced model is still not an application level performance estimate, and the README does not claim it is. Treating it as one is the most common way to misuse a tool like this. ## Conclusion Accel-Sim suits a GPU architecture researcher or a performance engineer who needs cycle level counters for a kernel rather than wall clock timings, since the framework replays a real hardware trace on a detailed model and reports correlation against silicon. It is the wrong tool if you want to predict how fast your application will run on a machine you do not have, because a cycle level simulation of a traced kernel is a different exercise from profiling a workload end to end. Before adopting it, read release.notes.md for the 2.0 changes, install the prebuilt Docker image rather than building locally, and confirm the CUDA version on the target host matches the 12.8 base the image is built on. ## FAQ ### What does Accel-Sim simulate and how? It traces real SASS execution from NVIDIA hardware with NVBit and replays it on a detailed performance model, GPGPU-Sim 4.x, together with the AccelWattch power model. The result is cycle-level simulation of a kernel that actually ran, rather than a synthetic workload. ### What does Accel-Sim 2.0 add for NVIDIA Hopper? Full H100 and H200 support, with the Tensor Memory Accelerator, asynchronous Warp Group MMA, mbarrier producer and consumer synchronization, threadblock clusters, a chiplet and uGPU partitioned memory subsystem, a rebuilt tracer with compressed traces and PyTorch per-layer hooks, and GPUVision for cycle-level hardware correlation. The release is v2.0.0, dated 2026-08-25. ### How do I install Accel-Sim? A prebuilt Docker image is available, built on nvidia/cuda:12.8.0-cudnn-devel-ubuntu24.04, with its Dockerfile in the separate accel-sim/Dockerfile repository. Building locally needs a modern Linux distro with CUDA 12.8, and the Python dependencies listed in requirements.txt: pyyaml, pandas, plotly, kaleido, psutil and tqdm. ### Can Accel-Sim trace LLM inference and training? Yes. The README states that Accel-Sim 2.0 fully supports vLLM inference and PyTorch training, so you can trace a full training step including forward, backward and optimizer with a few lines of Python and run it on a cycle-level model of an H100, with modern async Hopper kernels such as FlashAttention-3, cuBLAS/CUTLASS and NCCL running out of the box. ### What papers do I have to cite if I use Accel-Sim? The base set, cumulatively: the Accel-Sim 2.0 paper from 2026, the Accel-Sim paper from ISCA 2020, and the GPGPU-Sim paper from ISPASS 2009. The AccelWattch MICRO 2021 and GPUWattch ISCA 2013 papers are added on top only if you use AccelWattch or GPUWattch. CITATION.bib and CITATION.cff ship with the repository. ## Sources - [accel-sim/accel-sim-framework on GitHub](https://github.com/accel-sim/accel-sim-framework) - [Issues](https://github.com/accel-sim/accel-sim-framework/issues) - [Project website](https://accel-sim.github.io) - [README](https://github.com/accel-sim/accel-sim-framework/blob/dev/README.md) - [Releases](https://github.com/accel-sim/accel-sim-framework/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/accel-sim-accel-sim-framework