A ComfyUI front-end page loading method and system

Abstract

The application provides a ComfyUI front-end page loading method and system, which is suitable for a multi-service architecture, the multi-service architecture comprising a first service for front-end display and at least one second service for model inference, the first service and the second service being separately deployed, and the method comprising: deleting a local model folder of the first service and causing a backend interface to stop returning model data to the front end; in response to a model selection operation in a ComfyUI front-end page, calling a model list interface provided by a backend of the first service to obtain a model list, and displaying a custom model selection pop-up window on the ComfyUI front-end page based on the model list; and in response to a model selection operation of a user in the custom model selection pop-up window, transmitting identification information of a selected target model to the second service, and loading the target model by the second service according to the identification information to perform inference. The application improves the loading speed of the ComfyUI front-end page.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence front-end interaction technology, specifically to a ComfyUI front-end page loading method and system. Background Technology

[0002] With the rapid iteration of AIGC (Artificial Intelligence Generated Content) technology, diffusion models such as Stable Diffusion and Flux are widely used in image and video generation scenarios. ComfyUI, a front-end tool based on a node-based visual programming paradigm, has become a core choice for professional creators building complex generation workflows due to its modularity and high customizability. Currently, ComfyUI is widely integrated into various AIGC creation and sharing platforms, handling the workflow editing, saving, previewing, and loading needs of a massive number of users, serving as an important bridge connecting ordinary users and professional AIGC technology. However, in practical applications, the ComfyUI front-end page loading process suffers from a significant efficiency bottleneck, which has become a core technical pain point restricting user interaction experience and improving creation efficiency. The difficulties and complexities mainly manifest in the following aspects: As the number of basic models and LoRA fine-tuning models continuously increases, the amount of model data returned by the back-end interface during ComfyUI front-end loading expands dramatically, typically reaching 60-80MB. This data contains metadata about all available models (such as filenames, paths, preview images, etc.), which the front-end needs to load and render into the model selector all at once, resulting in a significant increase in page load time. In actual application testing, when opening a workflow, loading and rendering the model data alone takes a lot of time, seriously affecting the continuity of the user's creative process.

[0003] To address the aforementioned technical pain points, some preliminary optimization attempts have emerged within the industry. Currently, the mainstream optimization approach involves data trimming at the backend interface level, returning only node information and omitting model information to compress the amount of data returned. However, this method still relies on a single ComfyUI service architecture and cannot fundamentally decouple frontend display from model inference. Model data still needs to exist in some form on the frontend, resulting in limited improvements in loading speed.

[0004] Therefore, there is an urgent need for a ComfyUI front-end page loading method and system that can completely separate front-end model data at the architectural level, thereby significantly reducing the amount of model data loaded during front-end page loading and improving loading speed. Summary of the Invention

[0005] In view of this, it is necessary to provide a ComfyUI front-end page loading method and system to solve the technical problem that the existing technology essentially reduces the amount of model data loaded, but the model data still needs to appear on the front end, resulting in a relatively slow loading speed.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a ComfyUI front-end page loading method, applicable to a multi-service architecture, wherein the multi-service architecture includes a first service for front-end display and at least one second service for model inference, wherein the first service and the second service are deployed separately, and the method includes:

[0007] Delete the local model folder of the first service and modify the backend interface of the first service so that the backend interface stops returning model data to the frontend;

[0008] In response to the model selection operation on the ComfyUI front-end page, the model list interface provided by the back-end of the first service is called to obtain the model list, and a custom model selection pop-up is displayed on the ComfyUI front-end page based on the model list; the model list interface is generated according to the model metadata stored in the database.

[0009] In response to the user's model selection operation in the custom model selection pop-up window, the identification information of the selected target model is transmitted to the second service, and the second service loads the target model for inference based on the identification information.

[0010] In one possible implementation, when the ComfyUI front-end page triggers a model selection operation, the front-end of the first service disables the native ComfyUI model selector and does not execute the initialization logic of the native ComfyUI model selector.

