AWS Bedrock ਦੇ 33 ਰੀਜਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ—us-west-2—ਤੁਹਾਨੂੰ 70-ਬਿਲੀਅਨ-ਪੈਰਾਮੀਟਰ ਵਾਲੇ Llama 3.3 ਮਾਡਲ ਨੂੰ fine-tune ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਜਾਂ ਤਾਂ cross-region ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਜੋੜਨਾ ਪਵੇਗਾ ਜਾਂ ਫਿਰ ਇੱਕ ਮੁਸ਼ਕਲ workaround ਨਾਲ ਸਮਝੌਤਾ ਕਰਨਾ ਪਵੇਗਾ।

ਇਹ ਖੋਜ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

AWS ਦਾ ਪਬਲਿਕ ਪ੍ਰਾਈਸਿੰਗ ਪੇਜ ਅਜੇ ਵੀ ਪੁਰਾਣੀ Llama 2 ਸੀਰੀਜ਼ ਲਈ ਟ੍ਰੇਨਿੰਗ ਲਾਗਤਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ। ਨਵੇਂ Llama 3.1 ਅਤੇ 3.3 ਪਰਿਵਾਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗਾਇਬ ਹਨ। ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਪੈ ਰਿਹਾ ਹੈ ਕਿ ਕਿਹੜੇ ਰੀਜਨ ਅਸਲ ਵਿੱਚ fine-tuning ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਕੰਮ (jobs) ਕਿੰਨਾ ਸਮਾਂ ਕਿਊਅ (queues) ਵਿੱਚ ਰਹਿਣਗੇ, ਅਤੇ ਕੀ idle ਸਮੇਂ ਲਈ ਬਿਲਿੰਗ ਕੀਤੀ ਜਾਵੇਗੀ।

ਅਸਲ ਅੰਕੜੇ

  • us-west-2 – ਇਕਲੌਤਾ ਰੀਜਨ ਜਿੱਥੇ Llama 3.3 70B fine-tuning ਕੰਮ ਕਰਦੀ ਹੈ।
  • us-east-1 – ਸਿਰਫ਼ Amazon ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਮਾਡਲ; ਕੋਈ Llama ਜਾਂ Anthropic fine-tuning ਨਹੀਂ।
  • eu-west-2 (London) – ਇੱਕ ਸਿੰਗਲ, non-Llama ਮਾਡਲ ਨੂੰ fine-tune ਕਰਦਾ ਹੈ।
  • ਬਾਕੀ ਸਾਰੇ ਰੀਜਨ – Llama 3.3 70B ਲਈ “model not available” ਐਰਰ ਦਿੰਦੇ ਹਨ।

ਜੇਕਰ ਤੁਹਾਨੂੰ ਇੱਕ custom-tuned Llama 3.3 70B ਦੀ ਲੋੜ ਹੈ, ਤਾਂ job ਨੂੰ us-west-2 ਵਿੱਚ ਚਲਾਓ ਅਤੇ ਡੇਟਾ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੀਜਨਾਂ ਵਿੱਚ ਭੇਜੋ, ਜਾਂ “Custom Model Import” ਦਾ ਰਸਤਾ ਅਜ਼ਮਾਓ, ਜਿਸ ਵਿੱਚ ਲੇਖਕ ਦੀ ਕੋਸ਼ਿਸ਼ ਇੱਕ ਆਮ hardware error ਕਾਰਨ ਫੇਲ੍ਹ ਹੋ ਗਈ।

Custom Model Import: ਇੱਕ ਜੋਖਮ ਭਰਿਆ ਰਸਤਾ

AWS ਦਸਤਾਵੇਜ਼ਾਂ (docs) ਦਾ ਦਾਅਵਾ ਹੈ ਕਿ “Custom Model Import” 200 GB ਤੋਂ ਘੱਟ ਦੇ weights ਨੂੰ eu-central-1 ਸਮੇਤ ਕਿਸੇ ਵੀ ਰੀਜਨ ਵਿੱਚ ਲਿਆ ਸਕਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ, Llama 3.3 70B (ਜੋ ਕਿ ਇਸ ਆਕਾਰ ਤੋਂ ਕਿਤੇ ਵੱਧ ਹੈ) ਨੂੰ import ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਵਾਰ-ਵਾਰ “hardware error” ਦਾ ਸਾਹਮਣਾ ਕਰਦੀਆਂ ਹਨ। ਫਿਲਹਾਲ, ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ native us-west-2 fine-tuning endpoint ਹੀ ਹੈ।

