Copy

Visão geral

Este documento detalha as especificações de formato, requisitos de empacotamento, limites de tamanho e quantidade e cotas de upload via API para dados de ajuste fino de modelos de geração de texto. O escopo abrange o ajuste fino de modelos de geração de texto (texto/imagem/vídeo → texto), incluindo SFT/DPO/CPT em texto simples, compreensão de imagem e vídeo com Qwen VL, extração de quadros de vídeo, function calling e raciocínio. O ajuste fino de modelos de geração de vídeo (imagem → vídeo) está fora do escopo. Não é possível alterar o tipo de dataset (conjunto de treinamento ou conjunto de avaliação) após a criação. A tabela Training method and element support matrix apresenta o suporte detalhado para cada método de treinamento e elemento. As regras de construção de formato para cada combinação estão descritas nos capítulos correspondentes abaixo.

As operações de publicação e exclusão são irreversíveis: versões publicadas não podem ser editadas novamente, e apenas versões em rascunho podem ser excluídas ou editadas online. Além disso, o tipo de dataset não pode ser alterado após a criação. Alterar o tipo, cenário ou método de treinamento limpa os arquivos enviados.

Documentos relacionados abordam operações de gerenciamento, como parâmetros de criação, gestão de versões, regras do conjunto de avaliação, seleção de método de importação, limpeza de dados, segurança e conformidade. Consulte Training set and evaluation set, Introduction to model fine-tuning, entre outros. Recomendamos baixe o modelo de dados correspondente ao cenário na página de criação do dataset e preparar os dados conforme essa estrutura para evitar falhas na importação. Para obter recomendações sobre a construção de datasets, incluindo escala de dados sugerida, diversidade, equilíbrio e estratégias de aumento de dados, consulte Model fine-tuning introduction - Dataset construction tips.

Matriz de suporte a métodos de treinamento e elementos

O conjunto de treinamento aceita três métodos: SFT, DPO e CPT. A tabela abaixo mostra o status de suporte de cada método e elemento. A ordem recomendada para ajuste fino é CPT (opcional) → SFT → DPO (opcional). Esses métodos são progressivos e não mutuamente exclusivos. Disponibilidade por região:

SFT, upload local, backflow de log, upload via API e formatos de dados multimodais têm suporte em todas as regiões.
DPO, CPT, importação via OSS e montagem de armazenamento em cloud estão disponíveis apenas na região Beijing.

A matriz de suporte para métodos de treinamento e elementos é a seguinte:

Método de treinamento	Geração de texto	Compreensão visual - Entrada de imagem	Compreensão visual - Entrada de vídeo (qwen3.5+)	Compreensão visual - Tool calling (qwen3.5+)	Raciocínio profundo
SFT	✓	✓	✓	✓	✓
DPO	✓	✗	✗	✗	✓
CPT	✓	✗	✗	✗	✗
Evaluation set	✓	✗	✗	✗	✗

Cada método de treinamento na matriz possui um link para sua seção explicativa detalhada. Para definições de campos, veja a próxima seção. Para consultar as definições de campos dos métodos SFT/DPO/CPT, acesse Introduction to model fine-tuning.

Geração de texto - Formato SFT

Os dados de treinamento SFT para geração de texto utilizam o formato de arquivo jsonl, baseados na estrutura multivolta ChatML messages.

Três funções são suportadas: system, user e assistant. O campo content é uma string (para a estrutura de array content em cenários multimodais, consulte o capítulo correspondente ao formato multimodal).
O tamanho máximo por arquivo individual é de 200 MB.
Um dataset pode misturar linhas de diferentes formatos. Cada registro seleciona seu formato independentemente, sem necessidade de unificação.
Formatos disponíveis: ChatML padrão, thinking, function calling e function calling combinado com thinking (consulte as abas de exemplo abaixo).

A geração de texto SFT aceita os seguintes formatos de amostra. A estrutura JSON completa de cada amostra aparece na aba correspondente:

Standard ChatML
Thinking
Function calling

Exemplo de formato ChatML padrão (diálogo multivolta system/user/assistant):

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

