一、项目背景

这个项目里，我们面对的是某多部门共用一个 AI 底座的典型情况：集团下多个业务线、多个职能部门都希望通过统一的 AI 能力做客服、写文案、做数据分析，但彼此在配额、数据归属和审计责任上又必须清晰分开。上线前我们吃过大亏——由于没有在网关层做租户隔离，一个部门在大促期间把批量生图任务打满，直接把 GPU 算力占满，导致另一个部门的实时客服问答排队超时；更麻烦的是，调用日志混在一起，事后出了问题谁都说不清是谁的流量，责任认定非常困难。

我们当时意识到，多部门共用底座不等于"大家共享同一口锅不分彼此"。正确的做法是在我们采用的 AI 网关技术平台上把边界划清楚：网关做流量与配额的边界，底座做数据的物理隔离。这样既保留了共用底座在成本与运维上的优势，又让每个部门有自己独立的配额、独立的调用视图和独立的审计轨迹。

二、落地场景

我们把"租户"定义为一个部门或一个独立业务应用，每个租户在网关侧拥有唯一标识、独立配额与独立鉴权凭证。落地覆盖三类场景：

第一类是配额分部门。网关的计量层按租户沉淀 token 配额与并发上限，某个部门用超了就被限流，不影响其他部门。大促前可临时给特定租户提额，事后回收。

第二类是数据与调用隔离。不同租户的私有知识库、私有提示词模板在底座侧按租户编号做命名空间隔离；网关在路由时强制把租户上下文带下去，确保 A 租户的检索不会误召回 B 租户的私有文档。

第三类是调用与审计按租户归集。所有请求从接入层就打上租户标签，贯穿路由、编排、计量到可观测链路，管控台的审计看板可以按租户拉出完整的调用链、费用明细与异常记录，做到"谁产生的流量、谁负责"。

案例片段（已脱敏）： 租户隔离与配额配置片段（YAML 示意）：yaml tenants:  - id: dept_sales    quota: { token_per_day: 2000000, max_concurrency: 8 }    route: { kb_namespace: kb_sales, fallback: model_small }  - id: dept_service    quota: { token_per_day: 5000000, max_concurrency: 20 }    route: { kb_namespace: kb_service, priority: high } isolation:  data: namespace_per_tenant  audit: tag_from_gateway_in

三、关键技术挑战与解决思路

挑战一：租户级配额与限流如何在网关稳定落地，且不被突发流量击穿。我们最初用简单的计数器做日配额，但遇到秒级突发仍会瞬时打满底座。后来的做法是在计量层做双层限流：粗粒度按日 token 配额做预算式拦截，细粒度按并发数与 QPS 做令牌桶限流；当某租户逼近配额时网关提前返回 429 并带上可重试提示，把压力挡在模型前，避免穿透造成共享故障域扩散。

挑战二：数据与调用的隔离，尤其是私有知识库不能串租户。我们在底座侧给每个租户分配独立向量命名空间，网关在请求归一化阶段就把租户标识注入上下文，RAG 检索严格限定在本租户命名空间内。同时我们在编排层加了隔离校验：若下发请求缺失租户标签或标签与鉴权凭证不一致，直接拒绝，杜绝越权召回。

挑战三：跨租户审计归集与可追溯。多部门共用意味着出了事要能快速定位到是哪个租户、哪个账号、哪次调用。我们把租户标签从接入层（Gateway-In）就写入调用链上下文，贯穿到计量账单与可观测链路；管控台提供按租户、按用户、按时间窗的审计检索。这样审计可追溯率提升到接近全量，定位一次异常调用从原来的翻总日志变成点开租户视图即可。

挑战四：资源争用与故障域隔离。共用底座最怕一个租户把算力拖垮连累全员。我们的思路是配额先于共享——先给每个租户划好资源上限，再谈共享带来的成本节约；网关限流信号还会反向驱动底座做弹性扩缩容，形成"流量—算力"联动，单个租户的异常流量被限制在自身配额边界内，不再演变成全局故障。

四、效果数据

租户隔离方案上线约两个月后，我们对比了上线前后（数据为脱敏示意值，非审计级精确数字）：

可以看到，配额与限流上线后，单日成功拦截的超标调用约 120 次，避免了多次潜在的跨租户影响；审计可追溯率从约 40% 提升到约 99%，定位问题不再靠翻混合日志；资源争用率降至约 35%，大促期间某部门批量任务不再拖垮其他部门的实时服务。

五、可复用经验总结

第一，隔离的边界要分两层：网关做流量、配额、调用的边界，底座做数据的物理隔离。两层配合，共用底座才能既省钱又不出责任纠纷。

第二，配额要先于共享。不要为了追求共用率而放弃配额管控，先划好每个租户的上限，共享带来的成本优势才有安全感。

第三，租户标签要从接入层就打，贯穿全链路。只有标签贯穿路由、计量、可观测，审计归集与故障定位才真正可用。

第四，让网关限流信号反向驱动底座弹性扩缩容。流量与算力联动，能把单租户异常牢牢限制在自身边界，避免演变成全局故障。

案例片段（已脱敏）： 网关层租户限流判定片段（伪代码）：python def admit(tenant, req):    if metering.day_token(tenant) >= tenant.quota.token_per_day:        return 429, "quota_exceeded"    if limiter.concurrency(tenant) >= tenant.quota.max_concurrency:        return 429, "too_many_requests"    if not req.tenant_tag or req.tenant_tag != req.auth_tenant:        return 403, "tenant_mismatch"    return 200, "admitted"