云服务器突发性能实例值不值得买：CPU 积分机制对峰值业务的真实影响

你选了标注「突发性能」、价格只有标准型一半的实例，平时挺快。一到整点批处理、一到促销流量上来，CPU 直接被限到基线，接口超时一片。问题出在 CPU 积分，而不是你买错了配置。很多人把「突发性能」理解成「便宜又强」，这是整件事里最危险的误解。它真正的含义是：你买到的不是一台随时能跑满的机器，而是一台平时只能跑一小部分算力、需要靠空闲时间攒下来的「积分」去兑换短暂高峰的机器。下面把这套机制拆开讲清楚，帮你判断它到底适合谁。

突发性能实例卖的到底是什么：CPU 积分不是白送的算力

普通云服务器给你的承诺很直接：买 2 核就长期拥有 2 核的算力，随用随跑，不会因为邻居用了 CPU 你就被砍。突发性能实例换了一种卖法，它先给你一个「基线性能」，比如 10%、20% 或 30%，代表这台机器默认持续可用的 CPU 比例；剩下那段高于基线的算力，并不白给，而是用一种叫 CPU 积分的虚拟货币来兑换。

积分的单位有明确定义，主流云厂商的公开文档写法一致：1 个 CPU 积分等于 1 个 vCPU 以 100% 利用率运行 1 分钟。换句话说，你的机器要是消耗了 1 个积分，就等于把一个核心跑满跑了一分钟，或者把半个核心跑满跑两分钟，按时间折算。这个定义很关键，它意味着积分本质上是「时间」，你今天多出来的空闲时间，被换算成明天高峰时多撑几分钟的额度。

所以「便宜」的来源是真实的，也是有限的：云厂商用超卖把一台物理机的算力分给多个用户，赌的是大多数人大部分时间用不满。你以更低价格拿到机器，代价是你默认只能用其中一小块 CPU，超出部分要走积分账。它不是免费送了你更多算力，而是把算力拆成了「保底 + 透支」两层，透支的部分迟早要还。

这里还有一层容易忽略的区分：突发性能型限的是 CPU 上限，机器本身一直活着、网络一直通、磁盘一直可读写，只是算力被压到基线。它和竞价实例完全不同——竞价实例的风险是「可能被回收消失」，突发型的风险是「变慢但不报错」。一个考的是中断恢复能力，一个考的是性能预算，别把两者混为一谈。

基线性能与积分余额：两个每天要盯住的数字

衡量一台突发性能实例，真正要盯的不是「几核几 G」，而是两个数字：基线性能百分比，以及当前积分余额。基线性能决定了你不花积分时能稳定跑多快；积分余额决定了你还能在高性能状态下撑多久。

以公开文档里常见的规格举例。某主流云（AWS）的 T3 系列，t3.nano 是 2 个 vCPU、基线 5%，每小时能攒 6 个积分；t3.micro 是 2 个 vCPU、基线 10%，每小时攒 12 个；t3.small 是 2 个 vCPU、基线 20%，每小时攒 24 个；t3.large 是 2 个 vCPU、基线 30%，每小时攒 36 个。另一家（阿里云）的 t6 系列，像 ecs.t6-c2m1.large 配 2 个 vCPU、1GiB 内存，基线 10%，每小时攒 12 个积分，积分余额上限 288；ecs.t6-c1m1.large 是 2 个 vCPU、2GiB 内存，基线 20%，每小时攒 24 个，余额上限 576。每个 vCPU 开机时还会给 30 个初始积分。

把这两个数字放到一起看才有意义。如果一台机器基线 10%、每小时攒 12 分，但你业务长期跑在 60%，那每小时要花掉的远不止 12 分，差额只能从余额里扣；余额扣光之后，表现就回到 10% 基线，等于这台机器瞬间「缩水」到只有原来六分之一不到的持续算力。这就是为什么同一台机器，平时快、忙时卡，不是玄学，是账算穿了。

