Skip to content

Remove miles_megatron_plugins/ (moved to radixark/miles)#32

Draft
Shi-Dong wants to merge 1 commit into
miles-mainfrom
miles/move-plugins-to-miles
Draft

Remove miles_megatron_plugins/ (moved to radixark/miles)#32
Shi-Dong wants to merge 1 commit into
miles-mainfrom
miles/move-plugins-to-miles

Conversation

@Shi-Dong
Copy link
Copy Markdown

Summary

  • Delete miles_megatron_plugins/ from miles-main.
  • The package is being moved into radixark/miles as a top-level Python package; see the matching miles PR (linked once opened).

Why

miles_megatron_plugins implements the miles ↔ megatron contracts (true-on-policy backends, matmul / attention / rope replacements, sglang glue). It is conceptually miles' code that Megatron-LM imports back, not Megatron-LM's own code.

Today it lives inside this fork's working tree and is only on sys.path because miles' production setup uses PYTHONPATH=/root/Megatron-LM. That PYTHONPATH hack does not survive packaging miles as a wheel for pip install miles. Moving the package into miles makes it part of miles' regular Python package and removes the dependency on PYTHONPATH for this specific package.

The from miles_megatron_plugins.* import ... statements scattered across Megatron-LM source files (transformer_layer, transformer_block, attention, gpt_model, gpt_layer_specs, distributed_data_parallel, tensor_parallel/layers, tensor_parallel/matmul_tp_inv, models/gpt/{gpt_model, gpt_layer_specs}, extensions/sglang, …) continue to work in production because miles is always installed before megatron.core is imported, and the matching miles PR adds miles_megatron_plugins as a top-level package in miles' setup.py find_packages include list. Python's import system resolves the miles_megatron_plugins name via miles' installed location instead of via a sibling directory in the Megatron-LM checkout.

Test plan

  • Validated end-to-end via the matching miles PR's CI run (which uses a Megatron-LM checkout at this branch's HEAD and verifies import megatron.core.transformer.transformer_layer succeeds).
  • Smoke on H200 devbox after a rebuilt radixark/miles:dev image: python -c "import sys; import miles_megatron_plugins.true_on_policy.contracts; print(miles_megatron_plugins.__file__)" resolves to a path under /root/miles/, not /root/Megatron-LM/.

Merge ordering note

This PR should not merge into miles-main until the matching miles PR is ready. Once that PR's CI is green, this can merge. After that, the miles PR can flip its .gitmodules branch = back from miles/move-plugins-to-miles to miles-main.

The miles_megatron_plugins package is semantically part of miles (it
implements the miles <-> megatron contracts), not part of Megatron-LM.
It is being moved into the radixark/miles repository as a top-level
Python package, so that it is exposed via the miles wheel rather than
via a PYTHONPATH=/root/Megatron-LM hack.

The `from miles_megatron_plugins...` imports inside Megatron-LM source
files (transformer_layer, transformer_block, attention, gpt_model,
gpt_layer_specs, distributed_data_parallel, tensor_parallel/{layers,
matmul_tp_inv}, models/gpt/{gpt_model, gpt_layer_specs}, extensions/
sglang, etc.) continue to work because miles is always installed before
megatron.core is imported in production, and miles now exposes
miles_megatron_plugins as a top-level package via its setup.py
find_packages include.

Coordinated change: the matching radixark/miles PR adds
miles_megatron_plugins/ at the top level of the miles repo and bumps
the third_party/Megatron-LM submodule pointer to this branch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant