Skip to main content
Qwen model tuning

Fine-tuning data upload rules

Describes the format specifications, packaging requirements, size and quantity limits, and API upload quotas for text generation model fine-tuning data, helping users construct and upload compliant SFT/DPO/CPT training data by training method.

Overview

This document describes the format specifications, packaging requirements, size and quantity limits, and API upload quotas for text generation model fine-tuning data. The scope covers text generation model fine-tuning (text/image/video → text), including plain-text SFT/DPO/CPT, Qwen VL image and video understanding, video frame extraction, function calling, and thinking. Video generation model fine-tuning (image → video) is out of scope. The dataset type (training set or evaluation set) cannot be changed after creation. The support for each training method and element is detailed in Training method and element support matrix. Format construction rules for each combination are described in the corresponding chapters below.
Publish and delete operations are irreversible: published versions cannot be edited again, and only draft versions can be deleted or edited online; the dataset type cannot be changed after creation. Switching the type, scenario, or training method clears uploaded files.
Management operations (creation parameters, version management, evaluation set management rules, import method selection, data cleansing, security and compliance) are covered in sibling documents; see Training set and evaluation set, Introduction to model fine-tuning, etc. We recommend downloading the data template for the corresponding scenario on the dataset creation page and preparing data according to the template structure to avoid import failures. For dataset construction recommendations (recommended data scale, diversity and balance, data augmentation strategies), see Model fine-tuning introduction - Dataset construction tips.

Training method and element support matrix

The training set supports three training methods: SFT, DPO, and CPT. The support status of each training method and element is shown in the matrix table below. The recommended fine-tuning order is CPT (optional) → SFT → DPO (optional); the three are progressive, not mutually exclusive. Region availability:
  • SFT, local upload, log backflow, API upload, and multimodal data formats are supported in all regions.
  • DPO, CPT, OSS import, and cloud storage mount are only supported in the Beijing region.
The support matrix for training methods and elements is as follows:

Training method

Text generation

Visual understanding - Image input

Visual understanding - Video input (qwen3.5+)

Visual understanding - Tool calling (qwen3.5+)

Deep thinking

SFT

DPO

CPT

Evaluation set

Each training method in the matrix table is linked to its corresponding detailed explanation section; for field definitions, see the next section. For the field definitions of the training methods SFT/DPO/CPT, see Introduction to model fine-tuning.

Text generation - SFT format

SFT text generation training data uses the jsonl file format, based on the ChatML messages multi-turn structure.
  • Supports three roles: system, user, and assistant. The content field is a string (for the content array structure in multimodal scenarios, see the corresponding multimodal format chapter).
  • Maximum single file size is 200 MB.
  • A dataset can mix rows of different formats — each record independently selects a format, no need to unify into a single format.
  • Available formats: standard ChatML, thinking, function calling, and function calling combined with thinking (see the sample tabbed pages below).
SFT text generation supports the following sample formats. The complete JSON structure of each sample is shown on the corresponding tab:
  • Standard ChatML
  • Thinking
  • Function calling
Standard ChatML format sample (system/user/assistant multi-turn dialogue):
{
  "messages": [
    {"role": "system", "content": "System input 1"},
    {"role": "user", "content": "User input 1"},
    {"role": "assistant", "content": "Expected model output 1"},
    {"role": "user", "content": "User input 2"},
    {"role": "assistant", "content": "Expected model output 2"}
  ]
}
Some models support the loss_weight parameter, with a value range of (0.0, 1.0]; the larger the value, the higher the training importance.
Supported by Qwen3.5+ by default; for other models, contact your account manager if support is needed.
{"role": "assistant", "content": "Expected model output", "loss_weight": "1.0"}

Thinking tag rules

Thinking content is wrapped in <think>\n…\n</think>\n\n tags, placed inside the assistant output text (sharing the same last assistant content as the final reply). Rules:
  • It can only be placed in the last assistant output; intermediate assistant outputs must not include thinking tags.
  • The line breaks before and after the thinking tag must be preserved.
  • If a training sample is configured so that the model does not output thinking tags, it is not recommended to re-enable the thinking mode when calling the model after training.

Evaluation set format

The evaluation set only serves text generation scenarios and is independent of the SFT/DPO/CPT training method — models trained with DPO/CPT also use the text generation evaluation set for evaluation, with no distinction made by training method. Evaluation set specifications:
  • File format is xlsx; the column structure can be found in the template downloaded from the console.
  • Ingestion methods: local upload and log replay; Object Storage Service (OSS) import and cloud storage mounting are not supported.
  • Only draft versions support online editing (Prompt/Completion); published versions cannot be edited.
Local upload format description:
{"prompt": "Who painted the human body during the Renaissance?", "completion": "The Renaissance was a revival movement of art, culture, and scholarship, during which many artists painted the human body."}
{"prompt": "Why does the Sun emit light and heat?", "completion": "The Sun generates tremendous energy from the fusion of hydrogen nuclei under high temperature and pressure. This fusion reaction releases large amounts of light and heat."}
{"prompt": "Why is the sky blue?", "completion": "When sunlight reaches the Earth's atmosphere, the shorter-wavelength blue light is scattered by gas molecules in the atmosphere, forming the blue sky we see."}
Log replay ingestion limits:
  • Supported log range is within the last 30 days.
  • Maximum of 100,000 records per import.
  • You must authorize the service-linked role and specify the API Key and model filter conditions.
  • The training set is only available for SFT text generation scenarios (the text generation evaluation set is also supported).
For details on the log replay ingestion method, seeLog backflow. The evaluation set should be an independent collection of non-overlapping data, used to objectively evaluate the model's generalization ability. For evaluation set management rules, seeTraining set and evaluation set.

Text generation - DPO format

DPO text generation training data uses the jsonl format. Based on the ChatML messages multi-turn structure, it additionally contains two contrasting assistant outputs, chosen and rejected, for preference alignment training. All content within messages is used as input, and DPO is used to train the model's positive/negative feedback on the last user input. For the messages multi-turn structure rules, see Text generation - SFT format. For deep thinking content, the chosen or rejected assistant output can be wrapped with thinking tags. The thinking tag can only be placed in the last assistant line. For the rules, see Text generation - SFT format. The loss_weight parameter (invite-only, only supported by Qwen3.5+) supports the chosen module. The value range is 0.0 to 1.0; the larger the value, the higher the training importance. For details, see Text generation - SFT format. The single file size limit for DPO training data is 200 MB, consistent with SFT text generation. For the DPO definition, see Introduction to model fine-tuning. For draft and publish operations, see Training set and evaluation set. See the code block below for a DPO text generation training data sample:
  • Standard ChatML
  • Deep thinking (thinking)
Standard chosen/rejected comparison format sample (two contrasting assistant outputs):
{
  "messages": [
    {"role": "system", "content": "System input"},
    {"role": "user", "content": "User input 1"},
    {"role": "assistant", "content": "Model output 1"},
    {"role": "user", "content": "User input 2"},
    {"role": "assistant", "content": "Model output 2"},
    {"role": "user", "content": "User input 3"}
  ],
  "chosen": {"role": "assistant", "content": "Preferred expected model output 3"},
  "rejected": {"role": "assistant", "content": "Rejected expected model output 3"}
}

Text generation - CPT format

CPT text generation training data uses the jsonl plain text format, with one jsonl object per line, structured as {text}, where the text field is plain text content. For the messages multi-turn structure rules, see Text generation - SFT format. CPT training data constraints:
  • A minimum of 50 million Tokens is recommended, and the single file size limit is 300 MB.
  • Draft status and data inheritance are not supported; each new version requires creating new data and publishing immediately.
For the CPT definition, see Introduction to model fine-tuning. For version management and data inheritance operations, see Training set and evaluation set. The complete JSON structure of a CPT plain text sample is shown in the code block below. The data inheritance strategy when creating a new version for each training method is as follows (CPT does not support inheriting existing data; each new version requires creating new data):

Data inheritance strategy

SFT

DPO

CPT

Inherit existing data

Create new data

Supported (force new)

{text} plain text format sample (one jsonl plain text object per line):
{
  "text": "Text content"
}

Visual understanding-SFT format

SFT image training data is used for Qwen VL multimodal understanding (the console UI option is "Image Understanding"). It uses a zip package format containing a data.jsonl training text data file and image files. data.jsonl must be placed at the root of the package. Each training record's messages in data.jsonl adopt a content array structure, with array items containing an image field (image) and a text field (text). A single-layer directory structure is recommended. For packaging rules, see Multimodal zip package packaging rules.
  • Image input limits
  • Video input limits
