DeepInfer/pyproject.toml
loopyt b4f7a42652 test(h20): compare two hosts' Triton builds, not just two backends on one host
`h20_ops_ab.py` assumed the TileLang backend is importable, so on a vendor image it could
not start at all -- which is exactly where the Triton backend needs checking. Two modes fix
that:

* `--dump DIR` saves the selected backend's output per case.
* `--compare DIR` checks against dumps written elsewhere.

Together they answer "do triton 3.5.1 and 3.7.1 agree" without either host having TileLang.
Case builders that genuinely need a package the host lacks now report a skip instead of
aborting the run, so partial coverage is visible rather than fatal; the import of the
sampler's C++-backed inputs moved into the one builder that uses it for the same reason.

This is what showed the 19 ported kernels produce element-wise identical output across
triton 3.5.1, 3.6.0 and 3.7.1 -- 115 cases, no differences.
2026-10-22 10:53:36 +08:00

92 lines
2.8 KiB
TOML

[build-system]
requires = [
"ninja",
"setuptools >= 77.0.3",
"torch >= 2.7",
]
build-backend = "setuptools.build_meta"
[project]
name = "deepinfer"
version = "0.1.0"
description = "DeepInfer: High-performance, large-scale inference framework for DeepSeek models"
readme = "README.md"
license = "Apache-2.0"
license-files = ["LICENSE"]
requires-python = ">=3.12"
authors = [{ name = "DeepSeek-AI" }]
keywords = ["llm", "inference", "deepseek", "cuda", "ascend"]
classifiers = [
"Development Status :: 4 - Beta",
"Intended Audience :: Developers",
"Programming Language :: Python :: 3.12",
"Topic :: Scientific/Engineering :: Artificial Intelligence",
]
dynamic = ["dependencies"]
urls = { Repository = "https://github.com/deepseek-ai/deepinfer", Issues = "https://github.com/deepseek-ai/deepinfer/issues" }
[tool.pytest.ini_options]
# Use importlib import mode so that collecting test files inside the deepinfer
# package (e.g. deepinfer/model_executor/layers/tilelang_ops/*.py) does NOT
# trigger the package __init__.py chain (which imports heavy deps like
# deep_gemm).
addopts = ["--import-mode=importlib"]
testpaths = ["tests"]
markers = [
"ci: core tests that run on every CI pipeline",
"ci_npu: core tests that run on the NPU/Ascend CI pipeline",
"benchmark: performance tests selected by benchmark jobs",
"long_context: long-input/output decode PPL regression",
"gpu: unit tests requiring a working GPU",
]
[tool.ruff.lint]
select = [
# pycodestyle
"E",
# Pyflakes
"F",
# pyupgrade
"UP",
# flake8-bugbear
"B",
# flake8-simplify
"SIM",
# isort
"I",
# type hint
"ANN",
# disallow specific packages
"TID251",
]
ignore = [
# missing return type for private function; dynamically typed Any
"ANN202", "ANN401",
# star imports
"F405", "F403",
# lambda expression assignment
"E731",
# f-string without any placeholders
"F541",
# line too long, handled by black formatting
"E501",
# module level import not at top of file
"E402",
# function definition does not bind loop variable
"B023",
]
[tool.ruff.lint.per-file-ignores]
# Triton kernel bodies: parameters are pointers and scalars that Triton itself types, and the
# kernels are launched through `kernel[grid](...)` rather than called directly, so the usual
# signature annotations would be either wrong or rejected by the JIT.
"deepinfer/model_executor/layers/tilelang_ops/triton/*.py" = ["ANN001", "ANN201", "ANN202"]
# Same reason, for the environment probe: its kernels exist to be compiled by whatever Triton the
# image ships, and annotating their pointers would change what the JIT sees.
"scripts/flagtree_triton_probe.py" = ["ANN001", "ANN201", "ANN202"]
[tool.ruff]
line-length = 140
include = ["./**/*.py"]
extend-exclude = ["vendor"]