A large model native cross-device operating system

Abstract

The application provides a large model original cross-device operating system, relates to the technical field of large models, and comprises: an application interaction layer used for providing a unified operation interface and an application access entrance to multiple users through a browser; an operating system core layer arranged below the application interaction layer and configured to maintain multiple application instances running at a bottom layer, the application instances corresponding to the applications provided by the upper layer one by one, and used for realizing the functions of the corresponding applications; a bottom layer resource management layer arranged below the operating system core layer and configured to uniformly manage heterogeneous computing power devices and storage databases at the bottom layer; the operating system core layer is further configured with a resource scheduling interface and a data routing interface; and the application not only avoids resource waste caused by repeated calculation, but also improves the data interaction experience and overall efficiency of users in a cross-application scenario.

Description

Technical Field

[0001] This invention relates to the field of large model technology, and in particular to a native cross-device operating system for large models. Background Technology

[0002] With the rapid development of large-scale model technology, the computing power scheduling mode of traditional cloud platforms is usually bound to specific hosts, resulting in the inability to uniformly manage and elastically allocate heterogeneous computing resources across devices at the operating system level. At the same time, existing application systems generally suffer from the problem of "data silos," with data flow between different application instances often relying on external interfaces or third-party middleware, lacking a unified scheduling and coordination mechanism at the operating system level. This complicates resource isolation and task scheduling when multiple users access the system concurrently. In addition, when traditional applications process unstructured documents such as PDFs and Word documents uploaded by users, they usually need to rely on the data preprocessing modules of the upper-layer applications for format parsing and vectorization conversion, lacking native support at the operating system level. This makes it difficult for different applications to share the same knowledge base data, resulting in not only wasted resources from redundant calculations but also limiting the user's data interaction experience and overall efficiency across application scenarios. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0004] According to the large-model native cross-device operating system provided in this application, it includes:

[0005] The application interaction layer is used to provide a unified user interface and application access point to multiple users through a browser.

[0006] The operating system core layer is deployed below the application interaction layer and is configured to maintain and run multiple application instances at the bottom layer. Each application instance corresponds one-to-one with the application provided by the upper layer and is used to implement the functions of the corresponding application.

[0007] The underlying resource management layer is deployed below the operating system kernel layer and configured to uniformly manage heterogeneous computing devices and storage databases at the underlying level.

[0008] The operating system kernel layer is also configured with a resource scheduling interface and a data routing interface;

[0009] When any user opens the corresponding application through the application interaction layer, the operating system kernel layer establishes a connection between the user and the application instance; the application instance supports establishing connections with multiple users simultaneously.

[0010] When a user controls the application instance to initiate data interaction or computing power calculation tasks through the connection relationship, the application instance interacts with the operating system core layer by calling the resource scheduling interface. The operating system core layer controls the underlying resource management layer to perform actual computing power calculation or data access operations and returns the execution results to the application instance, which then feeds back to the application interaction layer.

[0011] When the application instance needs to synchronize data to other application instances, the application instance sends the data to be synchronized to the data routing interface of the operating system kernel layer, and the operating system kernel layer forwards the data to be synchronized to the target application instance.

[0012] When any user uploads data through the application instance, the operating system kernel layer vectorizes the data and stores it in the unified database of the underlying resource management layer, so that all application instances with established connections can access the data through the operating system kernel layer.

[0013] The present invention has at least the following beneficial effects:

[0014] The large-scale native cross-device operating system of this invention achieves unified management and decoupling of heterogeneous computing devices and storage databases through a three-tiered architecture consisting of an application interaction layer, an operating system kernel layer, and a low-level resource management layer. On this architecture, when a user opens an application, the operating system kernel layer can dynamically establish a dedicated connection between the user and the application instance, supporting concurrent one-to-many connections between the same application instance and multiple users while achieving underlying logical isolation. Through the resource scheduling interface configured in the kernel layer, when an application instance initiates computing or data interaction tasks, it does not need to concern itself with the underlying hardware details; it can directly issue instructions to the operating system kernel layer, which will then transparently schedule and execute the tasks and return the results. This effectively solves the problems of traditional cloud platform computing... This overcomes the limitations of hardware-bound systems. Furthermore, through the data routing interface of the operating system kernel layer, any application instance can directly send data to the kernel layer when it needs to synchronize data. The operating system then forwards the data to the target instance, breaking down traditional data silos between applications. In addition, when users upload data through application instances, the operating system kernel layer automatically performs vectorization processing on the data and stores it in the underlying unified database. This allows all connected application instances to access the data seamlessly through the operating system kernel layer, avoiding resource consumption from repeated data parsing and vector conversion by each application. This lowers the development and deployment threshold for multimodal large-scale applications, providing users with seamless data flow and a seamless interactive experience across applications and devices. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of the structural framework of the native cross-device operating system for a large model provided in an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0019] The following will refer to Figure 1 The diagram shown illustrates the structural framework of a large-scale native cross-device operating system, providing an introduction to such an operating system.

[0020] The large model's native cross-device operating systems include:

[0021] The application interaction layer is used to provide a unified user interface and application access point to multiple users through a browser.

[0022] In this embodiment, in actual engineering, the application interaction layer is a web front-end service (B / S architecture) deployed in the cloud. Users access this unified entry point through a browser on any device and receive a multi-tenant isolated interface, where they can click on various applications (such as multi-agent collaboration, intelligent operation and maintenance, digital employees, etc.).

[0023] The operating system core layer is deployed below the application interaction layer. It is configured to maintain and run multiple application instances at the bottom layer. Each application instance corresponds one-to-one with the application provided by the upper layer and is used to implement the functions of the corresponding application.

[0024] Operating system kernel layer corresponding Figure 1 The "operating system layer" is composed of "system middleware" and "system kernel". This is the underlying PaaS platform deployed on server clusters (such as Kubernetes clusters). Internally, this layer actually runs components such as a container orchestration engine, a global file system, a task scheduler, a vectorization engine, and a unified permission gateway.

[0025] The underlying resource management layer is deployed below the operating system kernel layer and configured to uniformly manage the heterogeneous computing devices and storage databases at the underlying level.

[0026] The underlying resource management layer corresponds to Figure 1 The bottom layer is the "Smart Device Layer," and to its left is the "System Security" component. At the bottom of this layer are various heterogeneous hardware devices (such as Wanka intelligent computing servers, edge boxes, and autonomous vehicles), which connect to the core layer through dedicated device drivers and network links, forming a unified resource pool.

[0027] The operating system kernel layer is also configured with a resource scheduling interface and a data routing interface.

[0028] The resource scheduling interface is a unified task distribution API provided by the operating system kernel layer, situated between the application instance and the underlying "distributed heterogeneous computing power scheduling" module; corresponding to Figure 1 "Distributed heterogeneous computing power scheduling" in the context of computing power scheduling.

[0029] Application instances do not need to know whether the underlying system is a "Wanka Intelligent Computing Server" or an "Edge Intelligent Terminal". Regardless of the computing power task sent by the instance, it is uniformly encapsulated into a standard task request (Payload) through this interface and handed over to the operating system.

