Concurrent debugging method and system based on sandbox-LLM session bidirectional binding

Abstract

The invention provides a concurrent debugging method and system based on sandbox-LLM (Language Model) session bidirectional binding. The method comprises the following steps: distributing a global unique session identifier for each LLM session; writing the globally unique session identifier and the sandbox instance identifier into a distributed memory database to form a bidirectional binding table, and marking the initial state as a binding state; realizing unvarnished transmission of a full-link global unique session identifier through an environment variable and an HTTP / gRPC header field; during sandbox thermal migration, the old instance atomically updates a binding table entry state into a migration state through a distributed mutual exclusion lock, and the new instance is written into the binding state after being preheated within a preset time; the log agent identifies an aggregation index according to a sandbox instance, collects average generation delay according to a preset frequency, accumulates a data collection number and GPU video memory occupation; and periodically polling the binding table, and cleaning entries which exceed a preset threshold value of the distributed mutual exclusion lock and are in a recovery state.

Description

Technical Field

[0001] The present invention relates to the technical field of electronic digital data processing, and in particular to a concurrent debugging method and system based on sandbox-LLM session bidirectional binding. Background Art

[0002] Common pain points when concurrently debugging large language model (LLM) applications in multiple containers or sandbox environments include: Session packet bursting: The LLM request link spans the container, sidecar, and reverse proxy, making it difficult to split logs by session. Hot migration context loss: The sandbox is migrated due to resource scheduling or failure, and the debug session ID becomes invalid; Lack of cross-link tracing: Distributed link tracing (such as OpenTelemetry) lacks the semantic layer of "LLM session", making it difficult to quickly associate prompts, fine-tune weights, and log in the sandbox.

[0003] Existing solutions (such as Jaeger + Sidecar log collection) can only guarantee HTTP-level traceId association and cannot establish a one-to-one mapping between the LLM Token-level and the sandbox lifecycle.

[0004] Patent application CN119026632A discloses a dynamic constrained multi-objective evolutionary method based on large language model interaction, including: initializing a population; dividing the population into target type and constraint type; transferring non-dominated individuals to the large language model to preserve historical information; detecting whether the environment has changed, and if so, classifying the type of environmental change; if so, initiating an interaction strategy with the large language model to generate responsive individuals based on the type of environmental change; if the environment has not changed, generating offspring using LLM interaction; connecting the reward value returned by the deep learning framework as the objective function for individual evaluation, selecting non-dominated individuals, and updating the population and archive; finally, determining whether the number of fitness evaluations is less than the maximum number of function evaluations. If so, outputting the optimal solution and optimal value of the population; otherwise, proceeding to the next generation of population evolution. However, this patent does not fully resolve existing technical problems or meet the requirements of the present invention. Summary of the Invention

[0005] In view of the defects in the prior art, the purpose of the present invention is to provide a concurrent debugging method and system based on sandbox-LLM session two-way binding.

[0006] The concurrent debugging method based on sandbox-LLM session bidirectional binding provided by the present invention includes: Step 1: Assign a globally unique session identifier to each large language model (LLM) session. Step 2: Write the globally unique session ID and the sandbox instance ID into the distributed memory database to form a two-way binding table. The initial state is marked as the binding state. Step 3: Transmit the globally unique session identifier through environment variables and HTTP / gRPC header fields. Step 4: When the sandbox is hot migrated, the old instance atomically updates the binding table entry state to the migration state through a distributed mutex lock. The new instance writes the binding state after completing the warm-up within the preset time. Step 5: The log agent aggregates metrics by sandbox instance ID, collecting average build latency, cumulative data collection count, and GPU memory usage at a preset frequency. When a violation is detected, a debug error report is generated. The report includes the globally unique session ID, the old and new sandbox instance IDs, the migration timestamp, the data collection rate, GPU utilization, and the error stack. Step 6: Periodically poll the binding table and clean up entries that exceed the preset threshold of the distributed mutex and are in the recycled state.

[0007] Preferably, preheating a new instance includes: loading a large language model (LLM) weight cache and session index identifier, synchronizing text instructions and query history cache through an in-memory database stream, and performing empty inference operations on the GPU to avoid cold start delays.

[0008] Preferably, violation detection uses a dynamic threshold model:

[0009] Where μ(t) is the baseline data acquisition rate generated by the exponentially weighted moving average, σ(t) is the standard deviation, and α is the sensitivity parameter. An anomaly flag is triggered when the data acquisition rate of two consecutive time windows exceeds the threshold.

[0010] Preferably, GPU utilization mutation analysis is performed: the cosine similarity between the current session GPU usage curve and the normal baseline of the same type of text instructions and queries is calculated, and when the similarity is lower than a preset threshold and accompanied by a data acquisition rate that does not meet the preset range, a joint alarm is triggered.

[0011] Preferably, the log agent includes: using a bucketing strategy to handle back pressure, bucketing according to a globally unique session identifier and a sliding time window, pausing log consumption and returning a corresponding response when the backlog of a single bucket exceeds a preset number of data collection events; instructing the client to retry the request after a specified time through a response header, and temporarily storing the bucketed data using a lightweight compression algorithm.

[0012] The concurrent debugging system based on sandbox-LLM session bidirectional binding provided by the present invention includes: Module M1: Assign a globally unique session identifier to each large language model (LLM) session; Module M2: Write the globally unique session identifier and the sandbox instance identifier into the distributed memory database to form a two-way binding table, and mark the initial state as the binding state; Module M3: Implements transparent transmission of the global unique session identifier through environment variables and HTTP / gRPC header fields; Module M4: When the sandbox is hot migrated, the old instance atomically updates the binding table entry state to the migration state through a distributed mutex lock, and the new instance writes the binding state after completing the warm-up within the preset time; Module M5: The log agent aggregates metrics by sandbox instance ID, collecting average generation latency, cumulative data collection count, and GPU memory usage at a preset frequency. When a violation is detected, a debug error report is generated, which includes the globally unique session ID, the old and new sandbox instance IDs, the migration timestamp, the data collection rate, the GPU utilization rate, and the error stack. Module M6: Periodically polls the binding table and cleans up entries that exceed the preset threshold of the distributed mutex and are in the recycled state.

[0013] Preferably, preheating a new instance includes: loading a large language model (LLM) weight cache and session index identifier, synchronizing text instructions and query history cache through an in-memory database stream, and performing empty inference operations on the GPU to avoid cold start delays.

[0014] Preferably, violation detection uses a dynamic threshold model:

[0015] Where μ(t) is the baseline data acquisition rate generated by the exponentially weighted moving average, σ(t) is the standard deviation, and α is the sensitivity parameter. An anomaly flag is triggered when the data acquisition rate of two consecutive time windows exceeds the threshold.

[0016] Preferably, GPU utilization mutation analysis is performed: the cosine similarity between the current session GPU usage curve and the normal baseline of the same type of text instructions and queries is calculated, and when the similarity is lower than a preset threshold and accompanied by a data acquisition rate that does not meet the preset range, a joint alarm is triggered.

[0017] Preferably, the log agent includes: using a bucketing strategy to handle back pressure, bucketing according to a globally unique session identifier and a sliding time window, pausing log consumption and returning a corresponding response when the backlog of a single bucket exceeds a preset number of data collection events; instructing the client to retry the request after a specified time through a response header, and temporarily storing the bucketed data using a lightweight compression algorithm.

[0018] Compared with the prior art, the present invention has the following beneficial effects: The present invention uses the "sandbox-LLM session two-way binding + MOVING state migration protocol + full-link session transparent transmission" technology to solve the problems of session packet stringing and migration context loss in concurrent debugging, realize the one-to-one binding of LLM sessions and sandbox instances, automatic renewal and traceable log aggregation, and provide millisecond-level debugging query capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Other features, objects and advantages of the present invention will become more apparent upon reading the detailed description of non-limiting embodiments with reference to the following drawings: Figure 1 is a flow chart of the method; Figure 2 This is the MOVING state timing diagram. DETAILED DESCRIPTION

[0020] The present invention will be described in detail below with reference to specific embodiments. The following examples will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those skilled in the art, several changes and improvements can be made without departing from the scope of the present invention. These all fall within the scope of protection of the present invention.

[0021] Example 1 like Figure 1 The present invention provides a concurrent debugging method based on sandbox-LLM session bidirectional binding, comprising: A) Session initialization: Assign a globally unique session identifier SessionID to each LLM session; B) Two-way binding registration: When the sandbox instance is started, the SessionID and the sandbox instance identifier SandboxID are written into the distributed binding table, and the initial state is recorded as BOUND; C) Full-link transparent transmission: In the sandbox and its sidecar process, the SessionID is injected into the environment variable and / or added to the HTTP or gRPC header field "X-LLM-Session" to achieve request link transparent transmission; D) Hot migration renewal: D1) When the orchestration and scheduling system triggers a sandbox hot migration, the old sandbox instance atomically updates the binding table entry state to MOVING through heartbeat detection combined with a distributed mutex lock and returns a confirmation signal; the MOVING state timing diagram is shown in the following figure. Figure 2 ; To ensure the atomicity and consistency of the sandbox hot migration process, the present invention introduces the following collaborative mechanism and fault-tolerant design between the distributed mutex and heartbeat detection: 1. Mutex implementation mechanism: Distributed mutex locks are implemented through Redis's SETNX command, with a key format of llm:lock: <sessionid>, set the lock holding time expire=300ms to ensure that a single instance holds the lock and automatically expires to prevent deadlock.

[0022] 2.MOVING status write logic: In every 50ms heartbeat cycle, the old sandbox detects a scheduling event and first attempts to acquire the aforementioned mutex lock. Only the successful lock holder can atomically update the binding table entry to MOVING and immediately release the lock. This process is wrapped in a Lua script to ensure the atomicity of Redis operations.

[0023] 3. Crash boundary scenario processing: If the old instance unexpectedly crashes or loses connection after being successfully marked as MOVING, the Watchdog process will deem the entry "non-renewable" after a continuous heartbeat timeout (for example, three consecutive heartbeats are missed). The new instance will be forced to renew as BOUND after the MOVING state detection timeout (default P95 < 200ms) and record the partial migration event for debugging.

[0024] 4. Anti-deadlock mechanism: To avoid deadlocks caused by multi-node lock contention, all locks are forced to have an expiration TTL (e.g., 300ms) and any form of infinite retry is prohibited. If the old instance fails to complete the status update within the TTL, it is considered a lock acquisition failure, and the scheduler automatically postpones the migration action for 1 second to retry or switch to an alternative migration path.

[0025] 5. Fallback mechanism for failure to write MOVING status: If the old instance fails to successfully write to the MOVING state (for example, due to Redis write failure or lock conflict), the current hot migration action is interrupted. The scheduler's retry process will be marked with the retry flag attempt=x and recorded in the event log to ensure that system behavior is auditable.

[0026] To ensure strong consistency and atomicity when the old sandbox instance atomically updates the binding table entry state to MOVING, the present invention adopts the following multi-layered technical mechanisms: 1. Atomic write guarantee: The state update operation is implemented through Redis's Lua script (EVAL), which integrates operations such as acquiring a mutex lock, determining the current state, setting a new state MOVING, and recording a timestamp into a single Redis atomic execution transaction to prevent concurrent write conflicts during the "read-modify-write" process.

[0027] Example operation: if redis.call('get', KEYS[1]) == 'BOUND' then redis.call('set', KEYS[1], 'MOVING') redis.call('set', KEYS[2], ARGV[1]) -- Set timestamp return 1 else return 0 end 2. Mutex lock mechanism cooperation: Before executing the above Lua script, the old instance must first obtain llm:lock through the Redis SETNX command: <sessionid>Distributed mutex locks prevent duplicate writes caused by competition among multiple sandboxes; The lock lifetime is set to 300ms to prevent deadlock (automatic release), and the unique holder is identified by UUID to ensure that only the lock holder can release the lock.

[0028] 3. Description of the integration points with CRDT: Although the RedisLua script is used for atomic write operations within a single data center, the present invention allows deployment in a multi-data center environment. For this purpose, the Redis cluster enables the CRDT (Conflict-free Replicated Data Type) replication mechanism. Binding table<SessionID,{SandboxID,Status,Timestamp}> The structure is defined as a CRDT type (such as Last-Write-Wins Element Set, LWW-Set), which can achieve distributed asynchronous replication and eventual consistency; After the old instance is marked as MOVING, the changes are immediately written to the local Redis shard and automatically propagated to replica nodes in other data centers through the CRDT engine, achieving "remote readable consistency".

