作者｜梁啟成

编辑 ｜Kitty

策划 ｜QCon 全球软件开发大会

当前，云计算已成为众多互联网企业支撑业务运行的关键基础设施，然而云计算的便利性和灵活性也带来了一系列资源成本管理挑战，包括成本增速过快、成本归属不清晰、缺乏有效成本控制手段、对云厂商高度依赖等。

在 InfoQ 举办的 QCon 全球软件开发大会（北京站）上，小红书混合云资源管理负责人梁啟成分享了《 小红书 FinOps 实践：云成本优化与资源效率提升之道》，重点介绍了小红书的 FinOps 通过技术优化手段提升资源使用效率，每年节省数亿成本的实践经验。

本文为该演讲的内容整理。主要包含以下方面：

第一部分：小红书用云概述

第二部分：成本优化面临的问题与挑战

第三部分：云成本洞察——内外账分离的尝试

第四部分：云成本优化实践

第五部分：总结与展望

以下是演讲实录：

大家上午好，我是来自小红书的梁啟成，很荣幸有机会来到 QCon 做分享交流，感谢大家来到小红书的场子，听我说说云成本优化的那些事，当然了，今天我也是带了不少干货来的，争取不令大家失望！

小红书用云概述

首先简单介绍下小红书的用云情况：

小红书在 2013 年成立之初，就把站点部署在了云上，天然就是一家长在云上的公司，2017 年伴随着大数据团队的建立，我们正式开始大规模地使用 EMR 产品，在 2021 年前后，SRE 团队开始在跨云环境下针对在线业务场景进行异地多活的容灾建设。当前小红书在公有云的资源体量规模，CPU 是千万核级别，GPU 是万卡级别，每天都在接收着海量金额流水的云产品账单。那么在云成本优化方面，我们应该做些什么？

成本优化面临的问题与挑战

我们不妨站在业务的角度去思考一个问题，如何避免技术资源成本因为业务增长而变得失控上涨？

参考 FinOps 框架提供的解题思路，可以从三个方面展开分析，比如：

业务知不知道自己每个月花了多少钱

使用了多少资源，成本分摊规则对不对

业务目标、资源动因是什么，能否给出具体的衡量指标，比如单位资源成本

首先看下云产品的折扣是否合理，有没有下降空间

接下来，我们再深入分析，有没有办法提升资源的使用效率，比如：内核升级、JDK 版本升级、动态调权等等，充分发挥昂贵资源的超强算力

重点关注跨团队协作流程是否高效，比如云资源开通权限有没有做好收口，是否有配套相应的资源申请审批流程

做好预算执行情况跟踪，以及定期组织预算 Review

成本优化面临的问题与挑战

简单来说，我总结为如下三点：

第一，要了解清楚资源使用现状以及成本构成；

第二，基于成本洞察的分析数据，尽快地做出应对决策，明确优化目标是什么，并针对性地进行资源使用优化；

第三，建立 FinOps 文化，尽可能将机制和流程做成线上化、自动化，提高方案实施的效率，并且做好持续运营的工作。

接下来，我将具体展开聊一聊，小红书在成本洞察和成本优化两个方向上的一些探索和实践经验。

云成本洞察探索

在成本洞察方面，我们经常会遇到这几类问题：

这个机器到底谁在使用，成本该算给谁

业务方不认可成本分摊的结果，为什么会有这笔费用，分摊比例是怎么定的、为什么是那么多

另一个则是出于数据安全考虑，财务和采购部门要求不能随意泄露云厂商的折扣信息，业务不能感知云账单的真实成本

商品化实现内外账分离

为了解决上述提到的问题，公司内部启动了技术商品化项目，对外统一混合云计费账单模型，对内屏蔽折扣、提供量价对应的资源账单，看清成本并实现精细化运营。

我们通过对自研的中台产品进行产商品上架管理，将外部账单作为产品的资源成本，然后按标准核、标准卡这种统一单位进行计量计费，最后再根据用量上报的资源归属关系，将量价对应计费账单出账给到对应场景和部门。

这样做的好处在于：

将之前不好拆分出去，留在中台的自持资源成本占比，从 15%+ 下降到了 5%

实现内外账分离之后，权责也更加清晰明了了

采购负责外账的商务 Saving

中台技术通过架构改造升级、分时复用、混部等手段，释放技术红利降低内部产品的单价

业务技术则关注资源的用量情况，以及资源利用效率是否符合预期

但与此同时，我们也带来了额外的工作量：

控制内外账金额偏差，整体上不要造成失真

中台产品上架管理维护，资源用量上报、计费项定价与计费出账

商品化实现内外账分离

上面这张图补充说了资源明细账单是如何关联匹配到对应的组织架构，也许各家公司的做法都不太一样，有的是基于资源 + 标签，有的是基于元数据规则匹配，我们公司是两种方法都用上了。

云成本优化实践

虽然钱已经花出去了，但云资源真的就被高效使用起来了吗？在这一章节我将分别对 CPU、GPU 两类算力资源来分享一些云成本优化的实践经验。

千万核规模的 CPU 算力用好了吗？

一般来说，我们会拿全局 CPU 利用率来衡量一家公司的资源使用效率怎么样，在行业内大概处于什么一个水平；在资源使用方式上，我们大致会区分：独占、共享、抢占这几种类型，其背后对应的资源保障程度是不一样的；另一方面，在线上业务正常运行的情况下，CPU 利用率曲线是有一定的规律，比如周末假期比较多人刷小红书，就会出来一条比较明显的周潮汐曲线。

那么小红书在千万核级别的 CPU 规模下，是如何提升资源使用效率的呢？

在线业务混部：工作负载性能瓶颈分析

当前小红书已经走过了全面容器化的阶段，所有在线服务都已经部署在 K8s 之上了。但我们发现一个现象，同属一个服务下的多个 Pod，它们彼此之间的 CPU 利用率分层非常明显，有的 Pod 已经到了 60%，但有的 Pod 连 30% 还不到，这给接口限流设置、服务容量评估都带来了许多麻烦。我们挑选了几个典型 case，进行深入的工作负载性能瓶颈分析，结果发现，我们过往使用虚拟机资源是比较粗犷的。

先给出结论，内存访问延迟的差异是导致 CPU 利用率分层的关键因素，但这个差异是怎么引入进来的呢？

可能是本身物理机机型存在 CPU 代差，这个很容易理解

可能是创建的这个 VM 申请的 CPU 内存资源，跨 NUMA 节点或者跨 Socket（插槽）了

这里简单拉齐一下认知，在多处理器系统中：

每个 CPU Socket 对应的是一个物理 CPU

在 NUMA 架构下，一个 Socket 及其直接连接的内存组成一个 NUMA 节点，并且在 AMD 的一些处理器架构还能支持将一个 Socket 进一步细分为多个 NUMA

在同一个 NUMA 节点下，CPU 访问本地内存的速度是快于访问其他 NUMA Node 内存的

因此，如果虚拟机分配到的 CPU 和内存资源出现了跨 NUMA 节点的话，内存访问的性能是相对比较差的，并且如果出现了跨 Socket，那么内存访问延迟将会更加明显。

有了这个输入以后，我们一起来看看这三个 case：

第一种情况，VM 申请到的资源在 0 号 Socket 下横跨了所有的 NUMA 节点，当进程启动以后，将会产生大量的跨 NUMA 内存访问，并且这种内存使用方式很难做到分布均衡的，也就造成了局部访问压力难以控制，最终导致了性能时好时坏，这张截图可以直观看出，当我们把 VM 从 NPS=4 替换成 NPS=1 以后，CPU 分层问题就基本上解掉了；

第二种情况，VM 申请到的资源横跨了 0 号和 1 号 Socket，这种情况在使用部分云厂商资源的时候有出现过，背后其实也反映出了云厂商对于物理资源售卖率与 VM 性能保障之间的取舍，同时在这种情况下，CPU 分层问题是最为明显的，把 VM 替换了以后，问题也随之消失；

第三种情况，是在相同 Socket 和 NUMA 节点下同时开出来了两个 VM，然而 VM 邻居之间也会竞争共享内存资源，当负载跑得越高，它们之间的竞争就会越为激烈，从截图可以发现，性能差的 workload 主要还是受到了对端 VM 的负载影响，当对面的 VM 负载降下来以后，它自身的性能也相应好了起来。

在线业务混部：工作负载性能瓶颈分析

上面主要解决的是 CPU 利用率分层问题，接着我们看下 CPU 利用率抖动的情况。

