GPU ಗಳಲ್ಲಿ ವೇಗದ ಎಂಬೆಡಿಂಗ್‌ಗಳು

ವೇಗವಾದ ಮತ್ತು ನಿಖರವಾದ search Perplexityನ ಎಲ್ಲ ಭಾಗಗಳಿಗೂ, ಅಂದರೆ Search ಮತ್ತು Computer ಇಂದ ನಮ್ಮ API Platform ವರೆಗೂ, ಅತ್ಯಂತ ಅವಶ್ಯಕವಾಗಿದೆ. ಹಿನ್ನೆಲೆಯಲ್ಲಿರುವ ಭಾರೀ ಕಾರ್ಯವನ್ನು embedding ಮತ್ತು ranking modelsಗಳು ನಿರ್ವಹಿಸುತ್ತವೆ; ಅವು ನಮ್ಮ systemsಗಳಿಗೆ ನಿರ್ದಿಷ್ಟ queryಗೆ ಅತ್ಯಂತ ಸಂಬಂಧಿಸಿದ ಫಲಿತಾಂಶಗಳನ್ನು ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ. ನಾವು pplx-embed ಮುಂತಾದ ನಮ್ಮದೇ modelsಗಳನ್ನು ತರಬೇತುಗೊಳಿಸಿ ಮತ್ತು ಸೇವೆ ಮಾಡುವ ಮೂಲಕ ಅತ್ಯಾಧುನಿಕ quality ಮತ್ತು latency ಸಾಧಿಸುತ್ತೇವೆ.

ಈ ಲೇಖನವು ಈ ವಿಶೇಷ ವರ್ಗದ ಮಾದರಿಗಳಿಗಾಗಿ ಪರ್ಪ್ಲೆಕ್ಸಿಟಿಯ ಸರ್ವಿಂಗ್ ಮೂಲಸೌಕರ್ಯದ ಅಡಿಯಲ್ಲಿರುವ ನೋಟವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ. AI-ಸ್ಥಳೀಯ ಹುಡುಕಾಟದ ಅನುಮಾನ ಅಗತ್ಯಗಳನ್ನು ಸಮರ್ಥವಾಗಿ ಪರಿಹರಿಸಲು ನಮ್ಮ ತಂತ್ರಗಳನ್ನು ನಾವು ಚರ್ಚಿಸುತ್ತೇವೆ, ನಮ್ಮ exabyte-scale search index ಅನ್ನು ಶಕ್ತಗೊಳಿಸುವಾಗ ಮಾದರಿಗಳ ತ್ವರಿತ ಪ್ರೋಟೋಟೈಪಿಂಗ್ ಮತ್ತು ಮೌಲ್ಯಮಾಪನವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ. ಈ ತಂತ್ರಗಳು ಒಟ್ಟಾಗಿ ಹುಡುಕಾಟದ ಗುಣಮಟ್ಟ ಮತ್ತು ದಕ್ಷತೆಯ ಪ್ಯಾರೆಟೊ ಗಡಿಯನ್ನು ವಿಸ್ತರಿಸುತ್ತವೆ, ಕಡಿಮೆ ವೆಚ್ಚ ಮತ್ತು ಸುಪ್ತತೆಯಲ್ಲಿ ಉತ್ತಮ ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ ಏಜೆಂಟ್‌ಗಳು ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಲು ನಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಹುಡುಕಾಟಕ್ಕಾಗಿ ಎಂಬೆಡಿಂಗ್‌ಗಳು

ವಿಶಿಷ್ಟವಾದ ಹುಡುಕಾಟ ಸೆಟಪ್‌ನಲ್ಲಿ, ಸೂಚ್ಯಂಕಿತ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಉನ್ನತ-ಆಯಾಮದ ವೆಕ್ಟರ್ ಸ್ಪೇಸ್‌ಗೆ ಮ್ಯಾಪ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಅದೇ ಮಾದರಿಯನ್ನು ಬಳಸಿ ಪ್ರಶ್ನೆಯನ್ನು ಎಂಬೆಡ್ ಮಾಡುವ ಮೂಲಕ, ಪ್ರಶ್ನೆಯ ಆ ವೆಕ್ಟರ್‌ಗೆ ಹತ್ತಿರವಿರುವ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವ ಮೂಲಕ ಒಂದೇ ರೀತಿಯ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಪತ್ತೆ ಮಾಡಬಹುದು. ಇದು ಅನುಮಾನ ಎಂಜಿನ್‌ಗೆ ಸೇವೆ ಸಲ್ಲಿಸಲು ಎರಡು ವಿಭಿನ್ನ ದಟ್ಟಣೆಯ ಮಾದರಿಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ:

• ಬ್ಯಾಚ್ ಎಂಬೆಡಿಂಗ್: ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿರ್ಮಿಸುವಾಗ, ವಿಸ್ತರಿಸುವಾಗ ಅಥವಾ ಮರು-ಸೂಚಿಸುವಾಗ, ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಥ್ರೋಪುಟ್ ಅನ್ನು ಗರಿಷ್ಠಗೊಳಿಸುವ ಮೂಲಕ ಬೃಹತ್ ದಾಖಲೆಗಳನ್ನು ವೆಕ್ಟರ್ ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಎಂಬೆಡ್ ಮಾಡಬೇಕು.

ವೆಕ್ಟರ್ ಹುಡುಕಾಟದ ನಂತರ, ಥ್ರೋಪುಟ್ ಮತ್ತು ಸುಪ್ತತೆಯ ನಡುವೆ ಸಮತೋಲನವನ್ನು ಸಾಧಿಸುವ ಮೂಲಕ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಸ್ಕೋರ್ ಮಾಡಬೇಕು.

• ಆನ್‌ಲೈನ್ ಎಂಬೆಡಿಂಗ್: ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸುವಾಗ, ಲುಕ್‌ಅಪ್‌ಗಳಿಗಾಗಿ ಒಂದು ಕಿರು ಪ್ರಶ್ನೆಯನ್ನು ಎಂಬೆಡ್ ಮಾಡಬೇಕು, ಸುಪ್ತತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಬಳಕೆ ಸಂದರ್ಭಗಳಾದ್ಯಂತ ಸಾಧ್ಯವಾದಷ್ಟು ಸಾಮಾನ್ಯ ಘಟಕಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳಲು ನಾವು ನಮ್ಮ inference infrastructure ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ. embeddingಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಸಣ್ಣ Transformer ಮಾದರಿಗಳನ್ನು ಬಳಸುವುದರಿಂದ, ನಮ್ಮ LLM inference code ಜೊತೆಗೆ implementationನ ಬಹುಭಾಗವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ: batch embeddingsಗಳು compute-bound prefillಗೆ ಸಮಾನವಾಗಿವೆ, ხოლო online embeddingsಗಳು, ಅವು ಬಹುಸಾರ ಕೆಲವೇ tokensಗಳಲ್ಲಿ ನಡೆಯುತ್ತವೆ, computationalವಾಗಿ memory-bound decodeಗೆ ಸಮಾನವಾಗಿವೆ. ಆದ್ದರಿಂದ embedding modelsಗಳನ್ನು ಸೇವೆ ಮಾಡಲು ನಾವು ನಮ್ಮ optimized prefill and decode kernels ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತೇವೆ. ಇದರ ಫಲವಾಗಿ, ಕಡಿಮೆ ಹೆಚ್ಚುವರಿ engineering workನೊಂದಿಗೆ ದೊಡ್ಡ batch inference throughput ಸಾಧಿಸಬಹುದು, ಜೊತೆಗೆ online embeddings workloadsಗಾಗಿ ಕಡಿಮೆ latencyಯನ್ನೂ ಕಾಪಾಡಿಕೊಳ್ಳಬಹುದು.

Tulips, Roses, ಮತ್ತು ಕೆಲವು Ivy

ನಾವು internal ಆಗಿಯೂ external ಆಗಿಯೂ ನಮ್ಮ API Platform ಮೂಲಕ standardized APIs ಮೂಲಕ inference ಅನ್ನು ಒದಗಿಸುತ್ತೇವೆ. ಒಳಗಡೆ, embedding requestನ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅನೇಕ servicesಗಳು ಭಾಗಿಯಾಗಿರುತ್ತವೆ:

• Ivy ಎಂಬುದು Perplexity ಸೇವೆಗಳು ಕರೆಯುವ Rust HTTP ಗೇಟ್‌ವೇ ಆಗಿದೆ.

ಇದು JSON ಪಾರ್ಸಿಂಗ್, ಟೋಕನೈಸೇಶನ್, ಇನ್‌ಪುಟ್ ಟೆಂಪ್ಲೇಟಿಂಗ್ ಮತ್ತು ಬ್ಯಾಚ್ ಸ್ಪ್ಲಿಟಿಂಗ್‌ನಂತಹ ವಿನಂತಿಗಳಿಗಾಗಿ CPU-ಬದಿಯ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸರ್ವರ್‌ಗಳಿಗಾಗಿ ಕಸ್ಟಮ್ gRPC ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಅನುವಾದಿಸುತ್ತದೆ. ಈ ಪ್ರತ್ಯೇಕತೆಯು ಭಾರವಾದ ಅನುಮಾನ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗಳನ್ನು ಮುಟ್ಟದೆ ಟೋಕನೈಸೇಶನ್ ಮತ್ತು ಇನ್‌ಪುಟ್ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಸುತ್ತಲಿನ ಕೆಲವು ನಿಯರಾಪಕಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

• Tulip ಎಂಬುದು ಅನುಮಾನ ಸರ್ವರ್ ಇಂಟರ್ಫೇಸ್ ಆಗಿದೆ.

ಇದು ರಸ್ಟ್, tokio, ಮತ್ತು tonic ನೊಂದಿಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾದ gRPC ಸರ್ವರ್ ಆಗಿದೆ. ತುಲಿಪ್ gRPC ಅನುಮಾನ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ವೇಳಾಪಟ್ಟಿ ಮತ್ತು ಬ್ಯಾಚಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ನಂತರ ಬ್ಯಾಚ್‌ಗಳನ್ನು ROSE ಇಂಜಿನ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಪೂರ್ಣಗೊಂಡ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

• ROSE (ರನ್‌ಟೈಮ್-ಆಪ್ಟಿಮೈಸ್ಡ್ ಸರ್ವಿಂಗ್ ಇಂಜಿನ್) ಮಾದರಿ ಅನುಮಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.

ಇದು ಪ್ರಾಥಮಿಕವಾಗಿ Python ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲ್ಪಟ್ಟಿದೆ, ಇದು ವ್ಯಾಪಕವಾದ ಮಾದರಿಗಳಿಗೆ ಕರ್ನಲ್‌ಗಳು, ಲೇಯರ್‌ಗಳು ಮತ್ತು ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ROSE ಮಾದರಿಗಳ ಮೂಲಕ ಫಾರ್ವರ್ಡ್ ಪಾಸ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಜೊತೆಗೆ ಎಂಬೆಡಿಂಗ್‌ಗಳಿಗಾಗಿ ವಿಶೇಷವಾದ CUDA ಗ್ರಾಫ್ ನಿರ್ವಹಣೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದು step() ಕಾರ್ಯದ ಮೂಲಕ Tulip ಗೆ ಸೇರಿಸಲ್ಪಟ್ಟಿದೆ, ಇದು ಬ್ಯಾಚ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಆಕ್ಸಿಲರೇಟರ್‌ನಲ್ಲಿ ಅದು ನಿರ್ವಹಿಸುವ ಲೆಕ್ಕಾಚಾರಕ್ಕೆ ಉಲ್ಲೇಖವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಕರ್ನಲ್ ಮೀರಿ ಗಮನ ಹರಿಸುವುದು