[0029] 4. Boundary protection and failure handling: If the Lua script fails to execute (for example, due to state conflicts or Redis exceptions), the old instance immediately records the migration failure and notifies the orchestration system to perform a rollback. If CRDT propagation is not complete, the new instance may read the "old state" when attempting to renew. The system is designed with a maximum delay threshold (default 100ms) after which a forced overwrite is performed to avoid blocking the migration process due to replica unsynchronization.

[0030] D2) After the new sandbox instance is preheated, {SessionID, SandboxID_new, BOUND} is written to the binding table and the mutex is released, making the overall migration window less than 200 milliseconds; To ensure that sandbox live migration is completed within the 200 millisecond P95 window, the system has designed the following guarantee mechanisms during the new instance renewal process: 1. LLM context preloading strategy in the warm-up phase: After a new instance is started, it immediately enters the pre-warming phase. During this phase, it does not directly process requests but instead loads the following context in advance: Corresponding LLM weight cache and Session Token index; Prompt history cache (session context synchronization via Redis Stream); Perform several warmups on the GPU to avoid the cold start delay of the first request. Only after the above three preparations are completed will an attempt be made to write {SessionID, SandboxID_new, BOUND}.

[0031] 2. Preemptive Bound Write: The system introduces "preemptive renewal" logic. This means that when a new instance attempts to write the BOUND status in the binding table, if the current status is MOVING and the MOVING mark time exceeds 100ms, it will be forcibly overwritten to prevent the old instance from deadlocking and causing migration to be stuck. This process still needs to acquire the mutex lock to ensure consistency under concurrent competition.

[0032] 3. Fallback strategy for failed renewal: If the new instance cannot successfully write BOUND within 200ms (for example, due to Redis unavailability or lock conflicts), it will immediately: Report the renewal failure event to the console and scheduler, and mark the session as degraded. The Watchdog triggers the "migration retry" process, marking the current new instance as INVALID and releasing resources. Prioritize rescheduling to the cold standby instance within the node to minimize delays caused by cross-machine migration.

[0033] 4. P95 Migration Window Measurement and Monitoring Mechanism: The system records T1 = MOVING setup time and T2 = BOUND write time for each session migration, and calculates ΔT = T2 - T1; All migration events are entered into a time series database (such as Prometheus + Grafana) to calculate the P95 and P99 migration time metrics. If five events exceeding 200ms occur in consecutive sampling, the system will automatically perform configuration rollback or downgrade.

[0034] E) Log Aggregation and Debug Reporting: The log agent aggregates link logs based on the SessionID and performance metrics collected at the token level. If an interface violation or anomaly is detected, a debug error report is generated. The report contains at least the SessionID, old / new SandboxID, migration timestamp, token rate, GPU utilization, and error stack. To effectively identify abnormal call behavior in high-concurrency scenarios, this paper designs a multi-dimensional "violation detection" judgment mechanism in the log agent, combining dynamic threshold modeling and correlation feature analysis. Specifically, it includes: 1. Token Rate Anomaly Detection (DAT) The system uses a sliding window mechanism (default 3 seconds) to record the token output rate (Token / s) of each session; Generate a dynamic baseline rate μ(t) using an exponentially weighted moving average (EWMA) on the historical window and set an adaptive threshold: , where α is the sensitivity parameter (default 2.5) and σ(t) is the standard deviation within the window; If the current token rate exceeds the threshold for two consecutive windows, it is marked as "rate abnormality" and the context is further analyzed to see if there is a risk of prompt injection or model generalization failure.

[0035] 2. Correlation analysis between GPU utilization mutation and context anomaly: Each log bucket records GPU real-time utilization (%), video memory usage (MB), and the number of video memory surges. The system calculates the cosine similarity between the GPU usage curve of the current session and the normal baseline session (same as Prompt type). If it is less than the set threshold (such as 0.75), combined with the abnormal token rate, a joint alarm is triggered; Special attention is paid to the "sudden drop-low utilization" pattern (for example, GPU utilization drops to <10% momentarily, but the log volume continues to increase) as a potential "infinite loop generation" or "Prompt defect" risk.

[0036] 3. Content-Indicator Joint Rules Engine: After all indicators are triggered abnormally, enter the rule-based content analysis module: Contains sensitive function call stacks (such as eval, exec); The session context contains abnormal keywords (such as infinite loop, redundant nesting, etc.); The number of SessionTokens exceeds the upper limit (e.g., 4,096); When any joint rule is triggered, a "debug error report" will be generated and immediately pushed to the front-end console and CI blocking interface via WebSocket.

