在当前 AIGC 迅猛发展的时代，技术与应用场景的融合正以前所未有的速度推进。
从全球范围来看，生成式 AI 已经从单一的内容生产工具，快速演化为全产业链赋能的核心引擎。如，OpenAI 的 GPT 系列模型在文本生成领域奠定了标杆，而 MidJourney、 Stable Diffusion、Flux、DALLE 等在图像生成领域掀起了创作革命。音乐、视频等领域也在蓬勃发展。在中国，各大科技公司争相布局，AIGC 正广泛渗透至社交媒体、电商、影视文娱、教育和企业服务等领域。
无论是文本生成、图像生成，还是视频、音频内容的自动化生成，AIGC 技术的广泛应用推动了创新型产品的诞生。然而，随着用户需求的增长和复杂度的提高，AIGC 产品的工程架构面临着日益严峻的扩展性挑战。如果架构设计不当，AIGC 系统可能在性能、稳定性和可维护性方面遇到瓶颈，难以支撑业务的长期发展。
本文分为两个大的部分：一个是从架构设计原则、数据处理、模型管理、计算资源分配、服务治理及弹性扩展等多个方面，简单探讨如何设计和实现具有良好扩展性的 AIGC 产品工程架构；另一个是从一个 AIGC 创业公司的角度来看，如何基于开源模型做好 AIGC 产品工程架构的扩展性。
1. 扩展性为何是 AIGC 产品的核心需求？
AIGC 产品的架构设计不同于传统的互联网系统，其扩展性的需求来源于以下几个方面：
-
模型规模与复杂性：AIGC 的核心是大规模预训练模型（如 GPT、Stable Diffusion 等）。这些模型通常包含数十亿甚至数千亿参数，对计算资源和存储的要求极高。 -
用户需求的多样性：用户可能会要求生成不同风格的内容，甚至需要定制化的模型，这对系统的灵活性提出了更高要求。 -
实时性和吞吐量：在实际业务场景中，AIGC 产品需要在高并发情况下保持生成内容的低延迟，同时保证生成结果的质量。因为 AIGC 产品的生成速度很慢，无法做到秒级的生成，从而导致单机服务的吞吐量很低，一定存在某种意义上的排队状态，如果一个用户大量生成可能会形成事实意义上的攻击行为。 -
跨领域扩展：AIGC 产品可能需要支持多种模态（文本、图像、音频等）和多种语言，这要求系统具有良好的可扩展性以支持多模态任务。 -
成本控制与效率优化：随着用户规模的扩大，系统需要能够动态调整计算资源，以实现性能与成本之间的平衡。而 AIGC 的成本大头在于 GPU 机器的成本，如何在用户体验和成本之间保持平衡是需要考虑的点。
2. AIGC 产品工程架构扩展性的核心设计原则
在设计 AIGC 产品的工程架构时，需要遵循以下核心原则：
-
模块化设计：将系统划分为多个独立的模块（如模型训练、推理服务、数据存储、任务调度等），以便于单一模块的优化和扩展。例如，将模型推理与任务高度分离，使两者可以独立扩展。
-
分布式架构：采用分布式架构以支持横向扩展。随着用户量或计算需求的增长，可以通过增加节点的方式扩展系统能力，而不是依赖单点硬件的性能提升。分布式部署不仅仅是在应用服务层面，在模型推理层面也一样。
-
无状态化服务：AIGC 推理服务天生自带无状态逻辑，我们在实际架构过程中不要将状态引入到推理服务中，如任务状态等，以让服务实例可以动态扩缩容，便于应对高并发请求。
-
异步与事件驱动：通过消息队列或事件驱动架构（如 Kafka、RabbitMQ），解耦系统中的各个模块，减少同步调用的阻塞问题，提高系统的弹性和吞吐能力。
-
弹性调度：利用容器编排工具（如 Kubernetes）实现计算资源的弹性调度，根据负载动态调整资源分配。或者使用云的弹性能力，如 Serverless 或者定制的 GPU 弹性调度服务。这些都要求上面的无状态及分布式架构先落地。
-
可观测性：构建完善的监控和日志系统，确保能够实时监测系统性能，定位和解决瓶颈问题，或者定位用户的问题。因为 AIGC 现在本身会存在较大的抽卡情况，有时很难复现一些 badcase，更加需要有完善的日志来辅助定位。
3. AIGC 产品架构扩展性的关键技术实现
3.1 数据处理的扩展性
AIGC 产品的数据处理链路通常包括数据采集、清洗、存储和分发。要确保数据处理的扩展性，需要关注以下几点：
-
数据存储设计：使用分布式存储系统（如 HDFS、Ceph）以应对海量数据存储需求，确保数据存取的高效性和可靠性。 -
数据管道工具：采用 Apache Airflow、Flink 等工具构建可扩展的数据处理管道，支持流式和批量处理。 -
缓存机制：对于频繁访问的数据（如热词、模型中间结果），可以引入 Redis 或 Memcached 等缓存系统，加快数据访问速度。
3.2 模型管理的扩展性
模型是 AIGC 产品的核心，模型管理的扩展性直接影响系统性能。
-
模型版本管理：通过模型仓库对模型进行版本化管理，支持模型的快速切换与回滚。 -
模型加载优化：采用分布式推理框架（如 TensorRT、DeepSpeed），实现模型的分片加载和分布式推理，避免单节点内存瓶颈。 -
多模型支持：通过模型路由机制，根据请求动态选择最适合的模型执行推理任务。多模型支持需要有更多一到两层的业务抽象，以达到多模型支持的灵活性和扩展性。
3.3 推理服务的扩展性
推理服务是 AIGC 产品的性能瓶颈所在，优化其扩展性是关键。
-
GPU/TPU 弹性调度：结合 Kubernetes，实现 GPU/TPU 资源的动态分配，提高推理任务的资源利用率。或者使用云的弹性能力，如 Serverless 或者定制的 GPU 弹性调度服务。这些都要求上面的无状态及分布式架构先落地。 -
批量推理：通过批处理（batching）技术，合并多个用户请求，减少推理调用的频率，提升吞吐量。批量处理需要在用户量达到一定级别后才能使用。 -
压缩与加速：使用模型剪枝、蒸馏和量化等技术，减少模型的计算开销，提升推理速度。对于推理模型的优化需要有实力的公司才能进行。
3.4 计算资源的扩展性
AIGC 产品对计算资源的需求波动较大，合理的资源调度是扩展性的基础。
-
动态扩展计算资源：结合云服务（如 AWS、Azure、GCP）或混合多云架构，根据业务负载动态调整计算资源。 -
多级资源池：划分不同优先级的资源池，例如将高优先级任务分配到独占资源池，低优先级任务分配到共享资源池，以提高资源利用率。如我们常见的开会员能加速。 -
边缘计算：对于部分低延迟需求的任务，可以通过边缘节点分担中心计算的压力。如将一些计算和推理任务放到端来进行，以音频为例，在端上做 TTS 是一种方案，或者一些视频的逻辑，AIGC 的生成并不是最终的视频，可能是视频生成过程中的关键参数，而最终视频的生成在端上进行。
3.5 服务治理与弹性扩展
在微服务架构下，服务治理和弹性扩展对系统的稳定性至关重要。
-
服务发现与负载均衡：结合服务网格实现服务的自动发现及流量分配，避免单点故障。 -
弹性扩缩容：设置自动扩缩容策略，例如根据 CPU/GPU 利用率或请求队列长度动态调整服务实例数量。 -
限流与降级：在高负载情况下，通过限流和降级机制保护核心服务，避免系统崩溃。
4. AIGC 生图项目的扩展性
以上是一些大的概念，或者一些原则方向性的逻辑，落到具体的业务场景，以一个实际的 AIGC 生图项目为例，假设其底层为常见的 SD 或者 Flux 都有，那如何做产品工程架构，以能保障其扩展性。
这类项目的核心挑战在于如何构建一个高效、灵活且可持续扩展的产品工程架构，以满足不断变化的业务需求和技术迭代。
4.1 核心问题
生图项目的扩展性需要解决以下核心问题：
-
吞吐量低：当前生成模型对计算资源依赖较高，单次生成往往需要显著的 GPU 高性能算力支持，导致无法高效处理大量用户请求。随着用户量级的增长，模型吞吐量成为主要瓶颈。 -
成本高：模型推理和训练成本居高不下。无论是运行在云端的 GPU 集群，还是部署在本地的高性能硬件，都会带来显著的成本压力，尤其在大规模业务落地时，成本问题显得尤为严峻。 -
需求多样性：用户需求逐渐从简单的图像生成转向多样化场景，例如特定风格的图片生成、分辨率调整、多模态输入（如文本+草图生成图像）等。这要求系统具备灵活的适配能力，同时支持快速开发和迭代。
4.2 解决方案：排队系统
在 AIGC 生图项目中，吞吐量低的主要表现之一是用户请求大量堆积，导致排队时间过长，进而影响用户体验。排队系统的设计目的是优化任务处理流程，在有限的计算资源下尽量提高效率，同时保证任务的公平性和优先级处理。以下是排队系统设计的核心思路：
1. 请求分类与优先级划分
为了更好地管理排队任务，需要对请求进行分类和优先级划分：
-
实时任务 vs 异步任务：
根据业务需求，将任务分为实时任务（需立即返回结果）和异步任务（允许较长的处理时间）。简单一些，一些前置的需求，需要快速处理的，如抠图这种是实时任务，走同步等待返回的逻辑，而 SD 生成是异步任务，走任务排队系统。 -
用户优先级：
不同用户可以设置不同的优先级，例如：-
普通用户：默认优先级，排队处理。 -
高级用户（如付费用户）：分配更高优先级，减少等待时间。
-
-
任务复杂度：
根据任务的资源消耗（如分辨率高低、生成图片数量等），对任务进行复杂度打分，优先处理低资源消耗的任务，从而提升整体吞吐量。
2. 任务队列设计
任务队列是排队系统的核心，通常可以考虑以下设计思路：
-
多队列模型：
-
按优先级划分多个队列（如高优先级队列、普通队列、低优先级队列）。 -
不同队列分配不同的资源比例。例如，高优先级队列占用 70% 的算力资源，普通队列占 20%，低优先级队列占 10%。
-
-
队列动态调整：
根据系统负载和当前任务积压情况，动态调整各队列的资源分配。例如，在高优先级队列空闲时，可以临时分配部分资源处理普通队列任务。 -
限流机制：
在入口处对用户请求进行限流，限制单用户的请求频率，避免某些用户的高频请求导致系统过载。
3. 调度策略
任务调度是排队系统的关键，合理的调度策略可以最大化资源利用率并减少等待时间：
-
优先级调度：
-
按任务优先级从高到低依次分配资源。 -
对于相同优先级的任务，采用先进先出（FIFO）原则。
-
-
时间片轮转：
为不同优先级的队列分配时间片，避免低优先级任务长期得不到处理。 -
批量处理：
对于类似需求的任务（如分辨率相同的图片生成），可以将其合并为一个批量任务，利用模型的并行能力（如 GPU 的批次处理）提升吞吐效率。
4. 任务状态管理
为了保证任务从排队到完成的全流程可控，需要设计任务状态管理系统：
-
常见任务状态：
-
等待中（Queued）：任务已进入队列，等待分配资源。 -
处理中（Processing）：任务已分配资源，正在执行。 -
已完成（Completed）：任务处理完成，结果已返回。 -
失败/重试（Failed/Retrying）：任务因故失败，可根据策略进行重试。
-
-
状态监控与通知：
通过后台系统实时监控任务状态，并向用户提供任务进度反馈（如显示“等待中，预计还需 30 秒”）。
5. 异步排队与回调机制
对于非实时任务，采用异步排队机制可以缓解吞吐量压力，同时提高用户体验：
-
异步排队：
用户提交任务后立即返回「任务已提交」的响应，任务进入队列等待处理。 -
任务回调：
任务完成后，通过回调接口或通知系统（如 Webhook、短信、邮件）向用户发送结果，避免用户长时间等待。
6. 分布式队列与扩展性
为支持大量并发请求和高吞吐量，可采用分布式队列技术：
-
消息队列工具：
使用 RabbitMQ、Kafka 或 Redis 等分布式消息队列框架，确保任务队列的高可用性和可扩展性。 -
水平扩展：
随着任务量增加，可以通过增加队列节点或任务处理节点的方式，实现系统的水平扩展。 -
队列持久化：
为防止任务队列因系统故障丢失，可对任务队列进行持久化存储（如写入数据库或磁盘）。
7. 示例架构
以下是一个典型的排队系统架构示意：
+--------------------+
| 用户请求入口 |
| (Web/App/API) |
+--------------------+
|
v
+--------------------+
| 限流与分类模块 |
+--------------------+
|
v
+--------------------+ +----------------+
| 高优先级队列 | -->| 高优先级处理器 |
+--------------------+ +----------------+
|
v
+--------------------+ +----------------+
| 普通任务队列 | -->| 普通任务处理器 |
+--------------------+ +----------------+
|
v
+--------------------+ +----------------+
| 低优先级队列 | -->| 低优先级处理器 |
+--------------------+ +----------------+
4.3 分层架构
AIGC 系统的分层架构将复杂的生成任务逐层拆解，从底层技术实现到最终用户体验，形成一个职责清晰的完整闭环。这种架构不仅能够提高系统的可扩展性，还能为不同角色的参与者（算法工程师、设计师、产品运营和用户）提供明确的接口和关注点。以下是四层架构的详细描述：
1. 模型层（面向算法工程师）
模型层是整个 AIGC 系统的核心技术基础，直接负责生成内容的能力，其职责主要包括：
-
统一模型 API：
提供对各种生成模型（如 Stable Diffusion、LoRA、DreamBooth）的统一接口，方便系统调用，避免直接暴露模型内部复杂性。通过统一 API，可以实现对不同模型的无缝替换和升级。 -
参数管理与默认值设定：
提供模型参数的灵活配置（如生成质量、分辨率、样式等），同时设定合理的默认值，降低上层使用者的学习和操作成本。 -
适配多样化需求：
模型层需要处理各种输入需求（如文本描述、图像提示、草图等），并生成多样化的输出（如高分辨率图像、特定风格的图片等），从而满足不同场景的要求。 -
优化与扩展：
支持模型的持续优化（如蒸馏、量化）和扩展（如引入新模型或定制化模型训练），以应对性能和功能需求的变化。
核心任务：
提供高效、灵活的「生成能力」，同时为上层的管线和产品层提供稳定的技术支撑。
2. 管线层/模板层（面向设计师）
管线层/模板层是模型层与产品/场景层的桥梁，其核心职责是将底层模型的能力组织成可复用、可扩展的生成逻辑。它的关键特点包括：
-
模型组合与调度：
支持多模型的组合调用，例如通过 Stable Diffusion 生成一张初始图像，再通过 LoRA 微调生成特定风格的版本。管线层负责定义这些流程并确保执行的顺序与逻辑一致。 -
输入输出的格式化：
对输入（如文本、图像、参数）进行预处理，并将模型层的输出标准化为产品层可以直接使用的形式。这样可以减少各层之间的耦合，提高系统稳定性。 -
Prompt 模板与参数优化：
针对特定的生成需求（如二次元风格、古风艺术），设计 Prompt 模板和参数默认值，确保生成结果的质量和一致性。通过管线层的优化，可以让不同风格或场景的生成逻辑更加清晰、易用。 -
多场景适配：
通过灵活的管线配置，将复杂的生成逻辑抽象化，适配不同的业务场景。例如，将生成逻辑切分为“基础内容生成”和“后期优化”两个阶段，方便业务团队快速调整。
核心任务：
将模型的底层能力抽象为可复用的生成流程，并为产品/场景层提供灵活的接口。
3. 产品/场景层（面向运营）
产品/场景层是 AIGC 系统面向具体业务场景的实现层，负责把技术逻辑包装成用户可以直接使用的功能。其主要职责包括：
-
场景化产品设计：
基于管线层定义的生成逻辑，创建针对特定场景的产品功能。例如，「生成二次元角色」场景可以提供角色描述、表情选择等参数化的输入选项，而「自然风景生成」场景则可以让用户选择天气、时间、色调等。 -
Prompt 模板与参数预设：
针对不同的用户群体（如普通用户、专业设计师），提供预设的 Prompt 模板和参数设置，使用户能够快速生成高质量结果，同时降低学习成本。 -
用户反馈与产品优化：
收集用户生成内容的反馈数据，并基于这些数据对产品的 Prompt 模板、生成逻辑和参数配置进行持续优化，以提升用户体验和生成效果。 -
易用性与封装：
将复杂的后台生成逻辑封装为简单直观的用户操作界面（UI）。例如，提供滑块或选项卡让用户调整风格，而不需要直接修改复杂的参数。
核心任务：
将技术能力转化为“场景化生成”功能，使用户能以简单的方式完成复杂的内容创作。
4. 范例层（面向用户）
范例层是 AIGC 系统与终端用户的交互窗口，通过直观的案例和模板引导用户快速理解和使用产品，其主要职责包括：
-
范例展示：
提供一系列精心设计的生成案例，展示系统的最佳生成效果。例如，展示不同风格的图片生成案例（卡通、写实、艺术风格等），帮助用户了解系统的能力。 -
快速上手模板：
针对典型场景或用户需求，提供一键生成模板。例如，“生成梦幻城堡”模板可以预设场景描述和风格参数，用户只需简单调整即可生成理想结果。 -
用户定制化支持：
允许用户基于范例进行自定义调整，例如修改 Prompt 描述、调整生成细节，帮助用户快速实现个性化需求。 -
引导与教育：
通过范例和案例，直观地引导用户理解 Prompt 的写法、参数的作用等，降低使用门槛。
核心任务：
通过直观的示例和模板设计，帮助用户快速上手生成内容，并展示产品的最佳能力。
5. 分层架构的价值
这种分层架构设计清晰地将系统职责划分为四个层次，每一层的关注点和目标都非常明确：
-
模型层：提供底层的生成能力，重点解决算法实现与性能优化问题。 -
管线层：负责将底层能力组织成高效的生成逻辑，适配多场景需求。 -
产品/场景层：将技术逻辑转化为场景化功能，满足用户的实际业务需求。 -
范例层：通过直观的案例和模板，降低用户的学习门槛，提升产品易用性。
这种架构从技术到用户体验形成闭环，不仅提升了系统的扩展性与灵活性，还明确了不同角色（算法工程师、设计师、运营、用户）在系统中的职责分工，为 AIGC 系统的持续迭代与优化提供了良好的基础。
5. 小结
在 AIGC 技术迅猛发展的背景下，扩展性问题不仅是一项工程挑战，更是对技术哲学和商业逻辑的深刻考验。作为生成式 AI 的核心能力，扩展性直接影响系统能否适应未来需求的变化，也决定了企业在技术迭代与资源约束下的生存能力。它的本质并非仅仅追求更强的性能，而是如何在有限的资源下实现对复杂需求的灵活响应。这种能力不仅关乎技术架构的设计，更体现了对系统可持续性和创新潜力的深刻理解。
扩展性并非一成不变的技术标准，而是动态平衡的艺术。它要求在性能、成本、用户体验之间找到最佳交点，同时具备应对不确定性的弹性。随着用户需求的多样化和业务场景的复杂化，AIGC 产品的扩展性不仅需要解决当前的瓶颈，更要为未来的可能性预留空间。技术的价值不在于一时的领先，而在于能否构建一个经得起时间考验、能够持续演进的系统。
在更深层次上，扩展性不仅仅是技术问题，也是企业战略的体现。它决定了技术的边界、产品的规模以及用户体验的高度。当技术走向规模化应用时，扩展性已经不再只是代码和架构层面的设计，而是对企业如何在市场竞争中实现长期主义的深度思考。真正优秀的扩展性设计，不仅解决当下的问题，更为技术创新与业务增长打开了无限可能。