近年来，生成式 AI 技术迅速演进。在自然语言处理之外，图像生成与编辑能力成为 AI 创新的重要前沿。在这一趋势下，OpenAI 推出了 GPT Image 系列模型，在 Azure OpenAI 服务内同样可用。而其中最新发布的 GPT-Image-1.5 可视为图像生成领域的新旗舰，在性能、效率和可控性方面均有显著提升。

什么是 GPT-Image-1.5

GPT-Image-1.5 是 OpenAI 最新发布的多模态图像生成模型，属于 GPT Image 系列，目前是效果最佳的版本。与前代（如 GPT-Image-1）相比，它在指令遵循能力、图像质量、生成速度和成本效率方面都有明显提升。

官方定义上，GPT Image 模型是原生多模态语言模型（natively multimodal），能接收文本和图像输入，并生成图像输出。在功能上，它不仅支持从纯文本生成图像，还可以对已有图像进行编辑、修改、风格化转换等操作。

简而言之：

• 多模态：同时理解文本和图像输入。
• 图像生成与编辑：支持从文本生成全新图像，也支持对已有图像进行局部修改和增强。
• 高质量与高效：相比前代生成更精细、更快速，同时成本更低。

核心能力与特点

1. 指令遵循及表达精准

GPT-Image-1.5 在理解自然语言提示方面得到显著提升，尤其擅长：

• 对复杂描述的视觉表达，细节理解更准确
• 在图像中生成清晰可读的文本内容
• 遵循用户指令进行定制化修改和组合

相比最初的图像生成模型（例如 DALL·E 系列），这类 GPT Image 系列模型对于提示语的响应更直观、可控性更高。

2. 图像质量与生成速度提升

GPT-Image-1.5 的生成速度比上一代快得多（据报道最高可达大约 4 倍提升），这对于需要快速迭代视觉内容的场景（如设计、产品原型等）尤为重要。

此外，图像生成结果在细节、现实感和一致性方面表现更好，尤其是在脸部、纹理、光影等关键元素上有显著进步。

3. 编辑与增强功能

GPT-Image-1.5 同时支持图像编辑，包括：

• 局部修改：对选中区域进行变更
• 添加或移除元素
• 风格化调整与概念转换

无需完全重新生成整幅图像，大幅提升工作流效率。

4. 成本与效率优化

GPT-Image-1.5 在 API 调用成本上较前代降低约 20%，使得高质量图像生成在更大范围内可持续使用，特别适合企业级批量生成需求。

5. 安全性与合规性

作为 Azure OpenAI 服务的一部分，GPT-Image-1.5 的使用受 Azure 的安全性、合规性和内容过滤体系保障，支持多种定制化审核与责任使用防护。

在 Microsoft Foundry 中部署与使用 GPT-Image-1.5

随着 Microsoft Foundry 的推出（当前为预览版），微软正在将 Azure OpenAI、模型目录、推理端点、Playground 与企业治理能力整合为统一的 AI 应用构建平台。在该预览版中，GPT-Image-1.5 已作为一等模型（first-class model）被直接纳入 Foundry 的模型体系，无需再通过传统的 “Azure AI Foundry / Azure AI Studio” 路径进行管理。

1. 在 Microsoft Foundry 中部署 GPT-Image-1.5

在 Preview 版 Foundry 中，模型部署流程更接近“产品级模型托管”而非传统 Azure 资源配置：

首先进入 Microsoft Foundry（Preview）控制台。在左侧选择 Models（模型库）。在模型列表中找到 GPT-Image-1.5（Image / Multimodal 分类）。

打开模型详情页后，点击 Deploy，创建一个新的推理部署。

选择默认部署，简单选择 Region 后即可完成部署，整个过程非常简单：

部署完成后会自动进入 GPT-Image-1.5 的 Playground：

完成后，Foundry 会自动生成：

• 一个可调用的 Inference Endpoint
• 与之绑定的身份、配额与监控策略

这一流程强调的是模型即服务（Model as a Service），开发者不再需要直接关心底层 Azure OpenAI 资源的复杂配置。

2. 使用 Foundry Playground 进行图像生成与 Prompt 验证

Microsoft Foundry（Preview）内置了统一的 Playground，用于对 GPT-Image-1.5 进行交互式试验。

在 Playground 中，你可以：

• 直接输入文本 Prompt 生成图像
• 调整图像尺寸、质量等级等参数
• 快速验证复杂描述、风格化指令的效果
• 对比不同 Prompt 的生成结果

这一能力特别适合以下角色协作使用：

• 产品经理：验证视觉创意可行性
• 设计师：探索生成风格与构图
• 工程师：在写代码前固化 Prompt 模板

Playground 在 Preview 版 Foundry 中的定位是 Prompt 即资产，验证通过的 Prompt 可以直接迁移到生产代码中使用。

生成图片后效果如下：

3. 从 Foundry 到应用代码的集成方式

在应用层面，Microsoft Foundry（Preview）部署的 GPT-Image-1.5 本质上仍然以标准推理 Endpoint 的形式对外提供服务：

• 代码侧只需要关心：

  • Endpoint URL
  • Deployment Name
  • 身份认证方式

• 不再直接依赖模型原始名称或版本号

在企业实践中，常见模式是：

• 开发 / 测试 / 生产环境使用不同 Deployment
• 模型版本升级（例如 GPT-Image-1.5 → 后续版本）在 Foundry 层完成
• 应用代码保持不变，仅消费稳定的 Endpoint

这种模式显著降低了 模型演进对业务系统的侵入性。

在 Azure OpenAI 中如何使用 GPT-Image-1.5

你可以通过 Azure OpenAI 提供的 API、SDK 或 Azure AI Foundry 平台来调用 GPT-Image-1.5。基本流程如下：

1. 获取访问权限与部署模型

在模型的详情页可以查看通过代码嗲用 GPT-Image-1.5 的所有信息：

2. 使用 REST API 生成图像

使用 POST 请求调用图像生成端点：

POST https://<your_resource>.openai.azure.com/openai/deployments/<your_deployment>/images/generations?api-version=<api_version>
Content-Type: application/json
api-key: <your_api_key>

{
  "prompt": "一位穿宇航服的猫在火星表面散步",
  "size": "1024x1024",
  "n": 1,
  "quality": "high"
}

常见参数说明：

• prompt: 文本描述
• size: 图像尺寸（如 1024x1024）
• n: 生成图像数量
• quality: 生成质量（low/medium/high）

3. 图像编辑（若支持）

上传已有图片并通过 prompt 指令结合修改：

POST /images/edits

此类调用可以指定 mask、输入图片等字段来控制局部变化。

4. SDK 与开发环境

Azure 支持多种语言 SDK（例如 Python、C#），可借助 Azure Identity 认证库、安全地调用 API 并处理生成结果。

总结

GPT-Image-1.5 在图像生成领域代表了下一阶段 AI 创意工具的能力边界。它在指令理解、生成速度、图像质量、成本效率与多模态处理方面均显著提升，为开发者和企业提供了一套强大且可扩展的视觉 AI 解决方案。

对于希望构建中长期 AI 能力平台的团队而言，Foundry + GPT-Image-1.5 是比直接裸用 API 更具工程化和可持续性的选择。

Azure OpenAI 服务结合了模型能力与企业级安全合规，让 GPT-Image-1.5 不仅适用于实验探索，也能支撑生产级应用。

如果你正在构建需要视觉理解或自动创意生成的应用，无论是批量生成还是交互式体验，GPT-Image-1.5 都值得深入实践。

本文将从架构层面系统梳理 LLM 的主流技术路径，并从应用视角分析其优劣及适配场景，为研发与业务团队提供技术选型参考。同时也希望可以为初学者们打开迈入大模型世界的一条门缝！

大语言模型的主流架构体系

目前的 LLM 架构，大概可以分为这么几类：

