A model selection method, a storage medium, and a computer program product

Abstract

The embodiment of the application discloses a model selection method, a storage medium and a computer program product. The model selection method comprises the following steps: in the case that a service demand sent by a medical association management device is received, a model acquisition request is sent to a target device; the service demand is carried in the model acquisition request, so that the target device finds at least one model matched with the service demand in a model library; in the case that model attribute information of the at least one model sent by the target device is received, current computing resource information is determined; the model attribute information and the computing resource information are sent to the medical association management device, so that the medical association management device determines a target model from the at least one model according to the model attribute information and the computing resource information; in the case that selection information of the target model sent by the medical association management device is received, the target model is downloaded and deployed. Through the application, the accuracy of selecting a matched large model for a medical association can be improved.

Description

Technical Field

[0001] This application relates to the field of medical large model technology, and in particular to a model selection method, storage medium, and computer program product. Background Technology

[0002] A medical consortium (or medical alliance) is a consortium composed of medical institutions of different levels and categories, aiming to achieve resource sharing, complementary advantages, and collaborative services. At the consortium level, shared computing resources and large-scale medical model services can be provided to hospitals within the consortium. This addresses the problem of hospitals lacking sufficient computing power to deploy and run large-scale medical models, while simultaneously wanting to deploy and use these models locally to meet the requirement of data remaining within the hospital premises.

[0003] In related technologies, there are various types of medical consortia, including but not limited to: urban medical groups, county-level medical consortia, specialist alliances, and telemedicine collaboration networks. Each type of medical consortium includes different hospitals, and the cooperation models between hospitals and the technical resources within the medical consortium are also different. Therefore, how to select a suitable large-scale model for medical consortia has become an urgent problem to be solved. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application aim to provide a model selection method, storage medium, and computer program product that can improve the accuracy of selecting a matching large model for a medical consortium.

[0005] The technical solution of this application is implemented as follows:

[0006] This application provides a model selection method applied to a medical consortium model deployment device, the method comprising:

[0007] Upon receiving a business request from the medical consortium management device, a model acquisition request is sent to the target device; the target device has a model library containing multiple large models; the model acquisition request carries the business request so that the target device can search the model library for at least one model that matches the business request.

[0008] Upon receiving model attribute information of at least one model sent by the target device, determine the current computing power resource information;

[0009] The model attribute information and the computing power resource information are sent to the medical consortium management device so that the medical consortium management device can determine the target model from the at least one model based on the model attribute information and the computing power resource information.

[0010] Upon receiving the target model selection information sent by the medical consortium management device, the target model is downloaded and deployed.

[0011] This application embodiment further provides a model selection method applied to a target device, the method comprising:

[0012] Upon receiving a model acquisition request from the medical consortium model deployment device, the business requirements are obtained from the model acquisition request;

[0013] Among the multiple large models in the model library, find at least one model that matches the business requirement;

[0014] Obtain model attribute information of at least one model;

[0015] The model attribute information is sent to the medical consortium model deployment device so that the medical consortium model deployment device can use the medical consortium management device to determine the target model from the at least one model based on the model attribute information and the current computing power resource information of the medical consortium model deployment device;

[0016] Upon receiving a download request for the target model from the medical consortium model deployment device, a download link for the target model is sent to the medical consortium model deployment device so that the medical consortium model deployment device can download and deploy the target model according to the download link.

[0017] This application embodiment further provides a model selection method applied to a medical consortium management device, the method comprising:

[0018] Send business requirements to the deployment equipment of the medical consortium model; the business requirements are the demand information of the medical consortium under the business corresponding to the medical big model.

[0019] Upon receiving model attribute information and computing resource information sent by the medical consortium model deployment device based on the business requirements, the target model is determined from at least one model corresponding to the model attribute information according to the model attribute information and the computing resource information.

[0020] The selection information of the target model is sent to the medical consortium model deployment device so that the medical consortium model deployment device can download and deploy the target model.

[0021] This application also provides a model selection method applied to hospital equipment, the method comprising:

[0022] A model customization request is sent to the medical consortium model deployment device. The model customization request carries first computing power resource information and first business requirements, so that the medical consortium model deployment device can determine a model deployment strategy that matches the hospital equipment based on the first computing power resource information and the first business requirements.

[0023] Receive the model deployment strategy sent by the medical consortium model deployment device;

[0024] Generate a confirmation instruction for the model deployment strategy and send the confirmation instruction to the medical consortium model deployment device;

[0025] Upon receiving the target model sent by the medical consortium model deployment device, the deployment process of the target model is executed according to the model deployment strategy.

[0026] This application provides a medical consortium model deployment device, which includes:

[0027] The first sending unit is configured to send a model acquisition request to a target device upon receiving a business requirement from a medical consortium management device; the target device is equipped with a model library including multiple large models; the model acquisition request carries the business requirement, so that the target device can search for at least one model matching the business requirement in the model library; and sends model attribute information and computing power resource information to the medical consortium management device, so that the medical consortium management device can determine the target model from the at least one model based on the model attribute information and the computing power resource information.

[0028] The first determining unit is configured to determine the current computing power resource information upon receiving model attribute information of at least one model sent by the target device.

[0029] The first deployment unit is used to download and deploy the target model upon receiving the target model selection information sent by the medical consortium management device.

[0030] This application embodiment provides a target device, the target device comprising:

[0031] The first acquisition unit is used to acquire business requirements from the model acquisition request sent by the medical consortium model deployment device upon receiving the model acquisition request; and to acquire model attribute information of at least one model.

[0032] The search unit is used to search for at least one model that matches the business requirement among multiple large models in the model library.

[0033] The second sending unit is configured to send the model attribute information to the medical consortium model deployment device, so that the medical consortium model deployment device can use the medical consortium management device to determine the target model from the at least one model based on the model attribute information and the current computing power resource information of the medical consortium model deployment device; upon receiving a download request for the target model sent by the medical consortium model deployment device, the unit sends a download link for the target model to the medical consortium model deployment device, so that the medical consortium model deployment device can download and deploy the target model according to the download link.

[0034] This application provides a medical consortium management device, which includes:

[0035] The third sending unit is used to send business requirements to the medical consortium model deployment device; the business requirements are the demand information of the medical consortium under the business corresponding to the medical big model; and to send the selection information of the target model to the medical consortium model deployment device so that the medical consortium model deployment device can download and deploy the target model.

[0036] The second determining unit is used to determine the target model from at least one model corresponding to the model attribute information based on the model attribute information and the computing power resource information when receiving model attribute information and computing power resource information sent by the medical consortium model deployment device based on the business requirements.

[0037] This application embodiment provides a hospital device, the hospital device comprising:

[0038] The fourth sending unit is used to send a model customization request to the medical consortium model deployment device. The model customization request carries first computing power resource information and first business requirements, so that the medical consortium model deployment device can determine a model deployment strategy that matches the hospital equipment based on the first computing power resource information and the first business requirements.

[0039] The first receiving unit is used to receive the model deployment strategy sent by the medical consortium model deployment device;

[0040] A generation unit is used to generate a confirmation instruction for the model deployment strategy and send the confirmation instruction to the medical consortium model deployment device;

[0041] The execution unit is used to execute the deployment process of the target model according to the model deployment strategy when it receives the target model sent by the medical consortium model deployment device.

[0042] This application provides a medical consortium model deployment device, which includes:

[0043] The system comprises a first memory, a first processor, and a first communication bus. The first memory communicates with the first processor via the first communication bus. The first memory stores a model selection program executable by the first processor. When the model selection program is executed, the model selection method described above for use in a medical consortium model deployment device is executed by the first processor.

[0044] This application embodiment provides a target device, the target device comprising:

[0045] The second memory, the second processor, and the second communication bus are connected. The second memory communicates with the second processor via the second communication bus. The second memory stores a model selection program that can be executed by the second processor. When the model selection program is executed, the model selection method applied to the target device described above is executed by the second processor.

[0046] This application provides a medical consortium management device, which includes:

[0047] The system comprises a third memory, a third processor, and a third communication bus. The third memory communicates with the third processor via the third communication bus. The third memory stores a model selection program executable by the third processor. When the model selection program is executed, the model selection method described above for use in medical consortium management devices is executed by the third processor.

[0048] This application embodiment provides a hospital device, the hospital device comprising:

[0049] The system includes a fourth memory, a fourth processor, and a fourth communication bus. The fourth memory communicates with the fourth processor via the fourth communication bus. The fourth memory stores a model selection program executable by the fourth processor. When the model selection program is executed, the model selection method described above for use in hospital equipment is executed by the fourth processor.

[0050] This application provides a storage medium storing a computer program applied to a medical consortium model deployment device, a target device, a medical consortium management device, and hospital equipment. The computer program, when executed by a first processor, implements the model selection method described above for use in the medical consortium model deployment device; when executed by a second processor, it implements the model selection method described above for use in the target device; when executed by a third processor, it implements the model selection method described above for use in the medical consortium management device; and when executed by a fourth processor, it implements the model selection method described above for use in the hospital equipment.

[0051] This application also provides a computer program product, including a computer program that can be executed by a first processor in a medical consortium model deployment device to complete the steps of the aforementioned model selection method applied to the medical consortium model deployment device; the computer program can be executed by a second processor in a target device to complete the steps of the aforementioned model selection method applied to the target device; the computer program can be executed by a third processor in a medical consortium management device to complete the steps of the aforementioned model selection method applied to the medical consortium management device; and the computer program can be executed by a second processor in a hospital device to complete the steps of the aforementioned model selection method applied to the hospital device.

[0052] This application provides a model selection method, storage medium, and computer program product. The model selection method includes: upon receiving a business requirement from a medical consortium management device, sending a model acquisition request to a target device; the target device has a model library containing multiple large models; the model acquisition request carries the business requirement, allowing the target device to search for at least one model matching the business requirement in the model library; upon receiving model attribute information of at least one model from the target device, determining the current computing power resource information; sending the model attribute information and computing power resource information to the medical consortium management device, allowing the medical consortium management device to determine the target model from the at least one model based on the model attribute information and computing power resource information; and upon receiving target model selection information from the medical consortium management device, downloading and deploying the target model. The above-described solution, upon receiving a business request from the medical consortium management device, sends a model acquisition request carrying the business request to the target device. Based on the model acquisition request, at least one model matching the business request is determined from multiple large models in the target device's model library. Upon receiving the model attribute information of at least one model from the target device, the computing power resource information of the medical consortium model deployment device under the current conditions is determined, and the model attribute information and computing power resource information are sent to the medical consortium management device. Thus, the medical consortium management device determines the target model from at least one model based on the model attribute information and computing power resource information. Upon receiving the target model selection information from the medical consortium management device, the large model matching the medical consortium corresponding to the medical consortium model deployment device (i.e., the target model) is determined, thereby improving the accuracy of selecting a matching large model for the medical consortium. Attached Figure Description

[0053] Figure 1 A model selection method flow provided in the embodiments of this application Figure 1 ;

[0054] Figure 2 An exemplary model selection method flow provided in this application embodiment Figure 1 ;

[0055] Figure 3 An exemplary model selection method flow provided in this application embodiment Figure 2 ;

[0056] Figure 4 An exemplary model selection method flow provided in this application embodiment Figure 3 ;

[0057] Figure 5 An exemplary model selection method flow provided in this application embodiment Figure 4 ;

[0058] Figure 6 An exemplary model selection method flow provided in this application embodiment Figure 5 ;

[0059] Figure 7 A model selection method flow provided in the embodiments of this application Figure 2 ;

[0060] Figure 8 A model selection method flow provided in the embodiments of this application Figure 3 ;

[0061] Figure 9 A model selection method flow provided in the embodiments of this application Figure 4 ;

[0062] Figure 10 A schematic diagram illustrating an exemplary multi-level medical large-scale model deployment application architecture provided for embodiments of this application;

[0063] Figure 11 A schematic diagram of the composition structure of a medical consortium model deployment device provided in this application embodiment. Figure 1 ;

[0064] Figure 12 A schematic diagram of the composition structure of a medical consortium model deployment device provided in this application embodiment. Figure 2 ;

[0065] Figure 13 A schematic diagram of the composition structure of a target device provided in an embodiment of this application. Figure 1 ;

[0066] Figure 14 A schematic diagram of the composition structure of a target device provided in an embodiment of this application. Figure 2 ;

[0067] Figure 15 A schematic diagram of the composition structure of a medical consortium management device provided in this application embodiment. Figure 1 ;

[0068] Figure 16 A schematic diagram of the composition structure of a medical consortium management device provided in this application embodiment. Figure 2 ;

[0069] Figure 17 A schematic diagram of the composition structure of a hospital device provided in this application embodiment. Figure 1 ;

[0070] Figure 18 A schematic diagram of the composition structure of a hospital device provided in this application embodiment. Figure 2 . Detailed Implementation

[0071] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0072] This application provides a model selection method, which is applied to a medical consortium model deployment device. Figure 1 A flowchart of a model selection method provided in this application embodiment is shown below. Figure 1 As shown, model selection methods may include:

[0073] S101. Upon receiving a business request from the medical consortium management device, a model acquisition request is sent to the target device. The target device has a model library containing multiple large models. The model acquisition request carries the business request so that the target device can search for at least one model in the model library that matches the business request.

[0074] The model selection method provided in this application embodiment is applicable to scenarios where a target model corresponding to a medical consortium is determined.

[0075] In the embodiments of this application, the medical consortium model deployment device can be implemented in various forms. For example, the medical consortium model deployment device described in this application may include a core network, network elements, cloud services, etc., or other types; the specific embodiments of this application do not limit this.

[0076] In this embodiment of the application, the medical consortium management device can be a medical consortium Model as a Service (NaaS) platform.

[0077] In this embodiment, business requirements can be the needs of the medical consortium under the corresponding business of the large medical model. Business requirements may include information such as a list of application scenarios, a list of required functions, and concurrency requirements. Specific business requirements can be determined according to the circumstances, and this embodiment does not limit them.

[0078] It should be noted that the application scenario list refers to a list of intelligent application scenarios based on the medical big data model, such as intelligent consultation, intelligent follow-up, and intelligent emergency care. The mandatory function list refers to a list of essential functions in the intelligent application scenarios based on the medical big data model, such as automatic medical record generation, treatment plan recommendation, automatic patient health profile generation, automatic rehabilitation plan generation, and quality control of medical records and test reports. The concurrency requirement refers to the concurrency requirements for intelligent applications accessing the medical big data model.

[0079] For example, the information included in the business requirements is shown in Table 1:

[0080] Table 1

[0081]

[0082] In this embodiment of the application, the target device can be a device with a model library. The specific target device can be determined according to the actual situation, and this embodiment of the application does not limit it.

[0083] In this embodiment, the model library integrates a collection of machine learning models with various large-scale parameters and complex structures. It may include general-purpose large models (i.e., basic large models L0) and industry-specific large models (i.e., L1), or other models. The specific models in the model library can be determined according to actual circumstances, and this embodiment does not limit this. The model library in this application includes one or more L1 medical large models (possibly provided by multiple vendors).

[0084] In the embodiments of this application, at least one model is a portion of a plurality of large models.

[0085] In the embodiments of this application, both the basic large model and the industry large model belong to the category of multi-level industry large models. Multi-level industry large models refer to a series of large models with specific functions and performances constructed through pre-training, fine-tuning, and other methods to meet the needs of different industries and different levels. These models form multiple levels, ranging from generality to specialization, and from generalization ability to refined processing, in order to better serve various industries and fields.

[0086] Among them, multi-level industry large models can usually be divided into basic large models, industry large models, vertical large models (L2), and industry small models.

[0087] It should be noted that the basic large model is a basic general-purpose model for multiple industries and scenarios. It has the characteristics of versatility (the basic large model is the foundation for building other levels of models and has a wide range of versatility and generalization ability), data scale (the basic large model is usually trained with massive amounts of open data, and the number of parameters is huge, possibly reaching billions, tens of billions or even hundreds of billions of parameters) and capabilities (the basic large model can handle a variety of tasks and scenarios and has powerful natural language understanding, generation and reasoning capabilities).

[0088] It's important to note that industry-specific large-scale models are large-scale AI models that have been deeply optimized and customized for specific industries or fields. They possess characteristics such as industry specificity (the core feature of industry-specific large-scale models is their industry focus; they concentrate on a particular industry, deeply understanding its business processes, data characteristics, and industry knowledge, thereby providing more accurate and effective solutions), high performance and accuracy (through large-scale data pre-training and fine-tuning, L1 industry-specific large-scale models demonstrate superior performance and high accuracy on specific industry tasks. They can handle complex industry data, extract key information, and make accurate predictions and decisions), and scalability and customizability (industry-specific large-scale models have good scalability and customizability. Users can further optimize and customize the model according to actual needs to meet application requirements in specific scenarios).

[0089] It should be noted that vertical large models are large-scale artificial intelligence models that are deeply optimized and trained for a specific domain or task. They have the characteristics of strong targeting (vertical large models are designed for a specific domain, such as medicine, finance, law, etc., to meet the specific needs of the domain), professional datasets (vertical large models are trained using high-quality datasets for specific domains, ensuring that the model has a deep understanding and mastery of the domain), efficiency (in specific tasks or domains, L2 vertical large models can provide efficient and accurate solutions, and outperform general large models in specific tasks), and relatively low computational resource consumption (compared to general large models, L2 vertical large models require less computational resources during training and inference, which helps to reduce costs).

[0090] It should be noted that industry-specific small models refer to machine learning or deep learning models built based on data from specific industry scenarios. They have a smaller number of parameters and lower computational complexity, representing a lightweight solution compared to large-scale models. These models feature smaller parameter counts and simpler model structures (designed and trained for specific industries or business needs, relatively small in scale but focused on solving problems in specific domains), higher accuracy and specialization for specific industries or tasks (capturing subtle differences and complex relationships within the domain, providing more precise services), relatively lower requirements for computing and storage resources (small models are smaller in scale, making them easier to deploy and apply in resource-constrained environments), and simpler training processes (due to their small size and focus on specific domains, industry-specific small models have a relatively simple training process, allowing for training and optimization with less training data and shorter training time).

[0091] In this embodiment, the medical consortium management device is a device used to manage the medical consortium model deployment device. For example, the medical consortium model deployment device can be a medical consortium MaaS platform, and the medical consortium management device can be a medical consortium management platform.

[0092] S102. Upon receiving model attribute information of at least one model sent by the target device, determine the current computing power resource information.

[0093] In this embodiment of the application, after the medical consortium model deployment device sends a model acquisition request to the target device, it determines the current computing power resource information upon receiving model attribute information of at least one model sent by the target device.

[0094] In this embodiment, the model attribute information includes model producer information, model function information, model scale information, model application scenario information, model computing resource requirements information, model performance information, model advantages and disadvantages information, and model value. For example, the model attribute information includes the model provider (i.e., model producer information), supported application scenarios (model application scenario information), scale (model scale information), computing resource requirements (model computing resource requirements information), performance (model performance information), price (model value), and advantages (model advantages and disadvantages information). The model attribute information may also include other information. The specific information included in the model attribute information can be determined according to actual circumstances, and this embodiment does not limit this.

[0095] It should be noted that "Provider" refers to the vendor that provides the L1 medical big data model (i.e., any one of the models in at least one model). "Supported application scenarios" refers to the list of application scenarios supported by the L1 medical big data model, such as intelligent consultation, intelligent follow-up, and intelligent emergency care. "Supported function list" refers to the list of functions supported by the L1 medical big data model, such as automatic medical record generation, treatment plan recommendation, automatic patient health profile generation, automatic rehabilitation plan generation, and quality control of medical records and test reports. "Scale" is a data representation of the scale of the L1 medical big data model, including but not limited to: the number of parameters, the size of the dataset used for model training, model depth (number of layers), and model width (number of neurons / layer). Computing resource requirements refer to the computing resources required for the deployment and operation of this L1 medical big data model, including but not limited to: computing resource type (general computing power, intelligent computing power, and supercomputing power, etc.), hardware type (such as Graphics Processing Unit (GPU), Tensor Processing Unit (TPU), Central Processing Unit (CPU)), hardware model, hardware quantity, storage system requirements, operating environment (such as containerization, virtualization), operating system, and network bandwidth. Performance refers to the performance characteristics of the L1 medical big data model expressed through one or more evaluation metrics, including but not limited to: accuracy, recall, and F1 score. Price refers to the selling price of the L1 medical big data model. Advantages refer to the advantages of the L1 medical big data model, usually summarized by the vendor and listed compared to other L1 medical big data models.

[0096] In this embodiment of the application, an exemplary model attribute information is shown in Table 2:

[0097] Table 2

[0098]

[0099] It should be noted that computing power resources refer to computing capabilities, which can be defined as the ability of nodes with computing capabilities in a network to process data and output specific results. Computing power resources specifically include resources such as CPU, GPU, memory, and storage.

[0100] As shown in Table 3, the metrics for CPUs include model, clock speed, number of cores, number of threads, power consumption, and cache; the metrics for GPUs include model, CUDA cores, video memory, single-precision floating-point performance, and INT8 performance.

[0101] Table 3

[0102]

[0103] In the embodiments of this application, as shown in Table 4: the indicators included in memory are memory capacity and memory bandwidth; the indicators included in storage are storage capacity, storage bandwidth, number of read / write operations per second (IOPS), and response time.

[0104] Table 4

[0105]

[0106] Computing power resources are generally categorized into three types based on application scenarios: general computing power, intelligent computing power, and supercomputing power. General computing power is a widely applicable and flexible computing capability capable of handling various types of computing tasks. It is primarily based on general-purpose computing units such as CPUs, supplemented by accelerators such as GPUs to enhance performance. It performs excellently in handling routine computing tasks, but may struggle with large-scale parallel computing or high-precision tasks. Intelligent computing power is specifically designed for artificial intelligence and machine learning tasks. It is typically provided by dedicated hardware such as GPUs, Application Specific Integrated Circuits (ASICs), and Field Programmable Gate Arrays (FPGAs). It offers significant advantages in handling artificial intelligence tasks, providing higher computing performance and lower latency. Supercomputing power is the computing power provided by high-performance computing clusters such as supercomputers. Its advantages lie in its high-performance computing and large-scale data processing capabilities, but its construction and maintenance costs are extremely high, and it requires a large power supply. Therefore, it is mainly used in large-scale scientific research projects and major national-level tasks.

[0107] In this embodiment, the method by which the medical consortium model deployment device determines its current computing resource information is existing technology, and this embodiment does not limit it.

[0108] S103. Send model attribute information and computing resource information to the medical consortium management device so that the medical consortium management device can determine the target model from at least one model based on the model attribute information and computing resource information.

[0109] In this embodiment of the application, after the medical consortium model deployment device determines the current computing power resource information, it sends the model attribute information and computing power resource information to the medical consortium management device.

[0110] In this embodiment of the application, the process of the medical consortium model deployment device sending model attribute information and computing power resource information to the medical consortium management device includes: determining at least one compression ratio and at least one compressed model performance when deploying at least one model based on the computing power resource information; adding at least one compression ratio and at least one compressed model performance to the model attribute information to obtain the added model attribute information; and sending the added model attribute information to the medical consortium management device.

[0111] It should be noted that at least one model corresponds to at least one compression ratio; that is, one model corresponds to one compression ratio.

[0112] It should be noted that at least one compressed model performance corresponds one-to-one with at least one model, that is, one model corresponds to one compressed model performance.

[0113] In this embodiment, the medical consortium management device can determine a suitable L1 medical model (i.e., determine the target model) based on the matching degree between user needs (including business needs) and the added model attribute information (i.e., L1 medical large model information). The L1 medical large model selection matching rules are shown in Table 5:

[0114] Table 5

[0115]

[0116] It should be noted that user requirements include information such as model producer information (e.g., a list of designated manufacturers), model application scenario information and model function information (e.g., application scenarios and required functions), acceptable compression ratio, model performance information (performance requirements), and model value (price range).

[0117] S104. Upon receiving the target model selection information sent by the medical consortium management device, download and deploy the target model.

[0118] In this embodiment of the application, after the medical consortium model deployment device sends model attribute information and computing resource information to the medical consortium management device, it downloads and deploys the target model upon receiving the target model selection information sent by the medical consortium management device.

[0119] In the embodiments of this application, the number of target models can be one or more. The specific number of target models can be determined according to the actual situation, and the embodiments of this application do not limit this.

[0120] In this embodiment of the application, the process of the medical consortium model deployment device downloading and deploying the target model includes: downloading the target model from the target device; and deploying the target model in the cloud of the medical consortium model deployment device according to the computing power resource information.

[0121] In this embodiment, the medical consortium model deployment device can first send a download request to the target device to download the target model, the target device sends a download link to the medical consortium model deployment device to download the target model, and the medical consortium model deployment device downloads the target model according to the download link, thereby obtaining the target model.

[0122] In this embodiment of the application, after the medical consortium model deployment device obtains the target model, it deploys the target model in the cloud of the medical consortium model deployment device according to the computing power resource information.

[0123] It should be noted that if the computing resource information indicates that the target model needs to be compressed for deployment, then after downloading the target model, the model will be compressed first before the deployment operation is performed. If the computing resource information indicates that the target model does not need to be compressed for deployment, then after downloading the target model, the deployment operation will be performed directly.

[0124] It should also be noted that the method of compressing the target model can be determined according to the actual situation, and this application embodiment does not limit it.

[0125] In this embodiment, the medical consortium model deployment device can deploy the target device to the cloud. Upon completion of the deployment of the target model, the medical consortium model deployment device sends a deployment success notification to the medical consortium management device.

[0126] For example, such as Figure 2 As shown:

[0127] 1. The medical consortium management platform (medical consortium management device) inputs business requirements into the medical consortium MaaS platform (medical consortium model deployment device) (i.e., the medical consortium model deployment device receives business requirements sent by the medical consortium management device). These business requirements represent the medical consortium's demand information for intelligent services based on the medical big data model.

[0128] 2. The medical consortium MaaS platform sends a request to the model library (i.e., the target device) to obtain a list of L1 medical large models (i.e., send a model acquisition request to the target device), carrying business requirement information (i.e., the model acquisition request carries business requirements); the model library (target device) sends a list of L1 medical large models that meet the business requirements to the medical consortium MaaS platform (i.e., the target device sends model attribute information of at least one model to the medical consortium model deployment device);

[0129] 3. After receiving the L1 medical large model list from the model library (i.e., the model attribute information of at least one model sent by the target device to the medical consortium model deployment device), the medical consortium MaaS platform will calculate the compression ratio (ranging from 0% to 100%) and compressed performance required for each L1 medical large model in the list when deployed in the medical consortium cloud, based on the currently available computing resources in the medical consortium cloud (i.e., the current computing resources). Then, these calculated compression ratios and compressed performance values ​​will be added to the information of the corresponding L1 medical large model (i.e., at least one compression ratio and at least one compressed model performance value will be added to the model attribute information to obtain the added model attribute information). Subsequently, the medical consortium MaaS platform will send the integrated L1 medical large model list to the medical consortium management platform (i.e., send the added model attribute information to the medical consortium management device).

[0130] 4. The medical consortium management platform determines a suitable L1 medical big model based on the matching degree between user needs and model information (that is, the medical consortium management device determines the target model from at least one model based on model attribute information and computing power resource information), and sends the target model selection information to the medical consortium MaaS platform (sending the selection result);

[0131] 5. The medical consortium MaaS platform orders (L1 medical large model order) from the model library and downloads (L1 medical large model download) the L1 medical large model selected by the medical consortium management platform. Then, it adjusts the L1 medical large model based on cloud computing resources and completes the deployment. Specifically, if the computing resources required by the model are greater than the current available cloud computing resources, the MaaS platform will use model compression technology to adjust the downloaded L1 medical large model to a scale that can be met by the current available cloud computing resources (that is, if it is determined that the target model needs to be compressed and deployed based on the computing resources information, and the target model has been downloaded, the target model will be compressed first and then the model deployment operation will be performed).