Alguns modelos aceitam o parâmetro loss_weight, com intervalo de valores (0.0, 1.0]. Quanto maior o valor, maior a importância durante o treinamento.

Suportado nativamente pelo Qwen3.5+. Para outros modelos, entre em contato com seu gerente de conta caso necessite desse recurso.

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

Exemplo de formato Thinking (a tag thinking deve estar na última mensagem do assistant; preserve as quebras de linha antes e depois dela):

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

Regras da tag thinking

O conteúdo de raciocínio fica envolvido pelas tags <think>\n…\n</think>\n\n, inserido dentro do texto de saída do assistant (compartilhando o mesmo último content do assistant com a resposta final). Regras:

Insira a tag apenas na última saída do assistant. Saídas intermediárias não devem conter tags de thinking.
Mantenha obrigatoriamente as quebras de linha antes e depois da tag thinking.
Se uma amostra de treinamento configurar o modelo para não gerar tags de thinking, evite reativar o modo de raciocínio ao chamar o modelo após o treinamento.

Formato do conjunto de avaliação

O conjunto de avaliação atende exclusivamente a cenários de geração de texto e independe do método de treinamento SFT/DPO/CPT. Modelos treinados com DPO/CPT também utilizam o conjunto de avaliação de geração de texto, sem distinção por método de treinamento. Especificações do conjunto de avaliação:

O formato do arquivo é xlsx. A estrutura de colunas está disponível no modelo baixado pelo console.
Métodos de ingestão aceitos: upload local e replay de log. Importação via Object Storage Service (OSS) e montagem de armazenamento em cloud não são suportadas.
Apenas versões em rascunho permitem edição online (Prompt/Completion). Versões publicadas não são editáveis.

Descrição do formato para upload local:

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

Limites de ingestão por replay de log:

O intervalo de logs suportado abrange os últimos 30 dias.
Limite de 100.000 registros por importação.
Autorize a função vinculada ao service e especifique a API Key e as condições de filtro do modelo.
O conjunto de treinamento aplica-se apenas a cenários SFT de geração de texto (o conjunto de avaliação de geração de texto também é compatível).

Para detalhes sobre o método de ingestão por replay de log, consulte Log backflow. O conjunto de avaliação deve ser uma coleção independente de dados sem sobreposição, usada para avaliar objetivamente a capacidade de generalização do modelo. Para regras de gerenciamento do conjunto de avaliação, consulte Training set and evaluation set.

Geração de texto - Formato DPO

Os dados de treinamento DPO para geração de texto usam o formato jsonl. Baseiam-se na estrutura multivolta ChatML messages e incluem duas saídas contrastantes do assistant, chosen e rejected, para treinamento de alinhamento de preferências. Todo o conteúdo dentro de messages serve como entrada, e o DPO treina o feedback positivo/negativo do modelo sobre a última entrada do user. Para regras da estrutura multivolta messages, consulte Text generation - SFT format. Para conteúdo de raciocínio profundo, a saída chosen ou rejected do assistant pode ser envolvida por tags de thinking. A tag thinking deve aparecer apenas na última linha do assistant. Para as regras, consulte Text generation - SFT format. O parâmetro loss_weight (disponível apenas por convite, suportado exclusivamente pelo Qwen3.5+) aceita o módulo chosen. O intervalo de valores vai de 0.0 a 1.0; quanto maior o valor, maior a importância no treinamento. Para mais detalhes, consulte Text generation - SFT format. O limite de tamanho de arquivo único para dados de treinamento DPO é de 200 MB, igual ao SFT de geração de texto. Para a definição de DPO, consulte Introduction to model fine-tuning. Para operações de rascunho e publicação, consulte Training set and evaluation set. Veja o bloco de código abaixo para uma amostra de dados de treinamento DPO para geração de texto:

Standard ChatML
Deep thinking (thinking)

Exemplo de formato padrão de comparação chosen/rejected (duas saídas contrastantes do assistant):

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

Exemplo de formato com tag thinking (conteúdo de raciocínio profundo envolvido por tags thinking, posicionado no último assistant):

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

Geração de texto - Formato CPT

