`zhiqiangguo`
# 云服务器高密度技术突破综合材料

> **整理自以下资料**：
> - 《云服务器密度突破探索》汇报PPT（郭志强，2025.11.18）
> - 《高密度突破：云服务器的软硬协同驱动算力普惠》课程PDF（2026.03.06）
> - 《智能调度》汇报PPT（2025.12.26）
> - 《云服务器密度攻坚技术突破》技术文档

---

## 一、背景与战略定位

### 1.1 云服务器的本质

云服务器通过软件将物理服务器资源分割为多个独立的虚拟计算单元（统称虚拟机），用户通过互联网远程租用这些计算单元，获得与物理服务器等效的计算能力。提供给客户弹性、可扩展、可编程、可被集成的新基础设施服务。

腾讯云服务规模：
- **超亿核**云服务规模，服务全球客户
- **200万+** 订阅客户，随用随取
- 调度规模业界最大，KVM 开源贡献社区第一
- 星星海自研服务器，稳定性性价比全面提升

### 1.2 什么是高密服务器

高密服务器指在单位空间内集成更多计算资源，主要体现在四个维度的同步提升：
- **核心密度**：提高单位空间 CPU 核心数
- **内存密度**：配套内存容量与带宽提升
- **存储密度**：配套存储 IO 能力提升
- **网络密度**：配套网络带宽与会话能力提升

高密服务器的概念最早在1980年由 IBM 提出，IBM 认为服务器应通过"精简指令集"、"优化架构"，在有限空间内集成更多计算资源。随着现代服务器的发展，对高密的要求也越来越高，不单是追求核心密度，而是要求内存、存储、网络同步向高密方向演进，以达成单位空间算力翻倍增长的目标。

### 1.3 腾讯为什么坚定投入高密化路线

**市场背景与架构演变**

| 维度 | 传统架构 | 云原生架构 |
|------|----------|------------|
| 架构特点 | 单体集中 | 分布式高并发 |
| 对服务器的诉求 | 极致单核性能 | 性能-能效平衡 |
| 价值取向 | 高性能高单价 | 够用的性能 + 更低的价格 |

**差异化竞争路线**：在传统 AWS 引领下，云厂商卷极致单核性能、走同质化军备竞赛路线。腾讯云作为追赶者，因腾讯内部业务的诉求，需要走出差异化错位竞争路线，选择"普惠性路线"——以更低的价格提供足够用的性能，这一理念与 AMD 一拍即合。2017年联合推出搭载 Naples 的 SA1，2019年推出搭载 Rome 的 SA2，SA2 成为腾讯云历史上增长速度最快的机型，大获成功。

随着云原生架构的普及，行业对芯片的需求从"极致单核性能"转向"性能-能效的平衡"——在满足性能需求的前提下尽可能提升能效比，降低 TCO。腾讯云在高密路线上更早的投入，使其能更及时地适配云原生的设计理念。

---

## 二、高密技术四大挑战与突破

高密云服务器面临行业无应用先例的四大核心挑战：

| 挑战 | 核心问题 |
|------|----------|
| 故障率高 | 硬件可靠性不足，宕机率高 |
| 开不了机 | 虚拟化可扩展性瓶颈，超大规格无法启动 |
| 单核性能低 | CPU 拓扑复杂带来性能瓶颈 |
| 稳定性挑战 | 高并发 IO、网络抖动问题 |

高密技术的交付需经历 1.5~2 年的完整周期：提前 1.5-2 年 AMD & 腾讯云沟通 CPU 迭代细节→提前 1 年实验室验证新硬件、细致分析物理特性→提前 0.5-1 年产品化适配、性能稳定性压测验收→公有云发布，期间与 AMD 原厂专家团队紧密协作，深度分析线上应用情况。

---

## 三、硬件层面：星星海硬件底座可靠性突破

### 3.1 硬件可靠性提升

**挑战**：高密产品硬件可靠性要求更高，需从硬件失效机理出发，进行多层级可靠性优化，实现硬件全链路质量优化，有效降低硬件宕机率。

**技术突破**：

**① 失效拦截策略**
- 联合原厂优化 CPU 拦截策略
- 联合智能网卡开发团队优化 SOC CPU、DDR 拦截策略
- 目标：预防早期失效故障，将早期失效故障率控制在 **0.55%**

**② 散热器方案升级**
- 采用本地 1U + 远端 8 根热管的高性能散热器方案
- 增加热管辊压工艺，提升散热效率
- 结合 Tblock 设计，支持精确温度检测，配合精密风道管理，有效降低热故障率
- 成果：散热器性能提升 **42%**

**③ 内存故障治理（精细化 RAS）**
- 细分故障等级策略，全面部署 **MCA Recovery** 特性
- 分析故障类型，分级进行告警、业务恢复、故障隔离
- 隔离故障域，大幅降低内存故障导致的系统宕机
- 成果：内存故障宕机降低 **40%**

**④ 物理层监控保障**
- 优化智能网卡，监控 DDR5 散热温度和温升率
- 有效降低芯片内部和电容应力失效导致的宕机率

**⑤ SSD 亚健康监控**
- 监控与巡检日志，提前识别 SSD 亚健康状态，热插拔更换
- 背板和主板硬件防抖设计，防误触发保护等逻辑优化

**整体成果**：故障率下降 **40%**，低至 **0.12%**

### 3.2 内存带宽瓶颈突破

**挑战**：高密场景下，对内存带宽要求高的应用（如广告推荐），单核内存带宽可能成为瓶颈问题。

**技术突破**：

**① 高频信号优化**：在不改变 PCB 设计的前提下，增加内存信号的**背钻**，将内存频率从 **5600MHz 提升至 6400MHz**。

**② 固件协同调优**：推动 AMD 定制支持高频内存稳定性运行。

**成果**：
- 内存带宽提升 **14%**，使高密机型的普适性更强
- 支持广告推荐等内存敏感型业务在 **384核**场景稳定运行

### 3.3 推理业务时延优化

**挑战**：高密度 CPU 因核数快速增长，导致单核 LLC cache size 对比性能核略低（约为同代次 Pcore 的**一半**），在广告推荐场景中，影响模型推理服务的时延，进而影响业务体验。

**技术突破**：
- 通过底层固件优化，提升 LLC 缓存性能
- 减少 store 指令的延迟，提高指令流水线效率

**成果**：
- 可明显降低推理场景下 LLC miss 率，提高业务处理时延性能
- 零业务代码改动，硬件成本无增加

### 3.4 高密存储机型 IO 瓶颈突破

**挑战**：高密度存储机型对 CPU IO 中断处理能力要求日益增加，CPU 固有的 IO 能力已无法满足业务对多盘性能的需求。传统的 NVMe **静态中断聚合**虽能解决高并发时的性能，但当 IO 流量较小时会显著增加 IO 处理时延，无法同时满足高并发性能和低时延两个需求。

**技术突破**：动态中断聚合引擎

- 在内核 NVMe 驱动中加入 **IO 流量监控**，并根据流量情况完成中断的动态聚合
- 按流量阈值自动切换中断模式：**低流量 → 独立中断**；**高流量 → 批量聚合**
- 与 kernel 协同优化，通过 patchset 落地，上层业务无感知
- 提供 **sysfs 接口**，支持用户灵活设置动态聚合的阈值与聚合程度

**成果**：
- IO 并发能力显著提升，可充分发挥多 NVMe 盘性能优势
- 动态聚合功能确保小 IO 场景性能不受影响

### 3.5 智能故障诊断系统

**挑战**：需要从硬件失效机理出发，采用多级根因自动诊断，及时识别故障环节、通过智能巡检预防特定故障。

**技术突破**：

**① 芯片级问题自动定位系统**
- **首创** CPU 异常日志自动定位，锁定根因，保全现场
- 完成时间从数天压缩至 **20 分钟**，耗时缩短 **99%**
- 流程：宕机事件触发 → BMC 日志采集 → 带外命令诊断故障类型 → Scan 策略判断 → 自动发起 Scan → dump 日志 → AC 重启（需 AMD 密钥服务解锁）

**② AI Agent 分析智能化**
- 打通带外带内日志上报能力
- 利用专家知识库 + 大模型、部件专属 Agent + A2A 技术
- 对日志进行：防漏异常、智能总结、推荐改进、健康巡检、新品异常识别

**③ 多级根因自动诊断**
- 故障诊断系统分 1 级、2/3 级故障原因，结合 AI 宕机诊断
- 诊断路径：CPU SMI → CPU 宕机 → BIOS/BMC 收集 → 原始日志 DB → 信息提炼 → 一级过滤（单机/部件）→ AI Multi-Agent 二级诊断 → 三级 AI Agent（敏感业务规避、亚健康隔离、指引故障修复、Oncall 建议）

**成果**：
- 故障单全量自动诊断效率提升 **90%+**
- 当前故障自动明确化率 **92%**，单均耗时 5 分钟内

---

## 四、虚拟化层面：可扩展性瓶颈突破

### 4.1 大规格虚拟机无法启动问题

**挑战**：传统虚拟化技术链路中存在大量 O(N)、O(N²) 算法，CPU 核心数翻倍时，出现数据空间不足、性能线性衰减等问题。具体问题：

1. **大于 256C 实例无法启动**：传统中断虚拟化方案通过 **8bit** 进行具体路由投递，高密机型上这里的 8bit 仅能支持 0~252C 的投递模拟，因此无法支持超过 256 核的虚拟机。
2. **启动时间极长**：高密虚拟化后中断数量过多，需注册/刷新的 iommu container 过多，造成设备初始化/启动过慢——一台 **256C 实例启动时间长达 20分钟**。

**技术突破**：

**① 突破 256C 限制：基于软件的 viommu 方案**

虚拟化团队对比了三类方案后，选择了**基于软件的 iommu 实现方案**：
- qemu 对 guest 暴露一个 **iommu 设备**，用于存储 guest 设置的 **giova → gpa** 的映射
- qemu 实际配置 **giova → hpa** 的映射
- viommu 基于 intel-iommu 进行改造，仅支持公共部分的 cap，**兼容 intel/amd**

该方案优势：
  - 兼容性：不需要 guest 做任何修改，能适配绝大多数当代操作系统
  - 性能：与物理机相比吞吐量几乎没有损失

同时，vCPU 上限优化：O(N) 算法优化至 O(1)，支持上限从 255 突破至 **65535**。

**② 缩短启动时长：shared-container + 禁用 dma-remapping**

- 虚拟化侧使用 **shared-container 技术**
- 禁用 dma-remapping，使得全局仅使用**一张页表**
- 结合路由刷新隔离（不同设备独立队列更新 entry，避免全局下刷）以及 O(N²)→O(N) 的中断配置隔离优化

**成果**：
- **业界首家**支持超 256C 服务器的云厂商，全球支持最大规格虚拟机
- **CVM 最大规格支持 768 核**（SA9，AMD Turin-D 2.0GHz/3.5GHz）
- 全球唯一：GPU 机型/NVMe 机型全产品类型支持，特定前置要求少
- 业界领先，国内唯一：支持大规格 Windows 服务器
- 启动时长从 20min 降至 **1min 以内**

### 4.2 热迁移技术大升级

**挑战**：CPU 密度提高后，热迁移基本不可用：
- **标脏技术锁竞争**：热迁移的标脏技术依赖于 vcpu 退出标脏，产生大量锁操作。大核心下锁问题尤为突出，CPU 影响超 **30%**，使得热迁移几乎不可能。
- **停机时间平方数增长**：设备增加导致需同步的寄存器信息增加，设备状态（irq 配置等）迁移时需要全部中断，停机时间随设备数呈平方数增加。

**技术突破**：

**① 热迁移框架重构（DirectTDP 技术）**
- 内核中**独立一个线程**进行源端页表的构建与目的端页表的准备，以实现 **EPT 页表的一次性替换**
- 使用 **CAS（Compare And Swap）方式**建立脏页跟踪机制（DirectTDP），避免锁竞争带来的跟踪感知问题
- 传统方式需拆页过程中持续锁冲突，重构后通过 directTDP 原子替换页表，directTDP 提前创建页表，实现了 O(N) 优化至 O(1)

**② 设备状态拷贝优化**
- 在内存迭代的同时传输设备状态，提前启动设备
- 停机时刻只需恢复部分设备信息即可，避免了"所有设备都 load 完毕后才进行地址空间拷贝"的低效路径（传统方式会反复拷贝单个设备）
- 配合智能网卡实现动态流控

**③ 设备热拔性能优化**
- 整个 acpi 热插拔框架中，对 irq 配置过程进行重构
- 路由刷新隔离：不同设备独立队列更新 entry，避免全局下刷（秒级延迟 → 无延迟）

**成果**：
- 高密场景停机时间从**秒级优化至毫秒级**
- 智能网卡热迁移停机时间下降 **80%**
- 动态多流热迁移方案，整体最大带宽可达 **140 Gbps**
- 敏感客户免授权比例从 **39% 提升至 65%**

### 4.3 大规格内核性能与稳定性

**背景**：在大规格机型产品化过程中，内核侧发现大量提升空间和潜在宕机可能。高密服务器在**锁性能**上有极大问题，内核中涉及 spinlock/mutex 的部分非常容易被压测出严重的性能问题/稳定性问题。整体思路近似于在混沌测试中发现问题后解决问题。

**技术突破**（OS 团队内核关键部分合入代码优化）：

- **vmalloc 路径优化**：合入多个 schedule 点，使得部分宕机问题得以解决
- **high order PCP 技术**（腾讯自研）：high order 内存也支持 **per cpu 内存技术**，降低锁冲突的可能性，使网络带宽可轻松达到 **200G**（性能测试发现内存管理锁竞争是除 RPS 之外的另一瓶颈）
- **socket 缓存路由条路释放优化**：复杂网络测试中发现 socket 缓存路由条路释放动作存在明显锁瓶颈，进行 schedule 点优化

**成果**：大规格实例稳定性提升 **50%**

---

## 五、网络层面：高密场景网络性能突破

### 5.1 Smart EP 技术：单网卡设备数突破

**挑战**：高密场景下 CPU 翻倍后对设备数要求同步上涨。单智能网卡需支持 **4K+ 设备**（弹性网卡 + 云盘），远超业界 1K 水平，硬件资源（CPU/内存）捉襟见肘。

**技术突破**：软硬解耦设计

**核心设计理念**：
- 硬件只处理数据面的 **DMA 交互**部分
- PCIe 协议、Virtio 协议的握手交互交由软件处理，完全**软件定义设备**，软件接管设备的扫描枚举和驱动加载时的交互处理

**全虚拟化支持**（独立小系统中运行的 PCIe/Device 模拟器）：
- 实现了 Host/SoC 设备的模拟
- 软件实现了 PCIe 的 Switch 和 SRIOV
- 实现了 Virtio 的 legacy 和 modern 模式
- 实现了 Option Rom Bar 用以云盘启动和 pxe 启动
- 实现了自定义的 VF 管理 bar，支撑热迁移和 ctrlq 聚合
- 支持 Virtio 标准的 net 和 blk 设备，同时支持自定义的 vrdma 设备，以及 soc 上的 harp offload 设备

**关键时延保障**：PCIe 报文对时延要求极高，超出 Host 规定时间（一般 50ms）不响应 tlp 报文会引发 host CTO，导致母机异常甚至宕机。Smart EP 实现了高实时性，在各种场景均能在规定时间内完成报文应答。

**高可用设计**：通过**无状态双实例**设计，支持 ms 级热升级和异常自动恢复。Smart EP 软件主体运行在独立小系统上，不占用 SOC 核，将 SOC 核让给业务软件使用以提升性能。

**成果**：
- 单卡最大设备数 **4 倍于友商**（银杉 4K，玄灵 16K）
- 软件定义拓扑：支持单路、双路、双单路服务器，覆盖 CVM 和裸金属
- 单机设备数从 1024 突破至 **4096+**

### 5.2 Socket Direct 技术：解决跨 NUMA 网络性能

**挑战**：云服务器 CPU 密度上升，带来的 IO 需求持续提高。**跨 NUMA 访问时延增加**，同时 QPI 总线拥堵导致性能瓶颈，对网络性能的影响愈发严重。

**技术突破**：

**① PCIe 接口拆分**：独立的 PCIe 接口分别直连到两颗 CPU Socket 上，每个端口由其连接的 CPU 控制。

**② 子机直通**：将网卡与子机分配在同一 socket 上，网络访问无需经过**处理器间总线**，显著降低延迟，同时减少处理器间总线的流量，提升整体系统效率；确保网络流量均匀分布到多个 CPU 上，保障数据通道的强隔离性。

**成果**：
- 子机网络性能整体提升 **30% 以上**
- 业界**首先全网大规模灰度落地**，形成标准化解决方案，无缝支持后续产品迭代

