关于甲骨文“配置减半”，AI的见解

原文档应该是3000小时OCPU 18000小时内存，由此可见的确减配了
"For Always Free tenancies, this is equivalent to 2 OCPUs and 12 GB of memory."（对于永久免费租户，这相当于 2 个 OCPU 和 12 GB 内存。）
但这其实是文档在表达上让人产生的一个巨大误解。 实际的免费规则依然是 4H24G，官方并没有缩水，只是文档的计算逻辑和描述方式容易让人误会。
我们可以从以下两个层面来拆解为什么文档会写成“2H12G”，以及真实的规则到底是怎么回事：

1. 官方文档的“文字游戏”：免费账号 vs 付费账号
   注意看这段话完整上下文的上一句：
   "All tenancies get the first 1,500 OCPU hours and 9,000 GB hours per month for free..."
   甲骨文在底层计算免费额度时，从来不是按“开机数量”算的，而是按“每个月消耗的资源时间（小时数）”来计算的：
   1500 OCPU 小时 / 月 /31天 / 24小时≈ 4 个 OCPU 18000小时内存，由此可见的确减配了
   9000 GB 小时 / 月 / 31天 / 24小时 ≈ 24 GB 内存
   这就是 4H24G 的数学来源。
   那为什么后面非要加一句“对于免费租户，这相当于 2 OCPU 和 12 GB 内存”呢？因为甲骨文有一个硬性限制：纯免费（Always Free）账号在同一个区域内，最多只能同时运行 2 台虚拟机（Compute Instances）。
   官方在写这段文档时的预设逻辑是：
   “既然纯免费账号最多只能开 2 台机器，那如果用户把总额度平均分配到这 2 台机器上，每台机器分到的不就是 2 OCPU 和 12 GB 内存了吗？”
   文档编辑者为了给新手一个“直观的单台机器参考配置”，擅自把总额度除以了 2，结果反而写成了具有误导性的“相当于 2 OCPU 和 12 GB”。
2. 怎么证明真实的配额还是 4H24G？
   你可以直接在自己的甲骨文后台验证，官方的后台控制面板才是最终的“账单法律”：
   1看控制台滑块： 如果你现在去创建 Ampere A1 实例，只要你当前的租户里没有其他 ARM 机器，你的 CPU 滑块依然可以一路拉到 4，内存依然可以一路拉到 24。如果官方真的改了硬上限，滑块在 2H12G 就会被锁死。
   2看服务限制（Service Limits）： 登录控制台，进入 控制面板 -> 调优与行政（Governance & Administration） -> 限制、配额和使用情况（Limits, Quotas and Usage）。找到 Compute 服务下的 Standard.A1，你会看到官方分配给你的硬性配额（Limit）清清楚楚写着的依然是：
   Number of OCPUs for A1 Based VM Instances: 4
   Amount of Memory for A1 Based VM Instances: 24 (GB)
   总结
   甲骨文的免费政策没有缩水。那段文档的意思是：“如果你想开满 2 台免费 ARM 机器，建议每台配置为 2H12G”。
   如果你不需要两台机器，你完全可以把所有的鸡蛋放在一个篮子里，直接开一台 4H24G 的大怪兽，只要单月总运行时间不超过 1500 OCPU 小时和 9000 GB 小时，它就依然是绝对免费的。