PyTorch中`torch.tensor()`和`torch.Tensor()`有何区别？

Question

**常见技术问题：** 在PyTorch中，`torch.tensor()` 和 `torch.Tensor()` 看似功能相似，但存在关键差异：前者是推荐的**构造函数（factory function）**，会根据输入数据自动推断`dtype`和`device`，并默认不继承历史（`requires_grad=False`）；后者是`Tensor`类的**原始构造器**，行为更底层——若传入Python数值或列表，它会使用默认`dtype=torch.float32`且**忽略输入数据类型**（如`torch.tensor([1, 2])` → `int64`张量，而`torch.Tensor([1, 2])` → `float32`张量），易引发静默类型转换错误。此外，`torch.Tensor()` 不支持`dtype`/`device`等显式参数（需配合`.to()`链式调用），且在新版本中已明确标记为“不推荐用于用户代码”。实践中混用可能导致dtype不一致、GPU迁移失败或梯度追踪异常。何时该用哪个？为什么官方文档强调优先使用`torch.tensor()`？

Answer 1

```html

一、表层现象：语法相似性带来的误用惯性

初学者甚至部分资深工程师常将 torch.tensor() 与 torch.Tensor() 视为等价写法，仅因二者均能创建张量。但实测可见：

import torch
print(torch.tensor([1, 2]).dtype)     # torch.int64
print(torch.Tensor([1, 2]).dtype)      # torch.float32 ← 静默转换！
print(torch.tensor([1.0, 2.0]).dtype)  # torch.float32
print(torch.Tensor([1.0, 2.0]).dtype)  # torch.float32（看似一致，实则机制不同）

这种“看起来都行”的错觉，是大量 dtype 不匹配 bug 的源头。

二、中层机制：构造函数 vs 类构造器的本质差异

从 PyTorch 源码设计视角看：

• torch.tensor() 是工厂函数（factory function），封装了类型推断、设备感知、梯度控制等完整语义逻辑；
• torch.Tensor() 是底层 C++ Tensor 类的 Python 绑定构造器，直接映射至 ATen 库的 empty() + copy_() 流程，不进行任何输入类型校验或适配。

其行为差异可归纳为下表：

维度	torch.tensor()	torch.Tensor()
输入类型推断	✅ 自动识别 int/list/float/numpy → 保留原精度	❌ 强制转为 float32（标量/列表）或继承 numpy dtype（仅当传入 ndarray）
显式参数支持	✅ dtype, device, requires_grad, pin_memory	❌ 仅支持 shape 参数（如 torch.Tensor(2,3)），其余需链式调用
梯度追踪默认值	❌ requires_grad=False（安全默认）	❌ 同样为 False，但无显式控制入口

三、深层影响：静默错误如何演变为系统性风险

在大规模训练 pipeline 中，混用二者将引发级联失效：

1. 混合精度训练崩塌：torch.Tensor([1,2]) 生成 float32，与模型中定义的 torch.int64 索引张量运算时报错 Expected object of scalar type Long but got Float；
2. GPU 迁移失败：若先用 torch.Tensor([1,2]) 创建 CPU 张量，再调用 .cuda()，虽可执行，但因未指定 device，无法利用 torch.set_default_device("cuda") 全局策略；
3. 梯度图断裂：当误用 torch.Tensor() 构造中间变量参与计算图（如 loss = (x - torch.Tensor([1.0])).sum()），该节点因非 factory 创建且无 requires_grad=True 显式声明，导致反向传播时梯度无法回传至该常量。

四、工程实践：决策树与迁移路径

以下流程图描述何时选用何者：

graph TD
    A[创建张量？] --> B{输入来源}
    B -->|Python 标量/列表/元组| C[必须用 torch.tensor()]
    B -->|NumPy ndarray| D[推荐 torch.tensor(), 支持 dtype/device 透传]
    B -->|空张量/占位符| E[torch.empty(), torch.zeros() 等专用 factory]
    C --> F[可加 dtype=torch.int32, device='cuda', requires_grad=True]
    D --> G[自动继承 ndarray dtype，可覆盖]
    E --> H[语义清晰，性能最优]
    style C fill:#4CAF50,stroke:#388E3C,color:white
    style F fill:#2196F3,stroke:#1565C0,color:white

五、权威依据与演进脉络

PyTorch 官方自 v1.2 起在文档中明确标注：
“torch.Tensor is a legacy constructor and should not be used in new code. Use torch.tensor instead.”
该建议源于三大技术演进：

• 统一 API 设计哲学：所有 factory 函数（torch.zeros, torch.ones, torch.full）均遵循 tensor(..., dtype=..., device=...) 模式，torch.tensor 是该范式的基石；
• 分布式训练兼容性：torch.Tensor() 无法解析 torch.distributed._remote_device 等新设备抽象，而 torch.tensor(..., device="meta") 已原生支持；
• 编译器栈集成需求：TorchDynamo 和 Inductor 在 tracing 时对 torch.tensor() 做了深度优化，对 torch.Tensor() 则降级为不可追踪操作。

截至 PyTorch 2.4，torch.Tensor 构造器已从用户文档首页移除，仅保留在底层 C++ 接口说明中。

```