ಹೊಂದಾಣಿಕೆಯಾದ ಟ್ರಾನ್ಸ್‌ಫಾರ್ಮರ್-ಆಧಾರಿತ ಮಾದರಿಗಳು ಮತ್ತು ಆಧಾರವಾಗಿರುವ ಹಾಪರ್/ಬ್ಲಾಕ್‌ವೆಲ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಎರಡೂ ಪ್ರಬುದ್ಧ ತಂತ್ರಜ್ಞಾನಗಳಾಗಿವೆ, ಆದ್ದರಿಂದ GPU ಬದಿಯಲ್ಲಿ ಎಂಬೆಡಿಂಗ್ ಅನುಮಾನವು ವಿವಿಧ ಅನುಮಾನ ಎಂಜಿನ್‌ಗಳಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಅತ್ಯುತ್ತಮವಾದ ಅನುಷ್ಠಾನಕ್ಕೆ ಒಮ್ಮುಖವಾಗಿದೆ. ಹಾಗಿದ್ದರೂ, ಮಾದರಿಗಳನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಅಂತ್ಯದಿಂದ ಅಂತ್ಯಕ್ಕೆ ಒಡ್ಡುವ ರನ್‌ಟೈಮ್‌ಗಳು ಮತ್ತು ಹಾರ್ನೆಸ್‌ಗಳಲ್ಲಿ ಸುಧಾರಣೆಗಾಗಿ ಹೆಚ್ಚುವರಿ ಅವಕಾಶಗಳನ್ನು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, CUDA ಗ್ರಾಫ್‌ಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಮತ್ತು ಸ್ಥಳೀಯ ರಸ್ಟ್ ಎಂಜಿನ್‌ನಲ್ಲಿ GPU-ಬದಿಯ ಫಲಿತಾಂಶವನ್ನು ಅಸಿಂಕ್ರೋನಸ್ ಆಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಲು LazyTensor ಅಮೂರ್ತತೆಯನ್ನು ನಿರ್ಮಿಸುವ ಮೂಲಕ ನಾವು ಸುಪ್ತತೆಯನ್ನು (latencies) ಸುಧಾರಿಸಬಹುದು ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ನಾವು ಈ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು Tulip ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ, ಇದರಿಂದಾಗಿ ಇದು ROSE ನ ಮಾದರಿ ಅನುಷ್ಠಾನಗಳೊಂದಿಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಇಂಟರ್ಫೇಸ್ ಮಾಡಬಹುದು.

Tulip

ನಮ್ಮ ಮಾದರಿ ಸೇವೆಯ ಮೇಲೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹಗುರವಾದ ಇಂಟರ್ಫೇಸ್ ಆಗಲು ನಾವು Tulip ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದೇವೆ. ಇದು ಟೋಕಿಯೊ (Tokio) ಅಸಿಂಕ್ ಕಾರ್ಯಗಳಲ್ಲಿ ಒಳಬರುವ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ವಿನಂತಿಗಳ ಪೂಲ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಆಕ್ಸಿಲರೇಟರ್‌ಗೆ ರವಾನಿಸಲು ಬ್ಯಾಚ್‌ಗಳನ್ನು ಶೆಡ್ಯೂಲ್ ಮಾಡುತ್ತದೆ. Tulip ನಲ್ಲಿನ ಶೆಡ್ಯೂಲಿಂಗ್ ಕಾರ್ಯವಿಧಾನವು ತುಂಬಾ ಸರಳವಾಗಿದೆ: Tulip ಕೆಲಸವನ್ನು ರವಾನಿಸುತ್ತಿರುವಾಗ ಅಥವಾ ಫಲಿತಾಂಶಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿರುವಾಗ ವಿನಂತಿಗಳು ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತವೆ. ಸಂಗ್ರಹವಾದ ವಿನಂತಿಗಳಿಂದ, ಮಾದರಿಯ ಮೂಲಕ ರನ್ ಮಾಡಲು ಮೊದಲ-ಬಂದವರಿಗೆ-ಮೊದಲ-ಸೇವೆ ಆಧಾರದ ಮೇಲೆ ಅನುಕ್ರಮಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ.

ಸರಳವಾದ ಶೆಡ್ಯೂಲಿಂಗ್ ಕಾರ್ಯವಿಧಾನವು ಮಾದರಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲಿನ ಅವಲೋಕನದಿಂದ ಪ್ರೇರೇಪಿಸಲ್ಪಟ್ಟಿದೆ. ಸಣ್ಣ ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಗಳಿಗಾಗಿ, ನಾವು ಸೇವೆ ಸಲ್ಲಿಸುವ ಅನುಕ್ರಮ ಉದ್ದಗಳಲ್ಲಿ, ಗಮನದ ವರ್ಗೀಯ ವೆಚ್ಚಕ್ಕಿಂತ ದಟ್ಟವಾದ ಲೇಯರ್‌ಗಳ ರೇಖೀಯ ವೆಚ್ಚವು ಪ್ರಮುಖವಾಗಿದೆ ಎಂದು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ. ಹೀಗಾಗಿ, ಸುಪ್ತತೆಯು ಹೆಚ್ಚಾಗಿ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ, ಅನುಕ್ರಮಗಳ ಸಂಖ್ಯೆಗೆ ಅಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಒಂದು ಬ್ಯಾಚ್ GPU ಅನ್ನು ಸ್ಯಾಚುರೇಟ್ ಮಾಡಲು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾದ ನಂತರ, ಇದು ಒಂದು ಬಿಲಿಯನ್‌ಗಿಂತ ಕಡಿಮೆ ನಿಯರಾಪಕಗಳ ಮಾದರಿಯಲ್ಲಿ ಸುಮಾರು 512 ಟೋಕನ್‌ಗಳಾಗಿರುತ್ತದೆ, ಅದರಲ್ಲಿ ಹೆಚ್ಚಿನ ಅನುಕ್ರಮಗಳನ್ನು ಪ್ಯಾಕ್ ಮಾಡುವುದರಿಂದ ದಕ್ಷತೆಯು ಸುಧಾರಿಸುವುದಿಲ್ಲ.

ಮಾದರಿಯೊಂದಿಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಇಂಟರ್ಫೇಸ್ ಮಾಡಲು, GPU ಮತ್ತು CPU ಕೆಲಸವನ್ನು ಅತಿಕ್ರಮಿಸಲು ಮತ್ತು ಲಭ್ಯವಿರುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಿಕೊಳ್ಳಲು Tulip CUDA ಗ್ರಾಫ್‌ಗಳು ಮತ್ತು ಲೇಜಿ ಫಲಿತಾಂಶ ಟ್ರ್ಯಾಕಿಂಗ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ.

CUDA ಗ್ರಾಫ್ ನಿರ್ವಹಣೆ

