Agricultural intelligent model reasoning scheduling system and method

Abstract

The invention belongs to the technical field of artificial intelligence, and provides an agricultural intelligent model reasoning scheduling system and method. The system comprises an application access layer which comprises a plurality of agricultural service systems, and the agricultural service systems initiate model calling requests through predefined fixed reasoning endpoints; the reasoning scheduling center layer is connected with the application access layer and is used for receiving the model calling request and carrying out endpoint standardization processing on the model calling request to obtain a unified reasoning request; and the model operation layer is used for receiving the unified reasoning request sent by the reasoning scheduling center layer, generating a reasoning result and observation information according to the unified reasoning request, and feeding back the reasoning result and the observation information to the application access layer. According to the invention, high availability, easy treatment and traceable unified management of cross-platform and cross-region model services can be realized, and the development efficiency and operation stability of agricultural intelligent application are significantly improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to an agricultural intelligent model reasoning and scheduling system and method. Background Technology

[0002] In the field of smart agriculture, with the in-depth application of IoT, remote sensing, and edge computing technologies, various AI models are widely deployed in heterogeneous environments from the cloud to the edge to support intelligent operations such as pest and disease identification, crop yield estimation, and agricultural machinery scheduling. However, the current lack of a unified model service governance framework has led to a highly fragmented state of online inference services: different teams use multiple inference frameworks (such as PyTorch Serving, TensorFlow Serving, etc.), and the exposed application programming interface (API) endpoints (such as / v1 / models / ) are fragmented. The :predict and / predictions are incompatible, and model instances are scattered across private clouds, public clouds, and field edge nodes, making unified discovery and scheduling difficult.

[0003] In this approach, model inference scheduling relies on manual adaptation at each application end or simple forwarding through basic gateways. This not only creates a huge development and maintenance burden, but also makes model version iteration slow, cross-regional collaboration difficult, and lacks effective fault tolerance and observability mechanisms in complex and ever-changing agricultural network environments. It cannot meet the rigid requirements of high availability and security auditing for business, and seriously restricts the large-scale expansion of the agricultural intelligent system. Summary of the Invention

[0004] This application provides an agricultural intelligent model inference scheduling method, apparatus, equipment, and storage medium to solve the problems of inconsistent inference service interfaces, difficulty in scheduling cross-environment deployment, and insufficient stability and observability of inference services in the prior art.

[0005] This application provides an agricultural intelligent model inference and scheduling system, the system comprising: The application access layer includes multiple agricultural business systems, which initiate model call requests through predefined fixed inference endpoints; The inference scheduling hub layer connects to the application access layer and is used to receive model call requests and perform endpoint normalization processing on the model call requests to obtain unified inference requests. The model execution layer receives unified inference requests sent by the inference scheduling hub layer, generates inference results and observation information based on the unified inference requests, and feeds back the inference results and observation information to the application access layer.

[0006] In one embodiment, the inference scheduling hub layer includes: The deployment mapping module is used to maintain the mapping relationship between the registration information of model instances and their real-time running status, and to determine the instance location information of model call requests; The endpoint normalization module is used to convert heterogeneous interface paths in instance location information into unified endpoints that are consistent with predefined fixed inference endpoints according to preset conversion rules. The request shaping module is used to validate, convert, and standardize model call requests to obtain unified inference requests; The unified scheduling module is used to distribute unified inference requests according to an adaptive fault-tolerant strategy; The observation and governance module is used to collect system logs, performance metrics and event information, and generate dynamic configuration feedback information.

[0007] In one embodiment, the preset conversion rule includes: matching mode, conversion logic information, and weight information; Matching patterns are used to identify heterogeneous interface features of target model instances; The conversion logic information is used to convert the identified heterogeneous interfaces into unified endpoints; Weight information is used to determine the conversion priority.

[0008] In one embodiment, the request shaping module is used to perform the following processing flow: The model invocation request is abstracted into a basic request vector, which includes: model identification information, model version information, input data, and inference parameters; Create request context information, which includes: request identifier information, target endpoint, and timestamp; The base request vector is converted into a normalized vector using an integer function, wherein the conversion process includes at least one of the following: Input field whitelist validation and default value filling; Set the configurable upper limit for input volume; Format conversion.

[0009] In one embodiment, the unified scheduling module is used to execute the following processing flow: When the request times out or the server returns a preset error message, a retry operation is performed; Based on the real-time monitored failure rate and dynamic threshold, trigger a circuit breaker for the target model instance or switch to a standby instance; When the circuit breaker or degradation conditions are met, return the cached result or switch to a standby instance.

[0010] In one embodiment, the observation governance module includes: The log submodule is used to generate structured logs and de-identify sensitive data. The metrics submodule is used to output performance metrics, which include: request volume, success rate, latency distribution, retry and circuit breaker status metrics. The event submodule is used to automatically trigger alarm notifications and / or generate audit events and / or generate policy adjustment suggestions.

[0011] This application also provides an agricultural intelligent model inference scheduling method, applied to an agricultural intelligent model inference scheduling system, the method comprising: Receive model invocation requests, where the model invocation requests are initiated based on fixed endpoints; The target model instance is determined based on the model identifier and version in the model call request; This application provides an agricultural intelligent model inference mode that generates inference results and observation information based on a unified inference request and a target model instance.

[0012] This application also provides an agricultural intelligent model inference and scheduling device, comprising the following modules: The receiving module is used to receive model invocation requests, which are initiated based on a fixed endpoint. The determination module is used to determine the target model instance based on the model identifier and version in the model call request; The conversion module is used to convert model call requests into unified inference requests after endpoint normalization. The generation module is used to generate inference results and observation information based on the unified inference request and the target model instance.

[0013] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-described agricultural intelligent model inference and scheduling methods.

[0014] This application also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements any of the above-described agricultural intelligent model inference scheduling methods.

[0015] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the above-described agricultural intelligent model inference scheduling methods.

[0016] The agricultural intelligent model inference scheduling system and method provided in this application effectively solves the problems of interface fragmentation, scheduling instability, and operation and maintenance difficulties faced by agricultural AI models in diverse business systems and complex deployment environments through the core design of "one fixed endpoint + one scheduling hub". It unifies and standardizes various business requests and intelligently schedules them to different model instances in the backend. At the same time, it integrates adaptive fault tolerance, full-link observation and dynamic feedback optimization capabilities, thereby achieving high availability, easy governance and traceable unified management of cross-platform and cross-regional model services, significantly improving the development efficiency and operational stability of agricultural intelligent applications. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the structure of the agricultural intelligent model inference and scheduling system provided in this application.

[0019] Figure 2 This is a schematic diagram of the workflow of the agricultural intelligent model inference and scheduling system provided in this application.

[0020] Figure 3 This is a schematic diagram of the model registration information aggregation, deployment mapping and maintenance process provided in this application.

[0021] Figure 4 This is a schematic diagram of the endpoint standardization and fixed interface generation mechanism provided in this application.

[0022] Figure 5 This is a schematic diagram of the observation, configuration, and feedback closed-loop process provided by the invention.

[0023] Figure 6 This is a flowchart illustrating the agricultural intelligent model reasoning and scheduling method provided in this application.

[0024] Figure 7 This is a schematic diagram of the agricultural intelligent model reasoning and scheduling device provided in this application.

[0025] Figure 8 A schematic diagram of the physical structure of an electronic device is provided. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] Figure 1 This is a schematic diagram of the structure of the agricultural intelligent model inference and scheduling system provided in this application, as shown below. Figure 1 As shown, the system includes the following: application access layer 101, inference scheduling hub layer 102, and model execution layer 103.

[0028] Application access layer 101 includes multiple agricultural business systems, which initiate model call requests through predefined fixed inference endpoints.

[0029] The inference scheduling hub layer 102 is connected to the application access layer. It is used to receive model call requests and perform endpoint normalization processing on the model call requests to obtain unified inference requests. The model execution layer 103 is used to receive unified inference requests sent by the inference scheduling hub layer, generate inference results and observation information according to the unified inference requests, and feed back the inference results and observation information to the application access layer.

[0030] In the embodiments of this application, see Figure 2 , Figure 2 This is a schematic diagram of the workflow of the agricultural intelligent model inference scheduling system provided in this application. The application access layer includes business systems such as greenhouse management, pest and disease identification, agricultural machinery scheduling, and agricultural product traceability. The system calls the model through fixed inference endpoints, such as / predict, / predict_image, and / batch_predict.

[0031] Among them, the inference scheduling hub layer is responsible for model deployment mapping, endpoint normalization, request shaping, adaptive fault tolerance and end-to-end observation functions.

[0032] The model runtime layer includes model container instances deployed on Docker orchestration tools (Docker Compose), Kubernetes, or edge nodes, which accept unified inference requests from the scheduling hub.

[0033] In this embodiment, after the data stream enters from the application side, it goes through the stages of parsing, positioning, normalization, shaping, scheduling, and execution in sequence, and finally generates model results and complete observation information to be returned to the upper-layer system, so as to realize business traceability and monitoring.

[0034] Optionally, in some embodiments, the inference scheduling hub layer 102 includes: The deployment mapping module 1021 is used to maintain the mapping relationship between the registration information of model instances and their real-time running status, and to determine the instance location information of the model call request.

[0035] Endpoint normalization module 1022 is used to convert heterogeneous interface paths in instance location information into unified endpoints consistent with predefined fixed inference endpoints according to preset conversion rules. The request shaping module 1023 is used to perform validation, format conversion and standardization on the model call request in order to obtain a unified inference request; The unified scheduling module 1024 is used to distribute unified inference requests according to an adaptive fault-tolerant strategy; The observation and governance module 1025 is used to collect system logs, performance indicators and event information, and generate dynamic configuration feedback information.

[0036] In the embodiments of this application, see Figure 3 , Figure 3 This is a schematic diagram of the model registration information aggregation and deployment mapping maintenance process provided in this application. To ensure consistency in cross-environment scheduling, the system is designed with a deployment mapping service to maintain structured deployment data. This data includes the following fields: model_id, version, runtime_type, endpoint_hint, host_port, service_name, tenant_id, traffic_ratio, and last_heartbeat. The system ensures the real-time performance of the mapping data through a Least Recently Used (LRU) + Time To Live (TTL) caching mechanism combined with an event bus. When a model goes live, scales down, or a heartbeat times out, the event bus triggers a refresh; when the cache is nearing expiration, the service automatically queries the database, Compose API, or Kubernetes API Server for the latest model information and completes the access address. This mechanism enables the scheduling hub to accurately locate model instances in complex environments across clouds, campuses, and organizations, supporting highly reliable distribution and stable access to inference requests.

[0037] Optionally, in some embodiments, the preset conversion rules include: matching mode, conversion logic information, and weight information; Matching patterns are used to identify heterogeneous interface features of target model instances; The conversion logic information is used to convert the identified heterogeneous interfaces into unified endpoints; Weight information is used to determine the conversion priority.

[0038] In this embodiment, to address the issue of inconsistent model interface styles across different operating environments, the system maintains a set of rules that can be hot-updated. Each rule in this set includes a matching pattern, transformation logic information, and weight information. When a difference is detected in the original endpoints of a model instance, such as / predictions / {id} or / v1 / models / model: When using paths like `predict` or ` / infer`, the rule engine automatically performs matching and transformation based on endpoint hints, mapping them uniformly to a predefined, fixed inference endpoint, such as ` / predict` or ` / predict_image`. If no rule is matched, the system automatically falls back to the default endpoint format, appended with the host address (`host_port`). The endpoint transformation hit rate and results are recorded and reported to the observation and governance module to calculate rule hit rates and guide operations in adjusting weights. Through this mechanism, the system achieves automatic standardization and unified access to model interfaces, fundamentally resolving compatibility issues caused by fragmented model endpoints.

