Cloud APIs ਉਦੋਂ ਤੱਕ ਸੁਵਿਧਾਜਨਕ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਉਹ ਸੁਵਿਧਾਜਨਕ ਰਹਿਣਾ ਬੰਦ ਨਹੀਂ ਹੋ ਜਾਂਦੇ। ਤੁਹਾਡਾ ਮਹੀਨਾਵਾਰ ਬਿੱਲ ਵਧਦਾ ਜਾਂਦਾ ਹੈ। ਕੀਮਤਾਂ ਵਿੱਚ ਬਦਲਾਅ ਤੁਹਾਡੇ ਬਜਟ ਨੂੰ ਵਿਗਾੜ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਕਿਤੇ ਨਾ ਕਿਤੇ ਛੋਟੇ ਅੱਖਰਾਂ (fine print) ਵਿੱਚ, ਤੁਹਾਡਾ ਮਾਲਕਾਨਾ ਡਾਟਾ ਕਿਸੇ ਹੋਰ ਦੇ ਮਾਡਲ ਨੂੰ ਟ੍ਰੇਨ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਰੁਕਾਵਟ ਵਧੇਰੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਲੋਕਲ AI ਵਰਕਸਟੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰ ਰਹੀ ਹੈ। ਤੁਸੀਂ ਹਾਰਡਵੇਅਰ ਇੱਕ ਵਾਰ ਖਰੀਦਦੇ ਹੋ, ਪੂਰੇ ਸਟੈਕ ਦੇ ਮਾਲਕ ਬਣਦੇ ਹੋ, ਅਤੇ ਇਹ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਤੋਂ ਕਿਹੜਾ ਡਾਟਾ ਬਾਹਰ ਜਾਵੇਗਾ।

ਇਸ ਹਫ਼ਤੇ ਤਿੰਨ ਅਜਿਹੀਆਂ ਮਹੱਤਵਪੂਰਨ ਘਟਨਾਵਾਂ ਸਾਹਮਣੇ ਆਈਆਂ ਹਨ ਜੋ ਇਸ ਤਬਦੀਲੀ ਨੂੰ ਹੋਰ ਵਿਹਾਰਕ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਇੱਕ Dockerized ਟ੍ਰੇਡਿੰਗ ਸਹਾਇਕ ਜੋ ਤੁਹਾਡੇ ਵਿੱਤੀ ਡਾਟਾ ਨੂੰ ਘਰ ਵਿੱਚ ਹੀ ਰੱਖਦਾ ਹੈ, NVIDIA GPUs ਨੂੰ ਆਪਣੇ ਕੰਟਰੋਲ ਵਿੱਚ ਲੈਣ ਲਈ ਇੱਕ ਸਿੱਧੀ ਗਾਈਡ, ਅਤੇ Hugging Face ਵੱਲੋਂ ਇੱਕ ਨਵਾਂ ਰਿਲੀਜ਼ ਜੋ ਰੋਬੋਟ ਲਰਨਿੰਗ ਨੂੰ ਇੱਕ ਆਮ ਕੰਪਿਊਟਰ ਡੈਸਕਟੌਪ ਤੱਕ ਪਹੁੰਚਾਉਂਦਾ ਹੈ।

Docker ਨਾਲ ਆਪਣਾ ਟ੍ਰੇਡਿੰਗ ਡਾਟਾ ਲੋਕਲ ਰੱਖੋ

ਇੱਕ ਡਿਵੈਲਪਰ ਨੇ TradingSpy ਲਾਂਚ ਕੀਤਾ ਹੈ, ਜੋ ਖਾਸ ਤੌਰ 'ਤੇ ਟ੍ਰੇਡਿੰਗ ਵਰਕਫਲੋ ਲਈ ਬਣਾਇਆ ਗਿਆ ਇੱਕ ਲੋਕਲ AI ਰਿਸਰਚ ਸਹਾਇਕ ਹੈ। ਮਾਰਕੀਟ ਡਾਟਾ ਅਤੇ ਨਿੱਜੀ ਵਾਚਲਿਸਟਾਂ ਨੂੰ ਕਿਸੇ ਰੀਮੋਟ ਐਂਡਪੁਆਇੰਟ 'ਤੇ ਭੇਜਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਸਭ ਕੁਝ ਆਪਣੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਇੱਕ Docker ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਚਲਾਉਂਦੇ ਹੋ।

