1. 从“裸奔”到“封装”为什么我们需要一个张量系统干了十年C后端中间GAP了六个月这事儿听起来挺吓人的技术迭代这么快半年时间感觉能错过一个时代。但换个角度看这半年也是难得的“抽离期”让你能从日常的CRUD和业务逻辑里跳出来重新审视一些更底层、更本质的东西。我这次复出的第一个大活儿就是动手写了一个接近三万行代码的LLM推理框架我管它叫TFFInfer。今天不聊框架全貌就聚焦在其中一个最基础、也最容易被轻视的模块上Tensor张量系统与内存抽象。很多刚入行的朋友甚至一些有经验的开发者在接触深度学习框架时往往把注意力放在模型结构、训练算法或者性能优化上。Tensor不就是个多维数组嘛float* data加一个std::vectorint shape不就搞定了我刚开始也这么想。但当你真正要构建一个稳定、高效、且要支持各种硬件后端CPU、GPU、甚至未来可能的NPU的推理框架时你会发现一个设计粗糙的Tensor实现会成为整个系统最大的性能瓶颈和稳定性噩梦。想象一下这个场景你的框架需要同时处理来自不同来源的Tensor——可能是从文件加载的模型权重可能是用户输入的预处理数据也可能是中间层计算产生的临时结果。这些Tensor的生命周期、内存布局、设备位置Host内存还是Device显存千差万别。如果没有一个统一的抽象层来管理你的代码很快就会充斥着if (tensor_on_gpu) { cudaMemcpy(...); } else { ... }这样的条件分支内存泄漏、非法访问、性能低下等问题接踵而至。这就像让你用汇编语言去管理一个现代操作系统的内存不是不能做是做得又累又容易出错。所以在TFFInfer里我把Tensor系统放在了架构的核心位置。它不仅仅是一个数据容器更是一套完整的内存与计算资源的管理抽象。今天这篇上我们就先掰开揉碎了讲清楚一个工业级的C Tensor系统到底需要解决哪些问题以及我是如何设计它的基础架构的。这部分的代码量占了整个框架相当大的一块但每一行都是为了解决实际痛点而写的。2. Tensor的核心设计哲学所有权、生命周期与数据视图设计一个Tensor类第一个要回答的问题就是谁拥有数据这个问题直接决定了内存管理的复杂度。常见的做法有几种独占所有权Tensor内部持有一个std::vector或unique_ptr拷贝Tensor就是深拷贝数据。简单安全但频繁拷贝大Tensor时性能是灾难。共享所有权使用std::shared_ptr管理数据块拷贝Tensor只是增加引用计数。避免了不必要的拷贝但引入了循环引用的风险且对非托管内存如CUDA显存不友好。视图ViewTensor不拥有数据只保存一个指向外部内存的指针和元数据。极其轻量但要求使用者必须手动保证外部内存的生命周期长于Tensor视图容易造成悬垂指针。在TFFInfer中我选择了一种混合策略其核心是明确区分“存储”和“视图”。我定义了一个TensorStorage类它是数据内存的真正所有者。这个类内部使用一个std::shared_ptrvoid来指向原始内存块并配套记录该内存块的字节大小、设备类型CPU/GPU、内存分配器等信息。TensorStorage负责内存的分配与释放通过RAII机制以及在不同设备间的拷贝。而Tensor类本身则主要是一个“视图”。它包含一个指向TensorStorage的std::shared_ptr共享所有权。元数据形状shape、步长stride、数据类型dtype、设备信息。一个偏移量offset用于支持切片slice操作。class Tensor { public: // ... 构造函数、析构函数、运算符重载 ... private: std::shared_ptrTensorStorage storage_; // 共享所有权的存储 Shape shape_; // 形状如 {batch, seq_len, hidden} Stride stride_; // 步长用于计算元素索引 DataType dtype_; // 数据类型如 float32, int64 Device device_; // 设备如 CPU:0, CUDA:0 size_t offset_ 0; // 在存储中的字节偏移 };这样设计的好处是什么高效的切片操作当我们需要取一个Tensor的某一行或某一列时不需要拷贝数据只需要创建一个新的Tensor对象其storage_指向同一个TensorStorage然后调整shape_、stride_和offset_即可。这个过程是O(1)的极其高效。// 假设 tensor 形状为 [N, C, H, W] Tensor channel_slice tensor.slice(1, 3); // 取第1个通道 // channel_slice 与 tensor 共享底层数据只是视图不同。清晰的生命周期管理只要还有一个Tensor视图存在底层的TensorStorage就不会被释放。当所有视图都被销毁后内存自动回收。这完美解决了视图模式下的悬垂指针问题。支持高级布局通过stride_我们可以轻松表达非连续内存布局如转置后的矩阵而无需实际移动数据。这对某些计算内核的优化至关重要。一个踩坑经验早期版本我曾尝试用std::shared_ptrvoid直接放在Tensor里但很快发现无法优雅地处理切片。因为切片需要共享数据但拥有独立的元数据如果每个Tensor都自己持有一个shared_ptr那么对元数据的修改如reshape会影响到所有切片这是不对的。将Storage独立出来是解决这个问题的关键。3. 内存分配器抽象统一CPU与GPU的内存接口在异构计算环境中内存来源五花八门。CPU有标准的malloc/newGPU有cudaMalloc还有可能用到内存池、 pinned memory页锁定内存等。如果Tensor内部写死了分配方式框架的扩展性将大打折扣。因此我引入了一个Allocator抽象基类。它的接口非常简单class Allocator { public: virtual ~Allocator() default; // 分配 aligned_size 字节的内存 virtual void* allocate(size_t aligned_size) 0; // 释放内存 virtual void deallocate(void* ptr) 0; // 返回分配器所属设备 virtual Device device() const 0; };然后我为不同的内存类型实现了具体的分配器CPUAllocator: 使用std::aligned_alloc或_aligned_malloc(Windows)。CUDAAllocator: 使用cudaMalloc和cudaFree。CUDAPinnedAllocator: 使用cudaMallocHost分配页锁定内存用于主机-设备间高速拷贝。TensorStorage在构造函数中接受一个Allocator*参数。当需要分配内存时就调用这个分配器的allocate方法。TensorStorage::TensorStorage(size_t bytes, const Allocator* allocator) : allocator_(allocator), device_(allocator-device()) { if (bytes 0) { data_ptr_ allocator_-allocate(bytes); capacity_ bytes; } }这样做带来了巨大的灵活性内存池集成我可以轻松实现一个MemoryPoolAllocator内部维护一个空闲内存块列表用于频繁分配释放的小Tensor显著减少系统调用和内存碎片。这在处理LLM推理中大量的小规模临时Tensor时效果显著。测试与模拟在单元测试中我可以实现一个MockAllocator记录所有的分配和释放操作用于检测内存泄漏。支持新硬件未来如果要支持AMD GPU或Intel XPU我只需要实现对应的XPUAllocator即可Tensor系统的其他部分完全不用改动。关于分配器的一个实践细节谁来管理分配器的生命周期全局静态分配器虽然简单但不够灵活比如无法为不同线程配置不同的内存池。在TFFInfer中我采用了一个AllocatorRegistry单例来注册和获取不同设备类型的默认分配器。同时允许在创建Tensor时显式传入一个分配器实例用于特殊场景。这平衡了便利性和灵活性。// 获取默认的CUDA分配器 Allocator* cuda_alloc GetAllocatorRegistry()-GetAllocator(DeviceType::CUDA, 0); // 使用特定分配器创建Tensor Tensor weight(shape, dtype, my_custom_allocator);4. 形状、步长与数据类型的系统化设计Tensor的元信息形状、步长、数据类型看似简单但设计不好会让后续的计算和序列化处处碰壁。4.1 形状与步长从连续存储到任意视图形状Shape我直接用std::vectorint64_t表示这没什么好说的。关键是步长Stride。步长定义了在每个维度上移动一个元素内存地址需要跳过的字节数。对于一个连续存储C-order即行优先的Tensor其步长可以自动从形状计算出来shape [d0, d1, d2, ..., dn-1] stride_n-1 sizeof(dtype) stride_i stride_i1 * shape_i1例如一个float类型、形状为[2, 3, 4]的连续Tensor其步长为[12, 4, 1]每个数字乘以sizeof(float)4就是字节步长。但在以下情况步长就不是连续的了切片操作tensor[0:2, :, 1:3]会产生一个非连续视图。转置操作tensor.transpose(0, 1)交换了维度也改变了步长。广播操作广播后的Tensor被广播的维度其步长为0。因此Tensor类必须独立存储shape_和stride_。任何改变视图的操作slice,transpose,reshape,broadcast_to本质上都是在操作这两个成员变量而不是数据本身。我实现了一个compute_contiguous_strides辅助函数和一个is_contiguous方法。很多优化过的计算内核如GEMM要求输入Tensor是连续的如果不是就需要一个显式的contiguous()调用它会触发数据拷贝返回一个连续的新Tensor。bool Tensor::is_contiguous() const { int64_t expected_stride 1; for (int i ndim() - 1; i 0; --i) { if (stride_[i] ! expected_stride) { return false; } expected_stride * shape_[i]; } return true; } Tensor Tensor::contiguous() const { if (is_contiguous()) { return *this; // 返回一个共享数据的副本视图 } // 非连续需要分配新内存并拷贝数据 Tensor new_tensor(shape_, dtype_, device_); // ... 调用拷贝内核 ... return new_tensor; }4.2 数据类型不只是float和intLLM推理中会遇到各种各样的数据类型模型权重可能是float32(FP32) 或bfloat16(BF16)量化后的权重可能是int8(INT8) 或int4(INT4)token id是int64注意力掩码是bool。我设计了一个DataType枚举类并配套了一系列工具函数enum class DataType { kFloat32, kFloat16, // 半精度浮点 kBFloat16, kInt64, kInt32, kInt16, kInt8, kUInt8, kBool, // ... 未来可以扩展 }; // 获取数据类型大小 size_t GetDataTypeSize(DataType dtype); // 获取数据类型的字符串名称 const char* GetDataTypeName(DataType dtype); // 判断是否为浮点类型 bool IsFloatingType(DataType dtype);在Tensor的序列化、网络传输、以及不同数据类型间的计算如类型提升时这些工具函数必不可少。例如实现一个cast操作时就需要根据源类型和目标类型分配合适的计算内核。一个容易忽略的坑字节序。虽然现代服务器基本都是小端序但如果你设计的框架某天需要从大端序的机器加载模型或者进行网络传输数据类型序列化时就必须考虑字节序转换。我在序列化模块中预留了相关的处理接口默认按小端序处理但可以通过编译选项或运行时配置来支持大端序。5. 设备抽象与跨设备数据搬运“张量在哪”和“张量是什么”同样重要。在TFFInfer中我用一个简单的Device结构体来标识struct Device { DeviceType type; // CPU, CUDA, ROCm, ... int index; // 设备索引如 0, 1 // 比较运算符重载用于作为map的key bool operator(const Device other) const { ... } };Tensor对象保存了其所在的Device。任何试图在不同设备间进行直接运算的操作都会在框架内部被拦截并返回一个清晰的错误或者触发隐式的数据拷贝。跨设备拷贝是性能敏感操作。我实现了一个统一的Copy函数它根据源设备和目标设备的类型分派到不同的实现void Copy(const Tensor src, Tensor dst) { if (src.device() dst.device()) { // 同设备拷贝调用memcpy或cudaMemcpy同步 internal_copy_on_device(src, dst); } else if (src.device().type DeviceType::CPU dst.device().type DeviceType::CUDA) { // Host - Device cudaMemcpy(dst.data_ptr(), src.data_ptr(), src.nbytes(), cudaMemcpyHostToDevice); } else if (src.device().type DeviceType::CUDA dst.device().type DeviceType::CPU) { // Device - Host cudaMemcpy(dst.data_ptr(), src.data_ptr(), src.nbytes(), cudaMemcpyDeviceToHost); } else { // 其他情况如CUDA-CUDA不同卡未来可能支持D2D DMA // ... } }这里有一个重要的优化点异步拷贝与流管理。上面的cudaMemcpy是同步的会阻塞CPU线程。在高性能推理中我们希望能将数据拷贝与计算重叠。因此我进一步引入了Stream的概念。每个设备特别是GPU可以关联多个计算流。Copy函数可以接受一个可选的Stream参数使用cudaMemcpyAsync进行异步拷贝。class Stream { public: Device device() const; cudaStream_t cuda_stream() const; // 如果是CUDA设备 void synchronize() const; // 等待流中所有操作完成 }; void Copy(const Tensor src, Tensor dst, const Stream stream);这样用户就可以在一个流上进行计算同时在另一个流上准备下一批数据实现流水线并行最大化硬件利用率。关于设备抽象的思考一开始我考虑过像PyTorch那样设计一个更复杂的Device类包含内存分配、流创建等能力。但后来我发现这会让Tensor与Device的耦合过紧。现在的设计更清晰Allocator管内存Stream管异步操作Device只是一个轻量的标识符。这种职责分离让系统更容易维护和扩展。6. 序列化与持久化让Tensor“可存可取”一个推理框架必然要加载预训练好的模型。模型文件本质上就是一系列具有特定形状、数据类型和值的Tensor的集合。因此Tensor系统的序列化能力至关重要。我设计了一个简单的二进制格式。每个Tensor的存储包括一个文件头和数据体。文件头是一个固定大小的结构体或按需扩展包含魔术字用于识别文件格式。版本号用于兼容性处理。Tensor元数据维度、形状数组、数据类型、设备类型通常序列化到文件时是CPU内存。数据体字节大小。数据体就是Tensor内存的原始字节。序列化过程大致如下void Tensor::serialize_to_file(const std::string path) const { // 1. 确保Tensor在CPU上如果是GPU上的先拷贝回CPU。 Tensor cpu_tensor this-to(DeviceType::CPU).contiguous(); // 2. 准备文件头 FileHeader header; header.magic kTensorFileMagic; header.version kCurrentVersion; header.ndim cpu_tensor.ndim(); header.dtype static_castuint32_t(cpu_tensor.dtype()); // ... 填充其他字段 std::vectorint64_t shape_data cpu_tensor.shape().vectorize(); size_t data_size cpu_tensor.nbytes(); // 3. 写入文件 std::ofstream ofs(path, std::ios::binary); ofs.write(reinterpret_castconst char*(header), sizeof(header)); ofs.write(reinterpret_castconst char*(shape_data.data()), header.ndim * sizeof(int64_t)); ofs.write(reinterpret_castconst char*(cpu_tensor.data_ptr()), data_size); }反序列化则是逆过程需要根据头信息创建对应形状和类型的Tensor然后读入数据。遇到的挑战与解决方案大文件支持模型权重可能高达数十GB。不能一次性读入内存。我实现了内存映射和分块加载两种机制。对于支持内存映射的系统在反序列化时只映射文件头Tensor的数据指针直接指向文件映射区域实现“零拷贝”加载。对于不支持或不需要内存映射的情况可以指定只加载Tensor的某一部分例如仅加载LoRA适配器的权重。兼容性与版本控制框架迭代后Tensor的存储格式可能会变。version字段就派上用场了。反序列化时根据版本号调用不同的解析逻辑或者提供升级工具。安全性与校验二进制文件容易损坏。除了魔术字校验我还增加了简单的CRC校验码放在文件尾部加载时会进行验证防止加载到错误数据导致程序崩溃。这套序列化系统不仅用于加载模型还可以用于中间结果的调试转储。当推理出现NaN或异常值时我可以方便地将中间层的Tensor输出到文件用外部工具进行分析这对于调试复杂的模型计算图非常有帮助。7. 零拷贝与内存共享极致性能的追求在推理服务中尤其是高并发场景内存拷贝常常是主要的性能开销之一。TFFInfer的Tensor系统在设计之初就考虑了多种零拷贝或内存共享的场景。7.1 从外部数据直接构造Tensor视图很多时候数据已经存在于某个内存块中比如从网络接收到的字节流或者从其他库如OpenCV中获取的图像数据。为了避免不必要的拷贝我提供了从外部指针创建Tensor视图的构造函数。// 从已有的CPU内存创建Tensor视图不接管所有权。 Tensor Tensor::from_external_data(void* data_ptr, const Shape shape, DataType dtype, const Allocator* allocator nullptr /*通常为nullptr*/) { Tensor tensor; // 创建一个“空”的Storage但将其数据指针指向外部数据。 // 需要设置一个自定义的Deleter确保不释放外部内存。 tensor.storage_ std::make_sharedTensorStorage(/* size */ shape.numel() * GetDataTypeSize(dtype), allocator); tensor.storage_-set_external_data(data_ptr); // 内部标记为外部数据析构时不释放。 tensor.shape_ shape; tensor.stride_ compute_contiguous_strides(shape); // ... 设置其他元数据 return tensor; }使用这个功能需要非常小心你必须保证在Tensor使用期间外部内存一直有效。这通常用于数据预处理到模型输入这个管道中实现零拷贝的数据传递。7.2 进程间共享内存在多进程部署的推理服务中数据预处理进程和模型推理进程可能分离。为了减少进程间通信IPC的开销可以使用共享内存。我设计了一个SharedMemoryAllocator它内部使用shm_open和mmapLinux或CreateFileMappingWindows来分配共享内存。// 进程A创建共享Tensor并写入数据 auto shm_alloc std::make_sharedSharedMemoryAllocator(/my_shm, 1024*1024); Tensor shared_tensor({1024}, DataType::kFloat32, shm_alloc.get()); // ... 填充数据 ... // 进程B通过相同的名字打开共享内存并创建Tensor视图 auto shm_alloc_b std::make_sharedSharedMemoryAllocator(/my_shm, 1024*1024); Tensor tensor_view Tensor::from_external_data(shm_alloc_b-get_base_ptr(), Shape{1024}, DataType::kFloat32); // tensor_view 直接访问进程A写入的数据。7.3 与CUDA的零拷贝内存/统一内存集成对于GPU计算CUDA提供了零拷贝内存和统一内存技术。零拷贝内存允许GPU直接访问锁页的CPU内存省去显式拷贝但访问速度较慢。统一内存则提供一个统一地址空间由驱动在CPU和GPU间按需迁移数据。在TFFInfer中可以通过实现特定的Allocator来支持这些特性。例如一个CUDAPinnedAllocator分配的内存可以直接用于cudaMemcpyAsync实现高效拷贝而一个CUDAManagedAllocator则分配统一内存。// 使用统一内存分配器 auto um_alloc GetAllocatorRegistry()-GetAllocator(DeviceType::CUDA_MANAGED, 0); Tensor um_tensor({1000, 1000}, DataType::kFloat32, um_alloc); // 这个Tensor既可以被CPU内核访问也可以被GPU内核访问数据迁移对用户透明。选择哪种内存共享策略取决于具体的硬件、数据访问模式和对性能的要求。TFFInfer的抽象层让用户可以灵活选择而不是被框架锁死。8. 调试、性能剖析与内存分析工具集成一个健壮的系统离不开良好的可观测性。对于Tensor系统我内置了几种调试和分析工具。8.1 格式化打印与可视化我重载了Tensor的流输出运算符可以打印出形状、数据类型、设备以及前几个和最后几个元素的值。这对于快速调试非常有用。std::cout tensor std::endl; // 输出可能类似 // Tensor(shape[2, 3], dtypefloat32, deviceCPU) // [[1.0, 2.0, 3.0], // [4.0, 5.0, 6.0]]对于大Tensor还实现了摘要模式只打印统计信息如最小值、最大值、均值、是否存在NaN/Inf。8.2 内存使用统计与泄漏检测通过自定义的Allocator可以很容易地加入内存统计功能。我实现了一个DebugAllocator它包装了另一个真实的分配器并记录所有分配和释放请求的大小、地址和调用栈。class DebugAllocator : public Allocator { public: DebugAllocator(Allocator* underlying_allocator) : underlying_(underlying_allocator) {} void* allocate(size_t size) override { void* ptr underlying_-allocate(size); std::lock_guardstd::mutex lock(mutex_); allocations_[ptr] {size, capture_stack_trace()}; // 记录分配 total_allocated_ size; peak_allocated_ std::max(peak_allocated_, total_allocated_); return ptr; } void deallocate(void* ptr) override { std::lock_guardstd::mutex lock(mutex_); auto it allocations_.find(ptr); if (it ! allocations_.end()) { total_allocated_ - it-second.size; allocations_.erase(it); } underlying_-deallocate(ptr); } void report_leaks() const { // 程序退出时如果allocations_不为空则打印泄漏信息。 for (const auto [ptr, info] : allocations_) { std::cerr Memory leak: info.size bytes at ptr std::endl; print_stack_trace(info.stack_trace); } } private: Allocator* underlying_; std::unordered_mapvoid*, AllocationInfo allocations_; size_t total_allocated_ 0; size_t peak_allocated_ 0; mutable std::mutex mutex_; };在开发阶段将默认分配器替换为DebugAllocator就可以在程序退出时自动报告内存泄漏并定位到泄漏发生的位置。8.3 与性能剖析器联动为了分析Tensor操作如拷贝、重塑的性能我在关键函数的入口和出口插入了高精度计时点。这些计时点可以通过编译宏控制开关。同时我还提供了与外部性能剖析工具如 NVIDIA Nsight Systems、Intel VTune集成的接口例如使用CUDA的nvtxRangePush/Pop来标记Tensor操作的区间方便在时间线上直观看到每个Tensor操作的开销。Tensor Tensor::contiguous() const { #ifdef TFF_ENABLE_PROFILING nvtxRangePushA(Tensor::contiguous); auto timer ScopedTimer(Tensor::contiguous); #endif // ... 实际实现 ... #ifdef TFF_ENABLE_PROFILING nvtxRangePop(); #endif }这些工具在框架性能调优和定位复杂Bug时起到了至关重要的作用。它们让我能清晰地看到时间到底花在了内存分配上还是数据拷贝上或者是某个非预期的序列化操作上。9. 边界条件、错误处理与稳定性保障工业级代码必须健壮。Tensor系统作为基础组件其错误处理必须严谨。9.1 边界检查所有涉及索引访问的操作如operator()或slice都必须进行边界检查。在Debug模式下使用assert或抛出异常在Release模式下为了性能可以考虑使用自定义的边界检查宏或者依赖安全的内存访问模式如确保迭代器在合法范围内。float Tensor::at(const std::vectorint64_t indices) { #ifndef NDEBUG for (size_t i 0; i indices.size(); i) { assert(indices[i] 0 indices[i] shape_[i]); } #endif // 计算偏移并返回引用 size_t offset compute_offset(indices); return reinterpret_castfloat*(data_ptr())[offset]; }9.2 设备与数据类型兼容性检查任何跨设备或跨数据类型的操作如拷贝、运算前都必须进行显式检查。例如Copy函数会检查源和目标的字节数是否匹配add操作会检查两个Tensor的形状是否可广播、设备是否相同或可隐式拷贝。9.3 异常安全Tensor的构造函数和修改操作如reshape,to需要保证异常安全即当操作失败时如内存不足对象应保持在一个有效且一致的状态。这通常通过RAII和“先准备后备再交换”的模式来实现。Tensor Tensor::to(Device target_device) const { if (this-device() target_device) { return *this; } // 1. 先在目标设备上创建一个新的、空的Tensor。 Tensor new_tensor(this-shape_, this-dtype_, target_device); // 2. 尝试拷贝数据。如果拷贝失败如cudaMemcpy返回错误异常会被抛出。 Copy(*this, new_tensor); // Copy内部会处理错误 // 3. 只有拷贝成功才返回新Tensor。 return new_tensor; } // 如果Copy抛出异常new_tensor会在栈展开时被正确析构释放已分配的目标设备内存。 // 调用者看到的仍然是原来的Tensor状态未改变。9.4 线程安全Tensor对象本身的读写不是线程安全的这是出于性能考虑加锁开销大。但TensorStorage的引用计数操作是原子的这保证了多个线程持有同一个Tensor的视图时底层内存的生命周期是安全的。框架文档中需要明确警告用户并发修改同一个Tensor的数据是未定义行为必须由用户自己加锁保护。对于分配器Allocator如果它内部有状态如内存池则需要自己实现线程安全。DebugAllocator就使用了互斥锁来保护其内部映射表。10. 总结与展望Tensor系统是框架的基石写到这里关于TFFInfer Tensor系统的上半部分——内存抽象与核心设计——就差不多了。我们从一个简单的多维数组概念出发逐步构建了一个支持视图、跨设备、可序列化、带调试工具、异常安全的复杂抽象。回顾一下关键点分离存储与视图是灵活性的根源它高效支持了切片、转置等操作。分配器抽象解耦了内存来源让框架能适配各种硬件和内存管理策略。明确的设备与数据类型是异构计算和混合精度计算的基石。深思熟虑的序列化与零拷贝机制直接关系到框架的加载效率和运行时性能。完善的工具链与错误处理是项目长期稳定运行的保障。这套系统近万行的代码不是一蹴而就的而是在不断踩坑、调试、优化中迭代出来的。比如最初没有设计Stride导致实现转置操作时必须物理拷贝数据性能惨不忍睹再比如早期内存泄漏排查困难促使我加入了DebugAllocator。在下篇中我们将聚焦于Tensor的运算系统如何基于这套内存抽象构建一个高效、可扩展的算子库如何实现自动微分虽然推理框架不一定需要但设计上有考虑如何与现有的BLAS库如OpenBLAS、cuBLAS以及更高级的编译器如TVM、MLIR进行集成这些内容将把Tensor从一个被动的数据容器变成一个主动参与计算的强大实体。Tensor系统就像一栋大楼的地基它不直接提供华丽的业务功能但决定了整栋楼能建多高、多稳。花时间打磨好地基后续在之上构建模型加载、计算图优化、算子融合、推理引擎等模块时才会感到顺畅和稳固。这六个月的GAP期让我有足够的时间回头审视这些基础问题现在看来是非常值得的。