张量形状适配器

Somewhere in the ComfyUI ecosystem, a node needs two tensors to have the same feature dimension, and yours don't. TensorShapeAdapter is the pack's universal adapter: it takes tensor_to_align, looks at the last dimension of tensor_reference, and rewrites the first tensor so its feature width matches the second. Output is a TENSOR you can now wire into whatever demanded matching widths.

It's the workhorse that makes this pack's other nodes forgiving - ConditioningConcatenation, TensorPooledMerge, TensorAttentionFusion, TensorCrossAttention, and ConditioningPacker all lean on it internally when two inputs disagree on the feature axis. You'll usually meet it as a dependency, silently fixing dims inside another node, rather than something you place yourself.

But here's the thing you need to know before you trust it: when the widths differ, the alignment is done with a freshly initialized, randomly weighted nn.Linear layer. Not trained, not fitted, not saved - a random projection from the source width to the target width. It makes shapes compatible and data flow onward, and that's all it does. If tensor_to_align already matches the reference width, it's a pass-through and no harm is done. If it doesn't, you get a tensor whose values have been scrambled by an arbitrary linear map. Dimension-legal, semantically meaningless.

That's not a bug; it's a design choice with a specific purpose. This whole pack is built around keeping a graph running while you experiment with embedding shapes - and a random projection is the cheapest way to keep shapes happy without a trained mapping. Just don't mistake "the node didn't crash" for "the alignment means something." If you're doing anything where the projected features actually get used (feeding the result into a sampler via ConditioningPacker, for instance), the random projection is genuinely garbage in, garbage out.

The honest guidance: prefer to match feature widths upstream so this node has nothing to do. When you can't - because two encoders genuinely emit different widths - treat the adapter as a compatibility shim for plumbing, not a transformation whose output you should interpret. If you need real alignment between two different encoders' embeddings, you want an actual trained projection or an embedding model, not a random Linear.

Install

ComfyUI Manager → search comfyui-spawner-nodes → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/spawner1145/comfyui-spawner-nodes

Light pure-Python deps (piexif, pypng, xmltodict), no models. README is a one-liner, UI is Chinese-labeled, author is spawner1145 (also of a Wan2.1 SD extension). Works; documentation is your own.

Troubleshooting

• Output values look scrambled - expected when widths actually differed. Check whether the input width matched the reference; if it did, this node is a no-op and the "scramble" came from elsewhere.
• Unexpected results downstream - you're probably using randomly projected features as real signal. Match dims upstream instead.
• No effect at all - correct behavior when widths already agree. It's a pass-through then.