第一种情况，我们正在做宿主机的机型升级，结果发现在线服务的性能并没有提升反而变得更差了，原因是机型升配的同时 VM 规格也从之前的 64 核扩大到了 192 核。大家知道，进程所在 CPU 在申请内存空间的时候是需要进行 CPU 间相互通信同步的，而这个 VM 上还同时跑着 3 个一样的进程，但现在进程共享核数增加了 2 倍，每次申请内存都要通知另外 191 个 CPU，结果当大量内存申请来了的时候，触发了海量的 IPI 中断请求，造成了内核态层面的抢锁，最终导致了性能严重退化。最快的解决方案就是让每个进程少绑定一些 CPU，比如从 3 个进程共享 192 核，改成每个进程绑定 64 核，这样可以指数级降低 IPI 中断的数量。

第二种情况，是我们一些程序使用透明大页不当引起的。一个普通 page 是 4KB，一个大页是 2MB，大小相差了 512 倍。当关闭了透明大页后发现，page fault 只上升了一倍，说明虽然大量的内存申请了但是并没有真正用起来，并且都需要先 clear 一下，导致浪费了大量的 CPU 时间在做无用功。

第三种情况，是跟系统的内存管理分配策略有关，海量的 page fault 导致频繁释放内存刷新 TLB 快表，大量的 IPI 中断请求造成了内核态的抢锁，从而导致了 RT 的抖动，我们针对 jemalloc 版本以及参数优化以后，page fault 大幅减少，服务的 CPU 利用率从之前 30% 到现在能稳定保持在 85%，性能接近翻了 3 倍。

在线业务混部：工作负载性能瓶颈分析

除了上面提到的两大类情况以外，VM 的内存带宽、网络带宽、磁盘 IO 等限制，也同样会阻碍 CPU 利用率的进一步提升，比如：

内存带宽早于 CPU 到达瓶颈，带宽打满以后，访问延迟就会急剧上升

内存带宽打满触发 CPU throttle，从这张图可以看出，CPU 利用率抖动情况跟内存带宽使用基本上是同频了

另外一种情况则是，突发的请求量超出了 VM 规格自身的处理能力，也伴随出现了 CPU throttle，以及服务 RT 的抖动情况

在线业务混部：大 VM 小 Pod 策略

那么我们的应对策略是什么呢？简单概括起来就是：做大 VM 的规格，做小 Pod 的规格。

一方面，尽可能避免云厂商底层虚拟化黑盒不受控的问题；

另一方面，通过对在线服务进行混部，让 VM 上运行的业务足够的丰富，多业务混跑，并且每个 Pod 对于 VM 的占比尽可能减小，这样，在时间和空间上都可以借用邻居的资源，尽可能避免某种资源共振导致的抖动，比如这里的 CPU，之前遇到的内存带宽瓶颈等等。

这个在线业务混部的收益还是比较显著的，一个是解决了 CPU 分层的问题，让峰值利用率能跑得更高； 另一个是通过提升单 Pod 性能，核心服务的副本数能节省 30% 以上，缩容完成以后，给全局 CPU 利用率至少提升 5%。

万卡规模的 GPU 算力用好了吗？

随着近几年大语言模型的兴起，公司在 GPU 算力资源上的成本投入，也在逐步提升。那么如何衡量这些卡用得好不好呢？

最常见的就是看 GPU 利用率，一般来说跑训练任务的利用率都不会差到哪里去，推理用途的相对会低一些；除此以外，我们还可以关注饱和度相关的指标，来进一步评估训练任务的 GPU 资源使用效率，比如：MFU 模型浮点运算利用率、TensorCore 利用率 等等，它们表示的是实际有效计算占理论最大计算能力的比例。

接下来，我将介绍小红书在内容大模型方向的一些降本增效实践。

内容大模型降本增效：数据存储与传输

首先是数据存储方面，过往我们主要使用的是 tfrecord 格式来存储和读取 AI 机器学习相关数据，为模型训练和推理提供支持，它是以记录为导向的行存储方式，复杂数据类型的支持是比较弱的；我们通过替换使用 parquet 这种列存格式，不仅能高效读取和处理特定列的数据，同时也能显著减少存储空间的使用；最后结合数据湖技术的应用，我们可以方便地跟各种实时和批处理计算框架相结合。

由于当前不同业务所用到的 GPU 资源可能分布在了不同的云厂商或者不同的地域上，如果把 AI 公共数据集在每个地方都部署一份显然是非常浪费的，针对这种情况，我们增加了一层数据加速层与训练引擎相互配合，统一多云环境下的 AI 训练数据集，减少冗余存储，通过近端缓存，减少跨云数据的传输，并通过异构介质进行数据的分层管理。

内容大模型降本增效：自动调参

