ಸ್ಥಳೀಯ ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗಳು (Local large language models) ಆರಂಭದಲ್ಲಿ ಮಿಂಚಿನ ವೇಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂದು ಅನಿಸುತ್ತದೆ. ನೀವು 7B ಅಥವಾ 13B ಪ್ಯಾರಾಮೀಟರ್ ಮಾದರಿಯನ್ನು ಲೋಡ್ ಮಾಡಿ, ಒಂದು ಸಣ್ಣ ಪ್ರಾಂಪ್ಟ್ ನೀಡಿದಾಗ, ಟೋಕನ್‌ಗಳು ಪರದೆಯ ಮೇಲೆ ಆರಾಮದಾಯಕ ವೇಗದಲ್ಲಿ ಹರಿಯುತ್ತವೆ. ನಂತರ ನೀವು ಒಂದು ಉದ್ದವಾದ ಕೋಡ್ ಬ್ಲಾಕ್ ಅನ್ನು ಪೇಸ್ಟ್ ಮಾಡಿದಾಗ ಅಥವಾ ನಿಮ್ಮ ಚಾಟ್ ಇತಿಹಾಸವು ಹನ್ನೆರಡು ಸುತ್ತುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಬೆಳೆದಾಗ, ಮಾದರಿಯ ವೇಗವು ಕುಸಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಈ ವೇಗ ಕುಸಿತವು ಸಾಮಾನ್ಯವಾಗಿ ನಿಧಾನವಾಗಿ ಆಗುವುದಿಲ್ಲ. ಇದು ಒಂದು ಕಡಿದಾದ ಪ್ರಪಾತದಂತೆ ಇರುತ್ತದೆ. ಒಂದು ಕ್ಷಣ GPU ಟೋಕನ್‌ಗಳನ್ನು ವೇಗವಾಗಿ ಉತ್ಪಾದಿಸುತ್ತಿರುತ್ತದೆ; ಮರುಕ್ಷಣವೇ, ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಮಾನಿಟರ್ ಮೆಮೊರಿ ಒತ್ತಡ (memory pressure) ಹೆಚ್ಚಾಗುತ್ತಿರುವುದನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಜನರೇಷನ್ (generation) ಅಸ್ತವ್ಯಸ್ತವಾಗಿ ನಿಧಾನವಾಗುತ್ತದೆ. ಇದನ್ನು ಯಾವಾಗ ನಿಖರವಾಗಿ ಉಂಟುಮಾಡಬಹುದು ಎಂದು ಯಾವುದೇ ಸರಳ ಸೂತ್ರದ ಮೂಲಕ ಮುನ್ಸೂಚಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಿಮ್ಮ ಏಕೈಕ ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗದರ್ಶಿ ಎಂದರೆ ಹಾರ್ಡ್‌ವೇರ್ ಮಾತ್ರ.

ಕಾನ್ಟೆಕ್ಸ್ಟ್‌ನ (Context) ಅಡಗಿರುವ ವೆಚ್ಚ

ನೀವು ಉತ್ಪಾದಿಸುವ ಪ್ರತಿಯೊಂದು ಟೋಕನ್ KV cache ಗೆ ಸ್ಟೇಟ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ಈ ಕ್ಯಾಶ್ (cache) ಪ್ರಿಫಿಲ್ (prefill) ಮತ್ತು ಜನರೇಷನ್ ಹಂತಗಳಲ್ಲಿ ಲೆಕ್ಕಹಾಕಲಾದ ಕೀಗಳು (keys) ಮತ್ತು ವ್ಯಾಲ್ಯೂಗಳನ್ನು (values) ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ನಿಮ್ಮ ಮಾಡೆಲ್ ತೂಕಗಳು (model weights), ಅಟೆನ್ಷನ್ ಬಫರ್‌ಗಳು (attention buffers) ಮತ್ತು ರನ್‌ಟೈಮ್ ಓವರ್‌ಹೆಡ್‌ನೊಂದಿಗೆ ಮೆಮೊರಿಯಲ್ಲಿ ಇರುತ್ತದೆ. 12 GB ಅಥವಾ 16 GB VRAM ಹೊಂದಿರುವ ಸಾಮಾನ್ಯ ಕನ್ಸ್ಯೂಮರ್ GPU ನಲ್ಲಿ, KV cache ಅಂತಿಮವಾಗಿ ಉಳಿದ ಎಲ್ಲದರೊಂದಿಗೆ ಜಾಗಕ್ಕಾಗಿ ಸ್ಪರ್ಧಿಸುತ್ತದೆ. ಮೀಸಲಾದ ವಿಡಿಯೋ ಮೆಮೊರಿ ತುಂಬಿದಾಗ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಯಾವುದೇ ದೋಷವನ್ನು (error) ತೋರಿಸಿ ನಿಲ್ಲುವುದಿಲ್ಲ. ಅದು ಮೌನವಾಗಿ ಅತಿಯಾದ ಡೇಟಾವನ್ನು ಶೇರ್ಡ್ ಮೆಮೊರಿ (shared memory) ಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ, PCIe ಬಸ್ ಮೂಲಕ GPU ಮತ್ತು ಸಿಸ್ಟಮ್ RAM ನಡುವೆ ಡೇಟಾವನ್ನು ಸಾಗಿಸುತ್ತದೆ. ಆ ಬಸ್ ಫೈಲ್ ವರ್ಗಾವಣೆಗಳಿಗೆ ವೇಗವಾಗಿದ್ದರೂ, ಗ್ರಾಫಿಕ್ಸ್ ಕಾರ್ಡ್‌ನ ಒಳಗಿನ ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ (memory bandwidth) ಗೆ ಹೋಲಿಸಿದರೆ ಅದು ಅತ್ಯಂತ ನಿಧಾನವಾಗಿದೆ. ಇದರ ಪರಿಣಾಮವು ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿನ ಸಣ್ಣ ಕುಸಿತವಲ್ಲ; ಬದಲಾಗಿ ಅದು ಸಂಪೂರ್ಣ ಕುಸಿತವಾಗಿದೆ.

ಪ್ರಪಾತವು ಬಂದಿದೆ ಎಂದು ತಿಳಿಸುವ ಮೂರು ಸಂಕೇತಗಳು

ಮಾದರಿಯು ಚಾಲನೆಯಲ್ಲಿದ್ದಾಗ ನಿಮ್ಮ ಹಾರ್ಡ್‌ವೇರ್ ಮಾನಿಟರ್‌ಗಳನ್ನು ಗಮನಿಸಿ. ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುಸಿತವು ಸಂಭವಿಸಿದ ತಕ್ಷಣ ನೀವು ಮೂರು ಸ್ಪಷ್ಟ ಸಂಕೇತಗಳನ್ನು ನೋಡಬಹುದು.

  • Shared VRAM ಏರಿಕೆಯಾಗುತ್ತದೆ. ಇದು GPU ಡ್ರೈವರ್ ಮೀಸಲಾದ ವಿಡಿಯೋ RAM ನಿಂದ ಹೊರಹಾಕಿ, ಹೋಸ್ಟ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ನಿರ್ವಹಿಸುವ ಪೂಲ್ (pool) ಗೆ ವರ್ಗಾಯಿಸಿದ ಮೆಮೊರಿ ಆಗಿದೆ. ಈ ಮೆಟ್ರಿಕ್ ಶೂನ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಾದ ತಕ್ಷಣ, ನೀವು ಮಿತಿ ಮೀರಿರುತ್ತೀರಿ ಎಂದರ್ಥ.
  • System RAM ಬಳಕೆ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಅತಿಯಾದ ಡೇಟಾ ಎಲ್ಲಾದರೂ ಹೋಗಲೇಬೇಕು, ಮತ್ತು ಅದರ ತಾಣ ನಿಮ್ಮ ಮುಖ್ಯ ಮೆಮೊರಿ (main memory). ಮಾದರಿಯು ಟೋಕನ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುವಾಗ ನಿಮ್ಮ RAM ಬಳಕೆ ಹೆಚ್ಚಾಗುತ್ತಿದ್ದರೆ, ಡೇಟಾವನ್ನು GPU ನಿಂದ ಹೊರಹಾಕಲಾಗುತ್ತಿದೆ ಎಂದರ್ಥ.
  • Eval ವೇಗವು ಅರ್ಧ ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕುಸಿಯುತ್ತದೆ. 10% ವೇಗ ಕುಸಿತವು ಥರ್ಮಲ್ ಥ್ರೊಟಲಿಂಗ್ (thermal throttling) ಅಥವಾ ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳ (background processes) ಸೂಚನೆಯಾಗಿರಬಹುದು. ಆದರೆ 50% ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಕುಸಿತವು, bottlenecks ಟೆನ್ಸರ್ ಕೋರ್‌ಗಳಿಂದ (tensor cores) ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮತ್ತು PCIe લેಟೆನ್ಸಿಗೆ (latency) ಬದಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಜನರೇಷನ್ ವೇಗವು ದ್ವಿ ಅಂಕಿಗಳಿಂದ (double digits) ಏಕ ಅಂಕಿಗಳಿಗೆ (single digits) ಇಳಿಯುವುದನ್ನು ನೀವು ನೋಡಿದಾಗ, ನೀವು ಈಗಾಗಲೇ ಪ್ರಪಾತಕ್ಕೆ ಬಿದ್ದಿದ್ದೀರಿ ಎಂದರ್ಥ.

ನಿಮ್ಮ ಶೀಘ್ರ ಬೆಂಚ್‌ಮಾರ್ಕ್ (benchmark) ಬಹುಶಃ ಸುಳ್ಳು ಹೇಳುತ್ತಿರಬಹುದು ಏಕೆ?

ಒಂದು ಸಣ್ಣ ಪರೀಕ್ಷೆಯು ನಿಮಗೆ ತಪ್ಪು ಆತ್ಮವಿಶ್ವಾಸವನ್ನು ನೀಡಬಹುದು. ನೀವು ನೂರು ಟೋಕನ್‌ಗಳ ಪ್ರಾಂಪ್ಟ್‌ನೊಂದಿಗೆ ಮಾದರಿಯನ್ನು ಬೆಂಚ್‌ಮಾರ್ಕ್ ಮಾಡಿ, ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೋಡಿ, ಕೆಲಸ ಮುಗಿಸಿ ಎಂದು ಭಾವಿಸಿದರೆ, ನೀವು ಕೇವಲ ಆರಂಭಿಕ ಹಂತವನ್ನು (honeymoon phase) ಮಾತ್ರ ಅಳೆದಿರುತ್ತೀರಿ. ಆಗ KV cache ಬಹುತೇಕ ಖಾಲಿಯಾಗಿರುತ್ತದೆ. ಉದ್ದವಾದ ಪ್ರಿಫಿಲ್‌ನಿಂದ ಲೇಯರ್‌ಗಳ ಮೇಲೆ ಒತ್ತಡವಿರುವುದಿಲ್ಲ. ಮಾದರಿಯು ಗಣನೀಯ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡಿದ ನಂತರ ಮತ್ತು ಕ್ಯಾಶ್ ತನ್ನ ನೈಜ ಕಾರ್ಯನಿರ್ವಹಣಾ ಗಾತ್ರಕ್ಕೆ ತುಂಬಿದ ನಂತರವಷ್ಟೇ ಅದರ ನಿಜವಾದ ಪ್ರಭಾವವು ತಿಳಿಯುತ್ತದೆ. ನೀವು ದೀರ್ಘವಾದ ಪ್ರಿಫಿಲ್ ಮತ್ತು ದೀರ್ಘ ಜನರೇಷನ್ ರನ್‌ಗಳೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಬೇಕು. ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಸಂಗ್ರಹವಾಗಲು ಬಿಡಿ. ಆಗ ಮಾತ್ರ ಮೆಮೊರಿ ಒತ್ತಡವು ಸ್ಥಿರವಾಗಿ ನಿಮ್ಮ ನೈಜ ಮಿತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ.

llama.cpp ಬಳಸಿ ನಿಮ್ಮ ಮಿತಿಯನ್ನು ಕಂಡುಹಿಡಿಯುವುದು

ನೀವು llama.cpp ಮೂಲಕ ಮಾದರಿಗಳನ್ನು ರನ್ ಮಾಡುತ್ತಿದ್ದರೆ, ಸರಳ ಗಣಿತ ಮತ್ತು ತಾಳ್ಮೆಯ ಪರೀಕ್ಷೆಯ ಮೂಲಕ ನಿಮ್ಮ ಮಿತಿಯನ್ನು ಅಳೆಯಬಹುದು.

1. ಶೇರ್ಡ್ ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಅಳೆಯಿರಿ.
ಕನಿಷ್ಠ ಪ್ರಾಂಪ್ಟ್‌ನೊಂದಿಗೆ ನಿಮ್ಮ ಬೇಸ್‌ಲೈನ್ (baseline) ಮೀಸಲಾದ VRAM ಅನ್ನು ದಾಖಲಿಸಿ, ನಂತರ ದೀರ್ಘ-ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಕಾರ್ಯವನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ಅದರ ಗರಿಷ್ಠ (peak) ಮಟ್ಟವನ್ನು ಗಮನಿಸಿ. ಗರಿಷ್ಠ ಮಟ್ಟದಿಂದ ಬೇಸ್‌ಲೈನ್ ಅನ್ನು ಕಳೆಯಿರಿ. ಈ ವ್ಯತ್ಯಾಸವು ನಿಮ್ಮ GPU ನಿಂದ ಶೇರ್ಡ್ ಸಿಸ್ಟಮ್ ಮೆಮೊರಿಗೆ ವರ್ಗಾವಣೆಯಾದ ಡೇಟಾವಾಗಿದೆ.

2. ನಿಮ್ಮ RAM ವ್ಯತ್ಯಾಸವನ್ನು (delta) ಲೆಕ್ಕಹಾಕಿ.
ಸಿಸ್ಟಮ್ RAM ಗೂ ಇದೇ ರೀತಿ subtraction ಮಾಡಿ. ದೀರ್ಘ ರನ್ ಸಮಯದಲ್ಲಿನ ಗರಿಷ್ಠ RAM ನಿಂದ ನಿಮ್ಮ ಬೇಸ್‌ಲೈನ್ RAM ಅನ್ನು ಕಳೆಯಿರಿ. ಈ ಸಂಖ್ಯೆಯು ವಿಡಿಯೋ ಕಾರ್ಡ್‌ನಿಂದ ನಿಮ್ಮ ಮುಖ್ಯ ಮೆಮೊರಿಗೆ ಎಷ್ಟು ಡೇಟಾ ವರ್ಗಾವಣೆಯಾಗಿದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ತಿಳಿಸುತ್ತದೆ. ಇದು ಬಸ್ ಮೂಲಕ ಆಗುವ ಡೇಟಾ ಸೋರಿಕೆಯನ್ನು ಅಳೆಯುತ್ತದೆ.

3. Eval ವೇಗ ಕುಸಿತದ ಸಮಯವನ್ನು ಗಮನಿಸಿ.
ಮಾದರಿಯು ದೀರ್ಘ ದಾಖಲೆಯನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡಿದ ನಂತರದ ದರವನ್ನು ನಿಮ್ಮ ಬೇಸ್‌ಲೈನ್ ಟೋಕನ್‌ಗಳ ಪ್ರತಿ ಸೆಕೆಂಡ್ (tokens-per-second) ದರಕ್ಕೆ ಹೋಲಿಸಿ. ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಹೊಸದಾಗಿದ್ದಾಗ ಮಾದರಿಯು ಸೆಕೆಂಡಿಗೆ ಹದಿನೇಳು ಟೋಕನ್‌ಗಳ ವೇಗದಲ್ಲಿ ಚಲಿಸಬಹುದು, ಆದರೆ ಕ್ಯಾಶ್ ತುಂಬಿದ ನಂತರ ಸೆಕೆಂಡಿಗೆ ಕೇವಲ ಎರಡು ಟೋಕನ್‌ಗಳನ್ನು ಮಾತ್ರ ನೀಡಬಹುದು. ಆ ಹದಿನೈದು ಟೋಕನ್‌ಗಳ ಕುಸಿತವು ಎಚ್ಚರಿಕೆಯ ಸಂಕೇತವಾಗಿದೆ.

ಬ್ರೇಕಿಂಗ್ ಪಾಯಿಂಟ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು

ವಕ್ರರೇಖೆಯನ್ನು (curve) ನಿಖರವಾಗಿ ಗುರುತಿಸಲು, ಕೇವಲ ಒಂದು ಡೇಟಾ ಪಾಯಿಂಟ್‌ನಲ್ಲಿ ತೃಪ್ತಿಪಡಬೇಡಿ. 16,000 tokens, 32,000 tokens, ಮತ್ತು 65,000 tokens ನಲ್ಲಿ ಮೂರು ವಿಭಿನ್ನ ಪ್ರಯೋಗಗಳನ್ನು ಮಾಡಿ. ಎರಡು ಬಿಂದುಗಳು ಒಂದು ರೇಖೆಯನ್ನು ಸೂಚಿಸಬಹುದು, ಆದರೆ ಎರಡು ಚುಕ್ಕೆಗಳು ಕೇವಲ ಒಂದು ಊಹೆಯಷ್ಟೇ. ನೀವು ನೋಡುತ್ತಿರುವುದು ಅಳತೆಯ ಶಬ್ದವನ್ನು (measurement noise) ಅಥವಾ ನಿಜವಾದ ಮೆಮೊರಿ ಗೋಡೆಯನ್ನು (memory wall) ಎಂದು ಮೂರನೇ ಬಿಂದುವು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಮಾಡೆಲ್, quantization layer ಮತ್ತು GPU ನ ಸಂಯೋಜನೆಯಲ್ಲಿ ಪ್ರತಿ ಹೆಚ್ಚುವರಿ ಸಾವಿರ ಟೋಕನ್‌ಗಳು ಎಷ್ಟು ಹೆಚ್ಚುವರಿ ಮೆಮೊರಿಯನ್ನು ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಹಾಕಲು, ಪ್ರತಿಯೊಂದು ರನ್ ನಡುವಿನ ಫಲಿತಾಂಶಗಳನ್ನು ಕಳೆಯಿರಿ.

ಒಮ್ಮೆ ನಿಮಗೆ ಆ ಇಳಿಜಾರು (slope) ಸಿಕ್ಕ ನಂತರ, ನೀವು ಮುಂದಿನ ಅಂದಾಜನ್ನು ಮಾಡಬಹುದು. ನಿಮ್ಮ ಪ್ರತಿ-ಟೋಕನ್ ವೆಚ್ಚವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಅದನ್ನು ಗುರಿ ಮಾಡಲಾದ context length ನಿಂದ ಗುಣಿಸಿ, ಘಟಕಗಳ ನಡುವೆ ಬದಲಾಯಿಸಲು 1024 ರಿಂದ ಭಾಗಿಸಿ, ಮತ್ತು ಆ ಫಲಿತಾಂಶವನ್ನು ನಿಮ್ಮ ಬೇಸ್ ಮಾಡೆಲ್ VRAM ಲೋಡ್‌ಗೆ ಸೇರಿಸಿ. ಸಮೀಕರಣವು ಹೀಗಿರುತ್ತದೆ:

Model VRAM load + (tokens × memory per token ÷ 1024) = Theoretical VRAM usage

ಈ ಅಂದಾಜು ಭವಿಷ್ಯವಾಣಿಯಲ್ಲ. ಇದು ನೈಜ ವರ್ತನೆಯಿಂದ ಪಡೆದ ಮಾರ್ಗದರ್ಶಿಯಾಗಿದೆ. ಪೂರ್ಣ ಪ್ರಮಾಣದ ಪ್ರೊಡಕ್ಷನ್ ರನ್‌ಗೆ ಬದ್ಧರಾಗುವ ಮೊದಲು ನಿಮ್ಮ ಮಿತಿಯನ್ನು (ceiling) ಅಂದಾಜಿಸಲು ಇದನ್ನು ಬಳಸಿ.

ಪೇಪರ್ ಫಾರ್ಮುಲಾಗಳು ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು Quantization ಏನನ್ನು ಸರಿಪಡಿಸಬಹುದು

ಪಠ್ಯಪುಸ್ತಕದ ಫಾರ್ಮುಲಾಗಳು ಸ್ಥಳೀಯ ಇನ್ಫರೆನ್ಸ್‌ನ (local inference) ಗೊಂದಲಮಯ ವಾಸ್ತವವನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ. ವಿಭಿನ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಅಟೆನ್ಶನ್ ಬಫರ್‌ಗಳನ್ನು (attention buffers) ವಿಭಿನ್ನವಾಗಿ ಹಂಚಿಕೆ ಮಾಡುತ್ತವೆ. ನಿಮ್ಮ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಡಿಸ್‌ಪ್ಲೇ ಡ್ರೈವರ್, ಕಂಪೊಸಿಟರ್ ಮತ್ತು CUDA context ಗಾಗಿ VRAM ಅನ್ನು ಮೀಸಲಿಡುತ್ತದೆ. ಡ್ರೈವರ್ ಆವೃತ್ತಿಗಳು ಅವುಗಳು ಶೇರ್ಡ್ ಮೆಮೊರಿಯನ್ನು ಎಷ್ಟು ತೀವ್ರವಾಗಿ ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಹಲವಾರು ಟ್ಯಾಬ್‌ಗಳು ತೆರೆದಿರುವಾಗ ಮಧ್ಯಾಹ್ನ 2:00 ಗಂಟೆಗೆ ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿ ಎಷ್ಟು VRAM ನಿಜವಾಗಿಯೂ ಲಭ್ಯವಿದೆ ಎಂಬುದನ್ನು ಒಂದು ಸೈದ್ಧಾಂತಿಕ ಸಮೀಕರಣಕ್ಕೆ ತಿಳಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀವು ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಮಾಡೆಲ್ ಅನ್ನು ರನ್ ಮಾಡಬೇಕು ಮತ್ತು ಮೀಟರ್‌ಗಳನ್ನು ಗಮನಿಸಬೇಕು.

