mirror of
https://github.com/deepseek-ai/DeepInfer.git
synced 2026-10-31 08:46:21 +08:00
The point of the Triton backend is to run where TileLang cannot, but importing `deepinfer` pulled the whole TileLang stack in regardless. Three separate leaks: 1. `ops.py` imported the platform default backend even when another one was selected, purely to have fallbacks available. That default is TileLang, so it dragged in `tile_kernels`. `DEEPINFER_OPS_STRICT=1` now skips it: no default import, no fallback, a missing kernel raises. That is the right trade when the default is not installed, or when a silent fallback would hide an incomplete port. 2. `tile_kernels` sat at module scope in `norm`, `cache_common`, `fused_transform` and `load_paged_kv_cache`, but only the reference implementations and the unit tests use it. The kernels never do. It now lives inside those functions. 3. `tilelang` itself: `compress` set a TileLang pass flag, and `norm` needed a TileLang dtype handle to pass along a parameter the Triton factory discards. Both now degrade to a no-op or a plain string when TileLang is absent. Verified on a FlagTree image (torch 2.11, triton 3.6, no TileLang): `import` succeeds, 19 kernels build and run, and the outputs are element-wise identical to the same kernels built by triton 3.5.1 and 3.7.1. Full A/B on the reference image is still green, so nothing changed for the paths that do have TileLang. |
||
|---|---|---|
| .. | ||
| eplb | ||
| input_metadata | ||
| layers | ||
| models | ||
| parallel_utils | ||
| __init__.py | ||
| layer_utils.py | ||
| model_loader.py | ||
| model_metadata_utils.py | ||
| model_output.py | ||
| sampling_inputs.py | ||
| utils.py | ||