WO2020206911A1 - 一种疾病分析模型的调度方法、装置及终端设备 - Google Patents

一种疾病分析模型的调度方法、装置及终端设备 Download PDF

Info

Publication number
WO2020206911A1
WO2020206911A1 PCT/CN2019/103109 CN2019103109W WO2020206911A1 WO 2020206911 A1 WO2020206911 A1 WO 2020206911A1 CN 2019103109 W CN2019103109 W CN 2019103109W WO 2020206911 A1 WO2020206911 A1 WO 2020206911A1
Authority
WO
WIPO (PCT)
Prior art keywords
disease analysis
gpu
disease
target
model
Prior art date
Application number
PCT/CN2019/103109
Other languages
English (en)
French (fr)
Inventor
朱军明
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2020206911A1 publication Critical patent/WO2020206911A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/50—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for simulation or modelling of medical disorders
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients

Definitions

  • This application belongs to the technical field of computer data processing, and in particular relates to a scheduling method, device and terminal equipment of a disease analysis model.
  • GPU graphics processing unit
  • analysis models based on deep learning technologies such as neural network models for disease analysis, etc.
  • GPU resource allocation is unreasonable, which affects data processing efficiency.
  • the embodiments of the present application provide a disease analysis model scheduling method, device, and terminal equipment to solve the problem that the disease analysis model existing in the related technology is allocated to the designated GPU for execution, and the GPU resource allocation is unreasonable, which affects the data. Deal with technical issues of efficiency.
  • the first aspect of the embodiments of the present application provides a method for scheduling a disease analysis model, including:
  • the disease analysis request carrying hospital data to be analyzed
  • the disease analysis request in the disease analysis request queue is allocated to the GPU in the GPU pool, and the GPU in the GPU pool is configured to call the target disease analysis model to process the Disease analysis request.
  • the second aspect of the embodiments of the present application provides a disease analysis model scheduling device, including:
  • a receiving unit configured to receive a disease analysis request sent by a user, the disease analysis request carrying hospital data to be analyzed;
  • the analysis unit is used to analyze the hospital data to obtain disease type information corresponding to the hospital data, determine a target disease analysis model from multiple disease analysis models according to the disease type information, and the target disease analysis model is used for analysis
  • the hospital data obtains the disease analysis result
  • the adding unit is configured to carry the model name of the target disease analysis model in the disease analysis request, and add the disease analysis request to the disease analysis request queue;
  • the first allocation unit is configured to allocate the disease analysis request in the disease analysis request queue to the GPU in the GPU pool according to the model name and the current state of the GPU pool, and the GPU in the GPU pool is configured to call The target disease analysis model processes the disease analysis request.
  • a third aspect of the embodiments of the present application provides a terminal device, including a memory and a processor.
  • the memory stores computer-readable instructions that can run on the processor.
  • the processor executes the computer When reading instructions, the following steps are implemented:
  • the disease analysis request carrying hospital data to be analyzed
  • the disease analysis request in the disease analysis request queue is allocated to the GPU in the GPU pool, and the GPU in the GPU pool is configured to call the target disease analysis model to process the Disease analysis request.
  • the fourth aspect of the embodiments of the present application provides a computer-readable storage medium that stores computer-readable instructions, and the computer-readable instructions implement the following steps when executed by a processor:
  • the disease analysis request carrying hospital data to be analyzed
  • the disease analysis request in the disease analysis request queue is allocated to the GPU in the GPU pool, and the GPU in the GPU pool is configured to call the target disease analysis model to process the Disease analysis request.
  • the model name of the target disease analysis model is carried in the disease analysis request, and then the disease analysis request is allocated to the GPU in the GPU pool according to the model name and the current state of the GPU pool. Due to comprehensive considerations The model name and the current state of the GPU pool make the GPU resource allocation more reasonable and improve the data processing efficiency.
  • Figure 1 is a specific implementation flowchart of a disease analysis model scheduling method provided by an embodiment of the present application
  • FIG. 2 is a specific implementation flowchart of another disease analysis model scheduling method provided by an embodiment of the present application.
  • FIG. 3 is a specific implementation flowchart of another disease analysis model scheduling method provided by an embodiment of the present application.
  • FIG. 4 is a specific implementation flowchart of another disease analysis model scheduling method provided by an embodiment of the present application.
  • FIG. 5 is a specific implementation flowchart of another disease analysis model scheduling method provided by an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a scheduling device for a disease analysis model provided by an embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of another disease analysis model scheduling device provided by an embodiment of the present application.
  • Fig. 8 is a schematic diagram of a terminal device provided by an embodiment of the present application.
  • first or “second” in this application is only used for descriptive purposes, and cannot be understood as indicating or implying its relative importance or implicitly indicating the number of indicated technical features. Therefore, a feature defined as “first” or “second” may explicitly or implicitly include at least one of the features.
  • FIG. 1 shows the implementation process of the scheduling method of the disease analysis model provided by the embodiment of the present application.
  • the scheduling method process includes steps S101 to S104. This scheduling method is suitable for situations where GPU resources need to be allocated to disease analysis models.
  • the scheduling method of the disease analysis model is executed by the scheduling device of the disease analysis model.
  • the scheduling device of the disease analysis model is configured in a terminal device and can be implemented by software and/or hardware. The specific implementation principle of each step is as follows.
  • S101 Receive a disease analysis request sent by a user, where the disease analysis request carries hospital data to be analyzed.
  • users refer to medical workers, such as doctors and nurses. After the user completes the chest CT, or performs abdominal color Doppler ultrasound, or performs ECG detection, etc., the user obtains hospital data, such as CT, color Doppler ultrasound, and ECG signals. At this time, it is usually necessary to analyze the patient's disease based on these hospital data to get the analysis result of whether he is healthy and whether he has a certain disease.
  • the user sends a disease analysis request carrying hospital data to the server.
  • the server receives the disease analysis request and schedules the disease analysis model to complete the disease analysis.
  • the server stores multiple different disease analysis models, and different disease diagnosis models are used to analyze hospital data of different diseases.
  • the type of disease information indicates the type of disease that may exist in the hospital data, including the type of cardiovascular disease, the type of lung disease, the type of liver disease, and the type of brain disease.
  • the server stores disease analysis models used to analyze cardiovascular diseases, lung diseases, liver diseases, brain diseases, etc., and each disease analysis model is used to analyze hospital data of one disease type to obtain disease analysis results.
  • the ECG signal analysis model is used to analyze the ECG signal to obtain the heart with normal ECG, left/right atrial hypertrophy, double atrial hypertrophy, left/right ventricular hypertrophy, double ventricular hypertrophy, various myocardial infarctions, various arrhythmias, etc. Analysis results of types of vascular diseases.
  • the hospital data is the ECG signal data
  • the corresponding disease information obtained from the analysis of the ECG signal data is the cardiovascular disease type.
  • the target disease analysis model is the ECG signal analysis model corresponding to the analysis of the ECG signal.
  • the signal analysis model is used to analyze the ECG signal to obtain the diagnosis result of the type of cardiovascular disease.
  • Disease analysis models include but are not limited to: linear models (such as logistic regression models), support vector machines based on kernel functions (Support Vector Machine, SVM) models (such as SVM with kernel function), deep neural network models (such as Convolutional Neural Network (CNN)), etc., this application does not specifically limit this.
  • the disease information corresponding to the hospital data is obtained, and the target disease analysis model for analyzing the hospital data is determined from multiple disease analysis models.
  • the embodiment of the application does not need to manually select a model, which improves the level of intelligence.
  • the obtaining disease type information corresponding to the hospital data by analyzing the hospital data includes steps 201 to 202.
  • S202 Acquire disease type information corresponding to the keyword as the disease type information corresponding to the hospital data.
  • each hospital data includes a certain keyword existing in the preset keyword library, for example, the preset keyword library includes: lung, heart, liver, leg bones, etc.
  • the preset keyword library includes: lung, heart, liver, leg bones, etc.
  • Each keyword corresponds to a disease type information, for example, the disease type information corresponding to the keyword "heart” is cardiovascular disease; the disease type information corresponding to the keyword "lung” is lung disease; and so on.
  • the disease type information corresponding to the keywords is obtained, so that the disease type information is used as the disease type information corresponding to the hospital data, so that in the subsequent steps, according to the
  • the disease type information determines a target disease analysis model from multiple disease analysis models, and the target disease analysis model is used to analyze the hospital data to obtain a disease analysis result.
  • the hospital data when the hospital data is ECG signal data, the data will contain the keyword "heart". If this keyword matches the keyword in the preset keyword database, then the keyword in the keyword database will correspond to The disease type information, that is, cardiovascular disease, is used as the disease type information of the hospital data. That is, by matching the keywords in the hospital data with the keywords in the keyword library, the disease type information corresponding to the successfully matched keyword is used as the disease type information corresponding to the hospital data.
  • S103 Carry the model name of the target disease analysis model in the disease analysis request, and add the disease analysis request to the disease analysis request queue.
  • model name of the target disease analysis model is written into the disease analysis request.
  • the model name is a preset name, which can be named according to preset rules or randomly. It only needs to ensure that the name of each disease analysis model is different. This application does not specifically limit the model name.
  • the target disease analysis model After determining the type of disease information corresponding to the hospital data, it is known which disease analysis model, that is, the target disease analysis model, is needed to process the hospital data to obtain the disease analysis result.
  • the target disease analysis model The model name of the disease analysis model is carried into the disease analysis request. Therefore, during the subsequent server processing the request, the target disease analysis model can be assigned to the request, which improves the distribution efficiency and shortens the data processing process.
  • the server usually receives more than one disease analysis request, in this embodiment of the present application, the disease analysis request received by the server is added to the disease analysis request queue, and the disease analysis request in the queue is subsequently scheduled.
  • the GPU pool includes several GPUs, and the GPUs in the GPU pool are configured to call the target disease analysis model to process the disease analysis request.
  • the target GPU in the GPU pool is determined, and a thread is established to call the target GPU to process the disease analysis request.
  • the model name carried in the disease analysis request is obtained from the GPU
  • Different numbers of GPUs are called in the pool to process the request, thereby obtaining the disease analysis result.
  • a single thread can be used to call one GPU at a time, which is low in data processing efficiency; it can also be multi-threaded, and multiple threads with the same or greater number of target GPUs can be established at the same time.
  • the number of GPUs required for each disease analysis model is different, and is related to the attributes of the disease analysis model, which is not specifically limited in this application.
  • the request is allocated to the GPU in the GPU pool according to the model name and the current state of the GPU pool. Since the model name and the current state of the GPU pool are considered comprehensively, the problem in the prior art can be solved.
  • the fixed allocation of GPU resources leads to technical problems such as low processing efficiency and waste of resources.
  • the disease analysis request in the disease analysis request queue is allocated to the GPU in the GPU pool according to the model name and the current state of the GPU pool. , Including steps 301 to 303.
  • the target GPU is It is configured to initialize the target disease analysis model handle, process the disease analysis request until completion, release the target disease analysis model handle after completion, and release the target GPU to the GPU pool.
  • the head-of-queue request is allocated. Since the queue head request carries the model name of the target disease analysis model, the target disease analysis model required by the queue head request can be determined. The number of GPUs required for each target disease analysis model is certain. Therefore, according to the GPU pool The number of idle GPUs in the middle, which processes the head of the queue request
  • each disease analysis model does not allocate a fixed GPU, but places the idle GPU in the GPU pool. According to the GPU pool, the allocation Head of queue request.
  • the queue head request is allocated to the target GPU of the target number in the GPU pool.
  • the target GPU After the target GPU is allocated the queue head request, it starts to initialize the target disease analysis model handle, and processes the disease analysis request until completion.
  • the target disease analysis model handle is released, and the target GPU is in an idle state at this time. In other words, after the target GPU processes the head-of-queue request, the target GPU is released to the GPU pool.
  • the model name of the target disease analysis model is carried in the disease analysis request in step 103, and the disease analysis request is added to The disease analysis request queue includes step 403.
  • S403 Carry the model name of the target disease analysis model in the disease analysis request, and add the disease analysis request to the disease analysis request queue corresponding to the model name.
  • step 104 allocating the disease analysis request in the disease analysis request queue to the GPU in the GPU pool includes steps 404 to 406.
  • S404 Acquire state information of the GPU pool corresponding to each model name; wherein the GPU in the GPU pool is configured to have completed the initialization of the target disease analysis model handle.
  • S405 If the state information of the GPU pool corresponding to the model name is idle, allocate the queue head request carrying the model name to the GPUs in the GPU pool, and mark the state information of the GPU pool as Busy; if the GPU in the GPU pool has processed the disease analysis request, mark the state information of the GPU pool as idle.
  • the disease analysis request is added to the disease analysis request queue corresponding to the model name. That is to say, for each disease analysis model, a disease analysis request queue is set up.
  • each disease analysis request is added to the corresponding disease request queue, so as to request for each disease For the queue, the GPU of the corresponding GPU pool is called to complete the processing of the disease request.
  • each disease request queue has a corresponding GPU pool.
  • the number of GPUs in each GPU pool is the number of GPUs required by the disease analysis model. Since the GPU of the GPU pool has determined the type of hospital data that needs to be processed, Each GPU is configured to have completed the initialization of the disease analysis model handle, and the disease analysis model corresponding to each GPU is fixed. Therefore, after completing the processing of the disease analysis request, there is no need to release the disease analysis model handle. It is necessary to frequently initialize and release the disease analysis model handle, which improves the efficiency of data processing.
  • the representative can process the head of the queue request in the corresponding disease request queue, and allocate the head of the queue request to the GPU pool.
  • the head of the queue request carrying the model name is selected Allocate to the GPU in the GPU pool, and mark the state information of the GPU pool as busy; if the GPU in the GPU pool has processed the disease analysis request, mark the state information of the GPU pool as free, so that Process the next head of queue request.
  • the status of the GPU pool corresponding to the model name is busy, it means that the GPU pool currently has processing tasks and cannot process the head of the request in the corresponding disease request queue. At this time, the allocation of the head of the queue carrying the model name is suspended. Request until the state information of the GPU pool is idle.
  • each disease analysis model is provided with a GPU pool correspondingly, so each GPU in each GPU pool is configured to have completed the initialization of the disease analysis model handle, and does not need to be released after processing a queue head request
  • the disease analysis model handle further improves the data processing efficiency.
  • step 403 carries the model name of the target disease analysis model in the disease analysis request, and sends the disease analysis request to Before being added to the disease analysis request queue corresponding to the model name, steps 501 to 503 are further included.
  • S501 For each disease analysis model, obtain the number of requests within the historical preset duration, the average duration of a single processing, and the number of GPUs required.
  • the historical preset duration can be selected and set based on experience, and it can be one month or one week, which is not specifically limited in this application.
  • step 501 the number of GPUs required for each disease analysis model and statistical data of each disease analysis model are obtained.
  • the statistical data includes the number of requests and the average duration of a single processing.
  • step 502 the GPU resource ratio of each disease analysis model is calculated in combination with the number of requests, the average duration, and the number of GPUs required. Therefore, in step 503, a corresponding GPU pool is allocated for each disease analysis model according to the proportion of GPU resources.
  • the GPU resources of the computing system are limited.
  • the GPU resources are allocated after calculating the proportion of GPU resources for each disease analysis model to realize the resources Maximize utilization and improve the performance of computing systems.
  • the weighted calculation according to the number of requests, the average duration, and the number of required GPUs to obtain the GPU resource proportion of each disease analysis model includes:
  • ⁇ i 1 n is the sum of i from 1 to n, and n is the total number of disease analysis models.
  • A, B, and C are empirical values, which are preset constants, and can also be selected and set as required, and this application does not specifically limit this.
  • FIG. 6 shows a structural block diagram of the disease analysis model scheduling device provided in an embodiment of the present application. For ease of description, only the same as the embodiment of the present application is shown. The relevant part.
  • the scheduling device of the disease analysis model includes:
  • the receiving unit 61 is configured to receive a disease analysis request sent by a user, the disease analysis request carrying hospital data to be analyzed;
  • the analysis unit 62 is configured to analyze the hospital data to obtain disease type information corresponding to the hospital data, and determine a target disease analysis model from multiple disease analysis models according to the disease type information, and the target disease analysis model is used for Analyzing the hospital data to obtain disease analysis results;
  • the adding unit 63 is configured to carry the model name of the target disease analysis model in the disease analysis request, and add the disease analysis request to the disease analysis request queue;
  • the first allocation unit 64 is configured to allocate the disease analysis request in the disease analysis request queue to the GPU in the GPU pool according to the model name and the current state of the GPU pool, and the GPU in the GPU pool is configured to Call the target disease analysis model to process the disease analysis request.
  • the first allocation unit 64 is specifically configured to:
  • the target GPU is configured to Initialize the target disease analysis model handle, process the disease analysis request until completion, release the target disease analysis model handle after completion, and release the target GPU to the GPU pool;
  • the allocation of the head of queue request is suspended until the number of free GPUs in the GPU pool is greater than or equal to the target number.
  • the adding unit 63 is specifically configured to:
  • the disease analysis request carries the model name of the target disease analysis model, and the disease analysis request is added to the disease analysis request queue corresponding to the model name.
  • the first allocation unit 64 is specifically configured to:
  • state information of the GPU pool corresponding to the model name is idle, assign the queue head request carrying the model name to the GPUs in the GPU pool, and mark the state information of the GPU pool as busy; If the GPU in the GPU pool has processed the disease analysis request, mark the state information of the GPU pool as idle;
  • the allocation of the queue head request carrying the model name is suspended until the state information of the GPU pool is idle.
  • the scheduling device of the disease analysis module further includes a second allocation unit 55 for:
  • a corresponding GPU pool is allocated for each disease analysis model, and the model name and the GPU pool are associated and stored.
  • the weighted calculation according to the number of requests, the average duration, and the number of required GPUs to obtain the GPU resource proportion of each disease analysis model includes:
  • ⁇ i 1 n is the sum of i from 1 to n, and n is the total number of disease analysis models.
  • the analyzing the hospital data to obtain the disease type information corresponding to the hospital data includes:
  • the disease type information corresponding to the keyword is acquired as the disease type information corresponding to the hospital data.
  • FIG. 8 is a schematic diagram of a terminal device provided by an embodiment of the present application.
  • the terminal device 8 of this embodiment includes: a processor 80, a memory 81, and computer-readable instructions 82 stored in the memory 81 and running on the processor 80, such as a disease analysis model The scheduling program.
  • the processor 80 executes the computer-readable instructions 82, the steps in the foregoing embodiment of the scheduling method for each disease analysis model are implemented, such as steps 101 to 104 shown in FIG. 1.
  • the processor 80 executes the computer-readable instructions 82
  • the functions of the modules/units in the foregoing device embodiments, such as the functions of the units 61 to 64 shown in FIG. 6, are realized.
  • the computer-readable instruction 82 may be divided into one or more modules/units, and the one or more modules/units are stored in the memory 81 and executed by the processor 80, To complete this application.
  • the one or more modules/units may be a series of computer-readable instruction instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer-readable instruction 82 in the terminal device 8.
  • the terminal device 8 may be a computing device such as a server, a desktop computer, a notebook, a palmtop computer, and a cloud server.
  • the terminal device may include, but is not limited to, a processor 80 and a memory 81.
  • FIG. 8 is only an example of the terminal device 8 and does not constitute a limitation on the terminal device 8. It may include more or less components than shown in the figure, or a combination of certain components, or different components.
  • the terminal device may also include input and output devices, network access devices, buses, etc.
  • the so-called processor 80 may be a central processing unit (Central Processing Unit, CPU), other general-purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc.
  • the general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like.
  • the memory 81 may be an internal storage unit of the terminal device 8, such as a hard disk or memory of the terminal device 8.
  • the memory 81 may also be an external storage device of the terminal device 8, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), or a secure digital (Secure Digital, SD) equipped on the terminal device 8. Card, Flash Card, etc.
  • the memory 81 may also include both an internal storage unit of the terminal device 8 and an external storage device.
  • the memory 81 is used to store the computer-readable instructions and other programs and data required by the terminal device.
  • the memory 81 can also be used to temporarily store data that has been output or will be output.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • the integrated module/unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
  • Non-volatile memory can include read-only memory (Read-Only Memory, ROM), programmable ROM (ProgrammableROM, PROM), erasable programmable ROM (Erasable Programmable ROM, EPROM), electrically erasable programmable ROM (Electrically Erasable Programmable ROM, EEPROM) or flash memory. Volatile memory may include random access memory (Random Access Memory, RAM) or external cache memory. As an illustration and not a limitation, RAM is available in many forms, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), and Double Data Rate SDRAM (Double Data Rate SDRAM).
  • SRAM Static RAM
  • DRAM Dynamic RAM
  • SDRAM Synchronous DRAM
  • SDRAM Double Data Rate SDRAM
  • DDRSDRAM DDRSDRAM
  • enhanced SDRAM Enhanced SDRAM, ESDRAM
  • synchronous link DRAM SynLink DRAM, SLDRAM
  • memory bus DRAM Rabus DRAM, RDRAM
  • direct memory bus DRAM Direct Rambus DRAM, DRDRAM

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • Data Mining & Analysis (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Biomedical Technology (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Pathology (AREA)
  • Software Systems (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • General Engineering & Computer Science (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

一种疾病分析模型的调度方法、装置及终端设备，适用于计算机数据处理技术领域，所述方法包括：接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据（S101）；分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型（S102）；在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列（S103）；根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU（S104）。所述方法根据所述模型名称和GPU池的当前状态，将携带有模型名称的疾病分析请求分配给GPU池中的GPU，使得GPU资源分配更合理，提高了数据处理效率。

Description

一种疾病分析模型的调度方法、装置及终端设备
本申请要求于2019年04月11日提交中国专利局、申请号为201910288569.5、发明名称为“一种疾病分析模型的调度方法、装置及终端设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请属于计算机数据处理技术领域，尤其涉及一种疾病分析模型的调度方法、装置及终端设备。
 背景技术
随着图形处理器（Graphics Processing Unit，GPU）技术的不断进步，GPU逐渐成为计算系统中最重要的加速部件之一。GPU技术在世界各地的政府、实验室、大学、大型以及中小企业等得到广泛的应用，越来越多的算法被移植到GPU芯片上执行。
目前，基于深度学习技术等的分析模型，例如，用于疾病分析的神经网络模型等等，通常被分配给指定的GPU芯片执行，GPU资源分配不合理，影响了数据处理效率。
 技术问题
有鉴于此，本申请实施例提供了一种疾病分析模型的调度方法、装置及终端设备，以解决相关技术存在的疾病分析模型被分配给指定的GPU执行，GPU资源分配不合理，影响了数据处理效率的技术问题。
 技术解决方案
本申请实施例的第一方面提供了一种疾病分析模型的调度方法，包括：
接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据；
分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，所述目标疾病分析模型用于分析所述医院数据获得疾病分析结果；
在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列；
根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。
本申请实施例的第二方面提供了一种疾病分析模型的调度装置，包括：
接收单元，用于接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据；
分析单元，用于分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，所述目标疾病分析模型用于分析所述医院数据获得疾病分析结果；
添加单元，用于在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列；
第一分配单元，用于根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。
本申请实施例的第三方面提供了一种终端设备，包括存储器以及处理器，所述存储器中存储有可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时，实现如下步骤：
接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据；
分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，所述目标疾病分析模型用于分析所述医院数据获得疾病分析结果；
在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列；
根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。
本申请实施例的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如下步骤：
接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据；
分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，所述目标疾病分析模型用于分析所述医院数据获得疾病分析结果；
在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列；
根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。
 有益效果
在本申请实施例中，通过先接收用户发送的携带待分析的医院数据的疾病分析请求；分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型；在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列；最后根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池。本申请实施例通过在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，然后根据模型名称和GPU池的当前状态，将疾病分析请求分配给GPU池中的GPU，由于综合考虑到了模型名称和GPU池的当前状态，使得GPU资源分配更合理，提高了数据处理效率。
 附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍。
图1是本申请实施例提供的一种疾病分析模型的调度方法的具体实现流程图；
图2是本申请实施例提供的另一种疾病分析模型的调度方法的具体实现流程图；
图3是本申请实施例提供的另一种疾病分析模型的调度方法的具体实现流程图；
图4是本申请实施例提供的另一种疾病分析模型的调度方法的具体实现流程图；
图5是本申请实施例提供的另一种疾病分析模型的调度方法的具体实现流程图；
图6是本申请实施例提供的一种疾病分析模型的调度装置的结构示意图；
图7是本申请实施例提供的另一种疾病分析模型的调度装置的结构示意图；
图8是本申请实施例提供的终端设备的示意图。
 本发明的实施方式
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。
另外，在本申请中若涉及“第一”或“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”或“第二”等的特征可以明示或者隐含地包括至少一个该特征。
为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。
图1示出了本申请实施例提供的疾病分析模型的调度方法的实现流程，该调度方法流程包括步骤S101至S104。该调度方法适用于需要对疾病分析模型分配GPU资源的情形。该疾病分析模型的调度方法由疾病分析模型的调度装置执行，所述疾病分析模型的调度装置配置于终端设备，可由软件和/或硬件实现。各步骤的具体实现原理如下。
S101，接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据。
其中，用户指的是医护工作者，例如医生和护士等。当用户给病人拍完胸部CT，或做完腹部彩超、或进行心电探测等之后，获取到医院数据，例如CT、彩超、心电信号等。此时，通常需要根据这些医院数据进行病人的疾病分析，得到是否健康，是否患有某种疾病的分析结果。用户将携带有医院数据的疾病分析请求发送至服务器。服务器接收疾病分析请求，进行疾病分析模型的调度，以完成疾病分析。
S102，分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，所述目标疾病分析模型用于分析所述医院数据获得疾病分析结果。
其中，服务器存储有多个不同的疾病分析模型，不同的疾病诊断模型用于对不同病种的医院数据进行分析。
病种信息表示医院数据可能存在的疾病类型，包括心血管疾病类型、肺疾病类型、肝疾病类型、脑疾病类型等。
也就是说，服务器中存储有用于分析心血管疾病、肺疾病、肝疾病、脑疾病等的疾病分析模型，每个疾病分析模型用于分析一种病种的医院数据，从而得到疾病分析结果。
例如，心电信号分析模型用于分析心电信号，得到心电图正常、左/右心房肥大、双心房肥大、左/右心室肥大、双心室肥大、各类心肌梗死、各类心律失常等等心血管疾病类型的分析结果。当医院数据为心电信号数据，根据分析心电信号数据得到对应的病种信息为心血管疾病类型，此时，目标疾病分析模型为对应分析心电信号的心电信号分析模型，该心电信号分析模型用于分析心电信号，得到心血管疾病类型的诊断结果。
需要说明的是，利用疾病分析模型分析医院数据得到何种分析结果，根疾病分析模型的属性相关。疾病分析模型包括但不限于：线性模型（如逻辑斯特回归模型）、基于核函数的支持向量机（Support Vector Machine，SVM）模型（如采用核函数的SVM）、深度神经网络模型（如卷积神经网络（Convolutional Neural Network，CNN））等，本申请对此不做具体限定。
通过分析医院数据，得到医院数据对应的病种信息，从而从多个疾病分析模型中确定出分析医院数据的目标疾病分析模型。本申请实施例不需要人为选定模型，提高了智能化水平。
可选地，如图2所示，所述通过分析所述医院数据得到所述医院数据对应的病种信息，包括步骤201至202。
S201，提取所述医院数据中存在于预设关键字库中的关键字。
S202，获取与所述关键字对应的病种信息，作为所述医院数据对应的病种信息。
其中，每个医院数据都包括存在于预设关键字库中的某一个关键字，比如，预设关键字库包括：肺、心、肝、腿骨等。每个关键字对应一个病种信息，如，关键字“心”对应的病种信息为心血管疾病；关键字“肺”对应的病种信息为肺部疾病；等等。提取出预设关键字库中存在的关键字后，获取与关键字对应的病种信息，从而将所述病种信息作为所述医院数据对应的病种信息，以便在后续的步骤中根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，利用所述目标疾病分析模型分析所述医院数据得出疾病分析结果。
示例性地，医院数据为心电信号数据时，数据中会包含“心”这个关键字，这个关键字与预设关键字库中的关键字匹配，则将关键字库中的关键字对应的病种信息，即心血管疾病，作为所述医院数据的病种信息。也就是说，通过将医院数据中的关键字与关键字库中的关键字进行匹配，将匹配成功的关键字对应的病种信息作为所述医院数据对应的病种信息。
S103，在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列。
其中，为了对获取到的疾病分析请求携带的医院数据进行准确分析，得到疾病诊断结果，将目标疾病分析模型的模型名称写进所述疾病分析请求。模型名称为预设定的名称，可以按照预设规则进行命名，也可以随机命名，只需要保证每个疾病分析模型的名称不同即可，本申请对模型名称不作具体限定。
也就是说，当确定所述医院数据对应的病种信息之后，就知道需要用哪种疾病分析模型，即目标疾病分析模型来处理这个医院数据以得到疾病分析结果，本申请实施例中将目标疾病分析模型的模型名称携带进疾病分析请求，因此，在后续服务器处理这个请求的过程中，能给该请求分配目标疾病分析模型，提高分配效率，缩短数据处理过程。
由于服务器接收到的疾病分析请求通常不止一个，因此，在本申请实施例中，将服务器接收到的疾病分析请求添加至疾病分析请求队列，对队列中的疾病分析请求作后续调度处理。
S104，根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。
其中，GPU池包括若干个GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。当要处理所述疾病分析请求队列中的疾病分析请求时，确定GPU池中的目标GPU，建立线程调用目标GPU对疾病分析请求进行处理，线程建立时，根据疾病分析请求携带的模型名称从GPU池中调用不同数量的GPU对请求进行处理，从而得到疾病分析结果。在本申请实施例中，可以采用单线程，每次调用一个GPU，这种方式数据处理效率偏低；也可以采用多线程，同时建立与目标GPU数量相同或大于目标GPU数量的多个线程，从而实现多线程服务，提升系统的整体性能，提高数据处理效率。此外，在采用多线程时，在GPU池的GPU资源足够的情况下，还可以同时处理多个疾病分析请求，进一步提高了数据处理效率。
需要说明的是，每个疾病分析模型所需GPU数量是不相同的，跟疾病分析模型的自身属性有关，本申请对此不做具体限定。在本申请实施例中，根据所述模型名称和GPU池的当前状态，将请求分配至GPU池中的GPU，由于综合考虑了模型名称和GPU池的当前状态，从而能解决现有技术中对GPU资源固定分配，导致处理效率低下，资源浪费的技术问题。
可选地，如图3所示，作为本申请一实施例，所述根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，包括步骤301至303。
S301，获取所述疾病分析请求队列中的队列头请求，根据所述队列头请求携带的模型名称确定所述队列头请求需要使用的目标疾病分析模型，并确定所述目标疾病分析模型所需GPU的目标数量。
S302，若GPU池中空闲GPU的数量大于或等于所述目标数量，则从所述空闲GPU中确定目标数量的目标GPU，将所述队列头请求分配至所述目标GPU；所述目标GPU被配置成初始化所述目标疾病分析模型句柄，处理所述疾病分析请求直至完成，在完成之后释放所述目标疾病分析模型句柄，并释放所述目标GPU至GPU池。
S303，若GPU池中空闲GPU的数量小于所述目标数量，则暂停分配所述队列头请求，直至所述GPU池中空闲GPU的数量大于或等于所述目标数量。
在本申请实施例中，每次从疾病分析请求队列中取出队列头请求，对队列头请求进行分配。由于队列头请求携带有目标疾病分析模型的模型名称，因而可以确定出该队列头请求所需的目标疾病分析模型，每个目标疾病分析模型所需的GPU数量是一定的，因此，根据GPU池中空闲GPU的数量，对队列头请求做出处理。
在这种情况下，每个疾病分析模型所需的GPU数量是确定的，但是每个疾病分析模型并未分配固定的GPU，而是将空闲GPU置于GPU池，根据GPU池的情况，分配队列头请求。
当GPU池中空闲GPU的数量大于或等于目标疾病分析模型所需的GPU数量时，则将队列头请求分配至GPU池中目标数量的目标GPU。目标GPU被分配队列头请求后，才开始初始化所述目标疾病分析模型句柄，处理所述疾病分析请求直至完成。当目标GPU处理完所述队列头请求，则释放所述目标疾病分析模型句柄，此时目标GPU为空闲状态。也即是说，当目标GPU处理完队列头请求后，释放所述目标GPU至GPU池。
可选地，作为本申请另一实施例，如图4所示，步骤103所述在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列，包括步骤403。
S403，在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至与所述模型名称对应的疾病分析请求队列。
相应的，步骤104所述根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，包括步骤404至406。
S404，获取每个所述模型名称对应的GPU池的状态信息；其中，GPU池中的GPU被配置成已经完成目标疾病分析模型句柄的初始化。
S405，若模型名称对应的GPU池的状态信息为空闲，则将携带有所述模型名称的所述队列头请求分配至所述GPU池中的GPU，并将所述GPU池的状态信息标记为忙碌；若所述GPU池中的GPU处理完所述疾病分析请求，标记所述GPU池的状态信息为空闲。
S406，若模型名称对应的GPU池的状态信息为忙碌，则暂停分配携带有所述模型名称的所述队列头请求，直至所述GPU池的状态信息为空闲。
在本申请实施例中，在所述疾病分析请求中携带所述目标疾病分析模型的模型名称之后，将所述疾病分析请求添加至与所述模型名称对应的疾病分析请求队列。也就是说，对应每个疾病分析模型，分别设一个疾病分析请求队列，当接收到多个疾病分析请求时，将每个疾病分析请求添加至对应的疾病请求队列中，从而针对每个疾病请求队列而言，调用对应的GPU池的GPU完成疾病请求的处理。
需要指出的是，每个疾病请求队列有对应的GPU池，每个GPU池的GPU数量为疾病分析模型所需的GPU数量，由于GPU池的GPU已经确定了需要处理的医院数据的类型，因而每个GPU被配置为已经完成疾病分析模型句柄初始化，并且每个GPU对应的疾病分析模型是固定的，因而，在完成疾病分析请求的处理之后，也不需要释放疾病分析模型句柄，这样设置不需频繁初始化和释疾病分析模型句柄，提高了数据处理效率。
当模型名称对应的GPU池状态为空闲时，代表可以处理对应疾病请求队列中的队列头请求，将队列头请求分配至所述GPU池，当将携带有所述模型名称的所述队列头请求分配至所述GPU池中的GPU，将所述GPU池的状态信息标记为忙碌；若所述GPU池中的GPU处理完所述疾病分析请求，标记所述GPU池的状态信息为空闲，以便处理下一个队列头请求。当模型名称对应的GPU池的状态为忙碌时，代表GPU池当前存在处理任务，不能处理对应的疾病请求队列中的队列头请求，此时，暂停分配携带有所述模型名称的所述队列头请求，直至所述GPU池的状态信息为空闲。
本申请实施例中，每个疾病分析模型对应设置有GPU池，因而各个GPU池中的每个GPU都被配置为已经完成疾病分析模型句柄初始化，在处理完一个队列头请求之后也不需释放疾病分析模型句柄，进一步提高了数据处理效率。
可选地，在上述图4所述实施例的基础上，如图5所示，步骤403在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至与所述模型名称对应的疾病分析请求队列之前，还包括步骤501至503。
S501，针对每个疾病分析模型，获取历史预设时长内的请求数量、单次处理的平均时长、以及所需GPU数量。
S502，根据所述请求数量、所述平均时长和所述所需GPU数量加权计算得到每个疾病分析模型的GPU资源占比。
S503，根据所述GPU资源占比，为每个疾病分析模型分配对应的GPU池，将模型名称和GPU池进行关联存储。
在本申请实施例中，历史预设时长可以根据经验进行选择设置，可以为一个月，一个星期，本申请对此不做具体限制。在步骤501中，获取每个疾病分析模型所需的GPU数量，以及每个疾病分析模型的统计数据，统计数据包括，请求数量和单次处理的平均时长。
在步骤502中，结合所述请求数量、平均时长和所需GPU数量计算每个疾病分析模型的GPU资源占比。从而在步骤503中，根据所述GPU资源占比，为每个疾病分析模型分配对应的GPU池。
需要说明的是，计算系统的GPU资源是有限的，在本申请实施例中，为了最大限度利用有限的GPU资源，计算出每个疾病分析模型的GPU资源占比之后分配GPU资源，以实现资源最大化利用，提升计算系统的性能。
可选地，所述根据所述请求数量、所述平均时长和所述所需GPU数量加权计算得到每个疾病分析模型的GPU资源占比，包括：
根据公式 G i =( AX i + BY i + CZ i )/∑ i =1 n( X iY iZ i )计算疾病分析模型 i的GPU资源占比 G i ，其中，疾病分析模型 i在历史预设时长内的请求数量为 X i ，单次处理的平均时长为 Y i ，所需GPU数量为 Z i ； A、 B和 C为预设常数。∑ i =1 n为针对 i从1至n求和，n为疾病分析模型的总数量。
需要说明的是，A、B和C为经验值，为预设常数，也可以根据需要选择设置，本申请对此不做具体限定。
对应于上文实施例所述的疾病分析模型的调度方法，图6示出了本申请实施例提供的疾病分析模型的调度装置的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。
参照图6，该疾病分析模型的调度装置包括：
接收单元61，用于接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据；
分析单元62，用于分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，所述目标疾病分析模型用于分析所述医院数据获得疾病分析结果；
添加单元63，用于在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列；
第一分配单元64，用于根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。
可选地，所述第一分配单元64具体用于：
获取所述疾病分析请求队列中的队列头请求，根据所述队列头请求携带的模型名称确定所述队列头请求需要使用的目标疾病分析模型，并确定所述目标疾病分析模型所需GPU的目标数量；
若GPU池中空闲GPU的数量大于或等于所述目标数量，则从所述空闲GPU中确定目标数量的目标GPU，将所述队列头请求分配至所述目标GPU；所述目标GPU被配置成初始化所述目标疾病分析模型句柄，处理所述疾病分析请求直至完成，在完成之后释放所述目标疾病分析模型句柄，并释放所述目标GPU至GPU池；
若GPU池中空闲GPU的数量小于所述目标数量，则暂停分配所述队列头请求，直至所述GPU池中空闲GPU的数量大于或等于所述目标数量。
可选地，所述添加单元63，具体用于：
在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至与所述模型名称对应的疾病分析请求队列。
相应的，所述第一分配单元64具体用于：
获取每个所述模型名称对应的GPU池的状态信息；其中，GPU池中的GPU被配置成已经完成目标疾病分析模型句柄的初始化；
若模型名称对应的GPU池的状态信息为空闲，则将携带有所述模型名称的所述队列头请求分配至所述GPU池中的GPU，并将所述GPU池的状态信息标记为忙碌；若所述GPU池中的GPU处理完所述疾病分析请求，标记所述GPU池的状态信息为空闲；
若模型名称对应的GPU池的状态信息为忙碌，则暂停分配携带有所述模型名称的所述队列头请求，直至所述GPU池的状态信息为空闲。
可选地，如图7所示，所述疾病分析模块的调度装置，还包括第二分配单元55，用于：
针对每个疾病分析模型，获取历史预设时长内的请求数量、单次处理的平均时长、以及所需GPU数量；
根据所述请求数量、所述平均时长和所述所需GPU数量加权计算得到每个疾病分析模型的GPU资源占比；
根据所述GPU资源占比，为每个疾病分析模型分配对应的GPU池，将模型名称和GPU池进行关联存储。
可选地，所述根据所述请求数量、所述平均时长和所述所需GPU数量加权计算得到每个疾病分析模型的GPU资源占比，包括：
根据公式 G i =( AX i + BY i + CZ i )/∑ i =1 n( X iY iZ i )计算疾病分析模型 i的GPU资源占比 G i ，其中，疾病分析模型 i在历史预设时长内的请求数量为 X i ，单次处理的平均时长为 Y i ，所需GPU数量为 Z i ； A、 B和 C为预设常数。∑ i =1 n为针对 i从1至n求和，n为疾病分析模型的总数量。
可选地，所述分析所述医院数据得到所述医院数据对应的病种信息，包括：
提取所述医院数据中存在于预设关键字库中的关键字；
获取与所述关键字对应的病种信息，作为所述医院数据对应的病种信息。
图8是本申请一实施例提供的终端设备的示意图。如图8所示，该实施例的终端设备8包括：处理器80、存储器81以及存储在所述存储器81中并可在所述处理器80上运行的计算机可读指令82，例如疾病分析模型的调度的程序。所述处理器80执行所述计算机可读指令82时实现上述各个疾病分析模型的调度方法实施例中的步骤，例如图1所示的步骤101至104。或者，所述处理器80执行所述计算机可读指令82时实现上述各装置实施例中各模块/单元的功能，例如图6所示单元61至64的功能。
示例性的，所述计算机可读指令82可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器81中，并由所述处理器80执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令指令段，该指令段用于描述所述计算机可读指令82在所述终端设备8中的执行过程。
所述终端设备8可以是服务器、桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于，处理器80、存储器81。本领域技术人员可以理解，图8仅仅是终端设备8的示例，并不构成对终端设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器80可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器 (Digital Signal Processor，DSP)、专用集成电路 (Application Specific Integrated Circuit，ASIC)、现场可编程门阵列 (Field-Programmable Gate Array，FPGA) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器81可以是所述终端设备8的内部存储单元，例如终端设备8的硬盘或内存。所述存储器81也可以是所述终端设备8的外部存储设备，例如所述终端设备8上配备的插接式硬盘，智能存储卡（Smart Media Card，SMC），安全数字（Secure Digital，SD）卡，闪存卡（Flash Card）等。进一步地，所述存储器81还可以既包括所述终端设备8的内部存储单元也包括外部存储设备。所述存储器81用于存储所述计算机可读指令以及所述终端设备所需的其他程序和数据。所述存储器81还可以用于暂时地存储已经输出或者将要输出的数据。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储于一计算机可读取存储介质中，该计算机可读指令被处理器执行时，可实现包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（Read-Only Memory，ROM）、可编程ROM（ProgrammableROM，PROM）、可擦除可编程ROM（Erasable Programmable ROM，EPROM）、带电可擦除可编程ROM（Electrically Erasable Programmable ROM，EEPROM）或闪存。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（StaticRAM，SRAM）、动态RAM（Dynamic RAM，DRAM）、同步DRAM（SynchronousDRAM，SDRAM）、双数据率SDRAM（Double Data Rate SDRAM，DDRSDRAM）、增强型SDRAM（EnhancedSDRAM，ESDRAM）、同步链路DRAM（SyncLink DRAM，SLDRAM）、存储器总线DRAM（Rambus DRAM，RDRAM）、以及直接存储器总线DRAM（Direct Rambus DRAM，DRDRAM）等。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (20)

  1. 一种疾病分析模型的调度方法，其特征在于，包括：
    接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据；
    分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，所述目标疾病分析模型用于分析所述医院数据获得疾病分析结果；
    在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列；
    根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。
  2. 如权利要求1所述的调度方法，其特征在于，所述根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，包括：
    获取所述疾病分析请求队列中的队列头请求，根据所述队列头请求携带的模型名称确定所述队列头请求需要使用的目标疾病分析模型，并确定所述目标疾病分析模型所需GPU的目标数量；
    若GPU池中空闲GPU的数量大于或等于所述目标数量，则从所述空闲GPU中确定目标数量的目标GPU，将所述队列头请求分配至所述目标GPU；所述目标GPU被配置成初始化所述目标疾病分析模型句柄，处理所述疾病分析请求直至完成，在完成之后释放所述目标疾病分析模型句柄，并释放所述目标GPU至GPU池；
    若GPU池中空闲GPU的数量小于所述目标数量，则暂停分配所述队列头请求，直至所述GPU池中空闲GPU的数量大于或等于所述目标数量。
  3. 如权利要求1所述的调度方法，其特征在于，所述在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列，包括：
    在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至与所述模型名称对应的疾病分析请求队列。
  4. 如权利要求3所述的调度方法，其特征在于，所述根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，包括：
    获取每个所述模型名称对应的GPU池的状态信息；其中，GPU池中的GPU被配置成已经完成目标疾病分析模型句柄的初始化；
    若模型名称对应的GPU池的状态信息为空闲，则将携带有所述模型名称的所述队列头请求分配至所述GPU池中的GPU，并将所述GPU池的状态信息标记为忙碌；若所述GPU池中的GPU处理完所述疾病分析请求，标记所述GPU池的状态信息为空闲；
    若模型名称对应的GPU池的状态信息为忙碌，则暂停分配携带有所述模型名称的所述队列头请求，直至所述GPU池的状态信息为空闲。
  5. 如权利要求3或4所述的调度方法，其特征在于，在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至与所述模型名称对应的疾病分析请求队列之前，还包括：
    针对每个疾病分析模型，获取历史预设时长内的请求数量、单次处理的平均时长、以及所需GPU数量；
    根据所述请求数量、所述平均时长和所述所需GPU数量加权计算得到每个疾病分析模型的GPU资源占比；
    根据所述GPU资源占比，为每个疾病分析模型分配对应的GPU池，将模型名称和GPU池进行关联存储。
  6. 如权利要求5所述的调度方法，其特征在于，所述根据所述请求数量、所述平均时长和所述所需GPU数量加权计算得到每个疾病分析模型的GPU资源占比，包括：
    根据公式 G i =( AX i + BY i + CZ i )/∑ i =1 n( X iY iZ i )计算疾病分析模型 i的GPU资源占比 G i ，其中，疾病分析模型 i在历史预设时长内的请求数量为 X i ，单次处理的平均时长为 Y i ，所需GPU数量为 Z i ； A、 B和 C为预设常数。
  7. 如权利要求1至4任一项所述的调度方法，其特征在于，所述分析所述医院数据得到所述医院数据对应的病种信息，包括：
    提取所述医院数据中存在于预设关键字库中的关键字；
    获取与所述关键字对应的病种信息，作为所述医院数据对应的病种信息。
  8. 一种疾病分析模型的调度装置，其特征在于，包括：
    接收单元，用于接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据；
    分析单元，用于分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，所述目标疾病分析模型用于分析所述医院数据获得疾病分析结果；
    添加单元，用于在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列；
    第一分配单元，用于根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。
  9. 如权利要求8所述的调度装置，其特征在于，所述第一分配单元具体用于：
    获取所述疾病分析请求队列中的队列头请求，根据所述队列头请求携带的模型名称确定所述队列头请求需要使用的目标疾病分析模型，并确定所述目标疾病分析模型所需GPU的目标数量；
    若GPU池中空闲GPU的数量大于或等于所述目标数量，则从所述空闲GPU中确定目标数量的目标GPU，将所述队列头请求分配至所述目标GPU；所述目标GPU被配置成初始化所述目标疾病分析模型句柄，处理所述疾病分析请求直至完成，在完成之后释放所述目标疾病分析模型句柄，并释放所述目标GPU至GPU池；
    若GPU池中空闲GPU的数量小于所述目标数量，则暂停分配所述队列头请求，直至所述GPU池中空闲GPU的数量大于或等于所述目标数量。
  10. 如权利要求8所述的调度装置，其特征在于，所述添加单元具体用于：
    在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至与所述模型名称对应的疾病分析请求队列。
  11. 如权利要求10所述的调度装置，其特征在于，所述第一分配单元具体用于：
    获取每个所述模型名称对应的GPU池的状态信息；其中，GPU池中的GPU被配置成已经完成目标疾病分析模型句柄的初始化；
    若模型名称对应的GPU池的状态信息为空闲，则将携带有所述模型名称的所述队列头请求分配至所述GPU池中的GPU，并将所述GPU池的状态信息标记为忙碌；若所述GPU池中的GPU处理完所述疾病分析请求，标记所述GPU池的状态信息为空闲；
    若模型名称对应的GPU池的状态信息为忙碌，则暂停分配携带有所述模型名称的所述队列头请求，直至所述GPU池的状态信息为空闲。
  12. 如权利要求10或11所述的调度装置，其特征在于，所述调度装置还包括第二分配单元，所述第二分配单元用于：
    针对每个疾病分析模型，获取历史预设时长内的请求数量、单次处理的平均时长、以及所需GPU数量；
    根据所述请求数量、所述平均时长和所述所需GPU数量加权计算得到每个疾病分析模型的GPU资源占比；
    根据所述GPU资源占比，为每个疾病分析模型分配对应的GPU池，将模型名称和GPU池进行关联存储。
  13. 如权利要求12所述的调度装置，其特征在于，所述根据所述请求数量、所述平均时长和所述所需GPU数量加权计算得到每个疾病分析模型的GPU资源占比，包括：
    根据公式 G i =( AX i + BY i + CZ i )/∑ i =1 n( X iY iZ i )计算疾病分析模型 i的GPU资源占比 G i ，其中，疾病分析模型 i在历史预设时长内的请求数量为 X i ，单次处理的平均时长为 Y i ，所需GPU数量为 Z i ； A、 B和 C为预设常数。
  14. 如权利要求8至11任一项所述的调度装置，其特征在于，所述分析所述医院数据得到所述医院数据对应的病种信息，包括：
    提取所述医院数据中存在于预设关键字库中的关键字；
    获取与所述关键字对应的病种信息，作为所述医院数据对应的病种信息
  15. 一种终端设备，包括存储器以及处理器，所述存储器中存储有可在所述处理器上运行的计算机可读指令，其特征在于，所述处理器执行所述计算机可读指令时，实现如下步骤：
    接收用户发送的疾病分析请求，所述疾病分析请求携带待分析的医院数据；
    分析所述医院数据得到所述医院数据对应的病种信息，根据所述病种信息从多个疾病分析模型中确定出目标疾病分析模型，所述目标疾病分析模型用于分析所述医院数据获得疾病分析结果；
    在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列；
    根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，所述GPU池中的GPU被配置成调用目标疾病分析模型处理所述疾病分析请求。
  16. 如权利要求15所述的终端设备，其特征在于，所述根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，包括：
    获取所述疾病分析请求队列中的队列头请求，根据所述队列头请求携带的模型名称确定所述队列头请求需要使用的目标疾病分析模型，并确定所述目标疾病分析模型所需GPU的目标数量；
    若GPU池中空闲GPU的数量大于或等于所述目标数量，则从所述空闲GPU中确定目标数量的目标GPU，将所述队列头请求分配至所述目标GPU；所述目标GPU被配置成初始化所述目标疾病分析模型句柄，处理所述疾病分析请求直至完成，在完成之后释放所述目标疾病分析模型句柄，并释放所述目标GPU至GPU池；
    若GPU池中空闲GPU的数量小于所述目标数量，则暂停分配所述队列头请求，直至所述GPU池中空闲GPU的数量大于或等于所述目标数量。
  17. 如权利要求15所述的终端设备，其特征在于，所述在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至疾病分析请求队列，包括：
    在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至与所述模型名称对应的疾病分析请求队列。
  18. 如权利要求17所述的终端设备，其特征在于，所述根据所述模型名称和GPU池的当前状态，将所述疾病分析请求队列中的疾病分析请求分配至GPU池中的GPU，包括：
    获取每个所述模型名称对应的GPU池的状态信息；其中，GPU池中的GPU被配置成已经完成目标疾病分析模型句柄的初始化；
    若模型名称对应的GPU池的状态信息为空闲，则将携带有所述模型名称的所述队列头请求分配至所述GPU池中的GPU，并将所述GPU池的状态信息标记为忙碌；若所述GPU池中的GPU处理完所述疾病分析请求，标记所述GPU池的状态信息为空闲；
    若模型名称对应的GPU池的状态信息为忙碌，则暂停分配携带有所述模型名称的所述队列头请求，直至所述GPU池的状态信息为空闲。
  19. 如权利要求17或18所述的终端设备，其特征在于，在所述疾病分析请求中携带上所述目标疾病分析模型的模型名称，并将所述疾病分析请求添加至与所述模型名称对应的疾病分析请求队列之前，还包括：
    针对每个疾病分析模型，获取历史预设时长内的请求数量、单次处理的平均时长、以及所需GPU数量；
    根据所述请求数量、所述平均时长和所述所需GPU数量加权计算得到每个疾病分析模型的GPU资源占比；
    根据所述GPU资源占比，为每个疾病分析模型分配对应的GPU池，将模型名称和GPU池进行关联存储。
  20. 一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，其特征在于，所述计算机可读指令被处理器执行时实现如权利要求1至7任一项所述的调度方法的步骤。
PCT/CN2019/103109 2019-04-11 2019-08-28 一种疾病分析模型的调度方法、装置及终端设备 WO2020206911A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910288569.5A CN110162398B (zh) 2019-04-11 2019-04-11 一种疾病分析模型的调度方法、装置及终端设备
CN201910288569.5 2019-04-11

Publications (1)

Publication Number Publication Date
WO2020206911A1 true WO2020206911A1 (zh) 2020-10-15

Family

ID=67639256

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/103109 WO2020206911A1 (zh) 2019-04-11 2019-08-28 一种疾病分析模型的调度方法、装置及终端设备

Country Status (2)

Country Link
CN (1) CN110162398B (zh)
WO (1) WO2020206911A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110162398B (zh) * 2019-04-11 2024-05-03 平安科技（深圳）有限公司 一种疾病分析模型的调度方法、装置及终端设备
CN111026552B (zh) * 2019-12-09 2023-03-03 腾讯科技（深圳）有限公司 资源的调度方法、装置、电子设备和计算机可读存储介质
CN111190712A (zh) * 2019-12-25 2020-05-22 北京推想科技有限公司 一种任务调度方法、装置、设备及介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1935089A (zh) * 2005-08-05 2007-03-28 西门子公司 用于自动检测医学图像数据中异常的装置
US20100186017A1 (en) * 2009-01-21 2010-07-22 Raghavendra Eeratta System and method for medical image processing
CN106919442A (zh) * 2015-12-24 2017-07-04 中国电信股份有限公司 多gpu调度装置和分布式计算系统以及多gpu调度方法
CN107767928A (zh) * 2017-09-15 2018-03-06 深圳市前海安测信息技术有限公司 基于人工智能的医学影像报告生成系统及方法
CN109582425A (zh) * 2018-12-04 2019-04-05 中山大学 一种基于云端与终端gpu融合的gpu服务重定向系统及方法
CN110162398A (zh) * 2019-04-11 2019-08-23 平安科技（深圳）有限公司 一种疾病分析模型的调度方法、装置及终端设备

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10517688B2 (en) * 2009-05-29 2019-12-31 Jack Wade Method for enhanced data analysis with specialized video enabled software tools for medical environments
CN102901951A (zh) * 2011-07-26 2013-01-30 张朝晖 基于gpu的雷达信号脉内特征实时分析实现方案
US9892482B2 (en) * 2012-12-19 2018-02-13 Intel Corporation Processing video content
US9575807B2 (en) * 2014-04-15 2017-02-21 Intel Corporation Processing accelerator with queue threads and methods therefor
US9965318B2 (en) * 2015-03-16 2018-05-08 Tata Consultancy Services Limited Concurrent principal component analysis computation
US10109030B1 (en) * 2016-12-27 2018-10-23 EMC IP Holding Company LLC Queue-based GPU virtualization and management system
CN108012156B (zh) * 2017-11-17 2020-09-25 深圳市华尊科技股份有限公司 一种视频处理方法及控制平台
CN108597600A (zh) * 2018-03-19 2018-09-28 武汉大学人民医院 单导心贴数据智能诊断云计算系统及其处理方法
CN108288502A (zh) * 2018-04-11 2018-07-17 平安科技（深圳）有限公司 疾病预测方法及装置、计算机装置及可读存储介质
CN108648829A (zh) * 2018-04-11 2018-10-12 平安科技（深圳）有限公司 疾病预测方法及装置、计算机装置及可读存储介质
CN109493972A (zh) * 2018-10-30 2019-03-19 平安医疗健康管理股份有限公司 基于预测模型的数据处理方法、装置、服务器及存储介质
CN109300052A (zh) * 2018-10-30 2019-02-01 平安医疗健康管理股份有限公司 基于线上问诊的保险推荐方法、设备、服务器及可读介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1935089A (zh) * 2005-08-05 2007-03-28 西门子公司 用于自动检测医学图像数据中异常的装置
US20100186017A1 (en) * 2009-01-21 2010-07-22 Raghavendra Eeratta System and method for medical image processing
CN106919442A (zh) * 2015-12-24 2017-07-04 中国电信股份有限公司 多gpu调度装置和分布式计算系统以及多gpu调度方法
CN107767928A (zh) * 2017-09-15 2018-03-06 深圳市前海安测信息技术有限公司 基于人工智能的医学影像报告生成系统及方法
CN109582425A (zh) * 2018-12-04 2019-04-05 中山大学 一种基于云端与终端gpu融合的gpu服务重定向系统及方法
CN110162398A (zh) * 2019-04-11 2019-08-23 平安科技（深圳）有限公司 一种疾病分析模型的调度方法、装置及终端设备

Also Published As

Publication number Publication date
CN110162398B (zh) 2024-05-03
CN110162398A (zh) 2019-08-23

Similar Documents

Publication Publication Date Title
CN110837410B (zh) 任务调度方法、装置、电子设备及计算机可读存储介质
WO2020206911A1 (zh) 一种疾病分析模型的调度方法、装置及终端设备
Kc et al. Scheduling hadoop jobs to meet deadlines
US10552213B2 (en) Thread pool and task queuing method and system
US20110154355A1 (en) Method and system for resource allocation for the electronic preprocessing of digital medical image data
US20240168812A1 (en) Managing computer resources for clinical applications
EP4123467A1 (en) Data transmission method and apparatus
CN111986194A (zh) 医学标注图像检测方法、装置、电子设备及存储介质
CN114613523A (zh) 线上医疗问诊的医生分配方法、装置、存储介质及设备
EP4361812A1 (en) Data processing method, system and related device
DE102017124078A1 (de) Ordinale modifikation der dienstgüte
CN113792920A (zh) 一种面向单诊室的医院就诊顺序优化方法及装置
Sahoo et al. Efficient data and CPU-intensive job scheduling algorithms for healthcare cloud
US20100186017A1 (en) System and method for medical image processing
CN115586961A (zh) 一种ai平台计算资源任务调度方法、装置及介质
CN113744845A (zh) 基于人工智能的医学影像处理方法、装置、设备及介质
US20170068554A1 (en) Hypervisor driven gradual balloon inflation
US11900601B2 (en) Loading deep learning network models for processing medical images
US9910893B2 (en) Failover and resume when using ordered sequences in a multi-instance database environment
WO2023029348A1 (zh) 基于人工智能的图像实例标注方法及相关设备
CN108091398B (zh) 患者分组方法及装置
CN114255478A (zh) 宠物分配方法、装置、存储介质及电子设备
WO2022066954A1 (en) Register compaction with early release
CN111933267B (zh) 医疗预警方法、装置、计算机设备及计算机可读存储介质
Haldorai et al. Biomedical informatics and computation in urban e-health

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19924321

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19924321

Country of ref document: EP

Kind code of ref document: A1