模型目录治理：OCI Enterprise AI 里的路由、发现与 IAM

Oracle 于 2026 年 10 月 9 日发布 OCI Enterprise AI 十月更新，标题很容易记：xAI 的 Grok 4.6 与 Grok 4.7 现在可以按需推理调用。真正有意思的是模型之外的东西。同一次发布还加了 Smart Model Router，在客户选定的区域之间路由推理请求；加了 Model Discovery 接口，可以查询某区域有哪些模型、以及它们的退役日期；扩充了 Model Import 目录，覆盖阿里、DeepSeek、Google 与 Z.ai；并让 IAM 策略可以放行或排除特定模型 ID。这是一朵云在长出治理能力，而治理恰恰是把模型演示变成可以长期跑下去的东西的那一层。

平台层的价值：把横跨区域的路由变成一份配置

这次到底发布了什么

六项内容，可以干净地分成容量、目录与控制三类。容量方面，Grok 4.6 与 4.7 支持按需推理，定位在编码、代理任务、推理与知识工作，且不需要客户管理底层基础设施。目录方面，Model Discovery 把区域模型清单开放成编程接口；Model Import 新增阿里 Qwen3.8-27B 与 Qwen3.5-397B-A17B、DeepSeek V4 Pro 0813 与 V4.1 Flash、Google Gemma 4 31B IT 与 26B A4B IT、Z.ai GLM-5.3 与 GLM-5.3-Flash。控制方面，有 Smart Model Router、模型级 IAM 策略，以及 Responses API 开始支持调用部分导入模型——首批是 Qwen3.6-35B-A3B 与 Gemma 4 31B IT。另外 Cohere Command A Vision 与 Embed 4 也扩展到了阿联酋东部（迪拜）区域。

# A routing profile is configuration, not application code.
ROUTING_PROFILE = {
    'name': 'prod-inference-eu-apac',
    'model': 'xai.grok-4.7',
    'approved_regions': ['eu-frankfurt-1', 'ap-singapore-1', 'ap-tokyo-1'],
    'excluded_regions': ['us-ashburn-1'],
}

def resolve(profile, requested_region):
    if requested_region in profile['excluded_regions']:
        return {'region': None, 'reason': 'region excluded by policy'}
    allowed = profile['approved_regions']
    if not allowed:
        return {'region': None, 'reason': 'no approved regions'}
    if requested_region in allowed:
        return {'region': requested_region, 'reason': 'requested region is approved'}
    return {'region': allowed[0], 'reason': 'routed to first approved region'}

print(resolve(ROUTING_PROFILE, 'us-ashburn-1'))
print(resolve(ROUTING_PROFILE, 'ap-singapore-1'))

# The regional scope stays yours. Write the profile so a reviewer can read it.

路由配置文件才是值得抄的那个抽象

Smart Model Router 会在模型可用的、由客户选定的 OCI 区域之间路由按需推理请求。机制是一个“路由配置文件”：你定义模型与获准区域，然后把这份配置用在 Chat API 或 Responses API 上。Oracle 的说法是，这样团队就不必自己搭建和维护跨区域路由逻辑——这说法没错，但更值钱的性质是：区域范围始终掌握在客户手里。这个区别在受监管环境里很关键：写在应用内部的跨区域路由，往往会变成某个人为了让延迟数字好看而随手加的函数；而路由配置文件是一个有名有姓的产物，带着一份获准区域清单，评审能读、变更流程能管。无论你是否采用这个功能，请把形状抄下来：让路由决策变成数据，而不是代码。

# Model discovery replaces the hardcoded model list in your app.
def refresh_catalog(client, region):
    catalog = {}
    for model in client.list_models(region=region):
        catalog[model['id']] = {
            'input_types': model.get('input_types', []),
            'output_types': model.get('output_types', []),
            'serving': model.get('serving_options', []),
            'params': model.get('supported_parameters', []),
            'retires_on': model.get('retirement_date'),
        }
    return catalog

def retiring_soon(catalog, today, days=90):
    alerts = []
    for model_id, meta in catalog.items():
        when = meta.get('retires_on')
        if when and (when - today).days <= days:
            alerts.append({'model': model_id, 'retires_on': when.isoformat()})
    return alerts

# A model list you maintain by hand is a model list that is already wrong.

模型目录应当是查询出来的，而不是手工维护的

模型发现让目录变成一次查询

Model Discovery 让开发者可以通过 API 发现某个区域有哪些模型，并获取能力、输入输出类型、服务方式、支持的参数以及退役日期等细节。其中退役日期是值得围绕它建流程的那一项。每个在生产环境跑过模型的团队都遇到过这个问题：模型 ID 硬编码在配置文件里，厂商通知躺在邮箱里，然后你只剩下原计划四分之一的时间去救火。如果目录可以被查询，你就可以定期刷新、跟你依赖的那一份做 diff，并在你调用的某个模型刚被标注退役日期的那一刻告警。这把一次应急变成一张带截止日期的工单，成本只是一个定时任务。