[0039] Optionally, in some embodiments, the request shaping module is used to perform the following processing flow: The model invocation request is abstracted into a basic request vector, which includes: model identification information, model version information, input data, and inference parameters; Create request context information, which includes: request identifier information, target endpoint, and timestamp; The base request vector is converted into a normalized vector using an integer function, wherein the conversion process includes at least one of the following: Input field whitelist validation and default value filling; Set the configurable upper limit for input volume; Format conversion.

[0040] In other words, in the embodiments of this application, see Figure 4 , Figure 4 This is a schematic diagram of the request shaping and input governance process provided in this application. After receiving the model call request, the model call request can be abstracted into a basic request vector containing model_id, version, inputs, and parameters as input. Then, the system uses a shaping function (e.g., f_schema) to convert the request into a standardized vector that the target model can directly recognize, including two parts: inputs′ and parameters′.

[0041] In this embodiment of the application, the conversion process includes the following core steps: performing whitelist validation and default value filling on the input fields; setting an upper limit on the input volume (e.g., |inputs′| ≤ M) to prevent abnormal data; and performing format conversion, such as converting Base64 images to tensor format and converting tabular data to JSON arrays.

[0042] In this embodiment of the application, the request shaping module can also generate request context information, which includes: request identification information (request number), target endpoint, and (timestamp) start time, etc.

[0043] In this embodiment, the processing flow of the request shaping module not only ensures the stability of model execution and the consistency of input, but also provides the necessary context information for subsequent log tracing and performance observation.

[0044] Optionally, in some embodiments, the unified scheduling module is used to perform the following processing flow: When the request times out or the server returns a preset error message, a retry operation is performed; Based on the real-time monitored failure rate and dynamic threshold, trigger a circuit breaker for the target model instance or switch to a standby instance; When the circuit breaker or degradation conditions are met, return the cached result or switch to a standby instance.

[0045] In other words, in this embodiment of the application, to address the complex and ever-changing characteristics of agricultural networks (including edge LANs, 4G mobile communication technology, 5G mobile communication technology, long-distance communication environments, etc.), the system introduces a unified fault-tolerant and adaptive scheduling mechanism at the scheduling layer. When a request times out or the server displays a preset error message (e.g., 5xx error), the system performs a retry according to the exponential backoff formula. Simultaneously, the system maintains a dynamic threshold θ(t) to determine whether to trigger a circuit breaker or switch to a backup instance.

[0046] In this embodiment, when the success rate of a single call is p=0.7, the composite success rate can be increased to approximately 97.3% after three retries. When the network remains unstable and the number of failures exceeds the threshold, the system will automatically downgrade to cached results or switch to a backup healthy instance to ensure the continuous execution of critical tasks (such as irrigation control, pest monitoring, and agricultural machinery scheduling). The scheduler's retry count, backoff baseline, circuit breaker threshold, and other parameters can all be dynamically issued and adjusted by the configuration center.

[0047] Optionally, in some embodiments, the observation and governance module includes: The log submodule is used to generate structured logs and de-identify sensitive data. The metrics submodule is used to output performance metrics, which include: request volume, success rate, latency distribution, retry and circuit breaker status metrics. The event submodule is used to automatically trigger alarm notifications and / or generate audit events and / or generate policy adjustment suggestions.

[0048] In the embodiments of this application, see Figure 5 , Figure 5 This invention provides a schematic diagram of the closed-loop process of observation, configuration, and feedback. The observation and governance center is responsible for full-link operation monitoring, metric collection, and feedback optimization, forming a complete governance closed loop of "Configuration—Execution—Observation—Feedback." The observation and governance module mainly includes the following three sub-modules: a log sub-module (Logs), used to record information such as model identifier, endpoint conversion, latency, and retry count based on RequestContext, and to anonymize sensitive data; a metric sub-module (Metrics), used to output key metrics such as total number of requests, number of successful requests, latency distribution, retry count, and circuit breaker status, which are then connected to the monitoring platform for visual analysis; and an event sub-module (Events), used to automatically trigger alarms, audits, or policy adjustments based on failure rate or circuit breaker status. The configuration center can push update instructions to the rule engine, fault tolerance strategy, and input schema in real time, enabling the system to perform policy adjustments and performance optimizations without interrupting service. Through the observation and governance module, the system achieves full-link observability and automated feedback of the model inference process, effectively improving system stability and manageability.

