同一份基座模型，按请求选不同 LoRA：vLLM 怎样提供微调服务

团队基于同一个模型训练了几个 LoRA 版本：一个做特定任务，另一个适配不同数据。到提供服务时，是否每个版本都要单独加载一份完整基座？vLLM 的 LoRA 文档，展示了在一份基座之上按请求选择适配器的路径。

这里讨论的是已有权重怎样被应用调用，不是微调训练教程。最终能得到的，是服务里可辨认的适配器名称，应用在请求中指定它，服务按所选配置执行。

先把适配器与基座接起来

官方文档以一个 text-to-SQL LoRA 为例。离线方式中，先取得适配器路径，再用 enable_lora=True 创建基座 LLM，调用 generate 时传入 LoRARequest。

LoRARequest 包含人可辨认的名称、全局唯一 ID 与路径。示例输入给出表结构和自然语言问题，让 SQL 适配器参与生成。这里产生的是查询文本，不是直接连数据库执行的业务动作。

这一步也有前提：文档限定为实现 SupportsLoRA 的模型。一个权重文件能下载，不代表适合任意基座；模型结构、适配器兼容性与各自使用许可都需要对应。

在线服务启动时使用 --enable-lora，并通过 --lora-modules 注册“名称=适配器路径”。官方示例将 SQL 版本命名为 sql-lora。

之后查询 /v1/models，可以看到基座模型和 sql-lora。请求的 model 字段填写 sql-lora，便选择这个适配器；填写基座名，则走基座模型。应用不必把服务器内部文件路径写进每次业务请求，而是使用服务公布的名称。

如果启动时提供多个适配器，就能为不同任务保留独立入口。它们能否与基座及其他适配器并行处理，受 max_loras 等服务级配置影响，不能只看注册了多少名称就推断吞吐。

max_lora_rank 控制允许的最大适配器 rank。官方建议按计划使用的最高 rank 设置，远高于实际需求会浪费内存，还可能影响性能。服务配置因此应跟随真实适配器，而不是统一把参数调到最大。

文档还提供运行时装载与卸载，但明确指出这类功能只适合隔离、完全可信的环境。先在启动时注册需要的适配器，已经能完成本篇的版本选择目标，不必将动态加载端点直接暴露给业务用户。

vLLM 代码采用 Apache-2.0，基座和 LoRA 权重仍各有条件，硬件也要按模型和部署方式选择。对已有微调成果的团队，这个例子把“训练出一个版本”向前推进了一步：版本有名称、能被列出，也能由应用在一次请求中明确选用。