ਵਿੱਤੀ ਡਾਟਾ ਬਹੁਤ ਹੀ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਸੰਭਵ ਹੋਵੇ, ਤਾਂ ਤੁਹਾਡੇ ਪੋਰਟਫੋਲੀਓ ਦੀ ਬਣਤਰ, ਟ੍ਰੇਡਿੰਗ ਨੋਟਸ, ਅਤੇ ਪੁਰਾਣੀਆਂ ਪੋਜੀਸ਼ਨਾਂ ਕਿਸੇ ਤੀਜੀ-ਪਾਰਟੀ API ਰਾਹੀਂ ਨਹੀਂ ਲੰਘਣੀਆਂ ਚਾਹੀਦੀਆਂ। ਮਾਡਲ ਨੂੰ ਲੋਕਲ ਚਲਾਉਣ ਨਾਲ ਉਹ ਖਤਰਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਕੰਟੇਨਰ ਇਨਫਰੈਂਸ (inference) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਰਅਅ (raw) ਬ੍ਰੋਕਰੇਜ ਡਾਟਾ ਕਦੇ ਵੀ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਜਾਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।

Docker ਉਸ ਉਲਝਣ ਭਰੀ ਡਿਪੈਂਡੈਂਸੀ (dependency) ਸਮੱਸਿਆ ਨੂੰ ਵੀ ਹੱਲ ਕਰਦਾ ਹੈ ਜੋ Python ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਆਉਂਦੀ ਹੈ। ਟ੍ਰੇਡਿੰਗ ਸਟੈਕਸ ਵਿੱਚ ਅਕਸਰ pandas ਵਰਗੀਆਂ ਡਾਟਾ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਟੈਕਨੀਕਲ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲਕਿੱਟਸ, ਅਤੇ GPU-accelerated ਇਨਫਰੈਂਸ ਇੰਜਣਾਂ ਦਾ ਮਿਸ਼ਰਣ ਹੁੰਦਾ ਹੈ। ਆਇਸੋਲੇਸ਼ਨ (isolation) ਤੋਂ ਬਿਨਾਂ, ਇੱਕ ਪ੍ਰੋਜੈਕਟ CUDA 11.8 ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਦੂਜਾ 12.1 ਚਾਹੁੰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਬੇਸ ਸਿਸਟਮ ਟਕਰਾ ਰਹੇ environment variables ਦਾ ਇੱਕ ਕਬਰਸਤਾਨ ਬਣ ਜਾਂਦਾ ਹੈ। Docker ਹਰੇਕ ਡਿਪੈਂਡੈਂਸੀ ਗ੍ਰਾਫ ਨੂੰ ਉਸਦੀ ਆਪਣੀ ਇਮੇਜ ਵਿੱਚ ਲਾਕ ਕਰ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਵਾਰ ਬਣਾਉਂਦੇ ਹੋ, ਅਤੇ ਇਹ ਇੱਕ headless Ubuntu ਸਰਵਰ, WSL2 ਦੇ ਨਾਲ Windows 11 ਡੈਸਕਟੌਪ, ਜਾਂ ਇੱਕ ਛੋਟੇ homelab NAS 'ਤੇ ਬਿਲਕੁਲ ਇੱਕੋ ਜਿਹਾ ਚੱਲਦਾ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ ਲੋਕਲ ਡਾਟਾ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਕੰਟੇਨਰ ਵਿੱਚ bind-mount ਵੀ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਤੁਹਾਡੀਆਂ ਫਾਈਲਾਂ ਤੁਹਾਡੇ ਫਾਈਲਸਿਸਟਮ 'ਤੇ ਰਹਿਣ ਅਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਾਤਾਵਰਣ ਸਾਫ਼ ਰਹੇ।