[0030] After receiving a user instruction, the application instance does not directly perform computation (such as not directly calling the GPU driver), but instead "hands over" the control of the action to the "computing power management" module of the operating system kernel layer through this interface, so that the operating system can schedule the underlying CPU, GPU, and memory resources.

[0031] After the operating system finishes execution, it also uses the asynchronous callback mechanism of this interface to return the execution result (such as the inferred text or the recognized image result) and the execution status (success / failure / insufficient resources) to the application instance that initially initiated the call.

[0032] The data routing interface is a unified data forwarding and governance entry point API provided by the operating system kernel layer. It connects application instances with "end-to-end data governance," "cross-instance synchronization," and "unified database," and is often implemented through the "transmission management" and "system API" modules of the middleware layer; corresponding to Figure 1 "End-to-end data governance" in the context of data governance.

[0033] When two application instances need to exchange data, they don't connect directly via complex RPC. Instead, they uniformly package the data and hand it over to the "data routing interface," which the operating system automatically routes it to the target application instance. When a user uploads a file (PDF / Word) through an application, the application instance also sends the file stream directly to the "data routing interface." After receiving the data, the data routing interface drives the "end-to-end data governance" module (which moves down to the system kernel) within the operating system's core layer, triggering native vectorization processing and storing the vectors in the underlying unified database. All application instances that need to query data (such as vector retrieval or knowledge base queries) do so by asking the operating system through this interface. After retrieving the data from the underlying unified database, the operating system returns the query results to the instance, eliminating the need for each instance to maintain its own database connection.

[0034] Step 1: When any user opens the corresponding application through the application interaction layer, the operating system core layer establishes a connection between the user and the application instance; the application instance supports establishing connections with multiple users simultaneously.

[0035] In this embodiment, after logging in through a browser, the user selects a smart application (e.g., "Smart Operations and Maintenance") in the application interaction layer. The front-end sends an application open request to the back-end; the operating system core layer (specifically the "Container Management" and "Application Center" modules in the middleware) receives this request. At this point, the system performs a logical judgment:

[0036] If the application instance has not yet started in the background, the system kernel will quickly launch a new application instance (i.e., run a Docker container or microservice process) through the container engine.

[0037] If the application already has a running instance in the background: the system core layer will not create a new instance for this user, but will directly establish a connection.

[0038] The concrete embodiment of the "connection relationship": The core layer generates a globally unique session credential (Token / Session ID) for the current user and writes this credential into the "Authentication and Permissions" module of the core layer. At the same time, it records a mapping table between this credential and the process ID (PID) or container handle of the application instance process. An application instance process can support mapping hundreds or thousands of user session credentials simultaneously, which realizes one-to-many concurrency control.

[0039] Step 2: When the user controls the application instance to initiate data interaction or computing power calculation tasks through the connection relationship, the application instance interacts with the operating system core layer by calling the resource scheduling interface. The operating system core layer controls the underlying resource management layer to perform actual computing power calculation or data access operations and returns the execution results to the application instance, which then feeds back to the application interaction layer.

[0040] In this embodiment, the user operates the application in a browser (e.g., uploading business data and requesting a large AI model to perform inference). The front-end sends instructions to the application instance process. This application instance process does not directly perform high-power computation; instead, it sends instructions containing task parameters and data addresses to the operating system's "resource scheduling interface" through a unified API interface. The "distributed heterogeneous computing power scheduling" module in the operating system kernel layer takes over the instructions. Based on the real-time load of the underlying resources, it distributes the task to the GPU of the optimal server in the "intelligent device layer" (such as a multi-card inference server). After the underlying GPU completes the inference, it writes the computation results to the operating system's underlying "storage management" module (or even directly to the shared memory area), and then the "distributed heterogeneous computing power scheduling" module calls back to the application instance. After receiving the results, the application instance pushes them to the front-end browser and displays them on the user's interface.

[0041] Step 3: When the application instance needs to synchronize data to other application instances, the application instance sends the data to be synchronized to the data routing interface of the operating system kernel layer, and the operating system kernel layer forwards the data to be synchronized to the target application instance.

[0042] In this embodiment, it is assumed that two different application instances, A and B, are running on the core layer. Instance A, having finished processing a segment of data, needs to hand it over to instance B to continue subsequent business processes. Application instance A directly sends the data packet to be synchronized, along with instance B's "instance ID," to the operating system's "data routing interface" (represented as "transmission management" or "system API" in the middleware) via API. Upon receiving this, the operating system core layer first triggers the "authentication and authorization" module to verify whether instance A has the permission to send data to instance B. If the verification passes, the operating system core layer directly pushes the data packet to the memory or underlying storage where instance B resides and sends a "new data arrived" wake-up event to instance B. Throughout this process, the data flow is entirely handled by the operating system in the background, without requiring direct P2P communication between application A and application B.

[0043] Step 4: When any user uploads data through the application instance, the operating system kernel layer performs vectorization processing on the data and stores it in the unified database of the underlying resource management layer, so that all application instances with established connections can access the data through the operating system kernel layer.

[0044] In this embodiment, a user uploads a PDF or Word file through any application instance. Upon receiving the file, the application instance immediately forwards the file stream to the "end-to-end data governance" module in the operating system kernel layer via an internal interface. This module then calls down to the system kernel's "file system" and "operator optimization" components.

[0045] The specific processing steps are as follows: First, the system extracts and cleans the unstructured text. Then, the vectorization operator in the kernel converts the text into a high-dimensional floating-point vector and generates a data summary in Markdown format.

[0046] Storage and Sharing: The original PDF file is stored in the underlying managed file storage system. The generated vector data is stored in the underlying vector database. The association between the vectorized data and the source file, as well as the data version information, are written to the metadata management system.

[0047] Because the data is stored in the operating system's unified database, regardless of who initiates the query through which application instance, the application instance only needs to submit the query request to the operating system's data governance module, and the operating system can directly retrieve and return the results from the underlying unified database. All application instances that have established connections do not need to develop their own vectorization transformation logic and can access the same structured data.

[0048] In this embodiment, a three-layer decoupled architecture is adopted, consisting of an application interaction layer, an operating system kernel layer, and a bottom-level resource management layer. During actual operation, the operating system kernel layer uniformly maintains application instances at the bottom layer and establishes session mappings with multi-tenant users, achieving seamless support for multiple concurrent users and bottom-level isolation for a single application instance. During task execution, the application instance issues instructions to the bottom layer through the resource scheduling interface built into the operating system kernel layer. The system's built-in distributed heterogeneous computing power scheduling module coordinates the computing power resources of various servers, edge devices, and even embodied intelligent robots, realizing transparent invocation and elastic allocation of cross-platform and cross-device computing power resources, completely eliminating the limitations of traditional applications being bound to specific underlying hardware. Meanwhile, the data routing interface configured in the operating system kernel layer can uniformly take over and forward data interactions between different application instances based on the system's embedded permission verification mechanism, cutting off the need for point-to-point direct connections between applications and significantly reducing the development complexity of cross-system data flow. In addition, based on the full-link data governance engine, the system directly completes the automatic vectorization and storage of unstructured files at the operating system kernel level, enabling all upper-layer application instances managed in the system to share a knowledge base based on a unified data foundation. This avoids each independent application performing repetitive data parsing and preprocessing work, greatly reducing the data management cost and resource consumption of multimodal large-scale applications in multi-application and multi-device scenarios.

