你在Azure上的AI实验正在烧钱——这样解决

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

如果你现在正在Azure上构建AI驱动的应用，你可能已经注意到一件事：你的云账单看起来和以前不一样了。不只是更高了——更奇怪了。波动很大，难以预测。

Microsoft刚刚发布了一篇关于仍然重要的云成本优化原则的优秀文章，说实话，时机再好不过了。因为AI工作负载在成本方面已经改变了游戏规则。

为什么AI工作负载不一样

事情是这样的。传统的.NET工作负载相对可预测。你了解你的App Service层级，了解你的SQL DTU，可以相当准确地估算每月开支。AI工作负载呢？完全不是这么回事。

你在测试多个模型看哪个合适。你在启动GPU支持的基础设施进行微调。你在调用Azure OpenAI的API，而token消耗量会因prompt长度和用户行为的不同而产生巨大差异。每个实验都要花真金白银，你可能需要运行几十次才能找到正确的方法。

这种不可预测性正是成本优化至关重要的原因——不是事后才想到，而是从第一天开始。

管理与优化——了解区别

文章中有一个我认为开发者容易忽视的区别：成本管理和成本优化是不同的。

管理是跟踪和报告。你在Azure Cost Management中设置预算，收到警报，查看仪表板。这是基本功。

优化是你真正做决策的地方。你真的需要S3层级，还是S1就能处理你的负载？那个始终运行的计算实例周末是不是闲着？你能否用竞价实例来跑训练任务？

作为.NET开发者，我们往往专注于代码，把基础设施决策留给"运维团队"。但如果你在Azure上部署，这些决策也是你的决策。

真正有效的方法

根据这篇文章和我自己的经验，以下是真正能产生效果的做法：

了解你在花什么钱、花在哪里。 给你的资源打标签。我是认真的。如果你无法分辨哪个项目或实验在消耗你的预算，你就无法优化任何东西。配合适当标签的Azure Cost Management是你最好的朋友。

实验之前设好护栏。 使用Azure Policy限制dev/test环境中昂贵的SKU。为你的Azure OpenAI部署设置消费上限。不要等到账单到了才发现有人让GPU集群在周末一直运行。

持续进行合理配置。 原型阶段选的那个VM？可能不适合生产环境。Azure Advisor会给你建议——真的去看看。每月审查，而不是每年。

考虑生命周期。 开发资源应该关闭。测试环境不需要7×24小时运行。使用自动关机策略。特别是对于AI工作负载，考虑使用按执行付费的无服务器选项，而不是让计算资源一直保持运行。

衡量价值，而不仅仅是成本。 这一点容易忘记。一个成本更高但能产出显著更好结果的模型可能才是正确的选择。目标不是花最少的钱——而是花得聪明。

总结

云成本优化不是一次性的清理工作。它是一个习惯。随着AI工作负载让开支比以往任何时候都更难预测，尽早养成这个习惯可以帮你避免日后的痛苦惊喜。

如果你是一名在Azure上构建的.NET开发者，开始像对待代码一样对待你的云账单吧——定期审查，混乱时重构，永远不要在不了解成本的情况下部署。

Azure Smart Tier 正式发布 — 无需生命周期规则即可自动优化 Blob Storage 成本

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

如果你曾经花时间调整 Azure Blob Storage 的生命周期策略，然后看着它们在访问模式变化时土崩瓦解，那这篇文章就是为你准备的。微软刚刚宣布了 Azure Blob 和 Data Lake Storage 的 smart tier 正式发布 — 这是一项完全托管的分层功能，根据实际使用情况自动在 hot、cool 和 cold 层之间移动对象。

Smart tier 实际做了什么

概念很简单：smart tier 持续评估存储账户中每个对象的最后访问时间。频繁访问的数据保持在 hot 层，不活跃的数据在 30 天后移到 cool 层，再过 60 天移到 cold 层。当数据被再次访问时，立即提升回 hot 层。循环重新开始。

无需配置生命周期规则。无需预测访问模式。无需手动调优。

在预览期间，微软报告称 超过 50% 的 smart tier 管理容量根据实际访问模式自动转移到了更冷的层级。对于大型存储账户来说，这是一笔可观的成本节省。

为什么这对 .NET 开发者很重要

如果你正在构建生成日志、遥测数据、分析数据或任何类型的不断增长的数据资产的应用 — 说实话，谁不是呢 — 存储成本会很快累积起来。传统的做法是编写生命周期管理策略，测试它们，然后在应用的访问模式变化时重新调整。Smart tier 完全消除了这个工作流。

一些实用的场景：

应用遥测和日志 — 调试时是 hot，几周后几乎不再访问
数据管道和 ETL 输出 — 处理期间频繁访问，之后大多处于 cold 状态
用户生成内容 — 最近上传的是 hot，较老的内容逐渐变冷
备份和归档数据 — 偶尔因合规需要访问，大部分时间处于闲置状态

如何设置

启用 smart tier 是一次性配置：

新账户：在创建存储账户时选择 smart tier 作为默认访问层（需要区域冗余）
现有账户：将 blob 访问层从当前默认值切换到 smart tier

小于 128 KiB 的对象保持在 hot 层，不产生监控费用。其他所有对象按照标准 hot/cool/cold 容量费率计费，没有层级转换费用，没有提前删除罚金，没有数据检索成本。每个对象的月度监控费用涵盖编排服务。

需要了解的权衡

Smart tier 的分层规则是固定的（30 天 → cool，90 天 → cold）。如果你需要自定义阈值 — 比如某个特定工作负载在 7 天后移到 cool — 生命周期规则仍然是正确的选择。而且不要混用：避免对 smart tier 管理的对象使用生命周期规则，因为它们可能会产生冲突。

总结

这算不上革命性的改变，但它解决了一个实实在在的运维痛点。如果你管理着不断增长的 blob storage 账户，并且厌倦了维护生命周期策略，启用 smart tier 让 Azure 来处理吧。目前在几乎所有区域公有云区域都可以使用。

Cost-Optimization | The .NET Blog