LLM-DoS attack protection method based on multi-level defense strategy and related device

Abstract

The invention discloses an LLM-DoS attack protection method based on a multi-level defense strategy and a related device, and belongs to the field of artificial intelligence security. According to the method, denial of service attacks aiming at a large language model are effectively prevented through a three-layer defense strategy: firstly, dynamic frequency control is carried out on an API request, a three-stage rate limiting system is established, a load-aware dynamic adjustment algorithm is introduced, and when the system load is too high, the quota is automatically adjusted; secondly, constructing an input perception classifier by adopting a lightweight Transform model, breaking through context limitation in combination with a random fragment compression and length penalty strategy, and realizing hierarchical interception of attack requests through a harmfulness scoring function; and finally, a request hash mapping and streaming response multiplexing technology is implemented at a server side, and real-time detection and response multiplexing are performed on repeated high-concurrency attack requests, so that consumption of computing resources is reduced. According to the method, the security and availability of the large language model service can be effectively improved, and the influence of DoS attacks on the system is reduced.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence security technology, and relates to an LLM-DoS attack protection method and related devices based on a multi-layered defense strategy. Background Technology

[0002] With the widespread application of Large Language Models (LLMs) across various fields, denial-of-service (DoS) attacks targeting these computationally intensive services are also on the rise. LLM-DoS attacks are a new type of resource-consuming attack that sends specifically designed input requests to the LLM service, causing excessive consumption of the model's computational resources, thus rendering the service unavailable or severely delayed. Unlike traditional network DoS attacks, LLM-DoS attacks primarily target computational resources rather than network bandwidth, making traditional network security measures less effective against such attacks.

[0003] Currently, the industry has developed several defense technologies against cyberattacks. For example, CN119583198A discloses a cyberattack risk mapping and assessment method. This method extracts multi-dimensional attack feature vectors by collecting network traffic data packets, uses deep neural networks for feature learning, constructs a standard attack feature model, and combines it with asset vulnerability assessment for risk mapping. CN119865343A proposes an AI-enhanced distributed denial-of-service attack defense method. This method uses a deep learning feature extraction model to obtain behavioral feature vectors, calculates attack probability scores through a multi-layer attention mechanism neural network model, and dynamically optimizes the defense strategy based on defense effect feedback using a reinforcement learning algorithm.

[0004] In the field of DDoS attack detection and defense, CN116800468A introduces a method that constructs an attack detection classifier by extracting DDoS attack features from flow table information and restricts attack traffic based on access control lists and the forwarding mechanism of the OpenFlow protocol. CN120378182A discloses an intrusion detection method for industrial control systems based on Mamba-ReLU. This method enhances the sensitivity to persistent attacks by constructing an enhanced classification model based on stacked ensembles and dynamically adjusting the output weights of probabilities using a ReLU linear attention mechanism and the Mamba model. Furthermore, CN120165968A proposes a network information security protection method based on dynamic defense using artificial intelligence. This method constructs a multi-layered security policy library based on network data features and uses a policy combination optimization algorithm to generate a weight matrix reflecting policy priority and dependencies, enabling the collaborative deployment of multi-dimensional security policies.

[0005] However, existing technologies have significant shortcomings in dealing with LLM-DoS attacks: First, traditional network security protection systems targeting network bandwidth and protocol stack levels are completely ineffective against computationally resource-intensive LLM-DoS attacks. This is because LLM-DoS attacks primarily consume GPU computing resources through legitimate API calls, rather than through traditional network traffic congestion.

[0006] Secondly, existing protection measures are mainly limited to basic API call frequency limits. This coarse-grained defense method cannot effectively distinguish between normal high-frequency requests and malicious attack requests, which can easily cause false alarms to normal business operations. At the same time, static thresholds are difficult to adapt to the load characteristics of different business scenarios, and are prone to misjudgment when faced with sudden traffic surges, affecting service availability.

[0007] Third, existing solutions lack the ability to understand the semantics of request content, making them unable to effectively identify disguised malicious requests. In particular, attack requests that trigger long-term model computation through carefully crafted prompts can often bypass simple feature detection.

[0008] Finally, existing solutions have significant shortcomings in attack detection accuracy, resource consumption assessment, and dynamic protection strategies. They cannot provide customized protection strategies for the specific computing patterns of LLM services, and they lack effective mechanisms for identifying and handling duplicate requests, resulting in limited protection effectiveness when facing high-concurrency attacks with similar requests.

[0009] Therefore, there is an urgent need for a technical solution that can target the characteristics of LLM-DoS attacks and combine multi-layered defense strategies to achieve comprehensive protection of LLM services. Summary of the Invention

[0010] The purpose of this application is to address the problems in the existing technology by providing an LLM-DoS attack protection method and related apparatus based on a multi-layered defense strategy. This application includes a three-tiered protection system of dynamic frequency control, intelligent traffic scrubbing, and cache optimization. Through a dual rate-limiting mechanism, a Transformer-based request classifier, and a dedicated LLM caching system, it achieves accurate identification of malicious requests and effective control of resource consumption. By deploying this solution, LLM-DoS attacks can be reduced to ordinary network requests, significantly reducing the resource consumption of service providers while ensuring normal service availability. This solves the technical problems of insufficient detection accuracy and delayed response in existing protection measures.

[0011] To achieve the above objectives, this application adopts the following technical solution: Firstly, this application provides an LLM-DoS attack protection method based on a multi-layered defense strategy, comprising the following steps: Limit the frequency of API requests to the LLM service and the number of output tokens, and dynamically adjust the limit thresholds based on the real-time system load; An input perception classifier is built based on a lightweight Transformer model, and graded interception is performed based on dynamic hazard scoring. The LLM server performs real-time detection and response reuse for repeated high-concurrency DoS attack requests.

[0012] Secondly, this application provides an LLM-DoS attack protection system based on a multi-layered defense strategy, comprising: The dynamic frequency control module is used to limit the request access frequency and the number of output tokens for API requests of the LLM service, and dynamically adjust the limit thresholds according to the real-time system load. An intelligent traffic cleaning module is used to build an input perception classifier based on a lightweight Transformer model. A shared cache defense module is used to perform real-time detection and response reuse for repeated high-concurrency DoS attack requests on the LLM server.

[0013] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0014] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described above.

[0015] Fifthly, this application provides a computer program product, the computer program product including computer instructions, wherein a processor of a computer device reads the computer instructions, and the processor of the computer device executes the computer instructions to implement the steps of the method described above.

[0016] Compared with the prior art, this application has the following beneficial effects: This application employs a three-tiered protection system—dynamic frequency control, intelligent traffic scrubbing, and cache optimization—to achieve end-to-end protection from request entry point to computational resource consumption, effectively addressing the diverse characteristics of LLM-DoS attacks. While ensuring a normal user experience, this application significantly improves the efficiency of intercepting malicious requests and reduces GPU resource waste. By adopting random fragment compression and length penalty strategies, this application overcomes the performance bottleneck of traditional Transformer models in long text classification, significantly improving the accuracy of identifying covert DoS attacks (such as extremely long malicious requests). Finally, through shared caching and response reuse technologies, this application drastically reduces the GPU computational load of repeated attack requests, while forcing attackers to increase their attack costs, achieving an asymmetric advantage in attack and defense costs. The lightweight Transformer classifier and real-time caching response mechanism ensure that the additional latency introduced by the protection system is controlled within seconds, guaranteeing the high availability of LLM services. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of the method described in this application.

[0019] Figure 2 This is a schematic diagram of the system in this application.

[0020] Figure 3 This is an overall flowchart of an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments 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, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0022] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0023] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0024] In the description of the embodiments of this application, it should be noted that if terms such as "upper," "lower," "horizontal," or "inner" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of the invention is in use, they are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on this application. In addition, terms such as "first" and "second" are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] Furthermore, the use of the term "horizontal" does not imply that the component must be absolutely horizontal, but rather that it can be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal than "vertical," and does not mean that the structure must be completely horizontal, but can be slightly tilted.

[0026] In the description of the embodiments of this application, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0027] The present application will now be described in further detail with reference to the accompanying drawings: See Figure 1 This application discloses an LLM-DoS attack protection method based on a multi-layered defense strategy, including the following steps: S1 limits the frequency of API requests to the LLM service and the number of output tokens, and dynamically adjusts the limit thresholds based on real-time system load; specifically, it includes the following steps: S1-1 establishes a three-tier rate limiting system, using a baseline threshold at the APIkey level. In practical applications, the three-tier rate limiting system is first established, with the baseline threshold used at the APIkey level. Specifically, at the user level, the maximum number of requests per minute (RPM) is set to 60; at the organization level, the maximum number of requests per minute is set to 300; and at the APIkey level, the maximum number of requests per minute and the maximum token processing volume per minute (TPM) are set to 120 and 12,000 tokens, respectively.

[0028] S1-2 implements a tiered circuit breaker mechanism. When a limit is triggered at any level, the connection at that level is immediately broken, and a cross-level interlocking response is initiated. In practical applications, this tiered circuit breaker mechanism is implemented so that when a limit is triggered at any level, the connection at that level is immediately broken, and a cross-level interlocking response is initiated. For example, when an API key triggers a TPM limit, not only is the API key temporarily disabled for 10 minutes, but the request quota of the user to whom the API key belongs is automatically reduced by 50% for 5 minutes to prevent attackers from quickly switching keys to continue the attack.

[0029] S1-3 introduces a load-aware dynamic adjustment algorithm. When GPU utilization consistently exceeds 80%, the TPM quotas at each level are automatically reduced exponentially. In practical applications, this algorithm further reduces TPM quotas at each level exponentially when GPU utilization consistently exceeds 80%. Specifically: if GPU utilization remains between 80% and 85% for 2 minutes, the TPM quota at each level is reduced to 80% of its original value; if GPU utilization remains between 85% and 90% for 1 minute, the TPM quota at each level is reduced to 60% of its original value; if GPU utilization exceeds 90% for 30 seconds, the TPM quota at each level is reduced to 40% of its original value. After the system load returns to normal, the quotas are restored linearly, increasing by 20% every 5 minutes until the original quotas are restored.

[0030] S1-4 establishes a whitelist credit system to reserve emergency quotas for historically low-risk users. In practical applications, a whitelist credit system is established to reserve emergency quotas for historically low-risk users. Specifically, the system records each user's usage behavior over the past 30 days. For users who have never triggered restrictions and whose usage patterns are stable, 50% of their basic quota is retained even under high system load to ensure the continuity of critical business operations.

[0031] S2 builds an input perception classifier based on a lightweight Transformer model and performs hierarchical interception based on dynamic hazard scoring. In practical applications, random fragment compression and length penalty strategies are used to overcome contextual limitations, and combined with dynamic hazard scoring thresholds, hierarchical interception of LLM-DoS attacks is achieved.

[0032] In this embodiment, hierarchical interception includes one or more combinations of direct rejection and manual verification.

[0033] It should be noted that the input perception classifier built based on the lightweight Transformer model, and the hierarchical interception based on dynamic hazard scoring, are implemented using the following steps: S2-1 builds a classifier based on a pre-trained lightweight Transformer model and uses a random segment compression method to process long text inputs. In practical applications, a classifier is built based on a pre-trained lightweight Transformer model, and a random segment compression method is used to process long text inputs. Specifically, the DistilBERT model is used as the basic architecture, with 66M parameters, only 40% of the full BERT model, resulting in a 2.5x speedup. For long text inputs exceeding 512 tokens, a random segment compression strategy is used, retaining the first 256 tokens and the last 128 tokens, and randomly sampling 128 tokens from the middle to form a new 512-token input sequence, ensuring no key information is lost while improving processing efficiency.

[0034] S2-3 introduces a length penalty factor to construct a harm scoring function. In practical applications, a length penalty factor is introduced to construct a harm scoring function. The scoring function is Score = Base_Score × (1 + Length_Factor), where Base_Score is the attack probability score of the original model output (between 0 and 1), and Length_Factor is the length penalty factor, calculated as min(input_length / 1000, 0.5). That is, for every 1000 tokens increase in input length, the harm score increases by a maximum of 50%, reflecting the high-risk characteristics of long text DoS attacks.