[0011] In one possible implementation, the model metadata includes identification information and the model name, but does not include the model file.

[0012] In one possible implementation, the method further includes:

[0013] Obtain and parse the current workflow file to obtain at least one target node type in the current workflow file;

[0014] Obtain the full node library, filter the full node library based on the target node type, and obtain a filtered node set containing only the node metadata corresponding to the target node type;

[0015] The native full node mounting logic of ComfyUI is blocked, and the node mounting method is called to mount the nodes in the filtered node set to the ComfyUI front-end page.

[0016] In one possible implementation, filtering the entire node library based on the target node type includes:

[0017] Iterate through each node in the full node library and extract the type field of each node;

[0018] Match the type field of each node with the target node type;

[0019] If a match is found, the node is added to the filtered node set.

[0020] In one possible implementation, blocking ComfyUI's native full node mounting logic includes:

[0021] Locate the full node mounting logic module in the front-end code of the first service;

[0022] Block the triggering condition for calling the full node mounting logic module and delete the execution path of the original full mounting logic.

[0023] In one possible implementation, if the ComfyUI front-end page includes a node library selection menu, then the method further includes:

[0024] In response to a user clicking on any folder in the node library selection menu, obtain a list of direct child nodes under that folder;

[0025] Attach the nodes from the list of direct child nodes to the area of ​​options to be used, and generate clickable node options;

[0026] In response to the user clicking the clickable node option, the node data of the clickable node option is loaded into the current workflow, and the visual graphics and parameter configuration panel of the clickable node option are rendered in the workflow editing area.

[0027] In one possible implementation, the node data includes node parameters, rendering configuration, and interaction logic.

[0028] In one possible implementation, the step of passing the identification information of the selected target model to the second service, and having the second service load the target model for inference based on the identification information, includes:

[0029] The identification information is encapsulated into a workflow request of the first service, and the workflow request is sent to the second service;

[0030] The workflow request is parsed based on the second service to obtain the identification information;

[0031] Based on the identification information, locate and load the corresponding model file from the local model folder of the second service, and execute the inference task.

[0032] Secondly, the present invention also provides a ComfyUI front-end page loading system, suitable for a multi-service architecture, wherein the multi-service architecture includes a first service for front-end display and at least one second service for model inference, wherein the first service and the second service are deployed separately, and the system includes:

[0033] The first service deployment unit is used to delete the local model folder of the first service and modify the backend interface of the first service so that the backend interface stops returning model data to the frontend.

[0034] The model selection pop-up display unit is used to respond to the model selection operation on the ComfyUI front-end page, call the model list interface provided by the backend of the first service to obtain the model list, and display a custom model selection pop-up on the ComfyUI front-end page based on the model list; the model list interface is generated according to the model metadata stored in the database;

[0035] The model loading unit is used to respond to the user's model selection operation in the custom model selection pop-up window, and to pass the identification information of the selected target model to the second service, so that the second service can load the target model for inference based on the identification information.

[0036] The beneficial effects of this invention are as follows: The ComfyUI front-end page loading method provided by this invention completely decouples the front-end and model data at the architectural level by splitting the ComfyUI service into a first service for front-end display and a second service for model inference, deleting the local model folder of the first service, and modifying its back-end interface to stop returning model data to the front-end. Based on this, the model metadata is queried from the database through the model list interface provided by the back-end of the first service. The front-end of the first service only needs to load the model list data, which is typically in the KB range, significantly reducing the data loading volume compared to the 60-80MB of model data required in existing technologies. Simultaneously, the target model's identification information is passed to the second service, which loads the target model for inference based on the identification information. This eliminates the need for the front-end of the first service to load any model files during page initialization. When selecting a model, the user only needs to wait for the transmission and rendering of KB-level data, significantly improving the loading speed of the ComfyUI front-end page.

