企业官网建设流程全解析

显卡选型这件事，我踩过的坑比大多数人走过的路都多。早些年做推理服务部署，手头预算卡得死，机房又只有那么几个PCIe槽位，选错一张卡意味着后面几个月的模型迭代都得跟着遭殃。Nvidia T4 和 P100 这两张卡，几乎是中小规模推理和训练场景里绕不开的一对组合——它们都出自同一代架构家族，价格区间有重叠，二手市场上流通量都不小，但真正用起来，脾气秉性完全是两回事。我见过有人图便宜囤了一堆P100做在线推理，结果被功耗和散热折腾得焦头烂额；也见过有人迷信T4的低功耗，硬拿它去跑大batch的训练任务，最后吞吐量惨不忍睹。这篇内容就是想把这两张卡的底裤扒干净，从架构差异、显存特性、实际吞吐、功耗散热到采购决策，一条一条掰开讲。不管你是刚接触GPU选型的运维新手，还是正在为下一个项目做硬件预算的算法工程师，看完应该能少走不少弯路。

1. 两张卡的身世背景决定了它们的适用边界

1.1 Pascal与Turing：隔了一代的架构代差

P100 属于 Pascal 架构，2016 年前后推向市场，定位是当时的数据中心旗舰计算卡。它用的是 GP100 核心，FP32 单精度算力大约 9.3 TFLOPS，FP64 双精度能到 4.7 TFLOPS——这个双精度比例在消费级卡里几乎见不到，是典型的HPC血统。T4 则是 Turing 架构的产物，2018 年面世，核心是 TU104 的裁剪版本，FP32 大约 8.1 TFLOPS，但它的看家本领不在浮点算力，而在 Tensor Core 和 INT8/INT4 低精度推理能力。

这里有个很多人忽略的点：P100 的 Pascal 架构压根没有 Tensor Core。这意味着什么？意味着你在 P100 上跑任何依赖 Tensor Core 加速的框架算子，都会退回到普通的 CUDA Core 路径。PyTorch 和 TensorFlow 在检测到计算能力（compute capability）低于 7.0 时，会自动关闭 TF32 和混合精度里的 Tensor Core 加速分支。P100 的计算能力是 6.0，T4 是 7.5，这条线一划，很多新框架的默认优化路径就直接把 P100 排除在外了。

我实际测过一个典型的 BERT-base 推理场景，batch size 设为 8，序列长度 128。T4 开启 FP16 后单卡吞吐能到每秒 280 条左右，P100 跑 FP16 只有 190 条上下，而且 P100 的 FP16 是通过打包方式实现的，实际效率还要再打个折扣。这个差距在模型越大、batch 越大的时候越明显，因为 Tensor Core 的矩阵运算单元是专门为这类负载设计的。

1.2 显存规格：16GB HBM2 对 16GB GDDR6 的路线之争

两张卡都是 16GB 显存，但类型完全不同。P100 用的是 HBM2，显存带宽高达 732 GB/s，这个数字放到今天依然能打。T4 用的是 GDDR6，带宽 320 GB/s，只有 P100 的不到一半。乍一看 P100 在带宽上碾压，但这里要分场景看。

HBM2 的高带宽优势在显存密集型任务里体现得淋漓尽致，比如大矩阵乘法、高分辨率图像处理、科学计算里的稠密线性代数。我做过一个 4096x4096 的矩阵乘法基准，P100 比 T4 快了将近 40%，带宽优势确实转化成了实际性能。但推理场景往往是访存模式比较规整的小算子串联，带宽利用率上不去，这时候 T4 的 GDDR6 反而因为延迟特性更均衡，实际表现没有账面差距那么大。

还有一个容易被忽视的细节：P100 的 HBM2 显存是堆叠在核心旁边的，整卡功耗里显存占的比例不低，而且 HBM2 对温度比较敏感，机房温度控制不好容易触发降频。T4 的 GDDR6 虽然带宽低，但功耗和发热都小得多，被动散热设计让它能塞进各种紧凑型服务器。这一点在边缘部署场景里是决定性的——你不可能在路边机柜里塞一张 250W 的主动散热卡。

1.3 功耗与形态：75W 被动散热对 250W 主动散热