[0037] 4. False Positive Suppression: Each rule item uses a confidence scoring mechanism, and a final alarm is generated only when the comprehensive score threshold (e.g., ≥0.7) is reached; During the training phase, historical session data is collected to form unsupervised clustering (such as DBSCAN) to optimize the threshold setting and ensure that the false alarm rate is controlled below 1%.

[0038] F) Failure detection: Periodically poll the binding table. When an entry exceeds a preset lifetime TTL and is in the DROPPED state, the entry is deleted to release resources.

[0039] The distributed binding table adopts Cluster implementation, the key format is llm:sandbox: <sessionid>The value contains {SandboxID,Status,Timestamp}.

[0040] The mutex is implemented using the RedisSETNX command. The heartbeat packet period is 50 milliseconds. If three consecutive heartbeats are missing, the old sandbox instance is considered invalid.

[0041] The migration window is measured as the time from when the state is set to MOVING to when the new sandbox instance is set to BOUND, ensuring that the P95 does not exceed 200 milliseconds.

[0042] Debug error reports are returned to the continuous integration pipeline via HTTP 409 status code or shell exit code 3 and are archived to the object storage service.

[0043] The log agent outputs metrics every 50 tokens when the LLM generates a response, including the average generation latency, the cumulative number of tokens, and the current GPU memory usage.

[0044] When the status is MOVING, the downstream caller receives a 302 redirect or a response with a Retry-After header to avoid a 404 error.

[0045] The polling period of the Watchdog process is 60 seconds, and the TTL is 30 minutes.

[0046] Debug error reports are pushed to the debug console in real time via WebSocket to support IDE interactive debugging.

[0047] The method of the present invention is applicable to containers, virtual machines or bare metal sandboxes, and supports orchestration platforms such as Kubernetes, Docker Compose or Nomad.

[0048] Example 2 The present invention provides a concurrent debugging system based on sandbox-LLM session bidirectional binding, comprising: a) Session ID allocation unit, used to generate a globally unique Session ID; b) A two-way binding registration unit, used to write the SessionID and the sandbox instance SandboxID into the Redis cluster and maintain the BOUND, MOVING, and DROPPED states; c) Link transparent transmission unit, used to inject SessionID into environment variables or HTTP / gRPC headers; d) Migration renewal unit, used to complete the state switching from MOVING to BOUND within a 200 millisecond window through heartbeat detection and mutex control during sandbox migration; e) Log aggregation unit, used to aggregate logs by SessionID and collect token-level metrics; f) A debugging query unit, configured to generate a debugging error report and output blocking instructions to the continuous integration system.

[0049] The Redis cluster enables multi-master CRDT replication to support cross-datacenter session migration.

[0050] The debugging query unit provides a SessionID-based REST interface / debug / {sid} and a WebSocket-based real-time subscription interface.

[0051] The log aggregation unit writes the debug data in batches into the data lake in Parquet format for offline analysis.

[0052] Those skilled in the art will appreciate that, in addition to implementing the system, device, and various modules provided by the present invention in purely computer-readable program code, it is entirely possible to implement the same program in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, embedded microcontrollers, and the like by logically programming the method steps. Therefore, the system, device, and various modules provided by the present invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; the modules for implementing various functions can also be considered both software programs for implementing the method and structures within the hardware component.

[0053] The above describes specific embodiments of the present invention. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art may make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. The embodiments of this application and the features in the embodiments may be combined with each other in any manner unless there is a conflict.< / sessionid> < / sessionid> < / sessionid>

Claims

1. A concurrent debugging method based on sandbox-LLM session two-way binding, characterized in that: include: Step 1: Assign a globally unique session identifier to each large language model (LLM) session. Step 2: Write the globally unique session ID and the sandbox instance ID into the distributed memory database to form a two-way binding table. The initial state is marked as the binding state. Step 3: Transmit the globally unique session identifier through environment variables and HTTP / gRPC header fields. Step 4: When the sandbox is hot migrated, the old instance atomically updates the binding table entry state to the migration state through a distributed mutex lock. The new instance writes the binding state after completing the warm-up within the preset time. Step 5: The log agent aggregates metrics by sandbox instance ID, collecting average build latency, cumulative data collection count, and GPU memory usage at a preset frequency. When a violation is detected, a debug error report is generated. The report includes the globally unique session ID, the old and new sandbox instance IDs, the migration timestamp, the data collection rate, GPU utilization, and the error stack. Step 6: Periodically poll the binding table and clean up entries that exceed the preset threshold of the distributed mutex and are in the recycled state.

