บันทึกวันที่! Google I / O ส่งคืนวันที่ 18-20 พฤษภาคม ลงทะเบียนตอนนี้
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

การดีบักปัญหาเชิงตัวเลขในโปรแกรม TensorFlow โดยใช้ TensorBoard Debugger V2

เหตุการณ์ภัยพิบัติที่เกี่ยวข้องกับ NaN บางครั้งอาจเกิดขึ้นในระหว่างโปรแกรม TensorFlow ซึ่งทำให้กระบวนการฝึกอบรมแบบจำลองถูกทำลาย สาเหตุของเหตุการณ์ดังกล่าวมักไม่ชัดเจนโดยเฉพาะอย่างยิ่งสำหรับแบบจำลองที่มีขนาดและความซับซ้อนที่ไม่สำคัญ เพื่อให้ง่ายต่อการแก้ไขข้อบกพร่องของโมเดลประเภทนี้ TensorBoard 2.3+ (ร่วมกับ TensorFlow 2.3+) จึงมีแดชบอร์ดเฉพาะที่เรียกว่า Debugger V2 ที่นี่เราสาธิตวิธีใช้เครื่องมือนี้โดยทำงานผ่านจุดบกพร่องจริงที่เกี่ยวข้องกับ NaN ในเครือข่ายประสาทเทียมที่เขียนด้วย TensorFlow

เทคนิคที่แสดงในบทช่วยสอนนี้ใช้ได้กับกิจกรรมการดีบักประเภทอื่น ๆ เช่นการตรวจสอบรูปร่างเทนเซอร์รันไทม์ในโปรแกรมที่ซับซ้อน บทแนะนำนี้มุ่งเน้นไปที่ NaN เนื่องจากมีความถี่ในการเกิดขึ้นค่อนข้างสูง

สังเกตจุดบกพร่อง

ซอร์สโค้ดของโปรแกรม TF2 ที่เราจะดีบักมี อยู่ใน GitHub โปรแกรมตัวอย่างยังรวมอยู่ในแพ็กเกจ tensorflow pip (เวอร์ชัน 2.3+) และสามารถเรียกใช้โดย:

python -m tensorflow.python.debug.examples.v2.debug_mnist_v2

โปรแกรม TF2 นี้สร้างการรับรู้หลายชั้น (MLP) และฝึกให้รู้จักภาพ MNIST ตัวอย่างนี้ตั้งใจใช้ API ระดับต่ำของ TF2 เพื่อกำหนดโครงสร้างเลเยอร์ที่กำหนดเองฟังก์ชันการสูญเสียและลูปการฝึกอบรมเนื่องจากความเป็นไปได้ที่จะเกิดจุดบกพร่องของ NaN จะสูงขึ้นเมื่อเราใช้ API ที่ยืดหยุ่นกว่า แต่มีโอกาสเกิดข้อผิดพลาดมากกว่าเมื่อเราใช้ง่ายกว่า ใช้งานได้ แต่มีความยืดหยุ่นน้อยกว่าเล็กน้อย API ระดับสูงเช่น tf.keras

โปรแกรมจะพิมพ์ความแม่นยำของการทดสอบหลังการฝึกแต่ละขั้นตอน เราจะเห็นในคอนโซลว่าความแม่นยำในการทดสอบติดอยู่ที่ระดับโอกาสใกล้เคียง (~ 0.1) หลังจากขั้นตอนแรก นี่ไม่ใช่วิธีที่การฝึกอบรมแบบจำลองคาดว่าจะปฏิบัติอย่างแน่นอน: เราคาดหวังว่าความแม่นยำจะค่อยๆเข้าใกล้ 1.0 (100%) เมื่อขั้นตอนเพิ่มขึ้น

Accuracy at step 0: 0.216
Accuracy at step 1: 0.098
Accuracy at step 2: 0.098
Accuracy at step 3: 0.098
...

การคาดเดาอย่างมีความรู้คือปัญหานี้เกิดจากความไม่แน่นอนของตัวเลขเช่น NaN หรือ infinity อย่างไรก็ตามเราจะยืนยันได้อย่างไรว่าเป็นกรณีนี้จริง ๆ และเราจะพบว่าการดำเนินการ TensorFlow (op) รับผิดชอบในการสร้างความไม่แน่นอนของตัวเลขได้อย่างไร เพื่อตอบคำถามเหล่านี้มาใช้โปรแกรม buggy ด้วย Debugger V2