Image admission limits are as follows:
  • The width and height of a single image must not exceed 1024 px.
  • A single image must not exceed 10 MB.
  • Supported formats: bmp, jpeg, jpg, png, tif, tiff, webp.
resized_width and resized_height are optional target scaling control parameters used to specify the target scaling dimensions of the image; they are not the image admission upper limit. The image admission upper limit is that the width and height do not exceed 1024 px and a single image does not exceed 10 MB. The specific values for image admission are subject to the actual display in the console.For token consumption calculation for images, see Image and video understanding - Billing and rate limits.
SFT image training examples are shown in the tabs below:
  • Standard ChatML
  • Thinking (thinking)
  • Function calling (function calling)
  • Image input
  • Video file path mode
  • Image frame list mode
Standard ChatML format example (system/user/assistant multi-turn dialogue):
{
  "messages": [
    {"role": "system", "content": [{"text": "System input 1"}]},
    {"role": "user", "content": [{"text": "User input 1"}]},
    {"role": "assistant", "content": [{"text": "Expected model output 1"}]},
    {"role": "user", "content": [{"text": "User input 2"}]},
    {"role": "assistant", "content": [{"text": "Expected model output 2"}]}
  ]
}
For the multimodal understanding definition, see Introduction to model fine-tuning.

Tool field description

The function calling mode adds tools definitions and the tool_calls/role:tool mechanism on top of the multi-turn messages structure. Field constraints are as follows:
  • tools: tool definition array; each item contains type:"function" and function{name, description, parameters}; parameters is a JSON Schema (containing type/properties/required).
  • messages: multi-turn dialogue array; roles include user, assistant, and tool.
  • content: multimodal content array; can contain image, text, video, and other items (consistent with the multimodal understanding format).
  • assistant.tool_calls: tool call array generated by the model; contains id, type:"function", function{name, arguments}; arguments is a JSON string.
  • role:"tool": tool return; tool_call_id must correspond one-to-one with the corresponding tool_calls[].id; content contains the tool return result.
The last message of a multi-turn dialogue is usually the assistant's final reply based on the tool return. The tool mode belongs to the SFT scenario; for tool data support in the DPO scenario, see Text generation - DPO format. loss_weight field constraints:
  • Invite-only parameter; value range 0.0 to 1.0; the larger the value, the higher the relative importance of this row during training.
  • For SFT thinking models, only the last assistant row supports loss_weight.
Bailian does not support OpenAI's name and weight parameters; all assistant outputs will be trained. Training data migrated from OpenAI/Azure must not carry name/weight fields. Data diversity and balance recommendations: the quantity of data in each scenario should be relatively balanced, and the data ratio should match the actual scenario ratio. Avoid having too much of one type of data, which would cause the model to favor learning that type of features and affect generalization ability. For ChatML and loss_weight field definitions, see Introduction to model fine-tuning.

Thinking tag rules