前面 AI 训练数据准备好了，接着来我们看下模型训练阶段的优化工作。在模型训练当中，一个比较突出的痛点是，在不同模型上找到性能最佳的参数配置，比如：并行训练方案、微批量大小（mirco batch size）和梯度累积步长（gradient accumulation steps）等等，通过充分发挥 GPU 硬件性能以实现更高的吞吐效率。

但是这个探索过程通常是手动完成的，并且耗费大量的时间与精力，原因在于：

不同的模型和模型大小在不同的 GPU 型号和规模上，其性能最佳配置各不相同

手动调试过程往往缺乏系统性和明确性，难以确定目标训练任务在给定的 GPU 资源上的性能上下限

手动调试通常只能找到较优配置，而非最优配置，无法充分重复利用 GPU 资源

调试过程高度依赖专家经验

因此，我们开发了智能调参工具，自动寻找最佳的系统参数配置，进而提高模型训练的速度。它利用模型信息、系统信息和启发式方法，来高效调节影响计算和内存效率的系统参数。

内容大模型降本增效：模型量化

模型训练调参结束以后，我们来看看模型压缩，常见做法就是 模型量化和知识蒸馏。

所谓模型量化，其实就是将浮点计算转成低比特定点计算的技术，它可以有效的降低模型计算强度、参数大小和内存消耗。通常会分为两个不同的实现阶段：PTQ 后训练量化 和 QAT 量化感知训练。

我们来看一个通过降低浮点数格式精度实现后训练加速的例子：

第一个关键是张量缩放（Tensor Scaling），它的意思是对张量中的元素进行数值大小调整的操作，比如这里提到的，使用 FP8 低精度格式来表达 FP32/FP16 这种高精度的数据，这里需要重点克服表示范围和精度下降相关的挑战；

从 Hopper 架构开始，新的 Tensor Core 支持了两个 FP8 的矩阵相乘，并以 FP32 或 FP16 格式进行累加，以此实现了高低精度的转化；

在 FP8 的 Per Tensor Scaling 技术中，我们选择使用延迟缩放（Delayed Scaling）方案，使用当前 Tensor 以往出现过的 amax 历史值 来预测当前的 amax 最大值。

实践结果表明，我们在 H20 上部署 Qwen2 7B 模型，进行全参数监督微调（Full-SFT），基于 FP8 训练模型的效率相比 BF16 有 40%+ 提升。

内容大模型降本增效：知识蒸馏

知识蒸馏（Knowledge Distillation）也同样是一种模型压缩技术，其核心思想是将一个复杂的大模型（教师模型）的知识传授给一个相对简单的小模型（学生模型），从而在保持较高预测性能的同时，大幅降低模型的复杂性和计算资源需求。

不同的蒸馏方案实际上是对各种“知识获取”与“知识迁移”方法的灵活组合。针对完整的蒸馏训练流程，我们根据训练数据的不同，将蒸馏方案划分为 Sequence-Level 蒸馏和 Feature-Level 蒸馏。

我们来看下内部模型的实测效果，根据 IFeval 综合基准评估，通用指令跟随能力下降 2~3%，推理性能提升 1 倍，成本节省 50%。

总结与展望

好，最后我们回顾一下今天的重点内容。首先，我们通过多部门协同践行 FinOps，从 成本洞察、成本优化和成本运营方向合理控制资源成本增长；其次，在成本洞察方面，通过商品化实现了内外账分离，看清资源使用量以及相应成本费用；接着，在成本优化方面，分享了 CPU 和 GPU 计算资源使用效率提升的实践例子：

CPU：基于大 VM 小 Pod 策略的在线混部，通过时空复用避免某种资源共振导致的抖动

GPU：从数据、训练、压缩等方面介绍了内容大模型的降本增效实践

最后，展望了我们从今年年初开始进行 AI for FinOps 的实践探索。

一方面，AI 技术可以更好的帮我们做成本优化，AI 技术是一个非常高效的优化器（给定优化目标）

另一方面，AI 技术可以更好的帮我们做成本洞察，对成本、效能相关数据做预测和异常发现

以上就是我今天分享的全部内容，谢谢大家。

作者介绍

梁啟成，小红书混合云资源管理负责人。多年 IT 资源管理与成本优化经验，曾深度参与头部互联网企业上云、大规模在离线业务混部，并持续推进业财一体化以及精细化的混合云资源成本管理，2024 年参与了信通院《IT 基础设施资源运营成熟度模型》标准制定，是 FinOps 文化的践行者。

会议预告

当前，云计算已成为众多互联网企业支撑业务运行的关键基础设施