[0049] In an optional embodiment, the operating system kernel layer establishes a connection between the user and the application instance, including:

[0050] The operating system core layer assigns a unique session identifier to the current user and establishes a mapping relationship between the session identifier and the runtime resource handle of the current application instance.

[0051] In this embodiment, in actual deployment, the operating system kernel layer maintains a global "mapping context registry" at the bottom layer (usually residing in the cache or memory database of the middleware layer).

[0052] When a user initiates a login or application access request to the operating system through the application interaction layer (browser), the "Authentication and Permissions" module of the operating system kernel layer generates a unique session identifier (such as UUID, JWT Token, or Session ID).

[0053] After the session identifier is generated, the core layer not only sends it back to the user's browser as a credential for subsequent interactions, but also maps the session identifier to a "resource handle" of the target application instance at runtime. This "resource handle" has different implementations depending on the underlying architecture: in a Kubernetes environment, it might be the container's Pod IP and port; in traditional process management, it might be the operating system's process ID (PID) or a memory pointer.

[0054] The mapping between this session identifier and the application instance resource handle is written into the internal routing table of the operating system kernel layer, ensuring that any subsequent requests carrying this session identifier can be accurately routed to the corresponding application instance.

[0055] When the same application instance is accessed by multiple users at the same time, the operating system core layer establishes a mapping relationship for each user and performs logical isolation protection on the interaction data and task status of each user at the underlying level based on the session identifier of each user.

[0056] In this embodiment, when the same application instance is accessed by multiple users simultaneously, the operating system kernel layer will independently establish the aforementioned mapping relationship for each user. However, this does not mean that multiple application instances are physically launched.

[0057] All user-initiated commands enter the same application instance's receive queue. When processing these commands, the instance extracts the current session identifier from the HTTP header or message body.

[0058] The system does not isolate memory through physical partitioning, but rather achieves logical isolation through the system middleware and the kernel's "data context interception mechanism". When the core layer passes instructions to the "end-to-end data governance" and the underlying storage, it converts the user's session identifier into the user's globally unique identifier (User ID).

[0059] When an application instance needs to retrieve data from the underlying unified database, the underlying storage component of the operating system kernel layer will forcibly attach a WHERE condition: WHERE UserID = [UserID corresponding to the current session identifier]. In other words, although the application instances run the same process at the underlying level, the kernel layer and the core layer ensure that user A can never see any data uploaded by user B, nor can user B's task execution status, by attaching the session owner identifier to the data access. Figure 1 The "System Security" module on the left and the "Authentication and Permissions" module in the middleware layer are the specific implementation solutions for this logical isolation mechanism.

[0060] The above-described implementation of this solution establishes a unique mapping system between user session identifiers and application instance runtime handles at the operating system kernel layer. This allows a single application instance to simultaneously support access from tens of thousands of concurrent multi-tenant users. On the one hand, it significantly saves system resources from the bottom layer (avoiding the repetitive overhead of independently launching a new application for each user) and improves the operating system's concurrency support density. On the other hand, based on session identifiers, the system implements strict data context isolation at the operating system kernel and middleware levels, intercepting and forcibly verifying all underlying database queries and task status reads. This ensures that the data of different users can achieve logical absolute "physical isolation" in a physically shared environment, meeting the agile scheduling requirements of large-scale model applications under high concurrency for multiple users while ensuring data security and compliance in large-scale multi-tenant scenarios.

[0061] In an optional embodiment, when any user opens the corresponding application through the application interaction layer, the operating system kernel layer includes the following steps before establishing the connection relationship:

[0062] If the application instance corresponding to the target application is not yet running at the underlying operating system, the operating system core layer dynamically starts a new application instance based on the container management engine of the middleware layer, and establishes the connection between the user and the new instance after the new application instance is successfully started.

[0063] In this embodiment, in actual engineering deployment, the underlying layer of the operating system kernel can be supported by a container orchestration cluster (such as Kubernetes or Docker Swarm).

[0064] When any user clicks to open an application through the application interaction layer (browser), the request will first reach the "Application Center" module in the operating system kernel layer.

[0065] After the "Application Center" module takes over the request, it does not return a result directly. Instead, it immediately initiates a query to the "Cluster Management" module at the underlying operating system kernel layer. This module retrieves the service registry in the cluster to determine whether the target application is already running in the background. There are clear criteria for determining "whether it is running": that is, whether the container (or Pod) corresponding to the application instance is in the "Running" state and whether its built-in health check interface has returned an available status.

[0066] Once the "cluster management" module determines that the application currently has no live instances, the operating system kernel layer will trigger the intervention of the "container management" engine. This action involves three specific steps:

[0067] Image loading: The container management engine pulls the operating system image (Docker Image) corresponding to the application from the underlying image repository.

[0068] Resource allocation: Before launching the container, the container management engine will call the "Distributed Heterogeneous Computing Power Scheduling" module below to allocate a specific host server (such as "Wanka Computing Power Server") to this new instance based on the preset resource quota (such as requiring at least 2 CPU cores, 16G memory, and one A100 graphics card) and the current load of the underlying "intelligent device layer".

[0069] Execution Startup: After allocating physical resources, the container management engine actually starts the container process on the host server and executes the entry startup command for the application instance.

[0070] The operating system kernel layer does not blindly attempt to establish a connection. Instead, it continuously monitors the startup logs of the newly launched application instance through the "System Monitoring" component. Only when the service port exposed by the application instance starts listening, and the readiness probe confirms that it has completed internal initialization and is in a serviceable state, will the operating system kernel layer officially register the new instance's "resource handle" (i.e., container IP and port information) into the operating system kernel layer's internal routing table.

[0071] After the above verification and registration are completed, the operating system kernel layer performs the connection establishment action: establishing a mapping relationship between the current user's session identifier and this newly launched application instance, and feeding back the page routes or data that can be accessed normally to the application interaction layer. Only then can the user start using the application without realizing it.

[0072] This optional embodiment leverages the container management engine and cluster management mechanism built into the operating system kernel layer to provide the system with automated instance lifecycle management capabilities of "dynamically launching on demand and recycling after use." The allocation of underlying resources and the startup of the application instance are only triggered when a user first accesses an application, avoiding the waste of idle computing power and memory caused by all applications residing on the underlying device for a long time. This significantly reduces the underlying resource overhead of cross-device operating systems in multiple application scenarios. At the same time, this dynamic launch process integrates container allocation, computing power scheduling, health monitoring, and routing table registration into an atomic operation. A connection is only established to the user side after the new instance is successfully launched and verified. This ensures that users receive a consistent "ready-to-use" seamless access experience whether they are facing an already launched application or loading an application for the first time, ensuring the immediacy of business response and the elastic scaling capability of the underlying system.

