这个问题也是我这两天一直在折腾的问题，现在已经初步有了个眉目。先说结论：
结论是可以，架构是vLLM + qwen3.6-27b-NVFP4（3并行）+ ComfyUI（Qwen-Image-Edit-BF16)
或者vLLM + qwen3.6-27b-FP8（2并行）+ ComfyUI（Qwen-Image-Edit-FP8)

我的提示词是这样的：
我现在要在本地部署vLLM运行qwen3.6-27b来推理Hermes也就是你。在飞书远程工作的同时，还要用到本地的ComfyUI工作流进行文生图或者图改生图，大多是Qwen-Image-2512，少量用到Qwen-Image-Edit，这些模型都在/home/bentonyi/ComfyUI-master/models/unet，你可以自己看。目前的qwen3.6-27b模型情况是有一个NVFP4量化，一个FP8量化。
以上是具体现状，我的底线要求是：
1，任何条件下不能触发把KV Cache放到内存里交换让CPU跑的情况；
2，上下文128k满载、并发2倍冗余以内、mtp种子为4的极端情况下vLLM不得oom；
3，在qwen3.6-27b和comfyUI工作流并行任务期间，假设一旦出现显存吃紧或者占满，崩溃运行失败的只能是comfyUI，vLLM不得受到任何影响（因为我要远程处理，vLLM和hermes必须在线）；
你给我推荐一个建议运行的qwen3.6模型版本，以及相对应vLLM的运行参数（尤其是留足comfyUI工作显存后的推荐并发上限）

这是智力密集型的plan类工作，我直接祭出了deepseek-v4-pro连hermes。中间查硬件，查模型，查量化版本以及把量化的详细过程算给我看的过程就省略了，各位可以以自己的实际情况对应的提示词去deepseek在线问。最后hermes给出了最前面的结论。还给我画了显存分配明细： │
而且已经经过底线验证：

不触发 CPU swap — KV Cache 全在 GPU，48 层 SSM 不吃 KV
128K × 6 并发 × MTP=3 → KV 24 GiB < 预算 30 GiB，不会 OOM
ComfyUI 先崩 — 它的 43 GiB 上限比 vLLM 的 52 GiB 硬限制先到
MTP=4 对本模型的 KV 影响极小（MTP 只有 1 层额外 full_attn，开销 < 100 MiB）
Qwen-Image-Edit BF16 只在切换使用 FP8 版本时可保平安

最后这张图是我的实际测试，显存占用和ds说得几乎一模一样。

抡锤者

benton yi