WorkBuddy 不支持原生多模型并行部署，需通过多个独立 HTTP 服务（如不同端口的 vLLM 实例）封装模型，并在 workflow.yaml 中配置多个 llm_node 指向各自 endpoint；vLLM 单进程不支持多模型，须分实例启动并控制显存与并发参数，同时注意 tokenizer 和 finish_reason 一致性。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
WorkBuddy 本身不支持原生多模型并行部署——它是一个轻量级工作流编排工具，底层调度依赖外部推理服务（如 vLLM、Triton 或本地 transformers + torch.distributed），所谓“多模型并行”实际是通过路由层+资源隔离实现的协同调用。
如何让 WorkBuddy 同时调用多个 LLM 实例
核心思路是把不同模型封装为独立的 HTTP 服务（例如用 vllm.entrypoints.api_server 启多个端口），再在 WorkBuddy 的 workflow.yaml 中定义多个 llm_node，各自指向不同 endpoint：
nodes:
- id: "qwen2-7b"
type: "llm_node"
config:
endpoint: "http://localhost:8001/v1/chat/completions"
model: "qwen2-7b-instruct"
- id: "phi3-4k"
type: "llm_node"
config:
endpoint: "http://localhost:8002/v1/chat/completions"
model: "phi3-mini-4k-instruct"注意：endpoint 必须带完整路径（含 /v1/chat/completions），否则 WorkBuddy 会因 404 失败；且每个服务需绑定不同端口，避免 Address already in use 错误。
WorkBuddy 桌宠工厂 —— 给一张角色图、一个 codex.pet 链接、一条 codex-pets.net 下载 URL、或一份现成的精灵表，就能自动创建一只可联动 WorkBuddy 状态的桌面宠物。当用户说"创建桌宠"、"做一只桌宠"、"用这张图做桌宠"、"从 codex.pet 安装桌宠"、"导入 codex 桌宠 XX"、"装一下 codex-pets.net 上的 XX&quo
为什么不能直接在同一个 vLLM 进程里加载多个模型
vLLM 当前（v0.6.x）不支持单进程多模型共享 GPU 显存——--model 参数只接受单个模型路径，强行传入逗号分隔列表会触发 ValueError: model path must be a string。即使改源码绕过校验，也会因 PagedAttention 缓存结构与模型参数强绑定而崩溃。
- 可行替代：启动多个 vLLM 实例，用
--gpu-memory-utilization 0.45控制每实例显存占用，留出余量给其他模型 - 不可行操作：在
config.yaml中写models: ["qwen2", "phi3"]—— WorkBuddy 不解析该字段，也不会透传给后端 - 验证方式：调用
curl http://localhost:8001/v1/models应只返回一个模型信息
并发请求下如何避免 GPU OOM 和 token 阻塞
关键不在 WorkBuddy，而在后端服务的并发控制策略：
- vLLM 实例必须设置
--max-num-seqs 256和--max-model-len 4096，否则长上下文请求会挤占短请求的 block table 空间 - WorkBuddy 的
concurrency_limit字段只限制 workflow 内部节点调度频次，不控制 HTTP 请求并发数；真实压测时需用--max-num-batched-tokens 8192防止 batch size 爆显存 - 若两个模型共用同一张卡，建议用
CUDA_VISIBLE_DEVICES=0分别启动，并在nvidia-smi中确认Used Memory波动错峰（例如 qwen2-7b 占 12G 时 phi3-4k 控制在 6G 内）
真正容易被忽略的是模型 tokenizer 的一致性：如果两个服务返回的 finish_reason 字段值不同（比如一个用 stop，另一个用 length），WorkBuddy 的默认 parser 会丢弃部分响应；必须在 llm_node.config.parser 中显式指定适配逻辑。