1. 传统 Transformer（Dense Transformer）
2. Mixture-of-Experts（MoE）架构
3. 多模态扩展架构（Vision-Language / Audio-Language）
4. 检索增强生成（RAG）与混合推理架构
5. 基于代理（Agentic）架构的系统级 LLM
6. 超大规模分布式训练架构（例如 Parameter Server / Fully Sharded）

下面逐一展开。

传统 Transformer：主流 LLM 的基础架构

Dense Transformer 是绝大多数 LLM 的基座，包括 GPT 系列、LLaMA、Mistral、Qwen 等。

架构

简单来说，就是“大力出奇迹”：

• 所有 token 通过全连接注意力进行计算；
• 全部参数在每次前向推理中都会被激活；
• 结构相对规则，训练稳定；
• 模型规模靠堆叠层数与扩大 hidden size 线性提升。

优势

• 推理路径稳定、可预测；
• 训练过程成熟，生态支持丰富；
• 对所有任务通用，不需要额外路由机制。

局限

• 参数规模大时推理成本高（全部参数激活）；
• 扩展模型能力的成本几乎与参数规模线性相关。

应用场景

Dense 模型依然是绝大多数企业首次采用 LLM 时的首选。

Mixture-of-Experts（MoE）：高效扩展能力的关键技术

MoE 是当前最重要的新架构之一，代表模型包括：

• Google Switch Transformer
• DeepSeek-V2/V3
• Mixtral 系列
• GPT-4 技术论文暗示其有 MoE 结构成分

架构

MoE 不再让所有参数参与每次计算，而是通过路由（Routing）机制让每个 token 只激活若干专家层（Expert）。

举个例子，一个 300B 参数的庞然大物，实际每次推理可能只动用了 30B 的参数。

优势

• 训练扩展性极强：参数规模可以以更低成本提升到数千亿甚至上万亿。
• 推理成本显著降低：激活专家减少推理 FLOPs。
• 擅长复杂推理与多任务能力。

局限

• 路由训练复杂，稳定性需求更高；
• 推理并行规模更大，对系统工程要求高；
• 不适合极端低延迟场景，因为专家调度带来额外开销。

应用场景

MoE 已成为大型商业 LLM 的主流趋势。

多模态 LLM 架构：模型能力向感知延伸

代表模型：GPT-4o、Gemini、Qwen-VL、LLaVA、Yi-VL

架构

多模态 LLM 通过在 Transformer 基座上引入额外编码器，将视觉、音频、视频等信号映射为 token 表示。

典型结构通常包含：

• 视觉编码器（Vision Encoder，比如 ViT）
• 投影层（Projection Layer）
• 统一的 Transformer
• 多模态注意力机制

优势

• 输入能力扩展显著：图像、音频、视频、文档统合处理；
• 极适合作为通用 AI Agent 的感知模块。

局限

• 成本比纯文本 LLM 更高；
• 多模态数据构建成本大；
• 输出的稳定性与高保真图像/视频理解仍有上限。

应用场景

随着 GPT-4o 全模态输入的普及，多模态 LLM 已成为企业 AI 转型的必备能力层。

RAG + LLM 混合架构：以知识增强为核心的系统形态

RAG（Retrieval-Augmented Generation）通过将外部知识库融合到推理中解决 LLM 本身无法持久更新和存储大量事实的问题。

架构

由三个核心组件构成：

• 向量数据库（Retriever）
• 文档预处理管线（Chunking, Indexing）
• 核心 LLM（Generator）

优势

• 模型无需重新训练即可持续更新知识；
• 显著增强长尾知识与事实性能力；
• 数据可控，便于企业级治理。

局限

• 依赖检索质量；
• 对 prompt 工程与 pipeline 工程化要求高；
• 多跳检索在 latency 上存在开销。

应用场景

RAG 是企业级 LLM 落地中最常见的架构。

基于代理的架构：基于智能体的系统级 LLM 架构

代表：AutoGPT、GPT-o1、GPT-o3、DeepSeek-R1、自主推理 Agent Framework

随着模型具备规划（Planning）、执行（Acting）和反思（Reflection）能力，Agent 架构正在成为应用层主流。

架构

• 多工具整合（Tool Use）
• 工作流管理
• 多轮子任务规划
• Memory 与外部状态管理

优势

• 可执行复杂任务链；
• 强化模型可控性；
• 工具能力扩展模型本身的局限。

局限

• 系统复杂度显著增加；
• 可靠性、可追踪性和可验证性要求高；
• 调度能力直接影响实际效果。

应用场景

Agent 架构代表了 LLM 应用的未来方向。

分布式训练架构：支撑万亿参数模型的底层工程

这类方案通常没有特定的架构模型，依照不同的需求，技术厂商会演进出各类方案，比如：

• ZeRO / FSDP（Fully Sharded Data Parallel）
• Megatron-LM（Tensor / Pipeline 并行）
• DeepSpeed
• Colossal-AI
• Parameter Server（SageMaker、Ray、DeepSeek 自研）

优势

• 高效训练超大模型；
• 利用 GPU 集群最大化吞吐；
• 优化显存占用。

局限

• 工程复杂度极高；
• 部署成本昂贵；
• 对 GPU 集群架构高度依赖。

应用场景

主要适用于自研大模型或千卡级 GPU 训练任务的企业或科研团队。

各架构侧重点及优势对比

以下为一张综合对比表：

如何选择适合的 LLM 架构？

基于上述介绍的 LLM 架构，我们初步了解了大语言模型本身的架构以及叠加一些应用场景的方案架构，而在 LLM 结合各个行业的真实应用场景中，架构远远不止这些，结合已有的计算机系统架构，LLM 的架构也在不断进化和丰富中，下面简单根据应用需求，推荐如下路径：

目标是开发一个企业级问答系统

Dense Transformer + 强化 RAG：可靠、易控、低成本、可持续更新。

目标是打造一个全能基础大模型系统

MoE 是优选：性能与性价比兼得。

目标是构建文档/图像/视频 AI 系统

多模态 LLM：例如 GPT-4o、Qwen-VL、Gemini。

需要自动化任务执行

基于代理的架构：模型本身不需要特别大，但需要良好的工具接口和规划能力。

需要训练和运行自研模型

FSDP / Megatron / PS-based 分布式架构，这类需求其实可选范围非常广，由于是训推整体方案，只要沿用市面成型的一体方案即可，不需要花大量时间在训练和推理框架之间做兼容。

总结

大语言模型架构的演进已经进入百花齐放阶段。Dense 模型提供稳定基座，MoE 架构带来成本与能力的突破，多模态扩展了 AI 的感知边界，而 RAG 与 Agent 架构将 LLM 推向真正可控、可执行的智能体时代。

对企业而言，选对架构比盲目追求“更大模型”更重要。依据实际需求、工程能力和预算进行架构选择，既能优化效果，也能确保长期可维护性。

这篇文章将全面介绍什么是 KV-Cache、它如何工作、为什么它能极大提升推理效率、它对行业带来了什么影响，以及在实际使用中的最佳实践。

KV-Cache 是什么？

首先，其工作原理架构图如下：

理解起来非常简单，单其中细节结合复杂度计算还是略有抽象。

KV-Cache，全称 Key-Value Cache，是在 LLM 推理过程中对 Transformer 解码器中自注意力层（Self-Attention）的中间结果进行缓存的一种方法。

Transformer 的自回归生成方式决定了： 每生成一个新 token，就需要重新计算它与全部历史 token 的注意力关系。

如果每次都把过去所有 token 的 Key 和 Value 重新计算一遍，其计算量是：

推理时间复杂度：O(n²) （n 为上下文长度）

为了避免重复计算，KV-Cache 会在每步生成 token 时，将计算后的 Key（K） 和 Value（V） 保存下来，这样之后再生成下一步 token 时就能直接引用过去的 Key/Value，而无需重新计算历史部分。