[0037] Furthermore, this invention separates the front-end display and model inference deployments. The first service does not require the hardware resources (such as high-performance GPUs) needed for model operation; it only needs to meet the requirements of front-end display and scheduling. The second service, on the other hand, can be centrally configured with high-performance computing resources, dedicated to model inference tasks. This architecture allows the two types of services to scale independently. When user traffic increases, instances of the first service can be flexibly added to handle the front-end load. When inference tasks increase, instances of the second service can be independently added to improve computing power. Resource utilization is more rational, and the overall scalability of the system is significantly enhanced. Attached Figure Description

[0038] 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.

[0039] Figure 1 This is a schematic flowchart of an embodiment of the ComfyUI front-end page loading method provided by the present invention;

[0040] Figure 2 A schematic diagram of an embodiment of node loading provided by the present invention;

[0041] Figure 3 For the present invention Figure 2 A schematic diagram of an embodiment of S203;

[0042] Figure 4 A schematic diagram of an embodiment of the clickable node loading provided by the present invention;

[0043] Figure 5 For the present invention Figure 1 A schematic diagram of an embodiment of S103;

[0044] Figure 6 This is a schematic diagram of an embodiment of the ComfyUI front-end page loading system provided by the present invention. Detailed Implementation

[0045] 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 a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0046] It should be understood that the illustrative drawings are not drawn to scale. The flowcharts used in this invention illustrate operations implemented according to some embodiments of the invention. It should be understood that the operations in the flowcharts may be implemented out of order, and steps without logical contextual relationships may be reversed or performed simultaneously. Furthermore, those skilled in the art, guided by the content of this invention, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor systems and / or microcontroller systems.

[0047] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0048] This invention provides a ComfyUI front-end page loading method and system, which will be described below.

[0049] Before describing specific embodiments, the following terms will be explained.

[0050] ComfyUI is an AI front-end interactive tool based on a node-based visual programming paradigm, used to build, edit, and execute AIGC (AI Generated Content) workflows centered around a diffusion model. In ComfyUI, users define the generation process by dragging and connecting different types of nodes. Each node corresponds to a specific functional module, such as model loading, prompt word encoding, and image sampling.

[0051] A service refers to an independently deployed ComfyUI instance. Each instance contains complete front-end code and back-end service programs, referred to below as front-end and back-end. Multiple services interact with each other through communication interfaces.

[0052] The ComfyUI front-end page loading method proposed in this invention is applicable to a multi-service architecture, which includes a first service for front-end display and at least one second service for model inference, wherein the first service and the second service are deployed separately. Figure 1 This is a schematic diagram of an embodiment of the ComfyUI front-end page loading method provided by the present invention, as shown below. Figure 1 As shown, the ComfyUI front-end page loading methods include:

[0053] S101. Delete the local model folder "models" of the first service and modify the backend interface of the first service to stop the backend interface from returning model data to the frontend.

[0054] The backend interface refers to the application programming interface exposed by the backend program of the first service to the frontend, used to respond to various data requests initiated by the frontend. Specifically, after modification, the function of this backend interface is limited to no longer returning any data related to the model file. That is, when the frontend of the first service requests model information, the interface only returns non-model data such as node libraries, or returns null values, thereby blocking the transmission of model data to the frontend from the source.

[0055] Model data refers to model files and their associated information stored in the local model folder of the first or second service. Specifically, model data includes binary model files (such as model weight files with extensions like .safetensors, .ckpt, .bin, etc.), model configuration files, model preview images, model path information, and model metadata. In the traditional ComfyUI architecture, the backend interface of the first service returns the above model data along with the frontend request, and the data volume can reach 60-80MB, causing slow frontend loading. This embodiment of the invention deletes the local model folder of the first service and modifies its backend interface to stop returning model data, so that the frontend of the first service does not load the above model data at all during page initialization, thereby achieving complete decoupling between frontend display and model files.

[0056] S102. In response to the model selection operation on the ComfyUI front-end page, call the model list interface provided by the back-end of the first service to obtain the model list, and display a custom model selection pop-up on the ComfyUI front-end page based on the model list; the model list interface is generated based on the model metadata stored in the database.

