mirror of
https://github.com/deepseek-ai/DeepInfer.git
synced 2026-11-01 09:16: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. |
||
|---|---|---|
| .. | ||
| _C | ||
| distributed | ||
| engine | ||
| entrypoints | ||
| h20_ops | ||
| hugging_face | ||
| model_executor | ||
| npu_ops | ||
| structure_output | ||
| tk_compat | ||
| ve | ||
| worker | ||
| __init__.py | ||
| attrdict.py | ||
| config.py | ||
| debug_dump.py | ||
| environ.py | ||
| load_class.py | ||
| logger.py | ||
| model_config_loader.py | ||
| multimodal_tokens.py | ||
| platform.py | ||
| py.typed | ||
| sampling_params.py | ||
| sequence.py | ||
| shared_memory.py | ||
| testing.py | ||
| timer.py | ||
| utils.py | ||