ಮಾದರಿಯ ಫಾರ್ವರ್ಡ್ ಪಾಸ್ ಅನ್ನು ರನ್ ಮಾಡುವುದು CPU-ಬದಿಯ ಮತ್ತು GPU-ಬದಿಯ ಕೆಲಸ ಎರಡನ್ನೂ ಒಳಗೊಂಡಿರುತ್ತದೆ. ಸೂಕ್ತವಾದ ನಿಯರಾಪಕಗಳೊಂದಿಗೆ ಬ್ಯಾಚ್‌ಗಳನ್ನು ಶೆಡ್ಯೂಲ್ ಮಾಡಲು ಮತ್ತು ಕರ್ನಲ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು CPU ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ, ಆದರೆ GPU ಸಂಬಂಧಿತ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗುಣಾಕಾರ, ಗಮನ (attention), ನಾರ್ಮ್ ಅಥವಾ ಆಕ್ಟಿವೇಷನ್ ಕರ್ನಲ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ತರಬೇತಿ ಮತ್ತು ಮರುಸೂಚಿಕೆ ಮುಂತಾದ ಅಧಿಕ-ಥ್ರೋಪುಟ್ ಕೆಲಸದ ಹೊರೆಗಳಿಗೆ, CPU-ಬದಿಯ ಓವರ್‌ಹೆಡ್‌ಗಳು ಅತ್ಯಲ್ಪವಾಗಿರುತ್ತವೆ ಏಕೆಂದರೆ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳು ಮತ್ತು GPU-ಬದಿಯ ಸುಪ್ತತೆ ಎರಡೂ ದೊಡ್ಡದಾಗಿರುತ್ತವೆ. ಆದಾಗ್ಯೂ, ಸಣ್ಣ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳಲ್ಲಿ, CPU-ಬದಿಯ ಕೆಲಸವು GPU-ಬದಿಯ ಕೆಲಸವನ್ನು ಮೀರಿಸಬಹುದು.

ವಿಸ್ತರಿಸಿ

ಓವರ್‌ಹೆಡ್‌ಗಳನ್ನು ತಗ್ಗಿಸಲು, ಸ್ವತಂತ್ರ ಕರ್ನಲ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವ ಬದಲು, CUDA ಡ್ರೈವರ್‌ಗೆ ಒಂದೇ ಕರೆಯೊಂದಿಗೆ ಫಾರ್ವರ್ಡ್ ಪಾಸ್‌ನ ಎಲ್ಲಾ ಕರ್ನಲ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಅಗತ್ಯವಿರುವ ಮೆಟಾಡೇಟಾವನ್ನು ಸೆರೆಹಿಡಿಯಲು CUDA ಗ್ರಾಫ್ ಅನ್ನು ನಿರ್ಮಿಸಬಹುದು. ಇದು CUDA ಗ್ರಾಫ್‌ಗಳನ್ನು ಸೆರೆಹಿಡಿಯಬಹುದಾದ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಿಗಾಗಿ ದುಬಾರಿ Python ಮತ್ತು PyTorch ಕೋಡ್ ಅನ್ನು ಮರು-ರನ್ ಮಾಡುವ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ.

ಪ್ರತಿ ಮಾದರಿಯಾದ್ಯಂತ, ನಾವು ಇನ್ಫ್ಲೆಕ್ಷನ್ ಪಾಯಿಂಟ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತೇವೆ, GPU ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು CPU-ಬದಿಯ ಕರ್ನಲ್ ಪ್ರಾರಂಭಕ್ಕಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚದಾಯಕವಾಗಿರುವ ಕನಿಷ್ಠ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಗಳು ಚಿಕ್ಕದಾಗಿರುವುದರಿಂದ, ಈ ಇನ್ಫ್ಲೆಕ್ಷನ್ ಪಾಯಿಂಟ್ ಸಾವಿರಾರು ಟೋಕನ್‌ಗಳು ಮತ್ತು ಹತ್ತಾರು ಅನುಕ್ರಮಗಳ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಬರುತ್ತದೆ ಎಂದು ನಾವು ಗಮನಿಸುತ್ತೇವೆ. ಕೆಲವು ಗಮನದ ಅನುಷ್ಠಾನಗಳು ಕರ್ನಲ್ ಪ್ರಾರಂಭಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಡೈನಾಮಿಕ್ ಹೋಸ್ಟ್-ಬದಿಯ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿವೆ, ಇದು ಪೂರ್ಣ-ಮಾದರಿ ಪ್ರೀಫಿಲ್/ದಟ್ಟವಾದ CUDA ಗ್ರಾಫ್‌ಗಳನ್ನು ತಡೆಯುತ್ತದೆ. ನಮ್ಮ ಅನುಮಾನ ಎಂಜಿನ್‌ನಲ್ಲಿ ಅವುಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ನಾವು ಸಂಬಂಧಿತ ಕರ್ನಲ್‌ಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಮಾಡಿದ್ದೇವೆ.

ಓವರ್‌ಹೆಡ್‌ಗಳನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಎಲ್ಲಾ ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಗಳಿಗಾಗಿ ಸಂಪೂರ್ಣ-ಮಾದರಿ CUDA ಗ್ರಾಫ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ ಮತ್ತು GPU ಕೆಲಸದೊಂದಿಗೆ CPU ಕೆಲಸವನ್ನು ಅತಿಕ್ರಮಿಸುತ್ತೇವೆ. CUDA ಗ್ರಾಫ್‌ಗಳು CPU-ಬದಿಯ ಓವರ್‌ಹೆಡ್‌ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವುದರಿಂದ, ಒಮ್ಮೆ ಗ್ರಾಫ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ಮುಂದಿನ ಬ್ಯಾಚ್ ಲಭ್ಯವಿರುವಾಗಲೆಲ್ಲಾ ಅದರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ಕ್ಯೂ ಮಾಡಲು ನಮಗೆ ಮುಕ್ತ ಸಮಯವಿರುತ್ತದೆ. ಬಾಕಿ ಉಳಿದಿರುವ ಬ್ಯಾಚ್‌ನ ಫಲಿತಾಂಶಗಳನ್ನು LazyTensor ನೊಂದಿಗೆ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ, ಇದು ಹಿಂದಿನ ಬ್ಯಾಚ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಮುಗಿಸುವವರೆಗೆ ರಸ್ಟ್‌ನಲ್ಲಿರುವ ಅಸಿಂಕ್ ಕಾರ್ಯವನ್ನು ನಿರ್ಬಂಧಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಕರ್ನಲ್ ಪ್ರಾರಂಭಗಳ ವೆಚ್ಚದಿಂದ ನಾವು ಹಿಂತಿರುಗಿಸಲ್ಪಡುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಮೂಲಕ ಕಡಿಮೆ-ಸುಪ್ತತೆಯ ಸೇವೆಗೆ CUDA ಗ್ರಾಫ್‌ಗಳು ಸಹಾಯ ಮಾಡುತ್ತವೆ ಮತ್ತು ಅಧಿಕ-ಥ್ರೋಪುಟ್ ಸಂದರ್ಭದಲ್ಲಿ ಸುಧಾರಿತ ಶೆಡ್ಯೂಲಿಂಗ್ ಅನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತವೆ ಏಕೆಂದರೆ ಅವುಗಳು ಮುಂದಿನ ಬ್ಯಾಚ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು CPU ಅನ್ನು ಮುಕ್ತಗೊಳಿಸುತ್ತವೆ.