[0035] S2-4 implements a three-tiered blocking strategy, including direct access, manual verification, and direct rejection. In practical application, the three-tiered blocking strategy is implemented as follows: When the hazard score is <0.3, the request is directly allowed; when the hazard score is between 0.3 and 0.7, the user is required to complete manual verification such as CAPTCHA before continuing; when the hazard score is >0.7, the request is directly rejected and a risk log is recorded.

[0036] S2-5 employs a dynamic threshold adjustment mechanism, adjusting the hazard scoring threshold based on system load. In practical applications, this mechanism adjusts the hazard scoring threshold according to system load. When the system load is below 50%, the allow threshold is increased to 0.4, and the rejection threshold is increased to 0.8, increasing system tolerance. When the system load exceeds 80%, the allow threshold is decreased to 0.2, and the rejection threshold is decreased to 0.6, increasing defense sensitivity.

[0037] S3 performs real-time detection and response reuse for repeated high-concurrency DoS attack requests on the LLM server. Specifically, it includes the following steps: S3-1 establishes a request hash mapping mechanism to generate a unique identifier for each input request. In practical applications, this mechanism is implemented as follows: the input text is normalized by removing extra spaces and special characters and converting it to lowercase; the hash value of the processed text is calculated using the SHA-256 algorithm as the unique identifier for the request; and a hash table is established to store the mapping relationship between recent requests and their corresponding responses.

[0038] S3-2 implements streaming response reuse technology, performing only a single GPU computation for the same request. In practical applications, when a duplicate request is detected, the system no longer re-invokes GPU resources for inference computation. Instead, it retrieves the previous response result from the cache and returns it to the user in a streaming manner, simulating the normal inference process. This approach ensures a consistent user experience while significantly reducing system resource consumption.

[0039] The S3-3 employs an LRU (Least Recently Used) strategy to manage cache space and sets short-term cache expiration times. In practical applications, the LRU strategy is used to manage cache space, with short-term cache expiration times. The system allocates a fixed amount of memory space to the cache, with a default of 8GB. When cache space is insufficient, the least recently accessed cache items are evicted first. The default expiration time for each cache item is 30 minutes, after which it automatically expires. For detected high-frequency DoS attack requests, the cache expiration time is extended to 2 hours to enhance defense durability.

[0040] By employing the three-tiered defense strategy described above in synergy, this method effectively defends against various LLM-DoS attacks, ensuring the stable operation of the large language model service and the rational allocation of resources. During peak system load periods, this method can reduce the resource consumption for processing DoS attack requests by more than 90%, ensuring that the response time for normal user requests is not significantly affected.

[0041] like Figure 2 As shown in the figure, this application discloses an LLM-DoS attack protection system based on a multi-layered defense strategy. This system effectively defends against denial-of-service attacks targeting large language models through a multi-layered defense mechanism. The system comprises three core components: a dynamic frequency control module, an intelligent traffic scrubbing module, and a shared cache defense module.

[0042] The dynamic frequency control module is responsible for limiting the request frequency and output token quantity of API requests to the LLM service, and dynamically adjusting the limit thresholds based on real-time system load. This system employs an adaptive threshold adjustment algorithm, monitoring system metrics such as CPU utilization, memory usage, and request queue length to calculate the system load status in real time. When the system load exceeds a preset security threshold, the dynamic frequency control module automatically reduces the API request frequency limit for individual users and decreases the maximum number of output tokens allowed per request to prevent system resource exhaustion. The system also integrates a user reputation scoring mechanism, granting higher access quotas to users with good historical behavior and imposing stricter restrictions on suspicious users. The dynamic frequency control module uses a tiered rate limiting strategy, setting differentiated restriction policies for different API endpoints, with a focus on protecting computationally intensive inference interfaces.

[0043] The intelligent traffic scrubbing module uses a lightweight Transformer model to build an input-aware classifier for identifying and filtering malicious requests. The system employs a two-stage filtering architecture: the first stage uses a rule engine to quickly filter obvious abnormal requests, such as excessively long inputs or repeated special characters; the second stage uses the lightweight Transformer model to perform semantic analysis on the request content, identifying complex prompts designed to trigger long-term model computation. The intelligent traffic scrubbing module has self-learning capabilities, continuously updating its identification rules and model parameters by analyzing request patterns marked as DoS attacks. The system integrates a context-aware analysis engine, capable of detecting distributed attack patterns across multiple requests, effectively preventing complex coordinated attacks. The intelligent traffic scrubbing module uses interpretable AI technology, providing clear criteria for each blocked request, facilitating security team review and system optimization.

[0044] The shared cache defense module performs real-time detection and response reuse for repeated high-concurrency DoS attack requests on the LLM server. The system implements a multi-level caching architecture, including request feature caching and response result caching. The request feature caching quickly identifies similar or duplicate requests by calculating the semantic hash value of the request content; the response result caching stores the output results of processed requests, and can directly return cached results for identical or highly similar requests without re-invoking LLM computing resources. The shared cache defense module adopts a distributed cache cluster design, supporting horizontal scaling to cope with large-scale attack scenarios. The system also implements an intelligent cache eviction policy, prioritizing the retention of frequently accessed content and request results that consume significant computing resources. By monitoring request patterns in real time, the shared cache defense module can automatically identify sudden surges in requests within a short period and trigger defense mechanisms, effectively responding to sudden DoS attacks.

[0045] In a preferred embodiment, the dynamic frequency control module also integrates geolocation analysis functionality, enabling stricter frequency control of requests from abnormal regions based on the geographical distribution characteristics of the request sources. The system maintains a global request heatmap, monitors changes in request volume in various regions in real time, and automatically increases the request verification strength and rate limiting threshold for a region when the request volume in a certain region increases abnormally within a short period of time.

[0046] In another preferred embodiment, the intelligent traffic scrubbing module employs a hybrid neural network architecture, combining CNN and Transformer technologies to reduce model inference latency while maintaining high accuracy in attack detection. This model has been specifically trained for various LLM-DoS attack samples and can identify multiple attack patterns, including recursive hints, resource exhaustion hints, and escape attacks.

[0047] In another preferred embodiment, the shared cache defense module implements request intent clustering technology, which can classify and process requests that are semantically similar but have different expressions, further improving the cache hit rate. The system extracts the core intent vector for each request and maps similar requests to the same cache entry through vector similarity calculation, effectively countering attackers' strategies of bypassing cache detection by slightly modifying the request content.

[0048] The protection system's three core components work together to form a complete multi-layered defense system. The dynamic frequency control module acts as the first line of defense, limiting request traffic; the intelligent traffic scrubbing module acts as the second line of defense, filtering malicious content; and the shared cache defense module acts as the third line of defense, optimizing resource utilization. These three layers of defense complement each other. Even if an attacker breaches one layer, they will still face protection measures at the other layers, significantly increasing the cost of attacks and effectively ensuring the stable operation of the LLM service and the rational allocation of resources.

[0049] Example: See Figure 3 , Figure 3 This is an overall flowchart of a multi-layered defense strategy for LLM-DoS attack protection according to an embodiment of this application, showing the basic framework for defending against LLM-DoS attacks.

[0050] Step 1: The large model service is provided via a RESTful API, and authorization management is conducted through a three-tier structure of "organization-individual user-APIkey". Rate limiting is a common practice for defending against DoS attacks. Based on the special characteristics of LLM-DoS, request rate is protected under a three-tier architecture at the APIkey level, user level, and organization level. Two metrics are designed based on request frequency and token output frequency: requests per minute (PRM) and requests per minute (TPM).

[0051] Tiered circuit breaker protection: PRM and TPM thresholds are set in progressively increasing increments. The APIkey level uses a baseline threshold (e.g., 100 PRM / 10k TPM), user level thresholds are increased by 5 times, and organization level thresholds are increased by 20 times, forming a pyramid-shaped protection structure. When any level triggers its limit, the connection at that level is immediately circuit-broken, and a cross-level interlocking response is initiated: if the organization level exceeds its limit, the quota for its users / APIkeys is automatically reduced to 30% of the original value, thus shrinking the attack surface.

[0052] Intelligent quota dynamic adjustment: Introducing a load-aware algorithm, when GPU utilization consistently exceeds 80%, the TPM quotas at all levels are automatically reduced exponentially (e.g., decreasing by 15% every 5 minutes). A whitelist credit system is established to reserve "emergency quotas" (20% of the basic quota) for historically low-risk users, ensuring the continuity of critical business operations.

[0053] Step Two: Train a fast-response input-aware classifier. Given the automated nature of LLM-DoS attacks, the server does not immediately consume GPU resources upon receiving an LLM request. Instead, it first uses a fast-response input-aware classifier to judge the request, marking it as suspicious and requiring secondary confirmation from the user.

[0054] Training a classifier presents two key challenges: fast response and detection of long text inputs. To achieve fast response, pre-trained Transformer models with fewer parameters (such as BERT or RoBERTa, with 110M parameters) are used for judgment. Compared to large-scale language models with hundreds of billions of parameters, BERT or RoBERTa consumes fewer resources, has a faster response time, and performs better in classification tasks. However, using BERT or RoBERTa for input-aware classification encounters the problem of limited context length; that is, the context length that an LLM can handle is greater than the detector's context length (RoBERTa uses 512 tokens). This problem is overcome by adding a text length penalty term and randomly compressing the classifier input.

[0055] Data collection and labeling. A target range is set up to implement LLM-DoS attacks (e.g., mainstream algorithms like Crabs and Engorgio), constructing the dataset. Normal input can also reach the upper limit of the output window, potentially causing LLM-DoS attacks. Intercepting these requests is not ideal; therefore, only data with obvious characteristics is labeled, such as "meaningless repetition," "long context input," and "high-cost requests," so that the classifier learns the characteristics of high-risk and obvious LLM-DoS attacks.

[0056] The model learns a classification task based on a pre-trained Transformer model (such as BERT or RoBERTa), with classification labels of "safe" and "unsafe". Input splitting: The input text is split into multiple segments or blocks (each block size does not exceed the maximum token limit, typically 512 tokens). These segments can be divided into sentences, paragraphs, or other logical units. Random segment selection: A subset is randomly selected from all the split segments. The number of subsets can be preset. This method ensures the diversity of information selected. Random concatenation: The selected segments are concatenated. The concatenation order is randomized to ensure that the information received by the model is randomized, thereby increasing its adaptability to different contexts.

[0057] For each sample Its real label is The model's predicted probability is The cross-entropy loss function is defined as:

[0058] The final harm score is obtained based on the normalized input token length and the model's predicted label value.

[0059] This is the original input length; To protect the maximum input length of the model; This indicates the probability that the text is "safe". and It is an adjustable weighting coefficient.

[0060] By setting thresholds, requests with extremely high hazard scores will be rejected directly, while requests with relatively high hazard scores will require manual confirmation from the user before execution. Combining this with methods such as CAPTCHAs can further enhance security.

[0061] Step 3: Shared Cache Defense Mechanism. Another characteristic of LLM-DoS is high concurrency. It's important to understand that, regardless of whether it's a white-box or black-box attack, constructing a well-designed DoS attack prompt requires significant resource consumption. Therefore, concurrent requests used in a DoS attack are highly likely to be duplicates. To address this, a shared cache mechanism is designed to defend against LLM-DoS attacks. The model response computed by the GPU is not directly sent to the user but first enters a cache, which is essentially a hard disk space. All input requests are hashed to obtain a unique ID, and the streaming response result is used as the value in the cache, maintained using the least recently used principle. When an attacker sends a batch of attack requests... When attack request 1 arrives, the cache misses, the GPU computes the response, and when other request sequences arrive, the cache already contains the request being processed, so the corresponding value is returned directly to the cache as a stream. Shared cache defense increases the attacker's cost and improves system security.

[0062] This application provides a computer device according to an embodiment. The computer device of this embodiment includes: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the various method embodiments described above. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit in the various device embodiments described above.

[0063] The computer program can be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application.

[0064] The computer device may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device may include, but is not limited to, a processor and memory.

[0065] The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0066] The memory can be used to store the computer program and / or module, and the processor implements various functions of the computer device by running or executing the computer program and / or module stored in the memory, and by calling the data stored in the memory.

[0067] If the modules / units integrated into the computer device are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0068] This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform... Figure 1 The methods provided in the various optional modes are already available, so they will not be elaborated upon here.

[0069] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0070] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0071] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0072] The methods and related apparatus provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may be stored in a computer-readable storage medium that can direct a computer or other programmable device to function in a particular manner, causing the instructions stored in the computer-readable storage medium to produce an article of manufacture including the instruction means, or to be transmitted via a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The instruction means is implemented in the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0073] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0074] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0075] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for protecting against LLM-DoS attacks based on a multi-layered defense strategy, characterized in that, Includes the following steps: Limit the frequency of API requests to the LLM service and the number of output tokens, and dynamically adjust the limit thresholds based on the real-time system load; An input perception classifier is built based on a lightweight Transformer model, and graded interception is performed based on dynamic hazard scoring. The LLM server performs real-time detection and response reuse for repeated high-concurrency DoS attack requests.

2. The LLM-DoS attack protection method based on a multi-layered defense strategy according to claim 1, characterized in that, The restrictions on the frequency of API requests to the LLM service and the number of output tokens include: Establish a three-level rate limiting system, with the APIkey level using a baseline threshold; Implement a tiered circuit breaker mechanism; when the limit is triggered at any level, the connection at that level will be immediately broken, and a cross-level interlocking response will be initiated. A load-aware dynamic adjustment algorithm is introduced to automatically reduce the TPM quota at each level according to an exponential curve when the GPU utilization rate is consistently >80%. Establish a whitelist credit system and reserve emergency quotas for users with historically low risk.

3. The LLM-DoS attack protection method based on a multi-layered defense strategy according to claim 1, characterized in that, The method of constructing an input perception classifier based on a lightweight Transformer model and performing graded interception based on dynamic hazard scoring includes: By employing random fragment compression and length penalty strategies to overcome contextual limitations, and combining dynamic hazard scoring thresholds, hierarchical interception of LLM-DoS attacks is achieved.

4. The LLM-DoS attack protection method based on a multi-layered defense strategy according to claim 3, characterized in that, The hierarchical interception includes one or more combinations of direct rejection and manual verification.

5. The LLM-DoS attack protection method based on a multi-layered defense strategy according to claim 1, characterized in that, The method of constructing an input perception classifier based on a lightweight Transformer model and performing graded interception based on dynamic hazard scoring includes: A classifier is built based on a pre-trained lightweight Transformer model, and a random fragment compression method is used to process long text inputs. A length penalty factor is introduced to construct a hazard scoring function; Implement a three-tiered interception strategy, including direct access, manual verification, and direct rejection; A dynamic threshold adjustment mechanism is adopted to adjust the hazard scoring threshold according to the system load.

6. The LLM-DoS attack protection method based on a multi-layered defense strategy according to claim 1, characterized in that, The real-time detection and response reuse of repeated high-concurrency DoS attack requests on the LLM server includes: Establish a request hash mapping mechanism to generate a unique identifier for each input request; Implement streaming response reuse technology to perform only a single GPU computation for the same request; The LRU strategy is used to manage cache space, and a short-term cache expiration period is set.

7. An LLM-DoS attack protection system based on a multi-layered defense strategy, characterized in that, include: The dynamic frequency control module is used to limit the request access frequency and the number of output tokens for API requests of the LLM service, and dynamically adjust the limit thresholds according to the real-time system load. An intelligent traffic cleaning module is used to build an input perception classifier based on a lightweight Transformer model. A shared cache defense module is used to perform real-time detection and response reuse for repeated high-concurrency DoS attack requests on the LLM server.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes computer instructions, a processor of a computer device reads the computer instructions, and the processor of the computer device executes the computer instructions to implement the steps of the method as described in any one of claims 1 to 6.

Images