[0049] In this embodiment, a complete inference chain is constructed through five sub-modules of the inference scheduling hub layer 102, encompassing model registration, unified interface, request governance, fault-tolerant scheduling, and observation feedback. This enables unified access and high-availability operation of agricultural intelligent models across platforms, organizations, and regions. With a "fixed endpoint inference scheduling hub" at its core, this system breaks down information silos between model deployment, invocation, monitoring, and auditing, resulting in scalable, governable, and traceable agricultural model services.

[0050] In this application embodiment, at the application level, this application can be widely used in scenarios such as smart greenhouses, digital farms, agricultural machinery collaboration, pest and disease identification, and agricultural product quality traceability. Through unified endpoint standards and dynamic mapping mechanisms, model developers only need to follow fixed interface specifications to quickly connect to existing agricultural information platforms; the scheduling end, relying on fault tolerance and observation mechanisms, ensures stable inference and safe operation under complex network conditions. Therefore, various stakeholders in agricultural production can achieve model collaboration and intelligent decision-making at a lower cost and with higher reliability.

[0051] The agricultural intelligent model inference and scheduling system provided in this application effectively solves the problems of interface fragmentation, scheduling instability, and operational difficulties faced by agricultural AI models in diverse business systems and complex deployment environments through a core design of "one fixed endpoint + one scheduling hub". It unifies and standardizes various business requests and intelligently schedules them to different model instances in the backend. At the same time, it integrates adaptive fault tolerance, end-to-end observation, and dynamic feedback optimization capabilities, thereby achieving high availability, easy governance, and traceable unified management of cross-platform and cross-regional model services, significantly improving the development efficiency and operational stability of agricultural intelligent applications.

[0052] Figure 6 This is a flowchart illustrating the agricultural intelligent model inference and scheduling method provided in this application, as shown below. Figure 6 As shown, the method includes the following: Step 601: Receive the model invocation request, wherein the model invocation request is initiated based on a fixed endpoint.

[0053] In this embodiment, agricultural business systems such as greenhouse management and pest and disease identification in the application access layer strictly follow predefined rules and initiate model call requests through fixed inference endpoints such as / predict and / predict_image.

[0054] Step 602: Determine the target model instance based on the model identifier and version in the model call request.

[0055] In this embodiment of the application, after the application access layer sends the model call request to the inference scheduling hub layer, it can extract key information from the request, mainly model_id (model identifier) ​​and version (version).

[0056] In this embodiment, the inference scheduling hub queries its maintained real-time mapping table (containing fields such as model_id, version, runtime_type, host_port, service_name, endpoint_hint, and traffic_ratio). This mapping table ensures data real-time performance through an LRU+TTL caching mechanism and an event bus, and can dynamically reflect the online, offline, scaling up, and down status of model instances on Docker, Kubernetes, or edge nodes.

[0057] In this embodiment of the application, the inference scheduling hub can also accurately locate the currently available and best target model instance based on the model identifier, version and possible traffic ratio strategy, and obtain its access address (host_port) and original interface hint information (endpoint_hint).

[0058] Step 603: Convert the model call request into a unified inference request through endpoint normalization.

[0059] In this embodiment, the inference scheduling hub can also query the set of rules (including matching pattern, transformation logic, and weight) that can be hot-updated based on the endpoint_hint obtained in the previous step (such as / v1 / models / m:predict). The rule engine will intelligently convert the identified heterogeneous interface paths into a unified endpoint.

[0060] Then, the original request can be abstracted into a basic request vector (containing model_id, version, inputs, parameters). At the same time, request context information (containing unique request identifier, target endpoint, timestamp, etc.) is created for end-to-end tracing. The basic vector is then transformed using an integer function to output a standardized vector, namely the "unified inference request".