การสร้างโค้ด TensorFlow ด้วย Debugger V2

tf.debugging.experimental.enable_dump_debug_info() คือจุดเข้า API ของ Debugger V2 เครื่องมือนี้ใช้โปรแกรม TF2 ด้วยโค้ดบรรทัดเดียว ตัวอย่างเช่นการเพิ่มบรรทัดต่อไปนี้ใกล้กับจุดเริ่มต้นของโปรแกรมจะทำให้ข้อมูลการดีบักถูกเขียนไปยังไดเร็กทอรีบันทึก (logdir) ที่ / tmp / tfdbg2_logdir ข้อมูลการดีบักครอบคลุมแง่มุมต่างๆของรันไทม์ TensorFlow ใน TF2 จะมีประวัติทั้งหมดของการดำเนินการที่กระตือรือร้นการสร้างกราฟที่ดำเนินการโดย @ tf.function การดำเนินการของกราฟค่าเทนเซอร์ที่สร้างโดยเหตุการณ์การดำเนินการตลอดจนตำแหน่งโค้ด (Python stack trace) ของเหตุการณ์ . ความสมบูรณ์ของข้อมูลการดีบักทำให้ผู้ใช้สามารถ จำกัด จุดบกพร่องที่คลุมเครือให้แคบลงได้

tf.debugging.experimental.enable_dump_debug_info(
    "/tmp/tfdbg2_logdir",
    tensor_debug_mode="FULL_HEALTH",
    circular_buffer_size=-1)

อาร์กิวเมนต์ tensor_debug_mode ควบคุมข้อมูลที่ Debugger V2 ดึงมาจากแต่ละตัวที่กระตือรือร้นหรือในกราฟ “ FULL_HEALTH” คือโหมดที่รวบรวมข้อมูลต่อไปนี้เกี่ยวกับเทนเซอร์แบบลอยตัวแต่ละชนิด (เช่น float32 ที่พบเห็นทั่วไปและ bfloat16 dtype ทั่วไปน้อยกว่า):

  • DType
  • อันดับ
  • จำนวนองค์ประกอบทั้งหมด
  • การแจกแจงองค์ประกอบแบบลอยตัวออกเป็นหมวดหมู่ต่อไปนี้: จำนวน จำกัด เชิงลบ ( - ), ศูนย์ ( 0 ), ไฟไนต์บวก ( + ), อินฟินิตี้เชิงลบ ( -∞ ), อินฟินิตี้บวก ( +∞ ) และ NaN

โหมด“ FULL_HEALTH” เหมาะสำหรับการแก้จุดบกพร่องที่เกี่ยวข้องกับ NaN และอินฟินิตี้ ดูด้านล่างสำหรับ tensor_debug_mode s ที่รองรับ

อาร์กิวเมนต์ circular_buffer_size ควบคุมจำนวนเหตุการณ์ที่บันทึกไว้ใน logdir ค่าดีฟอลต์คือ 1000 ซึ่งทำให้มีเพียง 1,000 เทนเซอร์สุดท้ายก่อนสิ้นสุดโปรแกรม TF2 ที่มีอุปกรณ์จะถูกบันทึกลงในดิสก์ ลักษณะการทำงานเริ่มต้นนี้ช่วยลดค่าใช้จ่ายในการดีบักเกอร์โดยการเสียสละความสมบูรณ์ของข้อมูลการดีบัก หากต้องการความสมบูรณ์เช่นในกรณีนี้เราสามารถปิดใช้งานบัฟเฟอร์แบบวงกลมได้โดยตั้งค่าอาร์กิวเมนต์เป็นค่าลบ (เช่น -1 ที่นี่)

ตัวอย่าง debug_mnist_v2 เรียกใช้ enable_dump_debug_info() โดยส่งแฟล็กบรรทัดคำสั่งไป ในการเรียกใช้โปรแกรม TF2 ที่มีปัญหาของเราอีกครั้งโดยเปิดใช้งานเครื่องมือการดีบักนี้ให้ทำ:

python -m tensorflow.python.debug.examples.v2.debug_mnist_v2 \
    --dump_dir /tmp/tfdbg2_logdir --dump_tensor_debug_mode FULL_HEALTH

เริ่มต้น Debugger V2 GUI ใน TensorBoard