ਦੋ ਤਰੀਕੇ ਜੋ ਪੈਸੇ (ਅਤੇ ਮਾਨਸਿਕ ਸ਼ਾਂਤੀ) ਬਚਾਉਂਦੇ ਹਨ

  1. ਉੱਪਰਲੇ ਪੱਧਰ ਦੇ “InProgress” ਫਲੈਗ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਇੱਕ job ਘੰਟਿਆਂ ਬੱਧੀ AWS-managed queue ਵਿੱਚ ਉਸੇ ਸਟੇਟਸ ਦੇ ਨਾਲ ਰਹਿ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕੋਈ compute ਨਹੀਂ ਚੱਲ ਰਿਹਾ ਹੁੰਦਾ। ਬਿਲਿੰਗ ਉਦੋਂ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ nested trainingDetails ਫੀਲਡ “Running” ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। Idle queue ਸਮੇਂ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਤੋਂ ਬਚਣ ਲਈ ਅੰਦਰਲੇ ਫਲੈਗ ਦੀ ਜਾਂਚ ਕਰੋ।
  2. ਧੀਰਜ ਬੇਸਬਰੀ (impatience) ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ। ਇੱਕ ਟੈਸਟ job ਟ੍ਰੇਨਿੰਗ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ 23 ਘੰਟਿਆਂ ਤੱਕ queue ਵਿੱਚ ਰਹੀ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਪੂਰੀ ਹੋ ਗਈ। ਇਸ ਨੂੰ ਬੰਦ (kill) ਕਰਕੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਇਹ ਲਾਈਨ ਦੇ ਸਭ ਤੋਂ ਪਿੱਛੇ ਚਲੀ ਗਈ, ਜਿਸ ਨਾਲ ਕੁੱਲ ਉਡੀਕ ਦਾ ਸਮਾਂ ਵਧ ਗਿਆ। Queue ਸਮਾਂ ਮੁਫ਼ਤ ਹੈ; ਖਰਚਾ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ GPU instances ਚਾਲੂ ਹੁੰਦੇ ਹਨ।

ਖੇਤਰ ਦੇ ਹੋਰ ਸਬਕ

  • Model schemas ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। Llama 3.3 ਅਤੇ Llama 3.1 ਵੱਖ-ਵੱਖ configuration objects ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਇੱਕ ਵਰਜ਼ਨ ਤੋਂ ਦੂਜੇ ਵਿੱਚ JSON schema ਨੂੰ copy-paste ਕਰਨ ਨਾਲ validation errors ਆਉਂਦੇ ਹਨ, ਭਾਵੇਂ ਕਿ token length ਵਰਗੀਆਂ ਸੀਮਾਵਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਹੋਣ।
  • Quota ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ। “Custom models with a creating status” ਦੀ ਸੀਮਾ ਅਕਸਰ ਸਮੁੱਚੇ job quota ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ “quota exceeded” ਐਰਰ ਮਿਲਦਾ ਹੈ ਜਦੋਂ ਕਿ ਪਿਛਲਾ job ਅਜੇ ਵੀ “creating” ਦਿਖਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਨਵਾਂ job ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਰਾਣੀ ਐਂਟਰੀ ਨੂੰ ਡਿਲੀਟ ਕਰ ਦਿਓ।
  • Storage ਵਧਦਾ ਜਾਂਦਾ ਹੈ। ਹਰ fine-tuned checkpoint S3 storage ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਿਸਦਾ ਬਿੱਲ ਸਟੈਂਡਰਡ ਰੇਟਾਂ 'ਤੇ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। ਪੁਰਾਣੇ ਵਰਜ਼ਨਾਂ ਨੂੰ ਬਿਨਾਂ ਵਰਤੋਂ ਦੇ ਰੱਖਣ ਨਾਲ ਤੁਹਾਡਾ ਮਹੀਨਾਵਾਰ ਬਿੱਲ ਵਧ ਜਾਂਦਾ ਹੈ ਜਿਸਦਾ ਕੋਈ ਫਾਇਦਾ ਨਹੀਂ ਹੁੰਦਾ।

ਨਿਚੋੜ

ਜੇਕਰ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਇੱਕ fine-tuned Llama 3.3 70B ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਉਸ ਕਦਮ ਨੂੰ us-west-2 ਵਿੱਚ ਚਲਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾਓ, ਜਾਂ custom imports ਦੇ ਨਾਲ trial-and-error ਲਈ ਤਿਆਰ ਰਹੋ। Queue ਸਟੇਟਸ ਦੀ ਬਾਰੀਕੀ ਨਾਲ ਜਾਂਚ ਕਰੋ, ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਉਡੀਕ ਕਰ ਰਹੇ jobs ਨੂੰ ਰੋਕਣ ਤੋਂ ਬਚੋ, ਅਤੇ storage ਤੇ quota ਦੀ ਵਰਤੋਂ 'ਤੇ ਨੇੜੇ ਤੋਂ ਨਜ਼ਰ ਰੱਖੋ।