ਮੈਂ ਸਿਰਫ਼ 3.2 GB RAM ਵਾਲੇ ਲੈਪਟਾਪ 'ਤੇ 284-ਬਿਲੀਅਨ-ਪੈਰਾਮੀਟਰ ਵਾਲਾ ਲੈਂਗੂਏਜ ਮਾਡਲ ਚਲਾਉਣ ਵਿੱਚ ਸਫਲ ਰਿਹਾ, ਜਿਸ ਲਈ ਮੈਂ ਸਿਰਫ਼ plain C99 ਅਤੇ ਇੱਕ NVMe ਡਰਾਈਵ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਚਾਲ ਇਹ ਸੀ ਕਿ ਪੂਰੇ 160 GB ਚੈੱਕਪੁਆਇੰਟ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਲੋਡ ਕਰਨ ਦੀ ਬਜਾਏ ਮਾਡਲ ਦੇ expert weights ਨੂੰ stream ਕੀਤਾ, ਜੋ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਵੱਡੇ ਤੋਂ ਵੱਡੇ mixture-of-experts (MoE) ਮਾਡਲਾਂ ਨੂੰ ਵੀ ਆਮ ਕੰਸਿਊਮਰ ਹਾਰਡਵੇਅਰ 'ਤੇ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

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

Large language models (LLMs) ਕੋਡ ਜਨਰੇਸ਼ਨ, ਰਿਸਰਚ ਅਸਿਸਟੈਂਸ ਅਤੇ ਹੋਰ ਕੰਮਾਂ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਦਾ ਆਕਾਰ ਆਮ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਮਹਿੰਗੇ multi-GPU ਸਰਵਰਾਂ ਜਾਂ ਭਾਰੀ quantisation ਵੱਲ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਜੋ ਗੁਣਵੱਤਾ (quality) ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। ਇਹ ਦਿਖਾਉਣਾ ਕਿ ਇੱਕ 284 B-parameter MoE ਮਾਡਲ ਕੁਝ ਗੀਗਾਬਾਈਟ RAM ਨਾਲ ਚੱਲ ਸਕਦਾ ਹੈ, ਸ਼ੌਕੀਆ (hobbyists), ਛੋਟੇ ਸਟਾਰਟਅੱਪਸ ਅਤੇ ਸੀਮਤ ਬਜਟ ਵਾਲੇ ਖੋਜਕਰਤਾਵਾਂ ਲਈ ਗੁਣਵੱਤਾ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤੇ ਬਿਨਾਂ state-of-the-art ਮਾਡਲਾਂ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨ ਦੇ ਦਰਵਾਜ਼ੇ ਖੋਲ੍ਹਦਾ ਹੈ।

ਮਾਡਲ ਅਤੇ ਹਾਰਡਵੇਅਰ ਦੀ ਰੁਕਾਵਟ

DeepSeek-V4-Flash ਹਰ transformer layer ਵਿੱਚ 256 experts ਵਿੱਚ 284 B parameters ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ। Raw checkpoint ਡਿਸਕ 'ਤੇ ਲਗਭਗ 160 GB ਜਗ੍ਹਾ ਲੈਂਦਾ ਹੈ—ਇੱਕ ਅਜਿਹਾ ਆਕਾਰ ਜੋ ਇੱਕ ਆਮ ਲੈਪਟਾਪ ਦੀ 3.2 GB RAM ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਵੱਡਾ ਹੈ। ਰਵਾਇਤੀ inference pipelines ਪੂਰੇ ਚੈੱਕਪੁਆਇੰਟ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਮੈਪ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ RAM ਜਲਦੀ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸਿਸਟਮ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ।

Streaming expert weights: ਮੁੱਖ ਵਿਚਾਰ

MoE architectures ਹਰ token ਲਈ ਮਾਡਲ ਦੇ ਮਾੜੇ ਹਿੱਸੇ (tiny subset) ਦੇ experts ਨੂੰ ਹੀ ਐਕਟੀਵੇਟ ਕਰਦੇ ਹਨ। DeepSeek-V4-Flash ਵਿੱਚ, router ਹਰ layer ਵਿੱਚ 256 ਵਿੱਚੋਂ ਛੇ experts ਦੀ ਚੋਣ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ ਕੰਪਿਊਟੇਸ਼ਨ ਕਦੇ ਵੀ ਸੌਂਏ ਹੋਏ (dormant) experts ਨੂੰ ਨਹੀਂ ਛੂਹੰਦੀ, ਇਸ ਲਈ inference engine ਉਹਨਾਂ ਨੂੰ ਲੋਡ ਕਰਨ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ।

ਇਹ implementation ਚੈੱਕਪੁਆਇੰਟ ਨੂੰ ਇੱਕ streaming source ਵਜੋਂ ਮੰਨਦਾ ਹੈ। ਜਦੋਂ router ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਮੌਜੂਦਾ token ਲਈ ਕਿਹੜੇ experts ਦੀ ਲੋੜ ਹੈ, ਤਾਂ engine ਉਹਨਾਂ weight blocks ਨੂੰ NVMe ਡਰਾਈਵ ਤੋਂ RAM ਵਿੱਚ ਮੌਜੂਦ ਇੱਕ LRU (least-recently-used) cache ਵਿੱਚ ਖਿੱਚ ਲੈਂਦਾ ਹੈ। ਜੇਕਰ cache ਕਾਫ਼ੀ ਵੱਡਾ ਹੈ, ਤਾਂ ਲਗਾਤਾਰ tokens ਵਿੱਚ ਉਹੀ experts ਦੁਬਾਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ cache hits ਮਿਲਦੇ ਹਨ; ਜੇਕਰ cache ਬਹੁਤ ਛੋਟਾ ਹੈ, ਤਾਂ engine ਡਿਸਕ ਤੋਂ ਵਾਰ-ਵਾਰ ਡਾਟਾ ਪੜ੍ਹਦਾ ਹੈ। ਇਸ ਦਾ ਨਤੀਜਾ 3.23 GB ਦਾ peak memory footprint ਹੈ, ਜੋ ਲੈਪਟਾਪ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਹੈ, ਜਦੋਂ ਕਿ full-precision weights ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਿਸੇ GPU acceleration ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।

Implementation ਤੋਂ ਮਿਲੇ ਅਹਿਮ ਸਬਕ

1. ਸਹੀ ਸ਼ਬਦਾਂ ਵਿੱਚ ਆਉਂਦਾ ਆਊਟਪੁੱਟ ਸਹੀ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ ਇੱਕ ਬੱਗੀ (buggy) kernel ਅਜੇ ਵੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਣ ਵਾਲੇ ਵਾਕ ਬਣਾ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਮਾਡਲ ਦੇ ਭਾਸ਼ਾ ਪੈਟਰਨ ਨੰਬਰਲ (numerical) ਗਲਤੀਆਂ ਨੂੰ ਛੁਪਾ ਲੈਂਦੇ ਹਨ। ਮੈਂ ਹਰੇਕ 14 ਮਹੱਤਵਪੂਰਨ ਕਾਰਜਾਂ (operations) ਨੂੰ ਇੱਕ ਤਾਜ਼ਾ PyTorch reference ਨਾਲ ਮਿਲਾ ਕੇ ਦੇਖਿਆ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਕਿ ਨੰਬਰਲ ਅੰਤਰ ਇੱਕ ਬਹੁਤ ਹੀ ਛੋਟੀ ਸੀਮਾ (tolerance) ਦੇ ਅੰਦਰ ਰਹੇ। ਇਸ ਕਦਮ ਨੂੰ ਛੱਡਣ ਨਾਲ ਬਾਰੀਕ ਗਲਤੀਆਂ ਨਜ਼ਰਅੰਦ ਹੋ ਸਕਦੀਆਂ ਸਨ।

2. ਸਾਂਝੇ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਤਰੀਕੇ ਤੁਹਾਡੇ ਟੈਸਟਾਂ ਨੂੰ ਧੋਖਾ ਦੇ ਸਕਦੇ ਹਨ ਇੱਕ memory-corruption bug ਨੇ routing ਚੋਣਾਂ ਨੂੰ ਕੁਝ ਹੀ experts ਤੱਕ ਸੀਮਤ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ cache-hit rate 52% ਤੋਂ ਵਧ ਕੇ 95% ਹੋ ਗਿਆ ਅਤੇ ਬਹੁਤ ਤੇਜ਼ ਰਫ਼ਤਾਰ ਦਾ ਭਰਮ ਹੋ ਗਿਆ। ਕਿਉਂਕਿ test suite ਨੇ ਇੱਕੋ ਬੱਗੀ ਕੋਡ ਦੇ ਦੋ ਵਰਜ਼ਨਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਸੀ, ਇਸ ਲਈ ਇਹ ਸਮੱਸਿਆ ਨੂੰ ਫੜ ਨਹੀਂ ਸਕਿਆ। ਇਸ ਦਾ ਹੱਲ ਇੱਕ ਸੁਤੰਤਰ reference path ਜੋੜਨਾ ਹੈ—ਅਜਿਹਾ ਕੋਡ ਜਿਸਦਾ ਮੁੱਖ implementation ਨਾਲ ਕੋਈ ਸਾਂਝਾ ਲੌਜਿਕ ਨਾ ਹੋਵੇ—so ਕਿ ਕੋਈ ਸਾਂਝੀ ਖਾਮੀ ਬਿਨਾਂ ਨਜ਼ਰ ਆਏ ਨਾ ਲੰਘ ਸਕੇ।

3. ਆਪਟੀਮਾਈਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪੋ ਮੈਂ ਇਹ ਮੰਨ ਲਿਆ ਸੀ ਕਿ ਇੱਕ memory copy ਵਿੱਚ 1 ms ਲੱਗਦਾ ਹੈ ਅਤੇ ਮੈਂ ਇਸ ਨੂੰ ਆਪਟੀਮਾਈਜ਼ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਬਰਬਾਦ ਕੀਤਾ। Profiling ਤੋਂ ਪਤਾ ਲੱਗਾ ਕਿ ਇਸ ਕਾਰਜ ਵਿੱਚ ਅਸਲ ਵਿੱਚ 3.6 ms ਲੱਗ ਰਹੇ ਸਨ, ਜੋ ਕਿ ਕੁੱਲ inference time ਦਾ 22% ਸੀ। ਸਬਕ: ਪ੍ਰਦਰਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ (performance-critical) ਹਿੱਸਿਆਂ ਲਈ ਕਦੇ ਵੀ ਅੰਦਾਜ਼ੇ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ; ਸਹੀ ਮਾਪ ਹੀ ਇੱਕੋ ਇੱਕ ਭਰੋਸੇਯੋਗ ਮਾਰਗਦਰਸ਼ਕ ਹੈ।

4. ਤਾਪਮਾਨ ਦੀਆਂ ਸਥਿਤੀਆਂ throughput ਨੂੰ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ ਇੱਕ "ਗਰਮ" (heat-soaked) ਲੈਪਟਾਪ 'ਤੇ benchmarks ਚਲਾਉਣ ਨਾਲ ਰਨ-ਟਾਈਮ ਇੱਕ ਠੰਢੇ ਮਸ਼ੀਨ ਦੇ ਮੁਕਾਬਲੇ ਤਿੰਨ ਗੁਣਾ ਤੱਕ ਹੌਲੀ ਰਿਹਾ। ਵਧੇ ਹੋਏ ਤਾਪਮਾਨ ਨੇ NVMe ਡਰਾਈਵ ਦੀ throughput ਨੂੰ ਘਟਾ ਦਿੱਤਾ ਅਤੇ CPU ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਨਤੀਜੇ ਵਿਗੜ ਗਏ। ਜਦੋਂ ਵੀ ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਅੰਕੜੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ਸਿਸਟਮ ਦੀ thermal ਸਥਿਤੀ ਨੂੰ ਜ਼ਰੂਰ ਦਰਜ ਕਰੋ।

ਅੰਕੜੇ ਕਿਹੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ

  • ਡਿਸਕ 'ਤੇ ਮਾਡਲ ਦਾ ਆਕਾਰ: ~160 GB
  • Peak RAM ਦੀ ਵਰਤੋਂ: 3.23 GB
  • ਪ੍ਰਤੀ token experts: 6 (256 ਵਿੱਚੋਂ)
  • Cache-hit rate: RAM ਦੇ ਨਾਲ ਬਦਲਦਾ ਹੈ; 3.2 GB ਦੇ ਨਾਲ ਇਹ ਉਤਾਰ-ਚੜ੍ਹਾਅ ਵਾਲਾ ਰਹਿੰਦਾ ਹੈ।
  • No quantisation: full-precision weights ਨੂੰ stream ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮਾਡਲ ਦੀ ਗੁਣਵੱਤਾ ਬਣੀ ਰਹਿੰਦੀ ਹੈ।

ਜੇਕਰ RAM ਬਜਟ ਲਗਭਗ 3.21 GB ਤੋਂ ਹੇਠਾਂ ਡਿੱਗਦਾ ਹੈ, ਤਾਂ cache ਕਦੇ ਵੀ ਨਹੀਂ ਭਰਦਾ ਅਤੇ engine ਹਰ token 'ਤੇ stream ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਭਾਰੀ ਗਿਰਾਵਟ ਆਉਂਦੀ ਹੈ।

ਸੋਰਸ ਕੋਡ github.com/ronak-create/deepseek-v4-in-c 'ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੈ। ਜੇਕਰ ਕੋਈ ਇਸ ਪ੍ਰਯੋਗ ਨੂੰ ਦੁਹਰਾਉਣਾ ਜਾਂ ਵਧਾਉਣਾ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ t.me/GyaanSetuAi 'ਤੇ ਇੱਕ ਕਮਿਊਨਿਟੀ ਡਿਸਕਸ਼ਨ ਚੈਨਲ ਮੌਜੂਦ ਹੈ।

ਸਿੱਟਾ (Takeaway)

ਸਿਰਫ਼ ਉਹਨਾਂ experts ਨੂੰ ਸਟ੍ਰੀਮ ਕਰਨਾ ਜਿਨ੍ਹਾਂ ਦੀ ਇੱਕ MoE ਮਾਡਲ ਅਸਲ ਵਿੱਚ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਇੱਕ 284 B-parameter LLM ਨੂੰ ਬਿਨਾਂ quantisation ਜਾਂ GPU acceleration ਦੇ ਇੱਕ ਸਾਧਾਰਨ ਲੈਪਟਾਪ 'ਤੇ ਚਲਾਉਣਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਪ੍ਰਯੋਗ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਡੇਟਾ ਦੀ ਚਲਾਕੀ ਨਾਲ ਕੀਤੀ ਗਈ ਹਰਕਤ, ਸਖ਼ਤ ਵੈਲੀਡੇਸ਼ਨ, ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਮਾਪ ਉਹਨਾਂ ਹਾਰਡਵੇਅਰ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਟਾਲ ਸਕਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਈ ਲੋਕ ਅਟੱਲ ਮੰਨਦੇ ਹਨ।