Automatic learning engine device based on encapsulated large model training platform

Abstract

The present invention provides an automatic learning engine device based on an encapsulated large model training platform, including: a unified access specification module, which standardizes the training and reasoning parameter configuration through a YAML configuration template file; a multi-device support and parallel computing framework module, which is compatible with three hardware devices: CPU, GPU, and NPU, and supports two parallel computing frameworks: Accelerate and DeepSpeed; a training engine module, which uses a three-tier architecture to implement task allocation, status monitoring, and exception handling; a training algorithm framework module, which is used to parse run configuration files, split data sets, convert data formats, support multiple fine-tuning training methods, and evaluate models. The overall solution of the present invention lowers the technical threshold for fine-tuning large models, allowing non-professionals to complete complex model training tasks through simple configuration, thereby promoting the popularization and application of large model technology.

Description

Technical Field

[0001] The present invention relates to the field of artificial intelligence technology, and in particular to an automatic learning engine device based on an encapsulated large model training platform. Background Art

[0002] With the current rapid development of artificial intelligence, particularly natural language processing (NLP), large language models (LLMs) have become a core engine driving technological innovation and industrial transformation. With the emergence of open-source or semi-open-source large language models such as GPT, LLaMA, and Qwen, these models, with their powerful language understanding and generation capabilities, are being widely adopted across industries. However, these pre-trained models are often general-purpose and require fine-tuning for specific domains or tasks to achieve optimal performance. The complexity, resource consumption, and technical barriers to fine-tuning are key factors hindering the widespread adoption of large models. Various open-source large models on the market have unique interface designs, parameter configurations, and training requirements. This diversity makes efficient integration and adaptation of these models in private enterprise environments extremely challenging. Furthermore, the computing resources required to train large models are often enormous, and achieving efficient training within limited hardware conditions is a pressing issue.

[0003] Traditional large-model fine-tuning deployment solutions typically involve specialized code development and adaptation for individual models. Technical teams need to conduct in-depth research on each model's architectural characteristics, interface design, and training methods, writing extensive custom code to implement model loading, training, and inference. This approach not only leads to lengthy development cycles but also creates problems such as code duplication and maintenance difficulties. When supporting new models or updating existing models, code often needs to be rewritten or significantly modified. The lack of a unified standard configuration method makes smooth switching between models difficult. In terms of training resource scheduling, existing solutions generally lack flexible multi-device support, making it difficult to automatically select the optimal parallel computing strategy based on task characteristics and hardware conditions. Furthermore, key aspects of the fine-tuning training process, such as exception handling, status monitoring, and result evaluation, lack systematic and standardized solutions, relying instead on extensive manual intervention and empirical judgment.

[0004] These technical challenges have had serious consequences: First, the application threshold of large-scale model technology remains high, making it difficult for small and medium-sized enterprises and research institutions to afford the high R&D costs, hindering the widespread adoption of AI technology. Second, low development efficiency and high maintenance costs require technical teams to invest considerable time and energy in repetitive engineering adaptation rather than business innovation. Third, computing resources are underutilized, and low training efficiency not only prolongs the model development cycle but also increases hardware investment costs. Fourth, model quality is difficult to ensure, and the lack of a standardized evaluation process leads to unstable fine-tuning results. Finally, insufficient system reliability and frequent training task failures reduce the success rate of large-scale model projects. These issues collectively constitute bottlenecks hindering the in-depth application and industrialization of AI technology. Summary of the Invention

[0005] To overcome the shortcomings of the existing technology, the present invention proposes an automatic learning engine device based on an encapsulated large model training platform. It defines training parameters through a unified YAML configuration template, standardizes the access process of different large models, and eliminates the need for developers to write special code for each model, significantly simplifying the development workflow.

[0006] To achieve the above objectives, the present invention proposes an automatic learning engine device based on an encapsulated large model training platform, comprising:

[0007] A unified access specification module that standardizes training and inference parameter configurations through YAML configuration template files. The YAML configuration template files follow the naming convention of "ai.config.train.<model name encoding>.<scenario name>.yaml", where the model name encoding is the encoding corresponding to the large model selected by the user, and the scenario name is fine-tuning (sft), pre-training (pt), or reward model training (rm);

[0008] Multi-device support and parallel computing framework module, which is compatible with three hardware devices: CPU, GPU, and NPU, and supports two parallel computing frameworks: Accelerate and DeepSpeed. It automatically generates corresponding training start commands based on the user's selected operation type and parallel framework;

[0009] The training engine module uses a three-tiered Master-Driver-Worker architecture to implement task allocation, status monitoring, and exception handling. The Master is responsible for receiving task messages and starting containers, the Driver is responsible for monitoring the Worker status and writing back the results, and the Worker is responsible for executing fine-tuning training tasks.

[0010] The training algorithm framework module is used to parse the ai.envs.train.yaml operation configuration file, split the data set, convert the data format, support multiple fine-tuning training methods, and evaluate the model.

[0011] Furthermore, the YAML configuration template file in the unified access specification module includes the following five parts:

[0012] The runtime part is used to describe the algorithm runtime environment configuration, including:

[0013] The type field indicates the operation type, which can be single machine single card (SMSG), single machine multiple cards (SMMG), or multiple machines multiple cards (MMMG);

[0014] The parallel_framework field indicates the parallel computing framework, which can be accelerate or deepspeed;

[0015] The workspace field indicates the working directory path;

[0016] The cmd field indicates the algorithm execution command list;

[0017] The options section is used to describe the algorithm running hyperparameters and contains multiple hyperparameter objects, each of which has:

[0018] The code field indicates the hyperparameter code;

[0019] The name field indicates the hyperparameter display name;

[0020] The type field indicates the hyperparameter data type;

[0021] The display field indicates whether the hyperparameters are displayed;

[0022] The default field indicates the default value of the hyperparameter;

[0023] The desc field indicates the hyperparameter description;

[0024] The rule field is used to define the enumeration value or value range of the hyperparameter;

[0025] The inputs section defines the input resources required by the algorithm, including training data, evaluation data, and basic models. Each input resource has:

[0026] The name field indicates the resource name;

[0027] The code field indicates the resource code;

[0028] The oid field indicates the original code / ID;

[0029] The type field indicates the resource type, and its value is dataset, datasource, or model;

[0030] The label field indicates the resource label;

[0031] The accessType field indicates the access type, with values ​​of local or remote;

[0032] uri field, indicating the uniform resource identifier;

[0033] The evalScale field indicates the evaluation data scale;

[0034] The outputs section defines the output results of the training process, including the model (main), tensorboard visualization results, checkpoint checkpoints, and task_result task results. Each output item has name, code, oid, type, accessType, and uri fields;

