香港GPU服务器推理对比：RTX 4090 48GB与A100 80GB怎样控制变量测试？

香港 GPU 服务器上，RTX 4090 48GB 与 A100 80GB 的推理对比，第一步不是直接运行相同模型，而是确认“4090 48GB”究竟代表什么。标准规格的 RTX 4090 通常是单卡 24GB 显存，服务商标注的 48GB 可能是两张 24GB 显卡的总显存，也可能是特殊改装或产品页面的聚合标识。若把两张 RTX 4090 的显存总量直接与单张 A100 80GB 对比，显存容量、GPU 数量和卡间通信同时发生变化，测试结果无法归因。

可复现的做法是先建立单卡基线，再单独增加第二张 RTX 4090，最后观察长上下文、高并发和不同精度下的变化。模型、推理框架、驱动、输入输出长度、批量、并发、时间段和网络路径均保持不变，每轮只调整一个变量。这样得到的结果，才能回答“哪种配置更快”“哪种配置更容易装下模型”以及“香港服务器的网络是否掩盖了 GPU 差异”。

1. 先确认“RTX 4090 48GB”的实际形态

1.1 单卡显存与总显存不是同一个指标

A100 80GB通常表示一张 A100 显卡拥有 80GB 显存；而“RTX 4090 48GB”需要拆解为以下几种可能：

两张 RTX 4090 的显存一般分别属于两张卡，不会自动合并成一个可供单个进程直接使用的 48GB 显存池。只有在模型支持张量并行、流水线并行或其他分布式切分方式时，第二张卡才可能参与同一个推理任务。

例如，一个模型需要 30GB 显存：

• 单张 RTX 4090 24GB无法直接装下完整模型；
• 两张 RTX 4090 合计 48GB，可能通过张量并行运行，但需要额外的卡间通信；
• 单张 A100 80GB可以在显存容量上直接容纳模型及运行时缓存，但仍需检查框架、权重精度和上下文长度。

因此，报告中应分别写成“1×RTX 4090 24GB”“2×RTX 4090 24GB”和“1×A100 80GB”，不要只写“4090 48GB”。

1.2 交付时先核对 GPU 数量、显存和型号

在 Linux 服务器上，可以先执行以下只读命令：

nvidia-smi --query-gpu=index,name,memory.total,driver_version,power.limit,pci.bus_id --format=csv

重点查看：

• name 是否为预期型号；
• memory.total 是每张卡的显存，还是服务商页面中的总量；
• GPU 数量是否与订单一致；
• 驱动版本是否相同；
• 功耗上限是否被人为限制；
• pci.bus_id 是否能区分多张卡。

如果需要观察多卡之间的拓扑关系，可执行：

nvidia-smi topo -m

这个结果用于确认两张 RTX 4090 是否通过 PCIe 交换芯片连接、是否跨 NUMA 节点，以及 A100 是否具备特定的高速互联。A100 的 PCIe 与 SXM 版本在功耗、散热和互联能力上可能不同，不能只依据“A100 80GB”这一名称判断。

2. 建立统一基线：先不比较“总显存”

2.1 基线的目的

第一轮只验证单 GPU 在相同推理任务下的表现：

• 1×RTX 4090 24GB；
• 1×A100 80GB；
• 相同模型；
• 相同精度；
• 相同输入输出长度；
• 相同批量和并发；
• 相同软件环境。

这轮测试不回答“谁能装下更大的模型”，而是观察在两张卡都能正常运行的任务中，单卡延迟和吞吐有什么差异。

第二轮再加入 2×RTX 4090 24GB，用来回答多卡配置能否抵消单卡显存不足，以及卡间通信会带来多大的代价。此时比较对象已经变成“2×4090配置”和“1×A100配置”，属于配置级比较，不应描述成单卡性能排名。

2.2 以生成式模型作为示例基线

如果测试的是大语言模型，可以选择一个两种配置都能稳定加载的 7B或8B模型，先采用 FP16或 BF16，不启用量化和专家混合。示例基线如下：

如果测试的是图像分类、目标检测或视觉语言模型，则应固定图像分辨率、预处理方式、输入数量和后处理逻辑。不要将文本生成的 token/s 与图像推理的 images/s混用。

2.3 指标必须分开记录

生成式模型至少应记录以下指标：

TTFT、TPOT和端到端延迟不能互相替代。输入很长时，预填充阶段可能让 TTFT显著增加；输出很长时，解码阶段的 TPOT会主导总时间。

对于输出长度固定为 128 tokens的请求，端到端时间可以近似表示为：

端到端延迟 ≈ TTFT + 128 × 平均每 token 解码时间

如果记录的是 100 tokens/s，则每个输出 token平均需要 10ms；如果 TTFT为 50ms，生成128 tokens的理论时间约为：

0.05秒 + 128 ÷ 100秒 ≈ 1.33秒

实际结果还会包含调度、序列化、网络和服务端排队时间，因此应以服务端时间戳和客户端时间戳分别记录。

3. 每次只改变一个关键变量

3.1 变量一：GPU形态

第一轮测试只改变 GPU 型号，其他条件保持基线一致：

观察重点不是简单看某一个平均值，而是判断性能变化来自哪里：

• 单请求低并发时，显卡时钟和内核效率可能影响结果；
• 多并发时，显存带宽、调度能力和批处理效率的影响会扩大；
• 长上下文时，KV Cache占用和显存带宽成为重要因素；
• 2×4090时，张量并行通信会增加额外同步开销。

两张 RTX 4090 不一定是单张卡的两倍吞吐。若模型每一层都需要在两张卡之间交换激活值，PCIe带宽和拓扑会影响多卡效率。

3.2 变量二：精度

精度测试应在同一 GPU 配置上逐项进行，不要同时换模型或推理框架。建议顺序如下：

1. FP16；
2. BF16；
3. INT8或其他量化格式；
4. FP8或框架支持的低精度路径。

A100和RTX 4090都可能支持多种低精度计算，但具体收益取决于驱动、CUDA、框架版本、算子实现和模型结构。不能看到硬件支持某种精度，就直接假定推理吞吐会提升。

每次切换精度后，应同时记录：

• 权重显存占用；
• KV Cache显存占用；
• TTFT；
• 输出 token/s；
• P95延迟；
• 输出一致性或精度指标。

如果量化后速度提升，但输出质量明显下降，那么它属于精度与质量的取舍，不应单独归入 GPU性能提升。

3.3 变量三：Batch与并发

Batch size和并发数必须区分：

• Batch size通常指一次提交给模型的样本数量；
• 并发数指同时处于服务处理流程中的请求数量；
• 动态批处理还会受到请求到达时间和调度窗口影响。

建议先固定并发为1，测试 batch 1、2、4；随后固定 batch策略，只改变并发数1、2、4、8、16。每次测试都要保持请求内容和输出长度一致。

参考记录表可以如下：

这里的重点是趋势，而不是将不同批量下的数值直接横向排列。高并发下吞吐提升的同时，P95延迟可能快速上升；如果业务对交互响应有严格要求，就不能只看平均吞吐。

3.4 变量四：输入长度和输出长度

长上下文是 A100 80GB与 RTX 4090显存差异容易体现的场景。可以固定输出长度，只改变输入长度：

• 512 tokens；
• 2,048 tokens；
• 4,096 tokens；
• 8,192 tokens。

随后固定输入长度，只改变输出长度。这样可以区分预填充压力和解码压力。

当输入长度增长时，显存并不只增加模型权重，还会增加 KV Cache。单张 RTX 4090可能在较长上下文或较高并发下先达到显存上限。两张 RTX 4090虽然总显存更大，但需要确认框架能否正确切分 KV Cache，以及切分后通信是否影响延迟。

如果测试中出现显存不足，应记录“无法完成该配置”，不要把它简单记为吞吐为0。显存容量本身就是推理可用性指标。

3.5 变量五：香港机房网络与测试时间

GPU计算和接口响应是两个层面。为了确认香港 GPU服务器本身的推理能力，应先通过本机回环地址或同机进程测试，尽量排除公网网络：

• 本机直接调用推理服务；
• 同一内网的独立客户端调用；
• 外部业务客户端调用。

三种方式分别记录客户端总耗时和服务端处理耗时。如果服务端处理时间接近，但外部客户端的 P95明显升高，问题更可能来自网络路径、连接复用、带宽、请求排队或跨地域链路，而不是 GPU 型号。

同一配置还应至少在两个时间段重复测试。测试时间变化可能带来：

• 宿主机共享资源变化；
• 机房出口拥塞变化；
• 多租户 GPU占用变化；
• 运营商到香港机房的链路变化；
• 服务商后台调度或限功耗变化。

时间段不是 GPU性能变量，但它会影响最终用户看到的响应时间，因此应作为单独的环境变量记录。

4. 让测试过程可复现

4.1 固定软件环境

两台服务器至少应核对以下内容：

nvidia-smi
python3 --version
uname -a

还应记录：

• NVIDIA驱动版本；
• CUDA运行时版本；
• PyTorch或其他框架版本；
• 推理服务版本；
• tokenizer版本；
• 模型权重哈希或文件版本；
• 容器镜像摘要；
• CPU型号和内存；
• GPU功耗限制。

