Runware Embeddings
Embeddings — textual inversion for Runware models, if you've got one
- embeddings
- embeddings
Embeddings are the smallest model type in the whole ecosystem: a vector that teaches the text encoder a new "word" - a face, a style, a season - without touching the diffusion model. This builder is how you attach one to a Runware model node. It's a thin node: you give it a model identifier and a weight, it outputs a RUNWARE_EMBEDDINGS value, and you wire that into a model node's embeddings socket. It's also, honestly, the least-used builder in this pack - only one model node in the catalog exposes that socket - which tells you where embeddings sit in 2026.
The inputs
- model - required STRING. The tooltip calls it a "Textual Inversion (Embedding) model identifier." It's the identifier for an embedding hosted on the Runware platform - not a local
.ptfile. If you don't have a Runware-hosted embedding, there's nothing to put here. - weight - -4 to 4, default 1. How strongly the embedding influences output. Negative weights push away from the concept, which is how people used to build "negative embeddings" - one token standing in for everything you want to avoid.
- embeddings - an input of the same type, so you can chain multiple embeddings together the same way the LoRA builder stacks.
The wider context you should know
The KB's verdict on embeddings is blunt: this technique is remembered for EasyNegative-style negative prompts, and the actual survivors are positive-concept embeddings for a small slice of SDXL derivatives. Two things broke the old uses. First, an embedding is a vector at one specific text encoder's dimensionality - SD 2.0's encoder swap invalidated the entire SD 1.x embedding library overnight, and the modern Qwen/Mistral encoders have nothing a CLIP-trained vector can bind to. Second, on guidance-distilled models (which is most of what people run now), negative embeddings are effectively inert at CFG 1 - there's no unconditional pass to steer. So if you're reaching for this node expecting EasyNegative magic on a modern model, set expectations accordingly: it only does anything if the embedding actually matches the model's encoder.
Output and wiring
Output is RUNWARE_EMBEDDINGS. Wire it into a model node's embeddings socket - check the model actually has one before you build around this.
Install
Standard pack install, once:
cd ComfyUI/custom_nodes
git clone https://github.com/Runware/ComfyUI-Runware
pip install -r ComfyUI-Runware/requirements.txt
Restart, add your Runware API key (Settings → Runware API key, or RUNWARE_API_KEY).
The honest take
You can safely skip this node for 99% of workflows, and that's not a knock on the implementation - it's the state of embeddings. The one case it earns its keep: you have a specific Runware-hosted textual inversion and you want to weight it in or out. Beyond that, the builder exists because the platform supports the feature, and "supports the feature" is doing the heavy lifting in that sentence.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| model | STRING | Textual Inversion (Embedding) model identifier. | |
| weightopt | FLOAT | 1.00-4–4 | Strength of the embedding influence. |
| embeddingsopt | RUNWARE_EMBEDDINGS | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| embeddings | RUNWARE_EMBEDDINGS | — |