[0035] The logs section is used to define the storage information of the logs, including the name, code, type, accessType, and uri fields.

[0036] Furthermore, the unified access specification module also includes a YAML configuration template file parser, which is specifically used to:

[0037] Read the YAML file and parse it into nested dictionaries and lists using Python's yaml library, parsing the runtime, options, inputs, outputs, and logs sections layer by layer.

[0038] Verify the data type and value range of each parameter to ensure that the parameters meet expectations, including ensuring that runtime.type must be one of SMSG, SMMG, or MMMG, and parallel_framework must be accelerate or deepspeed;

[0039] Automatically fill in default values ​​for parameters not explicitly specified in the YAML file, including default values ​​for hyperparameters in options;

[0040] When a user creates a fine-tuning task, the system reads the corresponding YAML template file based on the model and scenario selected by the user, and dynamically generates the runtime YAML file ai.envs.train.yaml, merging the user-defined hyperparameters with other configuration items in the template file.

[0041] Ensure that the generated runtime YAML file is correctly loaded into the container by mounting when the task is started for use in the fine-tuning algorithm.

[0042] Furthermore, the multi-device support and parallel computing framework module specifically includes:

[0043] The device adapter component is used to build corresponding container images for three different hardware devices: CPU, GPU, and NPU. The image address is configured in the YAML template file to ensure efficient operation in different operating environments.

[0044] Parallel computing support components, specifically supporting:

[0045] The Accelerate framework provides four functions: device management, mixed-precision training, distributed training, and gradient accumulation;

[0046] DeepSpeed ​​framework, which provides six features: device management, mixed-precision training, gradient accumulation, Zero Redundancy Optimizer (ZeRO), model parallelism, and checkpointing;

[0047] The run type selector is used to automatically build the corresponding training startup command based on the run type and parallel framework selected by the user:

[0048] When using a single machine and single graphics card (SMSG), use Python to run fine-tuning tasks directly.

[0049] When selecting Single Machine Multiple Graphics Cards (SMMG) or Multiple Machine Multiple Graphics Cards (MMMG), choose to use accelerate or deepspeed to build the startup command based on the parallel_framework parameter.

[0050] Furthermore, the Master-Driver-Work three-layer architecture of the training engine module specifically includes:

[0051] The Master component is responsible for:

[0052] Receive task messages from the management side and add the task ID to the Redis message queue for consumption;

[0053] When consuming, query the task configuration details based on the task ID and generate a Kubernetes standard YAML file;

[0054] Call the Kubernetes API to create the Driver container and Work container;

[0055] Receives the Driver's service registration event and starts listening for events according to the configured time interval and timeout settings;

[0056] Monitor the driver's survival and restart it when the monitoring event times out;

[0057] After the task is completed, destroy the Driver and Work containers to release resources;

[0058] Driver component, specifically responsible for:

[0059] After successful startup, call the Master service registration API to register;

[0060] Receive the service registration event of the Work and start the monitoring event to monitor whether the Work is alive;

[0061] When a work fails, reassign tasks and start a new work;

[0062] Receive the training completion notification sent by the Worker and write back the training results;

[0063] Work component, specifically responsible for:

[0064] After successful startup, call the Driver service registration API to register;

[0065] Dynamically load datasets, large models, and configuration files through mounting;

[0066] Perform fine-tuning training tasks;

[0067] After training is completed, call the Driver-side event monitoring API to write back the training results.

[0068] Furthermore, the task communication mechanism of the training engine module is specifically implemented as follows:

[0069] Task allocation mechanism:

[0070] After the user starts a task, the backend calls the Master's start task API interface and adds the task ID to the Redis message queue;

[0071] The master obtains the task ID from the message queue, queries the task configuration details and generates a Kubernetes standard YAML file;

[0072] The Master first calls the Kubernetes API to create a Driver container. After the Driver container is successfully started, it creates a Work container.

[0073] Container creation uses the Kubernetes API and is compatible with existing container orchestration systems;

[0074] Status monitoring mechanism:

[0075] After the Driver container is successfully started, it calls the Master service registration API to register. After receiving the registration event, the Master starts listening for events.

[0076] After the Work container is successfully started, it calls the Driver service registration API to register. After receiving the registration event, the Driver starts listening for events.

[0077] The Master periodically sends heartbeat packets to detect whether the Driver is alive. If there is no response within the timeout period, the Master considers the Driver down and restarts it.

[0078] The driver periodically sends heartbeat packets to check whether the Worker is alive. If there is no response within the timeout period, the Worker is considered down and restarted.

[0079] Result write-back mechanism:

[0080] After the Worker completes the training, it calls the event monitoring API provided by the Driver to write back the training results.

[0081] After receiving the training results, the Driver saves the results and updates the task status;

[0082] The master periodically checks the task status. When all work is completed, it marks the task as completed and releases resources.

[0083] Furthermore, the exception handling mechanism of the training engine module specifically includes:

[0084] Task failure retry mechanism:

[0085] When a fine-tuning training task fails, the system automatically retries the task. The number of retries is specified by the retry_count parameter in the YAML configuration file.

[0086] The retry interval is specified by the retry_interval parameter in the YAML configuration file, in seconds;

[0087] If the task still fails after the configured number of retries, the system marks the task as failed and records an error log;

[0088] Container health check and automatic restart mechanism:

[0089] The Master and Driver containers perform health checks regularly. The health check frequency is specified by the health_check_interval parameter.

[0090] If the container does not respond within the specified time (specified by the health_check_timeout parameter), the system automatically restarts the container;

[0091] When you restart a container, the system will retain the configuration and status information of the original container to ensure that the restarted container can continue to perform the original task;

[0092] Task status monitoring and recovery mechanism:

[0093] The Master monitors the status of the Driver and Work containers in real time and triggers the corresponding recovery process when an anomaly is detected;

[0094] If the Work container fails, the Driver will reallocate tasks and start a new Work container to take over the unfinished training;

[0095] If the Driver goes down, the Master will detect it and start a new Driver container. The new Driver will re-register with the Master and take over the unfinished tasks.

[0096] If the Master goes down, the system will automatically start a new Master container and restore the task execution status from the most recent checkpoint;

[0097] All recovery operations are based on the most recent checkpoint, ensuring that the task can continue from the interruption point and reducing repeated calculations.

[0098] Furthermore, the training algorithm framework module specifically includes:

[0099] The configuration parsing component is used to parse the run configuration ai.envs.train.yaml file, extract the parameter values ​​and convert them into the parameter format required for Llama-Factory fine-tuning, including the three hyperparameters of learning rate, batch size, and number of training rounds;

[0100] The dataset splitting component is used to randomly split the dataset. The specific implementation is as follows:

[0101] Determine the ratio of the training set and the evaluation set according to the evalScale parameter value in the ai.envs.train.yaml file;

[0102] Use random splitting algorithm to ensure uniformity of data distribution and prevent data bias;

[0103] Save the split data set into two files: training set and evaluation set;

[0104] The data format conversion component is used to convert datasets in various formats into the Llama-Factory standard format. The specific implementation is as follows:

[0105] Parse the original data format and extract key fields;

[0106] Reorganize the data according to the format required by Llama-Factory;

[0107] Ensure that the converted data is fully compatible with Llama-Factory;

[0108] The fine-tuning training component supports three fine-tuning training methods, which are determined by the train_method parameter in the ai.envs.train.yaml file;

[0109] Evaluation component, used to evaluate the model and output four evaluation indicators;

[0110] The intermediate process monitoring component is used to monitor the task iteration progress in real time and write the real-time results in JSON file format to the path specified by output.task_result in the ai.envs.train.yaml file. It supports the client to receive and display the real-time training status through the WebSocket protocol.

[0111] Furthermore, the fine-tuning training component specifically supports the following three fine-tuning methods:

[0112] The LoRA fine-tuning method is specifically implemented as follows:

[0113] Approximate the update of model weights through low-rank decomposition, and add a pair of trainable low-rank decomposition matrices for each weight matrix that needs to be updated;

[0114] Assume that the original weight matrix is ​​W, with a dimension of d×k, and introduce matrices A (with a dimension of d×r) and B (with a dimension of r×k) of rank r. The fine-tuned weight matrix becomes W+AB;

[0115] During the training process, only the two low-rank matrices A and B are trained, and the original weight matrix W remains fixed;

[0116] This method is particularly suitable for scenarios with limited computing resources, for fine-tuning on consumer-grade GPUs, and for scenarios where different fine-tuning directions need to be quickly tried.

[0117] The full fine-tuning method is specifically implemented as follows:

[0118] All parameters of the pre-trained model are treated as trainable parameters, including three types of parameters: embedding layer, multi-head attention layer, and feedforward neural network layer;

[0119] Use the backpropagation algorithm to update each parameter in the model, and the update step size is controlled by the optimization algorithm (Adam or SGD) according to the learning rate;

[0120] This method is suitable for scenarios with a large amount of high-quality labeled data and sufficient computing resources, and can maximize the adaptation of the model to specific tasks;

[0121] The freeze fine-tuning method is specifically implemented as follows:

[0122] Only some layers in the pre-trained model are adjusted, while the parameters of other layers remain fixed;

[0123] Choose to freeze the early layers near the input and only fine-tune the later layers near the output;

[0124] This method is suitable for scenarios where the task is similar to the pre-training task but also has certain differences. It can adapt to specific task requirements while retaining pre-training knowledge.

[0125] The automatic mechanism of fine-tuning method is as follows:

[0126] Select a fine-tuning method based on the user's task requirements, dataset size, and hardware resources;

[0127] Use LoRA fine-tuning when computing resources are limited or when you need to quickly try different fine-tuning directions;

[0128] When there is a large amount of high-quality annotated data and sufficient computing resources, use full-scale fine-tuning;

[0129] Use frozen fine-tuning when the task is similar to the pre-training task but also has some differences;

[0130] 1. Recommended conditions for LoRA fine-tuning (low-rank adaptation)

[0131] Applicable scenarios: Limited computing resources or the need for rapid iterative experiments.

[0132] Judgment conditions:

[0133] Hardware resources:

[0134] GPU memory ≤ 32GB

[0135] Available training time is less than 4 hours (need to quickly verify the effect).

[0136] Data scale:

[0137] The amount of labeled data is ≤ 100,000.

[0138] The data quality is medium or noisy (LoRA is less sensitive to noise).

[0139] Task requirements:

[0140] The task is moderately different from the pre-training task (e.g. text classification → sentiment analysis).

[0141] 2. Recommended conditions for Full Fine-Tuning

[0142] Applicable scenarios: sufficient resources and high-quality data.

[0143] Judgment conditions:

[0144] Hardware resources:

[0145] GPU video memory > 32GB (such as A100, H100).

[0146] Available training time > 4 hours.

[0147] Data scale:

[0148] The amount of labeled data is greater than 500,000 and the labeling consistency is high (e.g., the manual review pass rate is ≥ 95%).

[0149] Task requirements:

[0150] The task is significantly different from the pre-training task (e.g. pre-training is general text → downstream is medical entity recognition).

[0151] All model parameters need to be tuned to maximize performance.

[0152] 3. Freeze-Tuning Recommended Conditions

[0153] Applicable scenarios: The task is similar to the pre-training task but requires slight adaptation.

[0154] Judgment conditions:

[0155] Hardware resources:

[0156] GPU video memory ≤ 24 GB.

[0157] Available training time < 1 hour.

[0158] Data scale:

[0159] The amount of labeled data is ≤ 50,000 (suitable for small samples).

[0160] Task requirements:

[0161] The domain overlap between the pre-training task and the downstream task is ≥ 70% (e.g. BERT pre-training → news classification)

[0162] Users can manually select a fine-tuning method when creating a fine-tuning task, or the system can automatically select one based on rules.

[0163] Furthermore, the evaluation component is specifically used to calculate the following four evaluation indicators:

[0164] Perplexity, precision, recall, and loss;

[0165] The evaluation process is specifically implemented as follows:

[0166] Use the number of iterations (num_train_epochs) specified in the ai.envs.train.yaml file options to train the model;

[0167] After training is complete, save the model to the path specified by outputs.main in the ai.envs.train.yaml file;

[0168] During evaluation, the model in this path is read and the split test set is used for evaluation.

[0169] Write the evaluation results in JSON format to the path specified by output.task_result in the ai.envs.train.yaml file.

[0170] Furthermore, the intermediate process monitoring component is specifically implemented as follows:

[0171] A callback function mechanism is used to trigger the callback function at the end of each iteration step of model training;

[0172] The callback function collects training information in real time, including the current number of iterations, training loss value, and learning rate parameters;

[0173] Write the collected information in JSON format to the path specified by output.task_result in the ai.envs.train.yaml file;

[0174] The JSON file structure contains five fields: task ID, current iteration number, total iteration number, training loss value, and learning rate;

[0175] The backend service uses a file monitoring mechanism to detect changes in JSON files and read the latest content when the file is updated;

[0176] The backend service pushes the latest training status to the connected clients via the WebSocket protocol;

