Skip to main content

Overview

This document describes the schema for a workload Solution. The Solution 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)

The destination_passing_style field controls how outputs are handled: Example comparison:
When to use which:
  • 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

For python and triton languages, the entry point is a Python function. Signature requirements:
  • Parameter names must exactly match the keys in Definition.inputs (and Definition.outputs for DPS).
  • The function is called with positional arguments.
Parameter handling:
  • *args: Useful for flexible number of parameters. It requires (required params ≤ expected).
  • **kwargs: Ignored in signature validation.
Example (Triton with value-returning):

C++ / CUDA

For cpp 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:

Examples

Example: Triton Implementation for GEMM

Example: Triton Implementation for RMS Norm