2. The concurrent debugging method based on sandbox-LLM session two-way binding according to claim 1, characterized in that: Warming up a new instance includes loading the large language model (LLM) weight cache and session index identifiers, synchronizing text instructions and query history caches through in-memory database streams, and performing empty inference operations on the GPU to avoid cold start delays.

3. The concurrent debugging method based on sandbox-LLM session two-way binding according to claim 1, characterized in that: Violation detection uses a dynamic threshold model: Where μ(t) is the baseline data acquisition rate generated by the exponentially weighted moving average, σ(t) is the standard deviation, and α is the sensitivity parameter. An anomaly flag is triggered when the data acquisition rate of two consecutive time windows exceeds the threshold.

4. The concurrent debugging method based on sandbox-LLM session two-way binding according to claim 3, characterized in that: Perform GPU utilization mutation analysis: Calculate the cosine similarity between the current session's GPU usage curve and the normal baseline of similar text instructions and queries. When the similarity falls below the preset threshold and is accompanied by a data collection rate that does not meet the preset range, a joint alarm is triggered.

5. The concurrent debugging method based on sandbox-LLM session two-way binding according to claim 1, characterized in that: The log agent includes: using a bucketing strategy to handle back pressure, bucketing according to the globally unique session identifier and sliding time window, pausing log consumption and returning a corresponding response when the backlog of a single bucket exceeds the preset number of data collection events; instructing the client to retry the request after a specified time through the response header, and temporarily storing the bucketed data using a lightweight compression algorithm.

6. A concurrent debugging system based on sandbox-LLM session bidirectional binding, characterized in that: include: Module M1: Assign a globally unique session identifier to each large language model (LLM) session; Module M2: Write the globally unique session identifier and the sandbox instance identifier into the distributed memory database to form a two-way binding table, and mark the initial state as the binding state; Module M3: Implements transparent transmission of the global unique session identifier through environment variables and HTTP / gRPC header fields; Module M4: When the sandbox is hot migrated, the old instance atomically updates the binding table entry state to the migration state through a distributed mutex lock, and the new instance writes the binding state after completing the warm-up within the preset time; Module M5: The log agent aggregates metrics by sandbox instance ID, collecting average generation latency, cumulative data collection count, and GPU memory usage at a preset frequency. When a violation is detected, a debug error report is generated, which includes the globally unique session ID, the old and new sandbox instance IDs, the migration timestamp, the data collection rate, the GPU utilization rate, and the error stack. Module M6: Periodically polls the binding table and cleans up entries that exceed the preset threshold of the distributed mutex and are in the recycled state.

7. The concurrent debugging system based on sandbox-LLM session bidirectional binding according to claim 6, characterized in that: Warming up a new instance includes loading the large language model (LLM) weight cache and session index identifiers, synchronizing text instructions and query history caches through in-memory database streams, and performing empty inference operations on the GPU to avoid cold start delays.

8. The concurrent debugging system based on sandbox-LLM session bidirectional binding according to claim 6, characterized in that: Violation detection uses a dynamic threshold model: Where μ(t) is the baseline data acquisition rate generated by the exponentially weighted moving average, σ(t) is the standard deviation, and α is the sensitivity parameter. An anomaly flag is triggered when the data acquisition rate of two consecutive time windows exceeds the threshold.

9. The concurrent debugging system based on sandbox-LLM session bidirectional binding according to claim 8, characterized in that: Perform GPU utilization mutation analysis: Calculate the cosine similarity between the current session's GPU usage curve and the normal baseline of similar text instructions and queries. When the similarity falls below the preset threshold and is accompanied by a data collection rate that does not meet the preset range, a joint alarm is triggered.

10. The concurrent debugging system based on sandbox-LLM session bidirectional binding according to claim 6, characterized in that: The log agent includes: using a bucketing strategy to handle back pressure, bucketing according to the globally unique session identifier and sliding time window, pausing log consumption and returning a corresponding response when the backlog of a single bucket exceeds the preset number of data collection events; instructing the client to retry the request after a specified time through the response header, and temporarily storing the bucketed data using a lightweight compression algorithm.

Images