[0057] Model metadata refers to lightweight information describing the basic attributes of a model, stored in a database and decoupled from the model file itself. Specifically, model metadata includes, but is not limited to: model identifier, model name (e.g., "SDXL Base1.0" or "LoRA_Style Enhancement"), model type (e.g., base model, LoRA fine-tuning model, ControlNet model, etc.), model preview image (e.g., thumbnail URL or a small Base64 encoded image), model source information, and a brief descriptive text of the model. The model metadata is extremely small, typically only in the KB range, and is accessed by the front-end through a model list interface provided by the first service backend. The front-end renders a custom model selection pop-up based on the model metadata, allowing users to select models without loading the complete model file.

[0058] S103. In response to the user's model selection operation in the custom model selection pop-up window, the identification information of the selected target model is transmitted to the second service, and the second service loads the target model for inference based on the identification information.

[0059] Specifically, the identification information can be the model ID, the model file name, the model's primary key value in the database, or the relative path of the model in the local model folder in the second service.

[0060] It should be noted that the custom model selection pop-up can be closed after the user has selected a model.

[0061] It should be understood that the ComfyUI front-end page loading method in this embodiment of the invention can be implemented in an AI creation platform or cloud computing management system based on the ComfyUI front-end page loading method, such as the resource scheduling server of an AIGC creation platform, a cloud-native application management platform, the front-end service cluster controller of an intelligent computing center, or the gateway node of an enterprise-level AI workflow management system. Specifically, the ComfyUI front-end page loading method is deployed in the storage medium of the aforementioned device as a pre-compiled program module. When the device receives a user access request, a service initialization instruction, or a front-end page loading trigger signal, the program module is invoked and executed, and the ComfyUI front-end page loading method is implemented. This achieves rapid response and resource decoupling throughout the entire process, from front-end page request to lightweight model data loading and from model selection to back-end inference scheduling, significantly improving the user interaction experience and overall system operating efficiency.

[0062] Compared to existing technologies, the ComfyUI front-end page loading method provided in this invention completely decouples the front-end from model data at the architectural level by splitting the ComfyUI service into a first service for front-end display and a second service for model inference, deleting the local model folder of the first service, and modifying its back-end interface to stop returning model data to the front-end. Based on this, the model metadata is queried from the database through the model list interface provided by the first service back-end. The front-end of the first service only needs to load the model list data, which is typically in the KB range, significantly reducing the data loading volume compared to the 60-80MB of model data required in existing technologies. Simultaneously, the target model's identification information is passed to the second service, which loads the target model for inference based on the identification information. This eliminates the need for the first service's front-end to load any model files during page initialization; users only need to wait for the transmission and rendering of KB-level data when selecting a model, significantly improving the loading speed of the ComfyUI front-end page.

[0063] Furthermore, this embodiment of the invention separates the front-end display and model inference deployments. The first service does not require the hardware resources (such as high-performance GPUs) needed for model operation; it only needs to meet the requirements of front-end display and scheduling. The second service, on the other hand, can be centrally configured with high-performance computing resources, dedicated to model inference tasks. This architecture allows the two types of services to scale independently. When user traffic increases, instances of the first service can be flexibly added to handle the front-end load. When inference tasks increase, instances of the second service can be independently added to improve computing power. Resource utilization is more rational, and the overall scalability of the system is significantly enhanced.

[0064] In real-world applications, ComfyUI's native model selector, as an inherent component of the front-end page, is often loaded and initialized by default during page initialization. Even if the front-end subsequently displays a custom model selection pop-up, the native model selector still executes initialization logic in the background, consuming front-end thread resources, increasing page rendering overhead, and potentially conflicting with the interaction logic of the custom pop-up.

[0065] To address this technical problem, in some embodiments of the present invention, when the ComfyUI front-end page triggers a model selection operation, the front-end of the first service disables the native model selector of ComfyUI and does not execute the initialization logic of the native model selector of ComfyUI.