模式上还要分清两种。一种是性能约束模式（对应 AWS 的 Standard 模式）：积分余额用光，立刻回到基线，不能再超。另一种是无性能约束模式（对应 AWS 的 Unlimited 模式）：余额用光还能「透支」，透支部分要么后续空闲时还，要么按额外费用结算。前者把成本封死、把性能也封死；后者放开性能、但账单可能失控。选哪种，取决于你愿不愿意为了不让业务卡顿而多付钱。

积分怎么攒怎么花：空闲时攒、峰值时候花

积分的收支逻辑可以压缩成三句话。CPU 利用率低于基线时，攒的比花的多，余额往上涨；正好等于基线时，收支相抵，余额不动；高于基线时，花的比攒的多，开始消耗余额或者透支。整个核算是按毫秒级精度进行的，所以偶尔几次短暂的尖峰只消耗很少积分，不必恐慌；真正伤余额的是「持续高位」。

用阿里云文档里那个经典例子感受一下节奏：一台 t6 实例开机拿到初始积分，随后如果 CPU 利用率是 0，积分余额一路涨到上限 288；当利用率升到等于基线 10% 时，每小时获得和消耗都是 12 分，余额维持不变；一旦冲到 100%，每小时要花 120 分，余额开始肉眼可见地往下掉；掉到低位时，文档特别说明机器性能会在约 15 分钟内逐渐降到基线，而不是一脚踩死——这个「软着陆」设计是为了避免瞬时雪崩，但它也意味着你会在一段时间里持续变慢，只是慢得不明显。

各家对积分的「保质期」规定也不同，这点常被忽略。AWS 的 T3、T4g 实例，积分在实例停止后还能保留 7 天，重启时还能用；但上一代 T2 停止就清零。阿里云的 t6 也区分了初始积分和累积余额的处置方式，无性能约束模式下透支的积分，要等机器空闲时优先还账。所以如果你习惯「白天跑业务、半夜关机省钱」，选错代次可能让攒了一天的积分隔夜蒸发，等于白省。

还有一个常见误区：以为积分是「越多越好、永远留着」。积分有上限，攒到顶就不再涨，多余空闲时间就浪费了。所以真正高效的用法是让业务曲线尽量贴合「白天花、夜里攒」，而不是长期压在极低利用率——那样你只是在替云厂商省电，自己并没占到便宜。

哪些业务会最快把积分烧光：批处理、编译、转码最危险

判断一台机器会不会爆积分，核心看一个指标：CPU 是否长时间维持在明显高于基线的水平。以下几类业务几乎天生就是积分杀手。

整点批处理首当其冲。很多中小站点把数据统计、报表生成、日志归档、账单结算放在整点或者凌晨跑，单次可能持续几十分钟到几小时，CPU 拉满。如果平时机器空闲攒下的积分刚好够这次任务花，一切太平；可一旦某天任务变重、或者前阵子业务本身已经偏忙没攒下多少，这次批处理就会直接把余额掏空，顺带拖垮同一台机器上跑的其他服务。

代码编译和持续集成（CI）也是重灾区。一次全量编译、一次依赖安装加构建，往往能把多核吃满十几分钟。开发测试环境用突发型很常见，但如果你把 CI runner 常驻在突发型上、还频繁触发构建，积分会掉得比你想的快。

音视频转码、图片批量处理、压缩解压、索引重建这类「计算密集且持续」的任务，更是把积分当水喝。一段十分钟的 1080p 转码，可能消耗掉平时大半天攒下的额度。数据库里的大表 ALTER、全表扫描、复杂聚合查询同样危险，因为它们往往单线程吃满一个核持续很久。

反过来看，这些业务「危险」的本质不是它们不能跑，而是它们打破了突发型赖以成立的假设——「平均利用率低、偶尔尖峰」。当你的业务其实是「平均就不低、还经常持续高位」时，再便宜的单价也会被积分账反噬。识别这一点，比纠结买哪款更重要。

Web 服务为什么有时也中招：突发流量与积分悬崖

按理说，普通网站、接口服务、后台管理这类 Web 业务，流量是间歇的，平时空闲、访问来了一波尖峰，正是突发型设计的理想场景。那为什么很多人反馈「我的小网站也卡」？问题往往出在尖峰的「形状」和「邻居」上。

第一种情况，突发流量本身太大太密。一次秒杀、一次公众号推文带来流量、一次爬虫集中抓取，会让请求在十几二十分钟里持续偏高。积分能 cover 短促尖峰，cover 不住「又高又长」的 plateau。等余额掉到低位、进入那 15 分钟软降速区间，用户感受到的就是「时好时坏、慢得说不清」。

第二种情况更隐蔽：CPU 并不是被你的业务代码吃掉的，而是被「慢依赖」逼出来的。当下游数据库变慢、第三方接口超时、缓存击穿，Web 进程会堆积大量等待中的请求，线程池打满，CPU 在上下文切换和重试逻辑上空转。表面上 QPS 没涨多少，CPU 利用率却默默贴着高位，积分在你看不见的地方流失。

第三种情况，是同一台机器上混了定时任务。很多人图省事，把 Web 服务和 crontab 里的备份、导出、索引重建放在一台突发型上。白天 Web 还能靠夜里攒的积分撑，可一旦某个任务在白天触发、或者任务变重，就会和实时流量抢积分，结果两边一起变慢。所谓「积分悬崖」，不是某一个瞬间突然断崖，而是余额归零前后那段时间，性能逐渐塌方的过程。

所以 Web 服务能不能用突发型，答案不是简单的能或不能，而取决于你的流量曲线是否真的「尖而短」、是否有慢依赖、是否把重任务隔离出去。忽略这三条，再小的网站也会在你最在意的那次活动里掉链子。

跟标准型实例比，真实成本到底差多少

谈成本要分清「单价」和「总账」。突发型的小时单价确实更低，这是它存在的理由；但总成本要看你实际用了多少超额 CPU、以及是否触发了无性能约束模式下的额外费用。这里的关键概念是「盈亏平衡点」。

公开文档里有一个常被引用的例子：某云 t3.large（2 核、基线 30%）和同级的固定性能实例（如 m5.large）相比，盈亏平衡点约为平均 CPU 利用率 42.5%。意思是，如果你的 24 小时平均 CPU 低于 42.5%，突发型无限模式更划算；一旦长期高于这个点，无限模式产生的超额费用会让突发型反而比固定实例更贵。文档还提到，如果一台 T3 实例长时间 100% 跑满，最终花费大约相当于同级固定实例的 1.5 倍。

这个数字不是让你去记，而是让你建立直觉：突发型省的钱，来自你「用不满」；一旦你其实「用很满」，省的钱就吐回去了，还可能加倍。很多人的账单 surprises 就来自这里——以为买的是便宜机器，结果因为长期高负载不断触发超额计费，月底一看并不比标准型省。

具体到人民币报价，不同云厂商、不同地域、不同规格差异很大，没有统一数字。入门级云服务器常见参考起步价约为每月 25 元起（以一万云等公开渠道参考），但突发型与标准型之间的实际价差、以及无性能约束模式的超额单价，一律要以你所用厂商的官方实时报价为准，本文不对任何具体机型的精确价格做承诺。选型的稳妥做法，是先用标准型跑一周、记录平均 CPU，再反推突发型是否真的省钱。

配置怎么选：什么负载适合突发型、什么负载绝对不行

把上面的机制落成一句决策原则：先估你业务的「24 小时平均 CPU 利用率」，再和基线比。平均明显低于基线、且尖峰短促的，放心用突发型；平均接近或超过基线的，直接上标准型或计算型，别在积分上赌。

适合突发型的负载清单：开发测试环境、个人博客与展示型官网、访问量不大但偶尔有活动的小程序后端、微服务里那些长期空转只在请求到来时动一下的组件、监控与告警采集器、低频定时任务（注意是低频且不重）、企业内部 OA 这类白天用晚上闲的系统。它们的共同点是「大部分时间在摸鱼，偶尔伸个懒腰」。