[0177] After receiving the pushed data, the client updates the two visual components, the training progress bar and the loss curve graph, in real time, providing an intuitive training process monitoring experience.

[0178] Furthermore, the implementation process of the device includes the following steps:

[0179] The user selects the basic large model and training scenario in the management interface, and the system reads the corresponding YAML configuration template file based on the selection;

[0180] The system parses the YAML configuration template file, extracts the options section and displays them on the interface. Users can adjust hyperparameters as needed.

[0181] The user uploads or selects an existing training dataset and specifies the evaluation data ratio;

[0182] After the user submits a task, the system generates a running YAML file ai.envs.train.yaml and sends it to the Master through the Start Task API along with the training dataset and basic model.

[0183] The Master adds the task to the queue and starts the Driver and Worker containers to execute the training task.

[0184] During the training process, the system monitors the training status in real time and pushes the status to the client through the WebSocket protocol;

[0185] After training is completed, the system evaluates the model, outputs evaluation indicators, and saves the trained model to the specified path;

[0186] Users can view training results, evaluation indicators, and visualization charts of the training process in the management interface, and can also download the trained model for inference.

[0187] Compared with the prior art, the present invention has the following beneficial effects:

[0188] 1. The present invention provides an automatic learning engine device based on a packaged large model training platform, which supports multiple hardware devices such as CPU, GPU, NPU, and combines with parallel computing frameworks such as Accelerate and DeepSpeed ​​to efficiently utilize computing resources in different scenarios such as single machine and single card, single machine and multiple cards, and multiple machines and multiple cards.

[0189] 2. The present invention provides an automatic learning engine device based on an encapsulated large model training platform. The Master-Driver-Work architecture provides a complete exception handling mechanism, including task failure retry, container health check and automatic restart, task status monitoring and recovery, which greatly improves the reliability and fault tolerance of the system.

[0190] 3. The present invention provides an automatic learning engine device based on a packaged large model training platform, which automatically selects the most appropriate fine-tuning method (LoRA, full or frozen fine-tuning) according to task requirements, data set size and hardware resources, avoiding the uncertainty of manual selection and improving training effects.

[0191] 4. The present invention provides an automatic learning engine device based on an encapsulated large-model training platform. Through functions such as configuration parsing, automatic data set splitting, and automatic data format conversion, it reduces manual intervention and significantly shortens the entire process cycle from data preparation to model deployment. The overall solution lowers the technical threshold for fine-tuning large models, allowing non-professionals to complete complex model training tasks through simple configuration, thereby promoting the popularization and application of large-model technology.

[0192] 5. The present invention provides an automatic learning engine device based on an encapsulated large model training platform. It uses a callback function to monitor the training progress in real time and promptly feedback status changes, so that users can grasp the training status at any time and adjust the strategy in advance when necessary. Through standard indicators such as perplexity, precision, recall rate, and loss value, a standardized model performance evaluation system is established to facilitate comparison and evaluation between different models. BRIEF DESCRIPTION OF THE DRAWINGS

[0193] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0194] Figure 1 It is a schematic diagram of the device flow chart;

[0195] Figure 2 It is the engine training flow chart;

[0196] Figure 3 Display the effect diagram for the interface. DETAILED DESCRIPTION

[0197] The technical solutions of the present invention will be more clearly and completely explained below through description of preferred embodiments of the present invention in conjunction with the accompanying drawings.

[0198] Explanation of terms:

[0199] Explanation of technical terminology for large model training platforms

[0200] Llama-Factory - an open-source toolbox for training large models.

[0201] YAML configuration: A human-readable data serialization format used in this system to define training parameters, environment configuration, and resource allocation;

[0202] Fine-tuning (SFT): Adapting the model to a specific domain or task by further training it using task-specific data based on the pre-trained model;

[0203] Pre-training (PT): The process of initially training the model on a large-scale general corpus to learn the basic laws and knowledge of the language;

[0204] Reward Model Training (RM): The model training process used in reinforcement learning to evaluate the quality of generated content;

[0205] LoRA fine-tuning: a parameter-efficient fine-tuning method;

[0206] Accelerate - lightweight distributed training library.

[0207] DeepSpeed ​​- deep learning optimization library.

[0208] Mixed precision training: Use different numerical precisions for calculations simultaneously to balance training speed and accuracy;

[0209] Gradient accumulation: accumulate gradients over multiple small batches before updating the model;

[0210] Zero Redundancy Optimizer (ZeRO): A key technology in DeepSpeed ​​that reduces memory usage through layered optimization.

[0211] Master-Driver-Worker architecture: A hierarchical task management architecture where the Master is responsible for global scheduling, the Driver monitors work progress, and the Worker performs specific computing tasks.

[0212] Kubernetes: a container orchestration platform for automating the deployment, scaling, and management of containerized applications;

[0213] MLflow / Kubeflow: MLOps tools for managing machine learning experiments and model deployments.

[0214] Perplexity: An indicator for evaluating the predictive ability of a language model. Lower values ​​indicate more accurate model predictions.

[0215] Precision: The proportion of samples predicted to be positive that are actually positive, reflecting the accuracy of the prediction;

[0216] Recall rate: The proportion of samples that are actually positive that are correctly identified, reflecting the model's capture ability;

[0217] Loss value: A numerical value that quantifies the degree of error in the model's predictions, usually calculated using the cross-entropy loss function.

[0218] like Figure 1As shown, the top layer is the MaaS platform, which serves as the control center of the entire system. It sends tasks to the Master component through the task message mechanism. After receiving the task, the Master component is responsible for starting the Driver container. The Driver container then starts the Work container to form a container orchestration chain. The Work container, as the executor of the actual workload, handles various computing tasks. It will execute the specific business logic stored in the code framework, configuration framework or large model configuration file. After the task is completed, a completion signal is sent. At the same time, the system has a complete resource release mechanism, which is represented by the curved feedback path on the right to ensure that the Driver container and the Work container can return the computing resources to the resource pool in time after completing their respective responsibilities, avoiding resource waste. As a whole, an efficient task processing and resource management closed loop is formed.

[0219] As a specific embodiment, the specific embodiment of the automatic learning engine device based on the Llama-Factory encapsulation large model training platform

[0220] The present invention provides an automatic learning engine device based on the Llama-Factory encapsulated large model training platform. The device mainly includes four main parts: a unified access specification module, a multi-device support and parallel computing framework module, a training engine module, and a training algorithm framework module. It can realize the efficient management, deployment and execution of large model training.

