ComfyUI Node

LLM优化功能

The node that makes an optimized prompt actually travel

By TeutonicMepheles·Created 4 months ago·Updated 3 days ago· 0
LLM优化功能
    • 结果
    • 逐行结果
    ◄applied_text—►
    ◄applied_rows—►

    The display name promises an LLM. The node calls nothing. That contradiction is the entire point of it, and once you get why, this becomes one of the more sensible small nodes in the pack.

    LLM优化功能 (DAELAB.LLMStylePreviewB) has one input, applied_text, and one output, 结果. It executes no model, opens no socket, reads no key. Its own source sums it up: an explicitly approved canvas result, where execution never invokes an LLM.

    The problem it solves

    This pack has a prompt-optimisation flow: you can ask a model - a local one, or your own DeepSeek API key with its own separate cost documentation - to rewrite a prompt cell or a whole column. The suggestions arrive as proposals. You read them, you accept or reject, and accepting is a deliberate human action ("manual apply", in the pack's own words).

    Now imagine the naive version, where the optimiser node sits in the graph and calls out during execution. Every queue spends tokens. Re-queueing because a sampler hiccuped spends again. Worse, the prompt that produced a result is not the prompt that's stored in your workflow, so a week later you can't reproduce the image you liked.

    This node inverts that. The optimiser runs outside the execution path, you approve a specific piece of text, that text gets stamped into the node's input, and the graph consumes exactly what you approved. Reproducible, free to re-run, and the workflow you saved is the workflow you ran.

    Mechanism, such as it is

    applied_text is a multiline STRING. On execution the node trims it, and if it's empty it raises LLM 优化结果尚未应用 - "the LLM optimisation result hasn't been applied yet." That guard is the whole feature: you cannot accidentally wire an un-applied draft into a graph and get a run based on nothing. The failure is loud and early, which is how it should be for a node whose output might be the only prompt in a paid generation.

    If the text is there, 结果 is that string, unchanged. No reformatting, no commentary, no stripping of markdown. That matters if you care what actually reached the model - what you approved is what the encoder sees.

    One tidy consequence: this node is written in the older V1 node style (INPUT_TYPES rather than comfy_api.latest schemas). So unlike the newer table, storyboard and badge nodes in this pack, it imports even on a ComfyUI core that predates the V3 node API. Handy if you're on a frozen install.

    Where to wire it

    结果 is a STRING, so it goes into any prompt socket: a CLIPTextEncode, the pack's GPT Image 2 material-prompt node's base prompt, a table generation column's prompt source, a video node's prompt. The common shape is:

    1. Draft text lives in a primitive or a table cell.
    2. You run the pack's optimiser, review, and press apply.
    3. That approved text lands in applied_text.
    4. 结果 feeds the generation node that actually spends credits.

    Because the text is a static string once applied, ComfyUI caches everything downstream normally. Nothing about this node makes your graph re-run.

    The trade you're making

    Honestly: you lose the "prompt automatically improves every run" behaviour that people install LLM nodes for in the first place. If what you want is a node that rewrites your prompt on the fly, this isn't it - that's the live-LLM pattern described in the usual places, with its own costs and its own failure modes (dirty output, subject drift, tokens per run).

    What you gain is that the graph is a record. The prompt that made the picture is the prompt in the node. For anything client-facing, or anything you'll need to re-render at a different size six months later, that's worth more than the automation.

    The pack's own docs are candid about the cost side: prompt optimisation with your own DeepSeek key is billed to you, per cell or per column, with a dedicated cost note. Keeping the spend on an explicit "optimise" click rather than on every queue is the sane default.

    Install

    cd ComfyUI/custom_nodes
    git clone https://github.com/TeutonicMepheles/ComfyUI-DAELab-Custom-Nodes-Library.git
    

    Restart ComfyUI and refresh the browser tab. The node registers as DAELAB.LLMStylePreviewB with the display name LLM优化功能 under the DAELab/文本 category - a Chinese category label, so look for it there rather than under text. In ComfyUI Manager, search the pack title "ComfyUI-DAELab-Custom-Nodes-Library".

    Clone the whole repository; the node list is assembled in the root __init__.py, so a single node folder on its own won't register anything.

    Gotchas

    If you queue and get LLM 优化结果尚未应用, nothing is broken - you just haven't applied a suggestion yet, or you applied it to a different node instance than the one you queued. The pack's optimiser writes into the specific node you're editing, and cloned nodes don't share state.

    Don't use it as a text joiner. It takes one string and gives it back; concatenation, templating and per-row prompt construction belong to the table's prompt columns, which are built for it.

    And if the output looks like it has leftover markdown or a "Here is your improved prompt:" preamble, that came from the optimiser, not from this node - this node is a pure pass-through. Fix it at the source, or clean it before applying, because nothing downstream will.

    CategoryDAELab/文本

    Inputs (2)

    NameTypeDefaultDescription
    applied_textSTRING—
    applied_rowsoptSTRING—

    Outputs (2)

    NameTypeDescription
    结果STRING—
    逐行结果STRING—