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.

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.

For reinforcement learning (RL) training data format (jsonl + messages + rollout_extra, uploaded via SDK), see RL training data format.

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:

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:

{
  "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"}
  ]
}

{"role": "assistant", "content": "Expected model output", "loss_weight": "1.0"}

{
  "messages": [
    {"role": "system", "content": "System input 1"},
    {"role": "user", "content": "User input 1"},
    {"role": "assistant", "content": "Model output 1"},
    {"role": "user", "content": "User input 2"},
    {"role": "assistant", "content": "<think>\nExpected thinking content 2\n</think>\n\nExpected output 2"}
  ]
}

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:

{
  "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"}
}

{
  "messages": [
    {"role": "system", "content": "System input"},
    {"role": "user", "content": "User input 1"},
    {"role": "assistant", "content": "Model output 1"},
    {"role": "user", "content": "User input 2"}
  ],
  "chosen": {"role": "assistant", "content": "<think>\nExpected thinking content\n</think>\n\nExpected model output"},
  "rejected": {"role": "assistant", "content": "Rejected expected model output 2"}
}

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):

{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.

SFT image training examples are shown in the tabs below:

{
  "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"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "System input 1"}]},
    {"role": "user", "content": [{"text": "User input 1"}]},
    {"role": "assistant", "content": [{"text": "Model output 1"}]},
    {"role": "user", "content": [{"text": "User input 2"}]},
    {"role": "assistant", "content": [{"text": "<think>\nExpected thinking content 2\n</think>\n\nExpected output 2"}]}
  ]
}

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Query real-time weather for a specified city",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {"type": "string", "description": "City name, e.g.: Beijing"}
          },
          "required": ["city"]
        }
      }
    }
  ],
  "messages": [
    {"role": "user", "content": [{"text": "Help me check the weather in Beijing"}]},
    {
      "role": "assistant",
      "content": [{"text": "OK, I will help you query the weather in Beijing."}],
      "tool_calls": [
        {
          "id": "call_3a11c1ba883b41b6a4e0cb",
          "type": "function",
          "function": {
            "name": "get_weather",
            "arguments": "{\"city\": \"Beijing\"}"
          }
        }
      ]
    },
    {"role": "tool", "tool_call_id": "call_3a11c1ba883b41b6a4e0cb", "content": [{"text": "{\"city\": \"Beijing\", \"weather\": \"Sunny\", \"temperature\": \"25℃\"}"}]},
    {"role": "assistant", "content": [{"text": "Beijing is sunny today, with a temperature of 25°C, suitable for going out."}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "System input"}]},
    {
      "role": "user",
      "content": [
        {"text": "User input 1"},
        {"image": "image_file1.jpg", "resized_width": 200, "resized_height": 200}
      ]
    },
    {"role": "assistant", "content": [{"text": "Expected model output 1"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "System input"}]},
    {
      "role": "user",
      "content": [
        {"text": "User input 1"},
        {"video": "video_file1.mp4", "fps": 3.0, "resized_width": 200, "resized_height": 200, "video_start": 0.0, "video_end": 3.0}
      ]
    },
    {"role": "assistant", "content": [{"text": "Expected model output 1"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "System input"}]},
    {
      "role": "user",
      "content": [
        {"text": "User input 2"},
        {"video": ["0.jpg", "1.jpg", "2.jpg", "3.jpg"], "sample_fps": 5.0, "resized_width": 200, "resized_height": 200}
      ]
    },
    {"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.

RL training data format

Reinforcement learning (RL) training data uses the jsonl format, with one JSON object per line, containing the messages and rollout_extra fields. RL is uploaded via the SDK (AgenticRL.run()), not the console packaging channel; billing is by MTU model training unit, not Token. For details on RL data format, SDK upload, and Rollout/Reward function development, see Reinforcement learning training overview.

Field descriptions:

• messages: the user question, in ChatML structure ([{role, content}]). It only contains the prompt (user, optionally prefixed with system), and does not includeassistantanswers — the answer is autonomously generated by the model during the Rollout phase. content is a string.
• rollout_extra: the reference answer or business data, of dict type, passed through to the Reward function for scoring. It supports custom keys (not limited to solution); the framework automatically extracts ground_truth (the reference answer), and custom keys are read via rollout_extra["key"].

RL data does not includerewardfield — reward is computed by the Reward function at training runtime (scoring against the rollout_extra reference answer, outputting a 0~1 score), and is not preset in the jsonl. Unlike SFT (messages contain the full assistant answer) and DPO (chosen/rejected pairs), RL messages only contain the prompt.

Math reasoning sample (rollout_extra.solution standard answer):

{"messages": [{"role": "user", "content": "Output the answer when you are ready. The answer should be surrounded by three sharps (###), in the form of ### ANSWER: <answer> ###. 6.6 minus x (3/2) times equals 5.6."}], "rollout_extra": {"solution": "2/3"}}

Code generation sample (entry_point/tests/timeout_sec/language):

{"messages": [{"role": "user", "content": "Write a function add(a, b) that returns the sum of two integers."}], "rollout_extra": {"entry_point": "add", "tests": "def test_add():\n    assert add(1,2)==3\n    assert add(-1,1)==0\n", "timeout_sec": 10, "language": "python"}}

Agent tool call sample (expected_tools/success_check/max_steps):

{"messages": [{"role": "user", "content": "Query the logistics status of order ORD-123 and inform the estimated delivery date."}], "rollout_extra": {"expected_tools": ["query_order", "get_logistics"], "success_check": "SELECT status FROM orders WHERE id='ORD-123'", "max_steps": 6}}

Common keys of rollout_extra (by scenario):

• Math reasoning: solution (standard answer), solution_steps (process, optional), difficulty (difficulty, optional).
• Agent tool calls: expected_tools (expected tool set), success_check (success criterion), max_steps (call efficiency reference).
• Code generation: entry_point (entry function), tests (unit test code), timeout_sec (execution timeout), language (sandbox selection).

RL data constraints:

• The data volume must be greater than batch_size (default 64). Dozens to hundreds of samples can verify a solution; for formal training, math reasoning requires 500~2000 samples, Agent ≥1000 samples, code ≥1000 problems — the larger the data volume, the better the effect.
• The training set and validation set are two independent jsonl files, uploaded separately via TrainingDataset/ValidationDataset (validation set optional).
• RL is uploaded via the SDK (AgenticRL.run()), not the console packaging channel; billing is by MTU model training unit, not Token. For SDK fields and submission method, see Reinforcement learning training configuration.

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:

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:

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

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:

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 Data cleansing and augmentation, and for security and compliance data domains see Zero-Code Reinforcement of Large Language Model Security and Compliance.

When upload validation fails, go to the console New Dataset page to check the file format and admission rules.