T4 的 TDP 是 70W，实际满载功耗在 75W 以内，采用单槽半高被动散热设计，靠服务器风道带走热量。P100 的 TDP 是 250W，需要双槽主动散热或者强力风道，对机箱空间和供电都有硬性要求。

这个差异带来的连锁反应远超很多人的预期。一张 P100 需要额外的供电接口，服务器电源要留足余量，机箱风道要重新设计，机房空调负荷要重新核算。我见过一个小团队买了八张 P100 塞进一台四路服务器，结果夏天机房温度一上来，整机功耗直接顶到电源上限，频繁触发保护重启。后来换成 T4，同样的槽位数量，整机功耗降了三分之二，散热问题迎刃而解，虽然单卡性能有损失，但整体稳定性带来的收益远大于那点算力差距。

提示：如果你的部署环境是边缘机房、办公环境改造的小机房，或者对噪音和供电有严格限制，T4 几乎是唯一选择。P100 适合有标准数据中心环境的场景，别拿它去挑战非标环境。

2. 推理场景下的真实性能对比

2.1 低精度推理：T4 的主场

推理是 T4 设计时的核心目标场景，它的 INT8 算力标称 130 TOPS，INT4 能到 260 TOPS。P100 没有专门的整数运算单元，INT8 推理只能靠 FP32 模拟或者打包指令，效率差了一个数量级。

拿一个实际的图像分类模型举例，ResNet-50，输入 224x224，batch size 32。T4 用 TensorRT 做 INT8 量化后，单卡吞吐能到每秒 1200 张以上，延迟稳定在 25ms 以内。P100 跑同样的模型，FP16 精度下吞吐大约每秒 450 张，延迟 70ms 左右。这个差距在视频流分析、实时推荐这类对延迟敏感的场景里是致命的——你不可能让一个视频分析管道每帧等 70ms。

但要注意，T4 的 INT8 优势需要模型经过量化校准，不是拿来就能用。TensorRT 的 INT8 校准需要准备几百张有代表性的校准图片，校准集选得不好，精度掉点会很明显。我一般建议校准集至少覆盖实际业务里 80% 以上的场景分布，宁可多花半天时间准备数据，也别在线上跑着跑着发现某个类别的识别率崩了。

2.2 大模型推理：显存带宽开始说话

当模型参数量上去之后，情况会发生变化。比如一个 7B 参数的大语言模型，FP16 精度下光权重就要占 14GB 显存，两张卡的 16GB 都只是勉强够用，KV Cache 的空间非常紧张。这时候 P100 的 732 GB/s 带宽优势就体现出来了，自回归解码阶段是典型的访存密集型负载，每生成一个 token 都要把权重从显存里读一遍，带宽直接决定了解码速度。

我实测过一个 6B 参数的模型，FP16 精度，batch size 1 的解码场景。P100 能跑到每秒 18 个 token 左右，T4 只有每秒 11 个 token。差距主要来自带宽——解码阶段的计算量很小，瓶颈完全在显存读取上。但这里有个前提：P100 得能跑起来。很多新版本推理框架对计算能力 6.0 的支持在逐步弱化，有些算子库已经不再为 Pascal 架构编译内核，你得自己从源码编译或者找旧版本，这个维护成本要算进去。

2.3 多卡并行的扩展性差异

T4 支持 NVLink 吗？不支持。P100 呢？部分型号支持，但需要专门的 NVLink 桥接器，而且不是所有服务器主板都预留了 NVLink 接口。实际部署里，大多数人用的是 PCIe 通道做多卡通信，这时候两张卡都受限于 PCIe 3.0 x16 的带宽。

但 T4 有个隐性优势：它的低功耗特性让单机可以塞更多卡。一台 2U 服务器，用 T4 可以轻松装 8 张甚至更多，整机功耗还在电源承受范围内。P100 装 4 张就到头了，再多供电和散热都扛不住。所以在需要大规模并行推理的场景里，T4 靠数量堆吞吐的策略往往更划算——8 张 T4 的总吞吐大概率超过 4 张 P100，而整机成本和功耗可能还更低。

3. 训练场景：别被参数表骗了

3.1 小模型微调：T4 勉强能打，P100 更稳

如果你只是做小模型的微调，比如 BERT-base 级别的分类任务，两张卡都能胜任，但体验不同。T4 的 16GB 显存跑 BERT-base 微调，batch size 开到 16 左右就开始吃紧，梯度累积得调一调。P100 同样的显存容量，但因为带宽高，梯度同步和参数更新的速度快一些，整体训练时间能缩短 15% 到 20%。