การรันโปรแกรมด้วยเครื่องมือดีบักเกอร์จะสร้าง logdir ที่ / tmp / tfdbg2_logdir เราสามารถเริ่ม TensorBoard และชี้ไปที่ logdir ด้วย:

tensorboard --logdir /tmp/tfdbg2_logdir

ในเว็บเบราว์เซอร์ไปที่หน้าของ TensorBoard ที่ http: // localhost: 6006 ปลั๊กอิน "Debugger V2" จะไม่ทำงานโดยค่าเริ่มต้นดังนั้นให้เลือกจากเมนู "ปลั๊กอินที่ไม่ใช้งาน" ที่ด้านบนขวา เมื่อเลือกแล้วควรมีลักษณะดังนี้:

ภาพหน้าจอมุมมองแบบเต็มของ Debugger V2

การใช้ Debugger V2 GUI เพื่อค้นหาสาเหตุที่แท้จริงของ NaN

Debugger V2 GUI ใน TensorBoard แบ่งออกเป็นหกส่วน:

  • การแจ้งเตือน : ส่วนบนซ้ายนี้มีรายการเหตุการณ์ "การแจ้งเตือน" ที่ตรวจพบโดยดีบักเกอร์ในข้อมูลการดีบักจากโปรแกรม TensorFlow ที่มีเครื่องมือ การแจ้งเตือนแต่ละครั้งบ่งบอกถึงความผิดปกติบางอย่างที่ควรให้ความสนใจ ในกรณีของเราส่วนนี้จะเน้นถึงเหตุการณ์ 499 NaN / ∞ด้วยสีชมพู - แดงที่เด่นชัด นี่เป็นการยืนยันความสงสัยของเราที่ว่าแบบจำลองล้มเหลวในการเรียนรู้เนื่องจากมี NaN และ / หรือ infinities อยู่ในค่าเทนเซอร์ภายใน เราจะเจาะลึกการแจ้งเตือนเหล่านี้ในไม่ช้า
  • Python Execution Timeline : นี่คือครึ่งบนของส่วนตรงกลางด้านบน นำเสนอประวัติทั้งหมดของการดำเนินการอย่างกระตือรือร้นของการดำเนินการและกราฟ แต่ละช่องของไทม์ไลน์จะถูกทำเครื่องหมายด้วยตัวอักษรเริ่มต้นของชื่อ op หรือกราฟ (เช่น "T" สำหรับ "TensorSliceDataset" op, "m" สำหรับ tf.function "model" tf.function ) เราสามารถนำทางไทม์ไลน์นี้ได้โดยใช้ปุ่มนำทางและแถบเลื่อนเหนือไทม์ไลน์
  • การดำเนินการกราฟ : อยู่ที่มุมขวาบนของ GUI ส่วนนี้จะเป็นศูนย์กลางของงานดีบักของเรา มันมีประวัติของเทนเซอร์แบบ Floating-dtype ทั้งหมดที่คำนวณภายในกราฟ (กล่าวคือรวบรวมโดย @tf-function s)
  • โครงสร้างกราฟ (ครึ่งล่างของส่วนบนตรงกลาง) ซอร์สโค้ด (ส่วนล่างซ้าย) และการ ติดตามสแต็ก (ส่วนล่างขวา) จะว่างเปล่า เนื้อหาจะถูกเติมเมื่อเราโต้ตอบกับ GUI ทั้งสามส่วนนี้จะมีบทบาทสำคัญในงานการดีบักของเราด้วย

เมื่อมุ่งเน้นตัวเราไปที่องค์กรของ UI แล้วให้ทำตามขั้นตอนต่อไปนี้เพื่อไปที่ด้านล่างของสาเหตุที่ NaN ปรากฏขึ้น ขั้นแรกให้คลิกการแจ้งเตือน NaN / ∞ ในส่วนการแจ้งเตือน การดำเนินการนี้จะเลื่อนรายการของกราฟ 600 กราฟโดยอัตโนมัติในส่วนการดำเนินการของกราฟและมุ่งเน้นไปที่ # 88 ซึ่งเป็นค่าเทนเซอร์ที่มีชื่อว่า "Log: 0" ที่สร้างโดย Log (ลอการิทึมธรรมชาติ) สีแดงอมชมพูที่โดดเด่นจะเน้นองค์ประกอบ a -∞ท่ามกลางองค์ประกอบ 1,000 ชิ้นของ 2D float32 tensor นี่คือเทนเซอร์ตัวแรกในประวัติรันไทม์ของโปรแกรม TF2 ที่มี NaN หรืออินฟินิตี้ใด ๆ : เทนเซอร์ที่คำนวณก่อนที่จะไม่มี NaN หรือ∞; เทนเซอร์จำนวนมาก (ในความเป็นจริงส่วนใหญ่) ที่คำนวณหลังจากนั้นมี NaN เราสามารถยืนยันได้โดยการเลื่อนขึ้นและลงรายการการดำเนินการกราฟ ข้อสังเกตนี้ให้คำแนะนำที่ชัดเจนว่า Log op เป็นที่มาของความไม่เสถียรของตัวเลขในโปรแกรม TF2 นี้

