Google ನ Tunix ವ್ಯವಸ್ಥೆಯು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಏಜೆಂಟಿಕ್ ರಿಇನ್‌ಫೋರ್ಸ್‌ಮೆಂಟ್ ಲರ್ನಿಂಗ್ (RL) ಅನ್ನು TPUs ಅನ್ನು ಸಮರ್ಥವಾಗಿ ಬಳಸದಂತೆ ತಡೆಹಿಡಿಯುತ್ತಿದ್ದ ಅಡಚಣೆಯನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಇಂಟರಾಕ್ಷನ್ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸುವ ಕೆಲಸ ಮತ್ತು ಪಾಲಿಸಿಯನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುವ ಕೆಲಸವನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಮೂಲಕ, Tunix TPU ಬಳಕೆಯ ಪ್ರಮಾಣವನ್ನು ಏಕ ಅಂಕಿಗಳ ಶೇಕಡಾವಾರು ಮಟ್ಟದಿಂದ ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯದ ಹತ್ತಿರಕ್ಕೆ ಏರಿಸುತ್ತದೆ, ಇದರಿಂದ ಕಂಪ್ಯೂಟ್ ವ್ಯರ್ಥವಾಗುವುದನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಏಜೆಂಟಿಕ್ RL ನಲ್ಲಿನ ಬಾಟಲ್ ನೆಕ್ (bottleneck)

Agentic RL ಎಂಬುದು ಹೆಚ್ಚು ಪರಿಚಿತವಾದ "ನೆಕ್ಸ್ಟ್-ಟೋಕನ್" ಭಾಷಾ ಮಾದರಿ ತರಬೇತಿಯಿಂದ ಭಿನ್ನವಾಗಿದೆ. ಏಜೆಂಟ್ ಒಂದು API ಕಾಲ್‌ಗಳನ್ನು ಕಳುಹಿಸಬೇಕು, ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು ಅಥವಾ ಸಿಮ್ಯುಲೇಟೆಡ್ ಎನ್ವಿರಾನ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು, ನಂತರ ಅದರ ಫಲಿತಾಂಶಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು. ಆದ್ದರಿಂದ ತರಬೇತಿ ಲೂಪ್ (training loop) ಸಿಂಕ್ರೋನಸ್ ಆಗಿರುತ್ತದೆ: ಮಾದರಿಯು ಒಂದು ಕ್ರಿಯೆಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಎನ್ವಿರಾನ್‌ಮೆಂಟ್ ಚಲಿಸುತ್ತದೆ, ಫಲಿತಾಂಶವು ಹಿಂತಿರುಗುತ್ತದೆ ಮತ್ತು ನಂತರವೇ ಮಾದರಿಯು ಗ್ರೇಡಿಯಂಟ್ ಅಪ್‌ಡೇಟ್ ಅನ್ನು ಪಡೆಯುತ್ತದೆ. ಒಂದು ಎನ್ವಿರಾನ್‌ಮೆಂಟ್ ಹಂತವು ಹಲವಾರು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಾಗ, ದುಬಾರಿ TPU ಹಾರ್ಡ್‌ವೇರ್ ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತದೆ ಮತ್ತು ವರದಿಯಾದ ಬಳಕೆಯ ಪ್ರಮಾಣವು 10% ಕ್ಕಿಂತ ಕೆಳಗೆ ಇಳಿಯಬಹುದು. ಈ ಅಸಮರ್ಥತೆಯು ನೇರವಾಗಿ ಹೆಚ್ಚಿನ ಕ್ಲೌಡ್ ಬಿಲ್‌ಗಳು ಮತ್ತು ನಿಧಾನಗತಿಯ ಸಂಶೋಧನಾ ಚಕ್ರಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

Tunix ನ ಡಿ ಕಪ್ಲ್ಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ (decoupled architecture)

Tunix ಎರಡು ಹಂತಗಳನ್ನು—ಟ್ರ್ಯಾಜೆಕ್ಟರಿ ಜನರೇಷನ್ ಮತ್ತು ಪಾಲಿಸಿ ಆಪ್ಟಿಮೈಸೇಶನ್—ಪ್ರತ್ಯೇಕ ಹಾರ್ಡ್‌ವೇರ್ ಪೂಲ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

  • ಅಸಿಂಕ್ರೋನಸ್ ಆಕ್ಟರ್ಸ್ (Asynchronous actors) ಅಗ್ಗದ CPU ಅಥವಾ GPU ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಪ್ರತಿಯೊಬ್ಬ ಆಕ್ಟರ್ ತನ್ನ ನಿಯೋಜಿತ ಎನ್ವಿರಾನ್‌ಮೆಂಟ್‌ನೊಂದಿಗೆ ನಿರಂತರವಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತಾ, ಕ್ರಿಯೆಗಳು ಮತ್ತು ವೀಕ್ಷಣೆಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಮತ್ತು ಉಂಟಾಗುವ ಟ್ರ್ಯಾಜೆಕ್ಟರಿಗಳನ್ನು ಹಂಚಿಕೆಯ ಸ್ಟೋರ್‌ಗೆ ಸ್ಟ್ರೀಮ್ ಮಾಡುತ್ತದೆ.
  • ಕಂಟಿನ್ಯೂಯಸ್ ಲರ್ನರ್ಸ್ (Continuous learners) ಮೀಸಲಾದ TPU Pod ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಲರ್ನರ್ ಕೇಂದ್ರ ಬಫರ್‌ನಿಂದ ಬ್ಯಾಚ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಒಂದೇ ಆಕ್ಟರ್ ತನ್ನ ರೋಲ್‌ಔಟ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸುವವರೆಗೆ ಕಾಯದೆ ಗ್ರೇಡಿಯಂಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಮಾಡುತ್ತದೆ.
  • ಹೈ-ಥ್ರೂಪುಟ್ ಬಫರ್ (High-throughput buffer) ಮಧ್ಯದಲ್ಲಿ ಇರುತ್ತದೆ, ಇದು ಟ್ರ್ಯಾಜೆಕ್ಟರಿಗಳಿಗಾಗಿ ಸ್ಟೇಜಿಂಗ್ ಏರಿಯಾ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಲರ್ನರ್ ಬಫರ್ ಡೇಟಾವನ್ನು ಪೂರೈಸುವ ವೇಗದಲ್ಲಿಯೇ ಓದಬಲ್ಲದಾಗಿರುವುದರಿಂದ, TPU ಎಂದಿಗೂ ನಿಲ್ಲುವುದಿಲ್ಲ.

ಇದರ ಒಟ್ಟು ಪರಿಣಾಮವೆಂದರೆ TPUs ಬಹುತೇಕ ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಕಾರ್ಯನಿರತವಾಗಿರುವ ತರಬೇತಿ ಪೈಪ್‌ಲೈನ್ ಆಗಿದ್ದು, ಬಳಕೆಯನ್ನು 100% ಕಡೆಗೆ ತಳ್ಳುತ್ತದೆ.

ತಾಂತ್ರಿಕ ಸವಾಲುಗಳು ಮತ್ತು Tunix ಅವುಗಳನ್ನು ಹೇಗೆ ಎದುರಿಸುತ್ತದೆ

ಬದಲಾಗುವ ಉದ್ದದ ಎಪಿಸೋಡ್‌ಗಳು ಮತ್ತು XLA ರೀಕಂಪೈಲೇಶನ್ (recompilation)

JAX ನ XLA ಕಂಪೈಲರ್ ಸ್ಥಿರ ಟೆನ್ಸರ್ ಶೇಪ್‌ಗಳಿಗಾಗಿ (fixed tensor shapes) ಆಪ್ಟಿಮೈಸ್ ಮಾಡುತ್ತದೆ. ಆದರೆ, ಏಜೆಂಟಿಕ್ ಕಾರ್ಯಗಳು ವಿಭಿನ್ನ ಉದ್ದದ ಸರಣಿಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ದುಬಾರಿ ರೀಕಂಪೈಲೇಶನ್‌ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. Tunix ಚಿಕ್ಕ ಸರಣಿಗಳನ್ನು ಒಟ್ಟಿಗೆ ಪ್ಯಾಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಮಾನ ಉದ್ದದ ಎಪಿಸೋಡ್‌ಗಳನ್ನು ಬಕೆಟ್‌ಗಳಾಗಿ ಗುಂಪು ಮಾಡುತ್ತದೆ, ಇದರಿಂದ XLA ಕಂಪೈಲ್ ಮಾಡಿದ ಕರ್ನೆಲ್‌ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ಬೇಕಾದಷ್ಟು ಸಮಯದವರೆಗೆ ಶೇಪ್‌ಗಳನ್ನು ಸ್ಥಿರವಾಗಿಡುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕುಂಠಿತಗೊಳಿಸಬಹುದಾದ ಕಂಪೈಲರ್ ಓವರ್‌ಹೆಡ್ ಇಲ್ಲದೆ ಸ್ಥಿರವಾದ ಥ್ರೂಪುಟ್ ಲಭ್ಯವಾಗುತ್ತದೆ.

