[Raiden Weight Sync 7/7] Clean up rollout path and remove redundant weight sync logic

[YixuanWang-99]

Overview

Part of the stacked Raiden weight-sync enablement PR chain replacing #5089.

Stack:

• [M7] [Raiden Weight Sync 1/7] Add cross-repo drift guard and FFI resolution tests #5166: Cross-repo drift guard
• [M1] [Raiden Weight Sync 2/7] Support inhomogeneous layer cycle interval in raiden_unscan #5167: Inhomogeneous layer cycle support in raiden_unscan
• [M2] [Raiden Weight Sync 3/7] MoE 128-lane layout and padding for TPU GMM kernels #5168: MoE 128-lane layout and padding (pairs with Tunix T5)
• [M3] [Raiden Weight Sync 4/7] Target-free and streaming weight conversion for vLLM #5169: Target-free streaming weight conversion
• [M5] [Raiden Weight Sync 5/7] Pass weight_dtype in Qwen3NextSparseMoeBlock shared expert gate #5170: Shared expert gate weight_dtype fix
• [M4] [Raiden Weight Sync 6/7] Integrate Raiden weight sync in MaxTextTrainingEngine with FFI support #5171: TrainingEngine Raiden FFI integration (pairs with Tunix T2a)
• [M6] AI-Hypercomputer/maxtext (this PR): Rollout cleanup

Details

• Net −354 lines.
• Removes deprecated and redundant rollout and weight sync duplication in maxtext_vllm_rollout.py and train_rl.py, now that the logic is cleanly owned by M3/M4.

Checklist

Before submitting this PR, please make sure (put X in square brackets):

• I have performed a self-review of my code. For an optional AI review, add the gemini-review label.
• I have necessary comments in my code, particularly in hard-to-understand areas.
• I have run end-to-end tests tests and provided workload links above if applicable.
• I have made or will make corresponding changes to the doc if needed, including adding new documentation pages to the relevant Table of Contents (toctree directive) as explained in our documentation.

[gemini-code-assist]

Code Review

This pull request simplifies the weight synchronization and rollout logic for vLLM integration by removing unused standalone converters, Qwen scanned weight unrolling, and local compatibility patches. Feedback on the changes highlights two critical issues: first, replacing the standard logging module with absl.logging will cause an AttributeError when calling logging.getLogger() in _log_and_flush_traceback; second, the fallback logic to determine if a model is Gemma relies on config.model_config, which is not present on VllmConfig and should instead use config.engine_kwargs.

[gemini-code-assist]

If model_name is not provided or is empty, the fallback logic tries to retrieve model_config from config. However, VllmConfig does not have a model_config attribute, meaning self._model_name will remain empty and self._is_gemma will incorrectly evaluate to False for Gemma models. Falling back to config.engine_kwargs.get("model") provides a robust way to retrieve the model name/path.

Suggested change

	if not self._model_name:
	model_config = getattr(config, "model_config", None)
	self._model_name = getattr(model_config, "model", "") or ""
	architectures = getattr(model_config, "architectures", []) or []
	hf_config = getattr(model_config, "hf_config", None)
	model_type = getattr(hf_config, "model_type", "") or ""
	arch_str = " ".join(str(a) for a in architectures)
	self._is_gemma = (
	"gemma" in str(self._model_name).lower()
	or "gemma" in str(model_type).lower()
	or "gemma" in str(arch_str).lower()
	)
	else:
	self._is_gemma = "gemma" in str(self._model_name).lower()
	if not self._model_name:
	engine_kwargs = getattr(config, "engine_kwargs", {}) or {}
	self._model_name = engine_kwargs.get("model", "") or ""
	model_config = getattr(config, "model_config", None)
	architectures = getattr(model_config, "architectures", []) or []
	hf_config = getattr(model_config, "hf_config", None)
	model_type = getattr(hf_config, "model_type", "") or ""
	arch_str = " ".join(str(a) for a in architectures)
	self._is_gemma = (
	"gemma" in str(self._model_name).lower()
	or "gemma" in str(model_type).lower()
	or "gemma" in str(arch_str).lower()
	)
	else:
	self._is_gemma = "gemma" in str(self._model_name).lower()

[SurbhiJainUSC]

Can this logic be simplified?