ಆನ್-ಪ್ರೇಮ್, VPC ಮತ್ತು ಓಪನ್‌ವೇಟ್ ಹೋಸ್ಟಿಂಗ್

ಲಾಭಗಳು:

• ನಿರ್ವಹಿಸಿದ API, VPC ಮತ್ತು ಆನ್-ಪ್ರೇಮ್ ಹೋಸ್ಟಿಂಗ್ ನಡುವಿನ ವ್ಯಾಪಾರ-ವಹಿವಾಟುಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಸಾಮರ್ಥ್ಯ
• ಡೇಟಾ ಸಾರ್ವಭೌಮತ್ವ, ಪರಿಮಾಣ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಸಾಮರ್ಥ್ಯದ ಆಧಾರದ ಮೇಲೆ ಹೋಸ್ಟಿಂಗ್ ಅನ್ನು ನಿರ್ಧರಿಸುವ ಸಾಮರ್ಥ್ಯ
• ಸಂಪೂರ್ಣ ವಸ್ತುಗಳು ಮತ್ತು ವಿನ್ಯಾಸ ಹೈಬ್ರಿಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನೊಂದಿಗೆ ಮಾಲೀಕತ್ವದ ಒಟ್ಟು ವೆಚ್ಚವನ್ನು (TCO) ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಸಾಮರ್ಥ್ಯ

ಕೆಲವು ಸಂಸ್ಥೆಗಳಿಗೆ, "ಒದಗಿಸುವವರಿಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದು" - ಎಷ್ಟೇ ಸುರಕ್ಷಿತವಾಗಿದ್ದರೂ - ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ. ರಕ್ಷಣಾ ಉದ್ಯಮ, ಸಾರ್ವಜನಿಕ, ಬ್ಯಾಂಕಿಂಗ್ ಮತ್ತು ಕೆಲವು ಆರೋಗ್ಯ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ, ಡೇಟಾವು ಎಂದಿಗೂ ಸಂಸ್ಥೆಯ ಗಡಿಯನ್ನು ಮೀರಿ ಹೋಗಬಾರದು. ಈ ಹಂತದಲ್ಲಿ, ನಿಮ್ಮ ಸ್ವಂತ ಮಾದರಿಯನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವುದು ಮುಂಚೂಣಿಗೆ ಬರುತ್ತದೆ: ತೆರೆದ ತೂಕದ ಮಾದರಿಗಳು, ನಿಮ್ಮ ಸ್ವಂತ ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕ್ (VPC) ಅಥವಾ ನಿಮ್ಮ ಸ್ವಂತ ಸರ್ವರ್‌ಗಳಲ್ಲಿ (ಆನ್-ಪ್ರೇಮ್) ಚಾಲನೆಯಲ್ಲಿದೆ. ಈ ಘಟಕದಲ್ಲಿ ನಾವು ನಿರ್ವಹಿಸಿದ API ಮತ್ತು ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್ ನಡುವಿನ ವಹಿವಾಟುಗಳನ್ನು ಕಲಿಯುತ್ತೇವೆ, ಅದು ಅರ್ಥಪೂರ್ಣವಾದಾಗ ಮತ್ತು ಮಾಲೀಕತ್ವದ ಒಟ್ಟು ವೆಚ್ಚ (TCO).

ಪರಿಕಲ್ಪನೆಗಳು

• ನಿರ್ವಹಿಸಿದ API: ಮಾದರಿ ಪೂರೈಕೆದಾರರ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ರನ್ ಆಗುತ್ತದೆ; ನೀವು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಿರಿ. ಕಾರ್ಯಾಚರಣೆಯ ಓವರ್ಹೆಡ್ ಕಡಿಮೆಯಾಗಿದೆ, ಆದರೆ ಡೇಟಾವು ಒದಗಿಸುವವರಿಗೆ ಹೋಗುತ್ತದೆ.
• ಮುಕ್ತ-ತೂಕದ ಮಾದರಿ: ಮಾದರಿ ನಿಯತಾಂಕಗಳನ್ನು (ತೂಕಗಳು) ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು; ನೀವು ಅದನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಯಂತ್ರಾಂಶದಲ್ಲಿ ಚಲಾಯಿಸಬಹುದು. ಇದು "ಓಪನ್ ಸೋರ್ಸ್" (ಪರವಾನಗಿ ವಿಭಿನ್ನವಾಗಿರಬಹುದು) ಯಂತೆಯೇ ಇರಬೇಕಾಗಿಲ್ಲ.
• VPC ಹೋಸ್ಟಿಂಗ್ (ವರ್ಚುವಲ್ ಪ್ರೈವೇಟ್ ಕ್ಲೌಡ್): ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರತ್ಯೇಕವಾದ ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಮಾದರಿಯನ್ನು ರನ್ ಮಾಡುವುದು; ಡೇಟಾವು ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಗಡಿಯಲ್ಲಿ ಉಳಿದಿದೆ, ಆದರೆ ಮೂಲಸೌಕರ್ಯವು ಇನ್ನೂ ಕ್ಲೌಡ್‌ನಲ್ಲಿದೆ.
• ಆನ್-ಪ್ರೇಮ್ (ಆವರಣದಲ್ಲಿ): ನಿಮ್ಮ ಸ್ವಂತ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿನ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಮಾದರಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ರನ್ ಮಾಡುವುದು; ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣ, ಹೆಚ್ಚಿನ ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆ.

ಎಚ್ಚರಿಕೆ: "ಸ್ವಂತ ಹೋಸ್ಟಿಂಗ್ ಯಾವಾಗಲೂ ಸುರಕ್ಷಿತವಾಗಿದೆ" ಎಂಬುದು ತಪ್ಪು ಕಲ್ಪನೆ. ನೀವು ಡೇಟಾವನ್ನು ಎಲ್ಲಿ ಇರಿಸುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಸುರಕ್ಷತೆಯು ಕಡಿಮೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ನಿರ್ವಹಿಸುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಪ್ರಬುದ್ಧ ನಿರ್ವಹಿಸಿದ API ಗಿಂತ ಪ್ಯಾಚ್ ಮಾಡದ, ಕಳಪೆಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಆನ್-ಪ್ರೇಮ್ ಸರ್ವರ್ ಅಪಾಯಕಾರಿಯಾಗಿದೆ.

ನಿರ್ಧಾರದ ಅಕ್ಷ: ಯಾವಾಗ?

ಮೂರು ಪ್ರಶ್ನೆಗಳು ನಿರ್ಧಾರವನ್ನು ನಿರ್ದೇಶಿಸುತ್ತವೆ:

1. ಡೇಟಾ ಸಾರ್ವಭೌಮತ್ವ: ಕಾನೂನು ಅಥವಾ ಒಪ್ಪಂದವು ಸಂಸ್ಥೆ/ದೇಶವನ್ನು ತೊರೆಯದಂತೆ ಡೇಟಾವನ್ನು ನಿಷೇಧಿಸುತ್ತದೆಯೇ? ಹೌದು ಎಂದಾದರೆ, ನಿಮ್ಮನ್ನು VPC/on-prem ಕಡೆಗೆ ತಳ್ಳಲಾಗುತ್ತದೆ.
2. ವಾಲ್ಯೂಮ್ ಮತ್ತು ವೆಚ್ಚ: ಬಳಕೆ ತುಂಬಾ ಹೆಚ್ಚಿದೆಯೇ ಮತ್ತು ಊಹಿಸಬಹುದೇ? ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್‌ನ ಅತಿ ಹೆಚ್ಚಿನ ಸಂಪುಟಗಳು ಯುನಿಟ್ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು; ಕಡಿಮೆ/ಅನಿಯಮಿತ ಪರಿಮಾಣದಲ್ಲಿ ನಿರ್ವಹಿಸಲಾದ API ಯಾವಾಗಲೂ ಅಗ್ಗವಾಗಿದೆ.
3. ಕಾರ್ಯಾಚರಣೆಯ ಸಾಮರ್ಥ್ಯ: GPU ಮೂಲಸೌಕರ್ಯ, ಮಾದರಿ ನವೀಕರಣ, ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಭದ್ರತಾ ಪ್ಯಾಚಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ನೀವು ತಂಡವನ್ನು ಹೊಂದಿದ್ದೀರಾ? ಇಲ್ಲದಿದ್ದರೆ ನಿಮ್ಮ ಸ್ವಂತ ಹೋಸ್ಟಿಂಗ್ ಒಂದು ಗುಪ್ತ ವೆಚ್ಚವಾಗಿದೆ.

