A Google FDE RRK 式实践案例：设计生产级图像生成系统

AI拉呱：洞察AI技术前沿

一个面向生产的系统设计案例，涵盖客户调研、异步推理、Google Cloud 架构、AI 安全、评测、可靠性与成本。

重要免责声明： 这是一个原创的面试练习场景，并非泄露的、专有的或官方确认的 Google 面试题，所提出的架构也不是 Google 官方的参考设计。

在本文中，RRK 指的是与岗位相关的知识（role-related knowledge）：即运用技术判断力、生产经验和客户理解去解决一个真实工程问题的能力。

练习场景

想象面试官这样提问：

设计一个图像生成平台，让用户输入文本提示词，生成若干候选图像，精修结果，并下载或分享最终作品。

一个基础原型可以接受提示词、调用图像模型并返回结果。

而一个生产系统必须回答更棘手的问题：

客户是谁，他们想达成什么成果？
哪些请求和输出必须被拦截？
当推理耗时 40 秒时会发生什么？
如何避免重复工作和重复计费？
如何隔离企业租户？
如何衡量一张图像是否有用？
如何管理模型变更、流量峰值和推理成本？

因此，模型只是设计的一部分。完整的系统还需要身份认证、策略执行、任务调度、持久化状态、存储、评测、可观测性和运营控制。

AI拉呱：洞察AI技术前沿

1. 面试官在评估什么

这个案例测试你是否能从模糊的 AI 想法走向站得住脚的生产设计。

优秀的候选人应该展现出：

在技术选型之前先做客户调研；
清晰且有意识收敛的首个版本范围；
针对慢速、昂贵推理的生产推理；
将策略决策与技术故障分离；
安全的多租户架构；
可度量的图像质量；
成本、延迟和可靠性的权衡；
结构化的沟通表达。

一个糟糕的开场是这样：

"我会创建一个 API，把提示词发给图像模型，然后存储响应。"

一个更优秀的开场是这样：

"在选模型之前，我会先厘清用户是谁、主要的图像工作流、业务目标、延迟预期，以及客户认为不可接受的成果。"

这样的开场表明你在解决客户问题，而不是简单地对接一个接口。

2. 从客户调研开始

不要一上来就画架构图。

首先要确定谁会使用这个平台。面向消费者的创意产品、企业营销系统和电商商品图工具都可能使用图像生成，但它们的需求差异巨大。

企业营销客户可能关心：

品牌一致性；
机密的提示词与素材；
可审计性；
审批流程；
可预测的支出；
数据驻留；
知识产权风险。

接下来，定义主要工作流。平台可能支持文生图、编辑、背景替换、局部重绘（inpainting）、商品重新场景化、变体生成、超分辨率或批量生成。

不要把所有能力都塞进首个版本。

一个站得住脚的范围声明是：

"在初始设计中，我将支持文生图、2 到 4 个候选输出、历史记录、精修和下载。高级编辑和自定义模型训练不在首个版本范围内。"

业务目标也必须明确。对于企业营销平台，有价值的成果可能包括：

缩短获得已审批素材的时间；
增加营销活动实验数量；
降低外部设计成本；
提高能产出至少一张可用图像的用户占比；
降低每张被接受图像的成本。

最后，要问清楚"绝不能发生什么"。例如有害图像、欺骗性冒充、机密提示词泄露、跨租户访问和失控的推理支出。

3. 陈述假设，而不是凭空捏造事实

系统设计问题经常省略流量和存储数据。应陈述合理的假设，标注为假设性数据，并邀请面试官修改。

以下数字是说明性的面试输入，不是 Google 的产品目标或通用建议。

[站外图片上传中...(image-8544b4-1787364732396)]

这些假设大约产生：

每天 150,000 名生成用户；
每天 600,000 个生成任务；
平均每秒 6.9 个任务提交；
假设峰值下每秒 69–70 个提交；
每天 240 万张生成图像；
每天 2.4 TB 的新图像数据；
30 天约 72 TB（尚未计入缩略图、编辑、副本和临时文件）。

关键不在于预测精确的需求，而在于通过计算揭示出四个架构要求：

生成应当是异步的；
执行容量必须受到控制；
图像字节应放在对象存储中；
生命周期和成本策略是必需的。

4. 定义首个版本的需求

初始工作流如下：

用户登录并提交提示词。
API 校验请求并执行配额。
创建最小化的持久化任务记录。
执行输入策略检查。
通过的工作进入受控的执行队列。
编排器选择一个兼容的模型。
生成候选图像。
每个候选都通过输出策略检查。
通过审查的图像被私有存储。
用户收到通知，可以精修、下载或删除。

首个版本应支持：

文生图；
宽高比和候选数量选择；
任务状态查询；
历史记录；
下载和删除；
用户和租户配额；
输入与输出安全；
基础反馈与可观测性。

