Reglas de carga de datos de ajuste fino

Visión general

Este documento describe las especificaciones de formato, los requisitos de empaquetado, los límites de tamaño y cantidad, y las cuotas de carga mediante API para los datos de ajuste fino de modelos de generación de texto. El alcance cubre el ajuste fino de modelos de generación de texto (texto/imagen/video → texto), incluyendo SFT/DPO/CPT de texto plano, comprensión de imágenes y video Qwen VL, extracción de fotogramas de video, llamada de funciones y pensamiento. El ajuste fino de modelos de generación de video (imagen → video) queda fuera del alcance. El tipo de conjunto de datos (conjunto de entrenamiento o conjunto de evaluación) no se puede cambiar después de su creación. El soporte para cada método de entrenamiento y elemento se detalla en Matriz de soporte de métodos y elementos de entrenamiento. Las reglas de construcción de formato para cada combinación se describen en los capítulos correspondientes a continuación.

Las siguientes operaciones son irreversibles; proceda con precaución:

Las versiones publicadas no pueden editarse nuevamente; solo las versiones en borrador creadas previamente pueden eliminarse o editarse en línea.
El tipo de conjunto de datos no se puede cambiar después de su creación.
Cambiar el tipo, el escenario o el método de entrenamiento borra los archivos cargados.

Las operaciones de gestión (parámetros de creación, gestión de versiones, reglas de gestión del conjunto de evaluación, selección del método de importación, limpieza de datos, seguridad y cumplimiento) se tratan en documentos relacionados; consulte Conjunto de entrenamiento y conjunto de evaluación, Introducción al ajuste fino de modelos, etc. Recomendamos descargar la plantilla de datos para el escenario correspondiente en la página de creación del conjunto de datos y preparar los datos según la estructura de la plantilla para evitar fallos de importación. Para recomendaciones sobre la construcción del conjunto de datos (escala de datos recomendada, diversidad y equilibrio, estrategias de aumento de datos), consulte Introducción al ajuste fino de modelos - Consejos para la construcción del conjunto de datos.

Matriz de soporte de métodos y elementos de entrenamiento

El conjunto de entrenamiento admite tres métodos de entrenamiento: SFT, DPO y CPT. El estado de soporte de cada método de entrenamiento y elemento se muestra en la tabla matricial a continuación. El orden de ajuste fino recomendado es CPT (opcional) → SFT → DPO (opcional); los tres son progresivos, no mutuamente excluyentes. Disponibilidad por región:

SFT, la carga local, el retorno de registros, la carga mediante API y los formatos de datos multimodales son compatibles en todas las regiones.
DPO, CPT, la importación de OSS y el montaje de almacenamiento en la nube solo son compatibles en la región de Beijing.

La matriz de soporte de métodos y elementos de entrenamiento es la siguiente:

Método de entrenamiento	Generación de texto	Comprensión visual - Entrada de imagen	Comprensión visual - Entrada de video (qwen3.5+)	Comprensión visual - Llamada a herramientas (qwen3.5+)	Pensamiento profundo
SFT	✓	✓	✓	✓	✓
DPO	✓	✗	✗	✗	✓
CPT	✓	✗	✗	✗	✗
Conjunto de evaluación	✓	✗	✗	✗	✗

Cada método de entrenamiento crea nuevas versiones en modo de creación nueva, lo que requiere volver a importar todos los datos. Para las definiciones de campos de los métodos de entrenamiento SFT/DPO/CPT, consulte Introducción al ajuste fino de modelos.

Generación de texto - Formato SFT

Los datos de entrenamiento de generación de texto SFT utilizan el formato de archivo jsonl, basado en la estructura multiturno messages de ChatML.

Admite tres roles: system, user y assistant. El campo content es una cadena (para la estructura de matriz de contenido en escenarios multimodales, consulte el capítulo de formato multimodal correspondiente).
El tamaño máximo de un archivo individual es de 200 MB.
Un conjunto de datos puede mezclar filas de diferentes formatos: cada registro selecciona un formato de forma independiente, sin necesidad de unificarlos en un solo formato.
Formatos disponibles: diálogo estándar, pensamiento profundo, llamada de funciones y llamada de funciones combinada con pensamiento (consulte las pestañas de ejemplos a continuación).

La generación de texto SFT admite los siguientes formatos de muestra. La estructura JSON completa de cada muestra se muestra en la pestaña correspondiente:

ChatML estándar
Pensamiento profundo (thinking)
Llamada a funciones

Ejemplo de formato ChatML estándar (diálogo multiturno system/user/assistant):

{
  "messages": [
    {"role": "system", "content": "系统输入1"},
    {"role": "user", "content": "用户输入1"},
    {"role": "assistant", "content": "期望的模型输出1"},
    {"role": "user", "content": "用户输入2"},
    {"role": "assistant", "content": "期望的模型输出2"}
  ]
}