ಟ್ರೇಡ್ಆಫ್ ಟೇಬಲ್

ಗಾತ್ರ

ನಿರ್ವಹಿಸಿದ API

VPC

ಆನ್-ಪ್ರೇಮ್ (ತೆರೆದ ತೂಕ)

ಡೇಟಾ ಸಾರ್ವಭೌಮತ್ವ

ಒದಗಿಸುವವರನ್ನು ನಂಬಿರಿ

ಹೆಚ್ಚು (ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಮಿತಿಯಲ್ಲಿ)

ಅತ್ಯಧಿಕ (ಎಂದಿಗೂ ಏರುವುದಿಲ್ಲ)

ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆ

ತುಂಬಾ ಕಡಿಮೆ

ಮಧ್ಯಮ

ಹೆಚ್ಚು

ಆರಂಭಿಕ ವೆಚ್ಚ

ಕಡಿಮೆ (ನೀವು ಹೋದಂತೆ ಪಾವತಿಸಿ)

ಮಧ್ಯಮ

ಹೈ (ಹಾರ್ಡ್‌ವೇರ್)

ಸ್ಕೇಲಿಂಗ್

ಸ್ವಯಂಚಾಲಿತ

ನಿರ್ವಹಿಸಲಾಗಿದೆ

ನಿಮ್ಮ ಜವಾಬ್ದಾರಿ

ಮಾದರಿ ಗುಣಮಟ್ಟ/ಕರೆನ್ಸಿ

ಹೊಸ, ಸ್ವಯಂಚಾಲಿತ

ಅವಲಂಬಿತವಾಗಿದೆ

ನೀವು ನವೀಕರಿಸಿ

ನಿಯಂತ್ರಣ

ಕಡಿಮೆ

ಹೆಚ್ಚು

ಪೂರ್ಣ

ಹಂತ ಹಂತವಾಗಿ: ಹೋಸ್ಟಿಂಗ್ ನಿರ್ಧಾರ

1. ಡೇಟಾ ವರ್ಗವನ್ನು ನಿರ್ಧರಿಸಿ. ಯಾವ ಗೌಪ್ಯತೆಯ ಮಟ್ಟದಲ್ಲಿ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ?
2. ಕಾನೂನು ನಿರ್ಬಂಧವನ್ನು ಪರಿಶೀಲಿಸಿ. ಡೇಟಾ ಹೊರಬರಬಹುದೇ? (ಕೆವಿಕೆಕೆ, ವಲಯ ನಿಯಂತ್ರಣ, ಒಪ್ಪಂದ.)
3. ಪರಿಮಾಣವನ್ನು ಅಂದಾಜು ಮಾಡಿ. ಮಾಸಿಕ ವಿನಂತಿ/ಟೋಕನ್ ಪರಿಮಾಣ ಮತ್ತು ಬೆಳವಣಿಗೆಯ ರೇಖೆ.
4. TCO ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ. GPU ಮಾತ್ರವಲ್ಲ; ಶಕ್ತಿ, ನಿರ್ವಹಣೆ, ತಂಡ, ಭದ್ರತೆ, ಪುನರಾವರ್ತನೆ.
5. ಹೈಬ್ರಿಡ್ ಎಂದು ಯೋಚಿಸಿ. ಆನ್-ಪ್ರೇಮ್/ವಿಪಿಸಿಯಲ್ಲಿ ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಹೈಬ್ರಿಡ್ ಮಾದರಿ ಮತ್ತು ನಿರ್ವಹಿಸಲಾದ API ನಲ್ಲಿ ಸೂಕ್ಷ್ಮವಲ್ಲದ ಡೇಟಾವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.