ਇੱਥੇ ਲਾਗਤ ਦਾ ਵੀ ਇੱਕ ਪਹਿਲੂ ਹੈ। Cloud LLM APIs ਪ੍ਰਤੀ ਟੋਕਨ (token) ਚਾਰਜ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਸੈਂਕੜੇ ਟਿਕਰਾਂ (tickers) ਵਿੱਚ ਪ੍ਰੀ-ਮਾਰਕੀਟ ਸਕੈਨ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਮਾਡਲ ਵਿੱਚ ਪ੍ਰਾਈਸ ਐਕਸ਼ਨ, ਖ਼ਬਰਾਂ ਦੇ ਸਾਰਾਂਸ਼, ਅਤੇ ਟੈਕਨੀਕਲ ਇੰਡੀਕੇਟਰ ਪਾ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਕਾਲਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੀਆਂ ਹਨ। ਇੱਕ ਲੋਕਲ ਮਾਡਲ ਵਿੱਚ ਕੋਈ ਮੀਟਰ ਨਹੀਂ ਚੱਲਦਾ। GPU ਦੀ ਸ਼ੁਰੂਆਤੀ ਲਾਗਤ ਇੱਕ ਵਾਰ ਦਰਦ ਦਿੰਦੀ ਹੈ; API ਬਿੱਲ ਹਰ ਮਹੀਨੇ ਦਰਦ ਦਿੰਦਾ ਹੈ।

NVIDIA GPU ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਸਮਝਣਾ

Cloud APIs ਤੋਂ ਇੱਕ ਲੋਕਲ NVIDIA ਕਾਰਡ 'ਤੇ ਜਾਣਾ PyTorch ਇੰਸਟਾਲ ਕਰਨ ਅਤੇ .to('cuda') ਕਾਲ ਕਰਨ ਜਿੰਨਾ ਸੌਖਾ ਨਹੀਂ ਹੈ। ਇਸ ਵਿੱਚ ਸਿੱਖਣ ਦੀ ਇੱਕ ਅਸਲ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਸਮਝਣਾ ਇੱਕ ਸ਼ੌਕੀਆ ਸਕ੍ਰਿਪਟ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਵਰਕਸਟੇਸ਼ਨ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

Cloud APIs ਹਾਰਡਵੇਅਰ ਨੂੰ ਛੁਪਾਉਂਦੀਆਂ ਹਨ। ਤੁਸੀਂ JSON ਭੇਜਦੇ ਹੋ, ਤੁਹਾਨੂੰ JSON ਮਿਲਦਾ ਹੈ। ਲੋਕਲ ਪੱਧਰ 'ਤੇ, ਤੁਸੀਂ ਸਿਸਟਮ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰ ਹੋ। ਤੁਹਾਨੂੰ ਸਹੀ ਡਰਾਈਵਰ, ਇੱਕ ਅਨੁਕੂਲ (compatible) CUDA toolkit, ਅਤੇ ਤੁਹਾਡੇ GPU ਆਰਕੀਟੈਕਚਰ ਲਈ ਕੰਪਾਈਲ ਕੀਤਾ ਗਿਆ PyTorch ਬਿਲਡ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਤੁਹਾਨੂੰ ਉਸਨੂੰ ਆਪਣੇ runtime ਨਾਲ ਜੋੜਨਾ ਪੈਂਦਾ ਹੈ, ਚਾਹੇ ਇਸਦਾ ਮਤਲਬ ਕੰਟੇਨਰਾਂ ਲਈ nvidia-docker runtime ਨੂੰ ਕੰਫਿਗ ਕਰਨਾ ਹੋਵੇ ਜਾਂ bare metal 'ਤੇ LD_LIBRARY_PATH ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨਾ ਹੋਵੇ। ਹਰੇਕ ਲੇਅਰ ਦਾ ਇੱਕ version tuple ਹੁੰਦਾ ਹੈ ਜੋ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਇਹ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਤੁਹਾਨੂੰ ਮਿਸਿੰਗ ਲਾਇਬ੍ਰੇਰੀਆਂ ਜਾਂ ਅਣ-ਸ਼ੁਰੂ ਕੀਤੇ (uninitialized) ਡਿਵਾਈਸਾਂ ਬਾਰੇ ਰਹੱਸਮਈ ਗਲਤੀਆਂ (cryptic errors) ਮਿਲਦੀਆਂ ਹਨ।

