Prerequisites
Before proceeding, ensure you have:- AgentScope v1.0.14 or higher
- Linux system
- At least one Nvidia GPU with compute capability 8.0+ (e.g., Nvidia A100, H100, RTX 3090, RTX 4090, RTX 5090, etc.)
- CUDA 12.8 or higher
Refine Workflow Function
Continuing from Overview, assume you have a task dataset and judge function ready. Now, refine your workflow function for model weights tuning:model as a input parameter, and uses it to initialize the agent. The model has the same interface as OpenAIChatModel, but its weights will be tuned during the tuning process.
Configuration & Tuning
After refining the workflow function, you can set up the tuning configuration and start the tuning process.-
DatasetConfig: Specifies the task dataset for tuning.path: The path to the dataset, which can be a local path or a dataset from Hugging Face.split: The split of the dataset to be used for tuning (e.g., “train”, “test”, etc.).name: (Optional) The name of the dataset to be used for tuning. Some Huggingface datasets have multiple subsets, you can specify the subset name to select the specific subset for tuning. If not specified, it will use the default subset.
-
TunerModelConfig: Specifies the model to be tuned.model_path: The path to the model, which can be a local path or a model from Hugging Face.max_model_len: The maximum sequence length the model can handle. Longer lengths will cost more GPU memory.inference_engine_num: The number of inference engines to use for parallel inference. This can help speed up the inference process during tuning. Default is 1.tensor_parallel_size: Use tensor parallelism to split the model across multiple GPUs. Set this value to the number of GPUs you want to use for tensor parallelism. Default is 1 (no tensor parallelism).ulysses_sequence_parallel_size: Use Ulysses sequence parallelism to split the input sequences across multiple GPUs. Set this value to the number of GPUs you want to use for sequence parallelism. Default is 1 (no sequence parallelism).
AlgorithmConfig: Specifies the tuning algorithm and its hyperparameters.algorithm_type: The type of tuning algorithm to use. Currently, we only recommend using"multi_step_grpo"for model weights tuning, which is a variant of GRPO algorithm designed for agentic scenarios.group_size: Each task will be executedgroup_sizetimes to collect multiple responses in GRPO series algorithms. A larger group size can provide more stable reward estimates but will increase the tuning time.batch_size: The number of tasks to be processed in each tuning iteration.learning_rate: The learning rate for updating the model weights during tuning.save_interval_steps: The interval (in number of iterations) at which to save the model checkpoints. Default is 100.
main.py) and run it:
Monitor Tuning Process
Each run creates directory under the current workspace.Get Tuned Model
Checkpoints are saved everysave_interval_steps steps as introduced in AlgorithmConfig. You can find the saved model checkpoints in the corresponding global_step_x directory.
The saved checkpoints are in pytorch format, which is hard to use directly. You can use Trinity-RFT CLI to convert them into Hugging Face format for easier usage:
Advanced Features
This section introduces some advanced features not covered in the above example, which can further improve the tuning performance or provide more insights during the tuning process.LLM-as-a-Judge
In addition to using custom judge functions, you can also leverage powerful LLMs as judges to evaluate the agent’s performance during tuning. This can be particularly useful when designing a custom judge function is challenging. However, the tuning process requires frequent calls to the judge model, which can easily reach the rate limits of public LLM APIs. To address this,tuner provides auxiliary_models to deploy your own judge model in the training cluster.
auxiliary_models are different from the main model being tuned, and they are only used within the workflow function and judge function for inference. Below are the steps to set up and use LLM-as-a-Judge in the tuning process:
1
Add `auxiliary_models` parameter
Modifiy the signature of your workflow function and judge function and add configurations for the auxiliary models.The
auxiliary_models parameter is a dictionary that contains the auxiliary models used in the tuning process.
You can access the model using auxiliary_models[model_name] within your workflow function and judge function.
Auxiliary models also have the same interface as OpenAIChatModel, so you can use them just like others.2
Configure auxiliary models
When calling the
tune function, you can configure the auxiliary models with a dictionary of TunerModelConfig.
And the keys of the dictionary should match the names used in the auxiliary_models parameter of your workflow function and judge function.Runtime Monitoring
During the tuning process, it’s often helpful to monitor the running status of workflow / judge functions in real time. You can use themetrics parameter in the WorkflowOutput and JudgeOutput to log metrics you want to monitor during tuning. These metrics will be automatically logged to TensorBoard for visualization. For example:
logger parameter to your workflow function and judge function:
logger parameter is an instance of Python’s built-in Logger class, but it is pre-configured to print logs to both console and log files in the directory introduced in Monitor Tuning Process.
You can use this logger to log any information you want during the execution of the workflow function and judge function, which can help you better understand the tuning process and debug if necessary.
Because the tuning process will run multiple parallel workers to execute the workflow function and judge function, each worker will have its own log file in the log directory. The log files are named as explorer_runner_{worker_id}.log, where {worker_id} is the ID of the worker. Below is an example structure of the log directory:
Tuning without Local GPU
Model weights tuning usually requires GPUs for training. If you lack local GPUs, you can still perform tuning by leveraging remote training APIs such as TuFT and Tinker. To use these APIs, set the required environment variables before starting the Ray cluster:model_path supported by your remote training API (e.g., TuFT or Tinker), and provide a TinkerConfig with your desired LoRA rank:
Configuration using YAML File
The examples above show how to configure tuning using Python code. Alternatively, you can use a YAML file for configuration, which is often more convenient for managing complex setups. The following YAML configuration corresponds to the previous Python example:config.yaml) and load it in your Python code when calling the tune function: