企业官网建设流程全解析

如果你过去两三年一直在用 G4dn 跑 AI 推理，最近应该被各种新实例晃花了眼。先说结论：Amazon EC2 G7e 实例正式可用之后，我第一时间把手上的 OCR 和图像生成服务迁了过去，官方说的“推理性能最高提升 2.3 倍”不是营销话术，但它有一个必要前提——你得先把 CUDA 环境、TensorRT 版本、部署姿势调整到位，才能把这 2.3 倍真正吃进自己的业务里。这篇不是 AWS 新闻复述，是我从 G4dn 迁到 G7e 的完整记录：包括架构选型、benchmark 解读、实测数字、踩坑记录，以及哪些场景我建议你别急着换。

1. 2.3 倍的源头不是“CPU 变快”，而是 GPU 架构换了一代人

很多人一听说推理性能提升，第一反应是看 vCPU 或者主频，这个方向在 G7e 身上是错的。G7e 的核心变化在 GPU：从 G4dn 的 NVIDIA T4 换成了 NVIDIA L4。T4 是图灵架构，Tensor Core 还是第二代；L4 是 Ada Lovelace 架构，Tensor Core 已经到第四代，中间隔着 Ampere 和 Hopper 两代技术积累。这个代差带来的不是挤牙膏式的频率提升，而是计算单元和显存系统的双重换代。

1.1 L4 相比 T4，账面上最值钱的是这四样

先列硬件参数，再看这些参数对推理业务意味着什么：

• 显存从 16GB GDDR6 提升到 24GB GDDR6，别小看这 8GB 的增量。跑大一点的视觉模型或者长上下文的 NLP 模型时，16GB 经常得把 batch size 压到 4 以下，24GB 可以直接翻到 8 甚至 16，吞吐量是线性涨的。
• 第四代 Tensor Core 加入了对 FP8、INT8、INT4 的硬件级加速支持。这几个精度格式在 T4 上要么不支持，要么支持得不好。现在主流推理优化路线基本都是 INT8/FP8，模型量化后精度损失可控，吞吐收益却非常明显。
• NVENC 视频编码单元升级到第八代，支持 AV1 硬件编码。如果你除了推理之外还要做视频转码、直播推流、内容审核这类工作，G7e 的转码吞吐比 T4 高了不止一档。
• 功耗墙被压在 72W 左右，和 T4 基本持平。这意味着同样的机架功耗预算下，单台物理机能塞下更多 GPU，对大规模部署来说，单位机架推理密度直接上去了。

这些参数叠加起来，才是“推理性能最高提升 2.3 倍”这句话的底气。注意官网措辞是“最高”，不是“所有场景都提升 2.3 倍”。

1.2 G7e 实例规格怎么看：起步就是 12xlarge

G7e 的规格序列和 G4dn 不太一样，没有大家熟悉的 xlarge 或者 2xlarge 小规格起步，最小就是 g7e.12xlarge。我听 AWS 同学的反馈是，因为 L4 是低功耗 GPU，如果出单卡小规格，会被隔壁 G6 系列完全覆盖，所以 G7e 直接定位在中大规模推理集群场景。

我当时用的配置是 g7e.12xlarge，记录一下我这边看到的参数：48 个 vCPU、约 200GB 内存、4 张 L4 GPU。往上还有 g7e.24xlarge（8 张 L4）和 g7e.48xlarge（16 张 L4），具体到不同区域可能有差异，以官网的实例规格表为准。

选择 12xlarge 起步的决策逻辑，从我自己的业务角度看是这样：如果你已经需要 GPU 推理集群，单机 4 张卡起步反而更划算。因为网络栈、管理面开销都是按实例数量算的，4 张卡分摊这些成本，单位吞吐的管理成本更低。如果你的业务只是单张卡就能扛住的小流量，那 G7e 可能不是最优解，后面第四节我会专门讲选型。

1.3 为什么推理业务特别吃架构代差红利

推理和训练对硬件的需求有本质区别。训练是“把数据灌进去，等待权重收敛”，对算力上限要求高；推理是“输入进来，尽快算出结果返回”，对吞吐、延迟、显存容量、批处理效率更敏感。

把推理服务想象成一家餐厅的出餐口。T4 相当于一个只能同时放两个锅的小厨房，L4 相当于扩大了灶台数量、还换了更快的水龙头。客人点单（请求到达）后，你能同时开火的锅越多，出餐速度越快。L4 的 24GB 显存就是更大的操作台面，让你能同时备更多份菜。

具体到技术上，L4 的 INT8 Tensor Core 算力大约在 200 TOPS 量级，是 T4 的接近两倍；再加上更大的显存 buffer 空间，实际吞吐提升经常能超过三倍。所以官方给“2.3 倍”这个保守数字，背后其实是硬件底子给足了余量。

2. 读懂“2.3 倍”的正确姿势：官方 benchmark 是上限，不是你的基线

看到“最高 2.3 倍”这种宣传语，老手第一反应一定是追问：什么模型测的？什么 batch size？什么精度？延迟还是吞吐？这些问题不搞清楚，你很难判断自己的业务能不能复现这个提升。

2.1 官方 benchmark 覆盖的负载类型

根据 AWS 官方博客和相关文档的信息，G7e 的 2.3 倍主要基于典型推理负载对比 G4dn 得出，覆盖这几类：

• 视觉模型，比如图像分类（ResNet-50）、目标检测（SSD 系列）；
• NLP 模型，比如 BERT-Large 的句子分类和抽取式问答；
• 生成式 AI 方向，比如小型 LLM（7B 参数级别）的文本生成推理；
• 部分图像生成场景，类似 Stable Diffusion 1.5 的分步推理。

这里有个细节值得注意：这些 benchmark 大多是在批量推理（batch inference）条件下测的，而且输入尺寸是固定且适中。如果你的场景是单请求、小 batch、极端追求首字延迟，那你感受到的提升幅度大概率到不了 2.3 倍，可能在 1.5 倍上下浮动。

2.2 为什么我的业务真的吃到了接近 2.3 倍的提升

我当前跑得最重的两个服务，一个是 PaddleOCR 中文识别，一个是基于 Stable Diffusion 的批量图像生成。前者用 INT8 量化后的模型，后者用 FP16 精度 + 固定 batch size 8 的方式推理。

迁移到 G7e 之后的实测数字：

• OCR 服务：在同样的请求并发下，P95 延迟从 210ms 降到 125ms 左右，吞吐量提升约 1.9 倍；
• 图像生成：因为显存从 16GB 升到 24GB，batch size 从 4 提到 8，整体吞吐提升接近 2.6 倍，超过官方的“2.3 倍”。

为什么图像生成场景提升幅度更大？关键在显存容量。Stable Diffusion 的中间 feature map 在 batch size 8 时，T4 的 16GB 根本装不下，只能降 batch 或者切分计算。L4 的 24GB 让大 batch 变得顺理成章，GPU 计算单元利用率上去之后，吞吐自然水涨船高。

所以我的建议是：你要是做图像生成、视频理解这类显存敏感型推理，G7e 的实际收益会比官方宣传的更高；如果单纯做小 batch 的文本分类、实体抽取，提升幅度可能没那么夸张，但延迟仍然会实打实下降。

2.3 性能翻倍不等于成本减半，这笔账要分开算

性能提升归提升，成本账是另一件事。我以美东一区当时的按需价格做参考（价格随时波动，具体以 console 为准）：g7e.12xlarge 的时单价大约是 g4dn.12xlarge 的 1.4 倍左右。但单位时间能处理的请求数涨了 1.9 到 2.6 倍，所以算下来的单位请求成本是下降的，估算大约下降了 25% 到 35%。

我的结论很简单：如果你的业务已经到了需要持续跑推理服务的规模，迁移 G7e 大概率是划算的；但如果只是偶尔跑几个模型实验，按需开一台 G7e 的绝对价格可能让你心疼，不如先用 Spot 或预留容量。

3. 从 G4dn 迁移到 G7e：我的完整实测记录和三个坑

3.1 我为什么选了 g7e.12xlarge 而不是别的规格

我的业务是同时跑 3 个 GPU 推理服务：OCR、图像生成、还有一个小型 LLM 文本分类。三个服务加起来每个模型大概需要 2 到 3GB 显存，如果放在单卡 L4 上足够，但为了故障隔离和独立扩缩容，我用 4 张卡分别承载。

g7e.12xlarge 刚好 4 张 L4，单卡 24GB，给每个服务单独分配一张卡，互不干扰。这个选择还有一个附加好处：如果某个服务流量突然上涨，我可以在同一实例内临时把另一个服务的显存配额借过来，灵活性比 G4dn.12xlarge（也是 4 张 T4，但每张只有 16GB）好很多。

3.2 迁移流程梳理：AMI、驱动、CUDA、容器镜像

迁移过程本身不复杂，但细节多。我梳理一下我的操作流程：

1. 准备自定义 AMI：我基于 Amazon Linux 2023 创建了新的 AMI，而不是直接在原 G4dn 实例上原地升级驱动。新实例、新环境、干净的驱动栈，避免旧依赖残留干扰排查。
2. 安装 NVIDIA 驱动：G7e 需要 535 或更高版本的驱动才能识别 L4。如果直接从老 AMI 启动，驱动版本太低，nvidia-smi会报 Unknown Error。我用的是 NVIDIA 官方 CUDA 12.2 仓库安装的驱动 550 版本，一次性到位。
3. 升级 CUDA 和推理运行时：我的服务原本基于 CUDA 11.8 编译，L4 的某些算子需要 CUDA 12.x 才能完全发挥。我给容器镜像升级到 CUDA 12.2，重新编译了 ONNX Runtime 和 TensorRT 的插件。
4. 重新构建容器镜像：我用的是 ECS 上的自定义推理服务，所以这里重点是 Dockerfile 里的基础镜像从nvidia/cuda:11.8换成了nvidia/cuda:12.2.2-runtime-ubuntu22.04，并重新拉取最新的 PaddleOCR 和 diffusers 依赖。
5. 启动验证：先做小流量灰度，观察 GPU 利用率、显存占用、延迟指标，逐步切流量。

这套流程在半天内能跑完，真正的耗时主要在模型重新导出和 INT8 校准上，纯环境准备 1 到 2 小时足够。

3.3 实测对比：OCR 和图像生成的具体数字

我在同一时间段、相同请求压力下做了 A/B 对比，结果如下：

OCR 的提升主要来自 INT8 算子加速；图像生成则明显是显存+batch size 双buff。这里要注意一点：我把图像生成的 batch size 从 4 调到了 8，这是显存有余量之后才能做的调整。如果你迁移后不调整 batch size，提升幅度会打折扣。

3.4 踩过的三个坑，每一个都值得写下来

第一个坑：老驱动版本直接不认卡。我第一次尝试直接用原来 G4dn 的 AMI 启动 G7e，开机后nvidia-smi直接报“No devices were found”。排查到最后发现是驱动版本停留在 470 系列，完全不认识 L4。解决方法是 SSH 进去重装驱动，但如果 AMI 里已经打了nvidia-driver-latest-dkms，更新内核模块重启即可。

第二个坑：CUDA 版本对算子优化的影响非常大。最开始我只换了驱动，CUDA 还是 11.8，跑同一份 PaddleOCR INT8 模型，吞吐只提升了 30% 左右。升级到 CUDA 12.2 后，同样的模型直接翻倍到 1.9 倍。这说明 L4 的很多性能红利需要新 CUDA 版本才能解锁，不是光换硬件就行。

第三个坑：实例存储盘是临时盘。G7e 系列自带 NVMe 实例存储，速度很快，但实例重启或停机后数据会丢。我一开始把模型权重放在/mnt/local上，省事也快，结果一次维护重启后模型全没了，重新拉镜像和加载冷模型花了十几分钟。后来规规矩矩改成从 S3 拉权重到内存加载，或者放到 EBS 持久卷上，才算安心。

4. 冷静选型：G7e 不是所有推理场景的银弹

4.1 横向对比：G4dn、G6、G6e、G7e 怎么选

AWS 的 GPU 实例家族现在非常密，容易看花眼。我的简化理解方式是按定位分三层：

• G4dn：T4 GPU，推理老将，便宜但性能天花板低，适合预算有限、显存需求不大、模型老旧不上量化的场景。
• G6 / G7e：都是 L4 GPU，主打高性价比推理。G6 有从小规格到中规格的平滑选择，小流量起步合适；G7e 专注于中大规模集群，规格起步高，适合有确定性流量、追求单位吞吐成本最优的场景。
• G6e：L40S GPU，48GB 显存，面向更大的模型、模型微调、以及高分辨率图像生成，价格更高，但显存和算力都比 G7e 强一档。

一句话总结：你手里如果已经有一批 G4dn 在稳定跑生产，直接迁 G7e 是同代际升级的最佳路径；如果刚起步、单卡就够，别纠结 G7e，用 G6 或 G4dn 小规格更务实。

4.2 哪些场景我不建议你用 G7e

第一类是极低延迟敏感型交互服务，比如实时语音对话、实时翻译。这类服务首包延迟要求 100ms 以内，G7e 虽然比 G4dn 快，但单请求延迟的红利远没有吞吐红利大，性价比不如把模型量化压缩后用更小的实例分散流量。

