mirror of
https://github.com/deepseek-ai/DeepInfer.git
synced 2026-11-03 02:06:20 +08:00
Two files claimed that importing `flag_gems` registers ATen implementations process-wide, and used that to justify vendoring. The conclusion was right for the wrong reason, and the reason was wrong enough to distort planning: it made any broader FlagGems integration look reckless. Measured instead of assumed. Hashing `torch._C._dispatch_dump_table` for `aten::rms_norm`, `aten::silu`, `aten::softmax`, `aten::topk`, `aten::lerp` before and after `import flag_gems`: every table unchanged. The package `__init__` creates the `aten_lib` handle and imports the op modules; registration happens only when `enable()` or `only_enable(include=[...])` is called. And `only_enable(include=["rms_norm"])` changes exactly `aten::rms_norm` and nothing else. So the blast radius lives in `enable()`, not in the import -- which is what makes a wider integration tractable rather than risky. Vendoring still stands, for two reasons that survive the correction: the package root star-imports every op module and loads Triton TLE, which dlopen's `libflagcx` (a native dependency this deployment does not otherwise need); and the released kernel file has no internal imports, so the package bought nothing for that operator. Both files now say this, and say that it is a correction, so the next reader does not rediscover it. |
||
|---|---|---|
| .. | ||
| vendor | ||
| __init__.py | ||
| attn_sm90.py | ||
| deep_select_sm90.py | ||
| engram_local.py | ||
| quant.py | ||
| sparse_mla_sm90.py | ||
| sparse_mla_triton.py | ||
| sparse_mla.py | ||
| vit_attn.py | ||