vLLM-Omni 双卡部署 GLM-ImageAR Diffusion 两阶段图像生成与编辑实战指南【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omniGLM-Imagezai-org/GLM-Image来自 Z.ai是当前 vLLM-Omni 仓库中由社区维护的文本生成图像Text-to-Image与图像编辑Image-to-Image配方模型。本文以 recipes/GLM/GLM-Image.md 为核心骨架结合仓库内的部署配置、管线拓扑与源码实现系统讲解如何在2× A800 80GB上通过 OpenAI 兼容 API 在线服务 GLM-Image并深入剖析其AR 自回归生成 DiT 扩散去噪两阶段架构的底层原理。读完本文你将掌握 GLM-Image 的完整部署命令、T2I/I2I 客户端调用、生成参数调优、显存规划与常见问题排查并能理解 AR 阶段到扩散阶段之间 prior token 的生成、解析与上采样全过程。配方概览与适用场景recipes/GLM/GLM-Image.md 是一份已知可用known-good的部署配方其核心信息如下维度说明VendorZ.aiModelGLM/GLM-ImageTaskText-to-image (T2I) 与 image-to-image图像编辑Mode基于 OpenAI 兼容 API 的在线服务Online servingMaintainerCommunity社区维护目标硬件2× 80GB NVIDIA A800Ampere 架构何时使用该配方当你想在两张 A800 80GB 显卡上以稳定的起点部署GLM-Image并与仓库自带的examples/online_serving/glm_image客户端一起验证部署结果时。默认布局与上游 2×A100 80GB 示例一致Stage 0AR位于 GPU 0Stage 1扩散位于 GPU 1。配方参考文档为 docs/user_guide/examples/online_serving/glm_image.md该指南详细描述了 GLM-Image 在 vLLM-Omni 声明式配置系统中的两阶段支持方式。GLM-Image 两阶段架构原理GLM-Image 并非单一模型而是一个AR自回归 Diffusion扩散的两阶段图像生成管线。管线拓扑与阶段结构声明在 vllm_omni/model_executor/models/glm_image/pipeline.py 中这是一个冻结frozen的PipelineConfigStage 0ARmodel_stagear执行类型LLM_AR模型架构GlmImageForConditionalGeneration约 9B 参数负责多模态理解 prior token 生成。它拥有 tokenizertokenizer_subdirprocessor模型权重位于vision_language_encoder子目录final_outputFalse不是最终输出阶段引擎输出类型为token_ids。Stage 1DiTmodel_stagedit执行类型DIFFUSION对应GlmImagePipeline从 Stage 0 接收输入input_sources(0,)完成扩散去噪与 VAE 解码final_outputTrue、final_output_typeimage是最终图像输出阶段。其自定义输入处理函数指向vllm_omni.model_executor.stage_input_processors.glm_image.ar2diffusion。Stage 0 (AR Model) Stage 1 (Diffusion) ┌───────────────────┐ ┌─────────────────────┐ │ vLLM-optimized │ prior │ GlmImagePipeline │ │ GlmImageFor │──tokens──►│ ┌───────────────┐ │ │ Conditional │ │ │ DiT Denoiser │ │ │ Generation │ │ └───────┬───────┘ │ │ (9B AR model) │ │ ▼ │ └───────────────────┘ │ ┌───────────────┐ │ ▲ │ │ VAE Decode │──┼──► Image │ │ └───────────────┘ │ Text / Image └─────────────────────┘ InputAR 阶段vLLM 优化的条件生成实现AR 阶段的核心实现位于 vllm_omni/model_executor/models/glm_image/glm_image_ar.pyGlmImageForConditionalGeneration约 2852 行由 HuggingFace Transformers 的modeling_glm_image.py适配而来。该文件内部实现了几项值得关注的设计VQ-VAE 量化器优化GlmImageVQVAEVectorQuantizerGLM-Image 的 VQ-VAE 与 Chameleon 不同对输入与码本向量做L2 归一化距离等价于余弦相似度。推理实现用matmul argmax(similarity)替代einsum argmin(distance)数学上等价argmin(2-2·sim) ≡ argmax(sim)并移除了训练专用组件loss、直通估计器、beta 系数。视觉编码器GlmImageVisionModel与 GLM-4V 不同GLM-Image 的视觉注意力不使用 RoPE改用可学习位置嵌入且位置嵌入通过双线性插值而非双三次适配变分辨率patch embedding 使用 2D 卷积无时间维因为 GLM-Image 只处理单张图像。从源码结构看AR 模型实现了SupportsMultiModal、SupportsPP、SupportsMRoPE等接口可支持流水线并行与多模态输入。AR → DiT 过渡prior token 的生成与解析两阶段之间最关键的数据通路由 vllm_omni/model_executor/stage_input_processors/glm_image.py 的ar2diffusion函数实现。理解它需要先弄清楚 GLM-Image 的 token 布局规则compute_max_tokens(height, width, factor32, is_i2iFalse)计算 AR 阶段应生成的 token 总数AR 模型以32 倍下采样生成 tokenfactor32即 1024×1024 图像对应 32×32 1024 个目标 tokenT2I 模式小预览图small preview半分辨率× 大目标图large target× EOS即small_tokens large_tokens 1I2I 模式大目标图 EOS即large_tokens 1无小预览图。_parse_generated_tokens负责从 AR 输出中切出大目标 token去掉末尾 EOStoken id 16385后T2I 从small_image_tokens偏移处取large_image_tokens个 token若 token 数量不足会主动抛错拒绝低质量回退refusing low-quality fallback。_upsample_token_ids则把 32 倍下采样的 prior token 用最近邻插值放大 2 倍到 16 倍下采样因为 AR 模型以 32× 输出而 DiT 期望 16× 下采样的条件 token故 token 数量放大 4 倍。ar2diffusion的完整数据流为取 AR 输出的cumulative_token_ids→ 通过mm_processor_kwargs的target_h/target_w兼容旧的height/width顶层字段确定目标分辨率 → 检测 i2i 模式prompt 的modalities含img2img、multi_modal_data含源图、或 AR 输出了prior_image多模态输出三者任一命中→ 解析并上采样 prior token → 组装 diffusion 输入prompt、height、width、extra.prior_token_ids、可选prior_token_image_ids与pil_image并透传seed、num_inference_steps、guidance_scale、negative_prompt。此外compute_max_tokens中max_tokens被设置为理论最大值2048×2048 T2I ≈ 4353 tokenAR 模型在低分辨率下会自然在 EOS16385处停止远早于该上限——这也是部署配置中注释强调不要按请求覆盖 max_tokens的原因实际分辨率通过target_h/w传递。DiT 阶段扩散去噪与 VAE 解码扩散阶段基于 vllm_omni/diffusion/models/glm_image/glm_image_transformer.pyGlmImageTransformer系列约 1270 行实现它复用了 vLLM 的并行线性层ColumnParallelLinear/QKVParallelLinear/RowParallelLinear与扩散注意力后端。其中validate_glm_image_tp_constraints专门校验张量并行约束dim、num_heads、ffn_hidden_dim 必须都能被 TP size 整除否则会抛出异常并列出支持的所有 TP 候选值由三者约数交集得出——这为后续多卡/多机扩展提供了明确的约束依据。硬件与软件环境要求配方文档针对双 GPU CUDA 布局A800 80GB记录同一软件栈下可参考该布局ROCm / NPU 等更多平台待社区验证落地后补充NPU 平台已在部署 YAML 中预留配置见下文扩展小节。配方记录的环境版本取自一次可用的editable 安装激活vllm-omni/.venv或等价虚拟环境后复现组件版本OSLinuxPython3.12Driver / runtimeNVIDIA CUDA 栈需可见两张 A800 80GB必要时在宿主机设置CUDA_VISIBLE_DEVICESvLLM0.19.0vLLM-Omni0.19.0rc2.dev138g38d5f2d53本仓库 editable 安装Git38d5f2d5git describe≈v0.19.0rc1-138-g38d5f2d5Transformers5.5.4与.venv一致Stage 0 加载glm_image配置所必需重要保持Transformers ≥ 5.5.1本配方使用 5.5.4否则 Stage 0 可能在进行ModelConfig校验时失败——因为 GLM-Image 的 AR 配置依赖 Transformers 侧的glm_image支持。快速部署启动两阶段服务在仓库根目录启动服务vllm serve zai-org/GLM-Image --omni --port 8091--omni必需启用 vLLM-Omni 的多阶段编排能力示例配方与用户指南均强调该 flag。声明式配置系统会自动从模型的model_index.json检测管线因此无需手动指定--deploy-config。如需显式使用仓库内置的部署配置与默认行为一致vllm serve zai-org/GLM-Image \ --omni \ --port 8091 \ --deploy-config vllm_omni/deploy/glm_image.yaml默认布局为 Stage 0AR在 GPU 0、Stage 1Diffusion在 GPU 1。若想将两个阶段合并到单张 GPU用--stage-overrides按阶段覆盖设备vllm serve zai-org/GLM-Image --omni --port 8091 \ --stage-overrides {0: {devices: 0}, 1: {devices: 0}}部署配置文件逐项解读显式部署配置位于 vllm_omni/deploy/glm_image.yaml。配置中省略的字段回退到StageDeployConfigdataclass 默认值见 vllm_omni/config/stage_config.py管线级设置如trust_remote_code、distributed_executor_backend除非在此覆盖否则使用DeployConfig默认值。顶层async_chunk: false关闭异步分块。Stage 0ARGPU 0- stage_id: 0 max_num_seqs: 1 # 图像生成场景单请求批大小 gpu_memory_utilization: 0.6 # 显存利用率OOM 时可下调 enforce_eager: false # 关闭 eager 模式允许 CUDA Graph trust_remote_code: true enable_prefix_caching: false max_num_batched_tokens: 32768 devices: 0 default_sampling_params: temperature: 0.9 # 采样温度 top_p: 0.75 # 核采样阈值 top_k: 16512 # Top-K 截断 stop_token_ids: [16385] # EOS tokenAR 在此自然停止 max_tokens: 4353 # 2048×2048 T2I 的理论上限勿按请求覆盖 seed: 42 # 固定随机种子默认采样参数 detokenize: false # AR 输出 token_ids 而非文本Stage 0 的职责在注释中写得很清楚生成prior_token_ids用于条件化扩散过程。max_tokens设为 2048×2048 T2I 的理论最大值≈4353 tokenAR 模型在低分辨率下会于 EOS16385处提前自然停止。Stage 1DiT VAEGPU 1- stage_id: 1 max_num_batched_tokens: 32768 max_num_seqs: 1 enforce_eager: true # 扩散阶段使用 eager 执行 trust_remote_code: true enable_prefix_caching: false devices: 1 default_sampling_params: seed: 42 num_inference_steps: 50 # 扩散去噪步数默认 guidance_scale: 1.5 # 无分类器引导尺度默认 height: 1024 # 默认输出高度 width: 1024 # 默认输出宽度Stage 1 接收 AR 产生的prior_token_ids执行去噪 VAE 解码。注意两个阶段的采样参数默认值正好与 API 层extra_body中的生成参数形成对应请求未显式指定时使用这里的默认值。客户端调用文本生图与图像编辑服务就绪后可使用仓库内已有的示例客户端examples/online_serving/glm_image或以下标准调用方式。文本生成图像T2Icurl -s http://localhost:8091/v1/chat/completions \ -H Content-Type: application/json \ -d { messages: [ {role: user, content: A photorealistic mountain landscape at sunset} ], extra_body: { height: 1024, width: 1024, num_inference_steps: 50, guidance_scale: 1.5, seed: 42 } } | jq -r .choices[0].message.content[0].image_url.url | cut -d, -f2- | base64 -d output.png图像编辑I2IImage-to-Image在消息内容中通过image_url传入 base64 编码的源图curl -s http://localhost:8091/v1/chat/completions \ -H Content-Type: application/json \ -d { messages: [ { role: user, content: [ {type: text, text: Convert this image to watercolor style}, {type: image_url, image_url: {url: data:image/png;base64,$(base64 -w0 input.png)}} ] } ], extra_body: { height: 1024, width: 1024, num_inference_steps: 50, guidance_scale: 1.5 } } | jq -r .choices[0].message.content[0].image_url.url | cut -d, -f2- | base64 -d output.png从源码角度看i2i 模式的关键在于 glm_image_ar.py 中GlmImageDataParser会将img2img模态归一化为image供管线其余部分统一处理且get_supported_mm_limits声明 i2i 模式最多支持1 张源图作为条件。使用 OpenAI Python SDKfrom openai import OpenAI import base64 client OpenAI(base_urlhttp://localhost:8091/v1, api_keynone) response client.chat.completions.create( modelzai-org/GLM-Image, messages[{role: user, content: A beautiful sunset over the ocean}], extra_body{ height: 1024, width: 1024, num_inference_steps: 50, guidance_scale: 1.5, seed: 42, }, ) img_url response.choices[0].message.content[0].image_url.url _, b64_data img_url.split(,, 1) with open(output.png, wb) as f: f.write(base64.b64decode(b64_data))其他通用请求方式Pythonrequests等可参考 docs/user_guide/examples/online_serving/text_to_image.md 与 docs/user_guide/examples/online_serving/image_to_image.md。生成参数与响应格式生成参数通过/v1/chat/completions时参数放在extra_bodycurl JSON 或 OpenAI SDK 的extra_body关键字参数参见 docs/serving/chat_completions_api.md通过专用端点/v1/images/generations或/v1/images/edits时则作为顶层字段直接传入其中图像尺寸与数量使用size与n而非height/width。参数类型默认值说明heightint1024图像高度像素widthint1024图像宽度像素num_inference_stepsint50扩散去噪步数guidance_scalefloat1.5无分类器引导CFG尺度seedintNone可选随机种子negative_promptstrNone负向提示词注意请求中的height/width会经服务层写入mm_processor_kwargs.target_h/target_w最终由ar2diffusion优先读取源码中Prefer GLM-Image target size from mm_processor_kwargs的注释印证了这一点并向下取整到 32 的倍数参与 AR token 布局计算。响应格式{ id: chatcmpl-xxx, created: 1234567890, model: zai-org/GLM-Image, choices: [ { index: 0, message: { role: assistant, content: [ { type: image_url, image_url: { url: data:image/png;base64,... } } ] }, finish_reason: stop } ], usage: {} }图像以data URLbase64 编码 PNG形式嵌入在choices[0].message.content[0].image_url.url中。从响应中提取图像cat response.json | jq -r .choices[0].message.content[0].image_url.url | cut -d, -f2- | base64 -d output.png配方文档中的验证命令等价于此只是将cat response.json替换为curl ... | jq ...的管道形式。端到端验证与代表性性能数据配方文档提供了一次代表性的离线GLM-Image E2E 运行记录2× A800 80GB其指标如下字段值e2e_requests1e2e_wall_time_ms61,148.679e2e_total_tokens1,300e2e_avg_time_per_request_ms61,148.679e2e_avg_tokens_per_s21.260e2e_stage_0_wall_time_ms24,708.760e2e_stage_1_wall_time_ms33,787.442解读单请求端到端约61 秒50 步推理、1024×1024其中Stage 0AR约 25 秒、Stage 1扩散约 34 秒。该数据展示了 AR 扩散两阶段各自的开销占比AR 阶段负责生成约 1300 个 token含小预览 大目标扩散阶段负责 50 步去噪与 VAE 解码两者耗时接近说明这是一条计算密集型而非访存受限的链路。首次请求可能因模型预热而更慢后续请求会更快见 FAQ。显存需求与 FAQVRAM 规划阶段VRAMStage-0 (AR)~18 GiB KV CacheStage-1 (DiTVAE)~20 GiB合计~38 GiB KV Cache配方在 2× A800 80GB 上的实际观测为Stage 0AR约~38 GiB KV、Stage 1DiTVAE约~20 GiB显存观测与用户指南的理论值略有出入以双卡布局下各自卡的实测为准。两张 80GB 显卡与默认拆分完全匹配留有充裕余量。常见问题遇到 OOM 怎么办下调部署配置中的gpu_memory_utilization。默认 0.6可在 vllm_omni/deploy/glm_image.yaml 中改小# In vllm_omni/deploy/glm_image.yaml, reduce from default 0.6: gpu_memory_utilization: 0.5首次请求慢属于模型预热warmup后续请求会明显加快。Stage 0 启动报 ModelConfig 校验失败检查 Transformers 版本是否 ≥ 5.5.1配方使用 5.5.4。--deploy-config是否需要仅在使用自定义 YAML例如单 GPU 合并部署时才需要显式指定默认部署会自动检测管线。扩展离线推理与 NPU 平台离线推理示例若不想起服务可参考 docs/user_guide/examples/offline_inference/glm_image.md 使用Omni引擎直接生成。其 T2I 示例的核心结构为from vllm_omni.entrypoints.omni import Omni from vllm_omni.inputs.data import OmniDiffusionSamplingParams omni Omni(modelzai-org/GLM-Image) outputs omni.generate( A photorealistic mountain landscape at sunset, sampling_params_list[ omni.default_sampling_params_list[0], # Stage 0 (AR) 使用默认采样参数 OmniDiffusionSamplingParams( # Stage 1 (DiT) 显式指定扩散参数 height1024, width1024, num_inference_steps50, guidance_scale1.5, seed42, ), ], ) outputs[0].images[0].save(output.png)I2I 离线调用只需将 prompt 替换为{prompt: ..., multi_modal_data: {image: input.png}}字典。该示例印证了两阶段采样参数需要分别提供的接口设计——这与部署 YAML 中两个 stage 各自独立的default_sampling_params完全对应。NPU 平台预留配置vllm_omni/deploy/glm_image.yaml 底部还包含 NPU 平台的platforms.npu配置段当前配方文档声明社区验证落地后补充ROCm/NPU 平台仓库中已预留该布局Stage 0 使用NPUARWorkerOmniARScheduler、tensor_parallel_size: 4并开启前缀缓存与async_schedulingStage 1 扩散阶段使用sequence_parallel_size: 4、ulysses_degree: 4且两个阶段分别配置了独立的 HCCL 通信端口区间23000-23399 / 24000-24399以避免多进程共享 NPU 时的端口冲突。这为在昇腾 NPU 上复现双卡 GLM-Image 部署提供了现成的起点。小结GLM-Image 在 vLLM-Omni 中的落地体现了声明式配置系统对AR 扩散异构两阶段管线的完整支持管线拓扑冻结在 pipeline.py部署旋钮集中在 glm_image.yamlAR→DiT 的数据转换由 ar2diffusion 完成含 32×→16× 的 prior token 上采样、T2I/I2I 模式识别与 token 布局解析。按照本文步骤在 2× A800 80GB 上运行vllm serve zai-org/GLM-Image --omni --port 8091即可获得开箱即用的 OpenAI 兼容图像生成服务在此基础上可通过extra_body调整分辨率、步数与 CFG 尺度通过gpu_memory_utilization与--stage-overrides适配显存与拓扑并借助仓库中的离线示例与 NPU 预留配置向更多场景扩展。【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考