[0132] 6. The medical consortium MaaS platform deploys the L1 medical big data model and sends a deployment completion notification to the medical consortium management platform.

[0133] In this embodiment of the application, after the medical consortium model deployment device downloads and deploys the target model, upon receiving a model customization request sent by the hospital device, it determines a model deployment strategy matching the hospital device based on the first computing power resource information and the first business requirement in the model customization requirements; sends the model deployment strategy to the hospital device; and upon receiving confirmation instructions from the hospital device regarding the model deployment strategy, deploys the target model for the hospital device according to the model deployment strategy.

[0134] In this embodiment of the application, the hospital equipment can be the hospital information system of the hospital.

[0135] It should be noted that the first computing resource information refers to the computing resource information of the hospital equipment; the first business requirement refers to the business requirement of the hospital equipment.

[0136] In this embodiment, the first business requirement includes a hospital ID, an application scenario list, a mandatory function list, concurrency requirements, large model performance requirements, and security requirements. The hospital ID refers to the hospital's unique identifier within the medical consortium. The application scenario list refers to the list of intelligent application scenarios the hospital expects to implement based on the medical large model, such as intelligent consultation, intelligent follow-up, and intelligent emergency care. The mandatory function list refers to the list of functions the hospital expects to implement based on the medical large model, such as automatic medical record generation, treatment plan recommendation, automatic patient health profile generation, automatic rehabilitation plan generation, and quality control of medical records and test reports. The concurrency requirement refers to the hospital's expected support for the number of concurrent users accessing the medical large model. The large model performance requirements refer to the hospital's performance requirements for the medical large model, including but not limited to accuracy, precision, and inference speed. The security requirements refer to whether the hospital can accept some or all data leaving the hospital premises for training and inference in the cloud.

[0137] In this embodiment of the application, an exemplary first computing power resource information and a first business requirement are shown in Table 6:

[0138] Table 6

[0139]

[0140] It should be noted that the edge computing resource information in Table 6 is the first computing resource information, which refers to the computing resource information currently available in the hospital, including but not limited to: computing resource type (general computing, intelligent computing), hardware type (such as GPU, TPU, CPU), hardware model, hardware quantity, storage system capacity, operating system, and network bandwidth.

[0141] In this embodiment, the model deployment strategy can be a strategy configured in the medical consortium model deployment device, a strategy transmitted from other devices to the medical consortium model deployment device, or a strategy obtained by the medical consortium model deployment device through other means. The specific way in which the medical consortium model deployment device obtains the model deployment strategy can be determined according to the actual situation, and this embodiment does not limit it.

[0142] It should be noted that there can be multiple model deployment strategies, and the specific number of model deployment strategies can be determined according to the actual situation. This application embodiment does not limit this.

[0143] For example, the number of model deployment strategies can be four: no compression of the target model, compression of the target model according to a first preset compression ratio, compression of the target model according to a second preset compression ratio, and no deployment of the model at the hospital.

[0144] In this embodiment, the process of the medical consortium model deployment device deploying a target model for hospital equipment according to a model deployment strategy includes: when the model deployment strategy is to not compress the target model, sending the model information of the target model to the hospital equipment for deployment; when the model deployment strategy is to compress the target model according to a first preset compression ratio, compressing the target model according to the first preset compression ratio to obtain a large medical model; when the model deployment strategy is to compress the target model according to a second preset compression ratio, compressing the target model into a small medical model according to the second preset compression ratio; sending the large medical model or the small medical model to the hospital equipment for deployment; and when the model deployment strategy is not to deploy the model at the hospital, configuring a model calling interface for the hospital equipment for calling the target model according to the model calling interface.

[0145] In this embodiment, the first preset compression ratio and the second preset compression ratio are different. The first preset compression ratio results in a smaller compression degree on the target model than the second preset compression ratio.

[0146] It should be noted that the model call interface can be an application programming interface (API) interface, or it can be other interfaces. The specific model call interface can be determined according to the actual situation, and this application embodiment does not limit it.

[0147] In this embodiment, the process of determining a model deployment strategy matching hospital equipment based on the first computing power resource information and the first business requirement in the model customization requirements includes: if the first computing power resource information includes intelligent computing power resources and the first computing power resource corresponding to the intelligent computing power resources is greater than the computing power resources required to deploy and run the target model, the model deployment strategy is to not compress the target model; if the first computing power resource information includes intelligent computing power resources and the first computing power resource corresponding to the intelligent computing power resources is less than or equal to the computing power resources required to deploy and run the target model, the model deployment strategy is to compress the target model according to a first preset compression ratio; if the first computing power resource information includes general computing power resources but does not include intelligent computing power resources, the model deployment strategy is to compress the target model according to a second preset compression ratio; if the first computing power resource information corresponds to a computing power resource threshold that is less than or equal to the computing power resource threshold and the first business requirement identifier allows processing of hospital equipment business data on the side of the medical consortium model deployment device, the model deployment strategy is to not deploy the model at the hospital.

[0148] In this embodiment of the application, if the computing power resources of the hospital equipment are sufficient to deploy and run the target model (i.e., the first computing power resource information includes intelligent computing power resources, and the first computing power resources corresponding to the intelligent computing power resources are greater than the computing power resources required to deploy and run the target model), then the model deployment strategy is determined to be not to compress the target model.

[0149] In this embodiment, when the hospital equipment possesses certain intelligent computing resources, but these resources are insufficient to support the deployment and operation of the uncompressed target model (i.e., the first computing resource information includes intelligent computing resources, and the first computing resources corresponding to the intelligent computing resources are less than or equal to the computing resources required to deploy and operate the target model), the model deployment strategy is determined to compress the target model according to a first preset compression ratio. This means that customized compression (according to the first preset compression ratio) is performed on the edge-side computing resources of the hospital equipment (i.e., the first computing resource information). Compression methods such as knowledge distillation, low-rank decomposition, and parameter sharing can be used to compress the target model, appropriately reducing the model's complexity and computational load.

[0150] In this embodiment, when the hospital equipment only possesses certain general computing power resources but lacks intelligent computing power resources, thus failing to support the deployment and operation of the target model (i.e., the first computing power resource information includes general computing power resources but does not include intelligent computing power resources), the model deployment strategy is determined to compress the target model according to a second preset compression ratio. Specifically, the L1 medical large model is compressed into a medical small model based on the edge-side computing power resources of the hospital equipment (i.e., the first computing power resource information) (i.e., the target model is compressed into a medical small model according to the second preset compression ratio). For example, compression methods such as model pruning and quantization can be used, with a compression ratio typically ranging from 10% to 50%, and in extreme cases, it can be compressed to a fraction of the target model's size.

[0151] In this embodiment of the application, when the hospital's computing power resources are severely insufficient and some or all data are allowed to leave the hospital area (i.e., the first computing power resource corresponding to the first computing power resource information is less than or equal to the computing power resource threshold, and the first business demand identifier allows the processing of the hospital equipment's business data on the medical consortium model deployment device side), the model deployment strategy is determined to be not to deploy the model at the hospital end, that is, not to deploy the large / small medical model locally, and to provide model services by the cloud (i.e., to configure the model call interface for the hospital equipment so that the hospital equipment can call the target model according to the model call interface).

[0152] For example, such as Figure 3 As shown:

[0153] 1. The hospital (hospital equipment) sends a request to the medical consortium MaaS platform (medical consortium model deployment equipment) to customize a local medical model (i.e., the hospital equipment sends a model customization request to the medical consortium model deployment equipment carrying the first computing power resource information (edge ​​computing power resources) and the first business requirement (business requirement). The sending method can be to log in to the MaaS platform management system to enter the information, or to send a request message through the hospital's hospital information system.

[0154] 2. After receiving a request from a hospital, the medical consortium MaaS platform determines a large-scale model deployment strategy for that hospital based on the hospital's edge computing resources and business needs (i.e., determining a model deployment strategy that matches the hospital's equipment based on the first computing resource information and the first business needs in the model customization requirements), including but not limited to the following:

[0155] A. Deploy Uncompressed-LLM Healthcare Model: This strategy is recommended if the hospital has sufficient computing resources to deploy and run an uncompressed-LLM healthcare model.

[0156] B. Deploy the compressed L1 medical big model (Compressed-LLM): If the hospital has certain intelligent computing resources, but not enough to support the deployment and operation of the uncompressed L1 medical big model, this strategy is recommended. That is, to customize the compression of the hospital's edge computing resources. Compression methods such as knowledge distillation, low-rank decomposition, and parameter sharing can be used to appropriately reduce the complexity and computation of the model.

[0157] C. Deployment of Small-Model Medical Models: When hospitals only have certain general computing power resources but lack intelligent computing power resources, thus failing to support the deployment and operation of large-scale L1 medical models, this strategy is recommended. This involves compressing the large-scale L1 medical model into small-scale medical models using the hospital's edge computing resources. Compression methods such as model pruning and quantization can be used. The compression ratio is usually 10% to 50%, and in extreme cases, it can be compressed to a fraction of the original large model.

[0158] D. Non-Local Deployment: This strategy is recommended when hospital computing resources are severely insufficient and some or all data can be taken out of the hospital area. This means that large / small medical models are not deployed locally and the model services are provided by the cloud.

[0159] 3. The medical consortium MaaS platform sends the hospital's medical big data model deployment strategy to the hospital (the medical consortium model deployment device sends the model deployment strategy to the hospital's device). After the user confirms, feedback is sent back to the MaaS platform (a confirmation instruction for the model deployment strategy is sent to the medical consortium model deployment device).

[0160] 4. After receiving the user's confirmed strategy (receiving the hospital's confirmation instruction on the model deployment strategy), the medical consortium MaaS platform will, if the strategy is Uncompressed-LLM, send the uncompressed L1 medical large model to the hospital (i.e., send the target model's model information to the hospital's equipment); if the strategy is Compressed-LLM, customize a compressed L1 medical large model for the hospital and send it to the hospital (send the medical large model to the hospital's equipment); if the strategy is Small-Model, customize a compressed medical small model for the hospital and send it to the hospital (send the medical small model to the hospital's equipment); if the strategy is Non-Local, no processing will be done, and the hospital will call the API interface to use the cloud-based large model (i.e., configure a model call interface for the hospital's equipment so that the hospital's equipment can call the target model according to the model call interface).

[0161] 5. After obtaining the customized medical large / small model from the medical consortium MaaS platform, the hospital completes the deployment locally (i.e., deploys the customized medical large / small model).

[0162] In this embodiment, after the medical consortium model deployment device deploys the target model for the hospital equipment according to the model deployment strategy, upon receiving the model feedback instruction sent by the medical consortium management device, it sends a model subscription request for a preset business domain to the hospital equipment carried in the model feedback instruction; upon receiving the first model sent by the hospital equipment based on the model subscription request, it obtains the model features corresponding to the preset business domain from the first model; and adjusts the target model according to the model features.

[0163] In this embodiment of the application, the model feedback instruction is an instruction that the target model in the medical consortium model deployment device needs to be adjusted based on the model obtained after training the target model in the hospital equipment or the model updated after training the target model.

[0164] It should be noted that the preset business domain is the information carried in the model feedback instruction; the first model is the model obtained after the hospital equipment trains or updates the target model.

[0165] In this embodiment, if the target model is deployed on the hospital equipment, the first model can be the model obtained by the hospital equipment training the target model using training data from the hospital side, or the model obtained by the hospital equipment updating the trained target model later. If the large medical model is deployed on the hospital equipment, the first model can be the model obtained by the hospital equipment training the large medical model using training data from the hospital side, or the model obtained by the hospital equipment updating the trained large medical model later. If the small medical model is deployed on the hospital equipment, the first model can be the model obtained by the hospital equipment training the small medical model using training data from the hospital side, or the model obtained by the hospital equipment updating the trained small medical model later.

[0166] In this application embodiment, the preset business domain is specifically a preset disease or discipline.

[0167] In this embodiment, the model feedback instruction carries identification information of the hospital equipment. The hospital equipment can be identified based on the identification information, and then a model subscription request for a preset business domain can be sent to the hospital equipment.

[0168] It should be noted that the identification information specifically refers to the identification information of one or more hospitals that have a strong professional foundation in the preset disease or discipline and have a large number of patients.

[0169] In this embodiment of the application, the model features may be information such as relevant parameters or features of a preset disease or discipline carried in the first model.

[0170] In this embodiment, the medical consortium model deployment device can use knowledge transfer and other technical means to extract model features from the first model and transfer relevant parameters and features of specific diseases or disciplines (i.e., model features) to the cloud-based medical big model (i.e., adjust the target model according to the model features) to enhance the cloud-based medical big model's professional knowledge and experience in related diseases or disciplines; other medical institutions within the medical consortium can also conveniently call the cloud-based big model to perform reasoning tasks related to the disease or discipline, thereby improving the accuracy and efficiency of their own diagnosis and treatment of the disease / discipline.

[0171] In this embodiment of the application, when the medical consortium model deployment device receives the model feedback instruction sent by the medical consortium management device, it will also send a response message to the medical consortium management device indicating that the model feedback instruction has been received.

[0172] In this embodiment, the hospital (hospital equipment) trains a large / small medical model (i.e., target model, large medical model, or small medical model) obtained from the medical consortium MaaS platform (medical consortium model deployment equipment) based on local data (training data), generating a local L2 large medical model or a local small medical model (first model). The hospital can upload the locally trained edge-side model to the MaaS platform, and the MaaS platform extracts experience from it to feed back into the cloud-based L1 large medical model. For example, as shown... Figure 4 As shown:

[0173] 1. The hospital information system (hospital equipment) trains and fine-tunes the model based on local data (training the edge-side medical model based on local data) to form an L2 medical large model or medical small model (i.e., the first model) that is more suitable for local business.