Os dados de treinamento CPT para geração de texto utilizam o formato de texto simples jsonl, com um objeto jsonl por linha, estruturado como {text}, onde o campo text contém o conteúdo em texto simples. Para regras da estrutura multivolta messages, consulte Text generation - SFT format. Restrições para dados de treinamento CPT:

Recomenda-se um mínimo de 50 milhões de Tokens, e o limite de tamanho por arquivo único é de 300 MB.
Status de rascunho e herança de dados não são suportados. Cada nova versão exige a criação de novos dados e publicação imediata.

Para a definição de CPT, consulte Introduction to model fine-tuning. Para operações de gerenciamento de versões e herança de dados, consulte Training set and evaluation set. A estrutura JSON completa de uma amostra de texto simples CPT aparece no bloco de código abaixo. A estratégia de herança de dados ao criar uma nova versão para cada método de treinamento é a seguinte (o CPT não suporta herança de dados existentes; cada nova versão requer a criação de novos dados):

Estratégia de herança de dados	SFT	DPO	CPT
Herdar dados existentes	✓	✓	✗
Criar novos dados	✓	✓	Suportado (força novo)

Exemplo de formato de texto simples {text} (um objeto de texto simples jsonl por linha):

{
  "text": "Text content"
}

Compreensão visual - Formato SFT

Os dados de treinamento SFT com imagens destinam-se à compreensão multimodal do Qwen VL (a opção na UI do console é "Image Understanding"). Utilizam o formato de pacote zip, contendo um arquivo de dados de texto de treinamento data.jsonl e arquivos de imagem. O arquivo data.jsonl deve ficar na raiz do pacote. Em cada registro de treinamento, o campo messages no data.jsonl adota uma estrutura de array content, cujos itens contêm um campo de imagem (image) e um campo de texto (text). Recomenda-se uma estrutura de diretório de camada única. Para regras de empacotamento, consulte Multimodal zip package packaging rules.

Image input limits
Video input limits

Os limites de admissão de imagens são:

A largura e a altura de uma única imagem não podem exceder 1024 px.
Uma única imagem não pode ultrapassar 10 MB.
Formatos suportados: bmp, jpeg, jpg, png, tif, tiff, webp.

Os parâmetros resized_width e resized_height são opcionais e servem para controlar o redimensionamento alvo da imagem; eles não representam o limite superior de admissão. O limite de admissão exige que largura e altura não ultrapassem 1024 px e que o arquivo individual não exceda 10 MB. Os valores específicos para admissão de imagens seguem o que for exibido no console.Para calcular o consumo de tokens em imagens, consulte Image and video understanding - Billing and rate limits.

Suportado apenas pelos modelos multimodais qwen3.5 e posteriores. Dois modos de entrada de vídeo estão disponíveis:

Modo de caminho de arquivo de vídeo: o campo video é uma string (ex.: "video1.mp4"), e a plataforma cuida da extração de quadros. Ideal para cenários que usam arquivos de vídeo completos.
Modo de lista de quadros de imagem: o campo video é uma lista de nomes de arquivos de imagem (ex.: ["0.jpg","1.jpg"]), e você prepara a sequência de quadros. Adequado quando as imagens de extração de quadros já existem.

As imagens e vídeos nos dados de treinamento também devem respeitar os limites de entrada das chamadas de modelo, como resolução de imagem, duração de vídeo, taxa de quadros, etc. Para limites de chamada, consulte Video limits.

Para calcular o consumo de tokens em vídeos, consulte Image and video understanding - Billing and rate limits.A comparação de campos e exemplos dos dois modos aparece abaixo:

Campo/Parâmetro	Modo de caminho de arquivo de vídeo	Modo de lista de quadros de imagem
video	str (caminho do arquivo de vídeo, obrigatório)	List[str] (lista de quadros de imagem, obrigatório)
sample_fps	N/A	float ([0.1, 10], padrão 2.0, opcional)
fps	float ([0.1, 10], padrão 2.0, opcional)	N/A
resized_width	int (largura de redimensionamento, opcional)	int (largura de redimensionamento, opcional)
resized_height	int (altura de redimensionamento, opcional)	int (altura de redimensionamento, opcional)
video_start	float (tempo inicial do clipe, opcional)	N/A
video_end	float (tempo final do clipe, opcional)	N/A