这让时间复杂度大幅下降为：

推理时间复杂度：O(n)

所以简单总结一下，KV-Cache 是在自回归解码中缓存历史 token 的 Key/Value，让后续生成直接复用过去的注意力结果，从而把时间复杂度从 O(n²) 降到 O(n)，节省的成本非常巨大。

KV-Cache 是如何工作的？

以当前主流的解码流程为例，我们以是否使用 KV-Cache 来做一个简单的对比。

如果没有 KV-Cache

每次生成新 token 时需要做：

1. 重新对全部历史序列做 embedding
2. 通过所有 Transformer 层重新计算 K/V
3. 根据新 token 与整个序列做自注意力
4. 得到新 token 并输出

具体流程图示如下：

使用 KV-Cache

第一次推理（prefill 阶段）：

1. 对所有提示词（prompt tokens）进行计算
2. 计算所有 K/V，并将它们保存在 KV 缓存中

之后的每一步（decode 阶段）：

1. 只计算当前新 token 的 K/V
2. 与缓存中的 K/V 做注意力，得到结果
3. 写回缓存

这样，每生成一个 token 的计算量从全序列规模 → 近似常数开销，越长的上下文收益越大。

其流程图示如下：

KV-Cache 带来了什么影响？

推理速度提升数十倍

对长上下文模型（8k / 32k / 128k tokens）尤其明显。

例如对 32k token 的上下文，如果没有 KV-Cache：

• 每生成一个 token 需要遍历 32k 历史序列
• 整体是 重复 32k 次的巨量工作

有了 KV-Cache：

• 历史部分只算一次
• 单步 decode 的开销变成固定量（几百维 KV 与注意力点积）

通常加速比可达到：

10 倍至 100 倍不等 （取决于提示词长度、模型大小、硬件）

推理成本大幅降低

大模型推理的成本主要由这几个部分构成：

• 算力（矩阵乘法）
• 显存占用
• 带宽

KV-Cache 能大幅降低重复算力，因此成本成比例下降。

这就是为什么：

• OpenAI、Anthropic、Meta、Mistral
• 各大云推理服务
• 所有开源推理框架

都把 KV-Cache 作为默认推理方式。

但是显存占用会变高

KV 是每一层每个 token 的结果，因此缓存本身需要巨大的显存。

例如： Llama-3 70B 模型，64K context，对 1 token 的 KV 占用约 1.5KB。

那么 64K token 就是：约 96MB × 80 层 ≈ 7.6GB 的 KV-cache

当你看到推理卡 80GB 显存不够时，很大概率是因为 KV 满了，而不是模型权重太大。

影响了模型的架构设计与行业走向

KV-Cache 的重要性高到：模型架构都围绕它做优化。

包括：

• Mistral 的滑动窗口注意力（SWA）
• Meta 的 Grouped Query Attention（GQA）
• DeepSeek 的 Multi-head Latent Attention（MLA）
• Google 的 Multi-Query Attention（MQA）

这些技术主要目的之一就是：

降低 KV-Cache 的显存占用

因为 Q 数少 → KV 也变少 → 显存压力更低。

所以 KV-Cache 不只是一个技术点，而是影响模型架构的重要因素。

KV-Cache 的性能关键因素

不同 Attention 架构带来的 KV 大小差异

Prefill 和 Decode 性能壁垒不同

• Prefill 阶段：算 K/V 很耗算力，需要好 GPU。
• Decode 阶段：显存带宽优先，因为每步生成通常 batch 很小。

这也影响推理框架的优化策略。

KV-Cache 的布局与管理

例如：

• PagedAttention（vLLM 的核心技术）
• Block-sparse KV 管理（TensorRT-LLM）
• 动态缓存分配（llama.cpp）
• 连续 vs 分块 KV 内存

优秀的分配策略可以极大减少 fragmentation 和显存浪费。

KV-Cache 的最佳实践

尽量减少上下文长度

上下文越长 → KV 越大 → 推理越慢、越贵。

