Pytorch: RFC: 결정적 알고리즘을 강제 실행하기 위해 torch.deterministic 플래그 추가

이것은 나에게서 위로 엄지손가락이다. 문제는 주로 이것을 코드베이스의 모든 곳에서 실제로 롤아웃하는 방법입니다. 더 나쁜 것은 우리가 결정론적이라고 주장하는 것입니다. 그러나 비밀리에 그것은 아닙니다 :)

나는 그것에 찬성하고 내 접근 방식은 결정론이 켜져 있고 그렇지 않다는 것을 알고 있을 때 작업 및 오류에 플래그를 지정하는 것입니다.

비결정적 연산에서 오류를 범하는 것은 너무 가혹하다고 생각합니다. 경고는 더 부드러운 경험처럼 보입니다.

기본적으로 throw가 되어야 한다고 생각하지만 다중 값 속성을 지원할 수 있다고 생각합니다(비결정적은 괜찮음, 경고, throw).

나는 경고의 사용 사례를 실제로 보지 못한다는 것을 인정해야 합니다. 사람들이 그것을 켤 만큼 충분히 결정적인 것에 관심을 가질 때 그들은 아마도 오류를 예상할 것입니다. 어떤 비결정론이 있어도 괜찮다고 말하는 특정 호출에 대해서는 항상 이 기능을 끌 수 있습니다.

오류, 경고, 적절한 문서...
후자는 필수입니다.
경고 또는 오류? 오류가 발생합니다.

던지는 것은 대단한 것 같다. 던지는 대신 경고하는 옵션을 제공하는 것이 합리적으로 보인다는 Adam의 의견에 동의합니다.

알려주셔서 감사합니다. 결국 삼항 플래그를 위한 주요 노력은 플래그 자체이며 어렵지 않습니다.
Context.h에 플래그를 추가하고 (유틸리티 함수를 통해) AT_ERROR 및 AT_CHECK를 뿌릴 것입니다.

안녕하세요,
이 깃발에 어떤 소식이 있습니까?
결정론이 중요합니다.
내 경험에 따르면 현재 버전은 고정 시드를 사용하여 최대 정밀도 1e-16 까지 하나의 GPU에 대한 결정성을 허용합니다. 극미한 차이가 증폭되어 결과를 발산할 수 있다는 점에 유의하십시오.

multigpu의 경우도 고려하십시오(적어도 고정된 K GPU의 경우 동작은 결정적이어야 합니다. 저는 다음과 같은 이유로 때때로 분해되는 일종의 결정론을 달성할 수 있습니다. 지금은 이해하지 못합니다(nightly build 1.2.0.dev20190616 ). 나는 지금 그것 때문에 고군분투하고 있다( 1 , 2 ).

감사합니다!

@t-vi 이 일을 활발히 하고 있나요?

나는 당신이 그것을 하는 것을 막고 싶지 않습니다.

@t-vi 명확하지 않은 경우 죄송합니다. 작업할 계획이 없습니다. :) . 누군가가 적극적으로 그렇게하고 있는지 이해하려고했습니다.

거의 1년이 지난 후에도 비결정적 보간 문제는 여전히 해결되지 않고 있습니다.

커뮤니티에서 이 기능을 추가하기를 바랍니다. :)

결정론적 보간은 사용자에게 큰 도움이 될 것입니다.

~아직 광고하지 않았지만 할당된 개발자 리소스보다 사용자 관심이 더 많은 것 같아서 설정할 때 내 github 후원 페이지 에서 투표할 수 있는 프로젝트로 나열했습니다.
나는 우리가 올해 말까지 좋은 진전을 이룰 수 있다고 확신하고 보간법은 확실히 수정 방법에 대한 계획이 있는 것 중 하나입니다(내가 문제의 어딘가에 있는 fold에 대한 의사 코드와 유사). 내 자신의 우선 순위 목록에 높지 않습니다.~
흥미롭지 않은 것으로 나타났습니다.

결정론적 보간은 큰 도움이 될 것입니다. 링크

범핑 우선 순위, 특히 CUDA의 경우 사용자 피드백을 기반으로 합니다.

고쳐지고 있어서 다행입니다, 감사합니다!

@t-vi는 공정하기 위해 "우선 순위 충돌"이 "고정 중"과 동일하다고 생각하지 않습니다. :).

솔루션을 기대합니다!

colesbury는 결정론적 알고리즘의 킬러 이유 중 하나는 결정론이 실제로 문제이기 때문이 아니라 이 기능을 켤 때 이를 배제할 수 있다고 언급했습니다. ;)

torch.experimental.deterministic 는 RNG 시드와 어떻게 상호 작용해야 합니까? 수동 시드가 설정되지 않은 경우 기본 시드를 설정해야 합니까? 수동 시드가 설정되지 않은 경우 경고를 발행해야 합니까?

사용자가 시드를 설정하지 않은 경우 시드를 설정하지 않는 것이 좋습니다. 하나는 필요하지 않은 두 개의 인터페이스를 연결하기 때문입니다(결정론에 관심이 있는 사용자는 RNG를 매우 잘 이해할 것이라고 생각합니다). 더 중요한 것은 이 작업을 안정적으로 수행하기가 매우 어렵다는 것입니다. 다중 프로세스/스레드 응용 프로그램에서 RNG를 사용할 수 있고, 다른 torch.Generator 하위 클래스가 있고, numpy.random 도 사용할 수 있습니다.

경고를 설정할 수 있는 적절한 위치가 있는 경우에만 경고에 대해 확신할 수 없습니다(예: RNG가 사용되는 동일한 모듈/함수가 아니라 determinism=True 이전에 강제로 시드하시겠습니까?).

torch.backends.cudnn.deterministic=True 설정할 때 보간 연산자가 여전히 결정적일 수 없다는 점이 궁금합니다. pytorch 보간은 cudnn을 사용하지 않습니까?

그렇지 않을 수도 있습니다. 보간 실행을 nvprof하여 확실하게 확인할 수 있습니다.

torch.experimental.deterministic 가 구현되면 함수 호출에서 deterministic 인수를 계속 제공해야 하는지 여부가 궁금합니다. 사용자가 일부 작업에는 결정성을 선호하고 다른 작업에는 속도를 선호할 수 있기 때문에 그렇게 해야 할 수도 있습니다.

인수를 유지하면 torch.experimental.deterministic 와 함수의 deterministic 플래그가 서로 반대되는 경우 어떻게 됩니까? torch.experimental.deterministic = True 가 "무슨 일이 있어도 모든 경우에 결정론을 사용"을 의미해야 하거나 "결정론을 기본값으로 사용하지만 deterministic 인수가 함수 호출에 지정된 경우에는 다음을 사용하십시오. 특정 기능 호출에 대한 설정입니다." 즉, 아래 코드를 어떻게 처리해야 할까요? 비슷한 상황에서 torch.backends.cudnn.deterministic 플래그가 어떻게 작동하는지 아는 사람이 있습니까?

torch.experimental.deterministic = True
torch.some_operation(deterministic=False)

@kurtamohler 좋은 질문입니다. 가장 쉬운 수정은 bool? deterministic=None 로 만든 다음 None 를 " torch.experimental.deterministic 존중"을 의미하도록 해석하고, 그렇지 않으면 사용자가 요청한 것을 정확히 사용하는 것입니다.

우리는 종류의 회선과 비슷한 상황을 가지고 있지만 그것을 수행 된 방법이 있다는 것을이이었다 convolution 아니오 benchmark 다음 인수 및 _convolution 명시 적으로 기준.

이 솔루션 중 하나가 허용될 것이라고 생각합니다. 그러나 컨볼루션 접근 방식은 내부 deterministic 플래그를 사용자가 볼 수 있는 API로 누출하지 않는다는 추가 이점이 있습니다(내부 API를 사용하지 않는 한).

"나는 모든 곳에서 결정론적이 되고 싶지만 _이 특정 연산자에서는 _ 하지 않기를 원합니다."에 대한 근거는 무엇입니까? 이것이 우리의 많은 연산자(그리고 대부분의 복잡한 연산자)에 추가 입력을 추가하는 것을 보증할 만큼 충분히 일반적인 사용 사례라고 해야 할까요? IMO에서는 결정성을 토글하기 위한 컨텍스트 관리자를 제공하는 것이 좋습니다.

@apaszke , 네, 컨텍스트 관리자를 사용하여 결정론을 토글하는 것이 더 낫다고 생각합니다. 어떤 연산자에도 deterministic 인수를 추가해야 한다고 말하지는 않지만 일부 연산자에는 이미 있습니다. 그것들을 모두 제거하고 BC를 중단하는 것이 가장 좋습니까, 아니면 계속 유지하고 torch.experimental.deterministic 를 재정의하도록 허용하는 것이 가장 좋습니까?

나는 그것을 제거하거나 최소한 비공개로 만들어야 한다고 말하고 싶습니다(즉, 밑줄 접두사 또는 sth).

보간 기능에 대한 결정적 기능이 닫혀 있고 구현되지 않는지 궁금합니다.

아니요, 우리는 PyTorch의 모든 기능에 대한 결정론적 버전을 사용할 수 있습니다.

@ezyang 어떤 pytorch 버전에 결정적 F.interpolate 기능이 있습니까? pytorch 1.6부터 시작합니까? 아니면 최신 안정 버전(1.5)에서 사용할 수 있습니까? 아니면 소스에서 Pytorch를 다운로드하여 설치해야 합니까?

이 작업을 시작하게 되어 기쁩니다.

위의 커밋은 플래그만 추가할 뿐 아직 작업에는 영향을 미치지 않습니다. 누군가 시간을 내어 살펴보고 내가 잘못한 것이 있거나 지금까지 개선할 수 있는 것이 있으면 알려주시면 감사하겠습니다. torch.backends.cudnn.deterministic 구현 방법을 기반으로 했습니다.

이것은 괜찮아 보이지만 내부 이름 지정에는 실험적 항목이 포함되어서는 안 된다고 생각합니다.

@ezyang , 네 이해가 됩니다. 이름을 바꾸겠습니다.

@t-vi가 이 문제에 대한 이전 작업에서 했던 것과 유사한 torch.experimental.deterministic_error_level 추가했습니다. deterministic_error_level 는 deterministic == True 이고 주어진 함수에 결정적 구현이 없는 경우 오류/경고 동작을 제어합니다. 2(오류), 1(경고) 또는 0(무음)으로 설정할 수 있습니다.

사용자가 다른 값으로 설정하면 잡을 수 있는 파이썬 런타임 예외를 던지고 싶습니다. 일반적으로 이러한 종류의 동작에 TORCH_CHECK() 를 사용하지만 이 경우 예외를 포착할 수 없고 이유를 모르겠습니다. TORCH_CHECK() 호출은 다음과 같습니다. 링크

검사가 실패하면 다음과 같이 됩니다.

>>> import torch
>>> try:
...     torch.experimental.deterministic_error_level=50
... except:
...     print('exception caught')
... 
terminate called after throwing an instance of 'c10::Error'
  what():  error level 50 is invalid, must be one of 0: None, 1: Warn, or 2: Error
Exception raised from longToErrorLevel at ../aten/src/ATen/Context.cpp:85 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) + 0x58 (0x7f53e2cc0878 in /work/kurtamohler/development/pytorch-deterministic-flag/torch/lib/libc10.so)
frame #1: at::Context::longToErrorLevel(long) + 0x122 (0x7f53f6d61a82 in /work/kurtamohler/development/pytorch-deterministic-flag/torch/lib/libtorch_cpu.so)
frame #2: THPModule_setDeterministicErrorLevel(_object*, _object*) + 0x31 (0x7f53fb5625d1 in /work/kurtamohler/development/pytorch-deterministic-flag/torch/lib/libtorch_python.so)
<omitting python frames>
frame #23: __libc_start_main + 0xe7 (0x7f5432d62b97 in /lib/x86_64-linux-gnu/libc.so.6)

Aborted (core dumped)

누구든지 내가 그것을 고칠 수있는 방법을 알고 있다면 알려주십시오.

@kurtamohler 에 THPModule_setDeterministicErrorLevel HANDLE_TH_ERRORS / END_ HANDLE_TH_ERRORS 매크로가 누락되었습니까? C++ 예외를 잡아서 파이썬 오류 반환으로 변환하는 데 필요합니다.

아 그랬습니다, @colesbury에게 감사드립니다!

atomicAdd 의 모든 호출자에게 비결정적 경고를 추가하기 시작했습니다. 일부 발신자는 특정 경우에만 atomicAdd 를 사용한다는 것을 알았습니다. 예를 들어 adaptive_avg_pool3d_backward 는 (isizeW%osizeW != 0) || (isizeH%osizeH != 0) || (isizeT%osizeT != 0) 가 true인 경우에만 사용합니다. 이러한 경우에만 경고하고 오류 메시지로 전달해야 합니까, 아니면 atomicAdd 가 사용되는지 여부에 관계없이 이러한 함수가 호출될 때마다 경고하는 것이 괜찮습니까?

무조건 경고하면 구현하기 쉽고 이해하기 쉬울 것입니다.

@ngimel , 저는 CUBLAS_WORKSPACE_CONFIG 를 사용하여 결정적인 스트림 사용을 보장하는 방법에 대해 생각해 왔으며 고려해야 할 두 가지 주요 접근 방식이 있다고 생각합니다.

누군가가 영향을 받는 CUDA 버전(현재 10.2 이상) 중 하나를 사용하고 있고 torch.set_deterministic(True) 가 호출되면 std::getenv 를 사용하여 CUBLAS_WORKSPACE_CONFIG 가 :16:8 또는 :4096:8 . 그렇지 않은 경우 (1) 또는 (2)를 수행합니다.

1. 사용자에게 변수를 적절하게 설정하라는 오류를 던집니다.

2. putenv (Windows의 경우 _putenv )로 변수를 자동으로 설정합니다. 그러나 이와 관련된 몇 가지 추가 설계 결정이 있습니다. :16:8 (성능은 낮지만 메모리 사용량은 적음) 또는 :4096:8 (성능은 높지만 메모리 사용량은 많음)를 선택해야 합니까? 또한 사용자가 변수를 다른 비결정적 값으로 설정하면 torch.set_deterministic(False) 가 호출되면 원래 값을 추적하고 복원해야 합니다. 그렇지 않으면 사용자에게 다음과 같이 알리는 오류가 발생할 수 있습니다. 변수 또는 다른 구성표를 설정 해제해야 합니다.

또한 이미 실행 중인 응용 프로그램에서 변수를 설정하는 것이 실제로 어떤 영향을 미칠지 모르기 때문에 옵션 (2)가 가능한지 확실하지 않습니다. 변수는 CUDA 런타임이 시작되거나 cuBLAS 핸들이 생성될 때 한 번만 확인할 수 있습니다. 이에 대한 정보를 찾을 수 없었으므로 아마도 실험적으로 알아내야 할 것입니다(어느 쪽이든 테스트를 작성하려면 비결정적 스트림 사용량 재생기를 사용해야 하므로 이에 대해 조사하겠습니다) . 또한 환경 변수를 사용하는 대신 API 호출을 찾았지만 CUDA에서는 제공하지 않는 것 같습니다.