Quantization ಭಾಗಶಃ ಪರಿಹಾರವನ್ನು ನೀಡುತ್ತದೆ. KV cache ಅನ್ನು f16 ನಿಂದ q8_0 ಗೆ ವರ್ಗಾಯಿಸುವುದರಿಂದ ಅದರ ಮೆಮೊರಿ ಫುಟ್‌ಪ್ರಿಂಟ್ ಅರ್ಧದಷ್ಟು ಕಡಿಮೆಯಾಗುತ್ತದೆ ಮತ್ತು ಬಹುತೇಕ ಎಲ್ಲಾ ಪ್ರಾಯೋಗಿಕ ಕಾರ್ಯಗಳಿಗೆ ಅಗತ್ಯವಿರುವಷ್ಟು ನಿಖರತೆಯನ್ನು (precision) ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಆ ಬದಲಾವಣೆಯು ನಿಮಗೆ ಹೆಚ್ಚಿನ ಅವಕಾಶವನ್ನು (headroom) ನೀಡುತ್ತದೆ. ಆದರೆ ಅದು ಸಂಪೂರ್ಣ ರಕ್ಷಣೆ ನೀಡುವುದಿಲ್ಲ. ನೀವು ನೀಡುವ ಪ್ರತಿ ಟೋಕನ್‌ನೊಂದಿಗೆ ಕ್ಯಾಶ್ (cache) ಇನ್ನೂ ರೇಖೀಯವಾಗಿ (linearly) ಬೆಳೆಯುತ್ತದೆ. ಅಂತಿಮವಾಗಿ, ಕಡಿತಗೊಳಿಸಿದ ಗಾತ್ರವು ಸಹ ನಿಮ್ಮ ಲಭ್ಯವಿರುವ ಮೀಸಲಿಟ್ಟ ಮೆಮೊರಿಯನ್ನು ಮೀರಿತು ಮತ್ತು ಸಿಸ್ಟಮ್ RAM ಗೆ ಹರಿಯುವಿಕೆ (spillover) ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. context window ಅನ್ನು ಮಿತಿಗೊಳಿಸಿದಾಗ ಅಥವಾ ಡೇಟಾ ಚಲಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ ಮಾತ್ರ ಈ ಒತ್ತಡ ನಿಲ್ಲುತ್ತದೆ.

ನಿಜವಾದ ಸಾರಾಂಶ

ಮಾರ್ಕೆಟಿಂಗ್ ಸ್ಲೈಡ್‌ಗಳು, ಪ್ಯಾರಾಮೀಟರ್ ಸಂಖ್ಯೆಗಳು ಅಥವಾ ಕೇವಲ ಅಂದಾಜು ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ನಂಬಬೇಡಿ. ಮಾಡೆಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಿ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಮಾನಿಟರ್ ಅನ್ನು ತೆರೆಯಿರಿ. 65,000-ಟೋಕನ್ ಥ್ರೆಡ್ ಅನ್ನು ರನ್ ಮಾಡಿ, RAM ಏರುವುದನ್ನು ಗಮನಿಸಿ ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಎಷ್ಟು ಟೋಕನ್‌ಗಳು ಬರುತ್ತಿವೆ ಎಂದು ಎಣಿಸಿ. ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಸ್ಕ್ರೀನ್‌ನಲ್ಲಿ, ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ GPU ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಸಂಖ್ಯೆಗಳು ಮಾತ್ರ ಮುಖ್ಯವಾದವು. Context ಯಾವಾಗಲೂ ಗೆಲ್ಲುತ್ತದೆ. ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿ ಅದು ಯಾವಾಗ ಗೆಲ್ಲುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ತಿಳಿಯುವುದು ನಿಮ್ಮ ಕೆಲಸ.