[0066] This invention completely disables the native model selector by limiting the initialization of the native model selector in the first service when a model selection operation is triggered on the ComfyUI front-end page. That is, the initialization logic of the native model selector is completely blocked during the front-end page loading process, preventing the execution of any code paths related to the native selector. This releases front-end thread resources, memory space, and rendering overhead originally occupied by native components. Furthermore, the custom model selection pop-up becomes the only component related to the model selection interaction, avoiding potential hierarchical conflicts between the native selector and the custom pop-up, further shortening the overall loading time of the front-end page, thus further improving loading speed.

[0067] While the above embodiments achieve lightweight loading of front-end model data through a multi-service architecture, a significant efficiency bottleneck still exists in the node mounting process during the actual loading of ComfyUI front-end pages. Specifically, traditional ComfyUI front-ends execute full node mounting logic during page initialization, mounting all available nodes returned by the backend (usually hundreds) to the unused options area of ​​the front-end page at once, regardless of whether these nodes are used by the current workflow. This full mounting process involves the initialization, rendering, and memory allocation of a large number of nodes, accounting for the majority of page loading time. Even after the model data loading volume is compressed, this problem still results in persistently high page loading times.

[0068] To solve this technical problem, in some embodiments of the present invention, such as Figure 2 As shown, the ComfyUI front-end page loading methods also include:

[0069] S201. Obtain and parse the current workflow file to obtain at least one target node type in the current workflow file.

[0070] The current workflow file refers to the structured data file of the node workflow that the user opens, edits, or imports in the ComfyUI front-end page. During the node mounting optimization process, the front-end of the first service parses the current workflow file to extract all the node types that are actually referenced. This information is used as the basis for subsequent node filtering to ensure that only the nodes required by the current workflow are mounted to the front-end page.

[0071] S202. Obtain the full node library, filter the full node library based on the target node type, and obtain a filtered node set containing only the node metadata corresponding to the target node type.

[0072] The full node library contains complete information on all node types supported by ComfyUI, covering basic nodes (such as image loading nodes, CLIP text encoding nodes, sampler nodes, etc.), extended nodes (such as custom nodes added by third-party plugins), and various functional module nodes, typically containing hundreds of node entries.

[0073] Node metadata refers to a lightweight collection of information used to describe a node's basic attributes, functional definitions, and rendering configurations. Specifically, node metadata includes, but is not limited to: node type identifier, node name, node category, node input / output port definitions, node default parameter configurations, node icon or style information, and functional description text. Node metadata is decoupled from the node file itself (such as the corresponding JavaScript code, style files, etc.), and its data size is extremely small, typically only a few kilobytes to tens of kilobytes.

[0074] In this embodiment of the invention, the filtered node set obtained from the full node library is essentially the node metadata set of the nodes required by the current workflow. By performing node mounting based on this metadata, interactive node components can be rendered on the interface without preloading or initializing unused nodes.

[0075] S203: Block ComfyUI's native full node mounting logic, call the node mounting method, and mount the nodes in the filtered node set to the ComfyUI front-end page.

[0076] This invention achieves a shift from full node mounting to on-demand mounting. Specifically, by parsing the current workflow file, the target node types actually used in the workflow are accurately identified. Then, based on the target node types, the full node library is filtered, retaining only the node metadata required by the current workflow to form a filtered node set. Finally, the original full node mounting logic is blocked, and only the nodes in the filtered node set are mounted to the ComfyUI front-end page. Through this design, the front-end no longer performs redundant full node traversal and mounting operations during page initialization, only processing a small number of nodes actually used in the current workflow. The time and resource consumption for node mounting are reduced to a fraction of that of traditional solutions, or even lower. Verification shows that, through the decoupling of the first and second services and the on-demand mounting design, the overall loading time of the ComfyUI front-end page can be reduced from 1-2 minutes to less than 10 seconds, significantly improving the user's response speed in node editing and workflow loading, providing a smooth and consistent creative experience for professional creators.

[0077] In some embodiments of the present invention, such as Figure 3 As shown, step S203 includes:

[0078] S301. Traverse each node in the full node library and extract the type field of each node;

[0079] S302. Match the type field of each node with the type of the target node;

[0080] S303. If a match is successful, the node is added to the filtered node set.

[0081] This invention enables accurate and rapid construction of a filtered node set by matching the type field with the target node type.

[0082] In some embodiments of the present invention, blocking ComfyUI's native full node mounting logic in step S203 includes:

[0083] Locate the full node mounting logic module in the front-end code of the primary service;

[0084] Block the triggering conditions for calling the full node mounting logic module and delete the execution path of the original full mounting logic.

[0085] The full node mounting logic module refers to a piece of program logic in the front-end code of the first service. Its function is to mount all available nodes (full node library) obtained from the back-end to the available options area of ​​the front-end page one by one when the ComfyUI front-end page is initialized, and complete the initialization, rendering and event binding of each node.

[0086] A full-loaded logic module typically manifests as one or more JavaScript functions. Therefore, its location can be determined by searching the front-end source code of the first service and identifying the function names or characteristic code implementations related to node mounting.

[0087] This invention, in one respect, blocks the invocation triggering conditions, preventing the full mounting logic from starting at the source and avoiding unnecessary function call overhead. On the other hand, it removes execution paths as a redundancy safeguard, ensuring that even if undiscovered call paths or abnormal triggering situations exist, the full mounting logic will not perform any actual execution operations. This dual mechanism fundamentally eliminates the occurrence of full node mounting behavior, completely eliminating the performance overhead caused by full node traversal, DOM creation, and event binding during front-end page initialization. This fully guarantees the stability and reliability of the node mounting optimization effect, further improving the loading speed and interactive responsiveness of the ComfyUI front-end page.

[0088] In the process of professional creators building complex workflows, not all nodes are used during page initialization. Users often need to dynamically select and add new nodes from the node library during workflow editing according to their creative intentions. Therefore, in some embodiments of the present invention, the ComfyUI front-end page includes a node library selection menu, which serves as the core entry point for users to interact with node resources.

[0089] In existing technologies, the node library selection menu is usually fully built during the initialization phase of the ComfyUI front-end page. This means that all nodes (including all child nodes under all folder levels) are mounted to the front-end memory at once and a complete DOM structure is generated. When the user clicks on a folder, the front-end only changes the display status of existing node options (such as switching from hidden to visible) instead of dynamically loading node data. This preloading mechanism causes a large number of nodes that are not actually used by the user to occupy memory resources and rendering overhead for a long time. Furthermore, when the user expands deep folders, the large number of nodes may still cause lag.

[0090] To address this technical problem, in some embodiments of the present invention, such as... Figure 4 As shown, the ComfyUI front-end page loading methods also include:

[0091] S401. In response to the user clicking on any folder in the node library selection menu, retrieve the list of direct child nodes under the folder.

[0092] In a specific embodiment of the present invention, the node library selection menu is located on the left side of the ComfyUI front-end page.

[0093] S402. Attach the nodes in the list of direct child nodes to the area of ​​options to be used, and generate clickable node options;

[0094] S403. In response to the user's click on a clickable node option, load the node data of the clickable node option into the current workflow, and render the visual graphics and parameter configuration panel of the clickable node option in the workflow editing area.

[0095] Once the node data is loaded, the user can edit that node.

[0096] It should be noted that: Nodes are only node metadata, containing lightweight display information such as node type identifier, name, icon, and category, used to generate clickable node options. Node data is the complete instantiation data of the node, including node definition, parameter configuration, rendering style, port definition, event binding, execution logic references, etc., used to instantiate the node and load it into the workflow.

[0097] When the user does not click on a clickable node option, only the node metadata needs to be loaded, avoiding the loading of unnecessary complete node data during the browsing stage, optimizing front-end performance, and ensuring the completeness of functionality after the node is added.