ನಾಲ್ಕು ನಕಲು ಮಾಡಬಹುದಾದ ಟೆಂಪ್ಲೇಟ್‌ಗಳು

ಹೋಸ್ಟಿಂಗ್ ನಿರ್ಧಾರ ಪ್ರಾಂಪ್ಟ್:

ಕೆಳಗಿನ ಬಳಕೆಗಾಗಿ ಹೋಸ್ಟಿಂಗ್ ಅನ್ನು ನಿರ್ಧರಿಸಿ: {{ ಸನ್ನಿವೇಶ }}ಪ್ರಶ್ನೆಗಳು:- ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾದ ಡೇಟಾದ ಗೌಪ್ಯತೆ ವರ್ಗ ಯಾವುದು? (ಸಾರ್ವಜನಿಕ/ಆಂತರಿಕ/ಗೌಪ್ಯ/ಉನ್ನತ ರಹಸ್ಯ)- ಕಾನೂನು/ಒಪ್ಪಂದವು ಸಂಸ್ಥೆಯ ಹೊರಗೆ ಡೇಟಾವನ್ನು ಹೋಗಲು ಅನುಮತಿಸುವುದೇ?- ಮಾಸಿಕ ಪರಿಮಾಣದ ಮುನ್ಸೂಚನೆ ಮತ್ತು ಭವಿಷ್ಯ?- ಕಾರ್ಯಾಚರಣೆಗಳು/ಜಿಪಿಯು ತಂಡದ ಸಾಮರ್ಥ್ಯವಿದೆಯೇ? ಶಿಫಾರಸು: "ನಿರ್ವಹಿಸಿದ API / VPC / ಆನ್-ಪ್ರೇಮ್ / ಹೈಬ್ರಿಡ್" + ಸಮರ್ಥನೆ.

TCO ಐಟಂ ಪಟ್ಟಿ (ಸ್ವಯಂ ಹೋಸ್ಟಿಂಗ್‌ಗಾಗಿ):

ಮಾಲೀಕತ್ವದ ಒಟ್ಟು ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ:- ಹಾರ್ಡ್‌ವೇರ್ (GPU) ಖರೀದಿ/ಗುತ್ತಿಗೆ- ಶಕ್ತಿ ಮತ್ತು ಕೂಲಿಂಗ್- ಮಾನವ: MLOps + ಭದ್ರತಾ ತಂಡದ ಸಮಯ- ಮಾದರಿ ನವೀಕರಣ ಮತ್ತು ಪರೀಕ್ಷೆ ಕಾರ್ಯಪಡೆ- ಪುನರುಕ್ತಿ/ವಿಪತ್ತು ಮರುಪಡೆಯುವಿಕೆ- ಭದ್ರತಾ ಪ್ಯಾಚಿಂಗ್ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಇದನ್ನು 12-24 ತಿಂಗಳ ಹಾರಿಜಾನ್‌ನಲ್ಲಿ ನಿರ್ವಹಿಸಲಾದ API ಗಾಗಿ ಮಾಸಿಕ ಬಿಲ್‌ಗೆ ಹೋಲಿಸಿ.

ಹೈಬ್ರಿಡ್ ರೂಟಿಂಗ್ ನಿಯಮ:

ಡೇಟಾ ವರ್ಗದ ಆಧಾರದ ಮೇಲೆ ಪ್ರತಿ ವಿನಂತಿಯನ್ನು ರೂಟ್ ಮಾಡಿ:- "ರಹಸ್ಯ / ಉನ್ನತ ರಹಸ್ಯ" ಡೇಟಾ -> ಆನ್-ಪ್ರೇಮ್/ವಿಪಿಸಿ ಮಾದರಿ- "ಸಾರ್ವಜನಿಕ / ಆಂತರಿಕ" ಡೇಟಾ -> ನಿರ್ವಹಿಸಲಾದ API (ಹೆಚ್ಚು ಶಕ್ತಿಯುತ/ಅಗ್ಗದ) ಆಡಿಟ್ ಲಾಗ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ನಿರ್ಧಾರ ಮತ್ತು ಡೇಟಾ ವರ್ಗವನ್ನು ಬರೆಯಿರಿ.

ತೂಕ ಭದ್ರತಾ ಚೆಕ್ ಪ್ರಾಂಪ್ಟ್ ತೆರೆಯಿರಿ:

ನಮ್ಮ ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಮಾದರಿಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ:- ಪರವಾನಗಿಯು ವಾಣಿಜ್ಯ ಬಳಕೆಯನ್ನು ಮತ್ತು ನಮ್ಮ ಸನ್ನಿವೇಶದಲ್ಲಿ ಅನುಮತಿಸುವುದೇ?- ವಿಶ್ವಾಸಾರ್ಹ ಮೂಲದಿಂದ ಮಾದರಿ ತೂಕ, ಸಮಗ್ರತೆ (ಹ್ಯಾಶ್) ಪರಿಶೀಲಿಸಲಾಗಿದೆಯೇ?- ಸರ್ವರ್ ಪ್ಯಾಚಿಂಗ್, ನೆಟ್‌ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆ, ಪ್ರವೇಶ ನಿಯಂತ್ರಣವನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆಯೇ?- ನಿರ್ವಹಿಸಿದ API ನಂತೆ ಪ್ರಬುದ್ಧವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಲಾಗ್ ಮಾಡಲಾಗುತ್ತಿದೆಯೇ? ಯಾವುದೇ ಕಾಣೆಯಾದ ಐಟಂಗಳನ್ನು "ಆನ್" ಎಂದು ಗುರುತಿಸಿ.

ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್

ಕಳಪೆ ವಿಧಾನ

ಬಲವಾದ ವಿಧಾನ

"ಆನ್-ಪ್ರೇಮ್ ಸುರಕ್ಷಿತವಾಗಿದೆ, ಯಾವಾಗಲೂ ಇದನ್ನು ಬಳಸಿ"

ಡೇಟಾ ಸಾರ್ವಭೌಮತ್ವ + ಪರಿಮಾಣ + ಸಾಮರ್ಥ್ಯದ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಧಾರ

ಕೇವಲ GPU ವೆಚ್ಚವನ್ನು ನೋಡುತ್ತಿದೆ

ಪೂರ್ಣ TCO (ಶಕ್ತಿ, ಸಿಬ್ಬಂದಿ, ನವೀಕರಣಗಳು, ಭದ್ರತೆ)

ಒಂದೇ ಹೋಸ್ಟಿಂಗ್ ಮಾದರಿಗೆ ಲಾಕ್ ಮಾಡಲಾಗುತ್ತಿದೆ

ಹೈಬ್ರಿಡ್: ಡೇಟಾ ವರ್ಗದ ಮೂಲಕ ರೂಟಿಂಗ್

ತೆರೆದ ತೂಕವನ್ನು ಕಡಿಮೆ ಮಾಡದೆ ಮತ್ತು ಅದನ್ನು ಪರಿಶೀಲಿಸದೆ ಓಡುವುದು

ಪರವಾನಗಿ + ಸಮಗ್ರತೆ + ಪ್ಯಾಚ್ + ಜಾಡಿನ ನಿಯಂತ್ರಣ

ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು

ಪ್ರಕರಣ 1 - ಪ್ರೇಮ್ ಆದೇಶವು ಸರಿಯಾದ ನಿರ್ಧಾರವಾಗಿದೆ. ರಕ್ಷಣಾ ಗುತ್ತಿಗೆದಾರನು ಹೆಚ್ಚು ವರ್ಗೀಕೃತ ದಾಖಲೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾಗಿತ್ತು; ಒಪ್ಪಂದವು ದೇಶದಿಂದ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದನ್ನು ನಿಷೇಧಿಸಿದೆ. ನಿರ್ವಹಿಸಿದ API ಅನ್ನು ಮೊದಲಿನಿಂದಲೂ ತೆಗೆದುಹಾಕಲಾಗಿದೆ. ಆನ್-ಪ್ರೇಮ್ ಮುಕ್ತ ತೂಕದ ಮಾದರಿಯನ್ನು ಸ್ಥಾಪಿಸಲಾಯಿತು; ವೆಚ್ಚವು ಅಧಿಕವಾಗಿತ್ತು, ಆದರೆ ಇದು ಒಂದೇ ಹೊಂದಾಣಿಕೆಯ ಆಯ್ಕೆಯಾಗಿದೆ.

ಪ್ರಕರಣ 2 - ಗೌಪ್ಯ TCO ವ್ಯತಿರಿಕ್ತ ನಿರ್ಧಾರ. "API ದುಬಾರಿಯಾಗಿದೆ" ಎಂಬ ಕಾರಣದಿಂದ ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್‌ಗೆ ಬದಲಾಯಿಸಲು ಪ್ರಾರಂಭಿಕ ಯೋಜಿಸಿದೆ. TCO ಲೆಕ್ಕಾಚಾರದಲ್ಲಿ, ನೀವು GPU ಮಾತ್ರವಲ್ಲ; 2 ಪೂರ್ಣ-ಸಮಯದ MLOps ಇಂಜಿನಿಯರ್‌ಗಳನ್ನು ಸೇರಿಸಿ, ಅಪ್‌ಡೇಟ್ ಲೋಡ್ ಮತ್ತು ಪುನರಾವರ್ತನೆ, ಮತ್ತು 24-ತಿಂಗಳ ಒಟ್ಟು ಮೊತ್ತವು ನಿರ್ವಹಿಸಲಾದ API ಗಿಂತ ದ್ವಿಗುಣವಾಗಿದೆ. ಅವರ ಸಂಪುಟಗಳು ಕಡಿಮೆ ಮತ್ತು ವಿರಳವಾಗಿರುವುದರಿಂದ ಅವರು API ನಲ್ಲಿಯೇ ಇದ್ದರು.

ಪ್ರಕರಣ 3 - ಹೈಬ್ರಿಡ್ ಅತ್ಯುತ್ತಮವಾದದನ್ನು ನೀಡಿದೆ. ಬ್ಯಾಂಕಿನ ಕಾಲ್ ಸೆಂಟರ್ ಅಸಿಸ್ಟೆಂಟ್ ಎರಡು ರೀತಿಯ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಿದ್ದರು: ಸಾಮಾನ್ಯ ಉತ್ಪನ್ನ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಗ್ರಾಹಕ-ನಿರ್ದಿಷ್ಟ ಖಾತೆ ಡೇಟಾ. ಖಾತೆ ಡೇಟಾವನ್ನು VPC ಯೊಳಗಿನ ಮಾದರಿಗೆ ನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ, ಸಾಮಾನ್ಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಶಕ್ತಿಯುತ ನಿರ್ವಹಿಸಿದ API ಗೆ ನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ. ಸೂಕ್ಷ್ಮ ಡೇಟಾ ಎಂದಿಗೂ ಹೊರಬರಲಿಲ್ಲ, ಸಾಮಾನ್ಯ ಪ್ರಶ್ನೆಗಳಿಗೆ ಪ್ರಬಲ ಮಾದರಿಯ ಗುಣಮಟ್ಟವನ್ನು ಬಳಸಲಾಗಿದೆ; ವೆಚ್ಚ ಮತ್ತು ಫಿಟ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಹೊಂದುವಂತೆ ಮಾಡಲಾಗಿದೆ.