Os exemplos de treinamento SFT com imagens aparecem nas abas abaixo:

Exemplo de formato ChatML padrão (diálogo multivolta system/user/assistant):

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

Exemplo de formato Thinking (thinking) (a tag thinking fica na última mensagem do assistant; preserve as quebras de linha antes e depois):

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

Os modos qwen3.5+ suportam o uso do formato de dados function calling.

Exemplo de formato Function calling (function calling) (definições de tools + mensagens multivolta contendo a role tool, com tool_call_id em correspondência um a um):

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

Exemplo de formato imagem mais texto (o array content contém itens de imagem e itens de texto):

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

Exemplo de formato no modo de caminho de arquivo de vídeo (o campo video é uma string com o caminho do arquivo de vídeo):

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

Exemplo de formato no modo de lista de quadros de imagem (video é uma lista de quadros, contendo sample_fps):

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

Para a definição de compreensão multimodal, consulte Introduction to model fine-tuning.

Descrição do campo tool

O modo function calling adiciona definições de tools e o mecanismo tool_calls/role:tool sobre a estrutura de mensagens multivolta. As restrições de campos são:

tools: array de definições de ferramentas. Cada item contém type:"function" e function{name, description, parameters}. O campo parameters é um JSON Schema (contendo type/properties/required).
messages: array de diálogo multivolta. As roles incluem user, assistant e tool.
content: array de conteúdo multimodal. Pode conter itens image, text, video, entre outros (consistente com o formato de compreensão multimodal).
assistant.tool_calls: array de chamadas de ferramenta geradas pelo modelo. Contém id, type:"function", function{name, arguments}. O campo arguments é uma string JSON.
role:"tool": retorno da ferramenta. O tool_call_id deve corresponder um a um ao respectivo tool_calls[].id. O content contém o resultado retornado pela ferramenta.

A última mensagem de um diálogo multivolta geralmente é a resposta final do assistant baseada no retorno da ferramenta. O modo tool pertence ao cenário SFT. Para suporte a dados de tool no cenário DPO, consulte Text generation - DPO format. Restrições do campo loss_weight:

Parâmetro disponível apenas por convite. Intervalo de valores de 0.0 a 1.0. Quanto maior o valor, maior a importância relativa dessa linha durante o treinamento.
Em modelos SFT com thinking, apenas a última linha do assistant aceita loss_weight.

O Bailian não suporta os parâmetros name e weight da OpenAI; todas as saídas do assistant serão treinadas. Dados de treinamento migrados da OpenAI/Azure não devem conter os campos name/weight. Recomendações de diversidade e equilíbrio de dados: a quantidade de dados em cada cenário deve ser relativamente equilibrada, e a proporção deve refletir a distribuição real dos cenários. Evite excesso de um único tipo de dado, pois isso faz o modelo tender a aprender esse tipo de característica e prejudica a capacidade de generalização. Para definições de ChatML e do campo loss_weight, consulte Introduction to model fine-tuning.

Regras da tag thinking

O conteúdo de raciocínio fica envolvido pelas tags <think>\n…\n</think>\n\n e inserido dentro do texto de saída do assistant (pertencendo ao mesmo último content do assistant da resposta final). Regras:

Posicione a tag apenas na última saída do assistant. Saídas intermediárias não recebem tags de thinking.
Preserve obrigatoriamente as quebras de linha antes e depois das tags thinking.
Se as amostras de treinamento configurarem o modelo para não gerar tags de thinking, evite ative o modo de raciocínio nas chamadas após a conclusão do treinamento.

Regras de empacotamento zip multimodal

Os dados de treinamento para compreensão multimodal são enviados como um pacote zip pela página Add Dataset. O empacotamento deve atender às seguintes restrições:

O pacote zip suporta até 2 GB.
O conjunto de caracteres permitido para nomes de pastas e arquivos dentro do pacote inclui letras ASCII (a-z, A-Z), dígitos (0-9), underscores (_) e hífens (-).
O arquivo de dados de texto de treinamento é fixo como data.jsonl e deve estar no diretório raiz do pacote zip. Garanta que, após a extração, abrir o arquivo zip mostre diretamente o data.jsonl, sem nenhuma pasta externa adicional envolvendo o conteúdo.

Os nomes dos arquivos de imagem ou vídeo devem ser globalmente únicos dentro do pacote zip, mesmo se distribuídos em pastas diferentes. Dentro do data.jsonl, declare apenas o nome do arquivo, não o caminho. Exemplo correto: image1.jpg; exemplo incorreto: jpg_folder/image1.jpg. A montagem de armazenamento em cloud não aceita pacotes zip. Ao carregar um dataset via montagem de armazenamento em cloud, envie a pasta descompactada do dataset inteira para o Bucket OSS e especifique o caminho do arquivo data.jsonl via file_path do MountStorage. Quando houver múltiplos arquivos, basta especificar o caminho do data.jsonl; outros arquivos no mesmo diretório são montados automaticamente. Para detalhes sobre montagem de armazenamento em cloud, consulte Fine-tune with the API or CLI. Exemplos de nomenclatura e estrutura de diretórios aparecem no bloco de código abaixo. Para operações de autorização de montagem de armazenamento em cloud, consulte Fine-tune models in the console; para operações de marcação de importação de Bucket OSS, consulte 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

Acesse a página Create dataset no console para enviar o pacote zip multimodal e concluir a validação do empacotamento.

Limites de tamanho e quantidade de arquivos

Os limites superiores de tamanho e quantidade de arquivos para upload local variam conforme o método de treinamento e o cenário, conforme detalhado na tabela específica por cenário abaixo. Para limites de admissão de imagens, consulte Visual understanding-SFT format; para limites de formato do conjunto de avaliação, consulte Evaluation set format; para limites de ingestão por backflow de log, consulte Evaluation set format. O parâmetro max_length aceita valores entre 500 e 131072 como configuração de comprimento de sequência de treinamento, não como limite superior de admissão para upload. O documento source não fornece um valor numérico para o limite superior de tamanho de admissão por registro individual de dados de treinamento; consulte o valor exibido na página do console. Os limites superiores de tamanho e quantidade de arquivos para upload local são definidos por método de treinamento e cenário. O volume de dados recomendado representa o valor mínimo sugerido:

Método/cenário de treinamento	Tamanho máx. por arquivo	Qtd. máx. de arquivos (maxCount)	Volume de dados recomendado
Geração de texto - Formato SFT	200 MB	10 (padrão)	Pelo menos milhares de amostras
Geração de texto - Formato DPO	200 MB	10 (padrão)	Pelo menos centenas de amostras
Geração de texto - Formato CPT	300 MB	1	Pelo menos 50 milhões de Tokens
Multimodal (zip)	2 GB	1	Prepare amostras suficientes conforme os cenários reais
Nome do arquivo (sem extensão)	≤120 caracteres e único	—	—
Extensão	Deve constar na lista de Create dataset	—	—

Cota de upload via API

A cota para envio de arquivos de ajuste fino via DashScope API (com purpose marcado como ajuste fino de modelo) consta na tabela de cotas abaixo. Ao crie um dataset no console, a lista File API permite mesclar e registrar até 10 arquivos. Arquivos de ajuste fino enviados via API ficam visíveis e utilizáveis tanto na página de ajuste fino de modelo do console quanto em chamadas de API. Restrições para carregamento de datasets via montagem de armazenamento em cloud:

Especifique o caminho do manifesto do diretório raiz data.jsonl via file_path do MountStorage. Arquivos zip não são suportados.
Ao escolher montagem de armazenamento em cloud como local de armazenamento, a publicação imediata é obrigatória. Status de rascunho não é suportado.
Antes de montar, autorize o service Bailian a acessar os dados no OSS.

Tratamento de estouro e criptografia:

Arquivo único acima de 300 MB: envie via montagem de armazenamento em cloud ou pelo canal ZIP multimodal de 2 GB.
Cota total excedida: exclua arquivos históricos para liberar espaço.
Dados importados ativam automaticamente a criptografia do lado do servidor OSS (SSE-OSS, AES256).