Uso avanzado

Se admite el parámetro loss_weight, con un rango de valores de (0.0, 1.0]; cuanto mayor sea el valor, mayor será la importancia de este registro durante el entrenamiento.
Compatible de forma predeterminada en Qwen3.5 y modelos posteriores; para habilitar el soporte en los modelos de las series Qwen3 y Qwen2.5, contacte a su gerente de cuenta.

{"role": "assistant", "content": "期望的模型输出", "loss_weight": "1.0"}

Ejemplo de formato de pensamiento (la etiqueta de pensamiento se coloca en el último mensaje de assistant; se deben conservar los saltos de línea antes y después):

{
  "messages": [
    {"role": "system", "content": "系统输入1"},
    {"role": "user", "content": "用户输入1"},
    {"role": "assistant", "content": "模型输出1"},
    {"role": "user", "content": "用户输入2"},
    {"role": "assistant", "content": "<think>\n期望的思考内容2\n</think>\n\n期望的输出2"}
  ]
}

Reglas de etiquetas de pensamiento

El contenido de pensamiento se envuelve en etiquetas <think>\n…\n</think>\n\n y se coloca dentro del texto de salida del asistente (compartiendo el mismo último contenido del asistente que la respuesta final). Reglas:

Solo se puede colocar en la última salida de assistant; las salidas intermedias de assistant no deben incluir etiquetas de pensamiento.
Se deben conservar los saltos de línea antes y después de la etiqueta de pensamiento.
Si una muestra de entrenamiento está configurada para que el modelo no genere etiquetas de pensamiento, no se recomienda volver a habilitar el modo de pensamiento al llamar al modelo después del entrenamiento.

Formato del conjunto de evaluación

El conjunto de evaluación solo sirve para escenarios de generación de texto y es independiente del método de entrenamiento SFT/DPO/CPT: los modelos entrenados con DPO/CPT también utilizan el conjunto de evaluación de generación de texto para su evaluación, sin distinción por método de entrenamiento. Los conjuntos de evaluación admiten dos formatos de muestra, que se seleccionan en el escenario de entrenamiento del formato de datos al crear el conjunto de datos:

Generación de texto (prompt&completion): formato de una sola vuelta. Cada muestra consta de un Prompt (pregunta del usuario) y una Completion (respuesta de referencia). La carga local solo admite archivos xls y xlsx (hasta 20 MB por archivo); la estructura de columnas se puede consultar en la plantilla de datos proporcionada por la consola.
Generación de texto (ChatML-messages): formato de conversación multivuelta. Cada muestra es un array de messages compuesto por mensajes de los roles system, user y assistant, y la respuesta de referencia es el último mensaje de assistant en messages. La carga local admite archivos jsonl, xls y xlsx (hasta 200 MB por archivo); se puede descargar un archivo de muestra al crear el conjunto de datos.

En el formato ChatML, cada línea es una muestra jsonl, y las muestras de una sola vuelta y multivuelta se pueden mezclar, como se muestra a continuación:

{"messages": [{"role": "system", "content": "You are a helpful assistant"}, {"role": "user", "content": "谁在文艺复兴时期绘制人体?"}, {"role": "assistant", "content": "文艺复兴时期是一个关于艺术、文化和学术的复兴运动，在这个时期，许多艺术家都绘制了人体。"}]}
{"messages": [{"role": "system", "content": "You are a helpful assistant"}, {"role": "user", "content": "谁在文艺复兴时期绘制人体?"}, {"role": "assistant", "content": "文艺复兴时期是一个关于艺术、文化和学术的复兴运动，在这个时期，许多艺术家都绘制了人体。"},{"role": "user", "content": "那雕塑方面如何呢？"}, {"role": "assistant", "content": "文艺复兴时期的雕塑也非常有名，几位世界级的雕塑大师都出自于这个时期"}]}

Descripción de los campos del formato ChatML:

messages: el array de mensajes. El mensaje de system es opcional y se coloca en primer lugar; los mensajes de user y assistant se alternan; en las conversaciones multivuelta se siguen añadiendo pares de mensajes user/assistant, y el último mensaje de assistant es la respuesta de referencia de la muestra.
El content de un mensaje de assistant puede contener contenido de pensamiento del modelo: el texto de pensamiento se coloca antes de la respuesta y se separa con el marcador </think> (se utiliza al evaluar modelos de razonamiento).
extra: un campo de extensión personalizado opcional que admite tipos como objetos, arrays y valores numéricos, que puede utilizar para adjuntar datos personalizados a las muestras según las necesidades del negocio.

Especificaciones del conjunto de evaluación:

Métodos de ingesta: carga local y retorno de registros; no se admiten la importación de Object Storage Service (OSS) ni el montaje de almacenamiento en la nube.
Solo las versiones en borrador creadas previamente admiten la edición en línea (Prompt/Completion); las versiones publicadas no se pueden editar.
En los conjuntos de datos ChatML, la vista previa del archivo en la página de detalles del conjunto de datos muestra el contenido completo de messages de cada muestra jsonl.

Límites de ingesta de retorno de registros:

El rango de registros admitido abarca los últimos 30 días.
Máximo de 100,000 registros por importación.
Debe autorizar el rol vinculado al servicio y especificar la API Key y las condiciones de filtro del modelo.
El conjunto de entrenamiento solo está disponible para escenarios de generación de texto SFT (también se admite el conjunto de evaluación de generación de texto).

Para obtener detalles sobre el método de ingesta de retorno de registros, consulteRetorno de registros. El conjunto de evaluación debe ser una colección independiente de datos sin superposición, utilizada para evaluar objetivamente la capacidad de generalización del modelo. Para las reglas de gestión del conjunto de evaluación, consulteConjunto de entrenamiento y conjunto de evaluación.

Generación de texto - Formato DPO

Los datos de entrenamiento de generación de texto DPO utilizan el formato jsonl. Basándose en la estructura multiturno messages de ChatML, contiene adicionalmente dos salidas de assistant contrastantes, chosen y rejected, para el entrenamiento de alineación de preferencias. Todo el contenido dentro de messages se utiliza como entrada, y DPO se usa para entrenar la retroalimentación positiva/negativa del modelo sobre la última entrada del usuario. Para las reglas de la estructura multiturno de messages, consulte Generación de texto - Formato SFT. Para el contenido de pensamiento profundo, la salida de assistant elegida o rechazada puede envolverse con etiquetas de pensamiento. La etiqueta de pensamiento solo puede colocarse en la última línea de assistant. Para las reglas, consulte Generación de texto - Formato SFT. El parámetro loss_weight (solo por invitación) admite el módulo chosen. El rango de valores es de 0.0 a 1.0; cuanto mayor sea el valor, mayor será la importancia del entrenamiento. Para más detalles, consulte Generación de texto - Formato SFT. El límite de tamaño de archivo individual para los datos de entrenamiento DPO es de 200 MB, consistente con la generación de texto SFT. Para la definición de DPO, consulte Introducción al ajuste fino de modelos. Para la gestión de versiones y las operaciones de publicación, consulte Conjunto de entrenamiento y conjunto de evaluación. Consulte el bloque de código a continuación para ver una muestra de datos de entrenamiento de generación de texto DPO:

ChatML estándar
Pensamiento profundo (thinking)

Ejemplo de formato estándar de comparación chosen/rejected (dos salidas de assistant contrastantes):

{
  "messages": [
    {"role": "system", "content": "系统输入"},
    {"role": "user", "content": "用户输入1"},
    {"role": "assistant", "content": "模型输出1"},
    {"role": "user", "content": "用户输入2"},
    {"role": "assistant", "content": "模型输出2"},
    {"role": "user", "content": "用户输入3"}
  ],
  "chosen": {"role": "assistant", "content": "赞同的模型期望输出3"},
  "rejected": {"role": "assistant", "content": "反对的模型期望输出3"}
}

Ejemplo de formato de etiqueta de pensamiento (el contenido de pensamiento profundo se envuelve con etiquetas de pensamiento, colocado en el último assistant):

{
  "messages": [
    {"role": "system", "content": "系统输入"},
    {"role": "user", "content": "用户输入1"},
    {"role": "assistant", "content": "模型输出1"},
    {"role": "user", "content": "用户输入2"}
  ],
  "chosen": {"role": "assistant", "content": "<think>\n期望的思考内容\n</think>\n\n期望的模型输出"},
  "rejected": {"role": "assistant", "content": "反对的模型期望输出2"}
}

Generación de texto - Formato CPT

Los datos de entrenamiento de generación de texto CPT utilizan el formato de texto plano jsonl, con un objeto jsonl por línea, estructurado como {text}, donde el campo text es contenido de texto plano. Para las reglas de la estructura multiturno de messages, consulte Generación de texto - Formato SFT. Restricciones de datos de entrenamiento CPT:

Se recomienda un mínimo de 50 millones de Tokens, y el límite de tamaño de archivo individual es de 300 MB.

Para la definición de CPT, consulte Introducción al ajuste fino de modelos; para la gestión de versiones y las operaciones de publicación, consulte Conjunto de entrenamiento y conjunto de evaluación. La estructura JSON completa de una muestra de texto plano CPT se muestra en el bloque de código a continuación. {text} ejemplo de formato de texto plano (un objeto jsonl de texto plano por línea):

{
  "text": "文本内容"
}

