Li Xinqi
> > 针对 [#8866 (comment)](https://github.com/Oneflow-Inc/oneflow/pull/8866#discussion_r955574611) 这个问题。与后江开会讨论结果： > > > > 1. python层的flow.Stream名不副实。它其实在导出flow.StreamSet概念，即这是一个跨StreamType/DeviceType的概念，与一般用户理解的stream从属于device这一常识相去甚远。 > > 2. PipeLine，Device，StreamType这三者唯一确定一个vm::Stream对象。 > > 好像和通常理解的 PipeLine （流水线） 也关联不大，更接近 c++ std::thread 的抽象，flow.Thread？ > > _Thread，Device，StreamType这三者唯一确定一个vm::Stream对象_ _Thread，Device，StreamType这三者之下应该允许存在多个Stream对象。
> 读完 [Oneflow-Inc/OneTeam#1632](https://github.com/Oneflow-Inc/OneTeam/issues/1632) 这个 issue，还无法完全领会这个功能所起的作用，解决什么问题，以及为什么要这么解决（这么解决的好处或者必要性）。 把vm底层的vm::Stream导出到python层，直接提供给用户一些抓手优化性能。
> 现在我们Python这个Stream的作用其实和PyTorch的Pipe更贴近（https://pytorch.org/docs/stable/_modules/torch/distributed/pipeline/sync/pipe.html#Pipe ），oneflow C++ stream是更底层的东西，它就类似于流水线里的工人，可以有多个，高级的流水线还能让指令在这些stream上乱序执行。 > > 如果我们现在导出flow.stream，那以后为了对齐pytorch，肯定也还要导出flow.cuda.stream，这两个stream就很难向用户解释清楚了。 与Pipe Module差得还是挺多的，它主要解决多个卡之间的流水。 ``` If the module requires lots of memory and doesn't fit on a single GPU, pipeline parallelism is a useful...
> ```python > auto_sync=False > ``` auto_sync的参数是不是可以去掉，其实这个不需要用户操心。
> > > > 针对 [#8866 (comment)](https://github.com/Oneflow-Inc/oneflow/pull/8866#discussion_r955574611) 这个问题。与后江开会讨论结果： > > > > > > > > 1. python层的flow.Stream名不副实。它其实在导出flow.StreamSet概念，即这是一个跨StreamType/DeviceType的概念，与一般用户理解的stream从属于device这一常识相去甚远。 > > > > 2. PipeLine，Device，StreamType这三者唯一确定一个vm::Stream对象。 > > > > > >...
> > > ```python > > > auto_sync=False > > > ``` > > > > > > auto_sync的参数是不是可以去掉，其实这个不需要用户操心。 > > 为什么呢，我理解有了这个参数我们才能让我们目前的 stream 和未来兼容 PyTorch 的 stream 在同一个概念下暴露给用户 首先，torch.Stream并没有显式的auto_sync参数，而是一个笼统的kwargs。其次，如果将来真的有stream_set.compute_stream()的需求，到时再扩充flow.StreamSet，同样加一个kwargs就可以了。
> > experimental > > 试验性的工具类 torch 一般是放到 utils.xxx 下面，稳定后再升级到二级命名空间下、或者一级命名空间下。 > > 之前的实验性功能命名空间 experimental 也都已经删掉了 我没有找到过torch.experimental.xxx api。最多只是找到了functorch.experimental.xxx和torchtext.experimental.xxx。后两者看起来是基于pytorch框架做得库，不是torch本身的东西。 或者，在其子名字空间下还可以找到experimental https://pytorch.org/docs/stable/search.html?q=torch.experimental&check_keywords=yes&area=default#
## 备选方案以及辩护理由 ### 新奇、建浩提 flow.StreamSet / flow.stream_set 啸宇：不应该直接放在oneflow顶层名字空间 后江：Stream这个字眼不合适，普通c++的开发人员容易理解成io流，而cuda开发人员容易理解为stream，但其实都不太像。 ### 新奇、建浩提 flow.experimental.StreamSet / flow.experimental.stream_set 啸宇：torch的不太成熟的api一般都放在torch.utils名字空间下。 后江：Stream这个字眼不合适，普通c++的开发人员容易理解成io流，而cuda开发人员容易理解为stream，但其实都不太像。 ### 新奇提 flow.vm.StreamSet / flow.vm.stream_set 新奇：不太想把vm这个概念暴露出来，本质上不应该让用户关心。 后江：Stream这个字眼不合适，普通c++的开发人员容易理解成io流，而cuda开发人员容易理解为stream，但其实都不太像。 ### 新奇提 flow.worker.StreamSet / flow.worker.stream_set 新奇：用户不太能理解worker语义。 啸宇：子命名空间应该是特定功能，worker有点不合适。...
### 决策原则 1. api是否明确暴露eager 运行时的核心特性。 2. 让用户最快地理解api如何使用。
> [684b0a4](https://github.com/Oneflow-Inc/oneflow/commit/684b0a43b5cb9ca5e698a32c04a0cb90e0340f12) 编译有报错 https://github.com/Oneflow-Inc/oneflow/actions/runs/3286674212 > > ``` > ninja: build stopped: subcommand failed. > Error: {"ID":"0f3c12d8ef0a3ba46d79b1edd45ecf156129ab222dfae70cdc2bfaa937b55462","Running":false,"ExitCode":1,"ProcessConfig":{"tty":false,"entrypoint":"bash","arguments":["-l","/home/ci-user/runners/release/_work/oneflow/oneflow/ci/manylinux/build-gcc7.sh"],"privileged":false},"OpenStdin":false,"OpenStderr":true,"OpenStdout":true,"CanRemove":false,"ContainerID":"415a31872fb6d3610161033266276f17e23a7258abc57a2e18ed6353f33c1541","DetachKeys":"","Pid":2822682} > ``` > > @daquexian @lixinqi /home/ci-user/runners/release/_work/oneflow/oneflow/oneflow/api/python/custom_eval_frame.c:25:10: fatal error: internal/pycore_pystate.h: No such file or...