LiteRT.js, TensorFlow.js ਨੂੰ ਪਛਾੜ ਰਿਹਾ ਹੈ
WebGPU ਦੇ ਨਾਲ LiteRT.js ਇੱਕ MobileNetV2 inference ਨੂੰ 0.41 ms ਵਿੱਚ ਚਲਾਉਂਦਾ ਹੈ, ਜੋ ਕਿ M2 Max ਡੈਸਕਟਾਪ GPU 'ਤੇ 2,439 FPS ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ—ਇਹ ਉਸੇ ਹਾਰਡਵੇਅਰ 'ਤੇ TensorFlow.js ਨਾਲੋਂ 25 × ਤੋਂ ਵੀ ਵੱਧ ਤੇਜ਼ ਹੈ। ਵੱਡੇ ਮਾਡਲਾਂ ਲਈ ਇਹ ਅੰਤਰ ਹੋਰ ਵੀ ਵਧ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਵੈੱਬ-ਅਧਾਰਤ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਨੂੰ ਉਸ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਪੱਧਰ 'ਤੇ ਲੈ ਜਾਂਦਾ ਹੈ ਜੋ ਕਦੇ ਸਿਰਫ਼ ਨੇਟਿਵ ਐਪਸ (native apps) ਲਈ ਹੀ ਸੀਮਤ ਸੀ।
ਬੈਂਚਮਾਰਕ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਡਿਵੈਲਪਰ ਆਮ ਤੌਰ 'ਤੇ WebGL backend ਰਾਹੀਂ ਡਿਵਾਈਸ 'ਤੇ inference ਲਈ TensorFlow.js ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਆ ਰਹੇ ਹਨ। WebGL tensor ops ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਦੇ 2-D ਗ੍ਰਾਫਿਕਸ ਪਾਈਪਲਾਈਨ 'ਤੇ ਮੈਪ ਕਰਦਾ ਹੈ; ਇਹ ਹਰ ਜਗ੍ਹਾ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਇਸਨੂੰ ਡੀਪ-ਲਰਨਿੰਗ ਮਾਡਲਾਂ ਲਈ ਲੋੜੀਂਦੀ ਵਿਸ਼ਾਲ ਪੈਰਲਲਿਜ਼ਮ (parallelism) ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਸੀ। WebGPU, ਜੋ ਕਿ ਅਗਲੀ ਪੀੜ੍ਹੀ ਦੀ ਗ੍ਰਾਫਿਕਸ API ਹੈ, GPU ਕੰਪਿਊਟ ਯੂਨਿਟਾਂ ਤੱਕ ਸਿੱਧੀ ਪਹੁੰਚ ਦਿੰਦੀ ਹੈ। LiteRT.js ਪਹਿਲੀ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ TensorFlow-Lite ਮਾਡਲਾਂ ਲਈ WebGPU-ਅਧਾਰਤ inference engine ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਅਤੇ Google ਨੇ ਤਿੰਨ ਗੁਣਾ ਤੇਜ਼ੀ ਦੀ ਰਿਪੋਰਟ ਦਿੱਤੀ ਹੈ। ਸੁਤੰਤਰ ਟੈਸਟਾਂ ਤੋਂ ਹੋਰ ਵੀ ਵੱਧ ਫਾਇਦਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਜੋ ਇਹ ਸਵਾਲ ਖੜ੍ਹਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ WebGPU ਵੈੱਬ ML ਲਈ ਡਿਫੌਲਟ ਰਸਤਾ ਬਣ ਜਾਵੇਗਾ।
ਟੈਸਟ ਕਿਵੇਂ ਚਲਾਇਆ ਗਿਆ
ਅਸੀਂ ਦੋ ਇਮੇਜ-ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਮਾਡਲਾਂ—MobileNetV2 ਅਤੇ EfficientNet-Lite4—ਦਾ ਬੈਂਚਮਾਰਕ ਕੀਤਾ, ਜੋ ਦੋਵੇਂ TensorFlow-Lite ਵਿੱਚ ਬਦਲੇ ਗਏ ਸਨ। ਟੈਸਟ Apple-silicon M2 Max ਚਿੱਪ 'ਤੇ ਚਲਾਏ ਗਏ ਸਨ। ਹਰੇਕ ਮਾਡਲ ਲਈ, ਅਸੀਂ ਕਈ ਇਟਰੇਸ਼ਨਾਂ (iterations) ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ ਫਾਰਵਰਡ ਪਾਸ ਦੀ ਲੇਟੈਂਸੀ (latency) ਨੂੰ ਮਾਪਿਆ ਅਤੇ ਫਰੇਮ-ਪਰ-ਸਕਿੰਟ (FPS) ਦੀ ਰਿਪੋਰਟ ਦਿੱਤੀ। ਅਸੀਂ WebGL backend 'ਤੇ TensorFlow.js ਦੇ ਨਾਲ ਉਹੀ ਮਾਡਲ ਚਲਾਏ ਅਤੇ ਹਰੇਕ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਕੋਲਡ-ਸਟਾਰਟ ਸਮੇਂ (cold-start time) ਨੂੰ ਰਿਕਾਰਡ ਕੀਤਾ।
ਨਤੀਜੇ: ਰਫ਼ਤਾਰ ਅਤੇ ਸ਼ੁਰੂਆਤ
MobileNetV2
- LiteRT.js (WebGPU): 0.41 ms ਲੇਟੈਂਸੀ → 2,439 FPS
- TensorFlow.js (WebGL): 10.82 ms ਲੇਟੈਂਸੀ → 92 FPS
EfficientNet-Lite4
- LiteRT.js (WebGPU): 0.62 ms ਲੇਟੈਂਸੀ → 1,623 FPS
- TensorFlow.js (WebGL): ਰਿਪੋਰਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ, ਪਰ MobileNetV2 ਪਹਿਲਾਂ ਹੀ >25× ਫਾਇਦਾ ਦਿਖਾ ਰਿਹਾ ਹੈ।
ਪਹਿਲੇ inference ਤੋਂ ਪਹਿਲਾਂ TensorFlow.js ਨੂੰ ਆਪਣੇ WebGL shaders ਕੰਪਾਈਲ ਕਰਨ ਲਈ ਲਗਭਗ 10 ਸੈਕਿੰਡ (10,014 ms) ਦੀ ਲੋੜ ਸੀ। LiteRT.js 4.3 ms ਵਿੱਚ ਤਿਆਰ ਸੀ, ਜਿਸ ਨਾਲ ਇੰਟਰਐਕਟਿਵ ਐਪਸ ਲਈ ਕੋਲਡ-ਸਟਾਰਟ ਦੀ ਸਮੱਸਿਆ ਲਗਭਗ ਖਤਮ ਹੋ ਗਈ।
ਜਦੋਂ ਅਸੀਂ ਮਾਡਲ ਦਾ ਆਕਾਰ ਪੰਜ ਗੁਣਾ ਵਧਾਇਆ, ਤਾਂ ਲੇਟੈਂਸੀ ਸਿਰਫ਼ 50% ਵਧੀ, ਜੋ ਇਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਕਿ GPU ਦੀ ਪੈਰਲਲਿਜ਼ਮ ਜ਼ਿਆਦਾਤਰ ਵਾਧੂ ਕੰਮ ਨੂੰ ਸੰਭਾਲ ਲੈਂਦੀ ਹੈ। ਇਸਦਾ ਨਤੀਜਾ ਇੱਕ ਅਜਿਹਾ ਪ੍ਰਦਰਸ਼ਨ ਹੈ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਸਰਵਰ ਰੇਂਡ-ਟ੍ਰਿਪਸ (server round-trips) ਤੋਂ ਬਿਨਾਂ ਰੀਅਲ-ਟਾਈਮ ਵੀਡੀਓ ਸਟ੍ਰੀਮਾਂ, AR overlays, ਜਾਂ ਵਿਜ਼ਨ ਮਾਡਲਾਂ ਦੀ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
ਅੰਕੜੇ ਕੀ ਛੁਪਾਉਂਦੇ ਹਨ
- Batching – ਜ਼ਿਆਦਾਤਰ TensorFlow-Lite ਮਾਡਲਾਂ ਵਿੱਚ batch dimension ਨੂੰ 1 'ਤੇ ਲਾਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਸਿੰਗਲ ਕਾਲ ਵਿੱਚ ਕਈ ਤਸਵੀਰਾਂ ਭੇਜਣ ਦੀ ਸਿੱਧੀ ਸਹੂਲਤ ਨਹੀਂ ਹੈ, ਜਿਸ ਕਾਰਨ ਡਿਵੈਲਪਰਾਂ ਨੂੰ Web Workers ਬਣਾਉਣੇ ਪੈਂਦੇ ਹਨ ਜਾਂ ਮੈਨੂਅਲ ਤਰੀਕੇ ਨਾਲ ਇਨਪੁੱਟਸ ਨੂੰ ਪਾਈਪਲਾਈਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
- Memory management – LiteRT.js GPU tensors ਨੂੰ ਆਪਣੇ ਆਪ garbage-collect ਨਹੀਂ ਕਰਦਾ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਆਪਣੇ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਹਰੇਕ tensor 'ਤੇ
.delete()ਕਾਲ ਕਰਨਾ ਪਵੇਗਾ, ਨਹੀਂ ਤਾਂ ਕੁਝ ਸੌ inferences ਤੋਂ ਬਾਅਦ GPU ਮੈਮੋਰੀ ਖਤਮ ਹੋਣ ਦਾ ਖਤਰਾ ਰਹਿੰਦਾ ਹੈ। - Hardware reach – WebGPU ਡੈਸਕਟਾਪ Chrome ਅਤੇ Firefox 'ਤੇ ਸਥਿਰ ਹੈ। ਮੋਬਾਈਲ ਬ੍ਰਾਊਜ਼ਰ—ਜਿਸ ਵਿੱਚ Android 'ਤੇ Chrome ਅਤੇ iOS 'ਤੇ Safari ਸ਼ਾਮਲ ਹਨ—ਇਸ API ਨੂੰ ਸਿਰਫ਼ ਪ੍ਰਯੋਗਿਕ ਫਲੈਗਸ (experimental flags) ਰਾਹੀਂ ਹੀ ਦਿਖਾਉਂਦੇ ਹਨ ਜਾਂ ਬਿਲਕੁਲ ਨਹੀਂ। ਉਹਨਾਂ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ WASM backend ਹੀ ਇੱਕੋ-ਇੱਕ ਵਿਸ਼ਵਵਿਆਪੀ ਰਸਤਾ ਹੈ, ਪਰ ਇਹ ਵੱਡੇ ਮਾਡਲਾਂ ਲਈ ਕਾਫ਼ੀ ਹੌਲੀ ਹੈ।
ਇਹਨਾਂ ਸੀਮਾਵਾਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਭਾਵੇਂ ਸ਼ੁੱਧ ਰਫ਼ਤਾਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ, ਪਰ ਇਸਨੂੰ ਹਾਸਲ ਕਰਨ ਲਈ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਕੋਸ਼ਿਸ਼
LiteRT.js ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ WebGPU ਵੈੱਬ-ਅਧਾਰਤ ਇਨਫਰੈਂਸ ਨੂੰ ਸਬ-ਮਿਲੀਸਕਿੰਡ ਰੇਂਜ ਵਿੱਚ ਲੈ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ ਕਿ ਡੈਸਕਟਾਪ GPUs 'ਤੇ TensorFlow.js ਦੀ ਗਤੀ ਨਾਲੋਂ 25 × ਤੋਂ ਵੱਧ ਦੀ ਰਫ਼ਤਾਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਤਕਨਾਲੋਜੀ ਅਜੇ ਵੀ ਵਿਕਸਿਤ ਹੋ ਰਹੀ ਹੈ, ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬੈਚਿੰਗ ਸੀਮਾਵਾਂ, ਮੈਨੂਅਲ ਮੈਮੋਰੀ ਕਲੀਨਅੱਪ, ਅਤੇ ਸੀਮਤ ਮੋਬਾਈਲ ਸਪੋਰਟ ਵਰਗੀਆਂ ਚੁਣੌਤੀਆਂ ਨਾਲ ਨਜਿੱਠਣਾ ਪਵੇਗਾ। ਡੈਸਕਟਾਪ-ਪਹਿਲ ਵਾਲੇ ਅਨੁਭਵਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਰੀਅਲ-ਟਾਈਮ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਇਹ ਨਵੀਂ ਲਾਇਬ੍ਰੇਰੀ ਅੱਗੇ ਵਧਣ ਲਈ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰਾਹ ਪੇਸ਼ ਕਰਦੀ ਹੈ; ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਪਹੁੰਚ ਲਈ, ਪੁਰਾਣੇ WebGL ਅਤੇ WASM backends ਅਜੇ ਵੀ ਜ਼ਰੂਰੀ ਹਨ।
