1. 모든 파일은 google cloud storage 로부터 불러와야 한다 (참고1).

2. TPU 에서 학습시킬 네트워크는 정적이며 명시적인 shape 을 가지고 있어야 한다 (참고2). 텐서플로우는 자동으로 정적 그래프를 만들어주지만, 프로그래머는 배치 차원에 대해서는 특히 더 신경써 주어야 한다.

   

   모델을 설계할 때 모든 사이즈를 미리 정해 두어야 한다는 것은 아니다. None shape 으로 모델을 만들어 두고, 런타임에 사이즈를 추론해도 상관없다. 하지만 한번 정해진 뒤 변하면 안된다.

3. TPU 에서 학습시킬 때 데이터 파이프라인은 tf.data.Dataset 을 사용하여야 하며, 이때, py_function 과 numpy_function 을 사용해서는 안 된다 (참고3).

4. Compile-time constant 를 주의해야 한다 (참고4).

XLA 가 운영하지 못하는 연산에는 어떤 것이 있을까? 내가 TPU 구현체를 만드는 과정에서 어려웠던 점이 바로 이것과 관련이 있지는 않을까?

to

1. ‣

참고

1. 일반적인 오류 디버깅.로컬 파일 시스템을 사용할 수 없는 경우. TPU 는 GCS 에서 접근할 때에만 사용이 가능하다. os, sys 대신 tf.io 를 사용하면 간단하게 GCS 에 접근할 수 있다.
2. TPU 는 명시적인 (explicit) size 를 요구한다. 아키텍쳐상 그럴수밖에 없는 것 같다. (모델을 설계할 때 모든 사이즈를 미리 정해 두어야 한다는 것은 아니다. None shape 으로 모델을 만들어 두고, 런타임에 사이즈를 추론해도 상관없긴 하다만 학습을 하면서 사이즈가 변할 수 없고, 차원의 개수는 일치해야 한다는 사실은 자명하다.) 이것은 batch dimension 에도 동일하게 적용되며, 그렇기 때문에 drop remainder 을 시켜야 한다고 말하고 있다. tpu 를 사용할 때에는 drop remainder 옵션이 중요하다. (drop_remainder is important on TPU, batch size must be fixed.)
3. TPU 를 사용하기 위해서는 py_function 이 존재해서는 안 된다. (원문 : ... as it (dataset) uses py_function underneath which is incompatible with cloud tpu ...) 그리고 미리 그 변환을 한 다음 TFRecord 파일로 변환해서 저장해 두었다가 로드해 사용하라고 권장하고 있다. 이말은 곧 python 순수 연산에 의존하지 말고 모든 연산을 tensorflow ops 로 짜넣으라는 말이 된다.
4. deer.a7.3_5_3. title: TPU 에서 일부 레이어(e.g.랜덤) 는 compile-time constant 라는 문제를 일으킬 수 있다.