ವಿಸ್ತರಿಸಿ

ಪ್ರತಿ ವಿಭಿನ್ನ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ CUDA ಗ್ರಾಫ್‌ಗಳನ್ನು ಸೆರೆಹಿಡಿಯಬೇಕು, ಅಂದರೆ ಎಂಬೆಡಿಂಗ್‌ಗಳಿಗೆ ಪ್ರತಿ ಅನುಕ್ರಮ ಎಣಿಕೆ ಮತ್ತು ಟೋಕನ್ ಎಣಿಕೆಯ ಸಂಯೋಜನೆಗೆ ಒಂದು ಗ್ರಾಫ್. ಈ ಗ್ರಿಡ್ ವಿಸ್ತಾರವಾಗಿರುವುದರಿಂದ, ನಾವು ಟೋಕನ್ ಎಣಿಕೆಗಳನ್ನು 64 ಅಥವಾ 256 ರ ಗುಣಕಗಳಾಗಿರುವ ಬಕೆಟ್‌ಗಳಿಗೆ ಪ್ಯಾಡ್ ಮಾಡುತ್ತೇವೆ. ಇದು ಇನ್ನೂ ಸಾವಿರಾರು ಗ್ರಾಫ್‌ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಇದು ವಿಶಿಷ್ಟವಾದ ಮಾದರಿಗೆ ಸೆರೆಹಿಡಿಯಲು ಹಲವಾರು ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಸೆರೆಹಿಡಿಯುವಿಕೆಯ ವೆಚ್ಚವು ಎರಡು ಮೂಲಗಳಿಂದ ಬರುತ್ತದೆ: ಕರ್ನಲ್‌ಗಳನ್ನು ಕಂಪೈಲ್ ಮಾಡಲು ಮತ್ತು ಅವುಗಳ ಅಗತ್ಯವಿರುವ ವಿವಿಧ ಕರ್ನಲ್‌ಗಳಿಗೆ ಬಫರ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದ ಹಂಬಲದ ಫಾರ್ವರ್ಡ್ ಪಾಸ್ (eager forward pass), ನಂತರ Python ಕೋಡ್ ಅನ್ನು ಮರು-ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸೆರೆಹಿಡಿಯುವಿಕೆಯ ರನ್.

ಎಂಜಿನ್ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತಿದ್ದಂತೆ CUDA ಗ್ರಾಫ್‌ಗಳನ್ನು ಸೋಮಾರಿಯಾಗಿ (lazily) ಸೆರೆಹಿಡಿಯುವ ಮೂಲಕ ನಾವು ಆರಂಭಿಕ ವೆಚ್ಚಗಳನ್ನು ತಗ್ಗಿಸುತ್ತೇವೆ. ನಾವು ಪ್ರತಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಗ್ರಾಫ್ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ಪ್ರಚೋದಿಸುವ ಮೊದಲು ಅದು ಹಂಬಲದ ವಾರ್ಮ್‌ಅಪ್ ರನ್ (eager warmup run) ಮೂಲಕ ಹೋಗುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಎರಡನೇ ಹಿಟ್‌ನಲ್ಲಿ ಮರುಪಂದ್ಯ (replay) ಮಾಡುತ್ತೇವೆ. ಅದೇ ಗ್ರಾಫ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನ ಎಲ್ಲಾ ನಂತರದ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗಳು CUDA ಗ್ರಾಫ್ ಮರುಪಂದ್ಯದ ಮೂಲಕ ಹೋಗುತ್ತವೆ. ಲೇಜಿ ಗ್ರಾಫ್ ಸೆರೆಹಿಡಿಯುವಿಕೆಯು ಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ p99 ಸುಪ್ತತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ; ಆದಾಗ್ಯೂ, ಇದು ಹಲವಾರು ನಿಮಿಷಗಳ ಹಂಬಲದ ಕೆಲಸವನ್ನು ಹಲವಾರು ಗಂಟೆಗಳವರೆಗೆ ಹರಡುವಲ್ಲಿ ಮೌಲ್ಯಯುತವಾಗಿದೆ. ತ್ವರಿತ ಆರಂಭಿಕ ಸಮಯಗಳು ಎಂಬೆಡಿಂಗ್ ನಿಯೋಜನೆಗಳನ್ನು ಉತ್ತಮವಾಗಿ ಅಳೆಯಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಲೇಜಿ ಟೆನ್ಸರ್‌ಗಳು

CUDA ಮೂಲಕ, GPU ಕೆಲಸವು ಅಸಿಂಕ್ರೋನಸ್ ಆಗಿದೆ. ಕರ್ನಲ್ ಅನ್ನು ಅಸಿಂಕ್ರೋನಸ್ ಆಗಿ ಪ್ರಾರಂಭಿಸುವುದು ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಅದನ್ನು ಕ್ಯೂ ಮಾಡುವುದರಿಂದ, ಫಲಿತಾಂಶದ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಓದಲು ಹೋಸ್ಟ್ ಕೋಡ್ ಸ್ಪಷ್ಟವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕು. ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಸಮಾನಾಂತರತೆಯನ್ನು ಸುಲಭಗೊಳಿಸಲು ಮತ್ತು ಡಿವೈಸ್‌ನಲ್ಲಿ ಹಿಂದಿನದು ಪೂರ್ಣಗೊಳ್ಳಲು ಕಾಯುತ್ತಿರುವಾಗ ಭವಿಷ್ಯದ ಬ್ಯಾಚ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಮೌಲ್ಯಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಾವು LazyTensor ಅಮೂರ್ತತೆಯನ್ನು ಅವಲಂಬಿಸಿದ್ದೇವೆ.

