ಕೇವಲ 3.2 GB RAM ಹೊಂದಿರುವ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ, ಕೇವಲ plain C99 ಮತ್ತು NVMe ಡ್ರೈವ್ ಬಳಸಿ 284-ಬಿಲಿಯನ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳಿರುವ language model ಅನ್ನು ನಾನು ರನ್ ಮಾಡಿದೆ. ಸಂಪೂರ್ಣ 160 GB checkpoint ಅನ್ನು ಮೆಮೊರಿಗೆ ಲೋಡ್ ಮಾಡುವ ಬದಲು, ಮಾಡೆಲ್‌ನ expert weights ಅನ್ನು stream ಮಾಡುವುದು ಇದರ ರಹಸ್ಯವಾಗಿತ್ತು. ಇದು ಅತ್ಯಂತ ದೊಡ್ಡ mixture-of-experts (MoE) ಮಾಡೆಲ್‌ಗಳನ್ನು ಸಹ ಸಾಮಾನ್ಯ ಗ್ರಾಹಕ ಹಾರ್ಡ್‌ವೇರ್‌ಗೆ ಅಳವಡಿಸಬಹುದು ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

ಇದು ಏಕೆ ಮುಖ್ಯ

Large language models (LLMs) ಕೋಡ್ ಜನರೇಷನ್, ಸಂಶೋಧನಾ ನೆರವು ಮತ್ತು ಹೆಚ್ಚಿನವುಗಳಿಗೆ ಶಕ್ತಿಯನ್ನು ನೀಡುತ್ತವೆ, ಆದರೆ ಅವುಗಳ ಗಾತ್ರವು ಬಳಕೆದಾರರನ್ನು ದುಬಾರಿ multi-GPU ಸರ್ವರ್‌ಗಳತ್ತ ಅಥವಾ ಗುಣಮಟ್ಟವನ್ನು ಕುಗ್ಗಿಸುವ ಭಾರೀ quantization ಕಡೆಗೆ ತಳ್ಳುತ್ತದೆ. ಕೆಲವು ಜಿಗಾಬೈಟ್ RAM ನೊಂದಿಗೆ 284 B-parameter MoE ಮಾಡೆಲ್ ಅನ್ನು ರನ್ ಮಾಡಬಹುದು ಎಂದು ತೋರಿಸುವುದು ಹವ್ಯಾಸಿಗಳು, ಸಣ್ಣ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳು ಮತ್ತು ಸೀಮಿತ ಬಜೆಟ್ ಹೊಂದಿರುವ ಸಂಶೋಧಕರಿಗೆ ಗುಣಮಟ್ಟವನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ state-of-the-art ಮಾಡೆಲ್‌ಗಳೊಂದಿಗೆ ಪ್ರಯೋಗ ಮಾಡಲು ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತದೆ.

ಮಾಡೆಲ್ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ಬಾಟಲ್ನೆಕ್ (bottleneck)

DeepSeek-V4-Flash ಪ್ರತಿ transformer layer ನಲ್ಲಿ 256 experts ಮೂಲಕ 284 B ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಇದರ raw checkpoint ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಸುಮಾರು 160 GB ವಿಸ್ತಾರವನ್ನು ಹೊಂದಿದ್ದು, ಇದು ಸಾಮಾನ್ಯ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿರುವ 3.2 GB RAM ಗಿಂತ ಬಹಳ ದೊಡ್ಡದಾಗಿದೆ. ಸಾಂಪ್ರದಾಯಿಕ inference ಪೈಪ್‌ಲೈನ್‌ಗಳು ಸಂಪೂರ್ಣ checkpoint ಅನ್ನು ಮೆಮೊರಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ, ಇದರಿಂದಾಗಿ RAM ಬೇಗನೆ ಖಾಲಿಯಾಗಿ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತವೆ.

Expert weights ಸ್ಟ್ರೀಮಿಂಗ್: ಮುಖ್ಯ ಪರಿಕಲ್ಪನೆ

MoE ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಪ್ರತಿ ಟೋಕನ್‌ಗಾಗಿ ಕೇವಲ ಸಣ್ಣ ಗುಂಪಿನ experts ಅನ್ನು ಮಾತ್ರ ಸಕ್ರಿಯಗೊಳಿಸುತ್ತವೆ. DeepSeek-V4-Flash ನಲ್ಲಿ, ರೂಟರ್ (router) ಪ್ರತಿ ಲೇಯರ್‌ನ 256 ರಲ್ಲಿ ಆರು experts ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಲೆಕ್ಕಾಚಾರವು ಬಳಕೆಯಲ್ಲಿಲ್ಲದ (dormant) experts ಅನ್ನು ಎಂದಿಗೂ ಸ್ಪರ್ಶಿಸದ ಕಾರಣ, inference engine ಅವುಗಳನ್ನು ಲೋಡ್ ಮಾಡುವುದನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು.

ಅನುಷ್ಠಾನವು (Implementation) checkpoint ಅನ್ನು ಒಂದು streaming source ಆಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಪ್ರಸ್ತುತ ಟೋಕನ್‌ಗೆ ಯಾವ experts ಬೇಕು ಎಂದು ರೂಟರ್ ನಿರ್ಧರಿಸಿದಾಗ, engine ಆ weight ಬ್ಲಾಕ್‌ಗಳನ್ನು NVMe ಡ್ರೈವ್‌ನಿಂದ RAM ನಲ್ಲಿರುವ LRU (least-recently-used) cache ಗೆ ಎಳೆಯುತ್ತದೆ. ಕ್ಯಾಶ್ ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಅದೇ experts ಅನ್ನು ಸತತ ಟೋಕನ್‌ಗಳಾದ್ಯಂತ ಮರುಬಳಕೆ ಮಾಡಲಾಗುತ್ತದೆ (cache hits); ಕ್ಯಾಶ್ ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದ್ದರೆ, engine ಡಿಸ್ಕ್‌ನಿಂದ ಪದೇ ಪದೇ ಓದುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಪೂರ್ಣ-ನಿಖರತೆಯ (full-precision) weights ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತಾ ಮತ್ತು ಯಾವುದೇ GPU acceleration ಅಗತ್ಯವಿಲ್ಲದೆಯೇ, ಲ್ಯಾಪ್‌ಟಾಪ್‌ನ ಮಿತಿಯೊಳಗೆ 3.23 GB ಗರಿಷ್ಠ ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು (peak memory footprint) ಇದು ಸಾಧಿಸುತ್ತದೆ.

ಅನುಷ್ಠಾನದಿಂದ ಕಲಿತ ಕಠಿಣ ಪಾಠಗಳು

1. ಸುಲಲಿತವಾದ ಔಟ್‌ಪುಟ್ (Fluent output) ಸರಿಯಾದದ್ದರ ಪುರಾವೆಯಲ್ಲ ಒಂದು ಬಗ್ ಇರುವ kernel ಇನ್ನೂ ನಂಬಲರ್ಹವಾಗಿ ಕಾಣುವ ವಾಕ್ಯಗಳನ್ನು ನೀಡಬಹುದು, ವಿಶೇಷವಾಗಿ ಮಾಡೆಲ್‌ನ ಭಾಷಾ ಮಾದರಿಗಳು ಸಂಖ್ಯಾತ್ಮಕ ದೋಷಗಳನ್ನು ಮರೆಮಾಚಿದಾಗ. ನಾನು ಪ್ರತಿಯೊಂದು 14 ನಿರ್ಣಾಯಕ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು (critical operations) ಹೊಸ PyTorch reference ನೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿದೆ ಮತ್ತು ಸಂಖ್ಯಾತ್ಮಕ ವ್ಯತ್ಯಾಸವು ಅತ್ಯಲ್ಪ ಮಿತಿಯಲ್ಲೇ ಇರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಂಡೆ. ಈ ಹಂತವನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿದ್ದರೆ, ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು ಪತ್ತೆಯಾಗದೆ ಹೋಗುತ್ತಿದ್ದವು.

2. ಹಂಚಿಕೆಯ ವೈಫಲ್ಯದ ವಿಧಾನಗಳು (Shared failure modes) ನಿಮ್ಮ ಪರೀಕ್ಷೆಗಳನ್ನು ತಪ್ಪಿಸಬಹುದು ಮೆಮೊರಿ-ಕರೆಪ್ಷನ್ ಬಗ್ (memory-corruption bug) ರೂಟಿಂಗ್ ಆಯ್ಕೆಗಳನ್ನು ಕೇವಲ ಕೆಲವು experts ಗೆ ಸೀಮಿತಗೊಳಿಸಿತು, ಇದರಿಂದಾಗಿ cache-hit rate 52% ರಿಂದ 95% ಕ್ಕೆ ಏರಿತು ಮತ್ತು ಇದು ಭಾರಿ ವೇಗವರ್ಧನೆಯ ಭ್ರಮೆಯನ್ನು ನೀಡಿತು. ಪರೀಕ್ಷಾ ಸೂಟ್ (test suite) ಒಂದೇ ಬಗ್ ಇರುವ ಕೋಡ್‌ನ ಎರಡು ಆವೃತ್ತಿಗಳನ್ನು ಹೋಲಿಕೆ ಮಾಡಿದ್ದರಿಂದ, ಈ ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ ಒಂದು ಸ್ವತಂತ್ರ reference path ಅನ್ನು ಸೇರಿಸುವುದು—ಅಂದರೆ ಪ್ರಮುಖ ಅನುಷ್ಠಾನದೊಂದಿಗೆ ಯಾವುದೇ ತರ್ಕವನ್ನು (logic) ಹಂಚಿಕೊಳ್ಳದ ಕೋಡ್—ಹಾಗೆ ಮಾಡಿದರೆ ಹಂಚಿಕೆಯ ದೋಷವು ಗಮನಕ್ಕೆ ಬಾರದೆ ಹೋಗುವುದಿಲ್ಲ.

3. ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವ ಮೊದಲು ಅಳೆಯಿರಿ ಒಂದು ಮೆಮೊರಿ ಕಾಪಿ 1 ms ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸಿ ಅದನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಸಮಯ ವ್ಯಯಿಸಿದೆ. ಪ್ರೊಫೈಲಿಂಗ್ (Profiling) ಮಾಡಿದಾಗ ಆ ಕಾರ್ಯಾಚರಣೆಯು ವಾಸ್ತವವಾಗಿ 3.6 ms ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಅಂದರೆ ಒಟ್ಟು inference ಸಮಯದ 22% ಎಂದು ತಿಳಿದುಬಂದಿತು. ಪಾಠವೇನೆಂದರೆ: ಕಾರ್ಯಕ್ಷಮತೆಗೆ ನಿರ್ಣಾಯಕವಾದ ವಿಭಾಗಗಳಿಗಾಗಿ ಎಂದಿಗೂ ಅಂತಃಪ್ರಜ್ಞೆಯನ್ನು (intuition) ಅವಲಂಬಿಸಬೇಡಿ; ನಿಖರವಾದ ಅಳತೆಯೇ ಏಕೈಕ ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗದರ್ಶಕ.

4. ಉಷ್ಣ ಪರಿಸ್ಥಿತಿಗಳು (Thermal conditions) ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ತೀವ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ "Heat-soaked" (ಬಿಸಿಯಾದ) ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳನ್ನು ರನ್ ಮಾಡಿದ್ದಾಗ, ತಂಪಾದ ಯಂತ್ರಕ್ಕಿಂತ ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವಂತೆ ಕಂಡುಬಂದಿತು. ಹೆಚ್ಚಿದ ತಾಪಮಾನವು NVMe ಡ್ರೈವ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು (throughput) ಕುಗ್ಗಿಸಿತು ಮತ್ತು CPU ಅನ್ನು ನಿಧಾನಗೊಳಿಸಿತು, ಇದು ಫಲಿತಾಂಶಗಳನ್ನು ತಪ್ಪಾಗಿ ತೋರಿಸಿತು. ನೀವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಂಕಿಅಂಶಗಳನ್ನು ಪ್ರಕಟಿಸುವಾಗ ಯಾವಾಗಲೂ ಸಿಸ್ಟಮ್‌ನ ಉಷ್ಣ ಸ್ಥಿತಿಯನ್ನು (thermal state) ದಾಖಲಿಸಿ.

ಅಂಕಿಅಂಶಗಳು ಹೇಗಿವೆ

  • ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಮಾಡೆಲ್ ಗಾತ್ರ: ~160 GB
  • ಗರಿಷ್ಠ RAM ಬಳಕೆ: 3.23 GB
  • ಪ್ರತಿ ಟೋಕನ್‌ಗೆ experts: 6 (256 ರಲ್ಲಿ)
  • Cache-hit rate: RAM ಗೆ ಅನುಗುಣವಾಗಿ ಬದಲಾಗುತ್ತದೆ; 3.2 GB ನೊಂದಿಗೆ ಇದು ಏರಿಳಿತಗೊಳ್ಳುತ್ತದೆ.
  • No quantisation: ಪೂರ್ಣ-ನಿಖರತೆಯ weights ಅನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡಲಾಗುತ್ತದೆ, ಇದರಿಂದ ಮಾಡೆಲ್ ಗುಣಮಟ್ಟವು ಉಳಿಯುತ್ತದೆ.

ಒಂದು ವೇಳೆ RAM ಬಜೆಟ್ ಸುಮಾರು 3.21 GB ಗಿಂತ ಕಡಿಮೆಯಾದರೆ, ಕ್ಯಾಶ್ ಎಂದಿಗೂ ತುಂಬುವುದಿಲ್ಲ ಮತ್ತು engine ಪ್ರತಿ ಟೋಕನ್‌ಗೆ ಸ್ಟ್ರೀಮ್ ಮಾಡುತ್ತದೆ, ಇದು ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ತೀವ್ರ ಕುಸಿತಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಮೂಲ ಕೋಡ್ (Source code) github.com/ronak-create/deepseek-v4-in-c ನಲ್ಲಿ ಲಭ್ಯವಿದೆ. ಈ ಪ್ರಯೋಗವನ್ನು ಪುನರಾವರ್ತಿಸಲು ಅಥವಾ ವಿಸ್ತರಿಸಲು ಬಯಸುವವರಿಗೆ t.me/GyaanSetuAi ನಲ್ಲಿ ಸಮುದಾಯ ಚರ್ಚಾ ಚಾನಲ್ ಇದೆ.

ಮುಖ್ಯ ಅಂಶಗಳು (Takeaway)

MoE ಮಾಡೆಲ್ ವಾಸ್ತವವಾಗಿ ಬಳಸುವ ಎಕ್ಸ್‌ಪರ್ಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಸ್ಟ್ರೀಮ್ ಮಾಡುವುದರಿಂದ, 284 ಬಿ-ಪ್ಯಾರಾಮೀಟರ್ ಹೊಂದಿರುವ LLM ಅನ್ನು ಕ್ವಾಂಟೈಸೇಶನ್ ಅಥವಾ GPU ವೇಗವರ್ಧನೆಯಿಲ್ಲದೆ ಒಂದು ಸಾಧಾರಣ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಚಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಅನೇಕರು ಬದಲಾಯಿಸಲಾಗದವು ಎಂದು ಭಾವಿಸುವ ಹಾರ್ಡ್‌ವೇರ್ ಮಿತಿಗಳನ್ನು, ಚತುರ ಡೇಟಾ ಚಲಾವಣೆ, ಕಟ್ಟುನಿಟ್ಟಿನ ಮೌಲ್ಯೀಕರಣ ಮತ್ತು ಶಿಸ್ತುಬದ್ಧ ಮಾಪನಗಳ ಮೂಲಕ ಮೀರಿச் ಹೋಗಬಹುದು ಎಂದು ಈ ಪ್ರಯೋಗವು ತೋರಿಸುತ್ತದೆ.