Comprensión visual - Formato SFT

Los datos de entrenamiento de imágenes SFT se utilizan para la comprensión multimodal Qwen VL (la opción de la interfaz de la consola es "Image Understanding"). Utilizan un formato de paquete zip que contiene un archivo de datos de texto de entrenamiento data.jsonl y archivos de imagen. data.jsonl debe colocarse en la raíz del paquete. Los messages de cada registro de entrenamiento en data.jsonl adoptan una estructura de matriz content, cuyos elementos contienen un campo de imagen (image) y un campo de texto (text). Se recomienda una estructura de directorios de una sola capa. Para las reglas de empaquetado, consulte Reglas de empaquetado de paquetes zip multimodales.

Límites de entrada de imagen
Límites de entrada de video

Los límites de admisión de imágenes son los siguientes:

El ancho y el alto de una sola imagen no deben exceder 1024 px.
Una sola imagen no debe exceder 10 MB.
Formatos admitidos: bmp, jpeg, jpg, png, tif, tiff, webp.

resized_width y resized_height son parámetros opcionales de control del escalado objetivo, utilizados para especificar las dimensiones de escalado objetivo de la imagen; no son el límite superior de admisión de imágenes. El límite superior de admisión de imágenes es que el ancho y el alto no excedan 1024 px y que una sola imagen no exceda 10 MB. Los valores específicos de admisión de imágenes están sujetos a lo que se muestre realmente en la consola.Para el cálculo del consumo de tokens de las imágenes, consulte Comprensión de imágenes y video - Facturación y límites de tasa.

Solo es compatible con modelos multimodales qwen3.5 y posteriores. Se admiten dos modos de entrada de video:

Modo de ruta de archivo de video: el campo video es una cadena (por ejemplo, "video1.mp4"), y la extracción de fotogramas la gestiona la plataforma. Adecuado para escenarios que utilizan archivos de video completos.
Modo de lista de fotogramas de imagen: el campo video es una lista de nombres de archivos de imagen (por ejemplo, ["0.jpg","1.jpg"]), y el usuario prepara la secuencia de fotogramas. Adecuado para escenarios donde ya existen imágenes de fotogramas extraídos.

Las imágenes y los videos de los datos de entrenamiento también deben satisfacer los límites de entrada de las llamadas al modelo (como la resolución de imagen, la duración del video, la tasa de fotogramas, etc.). Para los límites de llamada, consulte Límites de video.

Para el cálculo del consumo de tokens de los videos, consulte Comprensión de imágenes y video - Facturación y límites de tasa.La comparación de campos y los ejemplos de los dos modos se muestran a continuación:

Campo/Parámetro	Modo de ruta de archivo de video	Modo de lista de fotogramas de imagen
video	str (ruta del archivo de video, obligatorio)	List[str] (lista de fotogramas de imagen, obligatorio)
sample_fps	N/A	float ([0.1, 10], valor predeterminado 2.0, opcional)
fps	float ([0.1, 10], valor predeterminado 2.0, opcional)	N/A
resized_width	int (ancho de escalado, opcional)	int (ancho de escalado, opcional)
resized_height	int (alto de escalado, opcional)	int (alto de escalado, opcional)
video_start	float (tiempo de inicio del clip, opcional)	N/A
video_end	float (tiempo de fin del clip, opcional)	N/A

Los ejemplos de entrenamiento de imágenes SFT se muestran en las pestañas siguientes:

Ejemplo de formato ChatML estándar (diálogo multiturno system/user/assistant):

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入1"}]},
    {"role": "user", "content": [{"text": "用户输入1"}]},
    {"role": "assistant", "content": [{"text": "期望的模型输出1"}]},
    {"role": "user", "content": [{"text": "用户输入2"}]},
    {"role": "assistant", "content": [{"text": "期望的模型输出2"}]}
  ]
}

Ejemplo de formato de pensamiento (thinking) (la etiqueta de pensamiento se coloca en el último mensaje de assistant; se deben conservar los saltos de línea antes y después):

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入1"}]},
    {"role": "user", "content": [{"text": "用户输入1"}]},
    {"role": "assistant", "content": [{"text": "模型输出1"}]},
    {"role": "user", "content": [{"text": "用户输入2"}]},
    {"role": "assistant", "content": [{"text": "<think>\n期望的思考内容2\n</think>\n\n期望的输出2"}]}
  ]
}

Los modos qwen3.5+ admiten el uso del formato de datos de llamada a funciones.