LazyTensor ಯು ಪೇಜ್-ಲಾಕ್ಡ್ ಮೆಮೊರಿಯಲ್ಲಿ ಹೋಸ್ಟ್ ಬಫರ್ ಅನ್ನು ಮತ್ತು ಡಿವೈಸ್‌ನಿಂದ ಡೇಟಾವನ್ನು ನಕಲಿಸುವ ಈವೆಂಟ್ ಮೂಲಕ cudaMemcpyAsync ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ. ಅದೇ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ಪಾಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ ಇದನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ. ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಹಿಂದಿನ ಕರ್ನಲ್‌ಗಳು ಕಾರ್ಯಗತಗೊಳ್ಳಲು ಕಾಪಿ ಕಾರ್ಯಾಚರಣೆಯು ಕಾಯಬೇಕಾಗಿರುವುದರಿಂದ, ಸಂಬಂಧಿತ ಈವೆಂಟ್ ಫಾರ್ವರ್ಡ್ ಪಾಸ್‌ನ ಮುಕ್ತಾಯ ಮತ್ತು CPU ನಲ್ಲಿ ಫಲಿತಾಂಶದ ಲಭ್ಯತೆ ಎರಡನ್ನೂ ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

GPU ಮತ್ತು CPU ಕೆಲಸವನ್ನು ಅತಿಕ್ರಮಿಸಲು ನಾವು ನಮ್ಮ ROSE ಎಕೋಡರ್ ಎಂಜಿನ್‌ನಲ್ಲಿ LazyTensor ಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತೇವೆ. ಪ್ರತಿ step() ಕರೆಯು CUDA ಗ್ರಾಫ್ ಅನ್ನು ರನ್ ಮಾಡಿ ಅದು ಮುಗಿಯಲು ಕಾಯುವ ಬದಲಿಗೆ, step() ಯು ಅದರ ಫಲಿತಾಂಶವನ್ನು ಅಸಿಂಕ್ರೋನಸ್ ಆಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಲು LazyTensor ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. CUDA ಗ್ರಾಫ್‌ಗಳೊಂದಿಗೆ ಜೋಡಿಸಲ್ಪಟ್ಟಿರುವುದು, ಕಡಿಮೆ ಸುಪ್ತತೆಗಳು ಮತ್ತು ಉತ್ತಮ ಥ್ರೋಪುಟ್ ಅನ್ನು ಸಾಧಿಸಲು ಇದು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ROSE

LLM ಸೇವೆಗಾಗಿ ನಾವು ಮೂಲತಃ ನಿರ್ಮಿಸಿದ ನಮ್ಮ ROSE ಎಂಜಿನ್ ಅನ್ನು, ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ನಿರ್ವಹಿಸಲು ನಾವು ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ. ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಗಳನ್ನು ಬೆಂಬಲಿಸಲು ಅಗತ್ಯವಿರುವ ಪ್ರಯತ್ನವನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ROSE LLM ಗಳು ಮತ್ತು ಎಂಬೆಡಿಂಗ್‌ಗಳ ನಡುವೆ ಕೋಡ್ ಅನ್ನು ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, pplx-embed ಸರ್ವಿಂಗ್ ಮತ್ತು Qwen3.5 LLM ಡಿಕೋಡಿಂಗ್ ಎಲ್ಲವೂ ಒಂದೇ ಕರ್ನಲ್‌ಗಳ ಮೂಲಕ ಹೋಗುತ್ತವೆ. ಪ್ರೋಟೋಟೈಪಿಂಗ್, ಮೌಲ್ಯಮಾಪನ ಮತ್ತು ಉತ್ಪಾದನಾ ಅನುಮಾನಕ್ಕಾಗಿ LLM ನಿಂದ ಮೂಲತಃ ಫೈನ್-ಟ್ಯೂನ್ ಮಾಡಲಾದ ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಗೆ ಸುಲಭವಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸಲು ಈ ಹಂಚಿಕೆಯು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ದಟ್ಟವಾದ ಲೇಯರ್‌ಗಳಿಗಾಗಿ, ಟೋಕನ್ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದರಿಂದ ಎಂಬೆಡಿಂಗ್ ಮತ್ತು LLM ಅನುಮಾನ ಒಂದೇ ಆಗಿರುತ್ತವೆ. ಗಮನದ ಲೇಯರ್‌ಗಳಲ್ಲಿ, LLM ಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಪೇಜ್ಡ್ ಪ್ರೀಫಿಲ್ ಮತ್ತು ಡಿಕೋಡ್ ಸೆಟಪ್‌ಗಳ ಜೊತೆಗೆ, ragged ಇನ್‌ಪುಟ್‌ಗಳಿಗೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಗೆ ಸೇವೆ ಒದಗಿಸುವಾಗ, ನಾವು KV ಸಂಗ್ರಹವನ್ನು (cache) ಇನ್‌ಸ್ಟಾಂಿಯೇಟ್ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಪ್ಯಾಡಿಂಗ್ ಅನ್ನು ತಪ್ಪಿಸಲು ragged ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ಬೆಂಬಲಿಸುವ ಗಮನದ ಕರ್ನಲ್‌ಗಳ ವ್ಯತ್ಯಾಸಗಳಿಗೆ ರವಾನಿಸುತ್ತೇವೆ. ಬೆಂಬಲಿಸುವ ಪರಿವರ್ತನೆ ಮತ್ತು ಮಾಪನಾಂಕ ನಿರ್ಣಯ ದಿನಚರಿಗಳನ್ನು ಸಹ LLM ಗಳೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲಾಗುತ್ತದೆ.

Ivy