第二类是训练和微调场景。G7e 的 L4 没有 NVLink，多卡通信走网络，训练大模型的效率比较差。训练请用 P5/P4d 这类专门实例，或者用 G6e 的 L40S 单机多卡做轻量微调，别拿 L4 硬撑。

第三类是偶发性的短时任务。如果你一个月只跑几次推理任务，每次半小时，G7e 的按需价格会让单次任务成本很难看。这种情况用 Spot 实例或 Serverless 推理（比如 AWS SageMaker Serverless）反而更划算。

4.3 Spot 和 Savings Plan 能再省多少

我在 G7e 上线初期就开通了 Spot 请求，实测下来命中率不错。我观察到美东一区和美西二区的 G7e Spot 价格大约是按需的 35% 到 65%，相比 G4dn 的 Spot 价格比例略高一点，但算上性能提升，综合成本优势依然明显。

如果业务需要长期稳定运行，建议先买 Savings Plan（计算节省计划）覆盖一部分实例，剩余流量用 Spot 承接。我自己是 60% 用 Savings Plan，40% 用 Spot，整体成本比纯按需降了 50% 以上。当然 Spot 被回收是常态，一定要做好被中断后的自动重新调度，别期待它像按需一样稳。

5. 生产环境落地 G7e 的几条实用补充

5.1 在 EKS 上用 Karpenter 管理 G7e 节点池

如果你是 EKS 用户，值得花点时间把 Karpenter 的 nodeTemplate 和 provisioner 配置好。G7e 实例的规格比较高，如果按照传统 Node Group 常驻，空闲时段的资源浪费很扎眼。我的做法是：

• 建一个 G7e provisioner，限定实例类型为g7e.12xlarge和g7e.24xlarge；
• 设置 consolidation 策略，让 Karpenter 根据 Pod 请求自动合并或缩减节点；
• 配置 Spot 池为优先，按需作为 fallback；
• 给 GPU Pod 添加显存和 GPU 数量的 resource request，Karpenter 会自动调度到合适规格的 G7e 节点。

这套配置跑下来，集群里 GPU 节点数量比之前 G4dn 时代少了接近一半，但总吞吐反而高了，运维成本明显下降。

5.2 监控指标和故障排查的几个经验

GPU 监控不能只看 CPU 和内存，要接 DCGM（NVIDIA Data Center GPU Manager）指标。我用 Prometheus 采集的指标包括：DCGM_FI_DEV_GPU_UTIL（GPU 利用率）、DCGM_FI_DEV_FB_USED（显存使用）、DCGM_FI_DEV_GPU_TEMP（温度）、DCGM_FI_DEV_POWER_USAGE（功耗）。

这里有一个经验：GPU 利用率不是越高越好。如果利用率长期 99%，说明 batch size 可能调得过大，请求排队时间拉长，P95 延迟会恶化。建议把 GPU 利用率控制在 70% 到 85% 之间，保持合理的响应速度。

遇到 GPU 异常时，第一步都是查/var/log/syslog和nvidia-smi -q，重点看有没有 Xid Error。如果出现 Xid 79 或 Xid 31，大概率是驱动问题或 GPU 掉卡，需要检查散热和电源。连续出现 Xid 79 的时候，我直接开工单让 AWS 换底层宿主机，比自己折腾系统快得多。

5.3 迁移之后还能做哪些扩展

G7e 落地稳定后，我开始把一部分离线批处理任务（比如视频内容审核抽帧、图片去重）从 CPU 集群迁到 G7e 配合批量推理来跑，效果比预期好，因为 L4 的 NVENC 在视频抽帧时吞吐极高，单台实例一小时能处理几万分钟的视频素材。

另一个方向是结合 NVIDIA TensorRT-LLM 跑量化后的 7B 到 13B 模型在线推理。L4 的 FP8 支持和 24GB 显存，跑 7B 模型 INT8 量化完全够用。如果你的业务已经开始用 LLM 做信息抽取或者文本分类，可以认真考虑这个组合。

我个人最大的体会是：G7e 不是把旧的 T4 换成了新的 L4 这么简单，它更像是一把钥匙，解锁了过去因为显存不足、算子不支持而不敢尝试的优化路线。硬件到位之后，下一步就是把自己的模型服务用最新推理引擎重新打磨一遍，这才是真正把 2.3 倍吃干榨净的方式。