某公司正在 AWS 上開發機器學習模型，這些模型是獨立的微服務。每個微服務在啟動時會從 Amazon S3 提取大約 1 GB 的模型資料並載入到記憶體中。使用者透過非同步 API 存取 ML 模型，可以傳送單一或批次請求。該公司服務數百名使用者。使用模式不規則：有些模型可能會閒置數天或數週，而有些則會收到數千個請求的批次。哪種解決方案能滿足這些要求？

正確答案是將 API 請求導向 Amazon SQS 佇列，並將 ML 模型部署為 Amazon ECS 服務，利用自動擴展根據 SQS 佇列大小進行擴展。這種方法最適合微服務架構和不規則的工作負載。SQS 佇列能有效處理非同步請求，解耦生產者和消費者，並緩衝突發流量，避免模型過載。ECS 服務非常適合運行 ML 模型，因為它支援容器化，可以輕鬆載入 1 GB 的模型資料到記憶體中，並且能夠根據佇列大小進行自動擴展，確保在模型閒置時不產生費用，在需求高峰時快速響應。 其他選項不夠理想： 將 ML 模型部署為 AWS Lambda 函數不適合，因為 Lambda 函數的記憶體限制可能不足以載入 1 GB 的模型資料，且冷啟動延遲會影響非同步 API 的效能。 使用 ALB 或 NLB 直接導向請求到 Lambda 或 ECS，雖然可行，但對於不規則且可能長時間閒置的工作負載，直接的同步請求處理不如 SQS 的非同步處理靈活和成本效益高。特別是對於批次請求，SQS 能更好地管理工作負載。