10 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
SK hynix Memory & Packaging: AI Server Performance Economics
ਜਾਣੋ ਕਿ SK hynix ਦੀ ਮੈਮੋਰੀ ਅਤੇ ਪੈਕੇਜਿੰਗ ਨਵੀਨਤਾਂ HBM ਅਤੇ DDR5 ਲਈ ਕਿਵੇਂ ਏਆਈ ਸਰਵਰ ਦੀ ਗਤੀ, ਪਾਵਰ, ਸਪਲਾਈ ਅਤੇ ਕੁੱਲ ਲਾਗਤ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ।
ਜਾਣੋ ਕਿ SK hynix ਦੀ ਮੈਮੋਰੀ ਅਤੇ ਪੈਕੇਜਿੰਗ ਨਵੀਨਤਾਂ HBM ਅਤੇ DDR5 ਲਈ ਕਿਵੇਂ ਏਆਈ ਸਰਵਰ ਦੀ ਗਤੀ, ਪਾਵਰ, ਸਪਲਾਈ ਅਤੇ ਕੁੱਲ ਲਾਗਤ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ।
ਲੋਕ ਜਦੋਂ ਏਆਈ ਸਰਵਰਾਂ ਬਾਰੇ ਸੋਚਦੇ ਹਨ ਤਾਂ ਉਹ GPUs ਦੀ ਤਸਵੀਰ ਬਣਾਉਂਦੇ ਹਨ। ਪਰ ਅਸਲ ਤੌਰ 'ਤੇ ਕਈ ਤਰ੍ਹਾਂ ਦੀਆਂ ਤਾਕਤਵਾਂ ਵਿੱਚ, ਮੈਮੋਰੀ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਇਹ GPUs ਲਗਾਤਾਰ ਬਿਜੀ ਰਹਿੰਦੇ ਹਨ ਜਾਂ ਉਡਕਦੇ ਰਹਿੰਦੇ ਹਨ। ਟ੍ਰੇਨਿੰਗ ਅਤੇ ਇੰਫਰੰਸ ਦੋਹਾਂ ਹੀ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਚਲਾਉਂਦੇ ਹਨ: ਮਾਡਲ ਵਜ਼ਨ, ਐਕਟੀਵੇਸ਼ਨ, attention caches, embeddings ਅਤੇ ਇਨਪੁੱਟ ਬੈਚ। ਜੇ ਮੈਮੋਰੀ ਸਿਸਟਮ ਡੇਟਾ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਪਹੁੰਚਾ ਸਕਦਾ ਤਾਂ compute ਯੂਨਿਟ ਆਈਡਲ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਮਹਿੰਗੇ ਐਕਸੈਲਰੇਟਰ ਘੰਟਿਆਂ ਵਿੱਚ ਘੱਟ ਕੰਮ ਕਰਦੇ ਹਨ।
GPU compute ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ, ਪਰ ਡੇਟਾ ਮুভਮੈਂਟ मुफ्त ਨਹੀਂ ਵਧਦਾ। GPU memory subsystem (HBM ਅਤੇ ਇਸ ਦੀ ਪੈਕੇਜਿੰਗ) ਅਤੇ ਸਰਵਰ ਦੀ ਮੁੱਖ ਮੈਮੋਰੀ (DDR5) ਮਿਲ ਕੇ ਇਹ ਗੱਲ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ:
ਏਆਈ ਢਾਂਚੇ ਦੀਆਂ ਅਰਥ-ਨੀਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਨਤੀਜਿਆਂ ਪ੍ਰਤੀ ਲਾਗਤ ਯੂਨਿਟ ਨਾਲ ਮਾਪੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: tokens/sec ਪ੍ਰਤੀ ਡਾਲਰ, training steps/day ਪ੍ਰਤੀ ਡਾਲਰ ਜਾਂ ਪ੍ਰਤੀ ਰੈਕ ਪ੍ਰਤੀ ਮਹੀਨਾ ਪੂਰੇ ਹੋਏ jobs।
ਮੈਮੋਰੀ ਉਸ ਸਮੀਕਰਨ ਨੂੰ ਦੋ ਪਾਸਿਆਂ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ:
ਇਹ ਤੱਤ ਇਕ-ਦੂਜੇ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ। ਉੱਚਾ bandwidth ਉਪਯੋਗਿਤਾ ਸੁਧਾਰ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ ਜਦੋਂ ਸਮਰੱਥਾ ਕਾਫੀ ਹੋਵੇ ਤਾਂ ਹੀ ਗਰਮ ਡੇਟਾ ਸਥਾਨਕ ਰਹੇ। ਲੇਟੈਂਸੀ ਉਹਨਾਂ ਤਬ ਖਾਸ ਹੈ ਜਦੋਂ ਐਕਸੈਸ ਪੈਟਰਨ ਅਨਿਯਮਤ ਹੋ (ਕੁਝ ਇੰਫਰੰਸ ਵਰਕਲੋਡਾਂ ਵਿੱਚ ਆਮ)। ਪਾਵਰ ਅਤੇ ਥਰਮਲ ਤਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਪੀਕ ਸਪੈੱਕ ਥਾਂਘਾਂ ਲੰਮੇ ਸਮੇਂ ਲਈ ਕਾਇਮ ਰਹਿ ਸਕਦੇ ਹਨ—ਜੋ ਲੰਬੇ ਟ੍ਰੇਨਿੰਗ ਰਨਾਂ ਅਤੇ ਉੱਚ ਡਿਊਟੀ-ਸਾਈਕਲ ਇੰਫਰੰਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਇਹ ਲੇਖ ਇਹ ਵਿਵਰਣ ਕਰੇਗਾ ਕਿ ਮੈਮੋਰੀ ਅਤੇ ਪੈਕੇਜਿੰਗ ਚੋਣਾਂ ਕਿਸ ਤਰ੍ਹਾਂ ਏਆਈ ਸਰਵਰ throughput ਅਤੇ ਕੁੱਲ ਮਲਕੀਅਤ ਲਾਗਤ (TCO) ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ, ਕਾਰਨ-ਮੁਤਾਬਿਕ ਨਜ਼ਰੀਏ ਨਾਲ। ਇਹ ਭਵਿੱਖੀ ਉਤਪਾਦ ਰੋਡਮੈਪ, ਕੀਮਤਾਂ ਜਾਂ ਵਿਕਰੇਤਾ-ਵਿਸ਼ੇਸ਼ ਉਪਲਬਧਤਾ ਬਾਰੇ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਏਗਾ। ਲਕਸ਼ ਹੈ ਕਿ ਤੁਸੀਂ ਏਆਈ ਸਰਵਰ ਕਨਫਿਗਰੇਸ਼ਨਾਂ ਦੇ ਮੁਲਾਂਕਣ ਵੇਲੇ ਬਿਹਤਰ ਸਵਾਲ ਪੁੱਛ ਸਕੋ।
ਜੇ ਤੁਸੀਂ ਏਆਈ ਸਰਵਰ ਖਰੀਦ ਰਹੇ ਹੋ, ਤਾਂ ਮਦਦਗਾਰ ਹੈ ਕਿ “ਮੈਮੋਰੀ” ਨੂੰ ਉਹਨਾਂ ਪਰਤਾਂ ਦੇ ਇੱਕ ਸਟੈਕ ਵਜੋਂ ਸੋਚੋ ਜੋ compute ਨੂੰ ਡੇਟਾ ਪਹੁੰਚਾਉਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਕੋਈ ਵੀ ਪਰਤ ਤੇਜ਼ੀ ਨਾਲ ਡੇਟਾ ਨਹੀਂ ਦੇ ਸਕਦੀ, ਤਾਂ GPUs ਨਿੱਕੀ-ਨਿੱਕੀ ਢੰਗ ਨਾਲ ਨਹੀਂ ਸੁਸਤ ਹੁੰਦੇ—ਉਹ ਅਕਸਰ ਆਈਡਲ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ ਪਾਵਰ, ਰੈਕ ਸਪੇਸ ਅਤੇ ਐਕਸੈਲਰੇਟਰਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਰਹਿੰਦੇ ਹੋ।
ਉੱਚ-ਸਤਰ ਤੇ, ਇੱਕ ਏਆਈ ਸਰਵਰ ਦਾ ਮੈਮੋਰੀ ਸਟੈਕ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:
ਮੁੱਖ ਵਿਚਾਰ: GPU ਤੋਂ ਹਟਕੇ ਹਰ ਇੱਕ ਕਦਮ ਲੇਟੈਂਸੀ ਵਧਾਂਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ bandwidth ਘਟਾਉਂਦਾ ਹੈ।
ਟ੍ਰੇਨਿੰਗ ਆਮ ਤੌਰ 'ਤੇ GPU ਦੇ ਅੰਦਰ bandwidth ਅਤੇ ਸਮਰੱਥਾ 'ਤੇ ਦਬਾਅ ਪਾਂਦਾ ਹੈ: ਵੱਡੇ ਮਾਡਲ, ਵੱਡੀਆਂ ਐਕਟੀਵੇਸ਼ਨ, ਬਹੁਤ ਪੜ੍ਹਨ/ਲਿਖਣ। ਜੇ ਮਾਡਲ ਜਾਂ ਬੈਚ ਕਨਫਿਗਰੇਸ਼ਨ ਮੈਮੋਰੀ ਨਾਲ ਸੀਮਿਤ ਹਨ, ਤਾਂ ਅਕਸਰ ਤੁਸੀਂ ਘੱਟ GPU ਉਪਯੋਗਿਤਾ ਵੇਖੋਗੇ ਭਾਵੇਂ compute ਲੱਗਦਾ "ਪ੍ਰਯਾਚਾਰਕ" ਹੋਵੇ।
ਇੰਫਰੰਸ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਦਿੱਖ ਸਕਦੀ ਹੈ। ਕੁਝ ਵਰਕਲੋਡ ਮੈਮੋਰੀ-бੈਂਡਵਿਡਥ ਖਪਾਉਂਦੇ ਹਨ (ਲੰਬੇ context ਵਾਲੇ LLMs), ਜਦੋਂਕਿ ਹੋਰ ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੇ ਹਨ (ਛੋਟੇ ਮਾਡਲ, ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ)। ਇੰਫਰੰਸ ਅਕਸਰ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ ਡੇਟਾ GPU ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੇਜ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਕਿੰਨਾ ਚੰਗਾ ਬਹੁਤ ਸਾਰੀਆਂ ਇਕੱਠੀਆਂ ਬੇਨਤੀਆਂ ਦੇ ਦੌਰਾਨ GPU ਨੂੰ ਭਰਦਾ ਹੈ।
ਹੋਰ GPU compute ਜੋੜਨਾ ਹੋਰ ਕੈਸ਼ਿਯਰਾਂ ਜੋੜਨ ਵਾਂਗ ਹੈ। ਜੇ "ਸਟਾਕ ਰੂਮ" (ਮੈਮੋਰੀ ਸਬਸਿਸਟਮ) ਚੀਜ਼ਾਂ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਪਹੁੰਚਾ ਰਹੀ, ਤਾਂ ਵਧੇਰੇ ਕੈਸ਼ਿਯਰ throughput ਨਹੀਂ ਵਧਾਉਂਦੇ।
ਬੈਂਡਵਿਡਥ ਦੀ ਕਮੀ ਮਹਿੰਗੀਆਂ ਹੈਂ ਕਿਉਂਕਿ ਇਹ ਸਿਸਟਮ ਦੇ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਹਿੱਸਿਆਂ—GPU ਘੰਟੇ, ਪਾਵਰ ਹੈਡਰੂਮ, ਅਤੇ ਕਲਸਟਰ ਪੁੰਜ—ਨੂੰ ਵੇਖਦੇ ਹੋਏ ਸੁਨਾਹਰੀ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦੀ ਹੈ। ਇਸ ਲਈ ਖਰੀਦਦਾਰਾਂ ਨੂੰ ਮੈਮੋਰੀ ਸਟੈਕ ਨੂੰ ਇੱਕ ਪ੍ਰਣਾਲੀ ਵਜੋਂ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਲੱਗ-ਅਲੱਗ ਲਾਇਨਾਂ ਵਜੋਂ ਨਹੀਂ।
High Bandwidth Memory (HBM) ਅਜੇ ਵੀ "DRAM" ਹੈ, ਪਰ ਇਹ DDR5 ਸਟਿਕਾਂ ਵਰਗੇ ਆਮ DRAM ਨਾਲ ਬਹੁਤ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਬਣੀ ਅਤੇ ਜੋੜੀ ਜਾਂਦੀ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਸਭ ਤੋਂ ਘੱਟ ਲਾਗਤ 'ਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਰੱਥਾ ਨਹੀਂ—ਇਹ ਬਹੁਤ ਉੱਚ memory bandwidth ਇੱਕ ਛੋਟੀ ਫੁੱਟਪ੍ਰਿੰਟ ਵਿੱਚ, accelerator ਦੇ ਨੇੜੇ, ਮੁਹੱਈਆ ਕਰਵਾਉਣਾ ਹੈ।
HBM ਕਈ DRAM ਡਾਈਜ਼ ਨੂੰ ਉੱਲ ਦਿਸ਼ਾ ਵਿੱਚ ਸਟੈਕ ਕਰਦਾ ਹੈ (ਇਕ ਲੇਅਰ ਕੇਕ ਵਾਂਗ) ਅਤੇ TSVs ਵਰਗੀਆਂ ਸੰਘਣੀ vertical connections ਵਰਤਦਾ ਹੈ ਤਾਂ ਜੋ ਲੇਅਰਾਂ ਵਿੱਚ ਡੇਟਾ ਚਲ ਸਕੇ। DDR ਵਰਗੇ ਸੰਗੀਨ, ਉੱਚ-ਗਤੀ ਚੈਨਲ 'ਤੇ ਨਿਰਭਰ ਹੋਣ ਦੀ ਬਜਾਏ, HBM ਇਕ ਬਹੁਤ ਚੌੜੀ ਇੰਟਰਫੇਸ ਵਰਤਦਾ ਹੈ। ਇਸ ਚੌੜਾਈ ਨਾਲ ਤੁਹਾਨੂੰ ਇੱਕ package ਪ੍ਰਤੀ ਬਹੁਤ ਵੱਡਾ bandwidth ਮਿਲਦਾ ਹੈ ਬਿਨਾਂ ਅਤਿਅਧਿਕ ਘੜੀ ਦਰਾਂ ਦੀ ਲੋੜ ਤੋਂ।
ਅਮਲ ਵਿੱਚ, ਇਹ "ਚੌੜਾ-ਅਤੇ-ਨੇੜੇ" ਡਿਜ਼ਾਇਨ ਸੂਚਨਾ ਸਿਗਨਲਾਂ ਦੀ ਦੂਰੀ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ GPU/accelerator ਨੂੰ ਡੇਟਾ ਇੰਨਾ ਤੇਜ਼ੀ ਨਾਲ ਖਿੱਚਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਕਿ ਉਸ ਦੇ compute ਯੂਨਿਟ ਬਿਜੀ ਰਹਿ ਸਕਣ।
ਟ੍ਰੇਨਿੰਗ ਅਤੇ ਸਰਵਿੰਗ ਵੱਡੇ ਮਾਡਲਾਂ ਲਈ ਤੇਰਬ-ਤੇਰਬ ਟੈਂਸਰਾਂ ਨੂੰ ਇੱਕ-ਵਾਰ ਫਿਰ-ਫਿਰ ਕੇ ਮੈਮੋਰੀ ਵਿੱਚ ਲਿਜਾਇਆ ਜਾਂਦਾ ਹੈ। ਜੇ compute ਮੈਮੋਰੀ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਵਧੇਰੇ GPU ਕੋਰ ਜੋੜਨ ਨਾਲ ਬਹੁਤ ਫ਼ਾਇਦਾ ਨਹੀਂ। HBM ਇਸ ਬੋਤਲ-ਨੈਕ ਨੂੰ ਘਟਾਉਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਸ ਲਈ ਇਹ ਆਧੁਨਿਕ AI accelerators 'ਤੇ ਮਿਆਰੀ ਹੈ।
HBM ਪ੍ਰਦਰਸ਼ਨ ਮੁਫ਼ਤ ਨਹੀਂ ਆਉਂਦਾ। compute package ਨਾਲ ਤੰਗ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਹੇਠਾਂ ਹਕੀਕਤਨ ਘਟਨਾਵਾਂ ਬਣਾਉਂਦੀ ਹੈ:
HBM ਉਨ੍ਹਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ ਚਮਕਦਾ ਹੈ ਜਿੱਥੇ bandwidth ਸੀਮਿਤ ਹੈ। ਪਰ capacity-heavy workloads—ਵੱਡੇ ਇਨ-ਮੇਮੋਰੀ ਡੇਟਾਬੇਸ, ਵੱਡੇ CPU-ਪਾਸੇ caches, ਜਾਂ ਉਹ ਕੰਮ ਜੋ RAM ਦੀ ਬਹੁਤ ਲੋੜ ਰੱਖਦੇ ਹਨ—ਲਈ HBM ਵਧਾਉਣਾ ਅਕਸਰ DDR5 ਵਧਾਉਣ ਜਾਂ ਡੇਟਾ ਪਲੇਸਮੈਂਟ ਨੂੰ ਦੁਬਾਰਾ ਸੋਚਣ ਨਾਲੋਂ ਘੱਟ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰਹਿੰਦਾ ਹੈ।
"ਨੀਤ੍ਰਿਤਵ" ਇੱਕ ਮਾਰਕੀਟਿੰਗ ਸ਼ਬਦ ਵਾਂਗ ਸੁਰਖੀਆਂ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਏਆਈ ਸਰਵਰ ਖਰੀਦਦਾਰਾਂ ਲਈ ਇਹ ਅਕਸਰ ਮਾਪਯੋਗ ਤਰੀਕਿਆਂ ਵਿੱਚ ਨਜਰ ਆਉਂਦਾ ਹੈ: ਕੀ ਵਾਸਤਵ ਵਿੱਚ ਵੋਲਿਊਮ ਵਿੱਚ ਭੇਜਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਰੋਡਮੈਪ ਕਿੰਨਾ ਨਿਯਮਤ ਤਰੀਕੇ ਨਾਲ ਦੇ ਦਿੱਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਹਾਰਡਵੇਅਰ ਵਿਕਸਿਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਭਾਗ ਕਿਵੇਂ ਰਵੱਈਆ ਕਰਦੇ ਹਨ।
HBM ਉਤਪਾਦਾਂ ਲਈ ਜਿਵੇਂ HBM3E, ਨੇਤ੍ਰਿਤਵਤਾ ਦਾ ਅਰਥ ਹੁੰਦਾ ਹੈ ਕਿ ਇੱਕ ਵਿਕਰੇਤਾ ਉੱਚ-ਵਾਲੀਅਮ ਡਿਲੀਵਰੀਜ਼, ਟੀਚੇ ਵਾਲੇ ਸਪੀਡ ਗਰੇਡ ਅਤੇ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਠੀਕ ਢੰਗ ਨਾਲ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ। ਰੋਡਮੈਪ ਐਕਜ਼ੀਕਿਊਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ accelerator ਜਨਰੇਸ਼ਨਾਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੇ ਹਨ; ਜੇ ਮੈਮੋਰੀ ਰੋਡਮੈਪ ਡੇਲੈ ਹੋ ਜਾਏ ਤਾਂ ਤੁਹਾਡੇ ਪਲੇਟਫਾਰਮ ਵਿਕਲਪ ਘੱਟ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕੀਮਤਾਂ ਉੱਤੇ ਦਬਾਅ ਪੈਂਦਾ ਹੈ।
ਇਸ ਵਿੱਚ ਓਪਰੇਸ਼ਨਲ ਪਰਿਪੱਕਤਾ ਵੀ ਸ਼ਾਮਿਲ ਹੈ: ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਦੀ ਗੁਣਵੱਤਾ, ਟ੍ਰੇਸੇਬਿਲਿਟੀ, ਅਤੇ ਫ਼ੀਲਡ ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਆਉਣ 'ਤੇ ਹੱਲ कितਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਵੱਡੇ ਏਆਈ ਕਲਸਟਰ ਇੱਕ ਚਿਪ ਥੋੜ੍ਹੀ ਢੰਗ ਨਾਲ ਧੀਰਜ ਨਾਲ ਨਹੀਂ ਫੇਲਦੇ; ਉਹ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿ ਫ਼ਰਕਵਾਰਤਾ ਕਾਰਨ ਆਪਰੇਸ਼ਨਲ ਰੁਕਾਵਟ ਬਣ ਜਾਦੀ ਹੈ। ਲਗਾਤਾਰ binning (ਜਿਸ ਵਿੱਚ ਹਿੱਸਿਆਂ ਨੂੰ performance ਅਤੇ power "ਬਕਟਾਂ" ਵਿੱਚ ਵਰਗੀਕਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ) ਇਸ ਗੱਲ ਦੇ ਮੌਕੇ ਘਟਾਉਂਦੀ ਹੈ ਕਿ ਕੁਝ ਨੋਡ ਜ਼ਿਆਦਾ ਗਰਮ ਚਲਣ, ਜਲਦੀ throttle ਹੋਣ, ਜਾਂ ਵੱਖਰੇ ਟਿਊਨਿੰਗ ਦੀ ਲੋੜ ਰੱਖਣ।
ਭਰੋਸੇਯੋਗਤਾ ਹੋਰ ਸਿਧੀ ਗੱਲ ਹੈ: ਘੱਟ initial failures ਦਾ ਅਰਥ ਹੈ ਘੱਟ GPU swap, ਘੱਟ ਨਿਮਰ ਸਰਵਿਸ ਵਿੰਡੋ, ਅਤੇ ਘੱਟ "ਚੁੱਪ" throughput ਘਟਿਆ। ਕਲਸਟਰ ਸਕੇਲ 'ਤੇ, ਸਰਗਰਮੀ ਵਿੱਚ ਥੋੜ੍ਹਾ ਜਿਹਾ ਫੇਰ ਵੀ availability ਅਤੇ on-call ਭਾਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਅਸਰ ਪਾ ਸਕਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਖਰੀਦਦਾਰ ਮੈਮੋਰੀ ਨੂੰ ਅਲੱਗ ਤੌਰ 'ਤੇ deploy ਨਹੀਂ ਕਰਦੇ—ਉਹ validated platforms deploy ਕਰਦੇ ਹਨ। qualification cycles (ਵਿਕਰੇਤਾ + OEM/ODM + accelerator ਵਿਕਰੇਤਾ) ਮਹੀਨਿਆਂ ਲੈ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਸ ਮੈਮੋਰੀ SKU ਨੂੰ ਕਿਸ ਸਪੀਡ ਗਰੇਡ, ਥਰਮਲ ਅਤੇ firmware ਸੈਟਿੰਗਾਂ 'ਤੇ ਮਨਜ਼ੂਰ ਕੀਤਾ ਗਿਆ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਨਤੀਜਾ: ਇੱਕ spec ਸ਼ੀਟ 'ਤੇ ਦਾ "ਸਭ ਤੋਂ ਵਧੀਆ" ਹਿੱਸਾ ਉਸ ਵੇਲੇ ਹੀ ਉਪਯੋਗੀ ਹੈ ਜਦੋਂ ਉਹ ਤੁਹਾਡੇ ਦੁਆਰਾ ਇਸ ਤਿਮਾਹੀ ਵਿੱਚ ਖਰੀਦ ਸਕਣ ਵਾਲੇ ਸਰਵਰਾਂ ਲਈ qualified ਹੋ।
ਚੋਣ ਮੁਲਾਂਕਣ ਕਰਦੇ ਸਮੇਂ ਮੰਗੋ:
ਇਸ ਨਾਲ ਗੱਲਬਾਤ deployable ਪਰਫਾਰਮੈਂਸ 'ਤੇ ਕੇਂਦਰਿਤ ਰਹੇਗੀ, ਸਿਰਫ਼ ਸਿਰਲੇਖਾਂ 'ਤੇ ਨਹੀਂ।
HBM ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਅਕਸਰ "ਵਧੀ ਬੈਂਡਵਿਡਥ" ਵਜੋਂ ਸੰਖੇਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਖਰੀਦਦਾਰ ਜੋ ਚਾਹੁੰਦੇ ਹਨ ਉਹ throughput ਹੈ: ਕਿੰਨੇ tokens/sec (LLMs) ਜਾਂ images/sec (vision) ਤੁਸੀਂ ਇੱਕ ਮਨਜ਼ੂਰਯੋਗ ਲਾਗਤ 'ਤੇ ਲਗਾਤਾਰ ਚਲਾ ਸਕਦੇ ਹੋ।
ਟ੍ਰੇਨਿੰਗ ਅਤੇ ਇੰਫਰੰਸ ਵਾਰ-ਵਾਰ ਵਜ਼ਨ ਅਤੇ ਐਕਟੀਵੇਸ਼ਨ ਨੂੰ GPU ਦੇ compute ਯੂਨਿਟਾਂ ਅਤੇ ਮੈਮੋਰੀ ਦੇ ਵਿਚਕਾਰ ਘੁੰਮਾਉਂਦੇ ਹਨ। ਜੇ compute ਤਿਆਰ ਹੈ ਪਰ ਡੇਟਾ ਦੇਰੀ ਨਾਲ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਪਰਫਾਰਮੈਂਸ ਘਟਦਾ ਹੈ।
ਜ਼ਿਆਦਾ HBM bandwidth ਉਹਨਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ ਵਰਕਲੋਡ ਮੈਮੋਰੀ-ਬਾਊਂਡ ਹੁੰਦਾ ਹੈ (ਵੱਡੇ ਮਾਡਲ, ਲੰਬੇ context windows, ਅਤੇ ਕੁਝ attention/embedding-ਭਾਰੀ ਰਸਤੇ), ਅੱਤੇ ਉਹਨਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ ਉੱਚ bandwidth step time ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੀ ਹੈ—ਜਿਸਦਾ ਅਰਥ ਹੈ ਬਿਨਾਂ ਮਾਡਲ ਬਦਲੇ ਹੋਏ ਵੱਧ tokens/sec ਜਾਂ images/sec।
ਬੈਂਡਵਿਡਥ ਲਾਭ ਸਦੀਵੀ ਨਹੀਂ ਵਧਦੇ। ਜਦੋਂ ਇੱਕ ਨੌਕਰੀ compute-bound ਹੋ ਜਾਂਦੀ ਹੈ (math units ਸੀਮਿਤ ਹਨ), ਤਾਂ ਵਧੇਰੇ ਮੈਮੋਰੀ bandwidth ਛੋਟੇ ਸੁਧਾਰ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ ਇਹ ਮੈਟਰਿਕਸ ਵਿੱਚ ਦੇਖੋਗੇ: ਮੈਮੋਰੀ ਸਟਾਲ ਘੱਟ ਹੋ ਜਾਣਗੇ, ਪਰ ਕੁੱਲ step time ਹੋਰ ਬਿਹਤਰ ਨਹੀਂ ਹੋਵੇਗਾ।
ਇੱਕ ਵਿਵਹਾਰਕ ਨਿਯਮ: ਜੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਦਿਖਾਂਦਾ ਹੈ ਕਿ ਮੈਮੋਰੀ ਮੁੱਖ ਬੋਤਲ-ਨੈਕ ਨਹੀਂ, ਤਾਂ GPU ਜਨਰੇਸ਼ਨ, kernel ਕੁਸ਼ਲਤਾ, ਬੈਚਿੰਗ ਅਤੇ ਪੈਰੱਲੇਲਿਜ਼ਮ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਨਾ ਕਿ ਸਿਰਫ਼ ਪੀਕ bandwidth ਨੰਬਰਾਂ ਦਾ ਪਿਛਾ ਕਰੋ।
ਬੈਂਡਵਿਡਥ ਗਤੀ ਨੂੰ ਤੇਜ਼ ਕਰਦੀ ਹੈ; ਸਮਰੱਥਾ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਫਿੱਟ ਹੁੰਦਾ ਹੈ।
ਜੇ HBM ਸਮਰੱਥਾ ਬਹੁਤ ਛੋਟੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਛੋਟੀ ਬੈਚਾਂ, ਵੱਧ ਮਾਡਲ ਸ਼ਾਰਡਿੰਗ/ਆਫਲੋਡ, ਜਾਂ ਘੱਟ context length ਨਾਲ ਕੰਮ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ—ਅਕਸਰ throughput ਘਟਾਉਂਦਾ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਨੁੰਹ ਜਟਿਲ ਬਣਾਉਂਦਾ ਹੈ। ਕਈ ਵਾਰ ਥੋੜ੍ਹੀ ਘੱਟ-ਬੈਂਡਵਿਡਥ ਪਰ ਕਾਫੀ ਸਮਰੱਥਾ ਵਾਲੀ ਕਨਫਿਗਰੇਸ਼ਨ ਇੱਕ ਤੇਜ਼ ਪਰ ਘੁੱਟੀ ਹੋਈ سیਟਅਪ ਨਾਲੋਂ ਵਧੀਆ ਨਤੀਜੇ ਦਿੰਦੀ ਹੈ।
ਕੁਝ ਇੰਡੀਕੇਟਰ ਕਸੂਤੀ ਤੌਰ 'ਤੇ ਟੈਸਟਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਟਰੈਕ ਕਰੋ:
ਇਹ ਦੱਸਦੇ ਹਨ ਕਿ HBM bandwidth, HBM ਸਮਰੱਥਾ, ਜਾਂ ਕੁਝ ਹੋਰ ਵਾਸਤਵ ਵਿੱਚ ਸੀਮਿਤ ਕਰ ਰਿਹਾ ਹੈ।
HBM "ਕੇਵਲ ਤੇਜ਼ DRAM" ਨਹੀਂ ਹੈ। ਇਸ ਦੇ ਵਿਵਹਾਰ ਦੇ ਪਿੱਛੇ ਵੱਡੀ ਭੂਮਿਕਾ ਪੈकेਜਿੰਗ ਦੀ ਹੈ: ਕਿਵੇਂ ਕਈ ਮੈਮੋਰੀ ਡਾਈਜ਼ ਸਟੈਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕਿਵੇਂ ਉਹ stack GPU ਨਾਲ ਜੋੜੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਉਹ ਸ਼ਾਂਤ ਇੰਜੀਨੀਅਰਿੰਗ ਹੈ ਜੋ ਕੱਚੀ ਸਿਲਿਕਨ ਨੂੰ ਵਰਤਣਯੋਗ bandwidth ਵਿੱਚ ਬਦਲਦੀ ਹੈ।
HBM ਉੱਚ bandwidth ਇਸ ਤਰ੍ਹਾਂ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਕਿ ਮੈਮੋਰੀ ਨੂੰ compute ਦੀ ਡਾਇ ਦੇ ਬਹੁਤ ਨੇੜੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਬਹੁਤ-ਚੌੜੀ ਇੰਟਰਫੇਸ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਲੰਮੇ trace motherboard 'ਤੇ ਟਰਾਂਜ਼ਮਿਸ਼ਨ ਦੀ ਬਜਾਏ, HBM GPU ਅਤੇ ਮੈਮੋਰੀ ਸਟੈਕ ਵਿਚਕਾਰ ਬਹੁਤ ਛੋਟੀ ਕਨੈਕਸ਼ਨਾਂ ਵਰਤਦਾ ਹੈ। ਛੋਟੀ ਦੂਰੀ ਆਮ ਤੌਰ 'ਤੇ ਸਫ਼ ਸਿਗਨਲ, ਹਰ ਬਿਟ 'ਤੇ ਘੱਟ energy ਅਤੇ ਗਤੀ 'ਤੇ ਘੱਟ ਸਮਝੌਤਾ ਦਿੰਦੀ ਹੈ।
ਆਮ HBM ਸੈਟਅਪ ਇੱਕ ਮੈਮੋਰੀ ਡਾਈਜ਼ ਦੀ ਸਟੈਕ ਹੈ ਜੋ GPU (ਜਾਂ accelerator) ਡਾਈ ਦੇ ਬगल ਵਿੱਚ ਬੈਠੀ ਹੋਈ ਹੈ, ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾਂ-ਪੁੱਟੀ base die ਅਤੇ ਇੱਕ high-density substrate structure ਰਾਹੀਂ ਜੁੜੀ ਹੋਈ। ਪੈਕੇਜੀਂਗ ਹੀ ਉਹ ਗੱਲ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਉਸ ਸੰਘਣੇ "ਬਾਈ-ਸਾਈਡ-ਬਾਈਸਾਈਡ" ਲੇਆਉਟ ਨੂੰ ਨਿਰਮਾਣਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਜ਼ਿਆਦਾ ਘਣਤਾ ਵਾਲੀ ਪੈਕੇਜਿੰਗ ਥਰਮਲ coupling ਵਧਾਉਂਦੀ ਹੈ: GPU ਅਤੇ ਮੈਮੋਰੀ ਸਟੈਕ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਗਰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਹੌਟ-ਸਪੌਟ sustained throughput ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ ਜੇ ਕੁਲਿੰਗ ਕਾਫੀ ਨਹੀਂ। ਪੈਕੇਜਿੰਗ ਚੋਣਾਂ ਸਿਗਨਲ ਇੰਟੀਗ੍ਰਿਟੀ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਤ ਕਰਦੀਆਂ ਹਨ (ਬਿਜਲੀ ਸਿਗਨਲ ਕਿੰਨੇ ਸਾਫ਼ ਰਹਿੰਦੇ ਹਨ)। ਛੋਟੀ interconnects ਮਦਦ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਸਿਰਫ਼ ਜੇ ਸਮੱਗਰੀ, alignment, ਅਤੇ ਪਾਵਰ ਡਿਲਿਵਰੀ ਕੰਟਰੋਲ ਵਿੱਚ ਹੋਣ।
ਅੰਤ ਵਿੱਚ, ਪੈਕੇਜਿੰਗ ਗੁਣਵੱਤਾ yield ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ: ਜੇ ਕੋਈ ਸਟੈਕ, ਇੰਟਰਪੋਜਰ ਕਨੈਕਸ਼ਨ, ਜਾਂ ਬੰਪ ਐਰੇ ਫੇਲ ਕਰ ਜਾਏ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਮਹਿੰਗੀ ਅਸੈਂਬਲ ਕੀਤੀ ਇਕਾਈ ਗਵਾ ਸਕਦੇ ਹੋ—ਕੇਵਲ ਇੱਕ ਡਾਈ ਨਹੀਂ। ਇਸ ਲਈ ਪੈਕੇਜਿੰਗ ਦੀ ਪਰਿਪੱਕਤਾ ਹਕੀਕਤ ਵਿੱਚ HBM ਦੀ ਕੀਮਤ 'ਤੇ ਉਤਨੇ ਹੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦੀ ਹੈ ਜਿੰਨੀ ਕਿ ਮੈਮੋਰੀ ਚਿੱਪਸ ਖ਼ੁਦ।
ਲੋਕ ਜਦੋਂ ਏਆਈ ਸਰਵਰਾਂ ਬਾਰੇ ਸੋਚਦੇ ਹਨ, ਧਿਆਨ ਤੁਰੰਤ GPU ਮੈਮੋਰੀ (HBM) ਅਤੇ ਐਕਸੈਲਰੇਟਰ ਪਰਦਰਸ਼ਨ ਤੇ ਹੁੰਦਾ ਹੈ। ਪਰ DDR5 ਅਜੇ ਵੀ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਬਾਕੀ ਸਿਸਟਮ ਉਹਨਾਂ ਐਕਸੈਲਰੇਟਰਾਂ ਨੂੰ ਭਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ—ਅਤੇ ਕਿ ਸਰਵਰ ਸਕੇਲ 'ਤੇ ਚਲਾਉਂਦੇ ਸਮੇਂ ਸੁਖਦ ਜਾਂ ਦਰਦਨਾਕ ਹੋਵੇਗਾ।
DDR5 ਪ੍ਰਮੁੱਖ ਤੌਰ 'ਤੇ CPU-ਜੁੜੀ ਮੈਮੋਰੀ ਹੈ। ਇਹ "ਟ੍ਰੇਨਿੰਗ/ਇੰਫਰੰਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ" ਕੰਮ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ: ਡੇਟਾ ਪ੍ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ, ਟੋਕਨਾਈਜ਼ੇਸ਼ਨ, ਫੀਚਰ ਇੰਜੀਨਰੀਅਰਿੰਗ, caching, ETL pipeline, shard metadata, ਅਤੇ ਕੰਟਰੋਲ ਪਲੇਨ (schedulers, storage clients, monitoring agents)। ਜੇ DDR5 ਘੱਟ ਹੈ, CPUs ਮੈਮੋਰੀ ਦੀ ਉਡੀਕ ਕਰਨਗੇ ਜਾਂ ਡਿਸਕ ਤੇ paging ਕਰਨਗੇ, ਅਤੇ ਮਹਿੰਗੇ GPUs ਕਦਮਾਂ ਦਰਮਿਆਨ ਆਈਡਲ ਰਹਿਣਗੇ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ DDR5 ਨੂੰ ਤੁਹਾਡਾ ਸਟੇਜਿੰਗ ਅਤੇ ਆਰਕਿਸਟ੍ਰੇਸ਼ਨ ਬਜੱਟ ਸਮਝਣਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਵਰਕਲੋਡ ਤੇਜ਼ ਸਟੋਰੇਜ ਤੋਂ ਸਿੱਧਾ GPUs ਤਕ ਸੁੱਚੇ ਬੈਚ ਪ੍ਰਵਾਹਿਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਘੱਟ ਪਰ ਤੇਜ਼ DIMMs ਨੂੰ ਤਰਜੀਹ ਦੇ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਭਾਰੀ preprocessing, ਹੋਸਟ-ਸਾਈਡ caching, ਜਾਂ ਹਰ ਨੋਡ 'ਤੇ ਕਈ ਸੇਵਾਵਾਂ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਸਮਰੱਥਾ ਹੱਦ ਬਣ ਜਾਂਦੀ ਹੈ।
ਇਹ ਸੰਤੁਲਨ accelerator ਮੈਮੋਰੀ 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: ਜੇ ਤੁਹਾਡੇ ਮਾਡਲ HBM ਸੀਮਾਵਾਂ ਦੇ ਨੇੜੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਤਕਨੀਕਾਂ ਵਰਤੋਂਗੇ ਜੋ CPU ਮੈਮੋਰੀ ਤੇ ਦਬਾਅ ਵਧਾਉਂਦੀਆਂ ਹਨ।
ਹਰ ਸਲੱਟ ਭਰਨ ਦੇ ਨਾਲ ਕੇਵਲ ਸਮਰੱਥਾ ਨਹੀਂ ਵੱਧਦੀ: ਇਹ ਪਾਵਰ ਖਪਤ, ਗਰਮੀ, ਅਤੇ ਏਅਰਫ਼ਲੋ ਲੋੜਾਂ ਨੂੰ ਵੀ ਵਧਾਉਂਦਾ ਹੈ। ਉੱਚ-ਕੈਪੇਸਿਟੀ RDIMMs ਗਰਮ ਦੌੜ ਸਕਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਕੁਲਿੰਗ ਘਟਾਵ੍ਹਾਂ CPU throttling ਨੂੰ ਟ੍ਰিগਰ ਕਰ ਸਕਦੇ ਹਨ—ਜਿਸ ਨਾਲ end-to-end throughput ਘਟ ਸਕਦੀ ਹੈ ਭਾਵੇਂ GPUs ਪੇਪਰ 'ਤੇ ਠੀਕ ਲਗ ਰਹੇ ਹੋਣ।
ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ, ਪੁਸ਼ਟੀ ਕਰੋ:
DDR5 ਨੂੰ ਇੱਕ ਵੱਖਰਾ ਬਜੱਟ ਲTreat ਕਰੋ: ਇਹ ਬੈਂਚਮਾਰਕਾਂ 'ਤੇ ਸਿਰਲੇਖ ਨਹੀਂ ਬਣਦਾ, ਪਰ ਅਸਲ ਉਪਯੋਗਿਤਾ ਅਤੇ ਓਪਰੇਟਿੰਗ ਲਾਗਤ ਅਕਸਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ।
ਏਆਈ ਸਰਵਰ ਪ੍ਰਦਰਸ਼ਨ ਸਿਰਫ਼ ਪੀਕ ਸਪੈਕਸ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਇਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਸਿਸਟਮ ਉਹ ਨੰਬਰ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਰੱਖ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਥਰਟਲ ਹੋਏ। ਮੈਮੋਰੀ ਪਾਵਰ (GPU 'ਤੇ HBM ਅਤੇ ਹੋਸਟ 'ਚ DDR5)ਸਿੱਧਾ ਹੀਟ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਗਰਮੀ ਰੈਕ ਡੈਨਸਟੀ, ਫੈਨ ਸਪੀਡਾਂ, ਅਤੇ ਆਖ਼ਿਰਕਾਰ ਤੁਹਾਡੇ ਕੁਲਿੰਗ ਬਿੱਲ ਲਈ ਸੀਮਾ ਬਥਾਉਂਦੀ ਹੈ।
ਮੈਮੋਰੀ ਦੁਆਰਾ ਖਾਏ ਗਏ ਹਰ ਵਾਟ ਨੂੰ ਤੁਹਾਡੇ ਡੇਟਾ ਸੈਂਟਰ ਨੂੰ ਹਟਾਉਣਾ ਪੈਂਦਾ ਹੈ। 8 GPUs ਪ੍ਰਤੀ ਸਰਵਰ ਅਤੇ ਦਹਾਂ ਸਰਵਰ ਪ੍ਰਤੀ ਰੈਕ ਦੇ ਗੁਣਾ ਕਰਨ 'ਤੇ, ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਫੈਸਿਲਿਟੀ ਸੀਮਾਵਾਂ ਤੇ ਜਲਦੀ ਪਹੁੰਚ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਇਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ:
ਗਰਮ ਹੋ ਰਹੇ ਕੰਪੋਨੇਟ ਸੇਵਾ ਬੰਦ ਕਰਨ ਲਈ throttle ਕਰ ਸਕਦੇ ਹਨ—ਇਹ ਘੜੀ ਦਰਾਂ ਨੂੰ ਘਟਾ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਹਾਰਡਵੇਅਰ ਦੀ ਰੱਖਿਆ ਹੋ ਸਕੇ। ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸਿਸਟਮ ਛੋਟੀ ਟੈਸਟਾਂ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਲੰਬੇ ਟ੍ਰੇਨਿੰਗ ਦੌਰਾਨ ਜਾਂ ਉਚ-ਥਰਪੂਟ ਇੰਫਰੰਸ ਦੌਰਾਨ ਢੀਲਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ "ਸਥਾਈ ਥਰਪੂਟ" ਪ੍ਰਸਿੱਧ ਬੈਂਚਮਾਰਕਾਂ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ।
ਤੁਹਾਨੂੰ exotic ਤਕਨਾਲੋਜੀ ਦੀ ਲੋੜ ਨਹੀਂ; ਤੁਹਾਨੂੰ ਅਨੁਸ਼ਾਸਨ ਚਾਹੀਦਾ ਹੈ:
ਸਿਰਫ਼ ਪੀਕ 'ਤੇ ਨਹੀਂ, ਪਰ ਓਪਰੇਸ਼ਨਲ ਮੈਟਰਿਕਸ 'ਤੇ ਧਿਆਨ ਦਿਓ:
ਥਰਮਲ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਮੈਮੋਰੀ, ਪੈਕੇਜਿੰਗ, ਅਤੇ ਸਿਸਟਮ ਡਿਜ਼ਾਇਨ ਮਿਲਦੇ ਹਨ—ਅਤੇ ਜਿੱਥੇ ਛੁਪੀ ਲਾਗਤਾਂ ਪਹਿਲਾਂ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ।
ਮੈਮੋਰੀ ਚੋਣਾਂ ਇੱਕ ਕੋਟ ਸ਼ੀਟ 'ਤੇ ਸਿੱਧੀਆਂ ਲੱਗਦੀਆਂ ਹਨ ("$/GB"), ਪਰ ਏਆਈ ਸਰਵਰ ਆਮ ਸਰਵਰਾਂ ਵਰਗੇ ਨਹੀਂ ਚਲਦੇ। ਜੋ ਮਿਆਰੀ ਵਸਤੂ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਐਕਸੈਲਰੇਟਰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਵਾਟ ਅਤੇ ਸਮਾਂ ਨੂੰ ਉਪਯੋਗੀ tokens, embeddings, ਜਾਂ ਟ੍ਰੇਨ ਕੀਤੇ ਚੈਕਪੌਇੰਟਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ।
HBM ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ, ਲਾਗਤ ਦੇ ਇੱਕ ਵੱਡੇ ਹਿੱਸੇ ਸਾਫਟਵੇਅਰ ਸਿਲਿਕਨ ਤੋਂ ਬਾਹਰ ਹੁੰਦਾ ਹੈ। ਆਧੁਨਿਕ ਪੈਕੇਜਿੰਗ (ਸਟੈਕਿੰਗ ਡਾਈਜ਼, ਬਾਂਡਿੰਗ, ਇੰਟਰਪੋਸਰ/ਸਬਸਟ੍ਰੇਟ), yield (ਕਿੰਨੇ stacks ਪਾਸ ਹੁੰਦੇ ਹਨ), ਟੈਸਟ ਸਮਾਂ, ਅਤੇ ਇੰਟੈਗਰੇਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਸਭ ਮਿਲ ਕੇ ਲਾਗਤ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਸਪਲਾਇਰ ਜਿਸਦੀ ਪੈਕੇਜਿੰਗ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਜ਼ਬੂਤ ਹੋਵੇ—ਜਿਹੜੀ ਮਾਮੂਲ ਤੌਰ 'ਤੇ SK hynix ਲਈ ਹਵਾਲਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ—ਉਹ ਦਿੱਤੀ ਗਈ ਲਾਗਤ ਅਤੇ ਉਪਲਬਧਤਾ 'ਤੇ ਵੱਡਾ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦਾ ਹੈ।
ਜੇ ਮੈਮੋਰੀ bandwidth ਸੀਮਿਤ ਹੈ, ਤਾੰ ਐਕਸੈਲਰੇਟਰ ਆਪਣੀ ਭੁਗਤਾਨ ਕੀਤੀ ਹੋਈ ਸਮੇਂ ਦਾ ਹਿੱਸਾ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸਸਤੀ ਮੈਮੋਰੀ ਕਨਫਿਗਰੇਸ਼ਨ ਜੋ throughput ਘਟਾਉਂਦੀ ਹੈ, ਉਹ ਚੁੱਪਚਾਪ ਤੁਹਾਡੀ ਪ੍ਰਭਾਵਿਤ ਲਾਗਤ ਪ੍ਰਤੀ ਟ੍ਰੇਨਿੰਗ ਸਟੈਪ ਜਾਂ ਪ੍ਰਤੀ ਮਿਲੀਅਨ ਟੋਕਨ ਨੂੰ ਵਧਾ ਸਕਦੀ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ:
ਜੇ ਤੇਜ਼ ਮੈਮੋਰੀ ਆਉਟਪੁੱਟ ਪ੍ਰਤੀ ਘੰਟਾ ਨੂੰ 15% ਵਧਾਂਦੀ ਹੈ ਤੇ ਸਰਵਰ ਲਾਗਤ 5% ਵਧਦੀ ਹੈ, ਤਾਂ ਇਕਾਈ ਅਰਥ-ਸ਼ਾਸਤਰ ਸੁਧਰੇਗੀ—ਚਾਹੇ BOM ਦੀ ਲਾਈਨ ਆਈਟਮ ਵੱਧ ਮਹਿੰਗੀ ਹੋਵੇ।
ਕਲਸਟਰ TCO ਆਮ ਤੌਰ 'ਤੇ ਇਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਨਾਲ ਵੱਡੀ ਤਰ੍ਹਾਂ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੀ ਹੈ:
ਚਰਚਾ ਨੂੰ throughput ਅਤੇ time-to-results 'ਚ ਲਟਕਾਓ, ਨਾ ਕਿ ਕੇਵਲ ਕੰਪੋਨੈਂਟ ਕੀਮਤ 'ਤੇ। ਆਪਣੀ A/B ਅਨੁਮਾਨ ਲੈਵੋ: ਮਾਪਿਆ ਹੋਇਆ tokens/sec (ਜਾਂ steps/sec), ਪ੍ਰੋਜੈਕਟ ਕੀਤਾ ਮਹੀਨਾਵਾਰ ਆਉਟਪੁੱਟ, ਅਤੇ implied cost ਪ੍ਰਤੀ ਇਕਾਈ ਕੰਮ। ਇਹ ਫਾਇਨੈਂਸ ਅਤੇ ਲੀਡਰਸ਼ਿਪ ਲਈ ਮਹਿਮਾਨੀ ਫੈਸਲਾ ਪੜ੍ਹਨ ਯੋਗ ਬਣਾਂਦਾ ਹੈ।
ਏਆਈ ਸਰਵਰ ਬਿਲਡ ਯੋਜਨਾਵਾਂ ਅਕਸਰ ਇੱਕ ਸਰਲ ਕਾਰਨ ਨਾਲ ਫੇਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ: ਮੈਮੋਰੀ "ਇੱਕ ਭਾਗ" ਨਹੀਂ ਹੁੰਦੀ। HBM ਅਤੇ DDR5 ਦੋਹਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਕੜੇ-ਜੁੜੇ ਨਿਰਮਾਣ ਕਦਮ ਸ਼ਾਮਿਲ ਹਨ (ਡਾਈਜ਼, ਸਟੈਕਿੰਗ, ਟੈਸਟ, ਪੈਕੇਜਿੰਗ, ਮੋਡੀਊਲ ਅਸੈਂਬਲੀ), ਅਤੇ ਕਿਸੇ ਵੀ ਕਦਮ ਵਿੱਚ ਦੇਰੀ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ। HBM ਵਿਚ ਇਹ ਚੇਨ ਹੋਰ ਵੀ ਨਿਗੜੀ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ yield ਅਤੇ ਟੈਸਟ ਸਮਾਂ ਸਟੈਕਡ ਡਾਈਜ਼ 'ਚ ਗੁਣਾ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਅੰਤਿਮ ਪੈਕੇਜ ਨੂੰ ਸਕੜੀ ਬਿਜਲੀ ਅਤੇ ਥਰਮਲ ਸੀਮਾਵਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ।
HBM ਉਪਲਬਧਤਾ ਕੇਵਲ ਵੇਫਰ ਸਮਰੱਥਾ ਨਾਲ ਸੀਮਤ ਨਹੀਂ; ਆਧੁਨਿਕ ਪੈਕੇਜਿੰਗ throughput ਅਤੇ qualification gates ਵੀ ਸੀਮਤ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਮੰਗ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੀ ਹੈ, lead times ਖਿੱਚ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਸਮਰੱਥਾ ਵਧਾਉਣਾ ਇਕ ਨਵੀਂ ਅਸੈਂਬਲੀ ਲਾਈਨ ਚਾਲੂ ਕਰਨ ਵਰਗਾ ਨਹੀਂ—ਨਵੇਂ ਟੂਲ, ਨਵੇਂ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਅਤੇ ਕੁਆਲਟੀ ਰੈਂਪ ਸਮਾਂ ਲੈਂਦੇ ਹਨ।
ਜਿੱਥੇ ਸੰਭਵ ਹੋ, multi-source ਯੋਜਨਾ ਬਣਾਓ (DDR5 ਲਈ ਆਮ ਤੌਰ ਤੇ ਆਸਾਨ) ਅਤੇ validated alternates ਤਿਆਰ ਰੱਖੋ। "Validated" ਦਾ ਮਤਲਬ ਹੈ ਤੁਹਾਡੇ ਟਾਰਗਟ ਪਾਵਰ ਲਿਮਿਟ, ਤਾਪਮਾਨ ਅਤੇ ਵਰਕਲੋਡ ਮਿਕਸ 'ਤੇ ਟੈਸਟ ਕੀਤੇ ਹੋਏ—ਕੇਵਲ ਬੂਟ ਟੈਸਟ ਨਹੀਂ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਰਵੱਈਆ:
ਕਾਲਗੇ ਕੁਆਰਟਰਾਂ ਵਿੱਚ ਅਨੁਮਾਨ ਲਗਾਓ, ਹਫਤਿਆਂ ਵਿੱਚ ਨਹੀਂ। ਸਪਲਾਇਰ commitments ਪੁਸ਼ਟੀ ਕਰੋ, ramp phases ਲਈ ਬਫਰ ਜੋੜੋ, ਅਤੇ ਖਰੀਦ ਸਮਾਂ ਨੂੰ ਸਰਵਰ lifecycle ਮਾਈਲਸਟੋਨਜ਼ ਨਾਲ ਸੰਗਠਿਤ ਕਰੋ (pilot → limited rollout → scale)। ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਤਬਦੀਲੀਆਂ re-qualification trigger ਕਰਦੀਆਂ ਹਨ (DIMM swap, speed bin change, ਵੱਖਰਾ GPU SKU)।
ਉਹਨਾਂ ਕਨਫਿਗਰੇਸ਼ਨਾਂ 'ਤੇ ਜ਼ਿਆਦਾ ਦਾਅਵਿਆਂ ਨਾ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਖਾਸ ਪਲੇਟਫਾਰਮ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ qualified ਨਹੀਂ ਹਨ। ਇੱਕ "ਨਜ਼ਦੀਕੀ ਮੇਲ" ਔਖੀਆਂ-ਡਿਬੱਗ ਕਰਨ ਵਾਲੀਆਂ ਅਸਥਿਰਤਾਵਾਂ, ਘੱਟ ਸਥਾਈ throughput, ਅਤੇ ਅਣਚਾਹੇ ਰੀਵਰਕ ਖਰਚ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ—ਜਦ ਤੁਹਾਨੂੰ ਸਕੇਲ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
ਵਧੇਰੇ HBM ਸਮਰੱਥਾ/ਬੈਂਡਵਿਡਥ, ਵਧੇਰੇ DDR5, ਜਾਂ ਵੱਖਰਾ ਸਰਵਰ ਕਨਫਿਗ ਚੁਣਨਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਦ ਹੋਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਪ੍ਰਯੋਗ ਵਾਂਗ ਦੇਖਦੇ ਹੋ: ਵਰਕਲੋਡ ਨਿਰਧਾਰਤ ਕਰੋ, ਪਲੇਟਫਾਰਮ ਲਾਕ ਕਰੋ, ਅਤੇ ਸਥਾਈ ਥਰਪੂਟ ਮਾਪੋ (ਪੀਕ ਸਪੈੱਕ ਨਹੀਂ)।
ਸ਼ੁਰੂ ਕਰੋ ਇਹ ਪੁਸ਼ਟੀ ਕਰਕੇ ਕਿ ਕੀ ਵਾਸਤਵ ਵਿੱਚ ਸਪੋਰਟ ਹੈ ਅਤੇ ਸ਼ਿਪ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਕਈ "ਕਾਗਜ਼" ਕਨਫਿਗਰੇਸ਼ਨ ਸਕੇਲ 'ਤੇ ਕੁਆਲੀਫਾਈ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਆਪਣੇ ਅਸਲ ਮਾਡਲ ਅਤੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੇ ਸੰਭਵ ਹੋਵੇ; synthetic bandwidth ਟੈਸਟ ਸਹਾਇਕ ਹਨ ਪਰ ਟ੍ਰੇਨਿੰਗ ਸਮਾਂ ਦਾ ਪੂਰਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਦਿੰਦੀਆਂ।
ਇਕ ਪਾਇਲਟ ਤਦ ਹੀ ਲਾਇਕੀ ਹੁੰਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਸਮਝਾ ਸਕੋ ਕਿ ਇੱਕ ਨੋਡ ਤੇਜ਼ ਜਾਂ ਵਧੇਰੇ ਸਥਿਰ ਕਿਉਂ ਹੈ।
GPU utilization, HBM/DRAM bandwidth counters (ਜੇ ਉਪਲਬਧ), memory error rates (correctable/uncorrectable), ਤਾਪਮਾਨ ਅਤੇ ਪਾਵਰ ਸਮੇਂ-ਸਮੇਂ ਤੇ, ਅਤੇ ਕੋਈ ਵੀ clock throttling ਇਵੈਂਟ ਇਕੱਠੇ ਕਰੋ। ਕੰਮ-ਸਤਹ ਪੱਧਰੀ retries ਅਤੇ checkpoint frequency ਵੀ ਰਿਕਾਰਡ ਕਰੋ—ਮੈਮੋਰੀ ਅਸਥਿਰਤਾ ਅਕਸਰ "ਰਹੱਸਮੀ" ਰੀਸਟਾਰਟਾਂ ਵਜੋਂ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਅੰਦਰੂਨੀ ਟੂਲ ਨਹੀਂ ਹੈ ਜੋ ਇਹ ਪਾਇਲਟ ਸਧਾਰਨ ਕਰੇ, ਤਾਂ platforms like Koder.ai ਟੀਮਾਂ ਨੂੰ ਹਲਕੀ-ਫੁਣੀ ਅੰਦਰੂਨੀ ਐਪ (ਡੈਸ਼ਬੋਰਡ, ਰਨਬੁਕਸ, configuration checklists, ਜਾਂ "ਦੋ ਨੋਡਾਂ ਦੀ ਤੁਲਨਾ" ਪਾਇਲਟ ਰਿਪੋਰਟ) ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਜਦ ਤੁਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ ਤਾਂ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰਨ ਦਿੰਦੇ ਹਨ। ਇਹ repeated qualification cycles ਦੇ ਆਲੇ-ਦੁਆਲੇ friction ਘਟਾਉਣ ਦਾ ਇੱਕ ਵਰਤੋਂਯੋਗ ਤਰੀਕਾ ਹੈ।
ਜਦੋਂ ਤੁਹਾਡੇ GPUs underutilized ਹਨ ਅਤੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਦਿਖਾਂਦੀ ਹੈ ਕਿ memory stalls ਹਨ ਜਾਂ ਅਕਸਰ activation recomputation ਹੁੰਦੀ ਹੈ, ਤਾਂ ਜ਼ਿਆਦਾ/ਤੇਜ਼ HBM ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਜਦ ਸਕੇਲਿੰਗ ਦੌਰਾਨ efficiency ਤੇਜ਼ੀ ਨਾਲ ਘਟਦੀ ਹੈ (ਜਿਵੇਂ all-reduce ਸਮਾਂ ਹावी ਹੋ ਜਾਂਦਾ), ਤਾਂ ਨੈੱਟਵਰਕ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਜੇ dataloading GPUs ਨੂੰ ਭਰਣ ਵਿੱਚ ਨਾਕਾਬਿਲ ਹੈ ਜਾਂ checkpointing bottleneck ਹੈ, ਤਾਂ ਸਟੋਰੇਜ ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਫੈਸਲਾ ਫਰੇਮਵਰਕ चाहिए, ਤਾਂ /blog/ai-server-tco-basics ਵੇਖੋ।
ਏਆਈ ਸਰਵਰ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਲਾਗਤ ਅਕਸਰ "ਕਿਹੜਾ GPU" ਨਾਲੋਂ ਘੱਟ ਆਪਣੇ-ਆਪ ਵਿੱਚ ਨਿਰਧਾਰਤ ਹੁੰਦੇ ਹਨ—ਇਸ ਨਾਲ ਅਨੁਸ਼ਚਿਤ ਹੁੰਦਾ ਹੈ ਕਿ ਮੈਮੋਰੀ ਸਬਸਿਸਟਮ ਉਹ GPU ਨੂੰ ਲਗਾਤਾਰ ਬਿਜੀ ਰੱਖ ਸਕੇ—ਘੰਟੇ-ਘੰਟੇ, ਅਸਲ ਥਰਮਲ ਅਤੇ ਪਾਵਰ ਸੀਮਾਵਾਂ ਹੇਠਾਂ।
HBM ਮੁੱਖ ਰੂਪ ਤੋਂ bandwidth-per-watt ਅਤੇ time-to-train/serve 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਂਦਾ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ bandwidth- hungry workloads ਲਈ। ਆਧੁਨਿਕ ਪੈਕੇਜਿੰਗ ਚੁਪਕੇ-ਚੁਪਕੇ enabling ਕਰਦੀ ਹੈ: ਇਹ achievable bandwidth, yields, ਥਰਮਲ, ਅਤੇ ਆਖ਼ਰਕਾਰ ਤੁਸੀਂ ਕਿੰਨੇ ਐਕਸੈਲਰੇਟਰ ਸਮੇਂ 'ਤੇ ਤੈਅ ਅਤੇ sustained throughput 'ਤੇ ਰੱਖ ਸਕਦੇ ਹੋ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ।
DDR5 ਅਜੇ ਵੀ ਅਹਿਮ ਹੈ ਕਿਉਂਕਿ ਇਹ host-side ਛੱਤ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਡੇਟਾ ਤਿਆਰੀ, CPU ਸਟੇਜ, caching, ਅਤੇ multi-tenant ਵਰਤੀ। DDR5 ਨੂੰ ਅਕਸਰ ਘੱਟ ਅੰਕਿਤ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਫਿਰ GPU ਨੂੰ ਦੋਸ਼ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਦ ਅਸਲ ਸਮੱਸਿਆ upstream ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।
ਟ੍ਰੈਕ ਕਰੋ effective throughput per watt, ਆਸਲ ਉਪਯੋਗਿਤਾ, memory-related stall ਮੈਟਰਿਕਸ, ਅਤੇ ਪ੍ਰਤੀ-ਜੌਬ ਲਾਗਤ ਜਦ ਮਾਡਲ ਬਦਲਦੇ ਹਨ (context length, batch size, mixture-of-experts) ਅਤੇ ਜਿਵੇਂ ਨਵੇਂ HBM ਜਨਰੇਸ਼ਨ ਅਤੇ ਪੈਕੇਜਿੰਗ ਦ੍ਰਿਸ਼ਟਕੋਣ ਕੀਮਤ/ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਬਦਲਦੇ ਹਨ।
ਬਜਟ ਯੋਜਨਾ ਅਤੇ ਪੈਕੇਜਿੰਗ ਵਿਕਲਪਾਂ ਲਈ, ਸ਼ੁਰੂ ਕਰੋ /pricing.
ਗਹਿਰਾਈ ਵਾਲੀਆਂ ਵਿਆਖਿਆਵਾਂ ਅਤੇ ਰਿਫ੍ਰੇਸ਼ ਮਾਰਗਦਰਸ਼ਨ ਲਈ, ਬ੍ਰਾਊਜ਼ ਕਰੋ /blog.
ਕਈ ਏਆਈ ਵਰਕਲੋਡਾਂ ਵਿੱਚ, GPUs ਵਜ਼ਨ, ਐਕਟੀਵੇਸ਼ਨ ਆਦਿ ਦੀ ਆਮਦ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਮੈਮੋਰੀ ਸਿਸਟਮ ਡੇਟਾ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਪਹੁੰਚਾ ਸਕਦੀ, ਤਾਂ GPU ਦੇ ਕੰਪਿਊਟ ਯੂਨਿਟ ਆਈਡਲ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡਾ ਦਿਲਚਸਪੀ ਪ੍ਰਤੀ ਡਾਲਰ ਪ੍ਰਦਰਸ਼ਨ ਘਟ ਜਾਂਦਾ ਹੈ—ਇੱਥੇ ਤੱਕ ਕਿ ਤੁਸੀਂ ਉੱਚ-ਲੈਵਲ ਐਕਸੈਲਰੇਟਰ ਖਰੀਦਿਆ ਹੋਵੇ।
ਇੱਕ ਵਾਜਿਬ ਨਿਸ਼ਾਨ ਹੈ: GPU ਦੀਆਂ ਉੱਚ ਪਾਵਰ ਰੀਡਿੰਗਾਂ ਦੇ ਬਾਵਜੂਦ ਘੱਟ ਹਾਸਿਲ ਕੀਤੀ ਗਈ ਉਪਯੋਗਿਤਾ, ਜਾਂ ਮੈਮੋਰੀ-ਸਟਾਲ ਕਾਊਂਟਰਾਂ ਨਾਲ ਸਾਥ-ਸਾਥ ਟੋਕਨ/ਸੈਕੇਂਡ ਵਿੱਚ ਕੋਈ ਸੁਧਾਰ ਨਾ ਹੋਣਾ ਭਾਵੇਂ ਤੁਸੀਂ ਹੋਰ ਕੰਪਿਊਟ ਜੋੜੋ।
ਇਸਨੂੰ ਇਕ ਪਾਈਪਲਾਈਨ ਵਾਂਗ ਸੋਚੋ:
ਜਦੋਂ ਕੰਪਿਊਟ ਚੱਲ ਰਹੀ ਹੈ ਅਤੇ ਡੇਟਾ ਨੂੰ ਬਾਰ-ਬਾਰ ਸਟੈਕ 'ਤੇੋਂ ਹੇਠਾਂ ਭੇਜਣਾ ਪੈ ਜਾਂਦਾ ਹੈ (HBM → DDR5 → NVMe), ਤਾਂ ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।
HBM ਕਈ DRAM ਡਾਈਜ਼ ਨੂੰ ਖੜ੍ਹਾ ਕਰਕੇ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹ GPU ਦੇ ਬਹੁਤ ਨੇੜੇ advanced packaging ਰਾਹੀਂ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ। ਇਸ "ਚੌੜੀ-ਅਤੇ-ਨਜ਼ਦੀਕੀ" ਡਿਜ਼ਾਇਨ ਨਾਲ ਬੇਇੰਤਹਾ bandwidth ਮਿਲਦਾ ਹੈ ਬਿਨਾਂ ਬਹੁਤ ਊੱਚੀ ਘੜੀ ਦਰਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋਏ।
ਦੂਜੇ ਪਾਸੇ, DDR5 DIMMs ਮਦਰਬੋਰਡ 'ਤੇ ਦੂਰ ਹਨ ਅਤੇ ਪਤਲੇ ਚੈਨਲਾਂ ਤੇ ਤੇਜ਼ signaling ਦਰਾਂ ਵਰਤਦੇ ਹਨ—ਆਮ ਸਰਵਰ ਵਰਤੇ ਗਏ ਕੰਮਾਂ ਲਈ ਵਧੀਆ, ਪਰ GPU ਦੇ ਨਜ਼ਦੀਕੀ HBM bandwidth ਦੇ ਬਰਾਬਰ ਨਹੀਂ।
ਇਹ ਸਾਰਣੀ ਆਸਾਨ ਨਿਯਮ ਵਰਤੋ:
ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ compute-bound ਹੋ, ਤਾਂ ਵਧੇਰੇ bandwidth ਤੋਂ ਘੱਟ ਲਾਭ ਮਿਲਦੇ ਹਨ; ਇਸ ਨਾਲ ਤੁਸੀਂ kernel ਅਪਟਿਮਾਈਜ਼ੇਸ਼ਨ, ਬੈਚਿੰਗ, ਜਾਂ ਤੇਜ਼ GPU ਜਨਰੇਸ਼ਨ ਦੀ ਓਰ ਵੇਖੋ।
ਪੈਕੇਜਿੰਗ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ HBM ਆਪਣੀ ਥਿਔਰਟਿਕਲ bandwidth ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਅਤੇ ਵਚਨਬੱਧ ਨਿਰਮਾਣ ਵਿੱਚ ਪਹੁੰਚਾ ਸਕੇ। TSVs, ਮਾਈਕ੍ਰੋ-ਬੰਪਸ, ਅਤੇ ਇੰਟਰਪੋਜਰ/ਸਬਸਟ੍ਰੇਟ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਪ੍ਰਭਾਵ ਪਾਂਦੀਆਂ ਹਨ:
ਖਰੀਦਦਾਰਾਂ ਲਈ, ਪੈਕੇਜਿੰਗ ਦੀ ਮੈਚਿਊਰਿਟੀ ਦਾ ਅਰਥ ਹੈ ਹੋਰ ਠੋਸ ਅਤੇ ਲੰਬੀ-ਅਵਧੀਕ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸਕੇਲਿੰਗ ਦੌਰਾਨ ਘੱਟ ਅਨੁਮਾਨਿਤ ਸਮੱਸਿਆਵਾਂ।
ਪ੍ਰਯੋਗਕਰਨ ਲਈ DDR5 ਨੂੰ ਇੱਕ ਸਟੇਜਿੰਗ ਅਤੇ ਆਰਕਿਸਟ੍ਰੇਸ਼ਨ ਬਜੱਟ ਵਜੋਂ ਸੋਚੋ। ਜੇ ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਤੇਜ਼ ਸਟੋਰੇਜ ਤੋਂ ਸਿੱਧਾ GPUs ਨੂੰ ਕਲੀਨ ਬੈਚ ਸਟ੍ਰੀਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਘੱਟ ਪਰ ਡਿੱਗ ਰੈਟ DIMMs ਨੂੰ ਤਰਜੀਹ ਦੇ ਸਕਦੇ ਹੋ। ਪਰ ਜੇ ਤੁਸੀਂ ਭਾਰੀ preprocessing, ਹੋਸਟ-ਸਾਈਡ ਕੈਸ਼ਿੰਗ, ਜਾਂ ਇੱਕ ਨੋਡ 'ਤੇ ਕਈ ਸੇਵਾਵਾਂ ਚਲਾ ਰਹੇ ਹੋ, ਤਾਂ ਸਮਰੱਥਾ ਮੁੱਦਾ ਬਣ ਜਾਂਦੀ ਹੈ।
ਇਹ ਸੰਤੁਲਨ accelerator memory 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: ਜੇ ਤੁਹਾਡੇ ਮਾਡਲ HBM ਸੀਮਾਵਾਂ ਦੇ ਨੇੜੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ checkpointing, offload, ਜਾਂ ਵੱਡੇ ਬੈਚ ਕਿਊਜ਼ ਵਰਗੀ ਤਕਨੀਕਾਂ ਵਰਤੋਂਗੇ ਜੋ CPU ਮੈਮੋਰੀ 'ਤੇ ਦਬਾਅ ਵਧਾਉਂਦੀਆਂ ਹਨ।
ਹਰ ਵਾਟ ਜੋ ਮੈਮੋਰੀ ਖਾਂਦੀ ਹੈ, ਉਹ ਤੁਹਾਡੇ ਡੇਟਾ ਸੈਂਟਰ ਨੂੰ ਹਟਾਉਣ ਲਈ ਹੀਟ ਬਣ ਜਾਂਦੀ ਹੈ। 8 GPUs ਪ੍ਰਤੀ ਸਰਵਰ ਅਤੇ ਕਈ ਸਰਵਰ ਪ੍ਰਤੀ ਰੈਕ ਨੂੰ ਗੁਣਾ ਕਰਨ ਤੇ, ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਫੈਸਿਲਿਟੀ ਸੀਮਾਵਾਂ ਤੇ ਪਹੁੰਚ ਸਕਦੇ ਹੋ। ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਕਈ ਕਾਰਵਾਈਆਂ ਕਰਨੀਆਂ ਪੈ ਸਕਦੀਆਂ ਹਨ:
ਇਸ ਲਈ "ਸਥਾਈ ਥਰਪੂਟ" ਛੋਟੀ-ਅਵਧੀ ਵਾਲੇ ਬੈਂਚਮਾਰਕ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।
HBM ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਗਤ ਸਿਰਫ਼ ਸਿਲਿਕਨ ਨਹੀਂ ਹੋਦੀ। ਆਧੁਨਿਕ ਪੈਕੇਜਿੰਗ (die stacking, bonding, interposers/substrates), yield, ਟੈਸਟ ਸਮਾਂ, ਅਤੇ ਇੰਟეგਰੇਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਮਿਲਾ ਕੇ ਲਾਗਤ ਬਣਦੀ ਹੈ। ਕੋਈ ਸਪਲਾਇਰ ਜਿਸਦੀ ਪੈਕੇਜਿੰਗ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਮਜ਼ਬੂਤ ਹੋਵੇ—ਅਕਸਰ SK hynix ਦੀਆਂ ਤਾਕਤਾਂ ਵਜੋਂ ਸੂਚਕ—ਵਹੀਂ ਹਕੀਕਤੀ ਲਾਹਾ ਅਤੇ ਉਪਲਬਧਤਾ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦੀ ਹੈ।
ਇਸ ਦਾ ਅਰਥ ਹੈ ਕਿ ਇੱਕ "ਸਸਤਾ $/GB" ਵਿਕਲਪ accelerator ROI ਲਈ ਨੁਕਸਾਨਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਉਹ throughput ਘਟਾ ਦੇਵੇ।
ਇੱਕ ਆਮ ਨਿਯਮ ਵਰਤੋ:
Unit-economics:
ਜੇ ਤੇਜ਼ ਮੈਮੋਰੀ ਆਉਟਪੁੱਟ ਪ੍ਰਤੀ ਘੰਟਾ ਨੂੰ 15% ਵਧਾਉਂਦੀ ਹੈ ਅਤੇ ਸਰਵਰ ਲਾਗਤ 5% ਵਧਦੀ ਹੈ, ਤਾਂ ਇੱਕਾਈ ਅਰਥਸ਼ਾਸਤਰ ਸੁਧਰਦਾ ਹੈ—ਅਤੇ BOM ਬਿੰਦੂ ਉੱਚਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਕੁੱਲ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ।
HBM ਦੀ ਉਪਲਬਧਤਾ ਕੇਵਲ ਵੇਫਰ ਸਮਰੱਥਾ ਨਾਲ ਨਹੀਂ ਬੰਨੀ; ਆਧੁਨਿਕ ਪੈਕੇਜਿੰਗ throughput ਅਤੇ ਕਵਾਲੀਫિકੇਸ਼ਨ ਗੇਟਸ ਵੀ ਸੀਮਤ ਕਰਦੇ ਹਨ। ਮੰਗ ਵਧਣ 'ਤੇ ਲੀਡ ਟਾਈਮ ਵਧ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਨਵੀਆਂ ਲਾਈਨਾਂ ਖੋਲ੍ਹਣ ਲਈ ਨਵੇਂ ਟੂਲ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਕੁਆਲਟੀ ਰੈਂਪ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਖਤਰਨਾਕਤਾ ਘਟਾਉਣ ਲਈ:
ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਨਿਯੰਤਰਿਤ ਪ੍ਰਯੋਗ ਵਾਂਗ ਚੋਣ ਕਰੋ: ਵਰਕਲੋਡ ਨਿਰਧਾਰਤ ਕਰੋ, ਪਲੇਟਫਾਰਮ ਲਾਕ ਕਰੋ, ਅਤੇ ਸਥਾਈ ਥਰਪੂਟ ਮਾਪੋ (ਪੀਕ ਨਹੀਂ)।
ਵਿਕਰਤਾ ਅਤੇ ਇੰਟੀਗਰੇਟਰਾਂ ਤੋਂ ਪੁੱਛਣ ਲਈ ਮੁੱਢਲੇ ਸਵਾਲ:
ਬੈਂਚਮਾਰਕਿੰਗ ਸੁਝਾਵ: ਆਪਣੇ ਅਸਲ ਮਾਡਲ ਅਤੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰੋ; synthetic bandwidth ਟੈਸਟ ਸਹਾਇਕ ਹਨ ਪਰ ਟ੍ਰੇਨਿੰਗ ਸਮਾਂ ਦੀ ਪੂਰੀ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ ਕਰਦੇ।
ਪਾਇਲਟ ਦੌਰਾਨ ਟੈਲੀਮੇਟਰੀ ਜੋ ਇਕੱਠੀ ਕਰੋ ਉਹ ਉਤਰ ਦੇਣ ਵਾਲੇ ਮੈਟਰਿਕਸ ਅਤੇ "ਕਿਉਂ" ਮੈਟਰਿਕਸ ਦੋਹਾਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:
ਜਦੋਂ GPUs ਅਪਪਯੋਗ ਨਹੀਂ ਹੋ ਰਹੇ ਅਤੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਮੈਮੋਰੀ ਸਟਾਲ ਜਾਂ activation recomputation ਬਹੁਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਬਹੁਤ ਵਧੇਰੇ HBM (ਜ਼ਿਆਦਾ/ਤੇਜ਼) ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
ਨੈੱਟਵਰਕ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੇ ਸਕੇਲਿੰਗ ਦੇ ਬਾਅਦ efficiency ਗਿਰ ਜਾਂਦੀ ਹੈ (ਉਦਾ: all-reduce ਸਮਾਂ ਬਹੁਤ ਵੱਧ ਹੋ ਜਾਣਾ)।
ਸਟੋਰੇਜ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੇ ਡੇਟਾ-ਲੋਡਿੰਗ GPUs ਨੂੰ ਫੀਡ ਨਹੀਂ ਕਰ ਰਹੀ ਜਾਂ ਚੇਕਪੌਇੰਟ ਬੋਤਲ-ਨੈਕ ਬਣ ਰਹੇ ਹਨ।
ਜੇ ਤੁਹਾਨੂੰ ਫੈਸਲਾ ਬਣਾਣ ਲਈ ਢਾਂਚਾ ਚਾਹੀਦਾ ਹੈ, ਤਬ /blog/ai-server-tco-basics ਦੇਖੋ।
AI ਸਰਵਰ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਲਾਗਤ ਅਕਸਰ ਇਸ ਗੱਲ ਨਾਲ ਨਿਰਧਾਰਤ ਹੁੰਦੇ ਹਨ ਕਿ ਕੀ ਮੈਮੋਰੀ ਸਬਸਿਸਟਮ GPU ਨੂੰ ਲਗਾਤਾਰ ਬਿਜੀ ਰੱਖ ਸਕਦਾ ਹੈ—ਘੰਟੇ ਘੰਟੇ, ਅਸਲ ਥਰਮਲ ਅਤੇ ਪਾਵਰ ਸੀਮਾਵਾਂ ਹੇਠਾਂ।
ਮੁੱਖ ਨੁਕਤੇ:
ਅਗਲਾ ਕਦਮ ਚੈੱਕਲਿਸਟ:
ਇਹ ਮਿਲਾ ਕੇ ਤੁਹਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਕੀ ਤੁਸੀਂ HBM, DDR5, ਸਾਫਟਵੇਅਰ ਕੁਸ਼ਲਤਾ ਜਾਂ ਥਰਮਲਾਂ ਨਾਲ ਸੀਮਿਤ ਹੋ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਅੰਦਰੂਨੀ ਟੂਲ ਨਹੀਂ ਹੈ ਤਾਂ platforms like Koder.ai ਤੇਜ਼ੀ ਨਾਲ ਹਲ ਬਣਾਉਣ ਵਿਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ — ਚੈਟ-ਡ੍ਰਿਵਨ ਵਰਕਫਲੋ ਦੁਆਰਾ ਡੈਸ਼ਬੋਰਡ, ਰਨਬੁਕਸ, ਜਾਂ "ਦੋ ਨੋਡਾਂ ਦੀ ਤੁਲਨਾ" ਪਾਇਲਟ ਰਿਪੋਰਟ ਬਣਾਉਣ ਅਤੇ ਫਿਰ ਜਦੋਂ ਤਿਆਰ ਹੋ ਤਾਂ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰਨ ਲਈ।