Overview
This document describes the schema for a workload Solution. TheSolution provides a concrete, high-performance implementation for a given Definition. Each Solution is a self-contained entry submitted by community members or autonomous agents, encapsulating the source code and all metadata required for building, interfacing, and benchmarking. The Solution will be benchmarked to collect evaluation statistics to be stored in a Trace object.
Tip: Visit FlashInfer Bench Viewer to see formatted code and visualized JSON for existing solutions.
JSON Schema Description
Top-Level Object Structure
sources : Source Code Files
The sources array contains any number of file objects, where each object represents a single source file in the project. The flashinfer-bench benchmarker will reconstruct the project’s directory structure to properly build the binaries/executables.
spec : Build Specification
This object details the build requirements and properties of the source code.
Dependencies Handling
Note: The dependencies field is currently only for semantic purposes and is not enforced.
The support for dependencies is coming soon.
The dependencies field is an array of strings declaring third-party packages needed to build/run the solution. In particular, we’re handling the third-party CUDA libs and Python packages:
-
CUDA/C++: Use version-pinned tokens.
Example:
CUTLASS_3_7→ the builder injects CUTLASS 3.7 headers paths during compilation. -
Python libs: You may list package specifiers, but we do not manage Python package installs currently. We only validate against the current environment. If a listed lib/version isn’t satisfied, the build fails fast with a validation error.
Example:
torch,triton >= 2.3→ the builder validates the current environment for these packages and versions.
Destination Passing Style (DPS)
Thedestination_passing_style field controls how outputs are handled:
Example comparison:
- DPS (
true): Preferred for performance-critical code. Avoids output allocation overhead. - Value-returning (
false): Simpler to write and doesn’t need to manually allocate outputs.
Language-Specific Guidelines
Python / Triton
Forpython and triton languages, the entry point is a Python function.
Signature requirements:
- Parameter names must exactly match the keys in
Definition.inputs(andDefinition.outputsfor DPS). - The function is called with positional arguments.
*args: Useful for flexible number of parameters. It requires (required params ≤ expected).**kwargs: Ignored in signature validation.
C++ / CUDA
Forcpp and cuda languages, the source code must be compiled. Use the binding field to specify how to interface with Python:
Entry point: The
entry_point should reference a C/C++ function symbol that will be exposed to Python.
Example spec for CUDA:

