初建平台时，先别把“每个租户分配多少显存”和“租户之间是否隔离”当成同一个问题。多租户AI平台的显存配额与隔离策略，取决于任务能否共享设备、故障影响范围，以及团队是否具备维护切分资源的能力。配额控制用量，隔离限制相互影响，两者可以组合使用。
配额不是显存墙：先弄清控制边界
软件配额通常由调度器、推理服务或框架限制任务可申请的显存。它能避免单个租户无限扩张，却不一定能拦住应用绕过配额，也不一定隔绝驱动、上下文和运行时开销。某个进程超出可用空间时，仍可能触发显存分配失败；并发任务则可能因争抢资源而变慢。
硬隔离是让租户使用相对独立的设备资源。常见方式包括分配整张卡、使用支持的硬件分区，或借助虚拟化提供隔离实例。NVIDIA MIG 是硬件切分的一个具体例子，但能否使用取决于设备型号、驱动和软件栈。硬隔离通常更易界定故障范围，代价是切分和运维复杂度增加，且可能留下暂时无法拼给其他租户的闲置资源。
按任务类型选择，不必一刀切
开发与低负载推理：先配额、后观察
交互式实验、短时验证和用量波动不大的小型推理服务，可以先采用共享设备加软件配额。好处是资源安排灵活、启动成本较低；缺点是隔离较弱，邻居任务的突发占用仍可能影响延迟。若使用 Kubernetes，设备插件暴露的资源分配能力与应用层显存限制不是一回事，需分别核实。
生产服务与不可信任务：优先缩小故障域
对延迟目标严格、任务来源不可信，或一次显存溢出会影响多个租户的场景，应考虑硬件切分或整卡独占。硬件分区可在适配设备上兼顾共享和隔离；整卡独占边界更直观，但利用率可能较低。若同一物理设备承担开发和生产任务，建议至少把生产工作负载单独放置，避免把软件配额误当成安全边界。
从测量到上线：四步建立配额
按模型、输入尺寸、批量和并发分别记录实际显存峰值，并在冷启动、长时间运行和并发压力下复测。权重之外，缓存、临时张量及框架开销也会占用显存。
以观测到的高峰值作为基线，再留出余量。约 10%—20% 可作为初始评估范围，但这不是通用标准；模型动态形状多、并发变化大或运行环境复杂时，应留更多空间，并通过压力测试调整。
将单租户上限、并发数、队列长度和超时策略一起配置。只设显存配额而不限制并发，多个任务同时启动仍可能让设备超载。
设置告警并演练超限处理：拒绝新任务、排队或迁移到隔离资源。记录租户、任务和设备信息，确认异常不会连带中断其他租户。
评估时可对照显存切分、时间切片、容器配额和整卡独占这几种方案：前三者更有利于共享或调度，但隔离边界不同；独占最直观，却牺牲资源合并能力。多租户AI平台的显存配额与隔离策略不必一次定终局，先按风险分层，再用真实负载验证，比全平台只用一种模式更稳妥。
常见问题
显存配额能防止其他租户看到我的数据吗？
不能仅凭配额作此保证。数据保密需要依靠权限、进程与设备隔离及数据清理等措施，并按实际运行架构验证。
硬件切分是否一定比共享更快？
不一定。它主要提供更明确的资源边界；性能还受切分规格、模型和并发影响，应以目标负载测试。
初期资源少，是否必须做硬隔离？
不一定。可先用配额承载低风险任务，同时将生产或高敏感任务单独放置；当互相干扰或故障风险不可接受时，再扩大硬隔离范围。
多久调整一次配额？
模型、输入、并发或软件栈发生变化时应重新测量；平时按告警和用量记录定期复核，不宜长期沿用旧峰值。