ಐವಿ (Ivy), ನಮ್ಮ ಅನುಮಾನ HTTP ಪ್ರಾಕ್ಸಿ ಲೇಯರ್ ಕೂಡ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಪ್ರಮುಖ ಪಾತ್ರ ವಹಿಸುತ್ತದೆ. ಉತ್ಪಾದನೆಯಲ್ಲಿ ವಿನಂತಿ ಪೇಲೋಡ್‌ಗಳು ಬದಲಾಗುವುದರಿಂದ, ವೈಯಕ್ತಿಕ ವಿನಂತಿಗಳನ್ನು ವೈಯಕ್ತಿಕ ಪ್ರತಿಕೃತಿಗಳಿಗೆ (replicas) ರೂಟಿಂಗ್ ಮಾಡುವುದರಿಂದ ಲೋಡ್ ಅಸಮತೋಲನ ಉಂಟಾಗಬಹುದು. ಐವಿ ದೊಡ್ಡ-ಬ್ಯಾಚ್ ವಿನಂತಿಗಳನ್ನು ತುಂಡುಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕೃತಿಗಳ ನಡುವೆ ಅವುಗಳನ್ನು ಲೋಡ್-ಬ್ಯಾಲೆನ್ಸ್ ಮಾಡುತ್ತದೆ, ಬಳಕೆದಾರರ ಬಳಕೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ ಮತ್ತು ಸುಪ್ತತೆಯನ್ನು ಸುಗಮಗೊಳಿಸುತ್ತದೆ. ಐವಿಯಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಹೊರತರಲಾದ in-house unigram tokenization ಕುರಿತ ನಮ್ಮ ಇತ್ತೀಚಿನ ಕೆಲಸವು ಆಫ್-ದ-ಶೆಲ್ಫ್ ಟೋಕನೈಜರ್‌ಗಳ ಮೇಲೆ ಸುಪ್ತತೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಸುಧಾರಿಸುತ್ತದೆ.

...ಆದರೆ ಕರ್ನಲ್‌ಗಳು ಇನ್ನೂ ಮುಖ್ಯವಾಗಿವೆ

ROSE ವಿವಿಧ ಗಮನ ಬ್ಯಾಕೆಂಡ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ವಿಭಿನ್ನ ಕರ್ನಲ್‌ಗಳು ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆ ಗಾತ್ರಗಳಿಗೆ ಸೂಕ್ತವಾಗಿರಬಹುದು. ಕಾಲಾನಂತರದಲ್ಲಿ, ragged ಗಮನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾವು FlashInfer 2, FlashInfer 3 ಮತ್ತು FlashAttention 4 ಕರ್ನಲ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸಿದ್ದೇವೆ.

ವಿಸ್ತರಿಸಿ

ಸಾಮಾನ್ಯವಾಗಿ, FlashAttention 4 ವೇಗವಾಗಿರುವುದನ್ನು ನಾವು ಗಮನಿಸುತ್ತೇವೆ. ಆದಾಗ್ಯೂ, FlashInfer 3 ಅತ್ಯಂತ ದೀರ್ಘ ಕ್ರಮ ಉದ್ದಗಳಲ್ಲಿ Qwen-based ಮಾದರಿಗಳಲ್ಲಿ ಅದನ್ನು ಮೀರಿಸುತ್ತದೆ. ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಟ್ಯೂನಿಂಗ್ attention heads ಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಆಯಾಮದ ಮೇಲೆ ಅವಲಂಬಿಸಿ ಬದಲಾಗಬಹುದಾದುದರಿಂದ, ನಾವು ಹಲವು ಸಂರಚನೆಗಳಿಗೆ ಬೆಂಬಲವನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ ಮತ್ತು ಸೇವೆ ನೀಡುವಾಗ ಪ್ರಕರಣಾನುಸಾರ ನಿರ್ಧಾರ ಕೈಗೊಳ್ಳುತ್ತೇವೆ.

ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳು

ನಾವು vLLM v0.22.0 ವಿರುದ್ಧ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಮಾಡುತ್ತೇವೆ, ವಾಸ್ತವಿಕ ಮಾದರಿ ತೂಕಗಳು ಮತ್ತು ಮೌಲ್ಯಮಾಪನ ಡೇಟಾಸೆಟ್‌ಗಳಿಂದ ಪಡೆದ ಇನ್‌ಪುಟ್‌ಗಳ ಮೇಲೆ BF16 ನಿಖರತೆಯ ಮೇಲೆ ಅನುಮಾನವನ್ನು ರನ್ ಮಾಡುತ್ತೇವೆ. ಎಲ್ಲಾ ಸಮಯದ ರನ್‌ಗಳಿಗೆ ವಾರ್ಮ್‌ಅಪ್ ರನ್‌ಗಳು ಮುಂಚಿತವಾಗಿದ್ದವು, ಇದು ಕೊಸೈನ್ ಹೋಲಿಕೆಯಲ್ಲಿನ ವ್ಯತ್ಯಾಸವು 0.1% ಒಳಗೆ ಇದೆ ಎಂದು ಪರಿಶೀಲಿಸಿತು.

ಕಡಿಮೆ-ಸುಪ್ತತೆಯ ಎಂಬೆಡಿಂಗ್‌ಗಳು (p50 / p90 / p99 / ಗರಿಷ್ಠ ms)

ನಾವು ಪೂರ್ವ-ಟೋಕನೈಜ್ ಮಾಡಲಾದ ವಿನಂತಿ ಬ್ಯಾಚ್ ಗಾತ್ರ 1, ಸಂಪೂರ್ಣವಾಗಿ ಅನುಕ್ರಮ ವಿನಂತಿಗಳು, 128, 512 ಮತ್ತು 4096 ಟೋಕನ್‌ಗಳ ಅನುಕ್ರಮ ಉದ್ದಗಳಿಗಾಗಿ ರನ್‌ಟೈಮ್‌ಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತೇವೆ.

ವಿಸ್ತರಿಸಿ

ಕಡಿಮೆ-ಸುಪ್ತತೆಯ ಸ್ಕೋರಿಂಗ್ (p50 / p90 / p99 / ಗರಿಷ್ಠ ms)

ಪೂರ್ವ-ಟೋಕನೈಜ್ ಮಾಡಲಾದ ವಿನಂತಿ ಬ್ಯಾಚ್ ಗಾತ್ರಗಳು 5, 25 ಮತ್ತು 50, 512 ಟೋಕನ್‌ಗಳ ಅನುಕ್ರಮ ಉದ್ದ.

ವಿಸ್ತರಿಸಿ

ಅಧಿಕ-ಥ್ರೋಪುಟ್ ಎಂಬೆಡಿಂಗ್‌ಗಳು (emb/s)

ವಿನಂತಿ ಬ್ಯಾಚ್ ಗಾತ್ರ 100, ವಿನಂತಿಗಳನ್ನು ಸಲ್ಲಿಸುವ ನಾಲ್ಕು ಏಕಕಾಲಿಕ ಪ್ರಕ್ರಿಯೆಗಳು, 512, 1024 ಮತ್ತು 4096 ಟೋಕನ್‌ಗಳ ಅನುಕ್ರಮ ಉದ್ದಗಳು.

ವಿಸ್ತರಿಸಿ