ਇਸਦਾ ਫਾਇਦਾ ਸਿੱਧਾ ਹਾਰਡਵੇਅਰ ਕੰਟਰੋਲ ਹੈ। ਤੁਸੀਂ ਸਿੱਖਦੇ ਹੋ ਕਿ GPU ਮੈਮੋਰੀ ਇੱਕ ਸਖ਼ਤ ਸੀਮਾ (hard ceiling) ਹੈ। ਸਿਸਟਮ RAM ਦੇ ਉਲਟ, ਜਿੱਥੇ OS ਸਵੈਪ (swap) ਅਤੇ ਪੇਜ (page) ਕਰ ਸਕਦਾ ਹੈ, VRAM ਖਤਮ ਹੋਣ ਦਾ ਮਤਲਬ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕ੍ਰੈਸ਼ ਹੋਇਆ ਟ੍ਰੇਨਿੰਗ ਜੌਬ ਜਾਂ ਇੱਕ ਇਨਫਰੈਂਸ ਬੈਚ ਹੈ ਜੋ ਤੁਰੰਤ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਹ ਸੀਮਾ ਤੁਹਾਨੂੰ ਬੈਚ ਸਾਈਜ਼ਿੰਗ, ਮਿਕਸਡ-ਪ੍ਰੇਸੀਜ਼ਨ ਟ੍ਰੇਨਿੰਗ, ਅਤੇ ਮੈਮੋਰੀ ਪ੍ਰੋਫਾਈਲਿੰਗ ਬਾਰੇ ਸੋਚਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। ਤੁਸੀਂ ਕੰਪਿਊਟ ਨੂੰ ਇੱਕ ਅਨੰਤ ਸਹੂਲਤ ਵਜੋਂ ਦੇਖਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਸੀਮਤ ਸਰੋਤ ਵਜੋਂ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ ਜਿਸਦਾ ਤੁਸੀਂ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹੋ।

ਇਸ ਹਫ਼ਤੇ ਚੱਲ ਰਹੀ ਇੱਕ ਲਾਭਦਾਇਕ ਗਾਈਡ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਅਤੇ ਕੰਜ਼ਿਊਮਰ GPUs ਨੂੰ ਇੱਕੋ ਜਿਹੀ ਕਿਸਮ ਵਜੋਂ

Hugging Face ਨੇ LeRobot ਦਾ version 0.6.0 ਜਾਰੀ ਕੀਤਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਅਜਿਹਾ framework ਹੈ ਜੋ chatbots ਅਤੇ image generators ਦੇ ਪਿੱਛੇ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ Transformers ਅਤੇ Diffusers libraries ਨੂੰ ਇੱਕ ਬਹੁਤ ਹੀ ਵੱਖਰੇ ਕੰਮ ਲਈ ਵਰਤਦਾ ਹੈ: robot learning। ਅਗਲੇ ਸ਼ਬਦ ਜਾਂ pixel ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਦੀ ਬਜਾਏ, ਇਹ ਮਾਡਲ ਕੈਮਰਾ ਫੀਡ ਅਤੇ ਭਾਸ਼ਾ ਦੇ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਅਗਲੀ motor action ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦਾ ਹੈ।

