概述
The design must meet the task’s reliability, data, latency, and cost constraints. A powerful accelerator is only one component of that design.
主要要点
- Separate workloads by their operating needs.
- Enforce data and permission boundaries.
- Design capacity, retries, and rollback together.
深入探讨
Separate interactive and background workloads where their requirements differ. A user waiting for an answer needs bounded response time, while batch processing can use queues and longer-running jobs. Make queue status and retry behavior observable. Define data boundaries and access roles. Documents, embeddings, model artifacts, and logs may have different retention and permission requirements. Keep credentials in appropriate secret management and avoid assuming that network location alone establishes authorization. Plan for capacity changes and dependency failures. Autoscaling can take time, model loading can be expensive, and a provider can impose rate limits. Use admission controls, backpressure, bounded retries, and clear unavailable states to prevent one overloaded dependency from overwhelming the whole service. Version the deployment and test recovery. Check compatible model and preprocessing versions, data migrations, and rollback procedures. Measure cost per useful completed task, including storage, transfer, failed attempts, and idle resources. A low price for one API call may hide a more expensive overall workflow.
04工作示例
Avoid retry amplification
Imagine 100 application workers calling one rate-limited model endpoint. Each failed request is retried immediately five times.
The extra attempts increase load without adding endpoint capacity.
Apply a bounded retry policy that respects provider backoff, limit concurrent requests, and show the queue or unavailable state to users.
它显示了什么
This constructed example explains how architecture can prevent an overload from spreading.
现实世界的实施
Use a durable queue for document processing with visible status and safe retries.
Separate model-serving capacity from ordinary web-request handling.
付诸实践
为什么这很重要
- 成本与预算. 多年来，架构决策决定着性能和运营成本。
- 更清晰的判决. 技术教育帮助团队选择正确的堆栈，而不仅仅是最新的堆栈。
- 质量控制. 更好的工程选择可以减少生产中的可靠性事故。
留意
- 优化一项基准测试可以隐藏更广泛的系统弱点。
- 基础设施和维护成本常常被低估。
- 随着系统变得更加复杂，安全性和可观察性差距可能会扩大。
后续步骤
- 在实施之前定义延迟、质量和成本目标。
- 在实际负载和数据条件下进行基准测试。
- 仪器监控错误、漂移和用户影响。
- 在扩展之前准备回滚和事件响应路径。
资料来源与延伸阅读
- Google CloudMLOps architecture and automation
不断探索
常见问题
Does autoscaling eliminate rate limits?
No. A downstream service may retain its own limits regardless of how many application instances you run.