어떤 옵션이 더 좋을지에 대한 강력한 의견이 있습니까? 옵션 (2)는 아마도 더 사용자 친화적이지만 옵션 (1)보다 덜 투명할 수 있습니다.

응용 프로그램이 이미 실행 중인 동안 변수를 설정하는 것이 실제로 어떤 영향을 미칠지 모르겠습니다.

이 질문에 대한 후속 조치로 pytorch 스크립트 내에서 환경 변수를 설정해도 CUDA 스트림의 결정성에 영향을 미치지 않는 것 같습니다. https://github.com/pytorch/pytorch/issues/39849 에서 스크립트를 수정하여 여러 번 실행하고 훈련 통계를 비교하여 비결정적 동작을 확인했습니다. 결정적 스트림 사용을 보장하기 위해 CUBLAS_WORKSPACE_CONFIG=:4096:8 설정을 시도합니다. https://github.com/kurtamohler/pytorch-perf-test-scripts/blob/master/nondeterministic_alert/cuda_stream_nondeterminism.py

그것을 실행하면 스크립트 내에서 변수를 설정하는 것으로부터 결정적인 동작을 얻지 못한다는 것을 알 수 있습니다.

$ python cuda_stream_nondeterminism.py 
Before setting var: not deterministic
After setting var: not deterministic
After restoring old var: not deterministic

그러나 스크립트 외부에 설정된 환경 변수로 실행하면 결정적입니다.

$ CUBLAS_WORKSPACE_CONFIG=:4096:8 python cuda_stream_nondeterminism.py 
Before setting var: possibly deterministic
After setting var: possibly deterministic
After restoring old var: possibly deterministic

훈련 기능을 5번만 실행하기 때문에 "possably deterministic"이 인쇄되며 동작이 실제로 결정적이지 않더라도 운이 좋을 수 있습니다.

아마도 cuda 스트림을 다시 초기화할 수 있다면 변경된 CUBLAS_WORKSPACE_CONFIG 변수를 적용하도록 강제할 것입니다. 나는 그것을 시도하고 싶지만 어떻게 또는 그것이 런타임에 가능한지 모르겠습니다. 아시는 분 계시면 알려주세요.

다음을 사용하여 새 스트림을 만들고 사용할 수 있다는 것을 알았습니다.

with  torch.cuda.stream(torch.cuda.Stream()):

그러나 새 스트림은 변경된 환경 변수 설정을 적용하지 않습니다. torch.cuda.init() 도 찾았지만 불행히도 cuda가 이미 초기화된 경우에는 작동하지 않습니다.

따라서 시도할 다른 방법이 생각나지 않으면 작업 공간 구성을 자동으로 변경할 수 없는 것 같으므로 사용자에게 설정하라는 오류가 발생해야 할 수 있습니다.

네, cuda 컨텍스트가 초기화된 후 환경 변수를 설정해도 아무런 효과가 없으므로 불행히도 그것은 전부 아니면 전무(all or nothing) 솔루션입니다. 사용자에게 설정하라는 오류를 던지는 것은 합리적으로 들립니다.

현재 nvcc가 아닌 컴파일된 파일에서 CUDA 버전을 확인할 수 없는 것 같아서 aten/src/ATen/cuda/detail/CUDAHooks.h 에 추가해야 할 것 같습니다(cuDNN 버전 확인은 해당 인터페이스의 일부임) . 더 잘 아시는 분 계시면 알려주세요.

위의 커밋은 오류를 추가합니다. 하지만 지금 단위 테스트로 무엇을 해야 하는지 알아내야 합니다. 두 가지 문제가 있습니다.

• 오류가 올바른 경우에 발생하는지 테스트하려면(cuda >= 10.2이고 CUBLAS_WORKSPACE_CONFIG 가 제대로 설정되지 않음) 테스트 인프라는 테스트를 실행하기 전에 환경 변수를 자동으로 변경할 수 있어야 합니다.
• 기존 torch.set_deterministic 테스트가 중단되지 않도록 하려면 CUBLAS_WORKSPACE_CONFIG 를 자동으로 적절하게 설정해야 합니다. cuda >= 10.2를 사용하는 모든 CI 작업에서 기본적으로 이 변수를 설정할 수 있습니다.

나는 파이썬 스크립트에서 환경 변수를 설정할 수 있다는 것을 알게 되었고, 새 값을 존중하도록 토치 모듈을 다시 로드할 수 있다는 것을 알게 되었습니다:

>>> import torch
>>> torch.set_deterministic(True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/work/kurtamohler/development/pytorch-deterministic-flag-cuda-env-var/torch/__init__.py", line 306, in set_deterministic
    _C._set_deterministic(d)
RuntimeError: To enable deterministic behavior with CUDA >= 10.2, you must set environment variable CUBLAS_WORKSPACE_CONFIG=:4096:8 or CUBLAS_WORKSPACE_CONFIG=:16:8. For more information, go to https://docs.nvidia.com/cuda/cublas/index.html#cublasApi_reproducibility
>>> import os
>>> os.environ['CUBLAS_WORKSPACE_CONFIG'] = ':4096:8'
>>> from importlib import reload
>>> torch = reload(torch)
>>> torch.set_deterministic(True)

토치를 재장전하면 CUDA가 이 변경 사항을 준수하게 될지 모르겠지만 적어도 이것은 우리에게 오류 메시지에 대한 단위 테스트 방법을 제공합니다. 묻고 싶지만 단위 테스트 내에서 토치 모듈을 다시 로드하는 데 문제가 있습니까?

편집: 변경된 환경 변수를 보기 위해 토치를 다시 로드할 필요가 없는 것으로 나타났습니다. 또한 변수를 변경한 후 다시 로드해도 CUDA 런타임에는 영향을 미치지 않습니다.

위의 커밋은 이전 의견에서 언급한 모든 문제를 해결합니다. torch.set_deterministic() 를 호출하는 API 테스트를 래핑하기 위해 데코레이터를 추가했고 필요할 때만 임시로 CUBLAS_WORKSPACE_CONFIG=:4096:8 설정했습니다. 또한 결정적 플래그와 CUBLAS_WORKSPACE_CONFIG 설정을 테스트가 실행되기 전의 상태로 복원합니다.

재현성 문서에서 결정적 CuDNN 동작이 필요하다고 언급한다는 것을 깨달았습니다.

torch.backends.cudnn.deterministic = True
torch.backends.cudnn.benchmark = False

이 스레드의 누군가가 benchmark 가 정확히 무엇인지 알고 있으며 torch.backends.cudnn.deterministic = True 자체로는 충분하지 않은 이유는 무엇입니까?

torch.is_deterministic() == True 이면 benchmark 를 강제로 끌 수 있습니다. 즉, ctx.benchmarkCuDNN() 를 at::_convolution() 직접 전달하는 대신 https://github.com/pytorch/pytorch/blob/ 라인에서 ctx.benchmarkCuDNN() && !ctx.deterministic() 여야 합니다. master/aten/src/ATen/native/Convolution.cpp#L602

이 변경을 수행하지 않으면 set_deterministic 및 CuDNN을 사용하는 사람들이 다음을 수행해야 할 것 같습니다.

torch.set_deterministic(True)
torch.backends.cudnn.benchmark = False

set_deterministic() 만으로는 모든 것을 다루지 못하므로 제 생각에는 혼란스럽습니다.

cc @ezyang @colesbury @t-vi @ngimel

새로운 컨볼루션 구성이 발생하면 benchmark=True 는 사용 가능한 모든 cudnn 구현을 실행하고 가장 빠른 구현을 선택하여 선택한 구현을 캐싱하므로 동일한 매개변수를 사용하는 컨볼루션에 대한 모든 후속 호출에서 이를 사용합니다. 따라서 deterministic 도 True 설정되어 있으면 이 캐시가 지속되는 한, 즉 동일한 프로세스에 있는 한 결과가 결정적입니다. 가까운 런타임이 있는 구현이 있는 경우 다음에 프로세스를 시작하고 벤치마킹을 다시 실행할 때 다른 구현이 승리할 수 있으며 결과(위에 설명된 의미에서 여전히 결정적이지만)는 이전 실행과 다릅니다. 따라서 실행 간의 결정성을 보장하려면 벤치마킹을 꺼야 합니다.

내가 참조. 따라서 아마도 일부 애플리케이션에서는 프로세스 간 결정론이 아닌 프로세스 내 결정론만 중요하므로 사람들이 torch.set_deterministic(True) 를 설정하면 벤치마킹을 계속 사용할 수 있다는 것이 유용하다는 것을 알 수 있습니다. 이 경우 현재 동작을 변경하지 않아야 합니다. 분명히 하기 위해 문서를 업데이트하는 한 문제가 발생하지 않습니다.

PyTorch 기고자가 torch.set_deterministic() 대한 지원을 추가할 수 있도록 위키 페이지를 만들었습니다. https://github.com/pytorch/pytorch/wiki/How-to-support-%60torch.set_deterministic ()%60-in- PyTorch 운영자

모든 개선 사항을 환영합니다.

또한 "현재 지원되지 않는 기능" 섹션이 이 위키에 있어야 하는지 아니면 새로운 github 문제로 더 좋을지(위키 페이지에서 링크할 수 있음) 확실하지 않았습니다. 선호하는 사람이 있습니까?

안녕하세요, 앞으로 torch.deterministic 에 대한 계획에 대해 이야기하고 싶습니다. 우리가 대답해야 할 몇 가지 높은 수준의 질문이 있습니다.

1. torch.deterministic 의 의미는 무엇입니까? 사용자는 무엇을 기대합니까? 최선의 노력이 실제로 사용자에게 유용한가? 유용하지 않은 경우 torch.deterministic 를 제어 하는 작업의 관점에서 정의하는 것이 더 낫습니까?
2. 이제 torch.deterministic 플래그가 있으므로 공개 API( bmm , 보고 있습니다)에서 deterministic= 키워드 인수를 완전히 제거하는 것이 합리적입니까?
3. 이 작품의 엔드게임은? 일반 커뮤니티에 비해 이 중 당신(@kurtamohler)은 얼마나 작업할 예정이며, 여기서 당신의 제한이 끝나면 합리적인 상태는 어떤 모습입니까?

(1)부터 시작하여 torch.deterministic에 대한 현재 문서는 다음과 같이 말합니다.

     r"""Sets a global flag to force all operations to use a deterministic
    implementation if available. If an operation that does not have a
    deterministic implementation is called while this setting is True, the
    operation will throw a RuntimeError.

    Note that deterministic operations tend to have worse performance than
    non-deterministic operations.

이는 최종 상태에 대해 사실일 수 있지만 이는 많은 작업이 감사되지 않고 주어진 모델에 대해 torch.deterministic 가 실제로 수행할 작업을 알 수 없는 현재 상황을 부정확하게 나타냅니다. 주석에 말하고 모델을 결정적으로 만들거나 nondet을 칠 때 오류를 발생시킵니다. 따라서 기본적으로 우리의 구현은 이러한 의미론과 관련하여 버그가 있으며 가까운 미래에도 계속 버그가 있을 것입니다. 이것은 좋은 상태가 아닙니다.

이를 개선하기 위해 torch.deterministic의 문서를 변경할 수 있습니다. 몇 가지 가능한 변경 사항:

• torch.deterministic 은 최선의 노력 이지만, 일부 비결정성을 포착하지 못하는 경우 버그를 보고하십시오.
• torch.deterministic은 이러한 연산자의 동작을 토글합니다(그런 다음 토글하는 연산자의 전체 목록을 제공합니다).

두 번째 글머리 기호는 (2)로 이어집니다. 이제 torch.deterministic이 결정론을 토글하는 방법으로 존재한다면 사용자 API에서 직접 결정론을 지원하는 것이 훨씬 덜 중요합니다. 따라서 bmm에 deterministic 인수를 추가해서는 안 됩니다. 무언가를 직접 토글하려는 경우 내부 함수를 노출하는 것을 고려할 수 있지만 deterministic 는 함수 자체에서 직접 사용할 수 없어야 합니다.

어떻게 생각해? 문서를 변경하는 것이 지속 가능한 경로로 가는 가장 쉬운 방법이라고 생각합니다. 전체 목록을 채우는 방법과 같은 몇 가지 다른 세부 사항이 있지만 이러한 의미 체계는 실제로는 사실이 아닌 "이상적인" 의미 체계보다 더 합리적일 수 있습니다.

cc @gchanan @mruberry

@zou3519 는 https://github.com/pytorch/pytorch/pull/38683#issuecomment -662590937에서도 Q와 교차했습니다.

@ezyang , @zou3519 , 해주셔서 기쁩니다. 내가 작성한 문서가 현재 상태에 대한 잘못된 표현이라는 데 동의합니다.

나는 torch.set_deterministic() 영향을 미치는 모든 기능을 철저하게 나열하여 사용자에게 거짓말을 하지 않는다는 아이디어를 좋아합니다. @zou3519, 1.6.0에 추가해주셔서 감사합니다.

deterministic 설정을 직접 함수 인수로 제공해서는 안 된다는 데 동의합니다.

최종 게임의 경우 필요한 기간 동안 계속 이 작업을 수행하게 되어 기쁩니다. 하지만 누구나 빠르게 도움을 받을 수 있도록 설정해야 합니다.

장기적으로 영향을 받는 기능의 전체 목록을 제공하는 것이 유효한 결정이라고 생각하지만 전략만으로는 결정적 플래그의 유용성을 극대화할 수 없다고 생각합니다. 다음과 같이 (하나의 특정 환경에서) 기능을 분류할 수 있습니다.

1. 결정론적
2. 기본적으로 비결정적이지만 결정적 플래그를 지원합니다(오류 또는 대체 구현).
3. 비결정적이며 결정적 플래그를 지원하지 않습니다.

물론 이상적인 경우는 범주 3을 완전히 제거한 다음 범주 2 기능 목록으로 충분합니다. 그러나 카테고리 3 기능은 상당한 기간 동안 계속 존재할 것입니다(또는 모든 기여자가 결정론에 대한 문제를 인식하지 못하거나 커밋이 실수로 함수에 대한 결정론을 제거하는 경우 등). 따라서 모든 범주 2 기능의 완전한 목록이 있더라도 사용자는 목록에 나타나지 않는 기능이 결정적인지 여부(범주 1 또는 3일 수 있음)를 알 수 있는 간단한 방법이 없습니다. 예를 들어, torch.add 는 목록에 나타나지 않는데 사용자가 그것이 결정적이라는 것을 어떻게 알 수 있습니까?

카테고리 3 기능 목록을 유지 관리하는 방법도 생각할 수 있습니다. 그러나 이러한 목록을 수동으로 유지 관리하는 것은 여러 가지 이유로 매우 어려울 수 있으므로 어느 정도 자동화할 수 있는지 궁금합니다. 모든 기능에 대해 결정성 테스트를 실행하는 CI 작업을 잠재적으로 설정할 수 있습니다. 함수가 결정적이라는 것을 귀납적으로 100% 증명할 수는 없으며 운이 좋지 않으면 비결정적 함수가 동일한 결과를 여러 번 제공할 수도 있습니다. 그러나 이러한 테스트를 더 자주 실행할수록 각 기능이 속한 범주에 대해 더 확신할 수 있습니다.

또한 각 기능과 플랫폼에 대해 우리가 알고 있는 것과 모르는 모든 것을 사용자에게 가장 효율적으로 전달하는 방법에 대한 질문도 있습니다. 각 플랫폼에서 모든 범주 2 및 3 기능에 대한 테이블을 만들 수 있습니다. 결정성 테스트가 이 테이블이 올바른지 자동으로 확인할 수 있다면 좋을 것입니다.

브레인스토밍을 해보면 이러한 아이디어가 가치보다 더 어려울 수 있습니다. 더 실용적인 계획은 비록 덜 이상적이더라도 훨씬 더 지속 가능합니다.

torch.add 결정적입니까?

import torch
n = 512
device = 'cuda'
a = torch.arange(n**3, device=device, dtype=torch.float32)
a = a.reshape((n, n, n))
b = torch.arange(n**3, device=device, dtype=torch.float32)
b = b.reshape((n, n, n))
out_zero = torch.zeros((n, n, n), device=device)
out_zero = out_zero.set_(out_zero.storage(), storage_offset=0, size=a.size(), stride=(1,1,1))
out_one = torch.zeros((n, n, n), device=device)
out_one = out_one.set_(out_one.storage(), storage_offset=0, size=a.size(), stride=(1,1,1))

torch.add(a, b, out=out_zero)
torch.add(a, b, out=out_one)
(out_zero == out_one).all()
: tensor(False, device='cuda:0')

겹친 텐서가 우리가 추구하는 결정론 계약을 위반한다는 것을 문서화해야 합니다.

"결정론" 플래그의 영향을 받는 작업을 나열하는 것이 좋습니다. 그러나 약간 뒤로 물러서면 우리가 실제로 두 가지에 대해 이야기하고 있는 것 같습니다.

• 가능한 경우 결정적인 버전의 작업 요청( use_deterministic ?)
• 작업이 비결정적일 경우 경고

먼저 플래그는 간단해 보입니다. 그러나 두 번째는 조금 더 까다롭습니다. oneDNN, cuDNN 및 MAGMA와 같은 수학 라이브러리의 작업이 특히 버전 및 하드웨어 전반에 걸쳐 결정적인지 여부를 말하기가 어렵다는 점이 걱정됩니다. @kurtamohler, 이 문제를 가장 잘 해결하는 방법에 대한 아이디어가 있습니까? 어쩌면 우리는 모든 네이티브 비결정적 연산에 대해 경고하고 수학 라이브러리가 호출될 때도 경고할 수 있을까요? 프로세스당 한 번 경고가 그렇게 방해가 되어서는 안 됩니다.

경고에 대한 이러한 접근 방식은 실행되기 전에 많은 알고리즘을 검토하고 사이트를 호출해야 하지만 사용 가능한 경우 결정적 알고리즘을 선택하기 위해 플래그를 차단할 필요는 없습니다.

(세 번째 논의 중인 것은 결정론적 알고리즘 선택을 제시하는 가장 좋은 방법이지만(글로벌 플래그를 통해 또는 함수에 대한 kwargs로) 플래그에 대한 계획을 결정할 때까지 논의를 연기할 수 있다고 생각합니다.)

나는 여기에서 완전한 것을 선의 적으로 두어서는 안 된다고 생각합니다. PyTorch에서 self-overlapping tensor를 사용하는 것이 언제 100% 안전한지 모르겠습니다. 제 인상은 보통 사람들이 사용하지 않는다는 것입니다.

포럼에서 내가 받은 인상은 대부분의 사람들이 무언가를 두 번 실행하고 다른 그라디언트를 얻는다는 사실에 놀란다는 것입니다. 가장 흔한 이유는 PyTorch의 기본 기능 중 하나가 atomicAdd를 사용하기 때문입니다.
이에 대한 경고를 받으면 사람들이 궁금해하는 대부분의 경우를 다룹니다. 절반처럼 느껴지는 것이 실제로는 뒤로 업스케일링한 것입니다.

나는 이것이 외부 라이브러리에 관한 한 최선의 노력이며 문제를 알게 되면 경고를 추가한다고 분명히 명시해야 한다고 생각합니다. 그러나 내 인상은 우리의 기본 커널이 실제로 가장 중요하다는 것입니다.

PyTorch에서 self-overlapping tensor를 사용하는 것이 언제 100% 안전한지 모르겠습니다. 제 인상은 보통 사람들이 사용하지 않는다는 것입니다.

예, 그리고 합리적으로 오류가 있는 것으로 분류될 수 있는 모든 프로그램. 나는 단지 우리가 이 플래그에 대해 제시한 계약을 문서화하는 데 주의해야 한다는 의미였습니다.

외부 라이브러리에 관한 한 이것이 최선의 노력이며 문제를 알게 되면 경고를 추가한다는 점을 분명히 밝혀야 한다고 생각합니다...

문서는 "비결정적이라고 알려진 수학 라이브러리 호출..."과 같이 말할 수 있습니다.

@t-vi에 동의합니다(보고된 비결정론의 절반이 역방향으로 업스케일링된다는 관찰이 정말 마음에 듭니다). 특히, 비결정적이라고 알려진 함수를 부분적으로 문서화한 상태(또는 일부 함수가 결정론적이라고 부분적으로 문서화한 상태)가 아무런 표시도 하지 않는 상태보다 엄격하게 더 낫다고 생각합니다. 우리가하지 않는 것을 지원한다고 주장하지 않는 것입니다! 나는 결정론을 테스트하는 방법에 대해 생각하는 것이 유용한 활동이라는 데 동의하지만 이것은 분명히 비결정적 API에 플래그를 지정하는 직교 활동이라고 생각합니다.

많은 아이디어가 떠돌았기 때문에 그 중 일부에 대한 구체적인 생각을 말씀드리겠습니다.

1. "아마도 우리는 카테고리 3 기능 목록을 유지하는 것에 대해서도 생각할 수 있습니다." 이것은 많은 작업처럼 보입니다. 결정론에 대한 조정을 명시적으로 만든 함수에만 가치가 있다고 생각합니다(대부분 결정론적 플래그를 지원하는 함수).
2. "우리는 잠재적으로 모든 기능에 대한 결정성 테스트를 실행하는 CI 작업을 설정할 수 있습니다." 이와 같은 작업은 매우 신중하게 수행되어야 한다고 생각합니다. 그 이유는 본질적으로 비결정적 테스트이기 때문에 결정론 테스트 자체가 "비정상적"이기 때문입니다(때로는 통과하고 다른 것은 실패함) . 당사의 CI 보고 도구는 이와 같은 상황을 잘 처리하지 못합니다.
3. "그러나 두 번째는 조금 더 까다롭습니다. oneDNN, cuDNN 및 MAGMA와 같은 수학 라이브러리의 작업이 특히 버전과 하드웨어 전반에 걸쳐 결정론적인지 말하기 어려운지 걱정됩니다." 우리는 최선을 다해야 합니다. 많은 경우 수학 라이브러리는 문서에서 결정론적인지 여부를 명시적으로 지정하고 문서에서 말하는 내용을 충실하게 보고해야 합니다.
4. "아마도 우리는 모든 네이티브 비결정적 연산에 대해 경고하고 수학 라이브러리 호출이 있을 때 경고도 할 수 있을까요?" 나는 우리가 이것을 해서는 안된다고 생각한다. 우리가 비결정론에 대해 경고할 때, 그것은 비결정론이 일어나고 있기 때문이 아니라 일어날 수도 있기 때문이어야 합니다. 당신이 지나치게 경고하면 사람들은 경고를 무시하기 시작할 것입니다.

나는 우리가 교차 버전/하드웨어 결정론에 대해 걱정할 필요가 없다고 생각합니다. 행운을 빕니다.

우리가 비결정론에 대해 경고할 때, 그것은 비결정론이 일어나고 있기 때문이 아니라 일어날 수도 있기 때문이어야 합니다. 당신이 지나치게 경고하면 사람들은 경고를 무시하기 시작할 것입니다.

까다로워 보입니다. 예를 들어, 내가 어떤 연산을 실행 중이고 PyTorch 구현이 결정적이지만 일부 확장이 (디스패치 키, 토치 기능 등을 통해) 무엇인가를 재정의했고 지금은 모르겠습니다. 그것이 실제로 내 비결정론의 근원이라면 경고를 받지 않는 것은 어리석은 일인 것 같습니다.

그것이 실제로 내 비결정론의 근원이라면 경고를 받지 않는 것은 어리석은 일인 것 같습니다.

물론, 하지만 사용자는 또한 우리를 그들의 비결정적 속임수에 연루시키지 않을 수 있으며, 그러면 당연히 경고를 기대하지도 않을 것입니다 ;)

플래그 API가 존재하고 문서화되어 있으므로 지금 이 문제를 종료할 수 있다고 생각합니다.

@kurtamohler 멋진 작품입니다. 감사합니다.

torch.manual_seed(111) 를 사용하여 interpolation 작업을 포함하여 모든 것을 결정적으로 설정할 수 있다는 뜻입니까?

아니요. 재현성/임의성 참고 사항을 살펴보십시오.
지금까지 우리는 인프라가 있고, 비결정론에 대한 알려진 소스를 표시하고, 무슨 일이 일어나고 있는지 알 수 있도록 문서를 크게 개선했습니다.
비결정적 작업에 도달하면 여전히 운이 없지만 이제 작업하는 것이 더 합리적입니다.

특히 보간은 역방향에 대해 그다지 복잡하지 않은 커널을 작성하여 결정론적으로 만들 수 있는 것으로 보입니다.

@t-vi 안녕하세요, 이제 pytorch 1.7이 출시되고 보간 역방향 커널이 업데이트 되었습니까?

따라서 CUDA 업샘플링 커널과 역방향은 aten/src/ATen/native/cuda/UpSample* 있습니다. grep은 선형, 쌍선형, 3차형이 역방향으로 비결정적(경고 표시가 있음)을 갖지만 가장 가까운 것은 그렇지 않음을 나타냅니다.
@kurtamohler 가 훨씬 더 나은 사람이 될 것입니다.