如果业务允许：

• 使用 RAG 把长文档拆分
• 使用压缩模型（compressor）
• 使用短指令模板
• 引导模型减少“废话”输出

选择合适的 Attention 架构

如果你在自定义模型、微调或部署模型：

• 需要高效推理 → 优选 MQA / GQA / MLA
• 需要兼容许多任务 → MHA 仍然最稳定

使用专业推理框架

优先使用：

• vLLM（商业与开源界第一推理框架）
• TensorRT-LLM（NVIDIA 官方）
• llm-d（中小型企业的极高性价比框架）
• OpenAI Triton 引擎（内部使用）

它们都在 KV-Cache 管理上有深度优化。

多卡推理时注意 KV 分布问题

KV 会引发：

• 多卡同步开销
• all-reduce 带宽瓶颈

部分框架提供：

• KV sharding
• pipeline parallelism
• block-sparse KV sharing

合理设置可显著提升吞吐量。

批处理策略影响巨大

适配 KV-Cache 的批处理策略包括：

• continuous batching
• block scheduling
• prompt+decode 混合 batch

正确 batching 通常带来 >10× 吞吐提升。

KV-Cache 的未来展望

未来几年，模型推理的发展趋势中，KV-Cache 会继续是核心机制。

我们将看到：

• 更轻量的 KV 结构（更少头、更小维度）
• 更智能的 KV 重用机制
• KV 的跨请求共享（multi-query serving）
• 部分 KV 的 CPU/NVMe offload
• Push-down Attention（降低 GPU 带宽要求）

总之，KV-Cache 将继续驱动推理性能提升，是 LLM 推理领域最重要的基础设施之一。

总结

KV-Cache 并不是一个“可选优化”，而是现代大语言模型推理的 核心基石。 它带来巨大的速度提升，但也带来显存压力，影响模型架构、推理框架设计乃至行业整个技术路线。

理解 KV-Cache，你就理解了：

• 为什么推理这么贵
• 为什么上下文越长模型越慢
• 为什么新一代模型都在改注意力结构
• 为什么推理框架竞争如此激烈

准备工作

在开始之前，你需要：

获取 Azure 订阅

拥有一个 Azure 订阅，如果您不清楚如何获取 Azure 订阅，可以参考之前文章中的注册 Azure 订阅内容进行操作。

创建 Azure AI Foundry

首先进入您的 Azure 订阅中的 AI Foundry，展开左侧 All Resources，找到 Azure AI Foundry，点击 Create 创建一个 Azure AI Foundry：

创建时注意区域选择，由于 Sora 2 模型并未在所有 Azure 区域开放预览，这里建议选择 East US 2 区域：

1. 创建 Azure AI Foundry Project

创建完成后进入您的 Azure AI Foundry 在 All Resources 中找到 Projects，点击 New 创建一个新的 Project：

2. 打开 Azure AI Foundry Protal

创建完成 Project 后，打开您的 Project，点击 Go to Azure AI Foundry protal：

正常情况下 Azure AI Foundry Protal 如下：

3. 启用和部署 Sora 2 模型

又有 Sora 2 模型在本文发布时仍然处于预览状态，所以我们首先需要申请权限，后续开放使用后可调过本步骤，首先点击左侧的 Model catalog，可以看到 Sora 2 模型的标签，点击 Check out model：

也可以在下方的模型列表找到想要的模型进行使用。

如果您没有使用 Sora 2 模型的权限，进入 Sora 2 模型介绍界面后将如下所示：

请点击 Request access 链接进行权限申请。

如您已经拥有 Sora 2 访问权限，可以点击 Use this model 进行模型部署：

部署过程非常简单，默认保持各类选项即可进行创建部署：

部署完成后，切换左侧菜单至 Models + endpoints，查看模型列表：

至此您就拥有了属于自己的 Sora 2 模型，可以开始使用！

通过 Azure AI Foundry Playground 使用 Sora 2

Azure AI Foundry 提供了强大的可视化界面，你可以无需写代码就生成视频。