ดีบักเกอร์ V2: การแจ้งเตือนน่าน / อินฟินิตี้และรายการการดำเนินการของกราฟ

เหตุใด Log op นี้จึงคาย a -∞ออกมา? การตอบคำถามนั้นจำเป็นต้องมีการตรวจสอบข้อมูลที่ป้อนไปยังหน่วยงาน การคลิกที่ชื่อของเทนเซอร์ (“ Log: 0”) จะแสดงภาพที่เรียบง่าย แต่ให้ข้อมูลเกี่ยวกับพื้นที่ใกล้เคียงของ Log op ในกราฟ TensorFlow ในส่วนโครงสร้างกราฟ สังเกตทิศทางจากบนลงล่างของการไหลของข้อมูล ตัว op จะแสดงเป็นตัวหนาตรงกลาง ด้านบนเราจะเห็นตัวยึดพื้นที่ให้ข้อมูลป้อน Log op เพียงรายการเดียว ค่าเทนเซอร์ที่สร้างโดยบันทึกนี้ตัวยึดตำแหน่งในรายการการดำเนินการกราฟอยู่ที่ไหน ด้วยการใช้สีพื้นหลังสีเหลืองเป็นตัวช่วยในการมองเห็นเราจะเห็นว่า logits:0 tensor คือสองแถวเหนือ Log:0 tensor นั่นคือในแถว 85

ดีบักเกอร์ V2: มุมมองโครงสร้างกราฟและการติดตามเพื่อป้อนค่าเทนเซอร์

การดูรายละเอียดเชิงตัวเลขของ "logits: 0" อย่างระมัดระวังมากขึ้นในแถว 85 จะแสดงให้เห็นว่าเหตุใด Consumer Log:0 สร้าง a -∞: ใน 1,000 องค์ประกอบของ "logits: 0" หนึ่งองค์ประกอบมีค่าเป็น 0 -∞เป็นผลมาจากการคำนวณลอการิทึมธรรมชาติของ 0! หากเราสามารถมั่นใจได้ว่า Log op ได้รับเฉพาะอินพุตที่เป็นบวกเราจะสามารถป้องกันไม่ให้ NaN / ∞เกิดขึ้นได้ สิ่งนี้สามารถทำได้โดยใช้การตัด (เช่นโดยใช้ tf.clip_by_value () ) บนตัวยึดล็อกเทนเซอร์

เรากำลังเข้าใกล้การแก้ไขข้อบกพร่องมากขึ้น แต่ยังไม่เสร็จสมบูรณ์ ในการใช้การแก้ไขนี้เราจำเป็นต้องทราบว่าซอร์สโค้ด Python นั้น Log op และอินพุต Placeholder มาจากที่ใดในซอร์สโค้ดของ Python Debugger V2 ให้การสนับสนุนชั้นหนึ่งสำหรับการติดตามการทำงานของกราฟและเหตุการณ์การดำเนินการไปยังแหล่งที่มา เมื่อเราคลิก Log:0 tensor ใน Graph Executions ส่วน Stack Trace จะถูกเติมด้วย stack trace ดั้งเดิมของการสร้าง Log op การติดตามสแต็กค่อนข้างใหญ่เนื่องจากมีเฟรมจำนวนมากจากโค้ดภายในของ TensorFlow (เช่น gen_math_ops.py และ dumping_callback.py) ซึ่งเราสามารถเพิกเฉยได้อย่างปลอดภัยสำหรับงานการดีบักส่วนใหญ่ กรอบที่สนใจคือบรรทัดที่ 216 ของ debug_mnist_v2.py (เช่นไฟล์ Python ที่เรากำลังพยายามแก้ไขจุดบกพร่อง) การคลิก“ บรรทัด 204” จะแสดงมุมมองของบรรทัดโค้ดที่เกี่ยวข้องในส่วนซอร์สโค้ด

