fix: fix the deprecated usage of tuple slicing, wandb's start_method, and transformers's dtype

[rchardx]

This pull request updates several model-loading and tensor manipulation functions across the codebase to improve consistency and correctness. The main change is standardizing the use of the dtype argument instead of torch_dtype when loading models, which aligns with recent library updates and prevents potential type mismatches. Additionally, tensor slicing operations are made more robust by ensuring slices are always passed as tuples.

Model loading and initialization updates

• Replaced the torch_dtype argument with dtype in all calls to HuggingFace model loading functions (from_pretrained and from_config) in areal/engine/base_hf_engine.py, evaluation/model_utils.py, and examples/docs/debug/cmp_rollout.py, ensuring compatibility with the latest library conventions. [1] [2] [3] [4]
• ⚠️⚠️ Use dtype instead of torch_dtype everywhere! huggingface/transformers#39782

Tensor slicing improvements

• Updated tensor slicing in areal/utils/ulysses.py to always pass slices as tuples, preventing indexing errors and improving code clarity. [1] [2]
• pytorch/pytorch@a6401cb

Logging configuration

• Removed the explicit wandb.Settings(start_method="fork") argument in the init function of areal/utils/stats_logger.py, simplifying the logging configuration.
• chore: add deprecation message for the start_method setting wandb/wandb#9837

[Copilot]

Pull Request Overview

This pull request addresses deprecated API usage and improves tensor slicing robustness. The changes replace the deprecated torch_dtype parameter with dtype in HuggingFace model loading functions, update tensor slicing to use explicit tuples for improved clarity and correctness, and remove an explicit wandb.Settings configuration that is no longer necessary.

Key changes:

• Standardized all HuggingFace model loading calls to use dtype instead of torch_dtype
• Updated tensor slicing operations in Ulysses parallel processing utilities to use tuple indexing
• Simplified wandb initialization by removing explicit start_method="fork" setting

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
examples/docs/debug/cmp_rollout.py	Updated model loading to use dtype parameter
evaluation/model_utils.py	Changed AutoModelForCausalLM loading to use dtype parameter
areal/utils/ulysses.py	Converted list-based tensor slicing to tuple-based indexing
areal/utils/stats_logger.py	Removed explicit wandb start_method configuration
areal/engine/base_hf_engine.py	Migrated all model loading functions from torch_dtype to dtype

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[gemini-code-assist]

Summary of Changes

Hello @rchardx, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on enhancing the robustness and consistency of model loading and tensor manipulation within the codebase. It addresses potential issues arising from deprecated argument usage in HuggingFace Transformers and improves tensor indexing practices. Additionally, it streamlines the Weights & Biases logging configuration, contributing to a cleaner and more up-to-date system architecture.

Highlights

• Model Loading Consistency: Standardized the use of the dtype argument instead of torch_dtype in HuggingFace model loading functions (from_pretrained and from_config) across various files, aligning with recent library updates and preventing type mismatches.
• Tensor Slicing Robustness: Improved tensor slicing operations by ensuring slices are consistently passed as tuples, which prevents potential indexing errors and enhances code clarity.
• Logging Configuration Simplification: Removed the explicit wandb.Settings(start_method="fork") argument from the wandb.init function, simplifying the Weights & Biases logging setup.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly addresses several deprecated API usages, replacing torch_dtype with dtype and fixing tensor slicing to use tuples. These are valuable maintenance improvements. I've included a couple of suggestions to further enhance code quality. One is a refactoring to reduce code duplication in areal/engine/base_hf_engine.py, and another is to use explicit keyword arguments for better readability in examples/docs/debug/cmp_rollout.py. Overall, the changes are solid.

[garrett4wade]

LGTM!