[0073] In one optional embodiment, the heterogeneous computing devices uniformly managed in the underlying resource management layer include: Wanka intelligent computing server, Wanka inference server, Wanka edge computing terminal, embodied intelligent robot, industrial intelligent equipment, drone, and unmanned vehicle; the operating system core layer is provided with a cross-device driver adaptation module, which is used to realize device discovery, driver loading and network interconnection when the above-mentioned heterogeneous computing devices access the underlying resource management layer.

[0074] In this embodiment, as Figure 1 As shown in the "Intelligent Device Layer" at the bottom, these physical devices do not belong to the same product line: there are "Wanka Intelligent Computing / Inference Servers" positioned in the central cloud, "Wanka Edge Terminals" positioned at the field, and even completely different forms such as "Embodied Intelligence (Humanoid Robots)," "Industrial Intelligent Equipment," "Drones," and "Unmanned Vehicles." To unify the management of these seemingly unrelated hardware devices, the operating system kernel layer (i.e....) Figure 1 The "operating system layer" is not implemented through manual configuration, but rather relies on the built-in "cross-device driver adaptation module" to dynamically complete the following three steps during system startup and operation:

[0075] 1. Device discovery and attribute detection

[0076] In a real physical network, when any of the aforementioned heterogeneous devices is powered on and connected to a local area network or 5G private network, the "cluster management" module in the "system middleware" of the operating system kernel layer will use standard network probe protocols (such as gRPC probing, MQTT keep-alive heartbeat, or IP-based broadcast discovery mechanisms) to handshake with these devices. After a successful handshake, the system will issue a fingerprint collection command to the device to obtain its hardware-level information, including: hardware architecture (ARM / x86 / RISC-V), chip model (GPU manufacturer and type, AI inference card model), available computing power, existing memory, and operating system type. Subsequently, the system will normalize and encode this information and register it in the operating system's global "device resource list".

[0077] 2. Automated driver loading and adaptation

[0078] Once a device is discovered, it requires a low-level driver from the operating system to be truly controlled. At this point, the "driver management" module at the system kernel level will match the hardware model collected in the previous step. In engineering implementation, the system has a built-in "driver software repository." If the system discovers underlying hardware (for example, a connected embodied intelligent robot using a specific model of motion control chip), and the system has not yet loaded the driver for that chip, the kernel's driver manager will dynamically pull a matching kernel module (such as a .ko driver file in Linux) from the software repository, compile it, or mount it into the operating system's kernel space. After the driver is loaded, the control commands for the hardware device can be truly recognized and transmitted by the operating system kernel.

[0079] 3. Network Interoperability and Protocol Mapping

[0080] Heterogeneous devices not only differ in their underlying instruction sets, but their native control network protocols are also often fragmented. For example, industrial equipment typically uses industrial Ethernet or Profinet protocols, drones and unmanned vehicles often rely on wireless data transmission links, and embodied intelligent robots mostly use self-developed internal buses. To overcome these barriers, the "network management" and "transmission management" modules in the "system middleware" of the operating system kernel layer intervene immediately after the driver is loaded. The system allocates a unified overlay network (such as VXLAN or VLAN) segment to these newly connected devices and starts a protocol conversion agent in the operating system's underlying network protocol stack. Simply put, it encapsulates the underlying data packets of proprietary or proprietary communication protocols of industrial equipment, drones, etc., into standard TCP / IP data packets that the operating system can understand. At this point, regardless of the device's form factor, they all become standard computing nodes that can be routed and accessed in the operating system's underlying network topology.

[0081] This optional embodiment builds a cross-device driver adaptation module at the lower layer of the operating system kernel, seamlessly connecting high-performance servers at the center, near-field edge computing terminals, and various embodied intelligent robots, industrial intelligent devices, and unmanned motion carriers into the same large-scale native operating system. The system eliminates hardware chip-level architectural barriers through an automated device discovery mechanism and dynamically loaded underlying driver management. At the same time, it utilizes a unified network interconnection and protocol mapping mechanism to enable hardware devices with different physical forms and communication protocols to achieve full connectivity of computing power, data, and model channels at the operating system layer. This effectively supports the large-scale native application of the model to be deployed and executed on any connected heterogeneous hardware in a "plug-and-play" manner without additional secondary development.

[0082] In one optional embodiment, the operating system kernel layer performs vectorization processing on the uploaded data, including:

[0083] Identify the original file format of user-uploaded data.

[0084] When a user uploads a file (such as a PDF financial report) through a browser at the application interaction layer, the file stream is passed through the application instance's interface to the "data routing interface" of the operating system kernel layer, and then enters... Figure 1 The "End-to-End Data Governance" module is part of this system. Upon receiving a file stream, this module does not immediately execute large-scale model inference. Instead, it first reads the file header (Magic Number) and file extension from memory to accurately identify the original format of the uploaded data. The code logic typically maintains a preset "whitelist of unstructured files" (e.g., files containing .pdf, .docx, .pptx, .txt, etc.). Once a file is matched to the whitelist, the system automatically switches to the subsequent text extraction process.

[0085] If the original file format is a preset unstructured file format, the system kernel's text parsing component is invoked to extract the text content of the user-uploaded data.

[0086] Once a file is determined to be unstructured, the operating system kernel immediately transfers control to the underlying "system kernel." Figure 1 The "System Kernel" section includes dedicated "File System" and "Operator Optimization" capabilities. The kernel invokes a built-in text parsing component (in practice, it typically integrates trimmed and optimized parsing libraries such as PDFium, LibreOffice, and Apache Tika). This parsing component meticulously removes non-textual interference information such as formatting tags, font control codes, and embedded images from the file, accurately extracting the actual plain text content from the PDF or Word document page by page and paragraph by paragraph, forming a long string of plain text.

[0087] The extracted text content is converted into vectorized data through a preset vectorization encoding model, and a structured knowledge base summary in Markdown format is generated simultaneously.

[0088] After extracting the plain text content, the operating system kernel continues to execute two tasks in parallel:

[0089] Vectorization transformation: The system sends in a plain text stream. Figure 1 It runs in the "Operator Optimization" module of the "System Kernel". This module embeds pre-trained vectorized encoding models (such as Sentence-BERT or BGE model operators). In actual execution, these operators run on the underlying GPU, directly converting the segmented text blocks into multi-dimensional floating-point vector data.

[0090] Markdown summary generation: The system uses the kernel-level rule engine to perform structured cleaning on the extracted plain text according to outline level and paragraph level, and automatically generates a Markdown format summary text with level tags such as # and ##.

[0091] The vectorized data, Markdown structured summaries, and user-uploaded data are associated and stored in a unified database of the underlying resource management layer.

[0092] The final step is to persist the processing results. The operating system issues storage commands through the "data routing interface" to write the three parts of data in a distributed manner. Figure 1 In the underlying "lower-level resource management layer" (or intelligent device layer) storage cluster:

[0093] Original files: stored in the underlying managed file storage system (such as NFS, S3 object storage).

[0094] Vectorized data: Stored in the underlying managed vector database (such as Milvus, Qdrant, etc.).

[0095] Markdown summaries and indexes: stored in a metadata management system.