ਰੋਬੋਟਿਕਸ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਇੱਕ ਅਜਿਹਾ ਖੇਤਰ ਰਿਹਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਲੈਬਾਂ ਤੱਕ ਸੀਮਤ ਸੀ ਜਿਨ੍ਹਾਂ ਕੋਲ motion-capture ਰੂਮਾਂ ਅਤੇ industrial GPUs ਦੇ ਕਲੱਸਟਰਾਂ ਤੱਕ ਪਹੁੰਚ ਸੀ। LeRobot ਉਸ ਰੁਕਾਵਟ ਨੂੰ ਘਟਾ ਰਿਹਾ ਹੈ। Version 0.6.0 ਇਸ ਗੱਲ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ robotic policies ਨੂੰ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ, ਟ੍ਰੇਨ ਅਤੇ ਮੁਲਾਂਕਣ (evaluate) ਕਰਦੇ ਹੋ। ਤੁਸੀਂ simulation ਵਿੱਚ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾ ਸਕਦੇ ਹੋ, policy architecture 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਹਜ਼ਾਰਾਂ ਲਾਈਨਾਂ ਦਾ low-level control code ਲਿਖੇ ਬਿਨਾਂ ਇੱਕ ਅਸਲੀ arm ਜਾਂ mobile base 'ਤੇ ਇਸ ਨੂੰ ਤਬਦੀਲ ਕਰ ਸਕਦੇ ਹੋ।

ਇਸ ਰਿਲੀਜ਼ ਦੀ ਖਾਸ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ consumer GPUs ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀ ਹੈ। ਪ੍ਰਯੋਗ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ server rack ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇੱਕ ਸਿੰਗਲ high-end consumer card ਅਜਿਹੀਆਂ policies ਨੂੰ ਟ੍ਰੇਨ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਅਸਲੀ grippers ਅਤੇ arms 'ਤੇ ਵੀ ਕੰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਇੱਕ ਸਪੱਸ਼ਟ ਸੰਕੇਤ ਹੈ ਕਿ open-weight models ਹੁਣ cloud ਤੋਂ ਬਾਹਰ ਨਿਕਲ ਕੇ physical hardware ਤੱਕ ਪਹੁੰਚ ਰਹੇ ਹਨ। ਇਹ weights ਤੁਹਾਡੀ ਡਰਾਈਵ 'ਤੇ ਰਹਿੰਦੇ ਹਨ। ਰੋਬੋਟ ਨੂੰ ਕਿਸੇ API ਤੱਕ network round-trip ਕੀਤੇ ਬਿਨਾਂ ਹੀ commands ਮਿਲ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਅਸਲੀ ਦੁਨੀਆ ਵਿੱਚ ਚੱਲਣ ਵਾਲੀ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਕੰਟਰੋਲ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ, ਤਾਂ latency ਅਤੇ privacy ਦੇ ਫਾਇਦਿਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

ਇਹ ਸੌਫਟਵੇਅਰ ਅਤੇ ਹਾਰਡਵੇਅਰ ਦੇ ਵਿਚਕਾਰਲੇ ਅੰਤਰ ਬਾਰੇ ਤੁਹਾਡੀ ਸੋਚ ਨੂੰ ਵੀ ਬਦਲਦਾ ਹੈ। ਪਹਿਲਾਂ robotic policies ਸਿਰਫ਼ ਖੋਜ ਪੱਤਰਾਂ (papers) ਤੱਕ ਸੀਮਤ ਸਨ। ਹੁਣ ਉਹ ਅਜਿਹੇ repositories ਵਿੱਚ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ clone ਕਰ ਸਕਦੇ ਹੋ, ਆਪਣੇ motion data 'ਤੇ fine-tune ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਆਪਣੇ ਕੋਲ ਮੌਜੂਦ ਹਾਰਡਵੇਅਰ 'ਤੇ deploy ਕਰ ਸਕਦੇ ਹੋ।

ਅਸਲੀ ਜਿੱਤ ਕੰਟਰੋਲ ਵਿੱਚ ਹੈ

ਇੱਕ local AI stack ਬਣਾਉਣ ਦਾ ਮਤਲਬ ਸਿਧਾਂਤਕ ਤ