如果一端使用容器、一端直接安装，或者一端启用了特定的编译优化，测试结果会混入软件变量。更稳妥的方式是使用同一镜像，只在启动参数中改变 GPU数量和目标设备。

4.2 预热与正式采样分离

首次请求可能包含模型加载、CUDA上下文建立、内核编译和显存分配，不能与稳定运行阶段混在一起。可以采用以下流程：

1. 启动服务并等待模型加载完成；
2. 使用固定请求预热20至50次；
3. 丢弃预热数据；
4. 发送至少100次正式请求；
5. 记录每次请求的服务端开始时间、首 token时间和结束时间；
6. 计算平均值、中位数、P95和P99；
7. 重新启动服务后重复一轮，观察缓存影响。

如果服务具有动态批处理功能，应记录请求到达间隔。连续发送请求与按固定间隔发送请求，可能得到完全不同的排队结果。

4.3 监控显存、功耗和利用率

测试期间可以使用以下命令持续观察 GPU状态：

nvidia-smi dmon -s pucm -d 1

其中可重点关注功耗、GPU利用率、显存利用率和编码或复制引擎状态。若发现：

• GPU利用率长期较低；
• CPU利用率很高；
• 显存占用稳定但吞吐不变；
• 功耗明显低于配置上限；
• 多卡中一张卡繁忙、另一张卡空闲；

就不能直接把结果归因于 GPU算力。可能存在 tokenizer、数据读取、CPU调度、通信拓扑或服务线程配置问题。

5. 参考结果：如何阅读一次控制变量实验

下面给出一组用于演示判读方法的参考数据。它不是香港某个机房的实测结果，也不代表固定型号在所有软件版本下都会得到相同数值。测试条件设为同一 8B模型、FP16、输入512 tokens、输出128 tokens、batch 1。

这个示例中，1×RTX 4090的 TTFT较低，但 A100的持续解码速度更高。若只测单个短请求，二者体感差异可能不明显；当输出长度增加或并发提升时，持续吞吐的差异会被放大。

2×RTX 4090的结果不能写成“48GB显存击败80GB显存”，因为它使用了两张卡，并引入了张量并行通信。正确的描述应是：在该模型、该并行策略和该软件栈下，两张 RTX 4090的总吞吐高于单张 A100，但这并不代表它在单请求延迟、容错、显存连续性和运维复杂度上都占优。

再看并发变化的参考样本：

从这个参考样本只能得出条件化判断：

• 低并发、短输出场景下，RTX 4090可能具有较好的单请求响应表现；
• 高并发场景下，A100的持续吞吐和显存带宽可能更有优势；
• 两张 RTX 4090适合单独评估多卡并行效率，不能用单卡指标推算；
• P95比平均值更适合评估在线接口的稳定响应；
• 如果模型在单张 RTX 4090上已经接近显存上限，继续提高并发可能先触发显存不足，而不是平稳降低速度。

6. 长上下文与多卡配置要单独验证

6.1 80GB显存的价值不只是“能装更大模型”

A100 80GB的主要优势之一，是可以为模型权重、KV Cache、运行时缓冲区和批处理预留更多空间。实际可用容量还会受以下因素影响：

• 权重精度；
• 模型架构；
• 上下文长度；
• 并发请求数；
• 框架的显存分配策略；
• 是否启用缓存复用；
• 是否加载视觉编码器或其他组件。

因此不能用“模型大小小于显存”作为唯一判断标准。模型权重占用20GB，不代表剩余60GB都可以用于 KV Cache，框架和临时张量还需要保留空间。

6.2 两张RTX 4090的通信开销必须可见

多卡测试至少要记录：

• 每张卡的显存占用；
• 每张卡的 GPU利用率；
• PCIe拓扑；
• 多卡并行方式；
• 单卡与多卡的吞吐增幅；
• 单请求延迟是否变长。

可使用以下效率计算：

多卡扩展效率 = 多卡吞吐 ÷（单卡吞吐 × 卡数量）

例如，单张 RTX 4090为80 tokens/s，两张卡为140 tokens/s，则扩展效率为：

140 ÷（80 × 2）= 87.5%

如果两张卡只有110 tokens/s，扩展效率则为68.75%。这说明通信、同步或模型切分带来的损耗较明显。

多卡扩展效率不是固定硬件属性，还会随模型层数、张量大小、batch、上下文长度和框架版本变化。小模型或低并发请求未必适合分布到两张卡上。