### 5.3 VPC-LAG 技术：100G 网卡带宽突破

**挑战**：从 Milan 到 Bergamo，CPU 核心数扩大一倍，导致单核带宽比下降 **50%**。客户需要购买双倍资源维持带宽不变，影响产品竞争力。

**技术突破**：

**① VPC 端口聚合**：一个 VPC 端口对应一个物理设备模式，扩展成 **1 对 N 的 LAG 模式**，使一个 VPC 端口能够承载 2 个物理设备（2 个 100G 网卡）。

**② 子机业务无感**：TVS 与 Qemu 协同配合，实现单子机绑定 2 张 100G 网卡，但**子机内部仍为 1 张网卡**，业务无感知。

**③ 全链路适配**：管控面/数据面/卸载面三层协同拓展适配。

**成果**：
- 单实例实现 **200 Gbps 网络带宽**及 **5000 万 PPS** 包转发能力，业界领先
- 银杉 SA5 整机网络性能提升 **120%**，性价比提升 **30%**（对比 Milan）
- 最大带宽翻倍

### 5.4 Fornax 技术：千万级会话管理突破

**挑战**：传统云计算网络采用以软件为中心的管理架构，以"流"（Flow）为基本管理单元，通过单向命令操作硬件流表。在高密场景面临严重瓶颈：
- **规模与性能矛盾**：流表规模高达 **1600 万**条目，且流量分布均匀（非长尾特征），每分钟变化率超 100%，软件管理资源开销巨大
- **实时性不足**：软件需周期性轮询硬件状态，无法实时响应策略变化或硬件错误，易引发丢包和服务异常
- **可靠性挑战**：硬件流表单元可能发生物理失效，传统软件检测机制效率低

**技术方案**：

**① 会话单元替代流单元**：以"**会话**"为管理单元，聚合双向流量及连接状态，使硬件自主感知生命周期和策略变化。

**② 轻量级软件管理器**：软件仅保留易失状态，通过分散存储和按需恢复策略减少资源占用，软件存储占用减少 **80%**，CPU 使用率降低 **77%**，硬件开销不足 **2%**。

**③ 双向交互协议**：硬件驱动老化、变更检测和容错协议，主动触发事件（如会话过期），软件被动响应，替代全表扫描，响应速度从分钟级提升至秒级。

**④ 容错机制**：引入**纠错码校验**和硬件挂死检测，异常时自动切换至 CPU 转发，确保业务无感知。

**成果**：
- 支持 **1600 万会话条目**管理，实现零丢包和低延迟
- 在数百万台云服务器稳定运行超两年，服务数十亿用户，硬件故障零宕机记录
- 可部署于多种智能网卡平台
- **网络丢包率降低 4 个数量级**
- 论文以《Fornax: A Hardware-Centric Session Management in Large Public Cloud Network》为题入选 **SIGCOMM 2025**

---

## 六、存储层面：CBS 存储性能突破

**挑战**：随着公有云机型迭代，单个母机可售卖的 CPU 数目急剧增长，对单个母机上 CBS 存储带宽也有了更高要求；但为控制成本，给 CBS 预留的计算资源并未增加。同时，随着整机 CPU 密度提高，客户相同业务集群的子机会集中调度到同一母机上，业务 IO 模型一致，要求 CBS 在流量突发时确保时延不受大影响。

**技术方案**（六项协同优化）：

1. **硬件协议栈卸载**：结合智能网卡，将协议栈卸载到硬件，腾出计算空间，业务逻辑获得更多 CPU 算力
2. **CRC 计算迁移**：计算端和存储端协同优化，将 **CRC 计算**放到智能卡从子机拉取数据的过程中，不再由 SOC 上的 CPU 计算，从而节省 CPU 算力
3. **内存零拷贝**：软件层面实现对数据的**内存零拷贝**，整个 IO 链路上 CPU 不会碰触数据，从而提高带宽
4. **路由表无锁化**：路由表无锁化改造，大幅提高并发性能，从而提高 IOPS
5. **IO 请求粒度打散**：基于 IO 请求粒度的打散，将单个盘的 IO 均匀散布到所有存储核上，以应对突发流量导致单核打满的问题
6. **自适应取请求**：通过不断计算前几轮 IO 处理压力来决定下一轮取请求的数目，以降低 IO 在组件内的排队等待时间