[0174] 2. To improve the overall diagnostic and treatment level of pre-defined diseases or disciplines within the medical consortium, the medical consortium management platform (medical consortium management equipment) selects one or more hospitals (hospital equipment) with a strong professional foundation and high patient volume in that disease or discipline to provide experience feedback to the medical consortium's cloud-based L1 medical big data model. Specifically, the medical consortium management platform sends edge-side medical model subscription and feedback instructions to the medical consortium MaaS platform (medical consortium model deployment equipment) (the medical consortium model deployment equipment receives the model feedback instructions sent by the medical consortium management equipment). This includes, but is not limited to: pre-defined disease or discipline information (pre-defined business areas), a list of hospital IDs (identification information), and a list of hospital destination addresses (including but not limited to: IP address, URL, domain name). The platform also receives response information from the medical consortium MaaS platform based on these edge-side medical model subscription and feedback instructions.

[0175] 3. The medical consortium MaaS platform sends a request to the hospital devices to subscribe to the edge-side medical model. Specifically, the medical consortium MaaS platform subscribes to the edge-side medical model for each hospital in the list specified by the medical consortium management platform (the medical consortium model deployment device sends a model subscription request for the preset business domain to the hospital devices carried in the model feedback instruction). After successful subscription, the hospital sends the latest edge-side medical model to the medical consortium MaaS platform when the initial subscription is made or when there are subsequent updates to the edge-side medical model (the hospital sends the first model to the medical consortium model deployment device based on the model subscription request).

[0176] 4. After obtaining edge-side medical models from hospitals listed on the medical consortium management platform, the MaaS platform of the medical consortium learns from the experience of the edge-side medical model group to optimize the local L1 medical big model. Specifically, using knowledge transfer and other technologies, it extracts relevant parameters and characteristics of specific diseases or disciplines specified by the medical consortium management platform from the edge-side medical models (i.e., obtains model features corresponding to the preset business domain from the first model) and migrates them to the cloud-based medical big model (i.e., adjusts the target model according to the model features) to enhance the professional knowledge and experience of the cloud-based medical big model in related diseases or disciplines. Other medical institutions within the medical consortium can easily call the cloud-based big model to perform inference tasks related to the disease or discipline, thereby improving the accuracy and efficiency of their own diagnosis and treatment of the disease / discipline.

[0177] In this embodiment, after the medical consortium model deployment device deploys the target model for the hospital equipment according to the model deployment strategy, it also sends an update notification request for the target model to the target equipment; upon receiving the update notification information for the target model sent by the target equipment, it sends an update notification information to the medical consortium management device; upon receiving an update instruction sent by the medical consortium management device, it sends an update request for the target model to the target equipment; it receives the updated target model sent by the target equipment based on the update request; it adjusts the updated target model according to the computing power resource information to obtain a second model, and deploys the second model in the cloud of the medical consortium model deployment device.

[0178] It should be noted that the updated target model is the model obtained after the target device performs the update operation on the target model.

[0179] In this embodiment of the application, after the medical consortium model deployment device sends an update notification request for the target model to the target device, the target device will send response information to the medical consortium model deployment device based on the update notification request for the target model.

[0180] In this embodiment of the application, the update notification information of the target model carries the content information of the target model upgrade.

[0181] In this embodiment, the medical consortium model deployment device sends an update notification to the medical consortium management device for display. When the user learns of the update notification on the medical consortium management device, they can determine whether to update the target model on the medical consortium model deployment device based on the actual situation. If an update is determined, an update instruction is input to the medical consortium management device. Upon receiving the update instruction, the medical consortium management device sends the update instruction to the medical consortium model deployment device.

[0182] In this embodiment, when the medical consortium management device receives an update notification from the medical consortium model deployment device, the medical consortium management device may independently determine whether to update the target model on the medical consortium model deployment device side based on the update notification. If an update is determined, an update instruction may be sent to the medical consortium model deployment device. The specific method by which the medical consortium management device determines whether to update the target model on the medical consortium model deployment device side can be determined according to the actual situation, and this embodiment does not limit this.

[0183] In this embodiment of the application, the medical consortium model deployment device can deploy a second model in the cloud in a manner similar to deploying a target model in the cloud.

[0184] In this embodiment, when the medical consortium model deployment device determines, based on computing resource information, that the updated target model needs to be compressed and deployed, it first compresses the updated target model to obtain a second model, and then deploys the second model in the cloud. Conversely, when the computing resource information determines that the updated target model does not need to be compressed and deployed, the updated target model is used as the second model, and then deployed in the cloud.

[0185] It should be noted that the method of compressing the updated target model can be determined according to the actual situation, and this application embodiment does not limit it.

[0186] In this embodiment of the application, the method by which the medical consortium model deployment device receives the updated target model sent by the target device based on the update request includes: receiving the upgrade model download address sent by the target device based on the update request, and downloading the updated target model from the download address.

[0187] In this embodiment of the application, the process of deploying a second model on the cloud of the medical consortium model deployment device includes: verifying the second model and obtaining verification results; testing the second model and obtaining test results; and deploying the second model on the cloud of the medical consortium model deployment device if both the verification results and the test results indicate that the second model is correct.

[0188] In this embodiment of the application, the method of verifying the second model and obtaining the verification result can be determined according to the actual situation, and this embodiment of the application does not limit it.

[0189] In this embodiment of the application, the second model is tested, and the test results can be determined according to the actual situation. This embodiment of the application does not limit this.

[0190] In this embodiment of the application, if the verification test of the second model passes, the second model is determined to be error-free, that is, both the verification result and the test result indicate that the second model is error-free.

[0191] In this embodiment of the application, after the medical consortium model deployment device deploys the second model in the cloud, it sends the second model to the hospital device so that the hospital device can deploy the second model according to the model deployment strategy.

[0192] In this embodiment, the method of sending the second model to the hospital device is the same as the method of sending the target model to the hospital device. Specifically, if the hospital device's model deployment strategy is not to compress the second model, the model information of the second model is sent to the hospital device for deployment; if the hospital device's model deployment strategy is to compress the second model according to a first preset compression ratio, the second model is compressed according to the first preset compression ratio to obtain a large medical model; if the model deployment strategy is to compress the second model according to a second preset compression ratio, the second model is compressed into a small medical model according to the second preset compression ratio; then, the large medical model or the small medical model is sent to the hospital device for deployment.

[0193] In this embodiment, after the L1 medical big data model (target model) in the target device is upgraded, the medical consortium MaaS platform (medical consortium model deployment device) obtains the latest L1 medical big data model (updated target model) and synchronously updates the cloud-based medical big data model (cloud-based target model) and the edge-side medical model (model at the hospital equipment). For example, as shown... Figure 5 As shown:

[0194] 1. The medical consortium MaaS platform (medical consortium model deployment device) subscribes to the upgrade notification of the L1 medical large model it subscribed to from the large model library (target device) (i.e., sends the target model update notification request to the target device). Then, the large model will send a response message (return) to the medical consortium MaaS platform based on the subscription of the L1 medical large model upgrade notification. When the L1 medical large model corresponding to the large model library is upgraded, the large model library will send an upgrade notification to the medical consortium MaaS platform (i.e., the target device sends the target model update notification information to the medical consortium model deployment device), carrying the content information of this upgrade;

[0195] 2. The medical consortium MaaS platform sends an L1 medical big model upgrade request to the medical consortium management platform (medical consortium management device) (i.e., the medical consortium model deployment device sends an update notification information to the medical consortium management device). The L1 medical big model upgrade request carries the content information of this upgrade, and the medical consortium management platform indicates whether to upgrade this time.

[0196] 3. If the medical consortium management platform indicates that an upgrade is needed (i.e., the return value is the update instruction sent by the medical consortium management device to the medical consortium model deployment device), the medical consortium MaaS platform sends an L1 medical large model upgrade request to the model library (i.e., the medical consortium model deployment device sends an update request for the target model to the target device), and the model library returns the download address of the upgraded L1 medical large model; the medical consortium MaaS platform downloads the upgraded L1 medical large model from this address (i.e., the medical consortium model deployment device receives the updated target model sent by the target device based on the update request);

[0197] 4. Upgrading the L1 medical model in the cloud on the medical consortium MaaS platform: Since the L1 medical model in the cloud was customized during ordering and subsequently optimized based on the edge-side medical model, it cannot be directly upgraded using the L1 medical model in the model library. Upgrade strategies such as transfer learning and fine-tuning are required (i.e., updating the central L1-side medical model). After the upgrade, verification and testing are necessary before deployment (i.e., the medical consortium model deployment device verifies the second model and obtains the verification results; the second model is tested and test results are obtained; if both the verification and test results indicate that the second model is correct, the second model is deployed on the cloud of the medical consortium model deployment device).

[0198] 5. The medical consortium MaaS platform upgrades the edge-side medical models it subscribes to and collects: The medical consortium MaaS platform upgrades the edge-side medical models it collects through technologies such as transfer learning, and verifies and tests them. After passing the tests, the models are sent to the corresponding hospitals for deployment (i.e., the medical consortium model deployment device sends a second model to the hospital equipment so that the hospital equipment can deploy the second model according to the model deployment strategy).

[0199] In this embodiment, after the medical consortium model deployment device deploys the target model for the hospital equipment according to the model deployment strategy, it receives the collaborative reasoning service instruction activated by the medical consortium management device for the hospital equipment. Upon receiving the collaborative reasoning request sent by the hospital equipment, it performs identity authentication on the hospital equipment based on the collaborative reasoning service instruction. If the identity authentication is successful, it sends a response message agreeing to collaborative reasoning to the hospital equipment. If the collaborative reasoning strategy of the hospital equipment is remote reasoning or joint reasoning, and it receives the reasoning request sent by the hospital equipment, it performs reasoning on the data to be processed carried in the reasoning request according to the collaborative reasoning service instruction and using the target model to obtain the reasoning result; and sends the reasoning result to the hospital equipment.

[0200] It should be noted that the collaborative reasoning strategy is the strategy by which the medical consortium management equipment distributes information to the hospital equipment.

[0201] In this embodiment, after receiving the collaborative reasoning service instruction from the medical consortium management device to the hospital device, the medical consortium model deployment device performs identity authentication on the hospital device based on the collaborative reasoning service instruction upon receiving the collaborative reasoning request sent by the hospital device.

[0202] In this application embodiment, the collaborative reasoning scenarios are shown in Table 7: the collaborative reasoning scenarios include collaborative reasoning business scenario suggestions and suggestions on the proportion of cloud reasoning tasks as triggering factors for passive collaborative reasoning.

[0203] Table 7

[0204]

[0205]

[0206] In this embodiment, the collaborative reasoning between the edge (i.e., hospital equipment) and the cloud model fully utilizes the computing resources of both the cloud (the cloud where the medical consortium model is deployed) and the edge. Sensitive medical data can be preliminarily processed at the edge before being transmitted to the cloud to reduce the risk of data leakage. Simultaneously, it can be flexibly expanded to adapt to more complex medical application scenarios. For example, as... Figure 6 As shown:

[0207] 1. The medical consortium management platform (medical consortium management device) sends a request to the medical consortium MaaS platform (medical consortium model deployment device) to enable collaborative reasoning services for the hospital (the medical consortium management device sends an instruction to the medical consortium model deployment device to enable collaborative reasoning services for the hospital's equipment), carrying information including but not limited to: hospital ID, service activation duration, maximum number of concurrent tasks, etc.

[0208] 2. The medical consortium management platform sends collaborative reasoning strategies to hospitals (hospital equipment) that have activated collaborative reasoning services (hospital equipment receives collaborative reasoning strategies sent by the medical consortium management equipment);

[0209] 3. The hospital monitors edge computing resources and inference performance in real time. This means that the hospital equipment monitors the utilization rate of edge computing resources and the performance of the medical model in real time (the hospital equipment detects the current second computing resource information of the hospital equipment and the performance of the target model). When there is a shortage of computing resources or insufficient performance of the medical model, the hospital sends a collaborative inference request to the medical consortium MaaS platform (that is, when the hospital equipment determines that collaborative inference is needed based on the second computing resource information and the performance of the target model, it sends a collaborative inference request to the medical consortium model deployment equipment). The information carried includes, but is not limited to: hospital ID, application scenario of the inference service required by the cloud, number of concurrent tasks, latency requirements, and performance (accuracy, precision, etc.) requirements.

[0210] 4. The medical consortium MaaS platform first authenticates the hospital's identity (authentication authorization) to confirm that it has the right to use the cloud collaborative reasoning function (the medical consortium model deployment device authenticates the hospital's device based on the collaborative reasoning business instruction), opens the service for it, and sends a response message (i.e. request response) to the hospital (the medical consortium model deployment device sends a response message agreeing to collaborative reasoning to the hospital's device after the identity authentication is passed).

[0211] 5. After the edge-cloud collaborative reasoning function is enabled, the hospital categorizes model reasoning tasks triggered by medical applications into three types and processes them differently:

[0212] Local inference: For inference tasks that can be effectively supported by the local edge-side medical model and / or involve privacy data security, the inference is still performed by the edge-side medical model, and the inference results are given (that is, when the hospital equipment determines that the collaborative inference strategy is local inference, it inputs the data to be processed into the first model and obtains the inference results).

[0213] Remote inference: For inference tasks that cannot be effectively supported by local edge medical models and do not involve privacy data security, the data can be sent to the cloud-based large medical model for inference and the inference results can be returned (that is, when the hospital equipment determines that the collaborative inference strategy is remote inference, it sends the data to be processed to the medical consortium model deployment equipment, so that the medical consortium model deployment equipment can use the target model in the cloud to process the data to be processed and obtain the inference results).

[0214] Joint Reasoning: For reasoning tasks that require both the professionalism of the hospital's edge-side medical model and the comprehensiveness of the cloud-based medical model, the reasoning task can be performed separately on the edge side and in the cloud, and then integrated on the edge side to generate the final reasoning result. For example, for a patient's discharge medical record, the patient's basic information, diagnostic process, and conclusion are generated locally through reasoning. Then, the edge side sends information that does not contain the patient's privacy data to the cloud, where the cloud reasons to generate a post-discharge follow-up plan and rehabilitation plan, and returns them to the edge side. Ideally, the edge side integrates the reasoning results from both sides to generate the final version of the patient's discharge medical record (i.e., when the hospital equipment determines that the collaborative reasoning strategy is joint reasoning, it obtains non-privacy type first data from the data to be processed and sends the first data to the medical consortium model deployment equipment, so that the medical consortium model deployment equipment can process the first data using the target model in the cloud to obtain the first processing result; the second data is input into the first model to obtain the second processing result; and upon receiving the first processing result sent by the medical consortium model deployment equipment, the first processing result and the second processing result are used as the reasoning result).

[0215] Understandably, upon receiving a business request from the medical consortium management device, a model acquisition request carrying the business request is sent to the target device. Based on the model acquisition request, at least one model matching the business request is determined from multiple large models in the target device's model library. Upon receiving the model attribute information of at least one model from the target device, the computing power resource information of the medical consortium model deployment device under the current situation is determined, and the model attribute information and computing power resource information are sent to the medical consortium management device. Thus, the medical consortium management device determines the target model from at least one model based on the model attribute information and computing power resource information. Upon receiving the target model selection information from the medical consortium management device, the large model matching the medical consortium corresponding to the medical consortium model deployment device (i.e., the target model) is determined, thereby improving the accuracy of selecting a matching large model for the medical consortium.

[0216] This application provides a model selection method, which is applied to a target device. Figure 7 A flowchart of a model selection method provided in this application embodiment is shown below. Figure 7 As shown, model selection methods may include:

[0217] S201. Upon receiving a model acquisition request from the medical consortium model deployment device, extract the business requirements from the model acquisition request.

[0218] The model selection method provided in this application embodiment is applicable to scenarios where a target model corresponding to a medical consortium is determined.

[0219] In the embodiments of this application, the target device can be implemented in various forms. For example, the target device described in this application can be determined according to the actual situation, and the embodiments of this application do not limit it in this regard.

[0220] In this embodiment of the application, the target device can be a device with a model library. The specific target device can be determined according to the actual situation, and this embodiment of the application does not limit it.

[0221] In this embodiment, the model library integrates a collection of machine learning models with various large-scale parameters and complex structures. It may include general-purpose large models (i.e., basic large models L0) and industry-specific large models (i.e., L1), or other models. The specific models in the model library can be determined according to actual circumstances, and this embodiment does not limit this. The model library in this application includes one or more L1 medical large models (possibly provided by multiple vendors).

[0222] In this embodiment, business requirements can be the needs of the medical consortium under the corresponding business of the large medical model. Business requirements may include information such as a list of application scenarios, a list of required functions, and concurrency requirements. Specific business requirements can be determined according to the circumstances, and this embodiment does not limit them.

[0223] It should be noted that the application scenario list refers to a list of intelligent application scenarios based on the medical big data model, such as intelligent consultation, intelligent follow-up, and intelligent emergency care. The mandatory function list refers to a list of essential functions in the intelligent application scenarios based on the medical big data model, such as automatic medical record generation, treatment plan recommendation, automatic patient health profile generation, automatic rehabilitation plan generation, and quality control of medical records and test reports. The concurrency requirement refers to the concurrency requirements for intelligent applications accessing the medical big data model.

[0224] S202. Among the multiple large models in the model library, find at least one model that matches the business requirements.

[0225] In this embodiment of the application, after the target device obtains the business requirements from the model acquisition request, it searches for at least one model that matches the business requirements among multiple large models in the model library.

[0226] In the embodiments of this application, at least one model is a portion of a plurality of large models.

[0227] In this embodiment of the application, the target device can match the attribute information of multiple large models with business requirements, thereby finding at least one model that meets the business requirements from the multiple large models.

[0228] It should be noted that the method by which the target device searches for at least one corresponding model among multiple large models in the model library according to business needs can be determined based on the actual situation, and this application embodiment does not limit this.

[0229] S203. Obtain model attribute information for at least one model.

[0230] In this embodiment of the application, after the target device searches for at least one model that matches the business requirements among multiple large models in the model library, it obtains the model attribute information of at least one model.

[0231] In this embodiment of the application, the target device can obtain the model attribute information of at least one model from the attribute information of multiple large models.

[0232] In this embodiment, the model attribute information includes model producer information, model function information, model scale information, model application scenario information, model computing resource requirements information, model performance information, model advantages and disadvantages information, and model value. For example, the model attribute information includes the model provider (i.e., model producer information), supported application scenarios (model application scenario information), scale (model scale information), computing resource requirements (model computing resource requirements information), performance (model performance information), price (model value), and advantages (model advantages and disadvantages information). The model attribute information may also include other information. The specific information included in the model attribute information can be determined according to actual circumstances, and this embodiment does not limit this.

[0233] It should be noted that "Provider" refers to the vendor that provides the L1 medical big data model (i.e., any one of the models in at least one model). "Supported application scenarios" refers to the list of application scenarios supported by the L1 medical big data model, such as intelligent consultation, intelligent follow-up, and intelligent emergency care. "Supported function list" refers to the list of functions supported by the L1 medical big data model, such as automatic medical record generation, treatment plan recommendation, automatic patient health profile generation, automatic rehabilitation plan generation, and quality control of medical records and test reports. "Scale" is a data representation of the scale of the L1 medical big data model, including but not limited to: the number of parameters, the size of the dataset used for model training, model depth (number of layers), and model width (number of neurons / layer). Computing resource requirements refer to the computing resources required for the deployment and operation of this L1 medical big data model, including but not limited to: computing resource type (general computing power, intelligent computing power, and supercomputing power, etc.), hardware type (such as Graphics Processing Unit (GPU), Tensor Processing Unit (TPU), Central Processing Unit (CPU)), hardware model, hardware quantity, storage system requirements, operating environment (such as containerization, virtualization), operating system, and network bandwidth. Performance refers to the performance characteristics of the L1 medical big data model expressed through one or more evaluation metrics, including but not limited to: accuracy, recall, and F1 score. Price refers to the selling price of the L1 medical big data model. Advantages refer to the advantages of the L1 medical big data model, usually summarized by the vendor and listed compared to other L1 medical big data models.

[0234] S204. Send model attribute information to the medical consortium model deployment device so that the medical consortium model deployment device can use the medical consortium management device to determine the target model from at least one model based on the model attribute information and the current computing power resource information of the medical consortium model deployment device.

[0235] In this embodiment of the application, after the target device obtains the model attribute information of at least one model, it sends the model attribute information to the medical consortium model deployment device.

[0236] In the embodiments of this application, the number of target models can be one or more. The specific number of target models can be determined according to the actual situation, and the embodiments of this application do not limit this.

[0237] In this embodiment, after the target device sends model attribute information to the medical consortium model deployment device, the medical consortium model deployment device, upon receiving model attribute information of at least one model, determines the current computing power resource information and then sends the model attribute information and computing power resource information to the medical consortium management device. This allows the medical consortium management device to determine the target model from the at least one model based on the model attribute information and computing power resource information. Specifically, the medical consortium model deployment device can determine at least one compression ratio and at least one compressed model performance when deploying at least one model based on the computing power resource information; add at least one compression ratio and at least one compressed model performance to the model attribute information to obtain the added model attribute information; and send the added model attribute information to the medical consortium management device.

[0238] S205. Upon receiving a download request for the target model from the medical consortium model deployment device, send a download link for the target model to the medical consortium model deployment device so that the medical consortium model deployment device can download and deploy the target model according to the download link.

[0239] In this embodiment of the application, after the target device sends model attribute information to the medical consortium model deployment device, upon receiving a download request for the target model from the medical consortium model deployment device, it sends a download link for the target model to the medical consortium model deployment device.

[0240] In this embodiment of the application, after the target device sends the download link of the target model to the medical consortium model deployment device, the medical consortium model deployment device can download the target device according to the download link, and then the medical consortium model deployment device deploys the target device in the cloud according to the computing power resource information.

[0241] Understandably, upon receiving a model acquisition request from the medical consortium model deployment device, the system searches for at least one corresponding model among multiple large models in the model library based on the business requirements carried in the request. It then obtains the model attribute information of at least one model and sends this information to the medical consortium model deployment device. This allows the medical consortium model deployment device to use the medical consortium management device to determine the target model from the at least one model based on the model attribute information and the device's current computing resources. In other words, it identifies the large model (i.e., the target model) that matches the medical consortium corresponding to the medical consortium. Upon receiving the download request for the target model from the medical consortium model deployment device, the system sends a download link to the target model, allowing the medical consortium model deployment device to download and deploy the target model. This improves the accuracy of selecting a matching large model for the medical consortium.

[0242] This application provides a model selection method, which is applied to medical consortium management equipment. Figure 8 A flowchart of a model selection method provided in this application embodiment is shown below. Figure 8 As shown, model selection methods may include:

[0243] S301. Send business requirements to the deployment equipment of the medical consortium model; the business requirements are the requirements of the medical consortium under the business corresponding to the medical big model.

[0244] The model selection method provided in this application embodiment is applicable to scenarios where a target model corresponding to a medical consortium is determined.

[0245] In the embodiments of this application, the medical consortium management device can be implemented in various forms. For example, the medical consortium management device described in this application can be determined according to the actual situation, and the embodiments of this application do not limit it in this way.

[0246] In this embodiment of the application, the medical consortium management device can be a medical consortium management platform, which is a platform for managing the medical consortium MaaS platform (i.e., medical consortium model deployment device).

[0247] In this embodiment of the application, business requirements may include information such as a list of application scenarios, a list of required functions, and concurrency requirements. Specific business requirements can be determined based on the circumstances, and this embodiment of the application does not limit them.

[0248] It should be noted that the application scenario list refers to a list of intelligent application scenarios based on the medical big data model, such as intelligent consultation, intelligent follow-up, and intelligent emergency care. The mandatory function list refers to a list of essential functions in the intelligent application scenarios based on the medical big data model, such as automatic medical record generation, treatment plan recommendation, automatic patient health profile generation, automatic rehabilitation plan generation, and quality control of medical records and test reports. The concurrency requirement refers to the concurrency requirements for intelligent applications accessing the medical big data model.

[0249] S302. Upon receiving model attribute information and computing resource information sent by the medical consortium model deployment device based on business needs, determine the target model from at least one model corresponding to the model attribute information according to the model attribute information and computing resource information.

[0250] In this embodiment, after the medical consortium management device sends a business requirement to the medical consortium model deployment device, upon receiving the model attribute information and computing resource information sent by the medical consortium model deployment device based on the business requirement, the target model is determined from at least one model corresponding to the model attribute information based on the model attribute information and computing resource information.

[0251] In this embodiment of the application, upon receiving model attribute information and computing resource information sent by the medical consortium model deployment device based on business needs, the process of determining the target model from at least one model corresponding to the model attribute information based on the model attribute information and computing resource information includes: receiving the added model attribute information sent by the medical consortium model deployment device, obtaining the model attribute information and computing resource information from the added model attribute information, and then determining the target model from at least one model corresponding to the model attribute information based on the model attribute information and computing resource information.

[0252] In this embodiment of the application, when the medical consortium model deployment device receives a business request sent by the medical consortium management device, it sends a model acquisition request carrying the business request to the target device. When the medical consortium model deployment device receives model attribute information of at least one model sent by the target device, it determines the current computing power resource information.

[0253] In this embodiment, the model attribute information includes model producer information, model function information, model scale information, model application scenario information, model computing resource requirements information, model performance information, model advantages and disadvantages information, and model value. For example, the model attribute information includes the model provider (i.e., model producer information), supported application scenarios (model application scenario information), scale (model scale information), computing resource requirements (model computing resource requirements information), performance (model performance information), price (model value), and advantages (model advantages and disadvantages information). The model attribute information may also include other information. The specific information included in the model attribute information can be determined according to actual circumstances, and this embodiment does not limit this.

[0254] It should be noted that "Provider" refers to the vendor that provides the L1 medical big data model (i.e., any one of the models in at least one model). "Supported application scenarios" refers to the list of application scenarios supported by the L1 medical big data model, such as intelligent consultation, intelligent follow-up, and intelligent emergency care. "Supported function list" refers to the list of functions supported by the L1 medical big data model, such as automatic medical record generation, treatment plan recommendation, automatic patient health profile generation, automatic rehabilitation plan generation, and quality control of medical records and test reports. "Scale" is a data representation of the scale of the L1 medical big data model, including but not limited to: the number of parameters, the size of the dataset used for model training, model depth (number of layers), and model width (number of neurons / layer). Computing resource requirements refer to the computing resources required for the deployment and operation of this L1 medical big data model, including but not limited to: computing resource type (general computing power, intelligent computing power, and supercomputing power, etc.), hardware type (such as Graphics Processing Unit (GPU), Tensor Processing Unit (TPU), Central Processing Unit (CPU)), hardware model, hardware quantity, storage system requirements, operating environment (such as containerization, virtualization), operating system, and network bandwidth. Performance refers to the performance characteristics of the L1 medical big data model expressed through one or more evaluation metrics, including but not limited to: accuracy, recall, and F1 score. Price refers to the selling price of the L1 medical big data model. Advantages refer to the advantages of the L1 medical big data model, usually summarized by the vendor and listed compared to other L1 medical big data models.

[0255] In this embodiment of the application, the medical consortium management device can acquire user requirements (including business requirements) and determine the target model from at least one model corresponding to the model attribute information based on the user requirements, model attribute information, and computing resource information.

[0256] S303. Send the target model selection information to the medical consortium model deployment device so that the medical consortium model deployment device can download and deploy the target model.

[0257] In this embodiment, after the medical consortium management device determines the target model from at least one model corresponding to the model attribute information based on the model attribute information and computing resource information, it sends the target model selection information to the medical consortium model deployment device so that the medical consortium model deployment device can download and deploy the target model.

[0258] In this embodiment of the application, after the medical consortium management device determines the target model, it generates the target model selection information and then sends the target model selection information to the medical consortium model deployment device.

[0259] Understandably, after sending a business requirement to the medical consortium model deployment device, and upon receiving the model attribute information and computing resource information sent by the medical consortium model deployment device based on the business requirement, the target model can be determined from at least one model corresponding to the model attribute information, that is, the large model (i.e., the target model) matching the medical consortium corresponding to the medical consortium model deployment device can be determined. Then, the target model selection information is sent to the medical consortium model deployment device, allowing the medical consortium model deployment device to understand the selected target model and download and deploy it, thus improving the accuracy of selecting a matching large model for the medical consortium.

[0260] This application provides a model selection method, which is applied to hospital equipment. Figure 9 A flowchart of a model selection method provided in this application embodiment is shown below. Figure 9 As shown, model selection methods may include:

[0261] S401. Send a model customization request to the medical consortium model deployment device.

[0262] The model selection method provided in this application embodiment is applicable to scenarios where a target model corresponding to a medical consortium is determined.

[0263] In the embodiments of this application, the hospital equipment can be implemented in various forms. For example, the hospital equipment described in this application can be determined according to the actual situation, and the embodiments of this application do not limit it in this way.

[0264] In this embodiment of the application, the hospital equipment can be the hospital information system of the hospital.

[0265] It should be noted that the model customization request carries the first computing power resource information and the first business requirement, so that the medical consortium model deployment equipment can determine the model deployment strategy that matches the hospital equipment based on the first computing power resource information and the first business requirement.

[0266] In this embodiment of the application, the model customization request is a request to obtain a model that matches the hospital equipment from the medical consortium model deployment device.

[0267] In this embodiment, the medical consortium model deployment device can be a medical consortium MaaS platform.

[0268] S402, Receive the model deployment strategy sent by the medical consortium model deployment device.

[0269] In this embodiment of the application, after the hospital equipment sends a model customization request to the medical consortium model deployment equipment, it receives the model deployment strategy sent by the medical consortium model deployment equipment.

[0270] It should be noted that there can be multiple model deployment strategies, and the specific number of model deployment strategies can be determined according to the actual situation. This application embodiment does not limit this.

[0271] For example, the number of model deployment strategies can be four: no compression of the target model, compression of the target model according to a first preset compression ratio, compression of the target model according to a second preset compression ratio, and no deployment of the model at the hospital.

[0272] In this embodiment of the application, the model deployment strategy sent by the medical consortium model deployment device is one of the strategies.

[0273] In this embodiment, the first preset compression ratio and the second preset compression ratio are different. The first preset compression ratio results in a smaller compression degree on the target model than the second preset compression ratio.

[0274] S403. Generate a confirmation instruction for the model deployment strategy and send the confirmation instruction to the medical consortium model deployment device.

[0275] In this embodiment of the application, after the hospital equipment receives the model deployment strategy sent by the medical consortium model deployment device, it generates a confirmation instruction for the model deployment strategy and sends the confirmation instruction to the medical consortium model deployment device.

[0276] In this embodiment, the confirmation instruction is generated when the hospital device agrees to the model deployment strategy. For example, upon receiving the model deployment strategy, the hospital device displays it. If a human confirms that the model can be deployed in the hospital device according to the strategy and has entered an agreement, a confirmation instruction for the model deployment strategy is generated. Alternatively, the hospital device automatically reviews the model deployment strategy, and if it determines that the model deployment strategy is acceptable, the confirmation instruction is generated. The specific execution method can be determined according to the actual situation, and this embodiment does not limit this.

[0277] S404. Upon receiving the target model sent by the medical consortium model deployment device, execute the deployment process of the target model according to the model deployment strategy.

[0278] In this embodiment of the application, after the hospital device generates a confirmation instruction for the model deployment strategy and sends the confirmation instruction to the medical consortium model deployment device, it executes the deployment process of the target model according to the model deployment strategy upon receiving the target model sent by the medical consortium model deployment device.

[0279] In this embodiment, if the hospital equipment has sufficient computing power to deploy and run the target model (i.e., the first computing power resource information includes intelligent computing power resources, and the first computing power resources corresponding to the intelligent computing power resources are greater than the computing power resources required to deploy and run the target model), then the medical consortium model deployment device determines the model deployment strategy as not compressing the target model. The medical consortium model deployment device sends the target model to the hospital equipment. Upon receiving the target model sent by the medical consortium model deployment device, the hospital equipment deploys the target model.

[0280] It should be noted that after the target model is deployed on the hospital equipment, training data is acquired and used to train the target model, resulting in the first model. It should also be noted that if the hospital equipment later updates the first model, the updated first model will also be referred to as the first model.

[0281] In this embodiment, when the hospital equipment possesses certain intelligent computing resources, but these resources are insufficient to support the deployment and operation of the uncompressed target model (i.e., the first computing resource information includes intelligent computing resources, and the first computing resources corresponding to the intelligent computing resources are less than or equal to the computing resources required to deploy and operate the target model), the medical consortium model deployment device determines the model deployment strategy as compressing the target model according to a first preset compression ratio to obtain a large medical model. Specifically, the medical consortium model deployment device performs customized compression (compressing according to the first preset compression ratio) on the edge-side computing resources of the hospital equipment (i.e., the first computing resource information). Compression methods such as knowledge distillation, low-rank decomposition, and parameter sharing can be used to compress the target model, appropriately reducing the model's complexity and computational load. Then, the medical consortium model deployment device sends the large medical model to the hospital equipment. Upon receiving the large medical model, the hospital equipment deploys it.

[0282] It should be noted that after the hospital equipment deploys the large-scale medical model, training data is acquired and used to train the large-scale medical model, resulting in the first model. It should also be noted that if the hospital equipment later updates the first model, the updated first model will also be referred to as the first model.

[0283] In this embodiment, when the hospital equipment only possesses certain general computing power resources but lacks intelligent computing power resources, thus unable to support the deployment and operation of the target model (i.e., the first computing power resource information includes general computing power resources but does not include intelligent computing power resources), the medical consortium model deployment device determines the model deployment strategy to compress the target model according to a second preset compression ratio to obtain a small medical model. Specifically, the medical consortium model deployment device compresses the L1 large medical model into a small medical model based on the edge-side computing power resources of the hospital equipment (i.e., the first computing power resource information) (i.e., compressing the target model into a small medical model according to the second preset compression ratio). For example, model pruning, quantization, and other compression methods can be used, with a compression ratio typically ranging from 10% to 50%, and in extreme cases, it can be compressed to a fraction of the target model's size. Then, the medical consortium model deployment device sends the small medical model to the hospital equipment. Upon receiving the small medical model, the hospital equipment deploys it.

[0284] It should be noted that after the hospital equipment deploys the small medical model, it acquires training data and uses this data to train the small medical model, resulting in the first model. It should also be noted that if the hospital equipment later updates the first model, the updated first model will also be referred to as the first model.

[0285] In this embodiment, when hospital computing resources are severely insufficient and some or all data can be exported (i.e., the first computing resource corresponding to the first computing resource information is less than or equal to the computing resource threshold, and the first business requirement identifier allows processing of hospital equipment business data on the medical consortium model deployment device side), the medical consortium model deployment device determines its model deployment strategy to not deploy the model at the hospital end. That is, the hospital equipment does not deploy the large / small medical model locally; instead, the model service is provided by the cloud of the medical consortium model deployment device (i.e., a model call interface is configured for the hospital equipment so that the hospital equipment can call the target model according to the model call interface). At this time, the medical consortium model deployment device does not send the target model to the hospital equipment. The hospital equipment will not deploy the target model locally; when the hospital equipment needs to use the target model, it directly calls the target model in the cloud of the medical consortium model deployment device through the model call interface.

[0286] It should be noted that if the hospital equipment does not deploy the target model, but only calls the target model in the cloud of the medical consortium model deployment equipment through the model call interface, the hospital equipment will not use the training data to train the target model in the cloud.

[0287] In this embodiment, after the hospital device executes the deployment process of the target model according to the model deployment strategy, upon receiving the collaborative reasoning strategy sent by the medical consortium management device and obtaining the data to be processed, it detects the current second computing power resource information and the target model performance of the target model. If it determines that collaborative reasoning is required based on the second computing power resource information and the target model performance, it sends a collaborative reasoning request to the medical consortium model deployment device. Upon receiving the response information from the medical consortium model deployment device agreeing to collaborative reasoning based on the collaborative reasoning request, it sends the data to be processed to the medical consortium model deployment device based on the collaborative reasoning strategy, so that the medical consortium model deployment device can collaboratively process the data to be processed.

[0288] In this embodiment of the application, the second computing power resource information is the second computing power resource information of the hospital equipment under the current situation, which is detected when the collaborative reasoning strategy sent by the medical consortium management device is received and the data to be processed is obtained.

[0289] In this embodiment, the second computing power resource information may be the same as the first computing power resource information, or the second computing power resource information may be different from the first computing power resource information. The specific details can be determined according to the actual situation, and this embodiment does not limit this.

[0290] In this embodiment of the application, when the hospital equipment determines that the computing resources are tight or the medical model performance is insufficient based on the second computing resource information and the target model performance, it determines that collaborative reasoning is needed, and then sends a collaborative reasoning request to the medical consortium model deployment equipment.

[0291] In the embodiments of this application, the collaborative reasoning strategy includes remote reasoning, joint reasoning, and local reasoning. Local reasoning is the process by which the hospital equipment uses the local target model, the large medical model, the large medical model, or the first model to reason about the local data to be processed.

[0292] It should be noted that the reasoning process is the process of using the model to process the data to be processed.

[0293] In this embodiment of the application, remote inference refers to the process by which hospital equipment, upon receiving data to be processed, directly sends the data to be processed to the medical consortium model deployment device, and uses the target model or second model located in the cloud of the medical consortium model deployment device to infer the data to be processed.

[0294] In this embodiment of the application, joint reasoning refers to the process of using the model on the hospital equipment side (including the target model, the large medical model, or the first model) and the model on the cloud of the medical consortium model deployment equipment (including the target model or the second model) to jointly process and execute the reasoning process of the data to be processed.

[0295] In this embodiment, the process of a hospital device sending data to be processed to a medical consortium model deployment device based on a collaborative reasoning strategy includes: when the collaborative reasoning strategy is remote reasoning, sending the data to be processed to the medical consortium model deployment device so that the medical consortium model deployment device can process the data to be processed using a target model or a second model in the cloud to obtain a reasoning result; when the collaborative reasoning strategy is joint reasoning, obtaining non-privacy type first data from the data to be processed and sending the first data to the medical consortium model deployment device so that the medical consortium model deployment device can process the first data using a target model or a second model in the cloud to obtain a first processing result; inputting the second data into the first model to obtain a second processing result; the second data is the remaining data in the data to be processed excluding the first data; upon receiving the first processing result sent by the medical consortium model deployment device, using the first processing result and the second processing result as the reasoning result; when the collaborative reasoning strategy is local reasoning, inputting the data to be processed into the first model to obtain the reasoning result.

[0296] It should be noted that the first model is the model obtained after the hospital equipment trains or updates the target model sent by the target equipment.

[0297] For example, the multi-level medical large-scale model deployment application architecture (i.e., the implementation architecture of the model selection method) in this application is as follows: Figure 10 As shown, it includes three levels:

[0298] Large model library (model library in the target device): A large model library is a collection of machine learning models that integrate a variety of large-scale parameters and complex structures, typically including general-purpose large models and industry-specific large models. For example, it can be assumed that the large model library contains one or more L1 medical large models (i.e., it contains multiple large models that may be provided by multiple vendors);

[0299] Medical Consortium MaaS Platform (Medical Consortium Model Deployment Equipment): The Medical Consortium MaaS Platform obtains L1 medical large models (target models) from a large model library, optimizes them, and deploys them in the cloud. They are provided to medical institutions within the medical consortium as a service. Users (hospital equipment) can call the cloud-deployed models for prediction or analysis through APIs and other interfaces, or they can deploy and use them in the local environment of the hospital equipment.

[0300] The hospital information system (hospital equipment) is the actual user of the medical big data model. Based on local computing resources and user strategies (model deployment strategies), the hospital equipment can use the medical big data model in ways including but not limited to: ① Deploying the L1 medical big data model (i.e., the medical big data model or target model) locally on the hospital equipment, and training the L1 medical big data model into an L2 medical big data model (the first model) based on local data; ② Deploying the medical small model locally (usually due to insufficient local computing power, such as only having general computing power and lacking intelligent computing power); ③ Not deploying the target model, medical big data model, or small model locally, but directly calling the medical big data model (target model or second model) in the medical consortium MaaS platform.

[0301] It is understandable that the model selection method in this application can be based on existing general medical models to adapt suitable L1 medical models for different medical consortia (i.e., determine the target model suitable for cloud deployment on medical consortia model deployment devices), while providing suitable customized medical models and deployment strategies for each hospital in the medical consortia. This solves the problem that general medical models cannot well adapt to the different forms and quantities of computing power resources and diverse intelligent business needs of hospitals.

[0302] Understandably, by sending a model customization request carrying the first computing power resource information and the first business requirement to the medical consortium model deployment device, the medical consortium model deployment device can determine the model deployment strategy matching the hospital equipment based on the first computing power resource information and the first business requirement. Upon generating a confirmation instruction for the model deployment strategy, the medical consortium model deployment device sends a confirmation instruction to the medical consortium model deployment device, enabling the medical consortium model deployment device to transmit the target model to the hospital equipment according to the model deployment strategy. The hospital equipment can also execute the deployment process of the target model according to the model deployment strategy, thereby realizing the model customization process on the hospital equipment side and improving the accuracy of selecting a matching large model for the hospital equipment.

[0303] Based on the same inventive concept as the model selection method applied to the above-mentioned medical consortium model deployment device, this application embodiment provides a medical consortium model deployment device 1, corresponding to a model selection method applied to the medical consortium model deployment device; Figure 11 A schematic diagram of the composition structure of a medical consortium model deployment device provided in this application embodiment. Figure 1 The medical consortium model deployment device 1 may include:

[0304] The first sending unit 11 is configured to send a model acquisition request to a target device upon receiving a business requirement from a medical consortium management device; the target device is equipped with a model library including multiple large models; the model acquisition request carries the business requirement so that the target device can search for at least one model matching the business requirement in the model library; and sends model attribute information and computing power resource information to the medical consortium management device so that the medical consortium management device can determine the target model from the at least one model based on the model attribute information and the computing power resource information.

[0305] The first determining unit 12 is used to determine the current computing power resource information upon receiving model attribute information of at least one model sent by the target device.

[0306] The first deployment unit 13 is used to download and deploy the target model upon receiving the target model selection information sent by the medical consortium management device.

[0307] In some embodiments of this application, the device further includes an adding unit;

[0308] The first determining unit 12 is configured to determine, based on the computing power resource information, at least one compression ratio and at least one compressed model performance when deploying the at least one model; the at least one model corresponds one-to-one with the at least one compression ratio; the performance of the at least one compressed model corresponds one-to-one with the at least one model.

[0309] The adding unit is used to add at least one compression rate and at least one compressed model performance to the model attribute information to obtain the added model attribute information.

[0310] The first sending unit 11 is used to send the added model attribute information to the medical consortium management device.

[0311] In some embodiments of this application, the first deployment unit 13 is used to download the target model from the target device and deploy the target model in the cloud of the medical consortium model deployment device according to the computing power resource information.

[0312] In some embodiments of this application, the first determining unit 12 is configured to, upon receiving a model customization request sent by a hospital device, determine a model deployment strategy matching the hospital device based on the first computing power resource information and the first business requirement in the model customization requirement; the first computing power resource information is the computing power resource information of the hospital device; the first business requirement is the business requirement of the hospital device.

[0313] The first sending unit 11 is used to send the model deployment strategy to the hospital equipment;

[0314] The first deployment unit 13 is configured to deploy the target model for the hospital equipment in accordance with the model deployment strategy upon receiving confirmation instruction from the hospital equipment regarding the model deployment strategy.

[0315] In some embodiments of this application, the device further includes a compression unit and a configuration unit;

[0316] The first sending unit 11 is configured to send model information of the target model to the hospital device when the model deployment strategy is not to compress the target model, so that the hospital device can deploy the target model; and send the large medical model or the small medical model to the hospital device, so that the hospital device can deploy the large medical model or the small medical model.

[0317] The compression unit is configured to compress the target model according to the first preset compression ratio to obtain a large medical model when the model deployment strategy is to compress the target model according to the first preset compression ratio; and to compress the target model into a small medical model according to the second preset compression ratio when the model deployment strategy is to compress the target model according to the second preset compression ratio.

[0318] The configuration unit is used to configure a model invocation interface for the hospital equipment when the model deployment strategy is not to deploy the model at the hospital end, so that the hospital equipment can invoke the target model according to the model invocation interface.

[0319] In some embodiments of this application, the first determining unit 12 is configured to: determine that the model deployment strategy is not to compress the target model when the first computing power resource information includes intelligent computing power resources and the first computing power resources corresponding to the intelligent computing power resources are greater than the computing power resources required to deploy and run the target model; determine that the model deployment strategy is to compress the target model according to a first preset compression ratio when the first computing power resource information includes intelligent computing power resources and the first computing power resources corresponding to the intelligent computing power resources are less than or equal to the computing power resources required to deploy and run the target model; determine that the model deployment strategy is to compress the target model according to a second preset compression ratio when the first computing power resource information includes general computing power resources but does not include the intelligent computing power resources; and determine that the model deployment strategy is not to deploy the model at the hospital end when the first computing power resource resources corresponding to the first computing power resource information are less than or equal to the computing power resource threshold and the first business requirement identifier allows the processing of the hospital equipment's business data on the medical consortium model deployment device side.

[0320] In some embodiments of this application, the device further includes an adjustment unit and a second acquisition unit;

[0321] The first sending unit 11 is configured to, upon receiving a model feedback instruction sent by the medical consortium management device, send a model subscription request for a preset business domain to the hospital device carried in the model feedback instruction; the preset business domain is the information carried in the model feedback instruction.

[0322] The second acquisition unit is configured to, upon receiving a first model sent by the hospital device based on the model subscription request, acquire model features corresponding to the preset business domain from the first model; the first model is a model obtained by the hospital device after training or updating the target model;

[0323] The adjustment unit is used to adjust the target model according to the model features.

[0324] In some embodiments of this application, the device further includes a second receiving unit;

[0325] The first sending unit 11 is configured to send an update notification request for the target model to the target device; upon receiving the update notification information for the target model sent by the target device, send the update notification information to the medical consortium management device; and upon receiving an update instruction sent by the medical consortium management device, send an update request for the target model to the target device.

[0326] The second receiving unit is configured to receive the updated target model sent by the target device based on the update request; the updated target model is the model obtained by the target device after performing an update operation on the target model;

[0327] The adjustment unit is used to adjust the updated target model according to the computing power resource information to obtain a second model, and to deploy the second model in the cloud of the medical consortium model deployment device.

[0328] In some embodiments of this application, the device further includes a verification unit and a testing unit;

[0329] The verification unit is used to verify the second model and obtain the verification result;

[0330] The testing unit is used to test the second model and obtain test results;

[0331] The first deployment unit 13 is used to deploy the second model in the cloud of the medical consortium model deployment device when both the verification results and the test results indicate that the second model is correct.

[0332] In some embodiments of this application, the first sending unit 11 is used to send the second model to the hospital equipment so that the hospital equipment can deploy the second model according to the model deployment strategy.

[0333] In some embodiments of this application, the device further includes an authentication unit and a first inference unit;

[0334] The second receiving unit is used to receive the collaborative reasoning service instruction activated by the medical consortium management device for the hospital equipment;

[0335] The authentication unit is used to authenticate the identity of the hospital device based on the collaborative reasoning service instruction when it receives a collaborative reasoning request sent by the hospital device.

[0336] The first sending unit 11 is configured to send a response message agreeing to collaborative reasoning to the hospital device when identity authentication is successful; and to send the reasoning result to the hospital device.

[0337] The first inference unit is configured to, when the collaborative inference strategy of the hospital equipment is remote inference or joint inference, and when it receives an inference request sent by the hospital equipment, perform inference on the data to be processed carried in the inference request according to the collaborative inference service instruction and use the target model to obtain an inference result; the collaborative inference strategy is a strategy issued by the medical consortium management device to the hospital equipment.

[0338] It should be noted that, in practical applications, the first sending unit 11, the first determining unit 12, and the first deployment unit 13 can be implemented by the first processor 14 on the medical consortium model deployment device, specifically by a CPU (Central Processing Unit), MPU (Microprocessor Unit), DSP (Digital Signal Processor), or FPGA (Field Programmable Gate Array), etc.; the data storage can be implemented by the first memory 15 on the medical consortium model deployment device.

[0339] This application also provides a medical consortium model deployment device, such as... Figure 12As shown, the medical consortium model deployment device includes: a first processor 14, a first memory 15, and a first communication bus 16. The first memory 15 communicates with the first processor 14 through the first communication bus 16. The first memory 15 stores programs executable by the first processor 14. When the program is executed, the model selection method applied to the medical consortium model deployment device as described above is executed through the first processor 14.

[0340] In practical applications, the first memory 15 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the first processor 14.

[0341] This application provides a computer-readable storage medium having a computer program thereon, which, when executed by a first processor 14, implements the model selection method as described above for use in a medical consortium model deployment device.

[0342] For example, embodiments of this application also provide a computer program product, including a computer program that can be executed by a first processor 14 in a medical consortium model deployment device to complete the steps described in the aforementioned model selection method applied in the medical consortium model deployment device.

[0343] Understandably, upon receiving a business request from the medical consortium management device, a model acquisition request carrying the business request is sent to the target device. Based on the model acquisition request, at least one model matching the business request is determined from multiple large models in the target device's model library. Upon receiving the model attribute information of at least one model from the target device, the computing power resource information of the medical consortium model deployment device under the current situation is determined, and the model attribute information and computing power resource information are sent to the medical consortium management device. Thus, the medical consortium management device determines the target model from at least one model based on the model attribute information and computing power resource information. Upon receiving the target model selection information from the medical consortium management device, the large model matching the medical consortium corresponding to the medical consortium model deployment device (i.e., the target model) is determined, thereby improving the accuracy of selecting a matching large model for the medical consortium.

[0344] Based on the same inventive concept as the model selection method applied to the target device described above, this application provides a target device 2, corresponding to a model selection method applied to the target device; Figure 13 A schematic diagram of the composition structure of a target device provided in an embodiment of this application. Figure 1 The target device 2 may include:

[0345] The first acquisition unit 21 is used to acquire business requirements from the model acquisition request when it receives a model acquisition request sent by the medical consortium model deployment device; and acquire model attribute information of at least one model.

[0346] The search unit 22 is used to search for at least one model that matches the business requirement among multiple large models in the model library.

[0347] The second sending unit 23 is configured to send the model attribute information to the medical consortium model deployment device, so that the medical consortium model deployment device can use the medical consortium management device to determine the target model from the at least one model based on the model attribute information and the current computing power resource information of the medical consortium model deployment device; and upon receiving a download request for the target model sent by the medical consortium model deployment device, send a download link for the target model to the medical consortium model deployment device, so that the medical consortium model deployment device can download and deploy the target model according to the download link.

[0348] It should be noted that, in practical applications, the first acquisition unit 21, the search unit 22, and the second sending unit 23 can be implemented by the second processor 24 on the target device, specifically by a CPU (Central Processing Unit), MPU (Microprocessor Unit), DSP (Digital Signal Processor), or FPGA (Field Programmable Gate Array), etc.; the data storage can be implemented by the second memory 25 on the target device.

[0349] This application also provides a target device, such as... Figure 14 As shown, the target device includes: a second processor 24, a second memory 25, and a second communication bus 26. The second memory 25 communicates with the second processor 24 through the second communication bus 26. The second memory 25 stores programs executable by the second processor 24. When the program is executed, the model selection method applied to the target device as described above is executed by the second processor 24.

[0350] In practical applications, the second memory 25 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the second processor 24.

[0351] This application provides a computer-readable storage medium having a computer program thereon, which, when executed by a second processor 24, implements the model selection method applied to a target device as described above.

[0352] For example, embodiments of this application also provide a computer program product, including a computer program that can be executed by a second processor 24 in a target device to perform the steps described in the aforementioned model selection method applied to the target device.

[0353] Understandably, upon receiving a model acquisition request from the medical consortium model deployment device, the system searches for at least one corresponding model among multiple large models in the model library based on the business requirements carried in the request. It then obtains the model attribute information of at least one model and sends this information to the medical consortium model deployment device. This allows the medical consortium model deployment device to use the medical consortium management device to determine the target model from the at least one model based on the model attribute information and the device's current computing resources. In other words, it identifies the large model (i.e., the target model) that matches the medical consortium corresponding to the medical consortium. Upon receiving the download request for the target model from the medical consortium model deployment device, the system sends a download link to the target model, allowing the medical consortium model deployment device to download and deploy the target model. This improves the accuracy of selecting a matching large model for the medical consortium.

[0354] Based on the same inventive concept as the model selection method applied to the above-mentioned medical consortium management equipment, this application provides a medical consortium management equipment 3, corresponding to a model selection method applied to the medical consortium management equipment; Figure 15 A schematic diagram of the composition structure of a medical consortium management device provided in this application embodiment. Figure 1 The medical consortium management device 3 may include:

[0355] The third sending unit 31 is used to send business requirements to the medical consortium model deployment device; the business requirements are the demand information of the medical consortium under the business corresponding to the medical big model; and to send the selection information of the target model to the medical consortium model deployment device so that the medical consortium model deployment device can download and deploy the target model.

[0356] The second determining unit 32 is configured to, upon receiving model attribute information and computing resource information sent by the medical consortium model deployment device based on the business requirements, determine the target model from at least one model corresponding to the model attribute information, based on the model attribute information and the computing resource information.

[0357] It should be noted that, in practical applications, the aforementioned third sending unit 31 and second determining unit 32 can be implemented by the third processor 33 on the medical consortium management device, specifically by a CPU (Central Processing Unit), MPU (Microprocessor Unit), DSP (Digital Signal Processor), or Field Programmable Gate Array (FPGA); the aforementioned data storage can be implemented by the third memory 34 on the medical consortium management device.

[0358] This application also provides a medical consortium management device, such as... Figure 16 As shown, the medical consortium management device includes a third processor 33, a third memory 34, and a third communication bus 35. The third memory 34 communicates with the third processor 33 through the third communication bus 35. The third memory 34 stores programs executable by the third processor 33. When the program is executed, the model selection method applied to the medical consortium management device as described above is executed through the third processor 33.

[0359] In practical applications, the aforementioned third memory 34 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the third processor 33.

[0360] This application provides a computer-readable storage medium having a computer program thereon, which, when executed by a third processor 33, implements the model selection method as described above for use in medical consortium management equipment.

[0361] For example, this application also provides a computer program product, including a computer program that can be executed by a third processor 33 in a medical consortium management device to complete the steps described in the aforementioned model selection method applied in the medical consortium management device.

[0362] Understandably, after sending a business requirement to the medical consortium model deployment device, and upon receiving the model attribute information and computing resource information sent by the medical consortium model deployment device based on the business requirement, the target model can be determined from at least one model corresponding to the model attribute information, that is, the large model (i.e., the target model) matching the medical consortium corresponding to the medical consortium model deployment device can be determined. Then, the target model selection information is sent to the medical consortium model deployment device, allowing the medical consortium model deployment device to understand the selected target model and download and deploy it, thus improving the accuracy of selecting a matching large model for the medical consortium.

[0363] Based on the same inventive concept as the model selection method applied to hospital equipment described above, this application provides a hospital equipment 4, corresponding to a model selection method applied to hospital equipment; Figure 17 A schematic diagram of the composition structure of a hospital device provided in this application embodiment. Figure 1 The hospital equipment 4 may include:

[0364] The fourth sending unit 41 is used to send a model customization request to the medical consortium model deployment device. The model customization request carries first computing power resource information and first business requirements, so that the medical consortium model deployment device can determine a model deployment strategy that matches the hospital equipment based on the first computing power resource information and the first business requirements.

[0365] The first receiving unit 42 is used to receive the model deployment strategy sent by the medical consortium model deployment device;

[0366] The generation unit 43 is used to generate a confirmation instruction for the model deployment strategy and send the confirmation instruction to the medical consortium model deployment device;

[0367] The execution unit 44 is used to execute the deployment process of the target model according to the model deployment strategy when it receives the target model sent by the medical consortium model deployment device.

[0368] In some embodiments of this application, the device further includes a detection unit;

[0369] The detection unit is used to detect the current second computing power resource information of the hospital equipment and the target model performance of the target model when it receives the collaborative reasoning strategy sent by the medical consortium management device and obtains the data to be processed.

[0370] The fourth sending unit 41 is used to send a collaborative reasoning request to the medical consortium model deployment device when it is determined that collaborative reasoning is required based on the second computing power resource information and the performance of the target model; and to send the data to be processed to the medical consortium model deployment device based on the collaborative reasoning request when it receives a response information from the medical consortium model deployment device agreeing to collaborative reasoning based on the collaborative reasoning request, so that the medical consortium model deployment device can collaboratively process the data to be processed.

[0371] In some embodiments of this application, the device further includes a third acquisition unit, an input unit, and a third determination unit;

[0372] The fourth sending unit 41 is used to send the data to be processed to the medical consortium model deployment device when the collaborative reasoning strategy is remote reasoning, so that the medical consortium model deployment device can process the data to be processed using the target model in the cloud to obtain the reasoning result, and send the first data to the medical consortium model deployment device, so that the medical consortium model deployment device can process the first data using the target model in the cloud to obtain the first processing result.

[0373] The third acquisition unit is used to acquire non-privacy type first data from the data to be processed when the collaborative reasoning strategy is joint reasoning;

[0374] The input unit is used to input the second data into the first model to obtain the second processing result; the second data is the remaining data in the data to be processed excluding the first data; the first model is the model obtained by the hospital equipment after training or updating the target model sent by the target equipment; when the collaborative reasoning strategy is local reasoning, the data to be processed is input into the first model to obtain the reasoning result;

[0375] The third determining unit is used to take the first processing result and the second processing result as the reasoning result when it receives the first processing result sent by the medical consortium model deployment device.

[0376] It should be noted that, in practical applications, the aforementioned fourth transmitting unit 41, first receiving unit 42, generating unit 43, and execution unit 44 can be implemented by the fourth processor 45 on the hospital equipment, specifically by a CPU (Central Processing Unit), MPU (Microprocessor Unit), DSP (Digital Signal Processor), or Field Programmable Gate Array (FPGA), etc.; the aforementioned data storage can be implemented by the fourth memory 46 on the hospital equipment.

[0377] This application also provides a hospital device, such as... Figure 18 As shown, the hospital equipment includes: a fourth processor 45, a fourth memory 46, and a fourth communication bus 47. The fourth memory 46 communicates with the fourth processor 45 through the fourth communication bus 47. The fourth memory 46 stores programs executable by the fourth processor 45. When the program is executed, the model selection method applied to the hospital equipment as described above is executed through the fourth processor 45.

[0378] In practical applications, the aforementioned fourth memory 46 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the fourth processor 45.

[0379] This application provides a computer-readable storage medium having a computer program thereon, which, when executed by a fourth processor 45, implements the model selection method applied to hospital equipment as described above.

[0380] For example, embodiments of this application also provide a computer program product, including a computer program that can be executed by a fourth processor 45 in a hospital device to perform the steps described in the aforementioned model selection method applied to a hospital device.

[0381] Understandably, by sending a model customization request carrying the first computing power resource information and the first business requirement to the medical consortium model deployment device, the medical consortium model deployment device can determine the model deployment strategy matching the hospital equipment based on the first computing power resource information and the first business requirement. Upon generating a confirmation instruction for the model deployment strategy, the medical consortium model deployment device sends a confirmation instruction to the medical consortium model deployment device, enabling the medical consortium model deployment device to transmit the target model to the hospital equipment according to the model deployment strategy. The hospital equipment can also execute the deployment process of the target model according to the model deployment strategy, thereby realizing the model customization process on the hospital equipment side and improving the accuracy of selecting a matching large model for the hospital equipment.

[0382] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0383] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0384] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0385] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0386] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A model selection method, characterized in that, The method, applied to a medical consortium model deployment device, includes: Upon receiving a business request from the medical consortium management device, a model acquisition request is sent to the target device; the target device has a model library containing multiple large models; the model acquisition request carries the business request so that the target device can search the model library for at least one model that matches the business request. Upon receiving model attribute information of at least one model sent by the target device, determine the current computing power resource information; The model attribute information and the computing power resource information are sent to the medical consortium management device so that the medical consortium management device can determine the target model from the at least one model based on the model attribute information and the computing power resource information. Upon receiving the target model selection information sent by the medical consortium management device, the target model is downloaded and deployed.