# On-demand or imported? Two shapes, mostly decided by steady-state load.
def serving_choice(rpm_peak, avg_input_tok, avg_output_tok, hours_per_day=8):
    daily_tokens = rpm_peak * 60 * hours_per_day * (avg_input_tok + avg_output_tok)
    return {
        'daily_tokens': daily_tokens,
        'recommended': 'on-demand' if daily_tokens < 5e8 else 'dedicated cluster with import',
        'reasons': [
            'on-demand has no capacity to manage and no idle cost',
            'import needs a compatible dedicated AI cluster, and you own the hosting',
            'import pays off when utilisation stays high across the month',
        ],
    }

print(serving_choice(rpm_peak=40, avg_input_tok=1800, avg_output_tok=400))

# Import also buys model choice. On-demand buys not having an on-call rota for GPUs.

导入与按需，是两种不同的运营模型

Model Import 与按需推理在一次 API 调用上看着像，从运维角度看则完全不同。按需意味着没有容量要管理、没有闲置成本，代价是你只能用提供商愿意放出来的容量。导入则意味着先把模型导入并托管在兼容的专用 AI 集群上，再调用它，好处是可以选择托管目录之外的模型并拿到可预期的吞吐，代价是你自己拥有这份托管责任。这个决策基本取决于利用率：整月都跑满的负载值得专用容量，而突发型负载会为自己永远用不到的闲置容量付费。选择之前，用自己的数字把两条路各算一遍；也别忘掉导入那条路还继承了一份维护义务，而按需没有。

# Model-level IAM: allow by pattern, exclude by explicit deny.
POLICY_RULES = [
    {'group': 'app-team-search', 'allow_patterns': ['cohere.*', 'google.gemma-4-*'], 'deny': []},
    {'group': 'app-team-agents', 'allow_patterns': ['xai.*', 'deepseek.*'], 'deny': ['xai.grok-4.6']},
]

def match(pattern, value):
    prefix = pattern.split('*')[0]
    suffix = pattern.split('*')[-1] if pattern.count('*') else ''
    return value.startswith(prefix) and value.endswith(suffix)

def permitted(group, model_id):
    for rule in POLICY_RULES:
        if rule['group'] != group:
            continue
        if model_id in rule['deny']:
            return {'allowed': False, 'reason': 'explicitly denied'}
        for pattern in rule['allow_patterns']:
            if match(pattern, model_id):
                return {'allowed': True, 'reason': 'matched ' + pattern}
        return {'allowed': False, 'reason': 'no matching allow rule'}
    return {'allowed': False, 'reason': 'group has no policy'}

print(permitted('app-team-agents', 'xai.grok-4.6'))
print(permitted('app-team-agents', 'xai.grok-4.7'))

# Access control that lives in the cloud beats access control that lives in a wiki.

模型级 IAM 让访问控制留在云上，而不是留在文档里

模型级 IAM，才是让审计安心的那个控制

这次发布里最被低估的一项，恰恰是最不显眼的：OCI IAM 策略现在可以控制不同用户组能调用哪些模型，既能按具体模型 ID 或模式放行，也能排除选定模型。很多组织把模型访问控制做在应用里，一开始能跑，直到有人加了一个新服务并忘了加限制。把它挪到云的身份层，意味着平台团队回答“哪些团队能调用某个模型”这种问题时，不必去读五个代码库；也意味着新加的模型不会自动对所有具备网络访问权限的东西开放。模式让策略在目录增长时依然可维护，显式排除则让你能把某个具体模型从某个具体团队的触达范围里摘出去，而不必把整个家族都禁掉。

# Retirement is a date, so treat migration as a scheduled task.
from datetime import date

def migration_plan(model_id, retires_on, today):
    window = (retires_on - today).days
    return {
        'model': model_id,
        'days_remaining': window,
        'steps': [
            ('frost the model in new code', window <= 120),
            ('stand up the replacement behind the same interface', window <= 90),
            ('run the compatibility suite on both', window <= 60),
            ('shift traffic and keep a rollback profile', window <= 30),
        ],
        'rollback': 'repoint the routing profile at the previous model',
    }

plan = migration_plan('google.gemma-4-31b-it', date(2027, 1, 31), date(2026, 10, 14))
print(plan['days_remaining'], [step for step, due in plan['steps'] if due])

# Because switching is a profile change, the migration is boring. Keep it boring.

一份能撑过模型退役的落地计划

把这几块拼起来，运营模型大致是这样：把模型 ID 放在路由配置文件里，而不是放在应用代码里，于是换模型变成一次带可评审 diff 的配置变更。定期刷新发现出来的目录，把退役日期当作排期输入，并采用这样一条迁移顺序——在截止日期之前很久就在新代码里冻结旧模型，用同一个接口把替代模型立起来，对两者跑一遍兼容性测试，然后切流并保留旧配置用于回滚。把权限落在 IAM 上，让一次误操作的爆炸半径由策略而不是由人的警觉度来限定。这些都不激动人心，而这正是重点：能毫发无伤地熬过一轮模型退役的团队，都是那些早就把换模型变成例行公事的人。