[0096] During the writing process, the system generates a globally unique file identifier (UUID). This identifier acts as a "pin," firmly linking the three discrete data blocks: the original file, vector data, and Markdown summary. After storing this information in a unified database, any application instance with a connection within the system can directly obtain the complete knowledge unit containing semantic text, typographical summary, and the original file from the operating system's underlying database using this file ID, without requiring each application to repeat the parsing and vectorization process.

[0097] In an optional embodiment, the application instance needs to synchronize data to other application instances, including:

[0098] The application instance sends a data synchronization request to the data routing interface of the operating system kernel layer.

[0099] In this embodiment, after completing part of its business, application instance A triggers a data synchronization event through its internal logic. Instead of actively initiating a specific network socket connection to find B, it packages the data and the target application identifier (such as the target instance's ID or service name) and sends a standard HTTP / gRPC synchronization request to the "data routing interface" exposed by the operating system kernel layer (usually a unified step-by-step endpoint provided by the "system API" of the system middleware layer). Upon receiving the request, the operating system immediately intercepts it at the logic level without directly issuing network commands.

[0100] The operating system kernel layer first calls the security isolation and permission verification component to verify whether the first application instance has cross-instance data sending permissions and target application instance data receiving permissions.

[0101] After the operating system kernel layer intercepts the request, it calls... Figure 1 The underlying verification module corresponding to the "System Security" section on the left is specifically embodied in the "Authentication and Permissions" component of the middleware layer. In actual projects, this component maintains a fine-grained "Cross-Instance Access Control List (ACL)". The verification logic includes, but is not limited to, the following two:

[0102] Outbound verification: Check whether instance A has the permission to "send data" (e.g., whether A is allowed to exchange data with other instances, or whether instance A's current role has exceeded the data sharing quota).

[0103] Inbound verification: Simultaneously check whether the target application instance B has the permission to "receive data" (e.g., whether B is in a normal service state, or whether B has the permission to process this type of data packet).

[0104] Only when both "outbound" and "inbound" double verifications pass will the operating system kernel layer's permission component issue an "authentication passed" pass token to the data forwarding module.

[0105] After the permission verification is passed, the operating system kernel layer encapsulates the data to be synchronized into a data packet that conforms to the system's internal communication protocol and forwards it to the target application instance.

[0106] After obtaining the access token, the data routing interface begins the actual data migration. To prevent data from being tampered with or contaminated during the underlying network transmission across nodes in the operating system, the "network connection" component at the system kernel level intervenes: it strips the external application layer dependencies from the original data payload submitted by application instance A and repackages it according to the "internal system communication protocol" (usually a lightweight RPC protocol based on Protobuf or a custom binary serialization, including header information such as data checksum and message ID).

[0107] After encapsulation, the operating system kernel layer, through the "transmission management" and "network management" modules of the system middleware, transmits the encapsulated data packet transparently through the underlying network interface card (NIC) and precisely pushes it to the physical node (whether it's a server or an edge terminal) where the target application instance B is running. Upon receiving the packet, the operating system translates and parses the internal protocol packet, ultimately restoring it into business data recognizable by the application instance B. The entire process is completely transparent to both the initiating instance A and the target instance B; they don't need to know who is verifying the data or who is encrypting and encapsulating it; they only need to "deliver the request" and "receive the data."

[0108] This optional embodiment constructs a unified data routing interface at the operating system kernel layer and deeply binds it to the built-in security isolation and permission verification components. It forces bidirectional authentication before cross-application data transfer, avoiding data leakage and unauthorized access risks caused by direct connections or exposed interfaces between application instances. This effectively safeguards the bottom line of data security in multi-tenant and multi-application scenarios within the operating system. Simultaneously, after permission verification, the operating system kernel layer uses a unified internal system communication protocol for secondary encapsulation and routing of data packets. This not only shields the differences in heterogeneous network protocols and data formats between underlying application instances, ensuring data consistency and integrity during cross-device and cross-node transmission, but also eliminates the need for upper-layer applications to concern themselves with underlying network links and communication details. This effectively reduces business integration costs and network maintenance complexity in multi-application and cross-device collaborative workflows.

[0109] In one optional embodiment, the operating system kernel layer controls the underlying resource management layer to perform actual computing power operations, including:

[0110] The resource scheduling interface has a built-in heterogeneous computing power scheduling algorithm, which is used to distribute the received computing power calculation tasks or model inference tasks to the optimal target device in the underlying heterogeneous computing power devices for execution.

[0111] During execution, the operating system core layer monitors the computing load of each underlying device in real time, and performs cross-device computing power elastic expansion, load balancing adjustment, and task breakpoint migration according to the task queue status.

[0112] In this embodiment, when an upper-layer application instance initiates a computing or model inference task request to the operating system through the "resource scheduling interface," the lower layer does not immediately randomly assign a device to run the task. Instead, it enters a rigorous engineering scheduling model, as follows:

[0113] The "computing power modeling" module in the operating system kernel layer maintains a dynamic global hardware topology table in the background, which records... Figure 1The hardware parameters of all heterogeneous computing devices at the bottom (such as Wanka intelligent computing servers, edge terminals, and embodied intelligent robots) include, but are not limited to: remaining video memory size, current CPU core utilization, PCIe bus bandwidth, and the health status of hardware accelerator cards. When a task request arrives, the core layer calls the built-in heterogeneous computing scheduling algorithm to match task attributes (whether it has high I / O, whether it depends on a specific operator library, and maximum video memory requirements) with this topology table. Through an optimal matching algorithm with multiple constraints, the most suitable underlying device for executing the task in the current state is finally selected, and the task instruction is actually sent to it.

[0114] Once a task is issued and execution begins, the underlying "resource monitoring" component continuously synchronizes data at a frequency of seconds (or even milliseconds) based on the system status interfaces of each underlying device (such as metrics provided by tools like nvidia-smi). The current computing load percentage, memory usage, and task queue depth of all devices are collected in real time and sent to the central scheduler of the operating system, forming a global real-time load heatmap, providing data for subsequent dynamic adjustments.

[0115] The "elastic scaling" module at the operating system kernel layer incorporates pressure threshold determination logic. When the scheduler detects that the number of backlogged requests in the current task queue exceeds a preset threshold, and the computing power of the currently online devices is nearing saturation, the scheduler proactively sends a scaling signal to the underlying "container management" module. The container management module then starts a new computing power service node from idle or edge-side backup devices (such as switching to a low-load Wanka inference server) using a standard container image and automatically registers it to the operating system's global resource pool. Once the new node is online, the operating system immediately redirects the backlogged tasks to it to alleviate task queuing and congestion.

[0116] During execution, if abnormal fluctuations occur (for example, a previously normally functioning underlying server suddenly experiences a surge in load due to other business processes preempting resources), the operating system's scheduler will detect this load change in real time. It will immediately interrupt the allocation plan for subsequent new tasks to that device and redirect subsequent tasks of the same type to other currently idle devices via network routing. This dynamic adjustment occurs entirely at the routing table level of the operating system, and upper-layer application instances are completely unaware that tasks are actually being scheduled to execute on different physical machines.

[0117] "Task breakpoint migration" is a high-level function used when hardware failure warnings occur at the system's lower level or when proactive maintenance is performed. For example, if the operating system detects a hardware risk on a device (such as an impending GPU memory failure or the need for physical removal for maintenance), the scheduler will not directly and abruptly kill the running task. Instead, it will capture the task's current model inference context (i.e., a checkpoint snapshot, often referred to in engineering, containing the current inference progress and already loaded model weight parameters) in real time via the underlying network connection, and then transmit this snapshot along with the task status to the target migration device. After loading the snapshot, the target device will directly continue the computation on the original progress and return the result. The entire interruption and recovery process is completed quickly at the lower level, achieving "completely seamless" hot migration to the upper business layer.

[0118] This optional embodiment integrates automated computing power scheduling and elastic management capabilities within the resource scheduling interface of the operating system kernel layer. This enables the large-scale operating system to accurately distribute tasks to the optimal computing power nodes for execution based on the real-time load heat map of the underlying heterogeneous devices when dealing with massive concurrent computing power requests. This significantly improves the utilization efficiency of heterogeneous computing power devices such as the underlying multi-card cluster, edge terminals, and various embodied devices.

[0119] In an optional embodiment, the operating system core layer further includes system middleware components and system kernel components.

[0120] like Figure 1 As shown, the operating system core layer is clearly divided into two layers: "system middleware" and "system kernel," which play the roles of "scheduling corridor" and "hardware base," respectively.

[0121] The system middleware components include a container management module, a cluster management module, a network management module, an authentication and permission management module, and a log monitoring module, which are used to provide upper-layer application instances with runtime environment isolation, underlying resource cluster status monitoring, internal network communication, unified authentication, and abnormal log tracing capabilities.

[0122] Figure 1 In actual deployment, the "system middleware" is a cluster of PaaS-level microservices running on the underlying physical machines. Its core components include:

[0123] Container management module: In engineering, this is typically encapsulated based on Kubernetes and CRI (Container Runtime Interface). It doesn't directly handle hardware but is responsible for the entire lifecycle of the "application instance," such as according to... Figure 1 The "one-click install" and "one-click backup" commands in the software can be used to pull container images, schedule Pods, and start and stop containers.

[0124] Cluster Management Module: This is the "resource ledger" of the entire middleware. It maintains a global hardware resource topology table in the background, recording... Figure 1 Real-time survivability of all smart devices at the bottom. This module works in conjunction with... Figure 1 The "System Monitoring" feature polls the health status of underlying devices every second.

[0125] The network management module is responsible for decoupling the dependency between application instances and the underlying physical network. Based on CNI (Container Network Interface) technology, it assigns an independent Overlay network IP to each launched application instance and implements cross-node, cross-device service discovery and internal network communication at the middleware level. When the data routing interface needs to forward data, it actually uses the internal channels maintained by this network management module.

[0126] Authentication and Access Control Module: Acts as the "unified entry gateway" of the operating system. Every operation command from the application interaction layer is first parsed in this module to verify whether the current operation carries valid credentials. It is based on... Figure 1 The requirement of the "multi-user system" is to manage which users can open which applications, and to make the final judgment on whether application instance A can send data to B.

[0127] Log monitoring module: In actual deployments, it is often integrated with the Prometheus monitoring system and the EFK (Elasticsearch, Fluentd, Kibana) log stack. It continuously gathers information on the underlying hardware's computing load, network anomalies, and application instance runtime anomalies, converging them to the central dashboard at the operating system kernel level. Figure 1 The "System Log" and "System Evaluation" sections provide upper-level operations and maintenance personnel with the ability to trace abnormal logs.

[0128] The system kernel components include a driver management module, a file system module, an operator optimization module, and a model migration module, which are used to directly interface with the hardware characteristics of the underlying heterogeneous computing devices and perform underlying system-level adaptation.

[0129] In this embodiment, Figure 1 The "system kernel" below is closer to the actual physical hardware. In engineering, it is often the host operating system (such as a heavily customized Linux system) and its kernel-mode extensions.

[0130] Driver management module: This is the first line of defense for hardware integration. When Figure 1When the underlying "embedded intelligent device" or "multi-card computing power server" is powered on and online, the kernel driver management will dynamically match the corresponding GPU driver or dedicated accelerator card driver in the "software repository" based on the hardware ID reported by the hardware bus (such as PCIe), and dynamically load the driver into the kernel space to ensure that the hardware chip can be recognized and called by the upper-layer system.

[0131] File system module: Provides underlying data persistence capabilities. It interfaces with the project... Figure 1 The "Storage Management" and "Remote Mount" functions mount the underlying block storage and distributed storage (such as Ceph and HDFS) into a unified file system directory that is readable and writable by the operating system, thus shielding the differences between the underlying hard drives, SSDs, or distributed NAS.

[0132] Operator optimization module: This is a performance foundation unique to the native operating system for large models. During actual large model inference, this module optimizes the underlying GPU architecture (such as NVIDIA's Tensor Cores or CUDA Cores) based on its characteristics. Figure 1 The deep learning computation graphs issued by mid-to-high-level applications undergo low-level compilation optimization (e.g., pre-compiling TensorRT operators or dynamically generating optimal assembly instructions) to ensure that the hardware computing power is fully utilized.

[0133] Model migration module: This part of the project often encapsulates high-performance RDMA network communication components or model snapshot tools. When the operating system's computing power scheduling module requires moving a large model instance from one Wanka server to another edge terminal, it is the underlying kernel "model migration" module that directly takes over the snapshotting, cross-node transfer, and state restoration of the underlying memory and video memory data.

[0134] In actual operation, the system middleware and kernel are not isolated. Requests from upper-layer application instances first hit the authentication and authorization module. After approval, if computing power is required, the container management module schedules resources. The container management module, through the cluster management module, locks onto the specific physical node, then calls the kernel driver management module to grant permissions to the corresponding GPU, and finally, the operator optimization module performs the computation. During data transmission, the network management module encapsulates the protocol packets and transmits them down to the kernel's file system module for final disk persistence. The entire process has a clear division of labor and well-defined boundaries.

[0135] This optional embodiment constructs a highly decoupled, responsibility-isolated dual-plane architecture by clearly dividing the operating system core layer into a system middleware layer that provides management and resource scheduling, and a system kernel layer that directly interfaces with hardware characteristics. The system middleware provides a standardized operating environment and internal communication channels for multiple application instances through container management, cluster management, and network management modules, avoiding direct dependence of upper-layer large-scale applications on the underlying physical network topology and hardware quotas. The system kernel, on the other hand, relies on driver management and file system modules to achieve unified management of heterogeneous underlying hardware such as Wanka intelligent computing servers and embodied intelligent devices across brands and forms.

[0136] In one optional embodiment, when a user controls the application instance to initiate a computing task through the connection relationship, the computing task includes model training, model fine-tuning, and model inference tasks for a large model; when the user initiates an interaction as a data access request, the application instance sends a query instruction to the operating system kernel layer by calling the resource scheduling interface, and the operating system kernel layer performs data retrieval or vector similarity matching in the unified database and returns the retrieval results to the application instance.

[0137] In this embodiment, when a user manipulates an application instance through their exclusive connection (session credentials), the underlying logic of the application instance will have a built-in "unified instruction distribution agent". This agent does not distinguish between task types itself, but directly initiates a general RPC (Remote Procedure Call) or HTTP request to the operating system's "resource scheduling interface". After receiving this standard request, the operating system kernel layer will accurately route it to different engine modules based on the "task type identifier" carried in the payload header.

[0138] If the user-initiated command involves large-scale model computation (e.g., requiring the system to fine-tune based on a dataset, or triggering real-time action inference for a robot), the application instance encapsulates the user-configured hyperparameters, dataset path index, and target model version number into a standard "training-inference task package" and sends it to the interface. Upon recognizing the "training-inference" type identifier, the operating system kernel layer immediately transfers control to [the relevant entity / processor]. Figure 1 The "Multimodal Model Training and Push Management" module (specifically corresponding to...) Figure 1 This module integrates sub-functions such as model training, model adaptation, model inference, and model evaluation. Figure 1 The "Distributed Heterogeneous Computing Power Scheduling" module searches for currently idle computing power in underlying Wanka intelligent computing servers or embodied intelligent devices. After finding the target hardware, the "Operator Optimization" module of the operating system kernel will call the GPU driver of that hardware, start the model instance to perform specific matrix multiplication and parallel computation, and return the generated checkpoint (weight breakpoint) or inference results back to the application instance via the original Reuters.

[0139] If the user-initiated interaction is a query for business data (e.g., searching for "troubleshooting solutions for product XX" in a knowledge base), the application instance only needs to encapsulate the user's natural language query statement (or the feature map to be matched) into a "data query package" and send it to the "resource scheduling interface." Once the operating system kernel layer recognizes the "data query" identifier, it directly forwards the request to the relevant department. Figure 1 The "End-to-End Data Governance" module in the document.

[0140] To improve retrieval efficiency, the operating system kernel layer does not directly input user queries into MySQL for fuzzy matching. In actual projects, it first calls the underlying kernel's "operator optimization" component, using the same vectorization model as during storage, to synchronously convert the user's query text into query vectors in real time. Subsequently, this query vector is compared with the "vector library" in the underlying unified database using high-dimensional inner product calculations or cosine similarity matching to find the top-K most semantically similar data. In addition to vector matching, if the query involves structured conditions (such as time or department), this module also collaborates with the metadata management system for joint filtering. Finally, the operating system returns the original file or Markdown summary of the matched records to the application instance.

[0141] In this implementation, application instances don't need to worry about whether computing tasks require GPU allocation or I / O tasks require quantitative indexing. It only recognizes a single "resource scheduling interface." After the instruction is issued, the operating system, within the core layer, guides the process to either "multimodal model training and push management" or "end-to-end data governance" based on the specific task intent. If computing devices are fully loaded and queued, data query tasks will not time out due to computing power congestion. The operating system will use an underlying multi-task asynchronous processing mechanism to ensure that these two types of tasks proceed independently without interference.

[0142] This optional embodiment uses the operating system's unified resource scheduling interface as a universal interaction intermediary between upper-layer application instances and the underlying execution engine. This enables logical splitting and efficient parallel processing of computing tasks and data retrieval tasks at the operating system's underlying layer. Upper-layer application instances do not need to develop and integrate different GPU inference frameworks or database query middleware. They can drive the system to perform heavy computing tasks such as large model training, fine-tuning, and inference, as well as complex data retrieval operations that rely on vector similarity matching, relying solely on a standardized interface specification. This significantly reduces the development and maintenance threshold for application instances in multiple application scenarios. At the same time, after receiving a query command, the operating system core layer actively performs real-time vectorization of the user input data at the underlying layer and performs inner product matching with the vector library in the unified database. Combined with the underlying heterogeneous computing power scheduling mechanism, the system can efficiently call upon the underlying computing power to meet the computing requirements of retrieval when responding to frequent data access requests, without requiring additional context state synchronization for upper-layer application instances. This fundamentally achieves "seamless service" for upper-layer applications, further improving the resource call efficiency and business response timeliness of the operating system under mixed business loads.

[0143] In one optional embodiment, the unified database of the underlying resource management layer includes a vector database, a file storage system, and a metadata management system;

[0144] The operating system core layer stores the vectorized data generated by vectorization processing in the vector database, stores the original uploaded file in the file storage system, and records the association index information, user ownership information, and version information between the vectorized data and the original uploaded file in the metadata management system.

[0145] In this embodiment, when a user initiates a search through an application instance, the operating system kernel layer first compares similar content in the vector database and obtains the content's ID. Then, based on this ID, it searches the metadata management system to find out "which user and which version" this data belongs to. Finally, based on the found path, it retrieves the original file from the file storage system and returns it to the user. Without the "metadata management system" as an intermediary, the scattered vector data and the original file would just be a bunch of uncorrelated gibberish.

[0146] In an alternative embodiment, in the traditional mode, if there are two AI applications (e.g.) Figure 1 If both "Smart Operations and Maintenance" and "Smart Office" in the system require the use of the "Llama3-70B" large model, each will independently load a complete 70B model parameter on its underlying computing device. This will instantly consume nearly 280GB (70B*2) of video memory, resulting in a huge waste of computing power. Based on the above problem, the following solution is provided:

[0147] When any application instance initiates a model inference request to the operating system kernel layer, the operating system kernel layer, based on the session identifier and inference prompt carried in the request, calls a pre-loaded shared large model base weight base in the video memory of the underlying resource management layer, and dynamically allocates a dedicated context cache space for the session identifier. At the same time, it loads the dedicated lightweight fine-tuning adapter weight corresponding to the application instance onto the shared large model base weight base as needed. The operating system kernel layer controls the underlying heterogeneous computing power devices to perform model inference based on the combined shared large model base weight base, the dedicated lightweight fine-tuning adapter weight, and the dedicated context cache space. After the inference is completed, it clears or releases the video memory context corresponding to the session identifier to release computing power resources.

[0148] In this embodiment, when the operating system kernel layer starts up, or when it receives the inference request of the first application instance, the operating system kernel layer controls the underlying resource management layer to load only one "large model base weight file" in the video memory (GPU). This base weight (Base Model) is set as a "read-only" shared memory segment at the underlying level, and resides in the graphics card as a common model base.

[0149] When a user initiates an inference task through any application instance (such as "Digital Employee"), the application instance only needs to send a request to the "Resource Scheduling Interface" at the operating system kernel layer. The request not only contains a prompt, but also carries a unique identifier for the current session (Session ID) and an application-specific lightweight fine-tuning adapter (LoRA weight) identifier.

[0150] Upon receiving the request, the operating system kernel layer does not launch a new model instance. Instead, it performs operations directly on the underlying common "large model base weight file."

[0151] Context isolation: The core layer dynamically allocates a small dedicated KV Cache in the underlying video memory for the user's session ID, which is used to record the historical state of the user's current conversation.

[0152] On-demand mounting: At the same time, the system kernel's "operator optimization" module will load a very small, application-specific LoRA fine-tuning weight (usually only 1% to 2% of the basic model) from the storage of the underlying resource management layer according to the application identifier, and then superimpose it on the underlying computing power device.

[0153] The underlying computing devices execute actual model inference using a combination of a "common base model + dedicated LoRA fine-tuning + dedicated KV cache". This allows multiple application instances to share the same massive underlying model, but each occupies a very small amount of GPU memory and has its own independent historical dialogue context.

[0154] By building a shared large model foundation weight base at the operating system kernel layer, the redundant and competitive barriers of GPU memory caused by "each application independently loading the large model" in traditional multi-application scenarios are fundamentally broken. The operating system only needs to load the basic large model weights globally once at the underlying level. It can then use the on-demand mounting of dedicated lightweight fine-tuning adapters (LoRA) and dynamic allocation of session-level context cache (KV Cache) to enable any number of upper-layer application instances to obtain completely independent and context-isolated high-quality large model inference capabilities without repeatedly occupying massive amounts of GPU memory. This greatly reduces the hardware resource overhead of expensive GPU memory on the native cross-device operating system for large models when supporting multiple AI services simultaneously, and realizes high-density sharing and on-demand reuse of large model computing resources under multiple services.

[0155] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A large-scale native cross-device operating system, characterized in that, include: The application interaction layer is used to provide a unified user interface and application access point to multiple users through a browser. The operating system core layer is deployed below the application interaction layer and is configured to maintain and run multiple application instances at the bottom layer. Each application instance corresponds one-to-one with the application provided by the upper layer and is used to implement the functions of the corresponding application. The underlying resource management layer is deployed below the operating system kernel layer and configured to uniformly manage heterogeneous computing devices and storage databases at the underlying level. The operating system kernel layer is also configured with a resource scheduling interface and a data routing interface; When any user opens the corresponding application through the application interaction layer, the operating system core layer establishes a connection between the user and the application instance; The application instance supports establishing connections with multiple users simultaneously. When a user controls the application instance to initiate data interaction or computing power calculation tasks through the connection relationship, the application instance interacts with the operating system core layer by calling the resource scheduling interface. The operating system core layer controls the underlying resource management layer to perform actual computing power calculation or data access operations and returns the execution results to the application instance, which then feeds back to the application interaction layer. When the application instance needs to synchronize data to other application instances, the application instance sends the data to be synchronized to the data routing interface of the operating system kernel layer, and the operating system kernel layer forwards the data to be synchronized to the target application instance. When any user uploads data through the application instance, the operating system kernel layer vectorizes the data and stores it in the unified database of the underlying resource management layer, so that all application instances with established connections can access the data through the operating system kernel layer.

2. The native cross-device operating system for large models according to claim 1, characterized in that, The operating system kernel layer establishes the connection between the user and the application instance, including: The operating system kernel layer assigns a unique session identifier to the current user and establishes a mapping relationship between the session identifier and the runtime resource handle of the current application instance; When the same application instance is accessed by multiple users at the same time, the operating system core layer establishes a mapping relationship for each user and performs logical isolation protection on the interaction data and task status of each user at the underlying level based on the session identifier of each user.

3. The native cross-device operating system for large models according to claim 1, characterized in that, When any user opens the corresponding application through the application interaction layer, the operating system kernel layer, before establishing the connection relationship, includes: If the application instance corresponding to the target application is not yet running at the underlying operating system, the operating system core layer dynamically starts a new application instance based on the container management engine of the middleware layer, and establishes the connection between the user and the new instance after the new application instance is successfully started.

4. The native cross-device operating system for large models according to claim 1, characterized in that, The heterogeneous computing devices uniformly managed in the underlying resource management layer include: Wanka intelligent computing servers, Wanka inference servers, Wanka edge computing terminals, embodied intelligent robots, industrial intelligent equipment, drones, and unmanned vehicles; the operating system core layer is equipped with a cross-device driver adaptation module, which is used to realize device discovery, driver loading, and network interoperability when the above-mentioned heterogeneous computing devices access the underlying resource management layer.

5. The native cross-device operating system for large models according to claim 1, characterized in that, The operating system kernel layer performs vectorization processing on the uploaded data, including: Identify the original file format of user-uploaded data; If the original file format is a preset unstructured file format, then the system kernel's text parsing component is called to extract the text content of the user-uploaded data; The extracted text content is converted into vectorized data through a preset vectorization encoding model, and a structured knowledge base summary in Markdown format is generated simultaneously. The vectorized data, Markdown structured summaries, and user-uploaded data are associated and stored in a unified database of the underlying resource management layer.

6. The native cross-device operating system for large models according to claim 1, characterized in that, The application instance needs to synchronize data to other application instances, including: The application instance sends a data synchronization request to the data routing interface of the operating system kernel layer; The operating system kernel layer first calls the security isolation and permission verification component to verify whether the first application instance has cross-instance data sending permission and target application instance data receiving permission. After the permission verification is passed, the operating system kernel layer encapsulates the data to be synchronized into a data packet that conforms to the system's internal communication protocol and forwards it to the target application instance.

7. The native cross-device operating system for large models according to claim 1, characterized in that, The operating system kernel layer controls the underlying resource management layer to perform actual computing power operations, including: The resource scheduling interface has a built-in heterogeneous computing power scheduling algorithm, which is used to distribute the received computing power calculation tasks or model inference tasks to the optimal target device in the underlying heterogeneous computing power devices for execution. During execution, the operating system core layer monitors the computing load of each underlying device in real time, and performs cross-device computing power elastic expansion, load balancing adjustment, and task breakpoint migration according to the task queue status.

8. The native cross-device operating system for the large model as described in claim 1, characterized in that, The operating system core layer also includes system middleware components and system kernel components; The system middleware components include a container management module, a cluster management module, a network management module, an authentication and permission management module, and a log monitoring module, which are used to provide upper-layer application instances with runtime environment isolation, underlying resource cluster status monitoring, internal network communication, unified authentication, and abnormal log tracing capabilities. The system kernel components include a driver management module, a file system module, an operator optimization module, and a model migration module, which are used to directly interface with the hardware characteristics of the underlying heterogeneous computing devices and perform underlying system-level adaptation.

9. The native cross-device operating system for the large model as described in claim 1, characterized in that, When a user initiates a computing task by controlling the application instance through the connection relationship, the computing task includes large model training, model fine-tuning, and model inference tasks; when the user initiates an interaction as a data access request, the application instance sends a query command to the operating system kernel layer by calling the resource scheduling interface, and the operating system kernel layer performs data retrieval or vector similarity matching in the unified database and returns the retrieval results to the application instance.

10. The native cross-device operating system for the large model as described in claim 1, characterized in that, The unified database of the underlying resource management layer includes a vector database, a file storage system, and a metadata management system. The operating system core layer stores the vectorized data generated by vectorization processing in the vector database, stores the original uploaded file in the file storage system, and records the association index information, user ownership information, and version information between the vectorized data and the original uploaded file in the metadata management system.

Images