[0221] In this implementation, YAML configuration template files are the core configuration unit of the system, used to standardize parameter configuration for training and inference. These files follow a specific naming convention: ai.config.train.<model name encoding>.<scenario name>.yaml. The model name encoding is the encoding of the user-selected large model (e.g., the Qianwen 7B large model encoding is Qwen-7B-Chat), and the scenario name is fine-tuning (sft), pre-training (pt), or reward model training (rm).

[0222] For example, for fine-tuning the Qianwen 7B model, the template file is named ai.config.train.Qwen-7B-Chat.sft.yaml. This file is used when a user adds a fine-tuning task and selects the Qianwen 7B base model. The system backend reads the YAML template file based on the model encoding and scenario, parses the hyperparameters (options), and displays them on the frontend for user-defined parameter adjustments. When the task starts, all configuration items, except for the user-defined hyperparameters (options), are retrieved from the YAML template to generate the runtime ai.envs.train.yaml file for task execution.

[0223] The YAML configuration template file is mainly divided into five sections: runtime, options, inputs, outputs, and logs. The runtime section describes the algorithm runtime environment configuration. It includes the type field (type) indicating the runtime type, which can be single-machine single-GPU (SMSG), single-machine multiple-GPU (SMMG), or multiple-machine multiple-GPU (MMMG); the parallel computing framework field (parallel_framework) indicating the parallel computing framework, which can be accelerate or deepspeed; the workspace field (workspace) indicating the working directory path; and the command field (cmd) indicating the algorithm runtime command list. The options section describes the algorithm runtime hyperparameters and contains multiple hyperparameter objects. Each object has a code field (code), a name field (name), a type field (type), a display field (display), a default value field (default), a description field (desc), and a rule field (rule) used to define the hyperparameter's enumeration value or value range. The inputs section defines the input resources required by the algorithm, including training data, evaluation data, and the base model. Each input has a name field (name), a code field (code), an original ID field (oid), a type field (type) indicating the resource type such as dataset, datasource, or model, a label field (label), an access type field (accessType) indicating local or remote access, a uniform resource identifier field (uri), and an evaluation scale field (evalScale) for training data. The outputs section defines the output results of the training process, such as the model (main), tensorboard visualization results, checkpoint checkpoints, and task_result task results. Each output item contains the name, code, oid, type, accessType, and uri fields. The logs section defines the storage information of the log, including the name, code, type, accessType, and uri fields.

[0224] The parsing of the YAML configuration template file is implemented through a custom parser, which can parse layer by layer according to the hierarchical structure of the YAML file and convert it into an internal data structure. The system first reads the YAML file and loads it as a dictionary object using Python's yaml library. The parser parses the five parts of runtime, options, inputs, outputs, and logs layer by layer according to the hierarchical structure of the YAML file. The parser verifies each parameter to ensure that its data type and value range meet expectations. If some parameters are not explicitly specified in the YAML file, the parser will automatically fill in the default value. When the user creates a fine-tuning task, the system will read the corresponding YAML template file based on the model and scenario selected by the user, and dynamically generate the runtime YAML file ai.envs.train.yaml, merging the user-defined hyperparameters with other configuration items in the template file.

[0225] When a user creates a fine-tuning task, the system reads the corresponding YAML template file based on the selected large model and scenario and dynamically displays the hyperparameter configuration (options section). Users can modify hyperparameters as needed. When the task is saved, the system generates a runtime YAML file, ai.envs.train.yaml. This file is dynamically mounted into the container when the task starts and used by the fine-tuning algorithm. The runtime YAML file contains the same five sections as the template file (runtime, options, inputs, outputs, and logs), but the options section contains user-defined parameter values.

[0226] This implementation is fully compatible with three types of hardware devices, including CPU, GPU, and NPU, ensuring efficient operation in different operating environments. Build corresponding images according to different hardware environments, and configure the image address in the yaml template file. It also supports two parallel computing frameworks: Accelerate and DeepSpeed, to greatly improve training efficiency. The Accelerate framework provides device management functions (automatically manages device allocation, supports CPU, GPU, and NPU), mixed precision functions (supports automatic mixed precision training, reduces memory usage and accelerates training), distributed training functions (supports multi-GPU and multi-node distributed training, automatically handles data parallelism and model parallelism), and gradient accumulation functions (supports gradient accumulation, which can train larger models with limited GPU memory). The DeepSpeed ​​framework provides device management functions (supporting multi-GPU and multi-node distributed training, and automatically managing device allocation), mixed precision functions (supporting automatic mixed precision training, reducing memory usage and accelerating training), gradient accumulation functions (supporting gradient accumulation, allowing training of larger models with limited GPU memory), Zero Redundancy Optimizer functions (ZeRO) (using layered optimization technology to reduce memory usage and support larger-scale model training), model parallel functions (supporting model parallelism, allowing large models to be split into multiple GPUs for training) and checkpoint functions (supporting automatic saving and restoration of training status, facilitating interruption and resumption of training).

[0227] In this embodiment, when the user selects a single machine and a single card, the runtime.type parameter in the ai.envs.train.yaml file is SMSG, the runtime.parallel_framework parameter is invalid (the option will be hidden on the page), and Python is used directly to run the fine-tuning task; when the user selects a single machine and multiple cards or multiple machines and multiple cards, the runtime.type parameter in the ai.envs.train.yaml file is SMMG or MMMG, and the runtime.parallel_framework parameter can select accelerate or deepspeed. When starting the task, the startup command is built according to the parallel_framework configuration to start it.

[0228] The training engine architecture adopts a three-tier Master-Driver-Work structure, with the responsibilities of each component as follows: The Master is responsible for receiving task messages from the management end, and then starting a Driver container and one or more Work containers based on the configuration, while monitoring the Driver status and destroying the Driver and Work containers to release resources after the task is completed; the Driver container is responsible for monitoring the status of the Work container and writing back the training results; the Work container is specifically responsible for executing fine-tuning training tasks, and the required data sets, large models, and configuration files are dynamically loaded into the container through mounting. After the task is completed, the Driver will be called to write back the training results and status.

[0229] The communication mechanism between the Master, Driver, and Work is specifically implemented as follows: after the user starts a task, the backend calls the Master's start task API interface and then adds the task ID to the Redis message queue for consumption; when consuming, the task configuration details are queried based on the task ID and Kubernetes standard YAML (including Driver YAML and Work YAML) is generated. Then, the Kubernetes API is called to pass in the Driver YAML to create the Driver container; after the Driver container is successfully started, the Work YAML is passed in to create the Work container; after the Driver service is successfully started, it calls the Master service registration API for registration. After receiving the registration event, the Master will start listening events according to the time interval and timeout setting in the configuration file to monitor whether the Driver is alive; similarly, after the Work container is successfully created, it will also call the Driver service registration API for registration. After receiving the registration event, the Driver will also start listening events according to the settings in the configuration file to monitor whether the Work is alive. After the Work is successfully registered, it starts the fine-tuning task for training. After the training is complete, a notification is sent to call the Driver event listening API to write back the training results.

