ComfyUI and Intel Omni documentation reviewed September 10, 2026. No new image or video was generated for this guide. Workflow support is upstream-documented; local compatibility, quality, and performance remain untested.
Start with one image on one card
A useful first result is an image you can reopen, with the workflow and settings that produced it. Choose one task, one model, and one card before adding video, custom optimizations, or multiple workers. That gives you a small configuration to diagnose when something fails.
ComfyUI documents native PyTorch XPU support for Intel Arc. This establishes an application route; it does not make every third-party node compatible. If a workflow imports a CUDA-only extension, trace that dependency with the porting guide.
Pick an environment
There are two useful starting points: upstream ComfyUI with its Intel requirements, or an Intel Omni environment. Record the exact version before importing workflows.
| Choice | Reviewed status | What to check first |
|---|---|---|
| Upstream ComfyUI | Native XPU route documented | Torch/XPU versions and each required custom node |
| Published Omni image | Release list names 0.2.0-b1 |
Use documentation matching that image |
Current Omni 0.2.0-b2 preview |
Source build only; experimental | Exact source commit, BMG build target and image acceptance output |
Intel’s current Omni README says the b2 preview focuses on single-XPU ComfyUI and has not been published under the corresponding Intel image tag. It points broader multi-XPU scenarios to the older b8 image. The release list and current development instructions therefore describe different artifacts.
For the source preview, the README includes an image acceptance script checking the packaged environment and XPU availability. Retain its output, then run an actual workflow: passing environment checks does not demonstrate model quality or successful generation.
Select a maintained workflow
Follow the Omni ComfyUI guide and the model’s official ComfyUI tutorial for the files and workflow matching your environment. The current source-built image does not bundle the model weights and points users toward maintained upstream templates.
Before launching, collect the workflow JSON, model revisions and hashes, required node revisions, and the model’s usage terms. Keep source assets you are entitled to share. Avoid updating several custom nodes in the middle of a comparison; that creates a different environment.
For the first image, set an explicit seed and save the prompt, width, height, batch size, sampler, scheduler, step count, guidance and precision. If the workflow has additional controls, preserve those too. The same seed is useful bookkeeping, but it does not guarantee identical pixels across different implementations.
Prove that the output is useful
Run once to establish the workflow, then repeat without rebuilding the environment. Inspect the saved files, not just a successful queue status.
| Check | What to retain |
|---|---|
| The intended card performed the work | Device-selection and execution logs |
| The output opens and has the requested dimensions | Original output and file metadata |
| The content responds to the prompt | Prompt/output pairs, including unsuccessful examples |
| Repeated execution completes | Per-run status, timings and errors |
| The workflow can be reconstructed | Workflow JSON, all revisions and any local modifications |
Record first-use time separately from warmed runs. A queue can reuse cached node outputs; if no generation work was performed, its short duration is not a generation benchmark. Deliberately cause the generation stage to execute again and retain enough logs to show which stages ran.
Measure memory and time separately
Save model-loading time, compilation where observed, and completed-workflow time as separate fields. State whether image encoding and file writing are inside the timing window. Keep raw repetitions, then report a median and range with the number of samples.
In the current source preview, Omni’s ComfyUI guide describes an optional DynamicVRAM entrypoint for memory-constrained workflows. It manages weights to preserve headroom and can add overhead when the workflow already fits. Treat it as a separate test configuration, with its reserve setting recorded.
If memory is the problem, change one factor at a time: resolution, batch size, offload behavior, or weight format. Reducing sampling steps changes the task too. A faster result after multiple simultaneous changes cannot establish which optimization helped or whether quality was preserved.
Extend to a short video
Once the image path is understood, select a video workflow explicitly documented for the chosen environment. Save width, height, frame count, frame rate, duration, sampler, steps, model variant, input assets and seed. Keep both the generation log and the encoded clip.
Inspect temporal behavior as well as a thumbnail: motion, flicker, repeated frames and whether the result follows the requested action. State whether encoding and interpolation are included in elapsed time. Changing frame count, resolution or a distilled model changes the comparison.
Our archived fast Wan result combines changed sampling, warm compilation and worker behavior, without a complete public per-run timing record. It is a lead for a new experiment, not a current video-performance claim. A short, fully recorded new run would be more useful than repeating its headline.
Give the second card a defined job
Two independent jobs are a straightforward experiment if each fits one card. Measure total completed work and each job’s latency; do not assume a single image becomes faster. Only attempt splitting with a workflow and environment that explicitly support it. The b2 single-XPU preview is not evidence for that capability.
The two-card guide explains these different uses. Start with one isolated baseline, then record what changes when both cards run. Shared host resources can affect the result.
Share a useful recipe
A community-ready example needs an environment record, workflow JSON, model/source links, settings, original outputs, raw timings, and known failures. Label source previews and local changes as experimental. Keep a first-use result distinct from a repeat-run result and document whether cached stages were reused.
For other routes, the creative resource shelf includes UI and quantization projects. For setup trouble, use the software-stack guide and version-aware troubleshooting log.