**整体成果**（以银杉平台为例）：
- IO 提升 **200%**，IOPS 提升 **50%**
- 高带宽下长尾时延由 **19% 降低至 0.27%**（降低约 3 个数量级）
- 性能最大规格（**12 GB/s**）提升至行业内第一梯队

---

## 七、资源调度层面：深度适配高密架构与AI智能化

VStation 的资源调度核心策略是通过贪心的思想达到 CPU 利用率最优，本质是多项固定、预设的策略集。随着 AI 能力的提升，调度器正在向更"聪明"的方向演进：通过子机业务画像让调度器"**懂业务**"，通过需求规格预测让调度器"**会规划**"，从被动、固定的资源分配，转向主动、感知、预测的智能化资源调度。

### 7.1 装箱算法：深度适配 AMD 高密架构

**挑战**：AMD Chiplet 架构带来 CPU 拓扑复杂度爆炸，装箱组合数指数上涨。

具体对比（S5 vs SA5）：
- S5 的 CPU 只有 **1 层 NUMA Node** 结构
- SA5 的 CPU 有 **NUMA Node → CCD → CCX 三层**结构

| 机型 | CPU 架构 | 32核的组合数 | 64核的组合数 | 平均装箱耗时 |
|------|----------|------------|------------|------------|
| S5（96核） | 2×NUMA | C(32,2)=496种 | 1 种 | ~20ms |
| SA5（512核） | 2×NUMA + 32×CCX | — | 35,960 种 | ~180ms |

分配一个 64 核虚拟机，在 S5 只有一种装箱方案，但在 SA5 上却有 **3.5 万种**选择，极大影响 CVM 创建耗时。

**技术突破**：VStation 新一代调度器

将过去以 **kv 表结构**存储的资源信息，抽象为"**树状结构**"存储的物理拓扑树信息，包含了母机从 NUMA 到 CCD 和 CCX 的层级，以此感知 CPU 微架构。通过数据存储结构的改变，将过去装箱面临的**算数枚举扣减问题转为树节点遍历问题**，结合 Router Proxy 槽位分配算法，使一次调度请求类似 Redis 写操作（平均 **20ms**，最快 **6ms**）。

业界调度架构对比：对比 Kubernetes 方案和友商方案，腾讯 VStation 方案具有明显的速度优势。

**成果**：装箱耗时从 **180ms 降至 20ms**

### 7.2 交织装箱：规避 AMD 局部性能瓶颈

**挑战**：SA5（Bergamo）对比 SA3（Milan），**单 CCD 核心数翻倍**，但单 CCD & 单 Corner 的内存通道数量、内存带宽未按比例增加，导致 32 核等规格场景下，SA5 性能比 SA3 劣化 **16%**。

**问题根因**（AMD Chiplet 架构）：
- 单 Corner 内存带宽瓶颈（100GB/s）：三个 CCD 共享一个 Corner，Corner 内存带宽不足以发挥 3 个 CCD 的性能
- CCD 间访存 Latency 不均：CCD0 访问"内存通道0"与访问"内存通道11"的延时不一致

**技术突破**：

1. **交织装箱**：依据 CPU 拓扑树进行资源分配，按照 CCD、Corner **交织装箱**，32 核使用 2 个 CCD 缓解内存带宽瓶颈
2. **均衡调度**：根据业务画像进行均衡调度，避免叠峰现象
3. **统一访存（NPS=1 方案）**：消除 CPU 拓扑导致的访存 latency 差异

**成果**：32 核 Bergamo 虚拟机性能从**劣化 16% 提升到优化 25%**（对比 Milan），同时对同租户实例进行 L3 cache 层级反亲和打散，避免同特征业务的缓存干扰、内存带宽争用。

### 7.3 业务画像：让调度器"懂业务"

**挑战**：高密机型核心数是传统机型的数倍，虚拟机共享底层物理资源的争抢概率增加，内存带宽、网络带宽、TDP 等各资源使用指标**单机叠峰概率显著增加**，单机编排调度的重要性愈发明显。

**技术突破**：基于深度学习的**双塔模型**聚类，生成子机业务画像