[0061] Step 604: Generate inference results and observation information based on the unified inference request and the target model instance.

[0062] In this embodiment, after generating a unified inference request, the unified scheduling module carries the standardized unified inference request and distributes it to the located target model instance. During this process, an adaptive fault tolerance strategy is executed: if the request times out or returns a 5xx error, it will be retried according to the exponential backoff strategy; the system monitors the failure rate in real time, and if it exceeds the dynamic threshold θ(t), it will trigger a circuit breaker or automatically switch to a standby instance; in extreme cases, a degradation strategy (such as returning cached historical results) can be executed. Finally, the request is reliably delivered to the corresponding model container instance in the model runtime layer, and the instance performs the calculation to generate the original inference result.

[0063] In this embodiment of the application, the observation and governance module is present throughout the entire process. Starting from step 603, it uses request context information to record endpoint conversion details, shaping process, scheduling path, time consumption, number of retries, etc., to form a structured log. The indicator submodule can collect performance indicators such as request volume, success rate, latency distribution, and circuit breaker status in real time. The event submodule can automatically trigger alarms or generate audit events based on abnormal indicators (such as a persistently high failure rate).

[0064] In this embodiment, the inference results generated by the model runtime layer, along with the observation information (such as status code, final instance used, total time, etc.) summarized by the observation governance module, are returned to the initiator of the application access layer. This enables business traceability and monitoring.

[0065] In this embodiment, calls are initiated through fixed endpoints, unifying the entry point from the source and eliminating direct coupling between the business system and the model. Next, instances are intelligently located based on real-time mapping tables, ensuring accurate identification of the target model in complex environments such as hybrid cloud and edge nodes. Then, through dual standardization processing of rule engines and request shaping, heterogeneous interfaces and data formats are transformed into unified requests recognizable by the model, breaking down compatibility barriers. Finally, under fault-tolerant scheduling, execution and synchronous generation of end-to-end observation information not only ensure high service availability through mechanisms such as retries, circuit breakers, and degradation, but also achieve monitorable, auditable, and optimizable call processes. These interconnected steps collectively construct a flexible, robust, and easily governable model service middleware layer, significantly reducing the complexity of system integration and operation.

[0066] The agricultural intelligent model inference scheduling device provided in this application is described below. The agricultural intelligent model inference scheduling device described below can be referred to in correspondence with the agricultural intelligent model inference scheduling method described above.

[0067] Figure 7 This is a schematic diagram of the agricultural intelligent model inference and scheduling device provided in this application, as shown below. Figure 7 As shown, the agricultural intelligent model inference scheduling device 70 includes the following: The receiving module 701 is used to receive model invocation requests, wherein the model invocation requests are initiated based on a fixed endpoint; The determination module 702 is used to determine the target model instance based on the model identifier and version in the model call request; The conversion module 703 is used to convert model call requests into unified inference requests after endpoint normalization processing; The generation module 704 is used to generate inference results and observation information based on the unified inference request and the target model instance.

[0068] The agricultural intelligent model inference scheduling device provided in this application initiates calls through fixed endpoints, unifying the entry point from the source and eliminating direct coupling between business systems and models. Next, it intelligently locates instances based on real-time mapping tables, ensuring accurate identification of the target model in complex environments such as hybrid cloud and edge nodes. Then, through dual standardization processing of rule engines and request shaping, heterogeneous interfaces and data formats are transformed into unified requests recognizable by the model, breaking down compatibility barriers. Finally, under fault-tolerant scheduling guarantees, it executes and synchronously generates end-to-end observation information. This not only ensures high service availability through mechanisms such as retries, circuit breakers, and degradation, but also achieves monitorable, auditable, and optimizable call processes. These interconnected steps collectively construct a flexible, robust, and easily governable model service middleware layer, significantly reducing the complexity of system integration and operation.