Debugger V2: ซอร์สโค้ดและการติดตามสแต็ก

ในที่สุดสิ่งนี้จะนำเราไปสู่ซอร์สโค้ดที่สร้าง Log op ที่มีปัญหาจากอินพุตบันทึก นี่คือฟังก์ชันการสูญเสียเอนโทรปีข้ามหมวดหมู่ที่กำหนดเองของเราซึ่งตกแต่งด้วย @tf.function และด้วยเหตุนี้จึงแปลงเป็นกราฟ TensorFlow Placeholder op "logits" สอดคล้องกับอาร์กิวเมนต์อินพุตแรกของฟังก์ชันการสูญเสีย Log op ถูกสร้างขึ้นด้วยการเรียก tf.math.log () API

การแก้ไขข้อบกพร่องนี้จะมีลักษณะดังนี้:

  diff = -(labels *
           tf.clip_by_value(tf.math.log(logits), 1e-6, 1.))

มันจะแก้ไขความไม่เสถียรของตัวเลขในโปรแกรม TF2 นี้และทำให้ MLP ฝึกสำเร็จ อีกวิธีหนึ่งที่เป็นไปได้ในการแก้ไขความไม่เสถียรของตัวเลขคือการใช้ tf.keras.losses.CategoricalCrossentropy

นี่เป็นการสรุปการเดินทางของเราตั้งแต่การสังเกตข้อบกพร่องของโมเดล TF2 ไปจนถึงการเปลี่ยนแปลงโค้ดที่แก้ไขข้อบกพร่องโดยได้รับความช่วยเหลือจากเครื่องมือ Debugger V2 ซึ่งให้การมองเห็นที่สมบูรณ์ในประวัติการทำงานของโปรแกรม TF2 ที่เป็นเครื่องมือรวมถึงสรุปตัวเลข ของค่าเทนเซอร์และการเชื่อมโยงระหว่างตัวเลือกเทนเซอร์และซอร์สโค้ดดั้งเดิม

ความเข้ากันได้ของฮาร์ดแวร์ของ Debugger V2

Debugger V2 รองรับฮาร์ดแวร์การฝึกอบรมหลักรวมถึง CPU และ GPU การฝึกอบรม Multi-GPU พร้อม tf.distributed นอกจากนี้ยังรองรับ MirroredStrategy การรองรับ TPU ยังอยู่ในช่วงเริ่มต้นและต้องมีการโทร

tf.config.set_soft_device_placement(True)

ก่อนที่จะเรียก enable_dump_debug_info() มันอาจมีข้อ จำกัด อื่น ๆ ใน TPU เช่นกัน หากคุณพบปัญหาในการใช้ Debugger V2 โปรดรายงานข้อบกพร่องใน หน้าปัญหา GitHub ของเรา

ความเข้ากันได้ของ API ของ Debugger V2

Debugger V2 ถูกนำไปใช้ในระดับที่ค่อนข้างต่ำของกองซอฟต์แวร์ของ TensorFlow และด้วยเหตุนี้จึงเข้ากันได้กับ tf.keras , tf.data และ API อื่น ๆ ที่สร้างขึ้นจากระดับที่ต่ำกว่าของ TensorFlow Debugger V2 ยังเข้ากันได้กับ TF1 แบบย้อนหลังแม้ว่า Eager Execution Timeline จะว่างเปล่าสำหรับผู้บันทึกการดีบักที่สร้างโดยโปรแกรม TF1

เคล็ดลับการใช้ API

คำถามที่ถามบ่อยเกี่ยวกับ API การดีบักนี้คือที่ในโค้ด TensorFlow หนึ่งควรแทรกการเรียกเพื่อ enable_dump_debug_info() โดยทั่วไปแล้ว API ควรถูกเรียกให้เร็วที่สุดในโปรแกรม TF2 ของคุณโดยเฉพาะอย่างยิ่งหลังจากบรรทัดการนำเข้า Python และก่อนที่จะเริ่มการสร้างและดำเนินการกราฟ สิ่งนี้จะช่วยให้มั่นใจได้ว่าการดำเนินการและกราฟทั้งหมดจะครอบคลุมทั้งหมดที่ขับเคลื่อนโมเดลและการฝึกอบรมของคุณ