[0098] This invention introduces an on-demand node library mounting mechanism, which changes the node library loading behavior from initial preloading to interactive triggering loading. Direct child nodes under a specific folder are dynamically acquired and mounted only when the user clicks on a specific folder, and complete node data is loaded into the workflow only when the user clicks on a specific node option. This significantly reduces front-end memory usage, lowers DOM rendering pressure, makes browsing and selection operations in the node library smoother for users, and further improves page loading speed.

[0099] In a specific embodiment of the present invention, node data includes node parameters, rendering configuration, and interaction logic.

[0100] Node parameters refer to specific configuration items that define the behavior and input / output data of a node during task execution. These are runtime variables that can be adjusted by the user or passed by the system after the node is instantiated. Specifically, they include: the number of sampling steps for the sampler node, the relevance of prompt words, and the sampler type.

[0101] Rendering configuration refers to the style and layout data that defines how nodes are visually presented in the workflow editing area of ​​the ComfyUI front-end page, ensuring that nodes are displayed on the interface in a way that meets user expectations. Specifically, this includes node size and position, node appearance style, etc.

[0102] Interaction logic refers to the program behavior and event handling mechanism that defines how nodes respond to user actions in the ComfyUI front-end page, enabling dynamic interaction between nodes and users. Specifically, this includes node selection and dragging behaviors, such as highlighting a node when clicked, real-time position updates when dragging on the canvas, and box selection responses when selecting multiple nodes in batches.

[0103] In some embodiments of the present invention, such as Figure 5 As shown, step S103 includes:

[0104] S501. Encapsulate the identification information into the workflow request of the first service, and send the workflow request to the second service;

[0105] S502. Based on the second service, the workflow request is parsed to obtain the identification information;

[0106] S503. Locate and load the corresponding model file from the local model folder of the second service based on the identification information, and execute the inference task.

[0107] The model file refers to the binary weight file stored in the local model folder of the second service, which is used to load and execute the generation calculation of the diffusion model in the inference task.

[0108] In summary, the ComfyUI front-end page loading method proposed in this embodiment of the invention constructs a multi-service architecture that includes front-end display services and model inference services. On this basis, it performs dual optimizations of model data stripping and on-demand node mounting, achieving a comprehensive improvement in the performance of ComfyUI front-end page loading. It compresses the ComfyUI page, which originally took 1-2 minutes to display stably, to less than 10 seconds to complete loading, significantly improving the user experience and creative efficiency of professional creators.

[0109] On the other hand, embodiments of the present invention also provide a ComfyUI front-end page loading system, suitable for a multi-service architecture. The multi-service architecture includes a first service for front-end display and at least one second service for model inference, wherein the first service and the second service are deployed separately, such as... Figure 6 As shown, the ComfyUI front-end page loading system 600 includes:

[0110] The first service deployment unit 601 is used to delete the local model folder of the first service and modify the backend interface of the first service so that the backend interface stops returning model data to the frontend.

[0111] The model selection pop-up display unit 602 is used to respond to the model selection operation on the ComfyUI front-end page. It calls the model list interface provided by the back-end of the first service to obtain the model list, and displays a custom model selection pop-up on the ComfyUI front-end page based on the model list. The model list interface is generated based on the model metadata stored in the database.

[0112] The model loading unit 603 is used to respond to the user's model selection operation in the custom model selection pop-up window, and to pass the identification information of the selected target model to the second service, which then loads the target model for inference based on the identification information.

[0113] The ComfyUI front-end page loading system 600 provided in the above embodiments can implement the technical solutions described in the above ComfyUI front-end page loading method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above ComfyUI front-end page loading method embodiments, and will not be repeated here.