ಅನೇಕ TPU ಚಿಪ್‌ಗಳಾದ್ಯಂತ ಬೃಹತ್ ಮಾದರಿಗಳನ್ನು ಸ್ಕೇಲ್ ಮಾಡುವುದು

70 ಬಿಲಿಯನ್‌ನಿಂದ ಹೆಚ್ಚು ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಏಜೆಂಟ್‌ಗಳನ್ನು ತರಬೇತಿಗೊಳಿಸಲು ಅನೇಕ TPU ನೋಡ್‌ಗಳಾದ್ಯಂತ ವೇಯ್ಟ್‌ಗಳು (weights) ಮತ್ತು ಡೇಟಾವನ್ನು ಹಂಚುವುದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. Tunix JAX ನ ShardMap ಪ್ರಿಮಿಟಿವ್ ಅನ್ನು ಬಳಸಿ ಮಾದರಿಯ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಮತ್ತು ಆಕ್ಟಿವೇಷನ್‌ಗಳನ್ನು ಎರಡನ್ನೂ ಶಾರ್ಡ್ (shard) ಮಾಡುತ್ತದೆ, ಇದು ಲರ್ನರ್‌ಗೆ ಇಡೀ ಮಾದರಿಯನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಇರಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ವೇಗದಲ್ಲಿ ಡೇಟಾವನ್ನು ಪೂರೈಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಈ ಶಾರ್ಡಿಂಗ್ ತಂತ್ರವು ಈ ಹಿಂದೆ ಒಂದೇ TPU ಪಾಡ್‌ನಲ್ಲಿ ತರಬೇತಿಗೊಳಿಸಲು ಅಸಾಧ್ಯವಾಗಿದ್ದ ಮಾದರಿಗಳನ್ನು ತರಬೇತಿಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

ಡಿ ಕಪ್ಲ್ಡ್ ಪೈಪ್‌ಲೈನ್‌ಗಳಿಂದ ಹಳೆಯದಾದ (stale) ಗ್ರೇಡಿಯಂಟ್‌ಗಳು

ಆಕ್ಟರ್‌ಗಳು ಲರ್ನರ್‌ನಿಗಿಂತ ಮುಂದೆ ಚಲಿಸಿದಾಗ, ಅವು ಪೂರೈಸುವ ಡೇಟಾ ಪ್ರಸ್ತುತ ಪಾಲಿಸಿಗೆ ಹೋಲಿಸಿದರೆ "ಹಳೆಯದಾದ" (stale) ಆಗಿರಬಹುದು. Tunix ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಎರಡು ವಿಧಾನಗಳ ಮೂಲಕ ತಗ್ಗಿಸುತ್ತದೆ: ಇಂಪಾರ್ಟೆನ್ಸ್-ಸ್ಯಾಂಪ್ಲಿಂಗ್ (importance-sampling) ಹಳೆಯ ಮಾದರಿಗಳ ಪ್ರಸ್ತುತತೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸಲು ಅವುಗಳನ್ನು ರೀವೈಟ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಕಾನ್ಫಿಗರಬಲ್ ಸ್ಟೇಲ್ನೆಸ್ ಥ್ರೆಶೋಲ್ಡ್ (staleness threshold) ನಿಗದಿತ ವಯಸ್ಸನ್ನು ಮೀರಿದ ಟ್ರ್ಯಾಜೆಕ್ಟರಿಗಳನ್ನು ಕೈಬಿಡುತ್ತದೆ. ಇವೆರಡೂ ಒಟ್ಟಾಗಿ ಪೈಪ್‌ಲೈನ್ ಅಸಿಂಕ್ರೋನಸ್ ಆಗಿ ಚಲಿಸಿದರೂ ಕಲಿಕೆಯನ್ನು ಸ್ಥಿರವಾಗಿಡುತ್ತವೆ.