[0230] The training engine's exception handling mechanism specifically includes: task failure retry mechanism. When a task fails, the system automatically retries the task. The number of retries and the interval time can be configured through the retry_count and retry_interval parameters in the YAML configuration file. If the task still fails after multiple retries, the system will mark the task as failed and record a detailed error log; container health check and automatic restart. The Master and Driver containers will perform health checks regularly. If a container does not respond within the specified time, the system will automatically restart the container. The frequency and timeout of health checks can be configured through the health_check_interval and health_check_timeout parameters in the YAML configuration file; task status monitoring and recovery. The Master will monitor the status of the Driver and Work containers in real time. If a Work container fails, the Driver will reallocate the task and start a new Work container to take over the unfinished training. If the Master or Driver goes down, the system will automatically start a new Master or Driver container and resume task execution from the most recent checkpoint.

[0231] like Figure 2 As shown in the figure, it is a flow chart of the training engine. After the system is started, the Master component receives task messages from the MaaS management end; then the Master performs intelligent scheduling analysis based on the task priority and the management end task list; then the system will determine whether the task is schedulable, which is a key decision point. If it is not schedulable, the task will be marked as invalid and the processing will be terminated. If it is schedulable, it will continue to execute according to the established strategy; for schedulable tasks, the system starts a dedicated Driver container and triggers the task processing logic; the Driver container will dynamically start one or more Work containers according to the task requirements to realize parallel processing of tasks; the Work container takes over and executes specific scheduling tasks to complete the actual business processing; after the task is executed, the system records the completion results and enters the resource recovery phase, destroying the no longer needed Driver and Work containers in turn; finally, the system releases all related resources, marking the completion of the entire task processing cycle, forming a complete closed-loop process from task reception, scheduling, execution to resource recovery.

[0232] The configuration parsing component of the training algorithm framework can parse the run configuration ai.envs.train.yaml file and construct the parameters required for Llama-Factory fine-tuning. The dataset splitting component supports random splitting of the dataset, splitting the original fine-tuning text dataset into training and evaluation sets in proportion. The split ratio is based on the evalScale parameter in the ai.envs.train.yaml configuration file. The data format conversion component converts the dataset format to the Llama-Factory standard format to ensure data consistency and compatibility without affecting the input and output formats of the model.

[0233] The fine-tuning training component supports three fine-tuning training methods: LoRA fine-tuning, full fine-tuning, and frozen fine-tuning. The specific method used is determined by the fine-tuning training method selected by the user when adding a new task (train_method value lora / full / freeze). The selection result is written to the train_method parameter in the ai.envs.train.yaml file. The core idea of ​​LoRA fine-tuning is to approximate the update of model weights through low-rank decomposition. Based on the original pre-trained model, a pair of trainable low-rank decomposition matrices are added to each weight matrix that needs to be updated. Assuming the original weight matrix is ​​W, with a dimension of d×k, by introducing the rank r matrices A (dimension d×r) and B (dimension r×k), the fine-tuned weight matrix becomes W+AB. During training, only the two low-rank matrices A and B are trained, while the original weight matrix W remains fixed. Full fine-tuning is the most direct fine-tuning method. Based on a pretrained model, all model parameters are treated as trainable. During training, backpropagation is used to update every parameter in the model, including the parameters of all layers, including the embedding layer, multi-head attention layer, and feedforward neural network layer, based on the task's loss function. Frozen fine-tuning involves adjusting only a subset of layers in the pretrained model, while keeping the parameters of other layers fixed. Generally speaking, layers close to the input capture more general features, while layers close to the output focus more on task-specific information. Therefore, early layers are often frozen, and only later layers are fine-tuned. The system also features an automatic fine-tuning mechanism that automatically selects the appropriate fine-tuning method based on the user's task requirements, dataset size, and hardware resources. LoRA fine-tuning is used when the user has limited computing resources or wants to quickly experiment with different fine-tuning directions. Full fine-tuning is used when the user has a large amount of high-quality annotated data and the computing resources allow for extended training of the entire model. Frozen fine-tuning is used when the user's task is similar to the pretrained task but also differs slightly.

[0234] The evaluation component has the function of evaluating the model and can output four evaluation indicators: Perplexity is a measure of how well a probability model predicts a sample. It is usually used to evaluate the quality of language models in NLP. The calculation method is: , where N is the number of words in the sentence, is the probability of the entire sequence. The lower the value, the better. Ideally, it is close to 1. Precision refers to the proportion of samples that are actually positive among all samples predicted to be positive. The calculation method is , where TP is the number of true positives and FP is the number of false positives. A high precision means that the model has a high accuracy in predicting a certain category; Recall refers to the proportion of samples that are correctly identified among all samples that are actually positive, and is calculated as , where FN is the number of false negatives. A high recall rate means that the model can capture more true positive examples. The loss value (Loss) is a quantitative way to quantify the degree of error in the model prediction. In this system, the cross entropy loss function is used for calculation. The formula is , where N is the number of samples, is the true label of sample i (0 or 1), is the probability that the model predicts sample i to be 1. During training, the loss value should gradually decrease, indicating that the model is learning and improving its performance. The evaluation process is as follows: iterative training is performed using the number of iterations (num_train_epochs) specified in the options file ai.envs.train.yaml. After training, the model is written to the model output path specified in outputs.main in the ai.envs.train.yaml file. During evaluation, the output model is read and evaluated using the test set. The evaluation results are written in JSON format to the path specified in output.task_result in the ai.envs.train.yaml file.

[0235] The intermediate process monitoring component uses a callback function to monitor the task iteration progress in real time, provide timely feedback on the training status, and write the real-time results in JSON file format to the corresponding path according to the output.task_result configuration of the ai.envs.train.yaml file. The management client uses the WebSocket protocol to connect to the backend service. The backend service monitors the changes in the result file and pushes the data to the client for display, allowing users to monitor the training progress in real time. Figure 3 shown.

[0236] The specific system operation process is as follows: the user selects the basic large model and training scenario on the management interface, and the system reads the corresponding YAML configuration template file according to the selection; the system parses the YAML configuration template file, extracts the options part and displays it on the interface, and the user can adjust the hyperparameters as needed; the user uploads or selects an existing training data set and specifies the evaluation data ratio; after the user submits the task, the system generates a running YAML file ai.envs.train.yaml, and sends it together with the training data set and the basic model to the Master through the start task API; the Master adds the task to the queue and starts the Driver and Work containers to execute the training task; during the training process, the system monitors the training status in real time and pushes the status to the client through the WebSocket protocol; after the training is completed, the system evaluates the model, outputs four evaluation indicators: perplexity, precision, recall and loss value, and saves the trained model to the specified path; users can view the training results, evaluation indicators and visual charts of the training process on the management interface, and can also download the trained model for inference.