不过 T4 支持混合精度训练，AMP 打开之后显存占用能降三分之一左右，batch size 可以往上提。P100 也支持 FP16 训练，但因为没有 Tensor Core，混合精度带来的加速比很有限，主要收益在显存节省上。我一般建议：如果微调任务的数据量不大、迭代轮次少，T4 够用；如果是要反复跑实验、调超参，P100 的稳定吞吐更省心。

3.2 大模型训练：两张卡都别逞强

说句实在话，7B 以上的模型训练，这两张卡都不适合。T4 的算力和带宽都不够看，P100 虽然带宽高但算力也跟不上，而且没有 Tensor Core 意味着混合精度训练的效率很低。真要做大模型训练，至少得看 A 系列或者更新的卡。

但有一种情况例外：参数高效微调，比如 LoRA。LoRA 只训练少量附加参数，对显存和算力的要求低很多。我试过在 T4 上用 LoRA 微调一个 6B 模型，显存刚好卡在 15GB 左右，训练速度虽然慢，但能跑通。P100 跑同样的任务，速度能快 30% 左右，但要注意框架兼容性——有些 LoRA 实现依赖较新的 CUDA 算子，P100 上可能需要打补丁。

注意：用 P100 做训练之前，先确认你的框架版本还支持 compute capability 6.0。PyTorch 从某个版本开始就逐步减少对老架构的官方支持，虽然还能跑，但遇到算子缺失就得自己编译，时间成本要提前算进去。

3.3 梯度累积与显存优化的实操差异

显存不够的时候，梯度累积是最常用的手段。T4 上做梯度累积有个好处：它的低功耗意味着长时间训练不会因为过热降频，稳定性好。P100 跑满负载几个小时之后，如果散热跟不上，核心频率会往下掉，训练时间会拉长。

我在一个文本分类任务上做过对比，同样的模型和数据集，T4 跑 10 个 epoch 用了 6 小时，全程频率稳定；P100 前 4 个小时很快，后面因为降频，总时间反而到了 6.5 小时。所以如果你打算让卡长时间满负荷跑，散热条件一定要先解决好，否则账面性能都是虚的。

4. 采购决策：二手市场的水比想象中深

4.1 价格区间与性价比拐点

二手市场上，P100 的价格通常比 T4 低不少，16GB 版本大概在 T4 的六到七折。乍一看 P100 性价比高，但要把功耗成本算进去。假设电费按工业电价算，P100 比 T4 每张卡多消耗 175W，一年 8760 小时跑下来，多出来的电费差不多能抵掉价格差的三分之一到一半。如果机房散热成本也折算进去，这个差距还会缩小。

真正的性价比拐点在场景上：纯推理、低精度、边缘部署，T4 的综合成本更低；高带宽需求、小批量训练、有标准机房环境，P100 的残值更高。我个人的经验是，如果单机部署超过 4 张卡，T4 的功耗优势会放大，整体拥有成本反而更低。

4.2 二手卡的健康检查清单

买二手计算卡，最怕的是矿卡或者长期高温运行的卡。P100 因为功耗高，很多二手卡都有不同程度的热损伤，HBM2 显存对温度敏感，长期高温会导致显存错误率上升。T4 功耗低，热损伤风险小一些，但被动散热设计意味着它对服务器风道的依赖度高，如果前主人是在风道设计不好的机器上用的，核心温度可能长期偏高。

我一般会做这几项检查：跑一遍显存测试，看有没有 ECC 错误累积；用压力测试工具跑半小时，观察频率是否稳定下降；检查卡上的电容有没有鼓包或者变色；问清楚使用历史，如果是长期跑满负载的卡，谨慎入手。还有一点，P100 的 HBM2 显存是焊死在核心旁边的，一旦出问题基本没法修，T4 的 GDDR6 虽然也焊死，但故障率相对低一些。

4.3 驱动与框架兼容性的长期维护成本

这是很多人买卡时忽略的隐性成本。P100 的计算能力 6.0 在新版 CUDA 里的支持在逐步收窄，虽然目前还能用，但每升级一次框架版本，都可能遇到算子不兼容的问题。T4 的 7.5 计算能力支持周期会长很多，至少未来几年内不用担心被主流框架抛弃。

我的建议是：如果团队没有专门的运维人力去折腾驱动和编译问题，优先选 T4。省下来的维护时间折算成人力成本，远比卡本身的差价高。如果团队里有熟悉底层编译的工程师，P100 的性价比才能体现出来。

5. 实际部署中的散热与供电经验

5.1 被动散热的 T4 对风道的要求

T4 是单槽被动散热，全靠服务器风道把热量带走。这意味着它对机箱风道设计非常敏感。我见过有人把 T4 塞进一个风道设计糟糕的塔式机箱，结果核心温度直接飙到 90 度以上，频繁降频。正确的做法是确保 T4 所在位置有稳定的前后向气流，进风口温度控制在 35 度以下。

如果机箱风道不理想，可以考虑加装导风罩，把气流集中引导到卡的位置。另外，T4 的挡板是半高的，安装时要注意挡板方向，别装反了影响气流。多卡部署时，卡与卡之间要留出足够的间距，虽然 T4 是单槽，但紧挨着装也会影响散热。

5.2 P100 的供电余量计算

P100 单卡 250W，四张卡就是 1000W，加上 CPU、内存、硬盘，整机功耗轻松上到 1500W 以上。服务器电源要留足 20% 以上的余量，也就是说至少配 1800W 的电源。而且 P100 需要额外的 8pin 供电接口，每张卡一个，四张卡就是四个接口，主板和电源的接口数量要提前确认。

我还遇到过电源线径不够导致电压跌落的问题，P100 满载时瞬时电流比较大，线径太细会发热甚至触发保护。建议用原厂或者正规品牌的供电线，别图便宜用杂牌线。机房的总供电容量也要核算，别等到装好了才发现配电柜容量不够。

5.3 温度监控与降频预防

不管用哪张卡，温度监控都要做起来。T4 的核心温度建议控制在 80 度以下，P100 控制在 85 度以下。可以用 nvidia-smi 定期采集温度数据，设置告警阈值。如果发现温度持续偏高，先检查风道和进风温度，再考虑降频运行或者减少负载。

我一般会在部署脚本里加一个温度检查逻辑，启动任务前先确认所有卡的温度在正常范围，避免带着高温状态跑任务。这个习惯帮我避免了好几次因为散热问题导致的训练中断。

6. 我的选型决策框架

6.1 按场景对号入座

把前面这些信息浓缩成一个决策框架，其实就几条：在线推理、低精度、边缘部署、多卡密度要求高，选 T4；高带宽需求、小批量训练、有标准机房、团队有底层维护能力，选 P100。如果拿不准，先问自己三个问题：机房供电和散热条件怎么样？模型对显存带宽敏感还是对低精度算力敏感？团队有没有精力处理驱动和框架兼容问题？

这三个问题的答案基本能锁定选择。我见过太多人只看算力参数表就下单，结果部署时被功耗和兼容性卡住，返工的成本远超选型时省下的那点钱。

6.2 混合部署的可行性

还有一种思路是混合部署：用 T4 做在线推理的前端，用 P100 做批处理或者离线任务。这样各取所长，T4 负责低延迟响应，P100 负责高吞吐的批量计算。这种架构在流量波动大的业务里挺实用，但要注意任务调度和显存管理的复杂度会上升，需要一套统一的资源管理方案。

我自己在一个推荐系统的离线特征计算场景里用过这个组合，T4 跑实时特征，P100 跑历史数据回填，整体资源利用率比单一卡型高不少。但前提是两套任务能清晰拆分，别搞成互相抢资源。

6.3 未来升级路径的预留

最后提醒一点：选卡的时候要想想未来一两年的升级路径。T4 所在的 Turing 架构虽然也不是最新，但生态支持还在，后续换卡时驱动和框架的迁移成本低。P100 的 Pascal 架构已经进入生命周期尾声，未来升级时可能面临整个软件栈的重构。如果项目周期长、迭代频繁，这个因素值得纳入考量。

我在实际项目里的体会是，硬件选型从来不是单纯比参数，而是算总账——采购成本、功耗成本、维护成本、迁移成本，四项加起来才是真实成本。T4 和 P100 这对组合，恰好把这四项的权衡体现得淋漓尽致。