ಅಳವಡಿಸಿಕೊಳ್ಳುವವರು ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು

  • ಲೇಟೆನ್ಸಿ ಆಡಿಟ್ (Latency audit) – ಡಿ ಕಪ್ಲಿಂಗ್‌ನ ಪ್ರಯೋಜನವು ಎನ್ವಿರಾನ್‌ಮೆಂಟ್‌ನ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ತಂಡಗಳು ಎಂಡ್-ಟು-ಎಂಡ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಅಳೆಯಬೇಕು ಮತ್ತು ಬಫರ್ ಅನ್ನು ಚೆನ್ನಾಗಿ ತುಂಬಿಸಿಕೊಳ್ಳಲು ಆಕ್ಟರ್ ಪೂಲ್‌ಗಳ ಗಾತ್ರವನ್ನು ಸರಿಯಾಗಿ ನಿರ್ಧರಿಸಬೇಕು.
  • ವರ್ಕರ್ ಪೂಲ್ ವಿನ್ಯಾಸ (Worker pool design) – ಅಗ್ಗದ CPU ಅಥವಾ GPU ಗಳು ಅನೇಕ ಆಕ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ಆದರೆ ಅವುಗಳನ್ನು ಅತಿಯಾಗಿ ಬಳಸುವುದರಿಂದ (oversubscribing) ನೆಟ್‌ವರ್ಕ್ ಅಥವಾ ಸ್ಟೋರೇಜ್‌ನಲ್ಲಿ ಸಂಘರ್ಷ ಉಂಟಾಗಬಹುದು. ಬಫರ್‌ನ ಇಂಜೆಸ್ಟ್ ರೇಟ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಸಮತೋಲಿತ ಪೂಲ್ ಅತ್ಯಗತ್ಯ.
  • ಬಫರ್‌ನ ದೃಢತೆ (Buffer robustness) – ಕೇಂದ್ರ ಸ್ಟೋರ್ ಹೊಸ ಬಾಟಲ್ ನೆಕ್ ಆಗಿ ಪರಿಣಮಿಸದೆ ಹೆಚ್ಚಿನ ಬರೆಯುವ (write) ಮತ್ತು ಓದುವ (read) ದರಗಳನ್ನು ನಿಭಾಯಿಸಬೇಕು. ಕಡಿಮೆ ಟೇಲ್ ಲೇಟೆನ್ಸಿ (tail latency) ಮತ್ತು ಸಾಕಷ್ಟು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಹೊಂದಿರುವ ಸ್ಟೋರೇಜ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿದೆ.

ಸಂಭಾವ್ಯ ಅನಾನುಕೂಲಗಳು

ವಿಭಜಿತ ಆರ್ಕಿಟೆಕ್ಚರ್ ಹೆಚ್ಚಿನ ಘಟಕಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ: ಪ್ರತ್ಯೇಕ ಹಾರ್ಡ್‌ವೇರ್ ಫ್ಲೀಟ್‌ಗಳು, ಒಂದು ಪರ್ಸಿಸ್ಟೆಂಟ್ ಬಫರ್ ಮತ್ತು ಸ್ಟೇಲ್ನೆಸ್ ಮಿತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸಲು ಸಮನ್ವಯ ತರ್ಕ (coordination logic).

ಸಾರಾಂಶ (Takeaway)

ಏಜೆಂಟಿಕ್ RL ನಲ್ಲಿನ ಪ್ರಮುಖ ವೆಚ್ಚವು ಮಾದರಿಯಲ್ಲಲ್ಲ, ಬದಲಾಗಿ ಸಿಂಕ್ರೋನಸ್ ಇಂಟರಾಕ್ಷನ್ ಲೂಪ್‌ಗಳಿಂದ ಉಂಟಾಗುವ ನಿಷ್ಕ್ರಿಯ ಸಮಯ ಎಂಬುದನ್ನು Tunix ತೋರಿಸುತ್ತದೆ. ರೋಲ್‌ಔಟ್ ಕೆಲಸವನ್ನು ಅಗ್ಗದ ಹಾರ್ಡ್‌ವೇರ್‌ಗೆ ವರ್ಗಾಯಿಸುವ ಮೂಲಕ ಮತ್ತು ಹೈ-ಥ್ರೂಪುಟ್ ಬಫರ್‌ನಿಂದ ನಿರಂತರವಾಗಿ ಕಲಿಯುವ TPU ಪಾಡ್‌ಗೆ ಡೇಟಾವನ್ನು ಪೂರೈಸುವ ಮೂಲಕ, Google 10% ಕ್ಕಿಂತ ಕಡಿಮೆ ಬಳಕೆಯ ಸಮಸ್ಯೆಯನ್ನು ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯದ ವರ್ಕ್‌ಫ್ಲೋ ಆಗಿ ಪರಿವರ್ತಿಸಿದೆ.