[0237] This implementation utilizes innovative designs such as unified access specifications, multi-device support and a parallel computing framework, a Master-Driver-Work three-tier training engine, comprehensive exception handling mechanisms, support for multiple fine-tuning methods, and real-time monitoring. This platform creates an easy-to-use, stable, and efficient large-model training platform suitable for a variety of large-model training scenarios, significantly improving the efficiency and success rate of large-model training. Compared to existing MLOps solutions, this device offers greater flexibility, scalability, and automation, better meeting the complex and ever-changing needs of large-model training.

[0238] The above-described specific embodiments merely describe preferred embodiments of the present invention and do not limit the scope of protection of the present invention. Any modifications, substitutions, and improvements made to the technical solution of the present invention by a person skilled in the art based on the textual description and drawings provided herein, without departing from the design concept and spirit of the present invention, shall fall within the scope of protection of the present invention. The scope of protection of the present invention is determined by the claims.

Claims

1. An automatic learning engine device based on a packaged large model training platform, characterized in that: include: A unified access specification module that standardizes training and inference parameter configurations through YAML configuration template files. The YAML configuration template files follow the naming convention of "ai.config.train.<model name encoding>.<scenario name>.yaml", where the model name encoding is the encoding corresponding to the large model selected by the user, and the scenario name is fine-tuning, pre-training, or reward model training; Multi-device support and parallel computing framework module, which is compatible with three hardware devices: CPU, GPU, and NPU, and supports two parallel computing frameworks: Accelerate and DeepSpeed. It automatically generates corresponding training start commands based on the user's selected operation type and parallel framework; The training engine module uses a three-tier Master-Driver-Worker architecture to implement task allocation, status monitoring, and exception handling. The Master is responsible for receiving task messages and starting containers, the Driver is responsible for monitoring the Worker status and writing back the results, and the Worker is responsible for executing fine-tuning training tasks. The Master-Driver-Worker three-tier architecture of the training engine module specifically includes: The Master component is responsible for: Receive task messages from the management side and add the task ID to the Redis message queue for consumption; When consuming, query the task configuration details based on the task ID and generate a Kubernetes standard YAML file; Call the Kubernetes API to create the Driver container and Work container; Receives the Driver's service registration event and starts listening for events according to the configured time interval and timeout settings; Monitor the driver's survival and restart it when the monitoring event times out; After the task is completed, destroy the Driver and Work containers to release resources; Driver component, specifically responsible for: After successful startup, call the Master service registration API to register; Receive the service registration event of the Work and start the monitoring event to monitor whether the Work is alive; When a work fails, reassign tasks and start a new work; Receive the training completion notification sent by the Worker and write back the training results; Work component, specifically responsible for: After successful startup, call the Driver service registration API to register; Dynamically load datasets, large models, and configuration files through mounting; Perform fine-tuning training tasks; After training is completed, call the Driver-side event monitoring API to write back the training results; The task communication mechanism of the training engine module is as follows: Task allocation mechanism: After the user starts a task, the backend calls the Master's start task API interface and adds the task ID to the Redis message queue; The master obtains the task ID from the message queue, queries the task configuration details and generates a Kubernetes standard YAML file; The Master first calls the Kubernetes API to create a Driver container. After the Driver container is successfully started, it creates a Work container. Container creation uses the Kubernetes API and is compatible with existing container orchestration systems; Status monitoring mechanism: After the Driver container is successfully started, it calls the Master service registration API to register. After receiving the registration event, the Master starts listening for events. After the Work container is successfully started, it calls the Driver service registration API to register. After receiving the registration event, the Driver starts listening for events. The Master periodically sends heartbeat packets to detect whether the Driver is alive. If there is no response within the timeout period, the Master considers the Driver down and restarts it. The driver periodically sends heartbeat packets to check whether the Worker is alive. If there is no response within the timeout period, the Worker is considered down and restarted. Result write-back mechanism: After the Worker completes the training, it calls the event monitoring API provided by the Driver to write back the training results. After receiving the training results, the Driver saves the results and updates the task status; The master periodically checks the task status. When all work is completed, it marks the task as completed and releases resources. The training algorithm framework module is used to parse the ai.envs.train.yaml operation configuration file, split the data set, convert the data format, support multiple fine-tuning training methods, and evaluate the model.

2. The automatic learning engine device based on the encapsulated large model training platform according to claim 1 is characterized in that: The YAML configuration template file in the unified access specification module consists of the following five parts: The runtime part is used to describe the algorithm runtime environment configuration, including: The type field indicates the operation type; The parallel_framework field indicates the parallel computing framework; The workspace field indicates the working directory path; The cmd field indicates the algorithm execution command list; The options section is used to describe the algorithm running hyperparameters and contains multiple hyperparameter objects, each of which has: The code field indicates the hyperparameter code; The name field indicates the hyperparameter display name; The type field indicates the hyperparameter data type; The display field indicates whether the hyperparameters are displayed; The default field indicates the default value of the hyperparameter; The desc field indicates the hyperparameter description; The rule field is used to define the enumeration value or value range of the hyperparameter; The inputs section defines the input resources required by the algorithm, including training data, evaluation data, and basic models. Each input resource has: The name field indicates the resource name; The code field indicates the resource code; The oid field indicates the original code / ID; The type field indicates the resource type; The label field indicates the resource label; The accessType field indicates the access type, with values ​​of local or remote; uri field, indicating the uniform resource identifier; The evalScale field indicates the evaluation data scale; The outputs section is used to define the output results of the training process, including models, tensorboard visualization results, checkpoint checkpoints, and task_result task results. Each output item has name, code, oid, type, accessType, and uri fields; The logs section is used to define the storage information of the logs, including the name, code, type, accessType, and uri fields.

3. The automatic learning engine device based on the encapsulated large model training platform according to claim 1 is characterized in that: The unified access specification module also includes a YAML configuration template file parser, which is specifically used to: Read the YAML file and parse it into nested dictionaries and lists using Python's yaml library, parsing the runtime, options, inputs, outputs, and logs sections layer by layer. Verify the data type and value range of each parameter to ensure that the parameter meets expectations; Automatically fill in default values ​​for parameters not explicitly specified in the YAML file, including default values ​​for hyperparameters in options; When a user creates a fine-tuning task, the system reads the corresponding YAML template file based on the user's selected model and scenario, and dynamically generates the runtime YAML file ai.envs.train.yaml. This file merges the user-defined hyperparameters with the configuration items in the runtime, inputs, outputs, and logs sections of the template file. Ensure that the generated runtime YAML file is correctly loaded into the container by mounting when the task is started for use in the fine-tuning algorithm.