面向香港部署的生成式模型推理与图像处理业务，A5数据提供包含RTX 4090、A100 80GB显卡选项的GPU物理服务器，配套服务器CPU、内存与NVMe存储，为模型加载、数据预处理和推理服务运行提供硬件基础。香港GPU系列配有CN2线路资源，将GPU计算与接口访问所需的网络资源纳入同一部署方案，覆盖开发测试、在线推理等应用场景。

7. 价格比较要使用有效吞吐，而不是显卡小时价

香港 GPU服务器的价格会因计费周期、磁盘、带宽、实例类型、独享程度和交付方式变化。比较时不宜只看每小时租金，而应计算单位有效产出成本。

对于生成式模型，可以使用：

每小时输出 token数 = 每秒输出 token数 × 3600

每百万 token成本 = 每小时价格 × 1,000,000 ÷ 每小时输出 token数

示例只用于说明计算方法：

• A100价格按20港币/小时计算；
• 有效吞吐按100 tokens/s计算；
• 2×RTX 4090配置按22港币/小时计算；
• 有效吞吐按160 tokens/s计算。

则：

• A100每小时输出：100 × 3600 = 360,000 tokens；
• A100每百万 token成本：20 × 1,000,000 ÷ 360,000 ≈ 55.56港币；
• 2×RTX 4090每小时输出：160 × 3600 = 576,000 tokens；
• 2×RTX 4090每百万 token成本：22 × 1,000,000 ÷ 576,000 ≈ 38.19港币。

这组价格和吞吐是演示数据，不是当前报价。正式核算时，还应加入空闲时间、模型加载时间、重启时间、带宽费用、磁盘费用和异常重试成本。如果业务需要低延迟而不能持续满载，平均吞吐会下降，单位 token成本也会随之上升。

对于图像推理，可以将公式中的 token替换为图片数量；对于在线请求，则可以按每百万请求计算，但必须使用相同输入尺寸、相同后处理和相同并发条件。

8. 香港 GPU服务器的交付验收清单

8.1 RTX 4090配置的核对项

如果购买页面写的是 RTX 4090 48GB，应逐项确认：

• 实际是1张还是2张 RTX 4090；
• 每张卡的显存容量；
• 是否为标准 RTX 4090；
• 两张卡是否位于同一台主机；
• PCIe拓扑和插槽带宽；
• 是否允许多卡并行；
• 驱动是否支持目标框架；
• 功耗限制和散热条件；
• 是否存在宿主机共享或超售。

如果业务模型需要单卡超过24GB显存，应确认服务商是否支持模型并行，而不能只根据页面上的“48GB”判断。

8.2 A100 80GB配置的核对项

A100需要额外确认：

• PCIe还是SXM形态；
• 80GB显存是否为单卡容量；
• 是否启用MIG；
• 是否允许独占整卡；
• 是否存在功耗限制；
• 是否提供预期的高速互联；
• 驱动和CUDA版本；
• 是否与其他租户共享CPU、内存或PCIe资源。

如果启用了MIG，A100的显存和计算资源会被切分，测试结果不能与整卡独占模式直接比较。验收时应记录MIG状态和实际分配到的实例规格。

8.3 统一的验收记录

建议把以下信息保存到交付记录中：

9. 适用条件与不适用边界

在相同模型、相同精度、低并发且显存需求不高的情况下，RTX 4090可能提供较好的单请求响应和较低的使用成本。它更适合开发测试、短上下文推理、图像处理以及能够接受消费级 GPU 运维边界的场景。

A100 80GB更适合模型显存需求较高、上下文较长、并发较多或需要数据中心级资源管理的场景。它的价值不仅体现在某一次请求的速度，还体现在显存余量、持续负载、ECC、MIG支持和多租户管理能力等方面。具体能力仍需结合 PCIe或SXM版本以及服务商交付模式核对。

2×RTX 4090适合追求较高总吞吐、模型能够进行有效多卡切分的场景，但不适合把“48GB总显存”当作单卡连续显存使用。若模型并行效率低、请求规模小或业务强依赖单请求低延迟，多卡配置的收益可能不如预期。

最终选择应建立在三组数据上：单卡基线、多卡扩展结果和实际业务网络结果。只比较峰值 TFLOPS、页面标注显存或每小时价格，都不足以代表香港 GPU服务器上的真实推理效果。

复测时，应保持模型权重、推理框架、驱动、精度、输入输出长度和并发策略不变，只替换 GPU配置；如果更换了机房、实例宿主机、网络出口或测试时间，应在报告中单独标记。A100的 PCIe与SXM、RTX 4090的单卡与双卡，以及本机调用与外部接口调用，都应分别统计。由此得到的结论只能适用于对应的硬件形态、软件栈和负载范围，不能无条件外推到所有香港 GPU服务器实例。