[0069] Figure 8 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 8 As shown, the electronic device may include a processor 810, a communications interface 820, a memory 830, and a communication bus 840. The processor 810, communications interface 820, and memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions from the memory 830 to execute the agricultural intelligent model inference scheduling method.

[0070] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0071] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the agricultural intelligent model inference scheduling method provided above.

[0072] In another aspect, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the above-described agricultural intelligent model inference scheduling method.

[0073] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0074] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0075] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An agricultural intelligent model reasoning and scheduling system, characterized in that, The system includes: The application access layer includes multiple agricultural business systems, which initiate model invocation requests through predefined fixed inference endpoints; The inference scheduling hub layer, connected to the application access layer, is used to receive the model invocation request and perform endpoint normalization processing on the model invocation request to obtain a unified inference request. The model execution layer is used to receive the unified inference request sent by the inference scheduling hub layer, generate inference results and observation information according to the unified inference request, and feed back the inference results and observation information to the application access layer.

2. The system according to claim 1, characterized in that, The inference scheduling central layer includes: The deployment mapping module is used to maintain the mapping relationship between the registration information of model instances and their real-time running status, and to determine the instance location information of the model call request; The endpoint normalization module is used to convert heterogeneous interface paths in the instance location information into unified endpoints consistent with the predefined fixed inference endpoints according to preset conversion rules. The request shaping module is used to verify, convert, and standardize the model call request to obtain the unified inference request. A unified scheduling module is used to distribute the unified inference request according to an adaptive fault-tolerant strategy; The observation and governance module is used to collect system logs, performance metrics and event information, and generate dynamic configuration feedback information.

3. The system according to claim 2, characterized in that, The preset conversion rules include: matching mode, conversion logic information, and weight information; The matching pattern is used to identify the heterogeneous interface features of the target model instance; The conversion logic information is used to convert the identified heterogeneous interfaces into the unified endpoint; The weight information is used to determine the conversion priority.

4. The system according to claim 2, characterized in that, The request shaping module is used to perform the following processing flow: The model call request is abstracted into a basic request vector, which includes: model identification information, model version information, input data, and inference parameters; Create request context information, which includes: request identifier information, target endpoint, and timestamp; The base request vector is converted into a normalized vector using an integer function, wherein the conversion process includes at least one of the following: Input field whitelist validation and default value filling; Set the configurable upper limit for input volume; Format conversion.

5. The system according to claim 2, characterized in that, The unified scheduling module is used to execute the following processing flow: When the request times out or the server returns a preset error message, a retry operation is performed; Based on the real-time monitored failure rate and dynamic threshold, trigger a circuit breaker for the target model instance or switch to a standby instance; When the circuit breaker or degradation conditions are met, return the cached result or switch to the standby instance.

6. The system according to claim 2, characterized in that, The observation and governance module includes: The log submodule is used to generate structured logs and de-identify sensitive data. The metrics submodule is used to output performance metrics, which include: request volume, success rate, latency distribution, retry and circuit breaker status metrics. The event submodule is used to automatically trigger alarm notifications and / or generate audit events and / or generate policy adjustment suggestions.

7. A reasoning and scheduling method for an agricultural intelligent model, characterized in that, The method, applied to the system as described in any one of claims 1-6, comprises: Receive a model invocation request, wherein the model invocation request is initiated based on a fixed endpoint; The target model instance is determined based on the model identifier and version in the model call request; The model call request is converted into a unified inference request through endpoint normalization. Based on the unified inference request and the target model instance, inference results and observation information are generated.

8. An agricultural intelligent model reasoning and scheduling device, characterized in that, include: A receiving module is used to receive model invocation requests, wherein the model invocation requests are initiated based on a fixed endpoint; The determination module is used to determine the target model instance based on the model identifier and version in the model call request; The conversion module is used to convert the model call request into a unified inference request; The generation module is used to generate inference results and observation information based on the unified inference request and the target model instance.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the agricultural intelligent model inference scheduling method as described in claim 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the agricultural intelligent model reasoning and scheduling method as described in claim 7.

Images