说明性的服务目标可能包括：

[站外图片上传中...(image-4d9948-1787364732396)]

这些是可协商的产品目标。实际生成时间取决于模型、分辨率、图像数量、区域、队列深度和策略处理。

5. 使用异步任务处理

图像生成可能需要数秒甚至更久。在整段推理期间保持原始 HTTP 请求打开，会带来超时、重试和扩展性问题。

更好的交互方式是：

[站外图片上传中...(image-639bab-1787364732396)]

示例提交：

POST /v1/generation-jobs
Idempotency-Key: 7fd2...

{
  "prompt": "A sustainable city beside a mountain lake",
  "aspect_ratio": "16:9",
  "number_of_images": 4,
  "quality_tier": "standard"
}

响应：

{
  "job_id": "gen_8fa92",
  "status": "QUEUED",
  "estimated_wait_seconds": 12
}

等待时间是一个估算值，不是保证。结果可以通过轮询、服务器发送事件（SSE）、WebSocket、推送通知或 Webhook 来交付。

6. 移动端友好的高层架构

在此插入配套的竖版架构图。

图：一个生产级图像生成工作流，从客户端和身份认证开始，经过策略、受控调度、模型路由、输出审查、存储和授权交付。

设计将职责分离：

API 负责校验、记录和准入；
持久化任务存储是状态的唯一来源；
策略层决定输入和输出是否被允许；
调度层控制速率、并发和优先级；
编排器选择兼容的模型；
对象存储保存图像字节；
元数据库存储归属、状态和血缘。

7. 一种可行的 Google Cloud 映射

这是一个站得住脚的实现方案，不是唯一正确的方案。

[站外图片上传中...(image-72b8f0-1787364732396)]

Cloud Run 是一个适合请求驱动或事件驱动服务的托管容器平台，而 Cloud Armor 为受支持的负载均衡器后面的应用提供可配置的边缘安全策略。

Cloud Storage 签名 URL 可以授予对特定对象的限时访问权限。由于任何持有有效 URL 的人都能使用它，过期时间应当很短；更严格的企业系统可能会在存储前面放置一个授权媒体服务。

元数据库应当遵循访问模式：

Firestore：用于无服务器的文档型任务状态；
Cloud SQL：用于关系型的计费、审批和项目；
Spanner：当全局关系一致性以及非常高的规模足以证明额外复杂度合理时使用。

8. 区分 Cloud Tasks、Pub/Sub 和优先级调度

Cloud Tasks 和 Pub/Sub 相关但不可互换。

Cloud Tasks 适用于平台需要调用特定 HTTP worker 并控制调度速率、并发和重试的场景。

Pub/Sub 适用于发布者应与订阅者解耦，或多个系统需要对同一事件做出反应的场景。

Google Cloud 的对比文档将其描述为：Cloud Tasks 是显式调用，Pub/Sub 是解耦的隐式调用。

对于这个系统：

用 Cloud Tasks 调用生成 worker；
用 Pub/Sub 处理完成事件、计费、分析和通知。

这两种服务都不会自动创造真正的业务优先级。

像 PREMIUM 这样的标签并不能保证高优任务先执行。真正的优先级需要：

独立的队列或订阅；
独立的调度限制；
预留的 worker 或模型容量；
加权调度；
准入控制。

例如：

企业交互式 → 预留容量
付费交互式 → 共享低延迟容量
标准       → 共享容量
批量       → 非高峰或富余容量

这才是通过隔离和容量分配实现的真正优先级。

9. 走查关键请求路径

准入

API 对用户进行认证，解析租户，校验提示词和设置，检查是否有符合条件的模型支持所请求的能力，估算成本并执行配额。

然后应用幂等性：

tenant_id + user_id + idempotency_key → job_id

使用相同 key 的重复请求会返回已有任务。为不同请求重用同一个 key 会返回冲突。

输入策略

平台评估禁止内容、上传文件安全、恶意软件、机密信息以及客户特定的限制。

此时应当已经存在一个最小化的持久化记录，这样即使请求被拦截，系统也能保留幂等性、状态和审计信息。

执行

通过的工作进入分配给其区域和流量类别的队列。

编排器使用以下条件选择模型：

所需能力；
区域可用性；
健康状态；
预期质量；
延迟；
成本；
客户策略。

输出处理

每个候选独立评估。可能的结果有：

APPROVED
BLOCKED
REQUIRES_REVIEW
TECHNICAL_FAILURE

如果四个候选中三个通过，平台可以返回三个，而不是让整个任务失败。

交付

通过审查的图像会连同其模型版本、策略版本、参数、安全决策、来源状态和保留日期一起存储。

用户获得短期授权的访问。

10. 隔离模型特定行为

业务逻辑不应在整个应用中直接调用某个模型。

定义一个与供应商无关的接口：

ImageGenerationProvider
generate(request)
edit(request)
createVariation(request)
upscale(request)
estimateCost(request)
getCapabilities()
getHealth()

能力注册表可以记录：

{
  "model_id": "image-model-a",
  "operations": ["TEXT_TO_IMAGE", "EDIT"],
  "aspect_ratios": ["1:1", "16:9", "9:16"],
  "supports_seed": true,
  "supports_negative_prompt": false,
  "supports_provenance": true,
  "regions": ["us-central1", "europe-west4"]
}

不要假设每个模型都支持相同的：

种子（seed）；
负面提示词；
参考图像；
确定性行为；
水印或来源控制；
区域可用性。

种子应被描述为在相同受支持模型和配置下的尽力可复现性，而不是永久的保证。

对于新的 Google Cloud 实现，请评估 Vertex AI 上当前受支持的 Gemini 图像生成模型，而不是照搬旧版 Imagen 示例中的参数。Google Cloud 的当前生命周期文档列出了各模型特有的发布和退役日期，这也说明了为什么模型标识符和能力应该放在抽象层后面。

11. 把安全与租户隔离当作系统属性

"模型自带安全过滤器"并不是一个充分的回答。

生产设计需要多个层次：

账户与滥用控制；
提示词审核；
上传图像与文件校验；
供应商支持的安全设置；
独立的输出审核；
在支持的情况下处理来源信息；
举报与申诉；
受限的人工审查；
策略版本管理。

系统应记录策略版本、审核版本、决策和申诉结果。

策略状态还必须与技术状态分离：

[站外图片上传中...(image-7beaca-1787364732396)]

每种结果需要不同的重试、计费和用户消息行为。

每个资源都必须携带租户上下文。访问应校验：

authenticated_tenant_id == job.tenant_id
AND user_has_permission(job.project_id)

提示词可能包含未发布的产品、内部活动或个人隐私信息。应明确界定它们的日志、加密、保留、训练使用和员工访问策略。

区域级故障转移绝不能悄悄违反客户的数据驻留协议。

12. 为重复投递和部分失败而设计

异步系统必须假设一个任务或事件可能被投递不止一次。

在调用昂贵的模型之前，worker 应该：

读取持久化任务；
确认允许执行；
获取执行租约；
记录尝试标识符；
保存供应商请求标识符。

只重试瞬时问题，如临时供应商故障、连接重置或临时存储错误。

不要重试无效请求、安全拦截、不支持的特性或预算耗尽。

一个说明性的重试策略可能允许三次尝试，带指数退避和抖动。具体数值取决于产品目标。

一个棘手的情况是：供应商已完成生成，但 worker 在记录结果之前崩溃。缓解措施包括：在可用时使用供应商幂等性、持久化请求标识符、对账检查，以及在重试前验证输出是否已存在。

现实目标是客户结果的有效一次（effectively-once），而不是在外部服务之间实现简单的精确一次（exactly-once）执行保证。

一个紧凑的状态模型是：

RECEIVED
→ VALIDATING
→ INPUT_POLICY_CHECK
→ QUEUED
→ DISPATCHED
→ GENERATING
→ OUTPUT_POLICY_CHECK
→ COMPLETED

侧翼状态包括：

REJECTED
BLOCKED
RETRY_PENDING
PARTIALLY_COMPLETED
FAILED
CANCELLED
EXPIRED

13. 评估有用性，而不只是视觉效果

"看起来不错"不是生产质量的度量标准。

要从多个维度评估：

提示词遵循度： 物体、颜色、数量和关系。
视觉合理性： 解剖结构、光照、透视和伪影。
文字渲染： 存在性、拼写、清晰度和位置。
安全性： 有害输出泄露和误拦截。
品牌合规： 颜色、标识、已批准的产品和禁用元素。
用户有用性： 接受、下载、发布和重新生成率。

复杂的提示词应分解为可测试的断言。

例如：

雪地小镇广场上，一辆红色自行车旁有三把黄色雨伞。

这可以拆解为：

恰好三把雨伞；
雨伞是黄色的；
有一辆自行车；
自行车是红色的；
可见雪；
场景是小镇广场；
所要求的空间关系被满足。

像 TIFA 这样的研究通过可解释的问答检查来评估提示词忠实度，而不是只依赖单一的相似度分数。

人工评估也应当是结构化的。RichHF-18K 展示了能够识别不可信图像区域以及缺失或错误表示的提示词概念的反馈。

一个实用的发布门禁结合了：

自动化断言检查；
成对人工比较；
安全回归测试；
品牌关键用例；
延迟和成本阈值；
在线接受与重新生成行为。

14. 监控完整旅程

用户体验的不只是模型推理：

总延迟
=
API 处理
+ 输入策略
+ 队列等待
+ worker 获取
+ 模型推理
+ 输出策略
+ 存储
+ 通知

关键指标包括：

[站外图片上传中...(image-94bcba-1787364732396)]

每张被接受图像的成本（cost per accepted image）通常比每次 API 调用的成本更有用，因为更贵的模型可能需要的重新生成次数更少。

在 API、策略服务、任务创建、worker、供应商调用、存储和通知之间传播同一个 trace 上下文。Cloud Trace 用来展示分布式操作耗时多长、延迟花在哪里。

调试突然的延迟飙升

当 p95 完成时间翻倍时：

确认变化何时开始、是哪个百分位移动了；
按租户、区域、模型、分辨率和流量类别分段；
对比队列时间、推理时间、输出策略和存储；
检查最近的部署和路由变更；
检查队列年龄、调度限制、worker 容量和重试放大；
按模型和区域对比供应商错误与延迟；
缓解手段：暂停批量任务、路由兼容流量、减少候选数量或收紧准入；
保存事件时间线、trace 和配置版本。

在证明推理是慢速环节之前，不要先怪罪模型。

15. 控制成本、过载和上线风险

当流量飙升时，不要无限制地接收工作，让队列无限增长。

应当使用：

每租户速率限制；
并发任务限制；
队列调度控制；
预留容量；
候选数量限制；
低成本草稿模型；
渐进式生成；
存储过期；
优雅拒绝。

一个有用的渐进式工作流是：

生成便宜的预览；
让用户选择一个；
只创建或超分放大被选中的结果。

对于首个版本，从托管模型开始，放在供应商无关的接口后面。只有在测量了持续流量、定制需求、区域约束、成本以及组织可靠运维 GPU 推理的能力之后，再考虑自托管。

以受控试点方式上线：

一个团队；
一个区域；
一组受限的用例；
发布前人工审批；
明确的预算；
每周质量和安全评审。

新模型应通过离线评估、内部测试、小规模金丝雀发布和受控扩展之后，才能承载全部生产流量。

45 分钟面试时间结构

第 0–5 分钟：调研

厘清用户、工作流、业务目标、规模和不可接受的成果。

第 5–10 分钟：范围与假设

定义 MVP，并陈述说明性的流量、存储和延迟假设。

第 10–20 分钟：架构

画出从客户端经 API、策略、调度、模型、输出检查、存储到交付的路径。

第 20–30 分钟：深挖

选择一到两个领域：任务调度、模型路由、安全、幂等性、租户隔离或评测。

第 30–38 分钟：故障与扩展

讨论重试、重复投递、供应商故障、取消、过载和部分完成。

第 38–43 分钟：指标、成本与上线

覆盖延迟、接受率、安全、每张被接受图像的成本和模型发布门禁。

第 43–45 分钟：总结

以你最重要的权衡和初始实现选择收尾。

一页纸口头回答框架

厘清客户、工作流、业务成果和不可接受的输出。
定义 MVP，并把规模假设标注为说明性。
因为推理又慢又贵，所以使用异步任务。
画出 API → 输入策略 → 受控调度 → 模型 → 输出策略 → 存储。
用 Cloud Tasks 做受控的 worker 执行，用 Pub/Sub 做生命周期事件。
按能力、区域、健康、质量和成本路由模型。
使用幂等性、执行租约和有界重试。
分离被拦截、被拒绝、失败和部分完成的状态。
强制执行租户隔离和私有媒体交付。
评估提示词遵循度、安全、用户接受度和每张被接受图像的成本。
调试前先分解端到端延迟。
通过评估、金丝雀发布和受控试点上线。

候选人面试评分卡

[站外图片上传中...(image-dc30db-1787364732396)]

这是一个原创的练习评分标准，不是 Google 官方的招聘评分卡。

结论

最强的答案不是画了最多方框的架构。

而是保持了清晰推理链的答案：

客户问题
→ 用户工作流
→ 明确假设
→ 可度量需求
→ 架构决策
→ 安全与故障控制
→ 评测与可观测性
→ 业务成果

原型证明的是"模型能生成图像"。

生产系统必须证明的是：工作流有用、安全、可靠、可度量、可负担且可运维。

这就是一个优秀的 FDE 候选人应该带到讨论中的视角。

来源与延伸阅读

Google Cloud 关于 Cloud Tasks 与 Pub/Sub 对比的文档。
Google Cloud 关于 Cloud Run 和 Cloud Armor 的文档。
Google Cloud 关于签名 URL 和 Cloud Trace 的文档。
Google Cloud 模型发布与生命周期文档。
TIFA: Accurate and Interpretable Text-to-Image Faithfulness Evaluation with Question Answering（TIFA：基于问答的文本到图像忠实度评估）。
Rich Human Feedback for Text-to-Image Generation（面向文生图的丰富人类反馈）。

AI拉呱：洞察AI技术前沿