1. 进入 Playground

打开 Azure AI Foundry 左侧菜单中的 Playgrounds，选择 Video playground：

进入 Playground 后选择 Sora 2 模型：

2. 填写提示词 Prompt

示例 Prompt：

A high-energy cyberpunk chase in the rain with neon reflections on wet streets. A futuristic motorcycle speeds through, dynamic motion blur capturing its sleek design and vibrant city lights.

3. 设置选项

可调节选项包括：

4. 生成视频

设置好后，点击 Generate 进行视频生成，视频生成成功后，你可以在 Generation history 中预览或下载视频：

通过 Python 调用 Sora 2

Azure 为 OpenAI 模型提供统一的接口，可以直接在你的后端调用。

1. 安装 SDK

pip install azure-ai-openai
pip install python-dotenv

2. 配置环境变量

创建 .env 文件：

AZURE_OPENAI_ENDPOINT=https://<your-resource-name>.openai.azure.com/
AZURE_OPENAI_KEY=<your-key>
AZURE_OPENAI_API_VERSION=2024-10-01-preview

3. Python 调用示例：文生视频

下面是最简可运行示例：

import os
from dotenv import load_dotenv
from azure.ai.openai import OpenAIClient
from azure.core.credentials import AzureKeyCredential

load_dotenv()

client = OpenAIClient(
    endpoint=os.getenv("AZURE_OPENAI_ENDPOINT"),
    credential=AzureKeyCredential(os.getenv("AZURE_OPENAI_KEY")),
    api_version=os.getenv("AZURE_OPENAI_API_VERSION")
)

prompt = """
A cinematic shot of a spaceship flying through a nebula filled with colorful cosmic clouds.
"""

response = client.get_video(
    model="sora-2",
    prompt=prompt,
    duration=5,              # seconds
    resolution="1080p",
)

# 保存视频
video_bytes = response.video
with open("output.mp4", "wb") as f:
    f.write(video_bytes)

print("Video generated: output.mp4")

4. 使用结构化 payload

Sora 还支持更多控制，例如镜头、分镜头脚本、环境细节。

payload = {
    "prompt": "A cute corgi running on a beach during sunset.",
    "duration": 8,
    "resolution": "720p",
    "motion": "medium",
    "style": "realistic"
}

response = client.get_video(
    model="sora-2",
    **payload
)

with open("corgi_beach.mp4", "wb") as f:
    f.write(response.video)

生成最佳视频的技巧

1. 提示词结构推荐（General Prompt Template）

[主体对象] + [场景环境] + [动作] + [镜头效果] + [光影] + [风格]

示例：

A high-energy cyberpunk chase in the rain with neon reflections on wet streets. A futuristic motorcycle speeds through, dynamic motion blur capturing its sleek design and vibrant city lights.

2. 控制一致性

• 使用 seed 可重复生成风格一致的视频
• 合理设置 motion level 获得更自然的动作
• 提供清晰场景描述可减少模型误解

常见问题（FAQ）

1. 我试了但看不到 Sora 2？

目前需要访问权限。你需要：

• 联系 Azure 管理员
• 到模型页面确认已启用

2. 视频最大时长是多少？

具体限制依区域会有不同，通常为 ≤ 10 秒。

3. Python 生成的视频过小或无内容？

确保保存时使用 response.video 而不是错误字段。

总结

本文介绍了在 Azure AI Foundry 中使用 Sora 2 文生视频模型的两种方式：

• 使用可视化 Playground 快速体验
• 使用 Python SDK 在生产环境自动生成视频

Azure 的企业级安全合规能力让 Sora 2 成为企业落地视频生成的重要选择。

先决条件

在开始之前，请确保您拥有 Azure 国际版订阅服务，如果您还没有 Azure 订阅，可以通过 Pay-as-you-go 轻松开启一个 Azure 订阅：

注意：开启 Pay-as-you-go Azure 订阅必须绑定国际信用卡，对于新用户还有 200 美金的免费额度，我们完全可以使用这些额度充分使用 Azure 的各项服务。