绝对不该放突发型的负载：任何数据库（MySQL、PostgreSQL、MongoDB），因为它们有后台刷脏页、 checkpoint、慢查询，CPU 曲线是「总体平稳但常有小高位」，正好持续啃积分；任何缓存（Redis、Memcached），它们是单线程吃 CPU 的典型；消息队列与流处理；持续批处理与转码；游戏逻辑服；以及对延迟敏感的实时 API。把这些跑在突发型上，等于让最不能慢的环节去赌最不稳定的算力。

把需求落到具体节点时，一万网络可以作为标准化方案参考之一：其深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。对中小站长来说，先按上面的清单分清楚负载属性，再决定是走低成本突发路线还是稳定型路线，比单纯比单价更有意义。

扩容与迁移：什么时候该从突发型搬走

判断迁移时机，不要等「已经卡到用户投诉」才动，要看几个提前信号。第一，监控里 CPU 积分余额长期贴着零，说明机器几乎一直在靠基线硬撑；第二，无性能约束模式下开始有规律产生超额费用，账单逐月走高；第三，业务高峰期的 P99 延迟明显抬升，但 CPU 利用率「看起来不高」——这恰恰是限频的典型症状，因为被压到基线后利用率曲线会失真。

迁移路径有几种。最轻量是临时打开无性能约束模式「先止血」，让业务不再被限频，但你要同时规划后续，否则账单会持续偏高。更彻底的做法是变配到固定性能实例，比如同代的标准型或计算型，直接消除积分变量，代价是单价上升，换来可预期的性能。还有一种折中：保留突发型承载轻量组件，把数据库、缓存、批处理单独迁到固定实例或独立资源上，用混合部署把「该稳的」和「可省的」分开。

操作上，主流云都支持实例变配或基于快照重建，停机窗口取决于你是否用了热迁移能力；对中小站点来说，挑一个访问低谷、提前打好快照、再切到新规格，通常能控制在几分钟到几十分钟的中断内。真正的成本不在迁移本身，而在你一直没发现「这台便宜机器其实一直在拖业务后腿」所损失的转化与口碑。

若后续需要把突发型迁到固定性能实例并就近部署，一万网络在华南、华东、华北及中国香港等地整合的自营节点与 BGP 多线资源，也能作为部署基础设施的选项之一，配合服务器租用与带宽接入的一体化交付来承接迁移后的稳定负载；实际配置与报价以官网实时信息为准。把算力升级和节点位置一起考虑，往往比单看机型更省心。

避坑清单：只盯单价不盯积分、长期高负载最致命

坑一，只看每小时单价就下单。单价低是用「默认只能跑基线」换来的，没算清自己的平均 CPU，便宜可能只是表象。规避办法：上线前用标准型跑一周，记录平均利用率再决定。

坑二，把突发型当万能生产机。数据库、缓存、队列这些「不能慢」的组件放上去，迟早限频。规避：核心有状态、对延迟敏感的组件一律固定实例。

坑三，开了无性能约束模式就以为高枕无忧。透支能解一时之急，但持续高位会累积超额费用，月底账单反超标准型。规避：把它当应急闸而非常态，配合余额监控。

坑四，Web 和重定时任务混在一台机器。白天流量和整点批处理抢积分，两边一起崩。规避：把备份、导出、索引重建迁移到独立实例或调度到低谷错峰。

坑五，忽略关机对积分的影响。部分代次实例停止后积分清零，你「白天关机省钱」反而把攒的额度弄没了。规避：确认所用代次的积分保留规则，别想当然。

坑六，迷信压测数字。十分钟满核压测时积分池还撑得住，撑不住的是八小时真实业务里夹着备份和导出的长尾。规避：压测至少覆盖一个完整业务高峰，或直接用积分余额曲线推算真实容量。

数据来源

Amazon Web Services 官方文档《Key concepts for burstable performance instances》与《Unlimited mode concepts for burstable instances》，说明了 CPU 积分定义（1 积分 = 1 vCPU × 100% × 1 分钟）、基线性能、Standard 与 Unlimited 两种模式，以及 t3.large 与 m5.large 约 42.5% 的盈亏平衡点示例；中国区文档《可突增性能实例的关键概念》补充了 T3/T4g 停止后积分保留 7 天、T2 停止清零的差异。

