当你手里只有一把锤子,所有问题看起来都像钉子——这句话对 AI 模型同样成立。很多团队在拿到 GPT-4 或某个开源模型的 API key 后,就把它塞进所有业务场景,直到月底账单爆炸或输出质量飘忽不定才意识到:选模型、控成本、保质量,这三件事必须系统性地管起来,而不是靠运气。
Microsoft 的 Azure AI Foundry 正是围绕这个痛点设计的——它不只是一个"模型超市",而是覆盖选型、评估、优化、治理全生命周期的一套运营框架。下面拆解几个关键环节,并给出可以直接跑的代码。
模型选型:别再"一个模型打天下"
不同任务对模型的要求差异极大。摘要生成可能用一个小模型就够了,复杂推理则需要大模型撑场。Foundry 的 Model Catalog 把微软自研模型、OpenAI 系列、Hugging Face 开源模型、Meta Llama、Mistral 等统一放在一起,附带能力标签和基准分数,方便横向比较。
实际操作中,推荐的做法是:先在 Catalog 里筛选候选,再用基准测试在你自己的数据集上跑一轮,最后按性价比拍板。
下面这段代码用 Azure AI Foundry SDK 列出可用模型,并按类别筛选:
# pip install azure-ai-projects azure-identity
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
# 从环境变量读取:AZURE_AI_PROJECT_ENDPOINT
project_client = AIProjectClient(
endpoint="https://your-project.cognitiveservices.azure.com",
credential=DefaultAzureCredential(),
)
# 列出当前项目可用的模型部署
deployments = project_client.deployments.list()
for d in deployments:
print(f"模型: {d.model_name} | 类型: {d.model_type} | SKU: {d.sku_name} | 速率限制: {d.rate_limits}")
运行前把 AZURE_AI_PROJECT_ENDPOINT 替换成你自己的项目地址。输出会告诉你每个部署的模型名、类型和 SKU,方便你判断哪些适合当前场景。
成本控制:把预算变成代码里的约束
模型调用按 token 计费,不加限制很容易失控。Foundry 提供了几层成本防线:
- 部署级速率限制:在创建部署时设定每分钟/每天的调用上限,从物理层面截断超量请求。
- token 预算与用量追踪:项目仪表盘实时展示 token 消耗趋势,支持按模型、按时间段拆分。
- 动态路由:根据请求复杂度,把简单任务路由到低成本小模型,复杂任务才调用大模型。
一个实用的模式是:在调用层加一个"成本门"——如果单次请求预估 token 超过阈值,就降级到更便宜的模型或直接拒绝。
import os
from openai import AzureOpenAI
# 简单任务用小模型,复杂任务用大模型
CHEAP_MODEL = "gpt-4o-mini" # 成本约 $0.15/1M input tokens
EXPENSIVE_MODEL = "gpt-4o" # 成本约 $2.5/1M input tokens
client = AzureOpenAI(
api_key=os.getenv("AZURE_OPENAI_API_KEY"),
api_version="2024-08-01-preview",
azure_endpoint=os.getenv("AZURE_OPENAI_ENDPOINT"),
)
def smart_complete(prompt: str, max_tokens: int = 500, token_budget: int = 2000) -> str:
"""根据 prompt 长度和 token 预算自动选模型"""
# 粗估 input token 数(英文约 4 字符/token,中文约 2 字符/token)
estimated_input_tokens = len(prompt) // 3
if estimated_input_tokens + max_tokens > token_budget:
model = CHEAP_MODEL
print(f"⚠️ 预估超预算,降级到 {model}")
else:
model = EXPENSIVE_MODEL
print(f"✅ 预算充足,使用 {model}")
response = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": prompt}],
max_tokens=max_tokens,
)
# 打印实际消耗(生产环境应写入监控系统)
usage = response.usage
print(f"实际消耗: input={usage.prompt_tokens}, output={usage.completion_tokens}, model={model}")
return response.choices[0].message.content
# 测试:短 prompt 用大模型,长 prompt 自动降级
short_result = smart_complete("用一句话解释什么是微服务")
long_prompt = "请详细分析以下 5000 字的产品需求文档..." + "冗余填充内容" * 200
long_result = smart_complete(long_prompt, max_tokens=800, token_budget=1500)
把 AZURE_OPENAI_API_KEY 和 AZURE_OPENAI_ENDPOINT 设成你的环境变量即可运行。核心思路:成本控制不是事后看账单,而是调用前就做决策。
质量评估:自动化基准测试,而不是靠人肉感受
"感觉输出还行"是最危险的质量判断方式。Foundry 内置了评估框架,支持对模型输出做系统性打分——准确性、相关性、连贯性、安全性等维度都可以量化。
关键步骤:
- 准备评估数据集:一组有标准答案的输入-输出对。
- 跑批量推理:让候选模型对同一批输入生成输出。
- 用评估器自动打分:比对模型输出与标准答案,输出结构化报告。
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
from azure.ai.evaluation import QAEvaluator, evaluate
project_client = AIProjectClient(
endpoint="https://your-project.cognitiveservices.azure.com",
credential=DefaultAzureCredential(),
)
# 1. 准备评估数据集(实际应从文件加载)
eval_data = [
{
"question": "Azure Functions 的冷启动延迟典型值是多少?",
"answer": "通常在 1-5 秒之间,取决于运行时语言和包大小。", # 标准答案
},
{
"question": "什么是 Cosmos DB 的 RU?",
"answer": "Request Unit,是 Cosmos DB 中衡量操作成本的抽象单位,1 RU ≈ 读取 1KB 文档的成本。",
},
]
# 2. 用 GPT-4o-mini 生成候选输出(此处简化,实际应批量调用模型)
model_outputs = []
for item in eval_data:
# 假设你已经拿到了模型的回答
model_outputs.append({
"question": item["question"],
"answer": item["answer"],
"model_response": "Azure Functions 冷启动大约需要几秒钟时间。", # 模型实际输出
})
# 3. 运行评估
qa_eval = QAEvaluator(model_config=project_client.models.get("gpt-4o-mini"))
result = evaluate(
evaluation_name="model-quality-check",
data=model_outputs,
evaluators={"qa": qa_eval},
)
# 打印每条结果的分数
for row in result.rows:
print(f"问题: {row['question']}")
print(f" QA 准确性分数: {row.get('qa.accuracy', 'N/A')}")
print(f" QA 相关性分数: {row.get('qa.relevance', 'N/A')}")
这段代码的核心价值:把"模型好不好"从主观判断变成可追踪的指标。 每次换模型或调参数后跑一遍,分数涨了还是跌了一目了然。
治理与规模化:让模型运营不靠"英雄工程师"
单个模型调通不难,难的是十个模型、五个团队同时跑的时候不出乱子。Foundry 在治理层面提供了几个关键能力:
- 统一权限与审计:谁在什么时候调了哪个模型、花了多少 token,全部可追溯。
- 内容安全过滤:内置 Content Safety 评估器,在输出到达用户前拦截有害内容。
- 模型版本管理:升级模型版本时可以灰度切换,而不是一刀切全量替换。
一个推荐的上线流程:
# 模型部署配置示例(用于 Azure AI Foundry 项目)
apiVersion: 2024-08-01
kind: Deployment
metadata:
name: gpt-4o-mini-prod
spec:
model:
name: gpt-4o-mini
version: "2024-07-18" # 锁定版本,避免静默升级
sku:
name: GlobalStandard
capacity: 50 # 速率上限:50 requests/min
contentSafety:
enabled: true # 开启内容安全过滤
severityThreshold: medium # 中等及以上风险内容拦截
tags:
env: production
team: platform-core
costCenter: ai-infra-001 # 成本归属标签
这个 YAML 体现了三个治理要点:版本锁定防漂移、速率限制防超支、安全过滤防事故。 实际部署时通过 az ai deployment create 或 SDK 提交即可。
落地建议与取舍清单
把上面这些串起来,给团队一个可操作的起步路径:
| 阶段 | 动作 | 优先级 |
|---|---|---|
| 第 1 周 | 在 Foundry 里列出所有现有模型部署,标注每个的月成本和调用量 | 🔴 必做 |
| 第 2 周 | 对高频场景做一次基准评估,确认当前模型是否真的合适 | 🔴 必做 |
| 第 3 周 | 给所有生产部署加速率限制和成本标签 | 🟡 重要 |
| 第 4 周 | 建立自动化评估流水线,每次模型变更自动跑分 | 🟡 重要 |
| 持续 | 用动态路由把 60%+ 的简单请求分流到小模型 | 🟢 优化 |
几个需要注意的边界:
- 评估器本身也消耗 token:用大模型做评估裁判时,评估成本可能比推理成本还高。建议评估时也用小模型,或者只在关键节点跑全量评估。
- 速率限制是硬墙:设得太低会导致高峰期请求排队甚至失败,需要根据业务峰值留出余量。
- 版本锁定有代价:你放弃的是自动获取模型改进,需要定期手动评估新版本再决定是否升级。
从"拿到 API key 就开干"到"系统性地选、评、控、治",中间差的不是更贵的模型,而是更完整的运营框架。Azure AI Foundry 提供了这套框架的骨架,但真正起效的前提是:团队愿意把模型当成基础设施来管,而不是当成一次性实验来做。