是什么
L2 · 主题中枢
计算硬件
算力不是堆卡，而是架构、软件栈与业务负载的精准匹配。
3核心硬件类型
4关键控制维度
2典型部署场景
先记住硬件选型由负载特征决定，而非参数规模
训练重吞吐与显存带宽，推理重延迟与能效；选错架构会导致算力浪费或性能瓶颈。
LIVE
CORE
计算硬件
为什么
通用 CPU 无法满足大模型高并发矩阵运算与低延迟推理需求，需专用硬件提供高吞吐、低功耗的并行计算能力。
怎么做
从明确业务负载类型（训练/推理/边缘）出发，选择匹配的硬件架构，配置驱动与框架栈，完成基准测试与部署。
什么时候
当模型参数量大、实时性要求高或能效比受限时必须使用；轻量任务或原型验证阶段可用云端 API 或 CPU 替代。
FOCUS
下属主题
FOCUS
先记住这些
为什么需要专用硬件
GPU/NPU 通过并行架构与专用算子实现 10-100 倍加速，但需承担驱动维护与部署复杂度。
真正难在哪里
版本碎片化、显存泄漏、多卡通信瓶颈与功耗墙限制，需系统化监控与调优。
什么时候用
当延迟/吞吐/成本指标无法通过软件优化或云服务满足时，才引入本地硬件。
ROUTE
学习路径
01
明确负载类型
区分训练、批量推理、实时推理或边缘部署，确定核心指标。
02
匹配硬件架构
根据指标选择 GPU、NPU 或 AI 芯片，评估生态兼容性。
03
搭建最小闭环
安装驱动、配置框架、运行基准测试，验证性能与稳定性。
PROBLEM / POSITION / INTERFACE
先弄清它为什么存在，以及谁在使用
-
01 解决的问题
模型训练耗时过长、推理延迟超标或云算力成本失控时触发硬件选型与优化需求。
缺乏对硬件架构与软件栈协同的理解，导致算力闲置、通信瓶颈或框架不兼容。
- 成功标准
- 在预算与功耗约束下，实现目标吞吐与延迟指标，且具备可观测的稳定性与扩展性。
-
02 AI 生态位
作为 AI 系统的底层执行引擎，承接框架调度指令，完成张量计算与数据搬运，向上支撑模型服务。
- 上游
- 依赖数据中心供电、散热、网络拓扑及操作系统与驱动支持。
- 下游
- 为深度学习框架、推理引擎与业务应用提供标准化算力接口。
-
03 人的生态位
工程师负责硬件选型、环境配置、性能调优与故障排查，不直接参与底层微架构设计。
- 适合使用
- 需本地部署大模型、追求低延迟推理、或长期算力成本高于云 API 时。
- 不必使用
- 业务处于验证期、负载轻量、或团队缺乏运维能力时，优先使用托管服务。
-
04 独特价值
专用架构（如 Tensor Core、NPU 矩阵单元）在特定算子下实现数量级加速，且能效比显著优于通用处理器。
软硬件协同调优困难，驱动/框架版本碎片化，多卡通信与显存管理易成瓶颈。
- 复杂度判断
- 复杂度不是功能数量，而是控制与验证成本。
INTERFACE FLOW
谁在操作，信息怎样流动
-
WHO OPERATES
HUMAN负责算力规划、硬件选型、环境部署、性能监控与成本优化
BACKEND负责驱动加载、任务调度、显存管理与硬件健康检查
-
INPUT
模型权重、输入张量、批处理配置与计算图指令
-
CONTROL
CUDA 版本、算子库、显存分配策略、功耗墙、多卡通信协议
-
OUTPUT
推理结果或训练梯度，以张量形式返回框架层，可能触发日志记录或自动扩缩容
FLOW
硬件部署与调优流程
01需求分析明确模型类型、延迟/吞吐目标、预算与功耗约束
02硬件选型根据负载匹配 GPU/NPU/AI 芯片，评估驱动与框架支持
03环境搭建安装驱动、CUDA/推理引擎、配置显存与网络
04基准测试运行标准负载，记录吞吐、延迟、显存占用与功耗
05生产部署集成监控、设置告警、配置自动扩缩容与故障转移
COMPARE
GPU vs NPU vs AI 芯片
| 维度 | GPU | NPU | AI 芯片 |
|---|---|---|---|
| 适用场景 | 训练/通用推理 | 边缘/低功耗推理 | 垂直场景优化 |
| 生态成熟度 | 高（CUDA/PyTorch） | 中（厂商 SDK） | 低（定制工具链） |
| 能效比 | 中 | 高 | 极高（特定负载） |
| 部署复杂度 | 中高 | 中 | 高 |
PRACTICE
最小可用部署清单
✓确认硬件型号与驱动版本兼容目标框架
✓安装 CUDA/cuDNN 或厂商推理引擎
✓配置显存分配策略与多卡通信协议
✓运行基准测试验证吞吐与延迟达标
✓部署监控采集 GPU 利用率、温度与功耗
CODE / PYTHONGPU 环境验证脚本
import torch
import os
def check_gpu_env():
if not torch.cuda.is_available():
print("CUDA 不可用，请检查驱动与版本")
return
device_count = torch.cuda.device_count()
print(f"可用 GPU 数量: {device_count}")
for i in range(device_count):
props = torch.cuda.get_device_properties(i)
print(f"GPU {i}: {props.name}, 显存: {props.total_memory / 1e9:.1f} GB")
# 测试张量计算
x = torch.randn(1000, 1000).cuda()
y = torch.matmul(x, x)
print("GPU 计算测试通过")
if __name__ == "__main__":
check_gpu_env()检查 CUDA 可用性与显存状态
JSON / RESPONSEGPU 环境验证返回结构
{
"cuda_available": true,
"device_count": 2,
"devices": [
{
"id": 0,
"name": "NVIDIA A100",
"total_memory_gb": 80.0
},
{
"id": 1,
"name": "NVIDIA A100",
"total_memory_gb": 80.0
}
],
"test_status": "passed"
}FAQ
常见问题
01谁在实际负责计算硬件的选型与运维？＋
算法工程师定义负载需求，基础设施工程师负责部署与监控，架构师做最终选型决策。
明确责任边界可避免性能问题无人兜底。02GPU 和 NPU 的核心区别是什么？＋
GPU 通用性强、生态成熟；NPU 专为神经网络优化，能效比高但生态封闭。
选错会导致开发成本飙升或性能不达标。03最小可用部署需要哪些步骤？＋
安装驱动→配置框架→运行基准测试→部署监控，形成闭环。
跳过任一环节都可能在生产环境暴露隐患。04生产环境最容易在哪里失败？＋
显存泄漏、驱动版本不兼容、多卡通信瓶颈或散热不足导致降频。
需提前配置监控与自动恢复机制。05什么时候不需要本地部署计算硬件？＋
业务处于验证期、负载轻量、或团队缺乏运维能力时，优先使用云 API。
避免过早投入重资产，保持灵活性。