ಅಧಿಕ-ಕಾನ್‌ಕರೆನ್ಸಿ ಎಂಬೆಡಿಂಗ್‌ಗಳು (p50 / p90 / p99 / ಗರಿಷ್ಠ ms)

ಅನುಕ್ರಮ ಉದ್ದ 512, ಬ್ಯಾಚ್ ಗಾತ್ರ 1, ಆದರೆ ನಾವು 1, 2, 4, 8 ಮತ್ತು 16 ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ. ಈ ಬೆಂಚ್‌ಮಾರ್ಕ್ Ivy ಮತ್ತು Tulip ನಡುವಿನ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಓವರ್‌ಹೆಡ್‌ನೊಂದಿಗೆ, Ivy ಮೂಲಕ ಟೋಕನೈಸೇಶನ್ ವೆಚ್ಚಗಳನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ.

ವಿಸ್ತರಿಸಿ

ತೀರ್ಮಾನ ಮತ್ತು ಭವಿಷ್ಯದ ಕೆಲಸ

Ivy, Tulip ಮತ್ತು ROSEಗಳಿಂದ ಕೂಡಿದ serving infrastructure ನಮಗೆ Perplexityಗಾಗಿ embeddingsಗಳನ್ನು ಕಡಿಮೆ latency ಮತ್ತು ಉತ್ತಮ throughput ಜೊತೆಗೆ ಸೇವೆ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಇದರಿಂದ off-the-shelf solutionsಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ ಹೆಚ್ಚು ನಿಖರ search ದೊರಕುತ್ತದೆ.

ನಿರ್ದಿಷ್ಟ ಮಾದರಿಗಳ ಮೇಲೆ ಗಮನ ಕೇಂದ್ರೀಕರಿಸಿ ಮತ್ತು ಸಂಪೂರ್ಣ ಸ್ಟ್ಯಾಕ್‌ನ ಹೊಣೆ ಹೊರುವ ಮೂಲಕ, ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಲವಚಿಕತೆಯ ನಡುವೆ ಪರಿಣಾಮಕಾರಿ ಸಮತೋಲನ ಸಾಧಿಸಲು ಅಗತ್ಯವಾದ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ; ಹೆಚ್ಚಿನ ಮರುಬಳಕೆ ಸಾಧ್ಯವಾದ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮ Rust primitivesಗಳನ್ನು Python‌ನ ಹೆಚ್ಚು ಸಾಮಾನ್ಯವಾದ modeling code ಜೊತೆಗೆ ಮಿಶ್ರಣ ಮಾಡುತ್ತೇವೆ. vLLM, SGLang, ಮತ್ತು TokenSpeed ಮುಂತಾದ ಅನೇಕ open-source inference enginesಗಳು ತಮ್ಮ stackಗೆ Rust ಮತ್ತು C++ ನಂತಹ ಭಾಷೆಗಳನ್ನು ಏಕೀಕರಿಸುತ್ತಿವೆ. ಕಳೆದ ಎರಡು ವರ್ಷಗಳಲ್ಲಿ ನಾವು Rustನಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ ಹಾಗೂ maintainability ಎರಡರಲ್ಲೂ ಅತ್ಯುತ್ತಮ ಲಾಭಗಳನ್ನು ಪಡೆದಿದ್ದೇವೆ. ನಮ್ಮ embedding implementationನ ಬಹುಭಾಗವನ್ನು ನಮ್ಮ LLM serving stack ಜೊತೆಗೆ ಹಂಚಿಕೊಳ್ಳುವ ಮೂಲಕ, embedding modelsಗಳ ನಿರ್ವಹಣೆಗೆ ಗಮನಾರ್ಹ engineering effort ಅಗತ್ಯವಿಲ್ಲದೆ, throughputನಲ್ಲಿಯೂ ಲಾಭಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ.

ಮಾದರಿಗಳು ವಿಕಸನಗೊಳ್ಳುತ್ತಿದ್ದಂತೆ, CPU-ಬೌಂಡ್ ಮತ್ತು GPU-ಬೌಂಡ್ ಸುಪ್ತತೆ ಎರಡನ್ನೂ ಕಡಿಮೆ ಮಾಡಲು ನಾವು ನಮ್ಮ ಸ್ಟಾಕ್‌ನ ಪ್ರತಿಯೊಂದು ಲೇಯರನ್ನು ಸುಧಾರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. Ivy ಮತ್ತು Tulip ಒಳಗಿನ ನಮ್ಮ ಕಸ್ಟಮ್ gRPC-ಆಧಾರಿತ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ನೆಟ್‌ವರ್ಕ್ ಸುಪ್ತತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಂವಹನವನ್ನುಟ್ವೀಕ್ ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ROSE ಲೆಕ್ಕಾಚಾರದ ಥ್ರೋಪುಟ್ ಅನ್ನು ಸುಧಾರಿಸಲು ಅಡಿಪಾಯವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಾದ್ಯಂತ ಉಚಿತ-ಥ್ರೆಡ್ಡ್ Python ಗಾಗಿ ಬೆಂಬಲವು ಬೆಳೆದಂತೆ, ಓವರ್‌ಹೆಡ್‌ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು Python-Rust ಪರಸ್ಪರ ಕಾರ್ಯಸಾಧ್ಯತೆಯನ್ನು ಮತ್ತಷ್ಟು ಸುಧಾರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಉಲ್ಲೇಖಗಳು

• AI-ಮೊದಲ ಹುಡುಕಾಟ API ಅನ್ನು ಆರ್ಕಿಟೆಕ್ಟಿಂಗ್ ಮತ್ತು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು
• pplx-embed: ವೆಬ್-ಅಳತೆಯ ಮರುಪಡೆಯುವಿಕೆಗಾಗಿ ಅತ್ಯಾಧುನಿಕ ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಗಳು
• ಯೂನಿಗ್ರಾಮ್ ಟೋಕನೈಜರ್ CPU ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುವುದು
• vLLM
• FlashInfer
• FlashAttention

ಉಲ್ಲೇಖ

@online{perplexity2026FastEmbeddingsOnGpus,
  author = {{Perplexity} and Nandor Licker and Sebastian Sepulveda and Phi Hoang and Jerry Ma},
  title = {{Fast embeddings on GPUs}},
  date = {2026-09-04},
  url = {https://www.perplexity.ai/hub/blog/fast-embeddings-on-gpus}
}