ಸಲಹೆ: ನಿರ್ಧಾರವು ಬೈನರಿಯಾಗಿರಬೇಕಾಗಿಲ್ಲ (ಎಲ್ಲಾ ಅಥವಾ ಏನೂ ಇಲ್ಲ). ಹೈಬ್ರಿಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ - ವರ್ಗದ ಮೂಲಕ ರೂಟಿಂಗ್ ಡೇಟಾ - ಏಕಕಾಲದಲ್ಲಿ ಹೆಚ್ಚಿನ ಎಂಟರ್‌ಪ್ರೈಸ್ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಅನುಸರಣೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• "ಸ್ವಂತ ಹೋಸ್ಟಿಂಗ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸುರಕ್ಷಿತವಾಗಿದೆ" ಎಂದು ಊಹಿಸಿ; ಆದರೆ ಸುರಕ್ಷತೆಯು ನಿರ್ವಹಣೆಯ ಗುಣಮಟ್ಟವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.
• TCO ಕೇವಲ GPU ವೆಚ್ಚ ಎಂದು ಯೋಚಿಸುವುದು; ತಂಡ, ಶಕ್ತಿ, ನವೀಕರಿಸುವುದು ಮತ್ತು ಭದ್ರತೆಯನ್ನು ಮರೆತುಬಿಡುವುದು.
• ಕಡಿಮೆ/ಅನಿಯಮಿತ ಪರಿಮಾಣದಲ್ಲಿ ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್‌ಗೆ ಬದಲಾಯಿಸುವುದು ಮತ್ತು ಘಟಕದ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುವುದು.
• ಪರವಾನಗಿ ಮತ್ತು ಸಮಗ್ರತೆಯನ್ನು ಪರಿಶೀಲಿಸದೆ (ಹ್ಯಾಶ್) ತೆರೆದ ತೂಕದ ಮಾದರಿಯನ್ನು ಬಳಸುವುದು.
• ಆನ್-ಪ್ರೇಮ್ ಸರ್ವರ್‌ನಲ್ಲಿ ನಿರ್ವಹಿಸಲಾದ API ನಂತೆ ಪ್ರಬುದ್ಧವಾಗಿ ಮಾನಿಟರಿಂಗ್/ಲಾಗಿಂಗ್ ಅನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುತ್ತಿಲ್ಲ.
• ಹೈಬ್ರಿಡ್ ಆಯ್ಕೆಯನ್ನು ಪರಿಗಣಿಸದೆ ಬೈನರಿ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು.

ಸಾರಾಂಶದಲ್ಲಿ

• ನಿರ್ವಹಿಸಿದ API ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಸುಲಭವಾಗಿದೆ, ಆದರೆ ಡೇಟಾವು ಒದಗಿಸುವವರಿಗೆ ಹೋಗುತ್ತದೆ; VPC/on-prem ನಿಮ್ಮ ಗಡಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಇರಿಸುತ್ತದೆ.
• ಮೂರು ಪ್ರಶ್ನೆಗಳು ನಿರ್ಧಾರವನ್ನು ನಡೆಸುತ್ತವೆ: ಡೇಟಾ ಸಾರ್ವಭೌಮತ್ವ, ಪರಿಮಾಣ/ವೆಚ್ಚದ ಊಹೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಸಾಮರ್ಥ್ಯ.
• "ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್ ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಾಗಿದೆ" ಎಂಬುದು ತಪ್ಪು ಕಲ್ಪನೆ; ಸುರಕ್ಷತೆಯು ನೀವು ಡೇಟಾವನ್ನು ಎಲ್ಲಿ ಇರಿಸುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದಿಲ್ಲ, ಆದರೆ ನೀವು ಅದನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ನಿರ್ವಹಿಸುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.
• ನಿಖರವಾದ TCO ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ: ಶಕ್ತಿ, ತಂಡ, ನವೀಕರಣ, ಪುನರಾವರ್ತನೆ ಮತ್ತು ಭದ್ರತೆ, ಹಾಗೆಯೇ GPU.
• ಹೈಬ್ರಿಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ (ವರ್ಗದ ಪ್ರಕಾರ ರೂಟಿಂಗ್ ಡೇಟಾ) ಏಕಕಾಲದಲ್ಲಿ ಹೆಚ್ಚಿನ ಎಂಟರ್‌ಪ್ರೈಸ್ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಅನುಸರಣೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಸಮತೋಲನಗೊಳಿಸುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ

AI ಬಳಕೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಗೌಪ್ಯತೆ ವರ್ಗಕ್ಕೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಡೇಟಾವನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ಹೋಸ್ಟಿಂಗ್ ನಿರ್ಧಾರದ ಪ್ರಾಂಪ್ಟ್‌ನೊಂದಿಗೆ ಶಿಫಾರಸನ್ನು ರಚಿಸಿ. ನಂತರ ನಿಮ್ಮ ಸ್ವಂತ ಹೋಸ್ಟಿಂಗ್‌ಗಾಗಿ TCO ಐಟಂ ಪಟ್ಟಿಯನ್ನು ಭರ್ತಿ ಮಾಡಿ ಮತ್ತು 24-ತಿಂಗಳ ಒಟ್ಟು ಮೊತ್ತವನ್ನು ನಿರ್ವಹಿಸಿದ API ಬಿಲ್‌ಗೆ ಹೋಲಿಸಿ. ಅಂತಿಮವಾಗಿ, ಡ್ರಾಫ್ಟ್ ಹೈಬ್ರಿಡ್ ರೂಟಿಂಗ್ ನಿಯಮವನ್ನು ಬರೆಯಿರಿ: ಯಾವ ಡೇಟಾ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ?

ಪರಿಶೀಲನಾಪಟ್ಟಿ

• [ ] ನಾನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾದ ಡೇಟಾದ ಗೌಪ್ಯತೆಯ ವರ್ಗ ಮತ್ತು ಕಾನೂನು ನಿರ್ಬಂಧವನ್ನು ನಿರ್ಧರಿಸಿದ್ದೇನೆ.
• [ ] ನಾನು ಸಾರ್ವಭೌಮತ್ವ + ಪರಿಮಾಣ + ಸಾಮರ್ಥ್ಯದ ಆಧಾರದ ಮೇಲೆ ಹೋಸ್ಟಿಂಗ್ ನಿರ್ಧಾರವನ್ನು ಮಾಡಿದ್ದೇನೆ.
• [ ] ನಾನು TCO ಅನ್ನು ಪೂರ್ಣ ಐಟಂಗಳೊಂದಿಗೆ (GPU ಅಲ್ಲದವು ಸೇರಿದಂತೆ) ಲೆಕ್ಕ ಹಾಕಿದ್ದೇನೆ.
• [ ] ನಾನು ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್‌ನಲ್ಲಿ ಪರವಾನಗಿ, ಸಮಗ್ರತೆ, ಪ್ಯಾಚಿಂಗ್ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇನೆ.
• [ ] ನಾನು ಹೈಬ್ರಿಡ್ ರೂಟಿಂಗ್ ಆಯ್ಕೆಯನ್ನು ಪರಿಗಣಿಸಿದ್ದೇನೆ.
• [ ] ನಾನು ನಿರ್ಧಾರ ಮತ್ತು ಅದರ ತಾರ್ಕಿಕತೆಯನ್ನು ದಾಖಲಿಸಿದ್ದೇನೆ.