甲骨文在未公开通知的情况下悄然将免费层Ampere A1计算配额减半

甲骨文悄悄把免费云服务器的配置砍了一半！原本免费提供的4核CPU和24GB内存，突然缩水到2核12GB，而且没发任何通知，只是改了文档。很多用户的实例直接被停机，才发现自己“白嫖”的资源没了。简单说，甲骨文Oracle Cloud一直有个很慷慨的免费套餐，吸引大量开发者用它跑个人网站、学习AI、搭建家庭自动化等小项目。现在容量减半，意味着原来能流畅运行的4核应用，要么缩水到2核，要么乖乖付费。更让人头疼的是，甲骨文没有提前通知，连邮件都没发，只在官网角落更新了数字。一些用户为了额外功能升级了付费账户，结果发现自己的免费资源也受牵连，搞不清会不会悄悄产生费用。官方支持团队说付费账户可能不受影响，但文档却写着“所有租户”都适用新限额，前后矛盾。对普通用户来说，如果你用甲骨文的免费云，得赶紧检查自家实例，确保总配额不超过2核12GB，否则可能被停机或超支收费。这次事件损害了信任，以后开发者可能不敢轻易把重要项目放在这个平台上。建议受影响的人立即调整实例配置，付费用户直接联系客服确认政策，并保留聊天记录做凭证。

甲骨文将其云平台 Oracle Cloud Infrastructure 上的 Always Free Ampere A1 Compute 配额从 4 OCPU 和 24 GB 内存降至 2 OCPU 和 12 GB 内存。该变更自2026年6月15日起生效。甲骨文未发布博客、未向客户发出通知，也未做任何公开说明，只是更新了文档，用户在实例被停机或社区成员发现网站上数值变化时才注意到限额已经发生了变更。此前，每月 3000 OCPU 小时与 18000 GB 小时（相当于持续运行 4 OCPU/24 GB）对免费云额度而言相当慷慨，这吸引了大量开发者、自托管爱好者与 Linux 用户在上面运行个人服务器、测试环境、使用 Ollama 的轻量级 AI 推理以及通过反向代理实现家庭自动化。新的配额 1500 OCPU 小时与 9000 GB 小时将容量进行了减半。计费的变化在社区中引发了数日的混乱。Linuxiac报道指出，缺乏通知引发了已经升级为 PAYG 的用户的不满，这些用户为了便于实例供应升级了账户，但仍依赖 Always Free 的资源。他们的担忧在于，运行旧 4 OCPU 配置的 PAYG 账户可能会在超额时悄然产生费用，而仅限免费层的账户则会被直接停机，直到用户手动调整为不超出 2 OCPU/12 GB。局势在 6 月 22 日出现了变化，多位用户报告称甲骨文的人工支持团队（而非聊天机器人）通过邮件确认，新的限额仅适用于免费层账户。PAYG 账户或许仍可使用 4 OCPU/24 GB 而不产生额外的费用。但“或许（may）”一词承载了较大的不确定性。截至发稿时，甲骨文尚未发布公开澄清，官方文档也未对账户类型做出区分。一位Reddit评论者直接指出了这一矛盾：甲骨文当前的官方文档写道：“所有租户每月可免费获得首次的 1500 OCPU 小时与 9000 GB 小时。”如果 PAYG 租户确实不受影响（按照其支持团队所述），那么这段表述就会引起误解。“所有租户”通常应该包含 PAYG 账户。用户更多依赖支持邮件的截图而非官方的政策文本。即便那些保留了旧 4/24 实例的用户，这种保护可能也是暂时的。另一位评论者提醒了文档中的细则：真正的陷阱在这里：“如果现有资源被终止，可能无法重新创建超过更新后 Always Free 限额的资源。”没有人能保证其实例永不被终止，而甲骨文也已经意识到这一点。这意味着被保留的旧实例只要发生一次终止（无论是维护、故障，还是用户操作失误），就可能永久受限于新的 2/12 配额。更值得关注的是甲骨文的处理方式。将免费层减半可以视为一项正当的商业决策，云服务提供商会随时间调整其免费产品，例如，AWS 在去年调整了免费方案（参见相关报道）。但在没有发布博客、未向受影响账户发邮件通知、也未在文档中清晰区分免费层与 PAYG 影响的情况下进行此类更改，会造成信任的丧失，使开发者对在该平台上进行构建产生顾虑。社区是通过文档差异和被中断的实例发现此次变更的，而非由甲骨文主动告知。对受影响用户而言，立即可采取的措施非常简单，那就是审计你的 Ampere A1 实例，确保租户内所有实例的总配额不超过 2 OCPU 与 12 GB 内存。如果你使用 PAYG 帐户，请直接联系甲骨文的支持团队确认旧配额是否仍适用于你的账户，并保存其回复作为凭证。甲骨文的Always Free Resources 文档已经反映了当前的限额。查看英文原文：Oracle Quietly Halves Free Tier Ampere A1 Compute Limits with No Public Announcement