Para detalhes sobre chamadas de API, autenticação, SDK, códigos de erro e campos do MountStorage, consulte Fine-tune with the API or CLI. A cota para envio de arquivos de ajuste fino via API é a seguinte:

Item de cota	Limite	Descrição
Tamanho de arquivo único	Até 300 MB	Arquivos de ajuste fino (purpose: ajuste fino de modelo)
Espaço total de arquivos válidos	100 GB	Acumulado de arquivos não excluídos
Contagem total de arquivos válidos	10000	Acumulado de arquivos não excluídos
Duração de armazenamento de arquivos	Sem limite de tempo	Não expira automaticamente
Limite superior da lista File API	10	Registro mesclado ao criar dataset no console

As diferenças entre importação via OSS e montagem de armazenamento em cloud são comparadas a seguir:

Dimensão	Importação via OSS	Montagem de armazenamento em cloud
Pré-requisito	Tag de autorização de acesso a dados do Bailian	Autorizar o service Bailian a acessar dados no OSS
Forma dos dados	Arquivos individuais ou em lote	Pasta inteira do dataset descompactado (zip não suportado)
Entrada	Data Management > New Dataset > OSS Import	Model Fine-tuning > Create Training Task > Data Configuration > Dataset Mount
Versão em rascunho	Suporta rascunho e publicação imediata	Força publicação imediata (rascunho não suportado)
Conjunto de avaliação ✓	✗	✗

Validação de upload e erros comuns

Ao enviar arquivos localmente na página Add Dataset, a validação de frontend rejeita arquivos fora das regras de admissão e exibe um aviso. Cenários comuns de rejeição por validação e erros de upload aparecem nos itens expansíveis abaixo:

Details

Problema: Durante o upload, o frontend informa que a contagem de arquivos excede o limite superior e rejeita os arquivos.Causa: O maxCount varia conforme o método de treinamento. Texto SFT/DPO tem padrão de 10; zip multimodal e CPT têm padrão de 1. Enviar arquivos além do limite do método de treinamento correspondente resulta em rejeição pelo frontend.Ação: Faça os ajustes abaixo e tente novamente:

Verifique o limite maxCount correspondente ao método de treinamento atual. Para detalhes, consulte File size and quantity limits.
Reduza a contagem de arquivos para dentro do limite. Mescle dados multimodais em um único zip e dados CPT em um único jsonl.
Se a contagem ainda exceder o limite, divida em múltiplos datasets e envie em lotes.

Details

Problema: O comprimento do nome do arquivo (sem extensão) ultrapassa 120 caracteres, e o frontend rejeita o upload.Causa: O nome do arquivo sem extensão tem limite de 120 caracteres e deve conter apenas letras ASCII, dígitos, underscores e hífens.Ação: Faça os ajustes abaixo e tente novamente:

Renomeie o arquivo para que o nome (sem extensão) fique dentro de 120 caracteres.
Use apenas caracteres a-z/A-Z/0-9/_/-. Remova caracteres chineses e outros não ASCII.
Nomes de arquivos dentro de um pacote multimodal também devem ser globalmente únicos.

Details

Problema: O nome do arquivo (ignorando a extensão) está duplicado, e o frontend rejeita o upload.Causa: Nomes de arquivos dentro do mesmo dataset devem ser únicos desconsiderando a extensão. A comparação ignora a extensão.Ação: Faça os ajustes abaixo e tente novamente:

Verifique se há arquivos com nomes duplicados e renomeie-os para que a parte sem extensão seja única.
Arquivos com o mesmo nome mas extensões diferentes (ex.: image.jpg e image.png) também são considerados duplicados e devem ser diferenciados simultaneamente.
Nomes de arquivos dentro de um zip multimodal devem ser globalmente únicos, mesmo se distribuídos em pastas diferentes.

Details

Problema: O tamanho do arquivo único excede o limite do método de treinamento correspondente, e o frontend rejeita o upload.Causa: O limite de tamanho de arquivo único varia por cenário de método de treinamento: texto SFT/DPO 200 MB, zip multimodal 2 GB, CPT 300 MB.Ação: Faça os ajustes abaixo e tente novamente:

Verifique se o tamanho do arquivo excede o limite do método de treinamento correspondente.
Divida o jsonl em múltiplos arquivos para upload em lotes (SFT/DPO). Dividir dados CPT exige criar múltiplos novos datasets.
Para o método de tratamento de estouro quando um arquivo único excede 300 MB, consulte API upload quota.

Details

Problema: A extensão do arquivo não está na lista supportedExtension, e o frontend exibe um alerta e rejeita o upload.Causa: A extensão deve estar dentro da lista suportada. Treinamento de texto usa jsonl, conjuntos de avaliação usam xlsx, imagens multimodais aceitam bmp/jpeg/jpg/png/tif/tiff/webp, e vídeos multimodais aceitam mp4 e outros formatos.Ação: Faça os ajustes abaixo e tente novamente:

Verifique se a extensão do arquivo está na lista suportada para o cenário correspondente.
Converta o arquivo para uma extensão suportada e reempacote para upload.
Extensões de imagem e vídeo dentro de um zip multimodal devem estar todas em conformidade, caso contrário a importação do pacote inteiro falha.

Details

Problema: Durante o upload via OSS, o arquivo fica com status de erro e o upload não é concluído.Causa: Causas comuns incluem tag de Bucket ausente, autorização de acesso do service Bailian ao OSS anormal ou formato de arquivo não conforme.Ação: Solucione o problema conforme abaixo e tente novamente:

Verifique se o Bucket OSS tem a tag de autorização de acesso a dados do Bailian adicionada.
Confirme que o service Bailian foi autorizado a acessar dados no OSS.
Verifique se o data.jsonl e o formato do arquivo estão em conformidade com as regras de empacotamento e tente o upload novamente. Para detalhes, consulte Multimodal zip package packaging rules.

Aviso de risco de operação irreversível:

Operações de publicação e exclusão são irreversíveis. Versões publicadas não podem ser editadas novamente, e apenas versões em rascunho podem ser excluídas ou editadas online.
O tipo de dataset (conjunto de treinamento/conjunto de avaliação) não pode ser alterado ou trocado após a criação. Selecione o tipo errado exige criar um novo dataset e reimportar todos os dados.
Alterar o tipo de dataset, cenário de treinamento ou método de treinamento limpa os arquivos enviados e redefine o local de armazenamento e o método de importação.

A divisão automática do conjunto de validação extrai aleatoriamente 10% dos dados do conjunto de treinamento para formar o conjunto de validação, reduzindo o volume real de dados de treinamento. Para datasets pequenos, recomenda-se um conjunto de validação independente. Para operações de configuração do conjunto de validação, consulte Fine-tune models in the console. Recomendamos baixe primeiro o modelo de dados do cenário correspondente. Preparar os dados conforme a estrutura do modelo evita falhas de importação. Para recomendações de download de modelos de dados, consulte Overview. A solução de problemas comuns está detalhada nos itens expansíveis abaixo. Para operações de limpeza e aumento de dados em rascunho, consulte ; para domínios de dados de segurança e conformidade, consulte . Quando a validação de upload falhar, acesse a página New Dataset no console para verifique o formato do arquivo e as regras de admissão.

​Visão geral

​Matriz de suporte a métodos de treinamento e elementos

​Geração de texto - Formato SFT

​Regras da tag thinking

​Formato do conjunto de avaliação

​Geração de texto - Formato DPO

​Geração de texto - Formato CPT

​Compreensão visual - Formato SFT

​Descrição do campo tool

​Regras da tag thinking

​Regras de empacotamento zip multimodal

​Limites de tamanho e quantidade de arquivos

​Cota de upload via API

​Validação de upload e erros comuns

Visão geral

Matriz de suporte a métodos de treinamento e elementos

Geração de texto - Formato SFT

Regras da tag thinking

Formato do conjunto de avaliação

Geração de texto - Formato DPO

Geração de texto - Formato CPT

Compreensão visual - Formato SFT

Descrição do campo tool

Regras da tag thinking

Regras de empacotamento zip multimodal

Limites de tamanho e quantidade de arquivos

Cota de upload via API

Validação de upload e erros comuns