2. The model selection method according to claim 1, characterized in that, Sending the model attribute information and the computing resource information to the medical consortium management device includes: Based on the computing power resource information, determine at least one compression ratio and at least one compressed model performance when deploying the at least one model; the at least one model corresponds one-to-one with the at least one compression ratio; the performance of the at least one compressed model corresponds one-to-one with the at least one model. Add at least one compression ratio and at least one compressed model performance to the model attribute information to obtain the added model attribute information; Send the added model attribute information to the medical consortium management device.

3. The model selection method according to claim 1, characterized in that, The downloading and deployment of the target model includes: Download the target model from the target device; Based on the computing power resource information, the target model is deployed in the cloud of the medical consortium model deployment device.

4. The model selection method according to claim 1, characterized in that, After downloading and deploying the target model, the method further includes: Upon receiving a model customization request from a hospital device, a model deployment strategy matching the hospital device is determined based on the first computing power resource information and the first business requirement in the model customization request; the first computing power resource information is the computing power resource information of the hospital device; the first business requirement is the business requirement of the hospital device. Send the model deployment strategy to the hospital equipment; Upon receiving confirmation of the model deployment strategy from the hospital equipment, the target model is deployed to the hospital equipment according to the model deployment strategy.

5. The model selection method according to claim 4, characterized in that, Deploying the target model for the hospital equipment according to the model deployment strategy includes: When the model deployment strategy is to not compress the target model, the model information of the target model is sent to the hospital equipment so that the hospital equipment can deploy the target model; When the model deployment strategy is to compress the target model according to a first preset compression ratio, the target model is compressed according to the first preset compression ratio to obtain a large medical model; When the model deployment strategy is to compress the target model according to the second preset compression ratio, the target model is compressed into a small medical model according to the second preset compression ratio; Send the large medical model or the small medical model to the hospital equipment so that the hospital equipment can deploy the large medical model or the small medical model; When the model deployment strategy is to not deploy the model at the hospital, a model invocation interface is configured for the hospital equipment so that the hospital equipment can invoke the target model according to the model invocation interface.