**双塔模型架构**：
- **时间向量塔**：处理 CPU/内存使用率、网络带宽、内存带宽等时序特征，采用卷积网络，输出 **512 维向量**
- **文本向量塔**：处理实例别名、标签、实例机型族、规格等文本特征，采用 BERT 模型，输出 **256 维向量**
- **双向交叉注意力机制**：时间塔和文本塔相互注意对方特征，强化注意力，提升区分度，最终特征融合

传统业务画像基于"峰值"、"标准差"等特征数值进行调度，本方案能够实现：

**① 亲和度（反亲和打散）**：
- 识别用户子机的业务集群归属，按"业务集群"进行迁移打散
- 以 Goto（雅加达）为例：某些机型 90% 都是 Goto 的子机，一台母机全是同一业务，故障后影响近十台子机。拿到客户业务集群信息后，做到核心集群的迁移打散，故障影响大幅降低

**② 租户干扰（错峰均衡调度）**：
- 识别子机 24 小时使用情况，感知趋势变化
- 聚类结果：聚类a（昼峰型）、聚类b（夜峰型）、聚类c（平稳型）
- 错峰均衡调度，减少子机叠峰现象引发的资源浪费

**规模意义**：高密机型下，一台高密服务器等价于以往一个小型集群（例如 SA9 × 1 台 = 传统 S5 × 8 台，768 核 = 96核×8）。

### 7.4 资源腾空与规整效率提升

**挑战**：通过迁移不同实例，高效规整母机资源碎片，腾出更多空母机，是云上运营的重要手段。但单机核心数增加，腾空代价成倍增长，影响运营效率和资源成本。

**技术突破**：

**① 最短迁移路径算法**：规整过程中选择一条最短迁移路径去执行（状态转移图中寻优，考虑部分失败时的迁移路径回退）。

**② 全面的迁移评估模型**：根据客户分级（重保客户→不可迁移、敏感客户→部分时段无感迁移、普通客户→可迁移、授权客户→全时段无感迁移）和业务画像（CPU 负载、内存带宽、规格大小等），准确评估迁移可行性和迁移窗口。

**成果**：
- 腾空代价从迁移 **8 倍降至 3 倍**
- 资源腾空效率：50 万核/月 → **100 万核/月**
- 敏感客户免授权比例从 **39% 提升至 65%**（结合热迁移能力优化）
- **端到端资源利用率 > 90%**（AWS ~80%，阿里云 ~70%，火山引擎 ~80%）

### 7.5 需求规格预测：让调度器"会规划"

**挑战**：当前腾挪策略是尽可能规整整机、大核心的贪心策略，只针对现状进行此刻最优的调度，无法提前感知未来的资源需求变化，导致无效腾挪迁移，也无法在库存不足时提前触发采购搬迁。

**技术突破**：基于**时序大模型**进行定向训练与微调（基于 damo 平台搭建）

**预测能力**：
- 预测用户购买、退回行为
- 预测未来「机型」、「规格」的需求情况

**两大应用方向**：
1. **采购搬迁依据**：库存无法满足未来需求时，提前触发采购、搬迁
2. **腾挪规整依据**：预测用户购买规格趋势，按预测需求腾挪，避免无效腾挪迁移，提升规整效率

**成果**：
- 近期目标：挖潜 **20 万核**资源，提升资源利用率 **2%**
- 远期目标：通过调度器智能化预计减少采购 **80 万核**（挖潜 60 万核）

---

## 八、落地案例与效果

### 8.1 拼多多案例：高密存储性能突破助力赢单

**背景**：拼多多在 Bergamo 正式发布前积极参与 POC 及万核压测，是 Bergamo 机型规模**第一大**客户。客户认同腾讯云高密路线，深度协同调优。

**技术攻坚**：
- 虚拟机支持 **200G 网络带宽**
- 解决 NVMe 磁盘 **IO 时延抖动**问题
- 高密存储机型启动从 **20分钟优化至 30秒**

### 8.2 小红书案例：2年攻坚，从"坚决不用"到"真香"

**背景**：客户不认可高密路线，经过 2 年持续建联与技术攻坚，进行应用场景与技术分享、突破成果持续交流，并创新**动态关核方案**，深入客户场景提供最佳实践。

**性能数据对比**：

| 机型方案 | 业务 RT（ms） | 业务 QPS | RT 优化 | QPS 提升 |
|----------|-------------|---------|---------|---------|
| SA4（基准） | 463 | 87.3 | - | - |
| SA9（Turin-D） | 461 | 124.8 | +1% | +42% |
| SA9e（Turin-C） | 450 | 128.8 | +3% | +46% |

**竞争格局**：受制于高密适配难点，**阿里云至今未推出同机型完整规格**；2025年底实现小红书规模反超阿里云。

---

## 九、总体成果与技术领先性

### 9.1 规模增长

| 年份 | 高密机型云上规模 |
|------|----------------|
| 2023年 | 10万核 |
| 2024年 | 2500万核 |
| 2025年 | **4600万核** |

单位成本随单机核心上升大幅度下降（SA1 → SA9 持续优化，100% → 40% → 20% 的相对成本）。

### 9.2 四大挑战突破汇总

| 挑战 | 核心技术 | 核心成果 |
|------|----------|----------|
| 故障率高 | 首创CPU异常自动定位、拦截策略；先进散热设计（1U+8根热管）；精细化RAS；MCA Recovery全量部署 | 故障率下降 **40%**，低至 **0.12%** |
| 开不了机 | viommu 软件化（giova→gpa→hpa映射）；shared-container+禁用dma-remapping；热迁移框架重构（DirectTDP+EPT原子替换） | CVM最大规格 **768核**；启动时长从20min→1min；热迁移停机秒级→毫秒级 |
| 单核性能低 | 交织装箱（拓扑树遍历）；NPS=1统一访存；动态关核；业务画像双塔模型 | 32核性能从劣化16%提升到 **+25%** |
| 稳定性挑战 | Fornax会话管理（1600万会话零丢包）；VPC-LAG（200G带宽）；CBS多路优化（内存零拷贝+无锁化）；内核high order PCP | 丢包率降**4个数量级**；长尾延迟降**3个数量级**；网络带宽200G |

### 9.3 技术荣誉

- Fornax 网络技术论文收录 **SIGCOMM 2025**（《Fornax: A Hardware-Centric Session Management in Large Public Cloud Network》）
- 多项独家技术方案贡献至开源社区
- KVM 开源贡献社区第一

---

## 十、高密技术全链路工程体系

高密服务器的技术突破，不是单一的技术，涉及以下多个技术栈的协同攻坚：

```
硬件层（星星海）     散热方案（1U+8根热管）、RAS优化（MCA Recovery）、
                    内存频率提升（5600→6400MHz背钻）、LLC固件调优、
                    AI故障诊断（专家库+大模型+A2A）

         ↓

OS/内核层           spinlock/mutex锁优化、vmalloc schedule点、
                    high order PCP技术（腾讯自研）、
                    NVMe动态中断聚合引擎

         ↓

虚拟化层（QEMU/KVM） viommu软件化（256C→768C）、
                    shared-container+禁用dma-remapping、
                    DirectTDP热迁移重构（EPT原子替换+CAS脏页跟踪）、
                    设备状态拷贝并行优化

         ↓

网络层               Smart EP（软硬解耦、PCIe/Virtio软件定义）、
                    Socket Direct（PCIe拆分直连两Socket）、
                    VPC-LAG（1对N端口聚合，200G带宽）、
                    Fornax（会话管理替代流管理，1600万会话）

         ↓

存储层（CBS）        协议栈硬件卸载、CRC迁移至智能网卡、
                    内存零拷贝、路由表无锁化、
                    IO请求粒度打散、自适应取请求

         ↓

调度层（VStation）   物理拓扑树（NUMA→CCD→CCX）、
                    交织装箱（规避Corner带宽瓶颈）、NPS=1统一访存、
                    双塔模型业务画像（BERT+CNN+双向交叉注意力，反亲和+错峰）、
                    最短迁移路径+分级迁移评估模型、
                    时序大模型需求规格预测（damo）、
                    多目标权衡调度（规划中）
```

整个工程历经 **1.5~2年** 的前置软硬件规划研发、腾讯内部业务验证，再到公有云发布，与 AMD 原厂专家团队紧密协作，深度分析线上应用情况，最终交付至客户。

---

*整理时间：2026年6月*
*主要贡献者：郭志强（zhiqiangguo）、黎洁（yvonneljli）、潘睿（ruippan）*