You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* [add] decoupled scriptrun command parsing from runtime scriptrun.
* [add] split positive/negative tests on pytorch scriptrun.
* [add] refactor AI.DAGRUN_RO and AI.DAGRUN to use the same code base (with read/write modes)
* [add] added positive and negative tests for dagrun with scriptrun
* [add] updated documentation to reflect scriptrun support on dagrun
* [add] added example enqueuing multiple SCRIPTRUN and MODELRUN commands within a DAG
A common pattern is enqueuing multiple SCRIPTRUN and MODELRUN commands within a DAG. The following example uses ResNet-50,to classify images into 1000 object categories. Given that our input tensor contains each color represented as a 8-bit integer and that neural networks usually work with floating-point tensors as their input we need to cast a tensor to floating-point and normalize the values of the pixels - for that we will use `pre_process_3ch` function.
581
+
582
+
To optimize the classification process we can use a post process script to return only the category position with the maximum classification - for that we will use `post_process` script. Using the DAG capabilities we've removed the necessity of storing the intermediate tensors in the keyspace. You can even run the entire process without storing the output tensor, as follows:
As visible on the array reply, the label position with higher classification was 111.
599
+
600
+
By combining DAG with multiple SCRIPTRUN and MODELRUN commands we've substantially removed the overall required bandwith and network RX ( we're now returning a tensor with 1000 times less elements per classification ).
601
+
602
+
603
+
579
604
!!! warning "Intermediate memory overhead"
580
605
The execution of models and scripts within the DAG may generate intermediate tensors that are not allocated by the Redis allocator, but by whatever allocator is used in the backends (which may act on main memory or GPU memory, depending on the device), thus not being limited by `maxmemory` configuration settings of Redis.
0 commit comments