阿里云官方帮助中心《CPU 积分变化示例》与突发性能实例规格说明，给出了 t6 实例各规格的基线性能、每小时获得积分、最大积分余额、每个 vCPU 30 个初始积分，以及性能约束模式与无性能约束模式下的积分收支过程，并说明余额低位时性能在约 15 分钟内逐步降至基线。

主流云厂商（含 AWS、阿里云、腾讯云等）公开的实例计费说明与突发性能实例产品页，用于核对积分机制、模式差异与计费口径；具体的机型价格、地域价差与无性能约束模式超额单价，以各厂商官网实时报价或咨询确认为准，本文未对精确价格做承诺。

常见问题

突发性能实例是什么？

突发性能实例是云厂商提供的一类「基线 + 积分」算力形态，它不像标准型那样随时能跑满你买到的核数，而是先给你一个较低的基线性能（比如 10% 到 40% 不等），超出基线的那部分算力要用 CPU 积分去兑换。积分来自机器空闲时按毫秒精度累积的「时间额度」，1 个积分等于 1 个 vCPU 以满速跑 1 分钟。它的存在意义，是让平均利用率低、只是偶尔尖峰的业务，用更低的单价拿到够用的弹性。代价是当业务持续高位、积分耗尽后，算力会被压回基线，表现明显变慢但不报错。所以它是「低成本弹性」而不是「免费高性能」，适合开发测试、小流量站点、低频任务这类负载，不适合数据库、缓存、持续批处理这类需要稳定满算力的场景。选购前最好先用标准型实测平均 CPU，再判断积分账是否真的划算。

CPU 积分耗尽会怎样？

积分耗尽后机器不会关机、不会报错、也不会直接断网，它继续运行，只是 CPU 被限制在基线性能上。具体症状表现为请求开始排队、响应变慢、系统 load 升高、原本流畅的接口出现超时，但你在监控里看到的 CPU 利用率可能「并不离谱」——因为被压到基线后曲线本身就失真了。在性能约束模式下，余额归零就立刻回到基线，必须等负载降下来、积分重新累积才能恢复高性能；在无性能约束模式下，可以先透支继续突发，但透支要么后续空闲时偿还，要么产生额外费用。阿里云文档还提到，余额很低时性能会在约 15 分钟内逐步降到基线，而不是瞬间断崖，这反而容易让人误判成「偶发卡顿」而非资源不足。识别它的关键，是盯住积分余额曲线和 P99 延迟，而不是单纯看平均利用率。

Web 站点能用突发型吗？

能用，但有前提。Web 服务如果能做到「平时空闲、访问来了一波短促尖峰、且慢依赖被隔离」，那正是突发型擅长的场景，小博客、展示官网、低频小程序后端、内部 OA 都很合适。真正出问题的是三种情况：一是流量尖峰又高又长，比如一次大促或推文带来十几分钟以上的持续高位，积分 cover 不住；二是慢依赖（数据库慢、第三方超时、缓存击穿）逼着 Web 进程空转吃 CPU，积分在看不见的地方流失；三是同一台机器混了备份、导出、索引重建等定时重任务，和实时流量抢积分。只要避开这三件事，Web 用突发型是划算的。实操建议：把数据库和缓存单独放固定实例，定时任务错峰或迁走，并对积分余额做告警，这样站点既能省钱又不会在关键活动里掉链子。

和标准型差多少钱？

