多租户算力平台的安全隔离边界，不能简单等同于“不同租户使用不同命名空间”或“任务被调度到不同节点”。真正需要控制的是风险能否跨越租户、工作负载、节点、网络、数据和运维权限边界扩散。平台的核心问题不是能否共享GPU、CPU等资源，而是在共享过程中，是否能明确回答：谁可以使用什么资源，能够访问哪些数据，异常会影响哪些业务，以及事后能否完成追责和复盘。
隔离边界应分层设计
第一层是身份与权限边界，重点控制用户、租户管理员、平台管理员、服务账号和审计人员各自能执行的操作。提交任务的权限，不应自动包含读取其他租户数据、修改全局策略或操作节点的能力。临时运维权限还应具备申请、审批、到期回收和事后复核机制。
第二层是资源与运行环境边界。资源配额、优先级、抢占规则需要能够解释，避免单个长任务持续挤占共享资源。容器、节点、镜像、设备直通和高权限系统调用也必须分别审查。任务被安排到不同节点，只能说明调度位置不同，并不代表权限、网络、存储和日志已经完成隔离。
第三层是网络、数据与故障边界。网络策略不应只划分“能通”和“不能通”，而要明确工作负载是否可以访问其他租户服务、控制面、节点管理接口、外部存储及业务数据库。对于生产推理、核心数据训练、开发测试等不同敏感等级的任务，应设置相应的资源池、访问范围和恢复策略。
用故障场景验证边界
安全隔离不能只靠静态配置验收。应模拟单个工作负载资源失控、租户误改策略、节点或设备故障、控制面异常以及高权限账号异常，观察影响是否局限在预定范围内。尤其要检查任务异常重试、日志暴增、网络连接失控时，是否存在限额、终止、隔离和审计机制。
审计链路还必须能够关联操作主体、操作对象、时间、变更内容、执行结果和影响范围。若只能看到“任务失败”，却无法追溯权限变更、资源使用和网络访问，就无法判断问题究竟来自调度、配置还是人为操作。
隔离强度应与风险匹配
集中式隔离便于统一治理，但高权限和故障影响可能过于集中；租户级隔离适合多数共享场景，前提是资源、网络、身份和日志边界保持一致；工作负载级隔离控制更细，却依赖自动化策略、统一运维和持续验证。最优架构不是隔离层次最多，而是能在数据敏感度、业务连续性、资源利用率和运维能力之间取得可解释的平衡。只有当权限可控、影响可限、操作可追、故障可恢复时，共享算力才真正具备安全基础。