你可以解压后看看对比一下 2 个文件。

style 很多时候占用的空间，比数据本身还多，如果没有任何 style, xlsx 文件内部的 xml 这种纯文本压缩后，不会被 txt 大多少，如果实在追求极致的文件大小,cvs 并压缩，应该是是最小的。

格式问题，datagrip 可能内部去掉了单元格的 style.

输出张量:
[
[0.23729032]
[0.84413356]
[0.5424989 ]
[0.24236819]
[0.1216919 ]
[0.574163 ]
[0.5093746 ]
[0.40847316]
[0.32745278]
[0.3172678 ]
]

输出张量:
[
[0.23729032]
[0.84413356]
[0.5424989 ]
[0.24236819]
[0.1216919 ]
[0.574163 ]
[0.5093746 ]
[0.40847316]
[0.32745278]
[0.3172678 ]
]

cupy-cuda117 我也试过，其它环境都和你的一样，只有显卡和驱动版本和型号同你的不一致。

NVIDIA-SMI 470.161.03 Driver Version: 470.161.03 CUDA Version: 11.4

感觉你可能需要更详细的用 conda list 获取所有包的详细版本和签名(或者用 conda-lock)，然后获取你的硬件信息(主要是 GPU 相关的，驱动版本和 CUDA 版本)，并提供一个复现的的 github 仓库地址，然后发给 pytorch 官方，让它们的人去找找原因。

@111qqz 抱歉，我无法复现你的问题，我在 3090/4090 都无法复现此问题，我手头暂时没有 H100/A100 的卡。不同机器上的结果竟然都不一致。但是调换后引用后的值，并不会有变化。可能是底层 CUDA 的 A100/H100 的底层模块不同导致的？你还有其它同事有其它型号的型卡吗? 或者切换以下版本。我用的 cupy-cuda111.
[[0.23727967]
[0.8440665 ]
[0.5425058 ]
[0.24246126]
[0.12167222]
[0.57418287]
[0.5093833 ]
[0.40845215]
[0.32752675]
[0.31734812]

[0.23727967]
[0.8440665 ]
[0.5425058 ]
[0.24246126]
[0.12167222]
[0.57418287]
[0.5093833 ]
[0.40845215]
[0.32752675]
[0.31734812]

@111qqz 库的版本信息呢？

我来给你测试一下。

怀疑是这 2 个库使用了不同的种子，因此后面一个覆盖了前面一个的，导致结果始终不同，不过这应该对最终结果不会造成影响。

@princelai 我也用过。现在懒得折腾，所有项目都尽量用 conda-lock 锁定版本，跳过解析过程。

就我看来，python 的设计是很糟糕的，除了降低了写代码的门槛低。之所以火，纯粹是因为搞 ML 这批人不是计算机专业的，很多人都是学数学等相关专业的。另外就是 python 存在大量的 wapper 函数库（也就是 python 在这这里只是调用底层 c/c++的一层胶水), 这显著降低了 python 的门槛。python 是一门好用，却难学的语言。大部分计算机要不难用，要不难学，c++例外，即难学有难用。

@oldshensheep 对于自己不理解的东西，先去尝试理解它的设计，然后再来评价。.NET 的 Assembly 设计是非常优秀的，pip/node 包的那么多破事就是因为版本依赖一开始就没有正确设计在 runtime 中。.NET 平台诞生之初就是要解决 dll hell 问题。我已经不知道多少次被 pytroch 的各种包折腾了。各种 ML 库的依赖绝对可以搞到你头大。随便一个小版本升级就 GG,conda 的依赖解析都是按照小时计算。后来 conda 自己又开始锁定包版本。至于源码查看，其实是因为很多包不提供二进制分发，如果 nuget 包提供二进制分发，使用 source link+pdb 文件，调试源代码一点也没问题。我天天调试.NET Runtime 和 ABP 等第三方框架的源代码，一点问题也没有。

可以记住一个人的上下文，并不意味着可以记住全球几千万的，因为每个人的上下文是不能交叉的。

并不是记不住，而是记得越多，下一次回答就要从头重新扫描一个当前的上下文，这会导致计算量极大，因此一个上下文越长，它的会速度就会越来越慢，越来越慢，至于为啥不能固化上一次的权重，当然是因为成本，如果算力足够，不计成本，当然可以记住你一个人的全部上下文。

@blackeeper 数据库配置文件根本没有被请求的可能性，数据库配置是通过环境变量注入到应用的（一次性环境变量)，数据库被入侵的时候应用容器组都是停止状态)。我远程的 root ssh 都是关闭了的，而且 root 的密码也是修改过的，默认用的也不是 root 账号，整个环境除了存在 0day 我实在想不通到底是哪里导致问题的，我现在甚至怀疑微信发送消息是不是会被泄露，因为整个流程我只有通过微信自己给自己（文件助手)发送过 mysql 密码，密码除了我的微信上有，我自己甚至都记不住。

@blackeeper 这些地方都没有可能性，因为数据库被攻破的时候，我的应用是停止状态，另外我的引用也全部是容器化的，msyql 工具用的是官方下载的 MySQL Workbench 8.0 CE ，密码除了通过微信发给过我自己，没有任何人知道。

有条件就再准备一个 Windows 笔记本的，性能也不需要很强，我现在的 Laptop3 就出差的时候应急。项目现场做汇报，没有 Windows 机器各种麻烦。

双持好了，我目前也是：2 个 Windows 台式机，一个 Mac Mini ，一个 Air. mac 主要用来娱乐，Windows 主要用来工作。使用 OneDrive 同步数据。