Thinking content is wrapped in <think>\n…\n</think>\n\n tags and placed within the assistant output text (belonging to the same last assistant's content as the final reply). Rules:
  • It must be placed only in the last assistant output; intermediate assistant outputs do not add thinking tags.
  • The newlines before and after the thinking tags must be preserved.
  • If the training samples set the model not to output thinking tags, after training is complete it is not recommended to enable the thinking mode for calls.

Multimodal zip package packaging rules

Multimodal understanding training data is uploaded as a zip package via the Add Dataset page. Packaging must meet the following constraints:
  • The zip package supports up to 2 GB.
  • The allowed character set for folder and file names inside the package is ASCII letters (a-z, A-Z), digits (0-9), underscores (_), and hyphens (-).
  • The training text data file is fixed as data.jsonl and must be located in the root directory of the zip package — ensure that after extraction, opening the zip file directly shows data.jsonl, with no additional outer folder wrapping.
Image or video file names must be globally unique within the zip package, even if distributed across different folders. Inside data.jsonl, only the file name needs to be declared rather than the file path — correct example: image1.jpg; wrong example: jpg_folder/image1.jpg. Cloud storage mount does not support zip packages. When loading a dataset via cloud storage mount, you must upload the uncompressed dataset folder as a whole to the OSS Bucket, and specify the data.jsonl file path via MountStorage's file_path; when multiple files are included, only the data.jsonl path needs to be specified, and other files in the same directory are mounted automatically. For details on cloud storage mount, see Fine-tune with the API or CLI. Naming examples and directory structure are shown in the code block below. For cloud storage mount authorization operations, see Fine-tune models in the console; for OSS Bucket import tagging operations, see Training set and evaluation set.
# Single-layer directory (recommended)
Trainingdata_vl.zip
  |--- data.jsonl        # Must be in the root directory, no outer folder wrapping
  |--- image1.png
  |--- video1.mp4

# Declare filename inside data.jsonl (not path)
# Correct: image1.jpg
# Wrong: jpg_folder/image1.jpg
Go to the console Create dataset page to upload the multimodal zip package and complete packaging validation.

File size and quantity limits

The upper limits on local upload file size and quantity are set by training method and scenario, as detailed in the scenario-specific table below. For image admission limits, see Visual understanding-SFT format; for evaluation set format limits, see Evaluation set format; for log backflow ingestion limits, see Evaluation set format. max_length takes values in the range 500 to 131072 as a training sequence length configuration parameter, not an upload admission upper limit. The upper limit on admission size for a single training data record is not given a numeric value in the source document; refer to the value displayed on the console page. The upper limits on local upload file size and quantity are set by training method and scenario. The recommended data volume is the minimum suggested value:

Training method/scenario

Max single file size

Max file count (maxCount)

Recommended data volume

Text generation - SFT format

200 MB

10 (default)

At least thousands of samples

Text generation - DPO format

200 MB

10 (default)

At least hundreds of samples

Text generation - CPT format

300 MB

1

At least 50 million Tokens

Multimodal (zip)

2 GB

1

Prepare sufficient samples based on actual scenarios

Filename (without extension)

≤120 characters and unique

Extension

Must be in the Create dataset list

API upload quota

The quota for uploading fine-tuning files via the DashScope API (with purpose tagged as model fine-tuning) is shown in the quota table below. When creating a dataset in the console, the File API list supports merging and registering up to 10 files; fine-tuning files uploaded via the API are visible and usable in both the console model fine-tuning page and API calls. Constraints for loading datasets via cloud storage mount:
  • Specify the data.jsonl root directory manifest path via MountStorage's file_path; zip archives are not supported.
  • When selecting cloud storage mount as the storage location, immediate publish is enforced; draft status is not supported.
  • Before mounting, you must authorize the Bailian service to access OSS data.
Overflow handling and encryption:
  • Single file exceeding 300 MB: upload via cloud storage mount or the multi-modal ZIP 2 GB channel.
  • Total quota exceeded: delete historical files to free up space.
  • Imported data automatically enables OSS server-side encryption (SSE-OSS, AES256).
For details on API calls, authentication, SDK, error codes, and MountStorage fields, see Fine-tune with the API or CLI. The quota for uploading fine-tuning files via the API is as follows:

Quota item

Limit

Description

Single file size

Up to 300 MB

Fine-tuning files (for model fine-tuning purpose)

Total valid file space

100 GB

Cumulative of undeleted files

Total valid file count

10000

Cumulative of undeleted files

File storage duration

No time limit

Does not auto-expire

File API list upper limit

10

Merged registration when creating a dataset in the console

The differences between OSS import and cloud storage mount are compared as follows:

Dimension

OSS import

Cloud storage mount

Prerequisite

Bailian data access authorization tag

Authorize Bailian service to access OSS data

Data form

Single or batch files

Entire uncompressed dataset folder (zip not supported)

Entry

Data Management > New Dataset > OSS Import

Model Fine-tuning > Create Training Task > Data Configuration > Dataset Mount

Version draft

Supports draft and immediate publish

Forces immediate publish (draft not supported)

Evaluation set ✓

Upload validation and common errors

When uploading files locally on the Add Dataset page, frontend validation rejects files that do not meet the admission rules and displays a prompt. Common validation rejections and upload error scenarios are shown in the collapsible items below:
Issue:When uploading files, the frontend prompts that the file count exceeds the upper limit, and the files are rejected.Cause:maxCount is set by training method — SFT/DPO text defaults to 10, multi-modal zip and CPT default to 1. Uploading files exceeding the corresponding training method's upper limit will be rejected by the frontend.Action:Adjust as follows and re-upload:
  1. Check the maxCount upper limit corresponding to the current training method; for details see File size and quantity limits.
  2. Reduce the file count to within the upper limit; merge multi-modal data into a single zip, and merge CPT data into a single jsonl.
  3. If the file count still exceeds the limit, split into multiple datasets and upload in batches.
Issue:The filename (excluding extension) length exceeds 120 characters, and the frontend rejects the upload.Cause:The filename excluding extension has a 120-character upper limit and must contain only ASCII letters, digits, underscores, and hyphens.Action:Adjust as follows and re-upload:
  1. Rename the file so that the filename (excluding extension) is shortened to within 120 characters.
  2. Use only a-z/A-Z/0-9/_/- characters; remove Chinese and other non-ASCII characters.
  3. Filenames inside a multi-modal archive must also be globally unique.
Issue:The filename (excluding extension comparison) is duplicated, and the frontend rejects the upload.Cause:Filenames within the same dataset must be unique excluding extension; the comparison ignores the extension.Action:Adjust as follows and re-upload:
  1. Check for duplicate-named files and rename them so the part excluding extension is unique.
  2. Files with the same name but different extensions (e.g., image.jpg and image.png) are also judged as duplicates and must be differentiated simultaneously.
  3. Filenames inside a multi-modal zip must be globally unique, even if distributed across different folders.
Issue:The single file size exceeds the upper limit of the corresponding training method, and the frontend rejects the upload.Cause:The single file size upper limit varies by training method scenario — SFT/DPO text 200 MB, multi-modal zip 2 GB, CPT 300 MB.Action:Adjust as follows and re-upload:
  1. Check whether the file size exceeds the upper limit of the corresponding training method.
  2. Split the jsonl into multiple files for batch upload (SFT/DPO); CPT data splitting requires creating multiple new datasets.
  3. For the overflow handling method when a single file exceeds 300 MB, see API upload quota.
Issue:The file extension is not in the supportedExtension list, and the frontend pops up a warning and rejects the upload.Cause:The extension must be within the supported list — text training uses jsonl, evaluation sets use xlsx, multi-modal images support bmp/jpeg/jpg/png/tif/tiff/webp, and multi-modal videos support mp4 and other formats.Action:Adjust as follows and re-upload:
  1. Check whether the file extension is within the supported list for the corresponding scenario.
  2. Convert the file to a supported extension and repackage for upload.
  3. Image and video extensions inside a multi-modal zip must each conform, otherwise the entire package import fails.
Issue:During OSS upload, the file is set to error status and the upload is not completed.Cause:Common causes are missing Bucket tag, abnormal Bailian service OSS access authorization, or non-conforming file format.Action:Troubleshoot as follows and retry:
  1. Verify that the OSS Bucket has the Bailian data access authorization tag added.
  2. Confirm that the Bailian service has been authorized to access OSS data.
  3. Check that data.jsonl and the file format conform to the packaging rules and retry the upload; for details see Multimodal zip package packaging rules.
Irreversible operation risk notice:
  • Publish and delete operations are both irreversible; published versions cannot be edited again, and only draft versions can be deleted or edited online.
  • Dataset type (training set/evaluation set) cannot be changed or interchanged after creation; selecting the wrong one requires creating a new dataset and re-importing all data.
  • Switching dataset type, training scenario, or training method clears the uploaded files and resets the storage location and import method.
Automatic validation set splitting randomly extracts 10% of data from the training set as the validation set, reducing the actual training data volume. For small datasets, an independent validation set is recommended; for validation set configuration operations see Fine-tune models in the console. It is recommended to first download the data template for the corresponding scenario; preparing data according to the template structure can avoid import failures. For data template download recommendations see Overview. Common issue troubleshooting is detailed in the collapsible items below. For draft data cleaning and augmentation operations see , and for security and compliance data domains see . When upload validation fails, go to the console New Dataset page to check the file format and admission rules.
Token Plan
Model Playground
  • Music generation
Statistics and Monitoring
Support
Fine-tuning data upload rules - Alibaba Cloud Model Studio