When should I use @graph over a regular job?

We recommend using

@graph

when you want to define a reusable collection of ops that can be composed into multiple jobs or when you want to encapsulate a subset of a larger workflow. A graph is essentially a way to define a set of ops and their dependencies without immediately binding them to a job execution context. This allows you to reuse the same graph in different jobs with different configurations or resources. On the other hand, a job is a concrete executable that includes not only the ops and their dependencies but also the necessary configurations and resources for execution. You would define a job when you have a specific workflow that you want to run with a particular configuration. Here are some situations where you might prefer to use `@graph`: 1. Reusability: If you have a set of ops that you want to reuse across multiple jobs, defining them in a graph allows you to do so without duplication. 2. Testing: Graphs can be easier to unit test because they represent just the business logic without the execution context. 3. Modularity: If you want to break down a complex workflow into smaller, more manageable pieces, you can define multiple graphs that represent different parts of the workflow and then compose them into a job. 4. Flexibility: When you want to create different jobs that share some common logic but have different configurations or resources, you can define this common logic in a graph and then instantiate it in multiple jobs with different settings. Remember that a graph by itself is not executable; it must be instantiated within a job to run. The documentation provides examples and more details on how to use graphs and jobs effectively.