Working with Graph Breaks

Created On: Jul 28, 2025 | Last Updated On: Sep 12, 2025

As you might remember from Dynamo Core Concepts that Dynamo performs a graph break when it encounters code that can’t be traced. In the default torch.compile settings, Dynamo compiles the FX graph that has been determined up to that point, executes the unsupported code in regular Python, and then resumes tracing.

Graph breaks enable Dynamo to trace through arbitrary Python code and carve out functional subgraphs that can each be individually optimized.

However, graph breaks may cause unexpected slowness in torch.compile. If you’re not seeing the expected speedups, we recommend checking for graph breaks and removing them.

The following sections outline strategies for addressing graph breaks.

• Use fullgraph=True to Identify and Eliminate Graph Breaks
  • Strategy 1: Rewrite the unsupported code to use features supported by Dynamo
  • Strategy 2: Pure functions can always be compiled via an escape hatch.
  • Strategy 3: Don’t compile the code
• Common Graph Breaks
  • Incorrect Code
  • Data-dependent operations
  • Printing and logging
• Use torch._dynamo.nonstrict_trace
• Custom Operators
• Working with fullgraph=False
  • Where to apply torch.compile?
    • compile(model) vs model.compile()
  • Disabling and Suppressing Errors
  • Toggling error_on_graph_break
    • error_on_graph_break(False) example
    • error_on_graph_break(True) example
    • error_on_graph_break nesting behavior
    • Interaction with fullgraph
    • Summary of fullgraph=True/False vs error_on_graph_break
  • Nested Graph Breaks
  • Skipped Functions
    • Graph Break in a Loop
    • Graph Break in a Context Manager
    • Graph Break in a Try Block
    • Hitting a Recompilation Limit
    • Compiler Errors
    • Dealing with Skipped Functions