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

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

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

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

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

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

โปรแกรม TF2 นี้สร้างการรับรู้แบบหลายชั้น (MLP) และฝึกให้จดจำภาพ MNIST ตัวอย่างนี้จงใจใช้ API ระดับต่ำของ TF2 เพื่อกำหนดโครงสร้างเลเยอร์ที่กำหนดเอง ฟังก์ชันการสูญเสีย และลูปการฝึกอบรม เนื่องจากโอกาสที่จะเกิดข้อบกพร่องของ NaN จะสูงกว่าเมื่อเราใช้ API ที่ยืดหยุ่นกว่าแต่มีแนวโน้มที่จะเกิดข้อผิดพลาดมากกว่าเมื่อเราใช้งานที่ง่ายกว่า -to-use แต่มีความยืดหยุ่นน้อยกว่าเล็กน้อย 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 หรือค่าอนันต์ อย่างไรก็ตาม เราจะยืนยันได้อย่างไรว่าเป็นเช่นนั้นจริงๆ และเราจะค้นหาการดำเนินการ TensorFlow (op) ที่รับผิดชอบในการสร้างความไม่เสถียรเชิงตัวเลขได้อย่างไร เพื่อตอบคำถามเหล่านี้ เรามาติดตั้งโปรแกรมบั๊กกี้ด้วย 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) ของเหตุการณ์เหล่านั้น . ข้อมูลการแก้ไขข้อบกพร่องที่สมบูรณ์ทำให้ผู้ใช้สามารถจำกัดข้อบกพร่องที่คลุมเครือให้แคบลงได้

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 ที่พบน้อยกว่า):

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

โหมด "FULL_HEALTH" เหมาะสำหรับการดีบักข้อบกพร่องที่เกี่ยวข้องกับ NaN และอนันต์ ดูด้านล่างสำหรับ tensor_debug_mode อื่นๆ ที่รองรับ

อาร์กิวเมนต์ circular_buffer_size ควบคุมจำนวนเหตุการณ์เทนเซอร์ที่บันทึกไว้ใน logdir โดยค่าเริ่มต้นอยู่ที่ 1,000 ซึ่งทำให้เทนเซอร์ 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

GUI Debugger V2 ใน TensorBoard ได้รับการจัดระเบียบออกเป็นหกส่วน:

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

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

Debugger V2: การแจ้งเตือน Nan / Infinity และรายการการดำเนินการกราฟ

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

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

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

เรากำลังเข้าใกล้การแก้ไขข้อบกพร่องมากขึ้น แต่ยังไม่ค่อยเสร็จสิ้น ในการใช้การแก้ไข เราจำเป็นต้องทราบว่า 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 ที่เรากำลังพยายามแก้ไขจุดบกพร่อง) การคลิก "บรรทัด 216" จะแสดงมุมมองของบรรทัดโค้ดที่เกี่ยวข้องในส่วนซอร์สโค้ด

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

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

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

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

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

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

ความเข้ากันได้ของฮาร์ดแวร์ของ 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 จะว่างเปล่าสำหรับ logdirs การดีบักที่สร้างโดยโปรแกรม 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 โหมด บน CPU โอเวอร์เฮดจะลดลงเล็กน้อย บน TPU ค่าใช้จ่ายในปัจจุบันจะสูงกว่า

ความสัมพันธ์กับ API การดีบัก TensorFlow อื่นๆ

โปรดทราบว่า TensorFlow มีเครื่องมือและ API อื่นๆ สำหรับการแก้ไขข้อบกพร่อง คุณสามารถเรียกดู API ดังกล่าวได้ภายใต้ เนมสเปซ tf.debugging.* ได้ที่หน้าเอกสาร 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