6. The model selection method according to claim 5, characterized in that, The step of determining a model deployment strategy to match the hospital equipment based on the first computing power resource information and the first business requirements in the model customization requirements includes: If the first computing power resource information includes intelligent computing power resources, and the first computing power resources corresponding to the intelligent computing power resources are greater than the computing power resources required to deploy and run the target model, then the model deployment strategy is determined to be not to compress the target model. If the first computing power resource information includes intelligent computing power resources, and the first computing power resources corresponding to the intelligent computing power resources are less than or equal to the computing power resources required to deploy and run the target model, then the model deployment strategy is determined to compress the target model according to the first preset compression ratio. If the first computing power resource information includes general computing power resources but does not include intelligent computing power resources, the model deployment strategy is determined to compress the target model according to the second preset compression ratio. If the first computing power resource corresponding to the first computing power resource information is less than or equal to the computing power resource threshold, and the first business demand identifier allows the processing of the business data of the hospital equipment on the medical consortium model deployment device side, then the model deployment strategy is determined to be not to deploy the model on the hospital side.

7. The model selection method according to claim 4, characterized in that, After deploying the target model to the hospital equipment according to the model deployment strategy, the method further includes: Upon receiving a model feedback instruction from the medical consortium management device, a model subscription request for a preset business domain is sent to the hospital device carried in the model feedback instruction; the preset business domain is the information carried in the model feedback instruction. Upon receiving a first model sent by the hospital device based on the model subscription request, the model features corresponding to the preset business domain are obtained from the first model; the first model is a model obtained by the hospital device after training or updating the target model. The target model is adjusted based on the model characteristics.

