p99 SLAs ತಲುಪುತ್ತಲೇ ನಮ್ಮ AI API ಬಿಲ್ ಅನ್ನು ನಾನು ಅರ್ಧಕ್ಕೆ ಹೇಗೆ ಕಡಿಮೆ ಮಾಡಿದೆ
ನಮ್ಮ AI ಬಿಲ್ ತುಂಬಾ ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿತ್ತು. ನನ್ನ CFO ಇದನ್ನು ಸುಸ್ಥಿರವಲ್ಲದ ಖರ್ಚು (unsustainable burn rate) ಎಂದು ಕರೆದರು. ಆ ಸಮಯದಲ್ಲಿ, ನಾವು ಎಲ್ಲದಕ್ಕೂ GPT-4o ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೆವು. ಅದು ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು, ಆದರೆ ವೆಚ್ಚವು ತುಂಬಾ ಹೆಚ್ಚಿತ್ತು ಮತ್ತು p99 latency ಅಸ್ಥಿರವಾಗಿತ್ತು.
ನಾನು AI ಮಾಡೆಲ್ ಆಯ್ಕೆಯನ್ನು ಒಂದು ಸಿಸ್ಟಮ್ ಡಿಸೈನ್ ಸಮಸ್ಯೆಯಾಗಿ ಪರಿಗಣಿಸಲು ನಿರ್ಧರಿಸಿದೆ. ನಾನು ಕೇವಲ ಅತ್ಯುತ್ತಮ ಮಾಡೆಲ್ ಅನ್ನು ಹುಡುಕುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ನಮ್ಮ ನಿರ್ದಿಷ್ಟ SLAs ಗೆ ಅತ್ಯುತ್ತಮವಾದ ಮಾಡೆಲ್ ಅನ್ನು ಹುಡುಕಲು ಪ್ರಾರಂಭಿಸಿದೆ.
ನಾನು ಮೊದಲು ಸ್ಪಷ್ಟ ಗುರಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಿದೆ: • ಚಾಟ್ಗಾಗಿ 1.5 ಸೆಕೆಂಡ್ಗಿಂತ ಕಡಿಮೆ p99 latency • 99.9% ಲಭ್ಯತೆ (availability) • ಮಲ್ಟಿ-ರೀಜನ್ ಫೇಲ್ಓವರ್ (Multi-region failover) • 3x ಪೀಕ್ ಲೋಡ್ನ ಥ್ರೂಪುಟ್ ಸಾಮರ್ಥ್ಯ (Throughput capacity)
ಈ ಅಂಕಿಅಂಶಗಳು ಸಿಕ್ಕ ನಂತರ, ಪರಿಹಾರವು ಸ್ಪಷ್ಟವಾಯಿತು. ಪ್ರತಿ ಟೋಕನ್ಗೆ ಅಗ್ಗದ ಮಾಡೆಲ್ ಎಂದರೆ ಅದು ಯಾವಾಗಲೂ ಪ್ರೊಡಕ್ಷನ್ಗೆ ಉತ್ತಮ ಆಯ್ಕೆಯಲ್ಲ. ಒಂದು ವೇಳೆ ಅಗ್ಗದ ಮಾಡೆಲ್ ನಿಮ್ಮ latency ಅನ್ನು ಎರಡರಷ್ಟು ಹೆಚ್ಚಿಸಿದರೆ, ನೀವು ಬಳಕೆದಾರರನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.
ನಾನು ಅನೇಕ ಮಾಡೆಲ್ಗಳನ್ನು ಹೋಲಿಕೆ ಮಾಡಿದೆ. ಬೆಲೆಯ ವ್ಯತ್ಯಾಸವು ಭಾರಿ ಪ್ರಮಾಣದಲ್ಲಿತ್ತು. GPT-4o ಪ್ರತಿ ಮಿಲಿಯನ್ ಔಟ್ಪುಟ್ ಟೋಕನ್ಗಳಿಗೆ $10.00 ವೆಚ್ಚವಾಗುತ್ತದೆ. GLM-4 Plus ಗೆ $0.80 ವೆಚ್ಚವಾಗುತ್ತದೆ. ಸಾರಾಂಶ (summarization) ಮತ್ತು ಎಕ್ಸ್ಟ್ರಾಕ್ಷನ್ (extraction) ನಂತಹ ನಮ್ಮ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಗಳಿಗಾಗಿ GLM-4 Plus ಮಾಡೆಲ್, GPT-4o ನಷ್ಟೇ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಮ್ಮ ಪರೀಕ್ಷೆಗಳು ತೋರಿಸಿವೆ.
ಇದನ್ನು ನಿರ್ವಹಿಸಲು ನಾನು ಒಂದು ರೂಟಿಂಗ್ ಲೇಯರ್ (routing layer) ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಸಿಸ್ಟಮ್ ಈ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ: • ಕೆಲಸದ ಪ್ರಕಾರಕ್ಕೆ (workload type) ಅನುಗುಣವಾಗಿ ವಿನಂತಿಗಳನ್ನು (requests) ರೂಟ್ ಮಾಡುವುದು • latency ಹೆಚ್ಚಾದಲ್ಲಿ ಫಾಲ್ಬ್ಯಾಕ್ ಮಾಡೆಲ್ (fallback model) ಬಳಸುವುದು • ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿವಿಧ ಪ್ರದೇಶಗಳಿಗೆ (regions) ಹಂಚುವುದು • ಪದೇ ಪದೇ ಬರುವ ವಿನಂತಿಗಳನ್ನು ಕ್ಯಾಶ್ (cache) ಮಾಡುವುದು
ನಾನು Redis ಕ್ಯಾಶ್ ಅನ್ನು ಸಹ ಸೇರಿಸಿದೆ. ಒಂದು ವಾರದಲ್ಲಿ ಇದರ hit rate 40% ತಲುಪಿತು. ಇದು ಪುನರಾವರ್ತಿತ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ (repeat queries) ನಾವು ಮಾಡುವ ಟೋಕನ್ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಿತು ಮತ್ತು latency ಅನ್ನು 1.4 ಸೆಕೆಂಡುಗಳಿಂದ 200 ಮಿಲಿಸೆಕೆಂಡ್ಗಳಿಗೆ ಇಳಿಸಿತು.
ಫಲಿತಾಂಶಗಳು: • ಮಾಸಿಕ ಇನ್ಫರೆನ್ಸ್ ವೆಚ್ಚವು (Monthly inference spend) 58% ಇಳಿಕೆಯಾಯಿತು • p99 latency 1.6s ನಿಂದ 1.18s ಗೆ ಇಳಿಕೆಯಾಯಿತು • ಅಪ್ಟೈಮ್ (Uptime) 99.95% ರಲ್ಲೇ ಉಳಿಯಿತು • ಕ್ಯಾಶ್ ಹಿಟ್ ರೇಟ್ (Cache hit rate) 42% ತಲುಪಿತು
ನಾನು ಕಲಿತ ಮೂರು ಪಾಠಗಳು:
- ನಿಮ್ಮದೇ ಆದ ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಸೂಟ್ (evaluation suite) ಅನ್ನು ನಿರ್ಮಿಸಿ. ಸಾಮಾನ್ಯ ಬೆಂಚ್ಮಾರ್ಕ್ಗಳನ್ನು (generic benchmarks) ನಂಬಬೇಡಿ. ನಿಮ್ಮ ನೈಜ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾವನ್ನು ಬಳಸಿ.
- ರೇಟ್ ಲಿಮಿಟ್ಗಳನ್ನು (rate limits) ಸೂಕ್ಷ್ಮವಾಗಿ ಗಮನಿಸಿ. ಪ್ರಾದೇಶಿಕ ಟ್ರಾಫಿಕ್ (Regional traffic) ಅನಿರೀಕ್ಷಿತ ಏರಿಕೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
- ಕಿಲ್ಲ ಸ್ವಿಚ್ (kill switch) ಅನ್ನು ನಿರ್ಮಿಸಿ. ಒಂದು ಕೆಟ್ಟ ಪ್ರಾಂಪ್ಟ್ (bad prompt) ಟೋಕನ್ ಬಳಕೆಯಲ್ಲಿ ಭಾರಿ ಏರಿಕೆಗೆ ಕಾರಣವಾಗಬಹುದು. ಗರಿಷ್ಠ ಟೋಕನ್ಗಳ ಮೇಲೆ ಮಿತಿ (cap) ವಿಧಿಸಿದ್ದು ಒಮ್ಮೆ ನಮಗೆ $14,000 ಉಳಿಸಿಕೊಟ್ಟಿತು.
ನಿಮ್ಮ AI ಬಿಲ್ ತುಂಬಾ ಹೆಚ್ಚಿದ್ದರೆ, ಮೊದಲು ನಿಮ್ಮ SLA ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ. ನೈಜ ಟ್ರಾಫಿಕ್ನಿಂದ ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಸೂಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ನಂತರ, ನೀವು ಪ್ರಸ್ತುತ ನಿರ್ಲಕ್ಷಿಸುತ್ತಿರುವ ಮಾಡೆಲ್ಗಳ ಬೆಲೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.
ಮೂಲ: https://dev.to/bolddeck/how-i-cut-our-ai-api-bill-in-half-while-hitting-p99-slas-1l05
ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi