vLLM多LoRA服务：基础模型共享、适配器命名与租户隔离

先检查适配器是否真的兼容

LoRA不是独立完整模型，必须对应基础模型架构、词表与训练版本。两个文件夹都有adapter_config.json，并不表示可以挂在同一个基础模型上。本文以vLLM 0.18.0为接口示例，假设你已经拥有两份合法获得、针对同一Qwen3-8B基础revision训练的适配器。示例路径不是提供下载的真实模型，不应空建目录后直接运行。

适配器适合部门任务或风格调整，不是数据访问控制机制。某个租户选择自己的LoRA，并不能阻止底层检索读取别人的文件。鉴权、知识库权限与日志隔离仍由业务层承担。

对照基础模型和配置

python -m json.tool /srv/adapters/support/adapter_config.json
python -m json.tool /srv/adapters/engineering/adapter_config.json
find /srv/adapters -name 'adapter_model.safetensors' -exec sha256sum {} \;

重点检查base_model_name_or_path、r、target_modules和词表变化。名称相同但revision不同也可能产生质量差异。若训练时增加了token或保存额外模块，需要确认推理引擎支持对应加载方式。不要开启信任未知远程代码来掩盖不兼容。

静态挂载两个适配器

docker run -d --name lora-test --gpus all --shm-size 8g \
  -p 127.0.0.1:8040:8000 \
  -v /srv/models/qwen3-8b:/model:ro \
  -v /srv/adapters:/adapters:ro \
  vllm/vllm-openai:v0.18.0 /model \
  --served-model-name qwen-base --enable-lora \
  --max-loras 2 --max-lora-rank 64 \
  --lora-modules support=/adapters/support engineering=/adapters/engineering \
  --max-model-len 4096 --max-num-seqs 2 \
  --gpu-memory-utilization 0.85
docker logs lora-test
curl -f http://127.0.0.1:8040/v1/models

max-lora-rank必须不小于实际适配器rank，64不是任意适配器都通用的值。max-loras控制并发批次相关能力，不等于整个业务可以拥有的租户数。显存还受到基础权重、缓存和运行时影响，不能按LoRA文件大小推算服务总容量。

用正确的model选择适配器

import requests
def ask(name):
 r=requests.post('http://127.0.0.1:8040/v1/chat/completions',
  json={'model':name,'messages':[{'role':'user',
   'content':'客户报告模型接口超时，应该按什么顺序检查？'}],
   'max_tokens':300,'temperature':0.2,
   'chat_template_kwargs':{'enable_thinking':False}},timeout=120)
 r.raise_for_status()
 return r.json()['choices'][0]
for name in ['qwen-base','support','engineering']:
 print(name,ask(name))

模型列表与请求名称必须一致。业务网关应根据登录用户确定允许使用的名称，不能只相信客户端传来的model字符串。对同一任务分别检查基础模型与适配器输出，保留正确率、风格、拒答和工具结构，而不只看答案是不是“更像客服”。

质量验收与混合负载

每个适配器准备至少50条任务，其中包含训练外样本和跨部门问题。先独立测试，再交错发送support与engineering请求，确认输出不会串用适配器。模型更新后重跑所有适配器，而不是仅检查基础模型健康。

记录冷加载、热请求与混合批次时延。若一个适配器过热，可限制其请求率；长输出也应有预算。较多适配器的缓存与动态装卸是后续容量课题，不应在两份静态挂载还没验证前直接引入复杂调度。

故障、安全与回滚

加载失败先检查rank、target_modules、基础revision与完整文件；请求unknown model检查名称；质量没有变化检查适配器是否实际被选中。OOM先降低活跃请求和上下文，不删除基础权重来尝试“腾空间”。

运行时加载和卸载接口属于管理权限，不能公开给普通用户，也不能允许任意本地路径。适配器可能包含敏感训练信息，公开发布前单独审核。回滚保留上一套基础模型与适配器组合，记录所有哈希，停止测试容器后不删除目录。依据：vLLM LoRA文档。

适配器注册清单

每份LoRA建立注册记录，包含所有者、基础模型revision、训练数据范围、rank、目标模块、文件哈希、创建时间和允许使用的任务。名称不能只用adapter一类模糊词，多个版本应有不同注册ID。用户界面可以显示友好名称，但后台映射到明确文件和版本，禁止客户端自行提供磁盘路径。

基础模型升级可能使原适配器失效，即使能够加载也要做质量回归。先在影子服务中加载新组合，比较各适配器独立任务和基础模型任务，不只看安装日志。若训练时修改词表、增加模块或使用特殊合并方式，应要求训练团队提供导出说明，而不是反复尝试忽略不匹配参数。

部门隔离与审计

业务网关为用户维护适配器白名单，记录实际选中的注册ID。输入数据和检索权限独立检查，不能把客服LoRA当成客服资料访问权限。混合压测中连续切换两个租户，使用带唯一标记的测试任务，检查响应与日志是否正确归属。不要把用户真实问题作为公开测试样本。

一个适配器可改善表达风格，也可能降低基础能力。对拒答、工具调用、数值和中文术语分别评估，训练任务外的结果同样重要。模型输出带部门特定内容时，确认它是来自授权资料还是训练记忆；公开分发前审查隐私与数据许可。

容量与变更控制

记录基础模型静态占用、适配器加载前后差值和混合批次峰值。冷加载不与热缓存结果混成平均，热点适配器和偶尔使用的适配器可采用不同预加载策略。若请求越来越多，先检查缓存、队列和活跃数量，再决定动态装卸；更多适配器不是无限免费的租户扩容。

更新适配器以新ID发布，让少量测试账户先验证，然后逐步切换。保留旧ID和文件，发现回归可立即退回，不在运行中覆盖同一个路径。卸载前确认没有使用中的请求，避免生成中途失败。交付时提供注册清单、质量样本与回滚步骤，运营人员能够知道每个名称对应什么，而不是仅看到一个长模型列表。

多适配器服务还应限制注册数量和单文件大小，避免管理接口被用于耗尽资源。管理员新增适配器前审核配置和许可，在试验实例加载成功后再注册到正式列表。用户选择不存在或没有权限的名称时，返回明确错误，不自动切换到另一个模型并隐藏变化。