4. The automatic learning engine device based on the encapsulated large model training platform according to claim 1, characterized in that: The multi-device support and parallel computing framework modules specifically include: The device adapter component is used to build corresponding container images for three different hardware devices: CPU, GPU, and NPU. It also configures the image address in the YAML template file to ensure efficient operation in different operating environments. Parallel computing support components, specifically supporting: The Accelerate framework provides four functions: device management, mixed-precision training, distributed training, and gradient accumulation; DeepSpeed ​​framework, which provides six features: device management, mixed-precision training, gradient accumulation, zero-redundancy optimizer, model parallelism, and checkpointing; The run type selector is used to automatically build the corresponding training startup command based on the run type and parallel framework selected by the user: When a single machine and single GPU is selected, use Python directly to run the fine-tuning task; When using a single machine with multiple graphics cards or multiple machines with multiple graphics cards, use accelerate or deepspeed to build the startup command based on the parallel_framework parameter.

5. The automatic learning engine device based on the encapsulated large model training platform according to claim 1 is characterized in that: The exception handling mechanism of the training engine module specifically includes: Task failure retry mechanism: When a fine-tuning training task fails, the system automatically retries the task. The number of retries is specified by the retry_count parameter in the YAML configuration file. The retry interval is specified by the retry_interval parameter in the YAML configuration file, in seconds; If the task still fails after the configured number of retries, the system will mark the task as failed and record an error log; Container health check and automatic restart mechanism: The Master and Driver containers perform health checks regularly. The health check frequency is specified by the health_check_interval parameter. If the container does not respond within the specified time, the system automatically restarts the container; When you restart a container, the system will retain the configuration and status information of the original container to ensure that the restarted container can continue to perform the original task; Task status monitoring and recovery mechanism: The Master monitors the status of the Driver and Work containers in real time and triggers the corresponding recovery process when an anomaly is detected; If the Work container fails, the Driver will reallocate tasks and start a new Work container to take over the unfinished training; If the Driver goes down, the Master will detect it and start a new Driver container. The new Driver will re-register with the Master and take over the unfinished tasks. If the Master goes down, the system will automatically start a new Master container and restore the task execution status from the most recent checkpoint; All recovery operations are based on the most recent checkpoint, ensuring that the task can continue from the interruption point and reducing repeated calculations.

6. The automatic learning engine device based on the encapsulated large model training platform according to claim 1, characterized in that: The training algorithm framework module specifically includes: The configuration parsing component is used to parse the run configuration ai.envs.train.yaml file, extract the parameter values ​​and convert them into the parameter format required for Llama-Factory fine-tuning, including the three hyperparameters of learning rate, batch size, and number of training rounds; The dataset splitting component is used to randomly split the dataset, specifically: Determine the ratio of the training set and the evaluation set according to the evalScale parameter value in the ai.envs.train.yaml file; Use random splitting algorithm to ensure uniformity of data distribution and prevent data bias; Save the split data set into two files: training set and evaluation set; The data format conversion component is used to convert datasets in various formats into the Llama-Factory standard format. The specific implementation is as follows: Parse the original data format and extract key fields; Reorganize the data according to the format required by Llama-Factory; Ensure that the converted data is fully compatible with Llama-Factory; The fine-tuning training component supports three fine-tuning training methods, which are determined by the train_method parameter in the ai.envs.train.yaml file; Evaluation component, used to evaluate the model and output four evaluation indicators; The intermediate process monitoring component is used to monitor the task iteration progress in real time and write the real-time results in JSON file format to the path specified by output.task_result in the ai.envs.train.yaml file. It supports the client to receive and display the real-time training status through the WebSocket protocol.

7. The automatic learning engine device based on the encapsulated large model training platform according to claim 6, characterized in that: The fine-tuning training component specifically supports the following three fine-tuning methods: The LoRA fine-tuning method is as follows: Parameter update is achieved by adding the product of low-rank matrices on the basis of the original weight matrix, and a pair of trainable low-rank decomposition matrices is added for each weight matrix that needs to be updated; Assume that the original weight matrix is ​​W, with a dimension of d×k, where d is the input feature dimension and k is the output feature dimension. Introduce matrices A (with a dimension of d×r) and B (with a dimension of r×k) of rank r. The fine-tuned weight matrix becomes W+AB. During the training process, only the two low-rank matrices A and B are trained, and the original weight matrix W remains fixed; The full fine-tuning method is as follows: All parameters of the pre-trained model are treated as trainable parameters, including three types of parameters: embedding layer, multi-head attention layer, and feedforward neural network layer; Use the backpropagation algorithm to update each parameter in the model, and the update step size is controlled by the optimization algorithm based on the learning rate; The freeze fine-tuning method is as follows: Only the parameters of the last Q layers at the output of the pre-trained model are updated, where Q is set by the user and ranges from 1 to the total number of model layers minus 1. The parameters of the first P layers at the input remain fixed, where P is equal to the total number of model layers minus Q. Choose to freeze the early layers near the input and only fine-tune the later layers near the output; The automatic recommendation mechanism of fine-tuning method is as follows: Automatically recommend appropriate fine-tuning methods based on the user's task requirements, dataset size, and hardware resources; When the GPU memory of the computing resource is less than 16GB or the fine-tuning effect needs to be quickly verified, LoRA fine-tuning is recommended; When the number of training dataset samples exceeds 100,000 and the GPU memory exceeds 32GB, full fine-tuning is recommended. When the target domain of the fine-tuning task is the same as the domain of the pre-training data and only the output format or style needs to be adjusted, frozen fine-tuning is recommended; Users can manually select a fine-tuning method when creating a fine-tuning task, or the system can automatically select one based on recommendation rules.

8. The automatic learning engine device based on the encapsulated large model training platform according to claim 6, characterized in that: The evaluation component is specifically used to calculate the following four evaluation indicators: Perplexity, precision, recall, and loss; The evaluation process is specifically implemented as follows: Use the number of iterations specified in the ai.envs.train.yaml file options to train the model; After training is complete, save the model to the path specified by outputs.main in the ai.envs.train.yaml file; During evaluation, read the model under the path and use the split test set for evaluation; Write the evaluation results in JSON format to the path specified by output.task_result in the ai.envs.train.yaml file.

Images