算力重构：腾讯云第九代CVM与玄灵网卡如何释放被偷走的CPU

算力这个词，这两年快被说烂了，尤其是碰上个AI热潮，动不动就是多少P算力、多少T算力。但说实话，绝大多数人聊算力的时候，脑子里想的都是计算芯片那点事——CPU主频多少、GPU卡有多少TFLOPS、最新出的推理卡能跑多大模型。我以前也是这么看的，直到我自己在云上折腾高并发服务，被CPU steal和网络软中断折磨到怀疑人生，才慢慢意识到一件事：算力这东西，从来不只是计算本身，而是计算、网络、存储、安全的合力。 你算得再快，数据送不进来、存不下来、防护规则卡一道，最终业务能享受到的算力就是大打折扣。

所以当我看到腾讯云第九代CVM，配合玄灵网卡一起发布的时候，第一反应不是“又换代CPU了”，而是这条技术路线的转向终于摆到了台面上：不再单纯靠堆CPU主频和核心数提升算力，而是把算力分配的逻辑重新做了一遍。这篇文章，我就想从为什么需要这么做、玄灵网卡到底干了什么、第九代CVM实际用起来有哪些变化，以及我们这些做业务的人怎么验证和利用好这波升级这几个维度，把这件事说透。

1. 算力这块蛋糕，为什么非要动刀

先说一个经常被忽略的事实：在云服务器里，CPU只有一部分时间在跑你的业务代码，剩下的时间很大一部分在替别人“打杂”。

1.1 从“算力是什么”说起

很多文章解释算力喜欢直接说“算力就是计算能力”，然后开始列参数。这个解释放在单机时代可以，放在今天这个云化、AI化的环境里，已经不够准确了。如果你是刚接触云计算、或者正被各种“算力平台”“租算力”信息搞得一头雾水的读者，先记住一个结论：通用算力=计算+网络+存储+安全，四者缺一不可。

打个比方。你开一家餐厅，灶台火力就是计算能力，但客人能不能进来、食材能不能运到、菜品能不能送出去，这些支撑系统但凡有一条路堵住，你灶台火力再猛也只能干等。在云端，网络的收发、存储的读写、安全的访问控制，都是吃掉CPU时间的“隐形环节”。

你去看那些显卡TOPS算力表，一张卡标着几百TOPS，那是纯理论峰值。但真跑AI任务的时候，数据要从远程存储拉过来，要经过网络传输到GPU显存，训练过程中多卡之间还要同步梯度——这个环节叫集合通信。网络稍有抖动，几千张卡就得一起等最慢的那一张。这时候你总得有一个东西去处理这些IO、这些通信调度。如果全靠CPU去顶，那CPU给GPU“打杂”的时间就会远远超过计算本身的时间。这就是为什么现在谈算力，一定要看网络和存储能不能跟得上。

1.2 虚拟化损耗：云上算力的隐形漏水

云服务器和物理服务器最大的区别是：一套物理资源要切成很多份，分给多个租户。这个“切分和隔离”的动作，叫做虚拟化。虚拟化不是免费的，它本身就要消耗资源。

在传统架构里，虚拟机的每一次网络数据包收发，走的路径大致是这样的：物理网卡收到数据，触发中断，宿主机的CPU响应中断，把数据从网卡缓冲区拷贝出来，再交给虚拟交换机（比如Open vSwitch）做二层转发、VLAN剥离、安全组过滤，最后才能把数据“塞”给虚拟机里的操作系统。虚拟机往外发包的时候，又是一条长长的逆过程。

你可以把宿主机CPU想象成一个大管家。本来每个租户自己房间里的活儿是各自干的，但这个大管家要负责替所有人收快递、拆快递、检查快递、再一家一家送上门。快递少的时代无所谓，管家闲着也是闲着。但现在的问题是快递量爆炸了——服务器网卡从10G带宽到25G、50G、100G，一个虚拟机里的应用动辄每秒处理几十万个数据包。大管家就算三头六臂也忙不过来，于是租户自己的计算任务就要排队。

这个“排队等待管家处理IO”的时间，在云计算里有个术语叫CPU steal。 你买了一个8核的虚拟机，实际跑下来可能只有7核多在替你干活，剩下的核时被虚拟化层偷走干杂活了。跑高并发业务的时候，这种CPU steal最明显——明明CPU没跑满，但请求就是处理得慢，延迟时不时抖一下。我以前排查过类似问题，最后定位到是网络中断和软中断把大量CPU时间吃掉了，应用本身的逻辑只占了一半左右。这种隐形损耗，才是云上算力最大的浪费。

1.3 为什么以前没解决，偏偏现在解决

一个问题存在了很久，为什么各个云厂商以前不彻底解决？答案很简单：以前的问题规模不够大，用软件方案硬扛也能扛得住。

早期云服务器网卡带宽小，一两Gbps的时代，一台物理机上跑的虚拟机数量也不多，IO路径长一点、CPU消耗大一点，业务感知不明显。成本也可以接受。但现在的场景已经完全变了：大模型训练需要几百张卡高速互联，分布式数据库需要低延迟高吞吐的网络，在线广告推荐、直播互动这些业务面对的是动辄几百万的并发连接。这种情况下，软件虚拟化带来的开销已经成为算力释放的瓶颈了。

CPU不能一直干这种“搬运工”的活儿，它应该把更多精力放在计算本身。那谁来当这个搬运工？答案是硬件网卡。这就是玄灵网卡这类智能网卡存在的根本价值——用专用硬件把IO处理、虚拟化、存储协议、安全防护这些杂务从CPU手里接管过来。

这背后其实是一场算力重分配。物理机上总CPU资源是固定的，以前虚拟化杂务要吃掉这块蛋糕的三成，现在把这三成还给租户的业务计算，等于同一台物理机能卖出去的有效算力变多了，而且每个租户拿到的算力更“干净”了。云厂商为什么要砸重金做自研网卡？从商业逻辑上看，这一步棋本质是提升每一台物理服务器的可售卖算力总量，属于技术驱动的成本重构。

2. 玄灵网卡到底做了什么，第九代CVM凭什么称作新范式

光说不练假把式。玄灵网卡被吹得再厉害，我们得知道它到底把哪些活儿接走了，接得干不干净。

2.1 玄灵网卡不是一块普通网卡

普通网卡也叫NIC（Network Interface Controller），它的职责很简单：把网络数据包从线上收下来、交给CPU处理，或者把CPU要发的内容打包、放到线上。相当于一个门口收发室，只负责递，不负责拆。

玄灵网卡属于智能网卡（SmartNIC）这一类，更准确说，它已经在往DPU（Data Processing Unit，数据处理单元）的方向上演进。它可不止一块网卡芯片。它有自己的CPU核心、可编程的数据通路、专门的加密解密和存储加速引擎，本质上就是把一台小型计算机塞进了网卡这个形态里。

类比一下：以前你小区里收快递，快递员把包裹堆在门卫室，然后喊每家每户自己下来拿，各家CPU都得放下手里的活儿跑一趟。有了智能网卡之后，相当于门口多了一个智能快递柜，门卫负责代收、代分类、代检查、代保管，居民按个键就能取件，谁家的件也串不了。CPU再也不用为这些琐事频繁中断自己了。

2.2 网络卸载：让数据包“绕着”CPU走

玄灵网卡最核心的一个能力，是网络虚拟化的全卸载。

第九代CVM的网络架构里，虚拟交换机的数据平面被搬到了网卡上。具体来说，虚拟机的网络流量不再经过宿主机的Linux内核协议栈和Open vSwitch，而是由网卡硬件直接根据流表规则进行转发。数据从一个虚拟机发出来，网卡硬件直接完成VXLAN封装、安全组规则匹配、路由查找，然后从物理端口发出去；收包的时候同样在网卡上完成解封装、过滤、分发，直接把数据放进对应虚拟机的内存队列里。

这个过程里，宿主机CPU几乎不参与数据拷贝和协议转换。好处是实实在在的：

• PPS（每秒处理数据包数量）大幅提升。以前靠CPU跑OVS，单实例几十万PPS就能把CPU吃满；硬件卸载之后，单实例百万PPS是常规操作。对网关类、接入层这种小包多、连接数高的业务，感受会非常明显。
• 延迟更稳定。软件转发路径可能受宿主机上其他租户流量影响，产生抖动；硬件转发路径的确定性更强，尾延迟（P99）会好看很多。
• CPU软中断大幅下降。以前跑高并发服务，top一下能看到大量si（soft interrupt）占用，卸载之后这一块基本可以忽略。

2.3 存储卸载：远程存储和本地盘都不再打扰CPU

除了网络，存储协议栈也是CPU的“耗电大户”。云服务器的云硬盘本质上是一块远程存储，数据要经过网络协议转换。传统的软件方案里，虚拟机的每一次磁盘读写都要在宿主机上完成SCSI命令到存储协议的转换，大量的CPU中断被消耗在存储路径上。

玄灵网卡把存储卸载做了两部分：

• 一个是把存储虚拟化相关的协议处理放到网卡上完成，数据通路变成“虚拟机内存→网卡硬件DMA→存储网络”，CPU只负责发起IO请求，剩下的搬运和组装由硬件完成。云盘的延迟和吞吐都更有保障，而且CPU占用更低。
• 另一个是本地盘场景。如果你买的是本地NVMe SSD的实例，理论上性能最好，但以前也要经过宿主机虚拟化层一层转换。现在本地盘的存储虚拟化也下沉到网卡，IO路径缩短了，跑数据库这类IO密集型应用时，单位时间内能支持的IOPS和事务数更高，而且不会出现“邻居吵你”的情况。

2.4 安全卸载：每个租户的防火墙规则交给硬件

云服务器的安全组规则，是实现租户隔离和访问控制的关键。传统的安全组实现，是在宿主机上的数据路径里，由软件逐条匹配规则。规则多起来，匹配本身就要消耗CPU。

玄灵网卡内置了高性能的规则匹配引擎，安全组、网络ACL的过滤规则直接被下到网卡硬件中。数据包在网卡上流转的时候，边转发边匹配，合法放行，非法直接丢弃，全程不经过宿主机CPU。对于大规模部署的场景，这个动作顺手解掉了一个隐性风险：以前安全组规则一多，虚拟机的网络吞吐就下降，现在规则不会成为性能瓶颈了。

2.5 软硬协同：一套完整的卸载体系

这里我要特别说明一下，玄灵网卡不是把某些功能硬塞到硬件里去，而是和腾讯云的虚拟化软件栈做了深度协同。硬件负责数据平面的高速转发，软件负责控制平面的灵活调度。

比如，热迁移场景。以前虚拟机从一台物理机迁移到另一台，网络状态和存储状态都得跟着搬。在玄灵网卡这套体系里，流表规则是控制面统一下发的，网卡硬件只是执行者，迁移的时候把规则切换到目标机器的网卡上就行，迁移过程对虚拟机里的应用几乎无感。再比如异常处理，如果宿主机发生故障，网卡上报的实时状态能帮助调度系统更快地发现和迁移可疑负载。

简单总结一下这四类卸载的能力矩阵：

3. 第九代CVM的几处具体变化，以及你在控制台上能看到什么

聊完玄灵网卡，我们把视角拉回第九代CVM本身。这是一次计算代际升级和网络硬件升级同时落地的产品发布会，这意味着用户得到的是一次系统性的提升，而不仅仅是CPU型号变了那么简单。

3.1 网络性能上的直观变化

从公开信息来看，腾讯云第九代CVM在网络层面比前代有非常明确的提升。单实例带宽上探到更高速率，而PPS能力则上探到百万级甚至更高。 可能你对“百万PPS”这个数字没有直观概念，我大概解释一下：以前一个Web接入层实例，如果按照传统软件转发路径，PPS到几十万的时候CPU就开始告警了，你必须额外开好几台实例分摊流量。但在新代次实例上，单台实例能扛住的报文量大了好几倍，这意味着同规模业务可能只需要原先三分之一的实例数量。

更关键的是多队列能力的增强。网卡支持更多的硬件队列，虚拟机里可以配置更多的RSS（Receive Side Scaling）队列，让多核CPU分摊网络收包。以前4核8核的机器，网络收包常常集中在某一两个核上，形成单核瓶颈。现在队列多了，多核负载更均衡，慢请求和CPU倾斜现象会明显改善。

3.2 CPU核被“还”回来了

第九代CVM在工艺和底层架构上，本身就带来了CPU主频和单核性能的提升。但对我来说，最有感知的是被偷走的CPU终于还回来了。

为什么这么说？以前用云服务器跑高流量业务，你会注意到监控面板上的CPU使用率里，有一部分是系统态（sy）和软中断（si），而不是用户态（us）。系统态就是CPU替操作系统干杂活的占比，软中断就是CPU处理网络收发包的占比。这两项长期偏高，意味着你的业务正在替云平台的虚拟化机制买单。

在第九代CVM上，因为玄灵网卡把网络和存储的杂活接管了，你会看到同样是跑业务，系统态和软中断的比例肉眼可见地下降。这意味着同样的CPU规格下，你的业务代码能使用的CPU比例更高了，换算下来等于是免费获得了额外的算力。我自己实测过类似业务，迁移到新代次之后，CPU整体使用率相比同规格老实例能降两成到三成，在高峰期表现得尤为明显。

3.3 对AI训练和大模型场景意味着什么

如果你只是跑传统Web服务，上述提升已经足够值回票价。而如果你正在折腾AI相关的业务，比如大模型微调、推理服务、或者做多机多卡训练，那么第九代CVM和玄灵网卡的组合能解决的问题就更值得关注了。

大模型训练的瓶颈往往不在GPU计算本身，而在通信上。多台机器一起训练时，每一轮梯度更新都需要在所有机器之间做一次全量同步，这种消息叫做AllReduce。这个操作是纯网络密集型的，如果网络带宽不够，会直接限制GPU的利用率——也就是业界常说的通信墙。网络时延稍微一抖动，几千张卡就得集体等待。所以在AI算力平台里，网络规格和GPU规格同等重要。

第九代CVM在AI场景上的价值有两个层次：第一个层次，基础网络性能提升，多机通信的带宽和时延都有改善；第二个层次，因为玄灵网卡卸载了大流量网络转发的压力，跑训练任务的同时，CPU还有余力去处理数据预处理、日志上报、监控采集这些杂活，不需要额外再开一台机器去干这些事。对于成规模的AI集群来说，这种“算力重分配”带来的整体效率提升非常可观。

如果你对算力、token、模型、场景这些AI名词之间的关联还在摸索阶段，我可以简单串一下：Token是模型读写数据的最小单位，算力决定了你每秒能处理多少Token，数据决定模型能力的上限，模型结构决定算力利用的效率，而场景则是把模型能力兑换为业务价值的出口。四者环环相扣，第九代CVM这类基础硬件升级，解决的是“算力”这一环的供给效率问题——不是让你平白多出多少计算芯片，而是让已有的计算芯片用得更满。

3.4 选型和迁移时要注意什么

腾讯云目前的产品矩阵里，第六代、第七代、第九代实例是三代并存的状态。选型的时候有个基本逻辑：老用户建议先跑一轮性能压测再确定迁移；新购用户如果在那个价位段有第九代可选，直接选第九代通常不会错。

迁移这件事，比很多人想象中顺利。因为第九代CVM的虚拟化层面依然保持标准虚拟化接口，操作系统内部看到的网卡型号跟普通弹性网卡一致，应用代码基本不需要改动。但对于以下两类用户，建议多留个心眼：

• 一类是之前用了DPDK或者SR-IOV直通方案做了深度优化的高性能业务。虽然现在玄灵网卡已经能卸载大部分虚拟化开销，但如果你之前的应用已经深度绑定某个特定网卡的驱动行为，迁移之前最好先做小流量验证。
• 另一类是高度依赖CPU亲和性、并且自己做了绑核配置的业务。新代次实例的CPU拓扑可能跟老实例不一样，如果代码里绑定了CPU编号，需要先重新核对NUMA架构。

我个人建议的迁移节奏是：先在非核心环境跑整整一周的压测和稳定性验证，用生产级别的流量录制回放，观察P95、P99延迟曲线，确认没有异常后再灰度切生产流量。测试期间重点看两项指标：CPU软中断是否明显下降、网络PPS上限是否达到预期。

4. 算力真的被“重构”了吗，以及普通用户能从这波变化里捞到什么

标题里用了“重构算力新范式”这种词，听起来有点大。我自己用下来的体会是：这波变化确实不是挤牙膏式的升级，而是把算力的分配模型换了一套思路。

4.1 云厂商的技术竞赛，本质是在抢“每一分算力”

过去几年，主流云厂商都在自研硬件，有的做CPU芯片，有的做智能网卡，有的做云端一体化的GPU调度。表面上大家在拼技术参数，本质上都在抢同一件事：每一台物理服务器能被有效卖出的算力。

这话说得直白一点：在数据中心里，电力、机柜、散热都是成本。一台物理机如果虚拟化层吃掉的资源越少，能开的虚拟机就越多，单台服务器的盈利效率就越高。与此同时，租户拿到的算力越“干净”，越不容易因为隔壁邻居的流量爆发导致自己网络抖动，用户留存率也越高。

所以选择把网络、存储、安全这些负载从CPU卸载到智能网卡上，不是某一家云厂商的心血来潮，而是云计算基础设施发展到一定阶段后的必然选择。腾讯云的玄灵网卡，本质上就是在这个必然趋势里拿出的自研方案。其实更早就有一批云厂商在做类似的事情，只不过有的把方案包装成了“裸金属+智能网卡”，有的包装成了“超融合基础设施”，大家走的路殊途同归。

4.2 中小团队真正能落地的收益

作为中小团队，最关心的不是云厂商之间的架构博弈，而是自己能不能真的受益。我个人判断，第九代CVM这套组合，对中小团队有三个实打实的好处：

第一个好处是网络质量的确定性。以前用共享型实例，高峰期网络抖动是常态，因为宿主机上其他租户的流量会互相干扰。现在数据转发路径被硬件隔离，流表规则在网卡里按租户隔离执行，这种“邻居干扰”会大幅缓解。对于做电商大促、抢购活动、直播弹幕这类流量波峰明显的业务，这个确定性比什么都值钱。

第二个好处是同价格下更省CPU。还是那句话，应用代码没变，实例规格没变，但可用的CPU核时变多了。相当于没涨价的配置升级。如果你正被CPU使用率压到需要扩容，先别急着加机器，可以先把旧实例迁到第九代，看看CPU水位下降了没有，再来决定要不要扩。

第三个好处是弹性伸缩的节奏更快。因为实例单机性能更强了，很多原本需要提前扩容的任务可以延后触发；临时任务也能用更少的实例跑完。云资源的计费方式基本都是按量付费，任务跑得快、实例用得少，账单自然就下降了。

4.3 一个实际的验证思路

如果你也想知道自己当前业务适不适合迁移到第九代CVM，这里给你一套我常用的验证方法，不用啥花哨工具，一条命令一条命令来：

1. 先做网络转发压力测试：用两台新代次实例对着压，一台跑 iperf3 -s，另一台跑 iperf3 -c <对端IP> -P 8，观察带宽能不能跑满预期值，同时 top 看CPU有没有被软中断打满。如果带宽很高但CPU还很闲，说明卸载效果到位。
2. 再做高并发应用层压测：部署一个Nginx或者Spring Boot服务，用 wrk -t8 -c400 -d60s http://<目标IP>/ 模拟固定连接数的请求压力，对比同规格老实例的QPS、P99延迟和CPU使用率。注意保持压测机和压测工具一致，只更换被测实例，数据才有可比性。
3. 顺便测一下存储：用 fio --randwrite=4k --iodepth=32 --numjobs=4 之类的方式压一下云盘，看IOPS和时延抖动。以前压存储的时候CPU占用率很高，现在如果CPU占用降了而IOPS还保持住，说明存储卸载生效了。
4. 重点关注最高点和variance：不要只看平均延迟。我多次遇到平均延迟不错、但P99突然掉到几倍的场景，通常是网络路径抖动导致。新代次实例因为路径更短，尾延迟的表现会比平均值更能说明问题。

4.4 一些值得注意的局限

玄灵网卡也不是万能的。它解决的问题是“虚拟化路径过长”和“CPU被杂务挤占”。如果你的业务本身是CPU密集型，比如纯计算、图像渲染，而且对网络IO的需求很低，那么这台网卡带来的体验升级就不会那么明显。CPU代际本身的提升才是你该关注的重点。

另外，虽然玄灵网卡把软中断压力降下来了，但应用本身如果写得“费CPU”，比如用了大量锁竞争、上下文切换，那该优化的还是得优化。硬件卸载解决不了软件层面的性能问题，它只是把你本来被浪费的CPU还给你，让你有更多余量去处理业务逻辑。

还有一个小细节值得注意：不要盲目追求最高规格实例。第九代CVM的更大带宽和更高PPS能力，是针对有真实需求的业务而言的。如果你只是跑一个小型管理后台，选一台低配置的新代次实例就够用了，没必要为了“性能冗余”多付钱。算力这个东西，够用、稳定、可弹性扩展才是关键。

我自己在跑高并发网关类业务时，最大的体感是：应用参数可以保持原样，但CPU使用率就是下去了，高峰期的抖动也少了很多。 那种感觉不是在用一台更强的机器，而是在用一台“更省心的机器”——把不该你管的事都替你挡在外面了。最后再分享一个小技巧：如果你的业务已经稳定运行在两台以上老代次实例上，可以先迁一台，通过负载均衡把一部分流量切过去跑几天，拿新老两侧的监控曲线做对比，数据比任何纸面参数都更有说服力。第九代CVM + 玄灵网卡这波升级，值得每一个还在为CPU水位和网络波动头疼的人认真试一试。