Ejemplo de formato de llamada a funciones (function calling) (definiciones de tools + mensajes multiturno que contienen el rol tool, con tool_call_id en correspondencia uno a uno):

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "查询指定城市的实时天气",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {"type": "string", "description": "城市名称，例如：北京"}
          },
          "required": ["city"]
        }
      }
    }
  ],
  "messages": [
    {"role": "user", "content": [{"text": "帮我查一下北京的天气"}]},
    {
      "role": "assistant",
      "content": [{"text": "好的，我来帮您查询北京的天气。"}],
      "tool_calls": [
        {
          "id": "call_3a11c1ba883b41b6a4e0cb",
          "type": "function",
          "function": {
            "name": "get_weather",
            "arguments": "{\"city\": \"北京\"}"
          }
        }
      ]
    },
    {"role": "tool", "tool_call_id": "call_3a11c1ba883b41b6a4e0cb", "content": [{"text": "{\"city\": \"北京\", \"weather\": \"晴\", \"temperature\": \"25℃\"}"}]},
    {"role": "assistant", "content": [{"text": "北京今天天气晴朗，气温 25℃，适合出行。"}]}
  ]
}

Ejemplo de formato de imagen más texto (la matriz content contiene elementos de imagen y elementos de texto):

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入"}]},
    {
      "role": "user",
      "content": [
        {"text": "用户输入1"},
        {"image": "图像文件名1.jpg", "resized_width": 200, "resized_height": 200}
      ]
    },
    {"role": "assistant", "content": [{"text": "期望的模型输出1"}]}
  ]
}

Ejemplo de formato del modo de ruta de archivo de video (el campo video es una cadena de ruta de archivo de video):

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入"}]},
    {
      "role": "user",
      "content": [
        {"text": "用户输入1"},
        {"video": "视频文件名1.mp4", "fps": 3.0, "resized_width": 200, "resized_height": 200, "video_start": 0.0, "video_end": 3.0}
      ]
    },
    {"role": "assistant", "content": [{"text": "期望的模型输出1"}]}
  ]
}

Ejemplo de formato del modo de lista de fotogramas de imagen (video es una lista de fotogramas, que contiene sample_fps):

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入"}]},
    {
      "role": "user",
      "content": [
        {"text": "用户输入2"},
        {"video": ["0.jpg", "1.jpg", "2.jpg", "3.jpg"], "sample_fps": 5.0, "resized_width": 200, "resized_height": 200}
      ]
    },
    {"role": "assistant", "content": [{"text": "期望的模型输出2"}]}
  ]
}

Para la definición de comprensión multimodal, consulte Introducción al ajuste fino de modelos.

Reglas del formato de llamada a funciones

El modo de llamada de funciones agrega definiciones de tools y el mecanismo tool_calls/role:tool sobre la estructura de mensajes multiturno. Las restricciones de campos son las siguientes:

tools: matriz de definiciones de herramientas; cada elemento contiene type:"function" y function{name, description, parameters}; parameters es un JSON Schema (que contiene type/properties/required).
messages: matriz de diálogo multiturno; los roles incluyen user, assistant y tool.
content: matriz de contenido multimodal; puede contener elementos de imagen, texto, video y otros (consistente con el formato de comprensión multimodal).
assistant.tool_calls: matriz de llamadas a herramientas generada por el modelo; contiene id, type:"function", function{name, arguments}; arguments es una cadena JSON.
role:"tool": retorno de la herramienta; tool_call_id debe corresponder uno a uno con el tool_calls[].id correspondiente; content contiene el resultado del retorno de la herramienta.

El último mensaje de un diálogo multiturno suele ser la respuesta final del asistente basada en el retorno de la herramienta. Bailian no admite los parámetros name y weight de OpenAI; todas las salidas del asistente se entrenarán. Los datos de entrenamiento migrados desde OpenAI/Azure no deben incluir los campos name/weight. Recomendaciones de diversidad y equilibrio de datos: la cantidad de datos de cada escenario debe estar relativamente equilibrada, y la proporción de datos debe coincidir con la proporción del escenario real. Evite un exceso de un tipo de dato, ya que esto provocaría que el modelo tienda a aprender ese tipo de características y afectaría su capacidad de generalización.

Reglas de etiquetas de pensamiento

El contenido de pensamiento se envuelve en etiquetas <think>\n…\n</think>\n\n y se coloca dentro del texto de salida del asistente (perteneciente al mismo último contenido del asistente que la respuesta final). Reglas:

Debe colocarse únicamente en la última salida de assistant; las salidas intermedias de assistant no agregan etiquetas de pensamiento.
Se deben conservar los saltos de línea antes y después de las etiquetas de pensamiento.
Si las muestras de entrenamiento configuran el modelo para no generar etiquetas de pensamiento, una vez finalizado el entrenamiento no se recomienda habilitar el modo de pensamiento para las llamadas.

Reglas de empaquetado de paquetes zip multimodales

Los datos de entrenamiento de comprensión multimodal se cargan como un paquete zip a través de la página Agregar conjunto de datos. El empaquetado debe cumplir las siguientes restricciones:

El paquete zip admite hasta 2 GB.
El conjunto de caracteres permitido para los nombres de carpetas y archivos dentro del paquete son letras ASCII (a-z, A-Z), dígitos (0-9), guiones bajos (_) y guiones (-).
El archivo de datos de texto de entrenamiento es fijo como data.jsonl y debe ubicarse en el directorio raíz del paquete zip: asegúrese de que, tras la extracción, al abrir el archivo zip se muestre directamente data.jsonl, sin ninguna carpeta externa adicional que lo envuelva.

Los nombres de los archivos de imagen o video deben ser globalmente únicos dentro del paquete zip, incluso si están distribuidos en diferentes carpetas. Dentro de data.jsonl, solo es necesario declarar el nombre del archivo en lugar de la ruta del archivo; ejemplo correcto: image1.jpg; ejemplo incorrecto: jpg_folder/image1.jpg. El montaje de almacenamiento en la nube no admite paquetes zip. Al cargar un conjunto de datos mediante montaje de almacenamiento en la nube, debe cargar la carpeta del conjunto de datos sin comprimir en su totalidad al OSS Bucket y especificar la ruta del archivo data.jsonl mediante file_path de MountStorage; cuando se incluyen varios archivos, solo es necesario especificar la ruta de data.jsonl, y los demás archivos del mismo directorio se montan automáticamente. Para obtener detalles sobre el montaje de almacenamiento en la nube, consulte Ajuste fino mediante API o CLI. Los ejemplos de nomenclatura y la estructura de directorios se muestran en el bloque de código a continuación. Para las operaciones de autorización del montaje de almacenamiento en la nube, consulte Ajuste fino de modelos en la consola; para las operaciones de etiquetado de importación de OSS Bucket, consulte Conjunto de entrenamiento y conjunto de evaluación.

# 单层目录（推荐）
Trainingdata_vl.zip
  |--- data.jsonl        # 必须在根目录，外层不再包裹文件夹
  |--- image1.png
  |--- video1.mp4

# data.jsonl 内声明文件名（非路径）
# 正确：image1.jpg
# 错误：jpg_folder/image1.jpg

Vaya a la página de la consola Crear conjunto de datos para cargar el paquete zip multimodal y completar la validación del empaquetado.

Límites de tamaño y cantidad de archivos

Los límites superiores del tamaño y la cantidad de archivos de carga local se establecen según el método de entrenamiento y el escenario, como se detalla en la tabla específica del escenario a continuación. Para los límites de admisión de imágenes, consulte Comprensión visual - Formato SFT; para los límites de formato del conjunto de evaluación, consulte Formato del conjunto de evaluación; para los límites de ingesta de retorno de registros, consulte Formato del conjunto de evaluación. max_length toma valores en el rango de 500 a 131072 como parámetro de configuración de longitud de secuencia de entrenamiento, no como límite superior de admisión de carga. El límite superior del tamaño de admisión de un solo registro de datos de entrenamiento está sujeto a lo que se muestre en la página de la consola. Los límites superiores del tamaño y la cantidad de archivos de carga local se establecen según el método y el escenario de entrenamiento. El volumen de datos recomendado es el valor mínimo sugerido:

Método de entrenamiento/escenario	Tamaño máximo de archivo individual	Recuento máximo de archivos (maxCount)	Volumen de datos recomendado
Generación de texto - Formato SFT	200 MB	10 (predeterminado)	Al menos miles de muestras
Generación de texto - Formato DPO	200 MB	10 (predeterminado)	Al menos cientos de muestras
Generación de texto - Formato CPT	300 MB	1	Al menos 50 millones de Tokens
Multimodal (zip)	2 GB	1	Prepare muestras suficientes según los escenarios reales
Nombre de archivo (sin extensión)	≤120 caracteres y único	—	—
Extensión	Debe estar en la lista Crear conjunto de datos	—	—

Cuota de carga de API

La cuota para cargar archivos de ajuste fino mediante la API de DashScope (con purpose etiquetado como ajuste fino de modelo) se muestra en la tabla de cuotas a continuación. Al crear un conjunto de datos en la consola, la lista de la File API admite fusionar y registrar hasta 10 archivos; los archivos de ajuste fino cargados mediante la API son visibles y utilizables tanto en la página de ajuste fino de modelos de la consola como en las llamadas a la API. Restricciones para cargar conjuntos de datos mediante montaje de almacenamiento en la nube:

Especifique la ruta del manifiesto del directorio raíz data.jsonl mediante file_path de MountStorage; no se admiten archivos zip.
Antes de realizar el montaje, debe autorizar al servicio Bailian para acceder a los datos de OSS.

Manejo de desbordamiento y cifrado:

Archivo individual que supera los 300 MB: cargue mediante el montaje de almacenamiento en la nube o el canal ZIP multimodal de 2 GB.
Cuota total superada: elimine archivos históricos para liberar espacio.
Los datos importados habilitan automáticamente el cifrado del lado del servidor de OSS (SSE-OSS, AES256).

Para obtener detalles sobre las llamadas a la API, la autenticación, el SDK, los códigos de error y los campos de MountStorage, consulte Ajuste fino mediante API o CLI. La cuota para cargar archivos de ajuste fino mediante la API es la siguiente:

Elemento de cuota	Límite	Descripción
Tamaño de archivo individual	Hasta 300 MB	Archivos de ajuste fino (para el propósito de ajuste fino de modelos)
Espacio total de archivos válidos	100 GB	Acumulado de archivos no eliminados
Recuento total de archivos válidos	10000	Acumulado de archivos no eliminados
Duración de almacenamiento de archivos	Sin límite de tiempo	No caduca automáticamente
Límite superior de la lista de la File API	10	Registro combinado al crear un conjunto de datos en la consola

Las diferencias entre la importación de OSS y el montaje de almacenamiento en la nube se comparan a continuación:

Dimensión	Importación OSS	Montaje de almacenamiento en la nube
Requisito previo	Etiqueta de autorización de acceso a datos de Bailian	Autorizar al servicio Bailian para acceder a los datos de OSS
Forma de los datos	Archivos individuales o por lotes	Carpeta completa del conjunto de datos sin comprimir (no se admite zip)
Entrada	Gestión de datos > Nuevo conjunto de datos > Importación de OSS	Ajuste fino de modelos > Crear tarea de entrenamiento > Configuración de datos > Montaje del conjunto de datos
Conjunto de evaluación	✗	✗

Validación de carga y errores comunes

Al cargar archivos localmente en la página Agregar conjunto de datos, la validación de la interfaz rechaza los archivos que no cumplen las reglas de admisión y muestra un aviso. Los rechazos de validación comunes y los escenarios de error de carga se muestran en los elementos desplegables a continuación:

Problema: Al cargar archivos, la interfaz indica que el recuento de archivos supera el límite superior y los archivos son rechazados.

Diagnóstico:maxCount se establece según el método de entrenamiento: el texto SFT/DPO tiene un valor predeterminado de 10, y el zip multimodal y CPT tienen un valor predeterminado de 1. La carga de archivos que superen el límite superior del método de entrenamiento correspondiente será rechazada por la interfaz.Acción:Ajuste de la siguiente manera y vuelva a cargar:

Verifique el límite superior de maxCount correspondiente al método de entrenamiento actual; para más detalles, consulte Límites de tamaño y cantidad de archivos.
Reduzca el recuento de archivos para que esté dentro del límite superior; combine los datos multimodales en un solo zip y los datos CPT en un solo jsonl.
Si el recuento de archivos aún supera el límite, divídalo en varios conjuntos de datos y cárguelos por lotes.

Problema: La longitud del nombre del archivo (sin incluir la extensión) supera los 120 caracteres y la interfaz rechaza la carga.

Diagnóstico:El nombre del archivo sin la extensión tiene un límite superior de 120 caracteres y debe contener únicamente letras ASCII, dígitos, guiones bajos y guiones.Acción:Ajuste de la siguiente manera y vuelva a cargar:

Cambie el nombre del archivo para que el nombre (sin incluir la extensión) se reduzca a un máximo de 120 caracteres.
Utilice únicamente caracteres a-z/A-Z/0-9/_/-; elimine los caracteres chinos y otros caracteres no ASCII.
Los nombres de archivo dentro de un paquete multimodal también deben ser globalmente únicos.

Problema: Los nombres de archivo están duplicados (la comparación excluye la extensión) y la interfaz rechaza la carga.

Diagnóstico:Los nombres de archivo dentro del mismo conjunto de datos deben ser únicos sin incluir la extensión; la comparación ignora la extensión.Acción:Ajuste de la siguiente manera y vuelva a cargar:

Busque archivos con nombres duplicados y cámbieles el nombre para que la parte sin la extensión sea única.
Los archivos con el mismo nombre pero diferente extensión (por ejemplo, image.jpg e image.png) también se consideran duplicados y deben diferenciarse simultáneamente.
Los nombres de archivo dentro de un zip multimodal deben ser globalmente únicos, incluso si están distribuidos en diferentes carpetas.

Problema: El tamaño del archivo individual supera el límite superior del método de entrenamiento correspondiente y la interfaz rechaza la carga.

Diagnóstico:El límite superior del tamaño de archivo individual varía según el escenario del método de entrenamiento: texto SFT/DPO 200 MB, zip multimodal 2 GB, CPT 300 MB.Acción:Ajuste de la siguiente manera y vuelva a cargar:

Compruebe si el tamaño del archivo supera el límite superior del método de entrenamiento correspondiente.
Divida el jsonl en varios archivos para la carga por lotes (SFT/DPO); la división de datos CPT requiere crear varios conjuntos de datos nuevos.
Para el método de manejo de desbordamiento cuando un solo archivo supera los 300 MB, consulte Cuota de carga de API.

Problema: La extensión del archivo no está en la lista supportedExtension y la interfaz muestra una advertencia y rechaza la carga.

Diagnóstico:La extensión debe estar dentro de la lista admitida: el entrenamiento de texto usa jsonl, los conjuntos de evaluación varían según el formato de muestra (prompt&completion usa xls/xlsx y ChatML-messages admite jsonl/xls/xlsx), las imágenes multimodales admiten bmp/jpeg/jpg/png/tif/tiff/webp, y los videos multimodales admiten mp4 y otros formatos.Acción:Ajuste de la siguiente manera y vuelva a cargar:

Compruebe si la extensión del archivo está dentro de la lista admitida para el escenario correspondiente.
Convierta el archivo a una extensión admitida y vuelva a empaquetarlo para su carga.
Las extensiones de imagen y video dentro de un zip multimodal deben cumplir cada una con los requisitos; de lo contrario, fallará la importación de todo el paquete.

Problema: Durante la carga de OSS, el archivo se establece en estado de error y la carga no se completa.

Diagnóstico:Las causas comunes son la falta de la etiqueta del Bucket, una autorización anómala de acceso a OSS del servicio Bailian o un formato de archivo no conforme.Acción:Solucione el problema de la siguiente manera y reintente:

Verifique que el Bucket de OSS tenga agregada la etiqueta de autorización de acceso a datos de Bailian.
Confirme que se ha autorizado al servicio Bailian para acceder a los datos de OSS.
Verifique que data.jsonl y el formato de archivo cumplan con las reglas de empaquetado y reintente la carga; para más detalles, consulte Reglas de empaquetado de paquetes zip multimodales.

Aviso de riesgo de operación irreversible:

Las operaciones de publicación y eliminación son irreversibles; las versiones publicadas no pueden editarse nuevamente, y solo las versiones en borrador pueden eliminarse o editarse en línea.
El tipo de conjunto de datos (conjunto de entrenamiento/conjunto de evaluación) no se puede cambiar ni intercambiarse después de su creación; si se selecciona el incorrecto, es necesario crear un nuevo conjunto de datos y volver a importar todos los datos.
Cambiar el tipo de conjunto de datos, el escenario de entrenamiento o el método de entrenamiento borra los archivos cargados y restablece la ubicación de almacenamiento y el método de importación.

La división automática del conjunto de validación extrae aleatoriamente el 10% de los datos del conjunto de entrenamiento como conjunto de validación, lo que reduce el volumen real de datos de entrenamiento. Para conjuntos de datos pequeños, se recomienda un conjunto de validación independiente; para las operaciones de configuración del conjunto de validación, consulte Ajuste fino de modelos en la consola. Se recomienda descargar primero la plantilla de datos para el escenario correspondiente; preparar los datos según la estructura de la plantilla puede evitar fallos de importación. Para las recomendaciones de descarga de plantillas de datos, consulte Visión general. La resolución de problemas comunes se detalla en los elementos desplegables a continuación. Para las operaciones de limpieza y aumento de datos en borrador, consulte , y para los dominios de datos de seguridad y cumplimiento, consulte . Cuando falle la validación de carga, vaya a la página de la consola Nuevo conjunto de datos para verificar el formato del archivo y las reglas de admisión.

​Visión general

​Matriz de soporte de métodos y elementos de entrenamiento

​Generación de texto - Formato SFT

Uso avanzado

​Reglas de etiquetas de pensamiento

​Formato del conjunto de evaluación

​Generación de texto - Formato DPO

​Generación de texto - Formato CPT

​Comprensión visual - Formato SFT

​Reglas del formato de llamada a funciones

​Reglas de etiquetas de pensamiento

​Reglas de empaquetado de paquetes zip multimodales

​Límites de tamaño y cantidad de archivos

​Cuota de carga de API

​Validación de carga y errores comunes

Visión general

Matriz de soporte de métodos y elementos de entrenamiento

Generación de texto - Formato SFT

Reglas de etiquetas de pensamiento

Formato del conjunto de evaluación

Generación de texto - Formato DPO

Generación de texto - Formato CPT

Comprensión visual - Formato SFT

Reglas del formato de llamada a funciones

Reglas de etiquetas de pensamiento

Reglas de empaquetado de paquetes zip multimodales

Límites de tamaño y cantidad de archivos

Cuota de carga de API

Validación de carga y errores comunes