Ulfgardleo t1_iuqhizr wrote
Reply to comment by bernhard-lehner in [R] Is there any work being done on reduction of training weight vector size but not reducing computational overhead (eg pruning)? by Moose_a_Lini
you might have misunderstood the message. OP asked if there is work on reducing the number of weights without compromising network strength as it is not compute that is the bottleneck but transmitting the object.
ReginaldIII t1_iurmviz wrote
This is just describing pruning though, the whole purpose of better pruning methods is reduce size without compromising performance on the intended task.
If you are embedding the weights of a model in an FPGA then the size of the FPGA is your bottleneck, it's unlikely to be your bandwidth talking to the ground because FPGA's just aren't that big relatively speaking.
Yes ground comms is a factor, but realistically A. How often are you going to be flashing new models onto your orbital systems relative to B. How much inference are you going to be doing with any one given model, and C. How big is the amount of data you'll then need to beam back down to collect those inferences.
Is the upload of the model weights really the dominant factor here?
By all means, strive to make the model as small as possible. But there's nothing special about the edge device being in orbit compared to it being on earth but hard to access.
bernhard-lehner t1_iuv03xs wrote
These are exactly the questions one needs to ask before even starting. I have seen it numerous times that people are working on something that might be interesting, but utterly useless at the end of the day.
Ulfgardleo t1_iurwhof wrote
hi, you are aware i am not the OP?
ReginaldIII t1_iurx61x wrote
Yes. You stated what OP had meant, and I responded to you to say that what you (both) were describing was just pruning in general.
bernhard-lehner t1_iuqkh9g wrote
"not reducing computational overhead" is not the same as not reducing performance
Viewing a single comment thread. View all comments