突发型的小时单价通常比同规格标准型低，这是它吸引人的地方，但「总账」取决于你实际消耗了多少超额 CPU 以及是否触发无性能约束模式的额外费用。公开文档给出的判断框架是「盈亏平衡点」：以某云 t3.large（基线 30%）对比同级固定实例为例，当 24 小时平均 CPU 低于约 42.5% 时突发型更省，长期高于这个点则无限模式的超额费用会让它反而更贵，文档甚至提到长时间满核时花费可达同级固定实例的约 1.5 倍。落到具体人民币，入门级云服务器常见参考起步价约为每月 25 元起（以一万云等公开渠道参考），但突发型与标准型的实际价差、各地域报价、超额单价差异很大，一律要以你所用厂商的官方实时报价为准，本文不做精确价格承诺。稳妥做法是先用标准型跑一周记录平均 CPU，再反推突发型是否真省钱，而不是只看宣传里的单价差。

积分能买吗？

积分本身不能直接像买流量包那样单独购买，它本质上是机器按时间累积的额度。你能做的是通过两种方式「间接补充」：一是选择更大的规格，更大规格通常对应更高的基线百分比和更高的每小时获得积分速率，积分余额上限也更高，等于池子更大；二是打开无性能约束模式（无限模式），在余额耗尽后允许透支，透支的额度后续要么用空闲时间攒的积分偿还，要么按厂商的超额单价结算——这相当于用钱换持续性能，而不是「买积分」本身。需要注意的是，部分代次实例在停止后会清空积分（如 AWS 上一代 T2 停止即清零，T3/T4g 可保留 7 天），所以靠「关机省钱再开机用积分」并不总成立。与其研究怎么买积分，不如先把持续高负载的业务迁到固定实例，从源头消除对积分的依赖。

怎么看余额够不够？

每家云厂商的控制台和监控指标都提供积分相关视图，核心是盯两个量：当前积分余额，以及余额的变化趋势。以 AWS 为例，有 CPUCreditBalance（当前余额）和 CPUSurplusCreditCharges（超额产生的费用）等指标；阿里云控制台实例页也能看到积分的累积与消耗情况。判断够不够不能只看瞬时值，要看「未来一段时间的高负载是否会击穿余额」：如果余额长期贴零、且业务高峰频繁，说明额度已经不够；如果无性能约束模式下开始有规律产生超额费用，也说明你在为持续高位买单。实操上建议给余额设告警阈值，并在业务高峰前预留足够额度；更可靠的办法是用一段真实业务的平均 CPU 去推算收支——平均低于基线就稳，平均接近或超过基线就该考虑升级，而不是等卡了再回头查余额。

数据库能用突发型吗？

强烈不建议把任何生产数据库放在突发性能实例上。原因不在数据库「跑不动」，而在它的 CPU 曲线天然是「总体平稳但常有小高位」：后台刷脏页、checkpoint、慢查询、全表扫描、大表 ALTER、复杂聚合，都会让 CPU 维持在不低的水位，持续啃积分。等积分耗尽回到基线，数据库响应会整体变慢，连接池堆积，进而拖垮所有依赖它的服务，而表象只是「网站有点卡」，极难第一时间定位。缓存（Redis、Memcached）同理，它们是单线程吃 CPU 的典型，也该用固定实例。如果预算实在紧张，至少把数据库放到标准型或计算型的最小可用规格，把突发型留给真正空闲的 Web 前端和任务组件。记住一条底线：凡是「不能慢、有状态、对延迟敏感」的组件，都不要拿积分去赌，稳定性比那点单价差重要得多。

什么时候该升级？

升级信号比「已经卡到用户投诉」出现得早得多，提前看这几个：第一，监控里积分余额长期贴零，机器几乎一直在靠基线硬撑；第二，无性能约束模式下开始有规律地产生超额费用，账单逐月走高，说明你在为持续高位持续买单；第三，业务高峰的 P99 延迟明显抬升，但 CPU 利用率曲线「看起来不高」，这是限频失真的典型症状；第四，你发现要把数据库、缓存、批处理都迁走之后，剩下的 Web 层才勉强跑得动，说明这台机器的定位已经撑不住当前业务。升级路径有几种：临时开无限模式止血、变配到同代标准型或计算型消除积分变量、或者混合部署把重组件拆到固定实例。选型原则始终是先估平均 CPU 再决定——平均明显低于基线才留突发型，否则早升早安心，别等积分账反噬到口碑和转化上才动手。