多租户推理服务有一个底线问题：租户甲的请求，绝不能看到租户乙的模型权重、对话内容、缓存数据或日志痕迹。隔离做不到位，轻则合规风险，重则一次串数据事故就足以毁掉整个平台的信任。隔离不是加一道鉴权就能交差的，它要从请求处理链路的每一层去落实。

先说权重隔离。不同租户可能用不同的微调模型，甚至是各自私有的数据训练出来的专属权重。权重文件在存储层就要按租户分开，访问权限按租户收敛，加载时也要确认当前实例加载的确实是请求所属租户的权重，而不是复用了上一个租户的残留。实例复用是常见的隐患：一个实例刚服务完租户甲，马上服务租户乙，如果权重、缓存、临时文件没有清理干净，就可能串扰。隔离级别的选择要与风险匹配：高敏感租户走独占实例或独占进程，普通租户可以在同一实例内通过严格的上下文隔离共存，但前提是每一层的清理与校验都经过验证。

再说运行时数据隔离。推理过程中的键值缓存是重点：缓存按租户分区存储，键名里必须带租户标识，读取时二次校验归属，不能只靠调用方传参自觉。历史对话、检索到的参考资料、中间推理结果，同样要按租户隔离，日志与监控指标里也不得混入租户的原始请求内容。很多串数据问题不是出在主链路，而是出在日志、调试接口、错误回显这些边角：一次把请求原文打进公共日志，隔离就破了口子。日志要脱敏，调试接口要按租户鉴权，错误信息只返回通用描述，不回显他人的数据片段。

性能隔离同样是隔离的一部分。一个租户突发大流量，不应该把其他租户的延迟拖垮。常见做法是配额与优先级：每个租户有并发上限与速率上限，超限的请求排队或快速失败，而不是无限制地挤占共享资源。配额要分层：实例级、模型级、租户级都要有上限，避免单个租户通过多模型、多实例绕过限制。资源紧张时，降级策略也要按租户执行，不能为了保一个租户而无差别地丢弃所有人的请求。

最后是审计。隔离做得好不好，不能只靠设计文档自证，而要靠可审计的证据：谁在什么时间访问了哪个租户的权重、缓存命中是否跨租户、配额触发记录、异常访问告警。定期做隔离专项演练：模拟租户越权访问、模拟缓存串扰、模拟日志外泄，验证每一层防线是否真实生效。多租户服务的隔离是一项持续工程，租户结构、模型形态、部署方式一变，隔离边界就要重新审一遍；把它当成一次性任务，迟早会在某个边角漏水。