tensor_debug_modes ที่รองรับในปัจจุบัน ได้แก่ NO_TENSOR , CURT_HEALTH , CONCISE_HEALTH , FULL_HEALTH และ SHAPE ซึ่งแตกต่างกันไปตามจำนวนข้อมูลที่ดึงออกมาจากแต่ละเทนเซอร์และค่าใช้จ่ายด้านประสิทธิภาพของโปรแกรมที่ดีบั๊ก โปรดดู ส่วน args ของเอกสารประกอบของ enable_dump_debug_info() ]

ค่าใช้จ่ายด้านประสิทธิภาพ

API การดีบักจะแนะนำค่าใช้จ่ายด้านประสิทธิภาพให้กับโปรแกรม TensorFlow ที่มีเครื่องมือ ค่าโสหุ้ยแตกต่างกันไปตาม tensor_debug_mode ประเภทฮาร์ดแวร์และลักษณะของโปรแกรม TensorFlow แบบมีเครื่องมือ ในฐานะที่เป็นจุดอ้างอิงบน GPU โหมด NO_TENSOR จะเพิ่มค่าใช้จ่าย 15% ระหว่างการฝึก โมเดล Transformer ภายใต้ขนาดแบทช์ 64 เปอร์เซ็นต์ค่าโสหุ้ยสำหรับ tensor_debug_modes อื่น ๆ จะสูงกว่า: ประมาณ 50% สำหรับ CURT_HEALTH , CONCISE_HEALTH , FULL_HEALTH และ SHAPE โหมด สำหรับซีพียูค่าใช้จ่ายจะต่ำกว่าเล็กน้อย ใน TPU ปัจจุบันค่าใช้จ่ายสูงกว่า

ความเกี่ยวข้องกับ API การดีบัก TensorFlow อื่น ๆ

โปรดทราบว่า TensorFlow มีเครื่องมือและ API อื่น ๆ สำหรับการดีบัก คุณสามารถเรียกดู API ดังกล่าวภายใต้ tf.debugging.* namespace ที่หน้าเอกสาร API ในบรรดา API เหล่านี้ที่ใช้บ่อยที่สุดคือ tf.print() เมื่อใดควรใช้ Debugger V2 และควรใช้ tf.print() แทนเมื่อใด tf.print() สะดวกในกรณีที่

  1. เรารู้ดีว่าจะพิมพ์เทนเซอร์ตัวไหน
  2. เรารู้ว่าตรงไหนในซอร์สโค้ดเพื่อแทรกคำสั่ง tf.print() เหล่านั้น
  3. จำนวนเทนเซอร์ดังกล่าวไม่มากเกินไป

สำหรับกรณีอื่น ๆ (เช่นการตรวจสอบค่าเทนเซอร์จำนวนมากการตรวจสอบค่าเทนเซอร์ที่สร้างโดยโค้ดภายในของ TensorFlow และค้นหาจุดเริ่มต้นของความไม่เสถียรของตัวเลขตามที่เราแสดงไว้ด้านบน) Debugger V2 เป็นวิธีที่เร็วกว่าในการดีบัก นอกจากนี้ Debugger V2 ยังให้แนวทางแบบครบวงจรในการตรวจสอบเทนเซอร์ที่กระตือรือร้นและกราฟ นอกจากนี้ยังให้ข้อมูลเกี่ยวกับโครงสร้างกราฟและตำแหน่งโค้ดซึ่งอยู่นอกเหนือความสามารถของ tf.print()

API อื่นที่สามารถใช้ในการดีบักปัญหาที่เกี่ยวข้องกับ∞และ NaN คือ tf.debugging.enable_check_numerics() ไม่เหมือนกับ enable_dump_debug_info() , enable_check_numerics() ไม่บันทึกข้อมูลการดีบักบนดิสก์ แต่เพียงตรวจสอบ∞และ NaN ระหว่างรันไทม์ TensorFlow และเกิดข้อผิดพลาดกับตำแหน่งรหัสต้นทางทันทีที่ op ใด ๆ สร้างค่าตัวเลขที่ไม่ถูกต้องดังกล่าว มีค่าใช้จ่ายด้านประสิทธิภาพที่ต่ำกว่าเมื่อเทียบกับ enable_dump_debug_info() แต่ไม่สามารถติดตามประวัติการดำเนินการของโปรแกรมได้อย่างสมบูรณ์และไม่มีอินเทอร์เฟซผู้ใช้แบบกราฟิกเช่น Debugger V2