下面介绍的内容除了与 GPT-4o 交互产生的费用外，其他都是免费的，日常不适用的话不会产生任何费用，GPT-4o 的费用也可以完全使用免费额度覆盖，所以大家不用担心信用卡被刷爆。

成功拥有 Azure 订阅后，然我们开始吧！

步骤 1：创建 Azure AI Studio 服务

在 Azure 订阅主页上方搜索栏中输入 azure ai，找到 Azure AI Studio：

点击进入 Azure AI Studio 资源页面：

点击 + New Azure AI Hub 进入创建页面：

从界面可以看到创建 Azure AI Hub 共分为 7 个步骤，这里按照指引一路 Next 都选择默认即可，其中需要注意的是区域建议选择 East US，由于免费订阅有一些资源使用限制，目前根据经验来看 East US 区域的使用便利性更佳。

另外是费用问题，可以参考 Azure OpenAI 费用详情页面来查看各个模型的收费情况：

创建完成后返回 Azure AI Studio 资源页面：

可以看到我们创建了一个 Azure AI hub 和一个配套的 Azure AI services 资源。

步骤 2：开始使用 Azure AI Studio

点击打开我们在第一步中创建的 Azure AI Hub 资源，我们会看到详情中醒目的 Launch Azure AI Studio 按钮：

点击后进入一个全新的 Azure AI Studio 界面：

这里将是我们主要工作的区域，点击列表中我们刚创建好的 AI Hub，当然在这里我们依然可以创建新的 AI Hub：

在 AI Hub 中，我们可以看到其相关联的所有资源：

首先我们需要创建一个 Project，点击左侧菜单中的 All projects，然后选择列表上方的 + New Project 按钮：

创建 Project 非常简单，只需要输入名称即可：

创建完成后将自动进入 Project 详情页面：

现在可以熟悉一下 AI Studio，Hub，Project 的界面，接下来我们来部署大语言模型！

步骤 3：部署 GPT-4o 大语言模型

依然在 Project 界面，在左侧菜单栏下放找到 Deployments 菜单，点击进入后选择 + Create Deployment 按钮：

在创建界面中我们看到 Azure 为我们提供了 1000 多重大语言模型可供使用，当然，它们要求的计算资源也各不相同，有兴趣可以逐个尝试（注意信用卡不要刷爆），这里我们选择 GPT-4o 模型：

选定后进入部署页面，按需修改相关选项，确认后点击 Deploy 进行部署：

部署成功后我们可以看到 GPT-4o 已经出现在我们的部署列表中：

步骤 4：部署专属 ChatGPT Web 应用

确认模型部署正常后，我们进入项目左侧菜单中的 Chat，并选择我们刚才创建的 GPT-4o 模型：

在 Chat 界面我们可以选择大语言模型，简单测试问答功能等，确认一些无误后，我们就可以开始创建专属 Web App 了，选择顶部菜单中的 Deploy to a web app：

在部署配置中输入名称，选择 Web App 想要部署的订阅，区域等信息，如果希望保存 ChatGPT 的聊天历史，可以开启最下方的选项，但会额外创建 CosmosDB 数据库服务，会产生额外费用：

确认部署后等待完成即可，如果部署正确，那么在 Chat 界面中会有一个 Launch 按钮：

点击后会打开您的专属 ChatGPT Web 界面：

注意：默认情况下我们部署的 Web App 是基于您订阅中的账户（IAM）来做用户验证的，如果您自己使用可以保持这个默认行为。

如果您有技术能力且希望对这个专属 ChatGPT Web App 做定制开发，可以前往 Git Repo 查看所有实现细节，可以按需修改为适合自己使用的版本。

总结

通过 Azure AI 相关的服务我们可以实现很多人工智能相关的实用业务场景，让我们对 AI 和 大语言模型的了解不仅只停留在铺天盖地的消息和无尽的想象，也可以亲身接触实践！