[0114] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0115] The above provides a detailed description of the ComfyUI front-end page loading method and system provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A ComfyUI front-end page loading method, characterized in that, Applicable to a multi-service architecture, the multi-service architecture including a first service for front-end display and at least one second service for model inference, wherein the first service and the second service are deployed separately, the method includes: Delete the local model folder of the first service and modify the backend interface of the first service so that the backend interface stops returning model data to the frontend; In response to the model selection operation on the ComfyUI front-end page, the model list interface provided by the back-end of the first service is called to obtain the model list, and a custom model selection pop-up is displayed on the ComfyUI front-end page based on the model list; the model list interface is generated according to the model metadata stored in the database. In response to the user's model selection operation in the custom model selection pop-up window, the identification information of the selected target model is transmitted to the second service, and the second service loads the target model for inference based on the identification information; The method further includes: Obtain and parse the current workflow file to obtain at least one target node type in the current workflow file; Obtain the full node library, filter the full node library based on the target node type, and obtain a filtered node set containing only the node metadata corresponding to the target node type; The native full node mounting logic of ComfyUI is blocked, and the node mounting method is called to mount the nodes in the filtered node set to the ComfyUI front-end page.

2. The ComfyUI front-end page loading method according to claim 1, characterized in that, When the ComfyUI front-end page triggers a model selection operation, the front-end of the first service disables the native model selector of ComfyUI and does not execute the initialization logic of the native model selector of ComfyUI.

3. The ComfyUI front-end page loading method according to claim 1, characterized in that, The model metadata includes identification information and model name, but does not include model files.

4. The ComfyUI front-end page loading method according to claim 1, characterized in that, The filtering of the full node library based on the target node type includes: Iterate through each node in the full node library and extract the type field of each node; Match the type field of each node with the target node type; If a match is found, the node is added to the filtered node set.

5. The ComfyUI front-end page loading method according to claim 1, characterized in that, The blocking of ComfyUI's native full node mounting logic includes: Locate the full node mounting logic module in the front-end code of the first service; Block the triggering condition for calling the full node mounting logic module and delete the execution path of the original full mounting logic.

6. The ComfyUI front-end page loading method according to claim 1, characterized in that, If the ComfyUI front-end page includes a node library selection menu, then the method further includes: In response to a user clicking on any folder in the node library selection menu, obtain a list of direct child nodes under that folder; Attach the nodes from the list of direct child nodes to the area of ​​options to be used, and generate clickable node options; In response to the user clicking the clickable node option, the node data of the clickable node option is loaded into the current workflow, and the visual graphics and parameter configuration panel of the clickable node option are rendered in the workflow editing area.

7. The ComfyUI front-end page loading method according to claim 6, characterized in that, The node data includes node parameters, rendering configuration, and interaction logic.

8. The ComfyUI front-end page loading method according to claim 1, characterized in that, The step of transmitting the identification information of the selected target model to the second service, and the second service loading the target model for inference based on the identification information, includes: The identification information is encapsulated into a workflow request of the first service, and the workflow request is sent to the second service; The workflow request is parsed based on the second service to obtain the identification information; Based on the identification information, locate and load the corresponding model file from the local model folder of the second service, and execute the inference task.

9. A ComfyUI front-end page loading system, characterized in that, The system is applicable to a multi-service architecture, which includes a first service for front-end presentation and at least one second service for model inference, wherein the first service and the second service are deployed separately. The first service deployment unit is used to delete the local model folder of the first service and modify the backend interface of the first service so that the backend interface stops returning model data to the frontend. The model selection pop-up display unit is used to respond to the model selection operation on the ComfyUI front-end page, call the model list interface provided by the backend of the first service to obtain the model list, and display a custom model selection pop-up on the ComfyUI front-end page based on the model list; the model list interface is generated according to the model metadata stored in the database; The model loading unit is used to respond to the user's model selection operation in the custom model selection pop-up window, and to transmit the identification information of the selected target model to the second service, so that the second service can load the target model for inference based on the identification information; The system also includes methods for acquiring and parsing the current workflow file to obtain at least one target node type in the current workflow file; acquiring a full node library, filtering the full node library based on the target node type to obtain a filtered node set containing only the node metadata corresponding to the target node type; blocking ComfyUI's native full node mounting logic, calling the node mounting method, and mounting the nodes in the filtered node set to units of the ComfyUI front-end page.

Images