8. The model selection method according to claim 4, characterized in that, After deploying the target model to the hospital equipment according to the model deployment strategy, the method further includes: Send an update notification request for the target model to the target device; Upon receiving the update notification information of the target model sent by the target device, the update notification information is sent to the medical consortium management device; Upon receiving an update instruction from the medical consortium management device, an update request for the target model is sent to the target device. The system receives the updated target model sent by the target device based on the update request; the updated target model is the model obtained after the target device performs an update operation on the target model. The updated target model is adjusted based on the computing power resource information to obtain a second model, which is then deployed in the cloud of the medical consortium model deployment device.

9. The model selection method according to claim 8, characterized in that, The deployment of the second model in the cloud on the medical consortium model deployment device includes: The second model was validated, and the validation results were obtained. The second model was tested, and the test results were obtained. If both the verification and test results indicate that the second model is correct, the second model is deployed in the cloud of the medical consortium model deployment device.

10. The model selection method according to claim 8, characterized in that, After deploying the second model in the cloud on the medical consortium model deployment device, the method further includes: The second model is sent to the hospital equipment so that the hospital equipment can deploy the second model according to the model deployment strategy.

11. The model selection method according to claim 4, characterized in that, After deploying the target model to the hospital equipment according to the model deployment strategy, the method further includes: Receive the collaborative reasoning service instruction activated by the medical consortium management device for the hospital equipment; Upon receiving a collaborative reasoning request from the hospital device, the hospital device is authenticated based on the collaborative reasoning service instruction. Upon successful identity authentication, a response message agreeing to collaborative reasoning is sent to the hospital equipment. When the collaborative reasoning strategy of the hospital equipment is remote reasoning or joint reasoning, and a reasoning request sent by the hospital equipment is received, the data to be processed carried in the reasoning request is reasoned according to the collaborative reasoning service instruction and using the target model to obtain the reasoning result; the collaborative reasoning strategy is the strategy issued by the medical consortium management equipment to the hospital equipment; The inference result is sent to the hospital equipment.

12. A model selection method, characterized in that, Applied to a target device, the method includes: Upon receiving a model acquisition request from the medical consortium model deployment device, the business requirements are obtained from the model acquisition request; Among the multiple large models in the model library, find at least one model that matches the business requirement; Obtain model attribute information of at least one model; The model attribute information is sent to the medical consortium model deployment device so that the medical consortium model deployment device can use the medical consortium management device to determine the target model from the at least one model based on the model attribute information and the current computing power resource information of the medical consortium model deployment device; Upon receiving a download request for the target model from the medical consortium model deployment device, a download link for the target model is sent to the medical consortium model deployment device so that the medical consortium model deployment device can download and deploy the target model according to the download link.

13. A model selection method, characterized in that, The method, applied to medical consortium management equipment, includes: Send business requirements to the deployment equipment of the medical consortium model; the business requirements are the demand information of the medical consortium under the business corresponding to the medical big model. Upon receiving model attribute information and computing resource information sent by the medical consortium model deployment device based on the business requirements, the target model is determined from at least one model corresponding to the model attribute information according to the model attribute information and the computing resource information. The selection information of the target model is sent to the medical consortium model deployment device so that the medical consortium model deployment device can download and deploy the target model.

14. A model selection method, characterized in that, Applied to hospital equipment, the method includes: A model customization request is sent to the medical consortium model deployment device. The model customization request carries first computing power resource information and first business requirements, so that the medical consortium model deployment device can determine a model deployment strategy that matches the hospital equipment based on the first computing power resource information and the first business requirements. Receive the model deployment strategy sent by the medical consortium model deployment device; Generate a confirmation instruction for the model deployment strategy and send the confirmation instruction to the medical consortium model deployment device; Upon receiving the target model sent by the medical consortium model deployment device, the deployment process of the target model is executed according to the model deployment strategy.

15. The model selection method according to claim 14, characterized in that, After executing the deployment process of the target model according to the model deployment strategy, the method further includes: Upon receiving the collaborative reasoning strategy sent by the medical consortium management device and obtaining the data to be processed, the system detects the current second computing power resource information of the hospital device and the target model performance of the target model. If collaborative reasoning is required based on the second computing power resource information and the performance of the target model, a collaborative reasoning request is sent to the medical consortium model deployment device. Upon receiving a response from the medical consortium model deployment device agreeing to collaborative reasoning based on the collaborative reasoning request, the system sends the data to be processed to the medical consortium model deployment device based on the collaborative reasoning strategy, so that the medical consortium model deployment device can collaboratively process the data to be processed.

16. The model selection method according to claim 15, characterized in that, The step of sending the data to be processed to the medical consortium model deployment device based on the collaborative reasoning strategy includes: When the collaborative reasoning strategy is remote reasoning, the data to be processed is sent to the medical consortium model deployment device so that the medical consortium model deployment device can process the data to be processed using the target model in the cloud to obtain the reasoning result; When the collaborative reasoning strategy is joint reasoning, non-privacy type first data is obtained from the data to be processed, and the first data is sent to the medical consortium model deployment device so that the medical consortium model deployment device can process the first data using the target model in the cloud to obtain a first processing result. The second data is input into the first model to obtain the second processing result; the second data is the remaining data in the data to be processed excluding the first data; the first model is the model obtained by the hospital equipment after training or updating the target model sent by the target equipment. Upon receiving the first processing result sent by the medical consortium model deployment device, the first processing result and the second processing result are used as the inference result; When the collaborative reasoning strategy is local reasoning, the data to be processed is input into the first model to obtain the reasoning result.

17. A storage medium storing a computer program thereon, applicable to medical consortium model deployment equipment, medical consortium management equipment, target equipment, and hospital equipment, characterized in that, When executed by a processor, the computer program implements the method described in any one of claims 1 to 16.

18. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 16.

Images