@fabrice it's still like 5-10 exabytes of extra bandwidth, and it's not going to be diff-friendly. They developed a new dedicated binary patcher to shrink Chrome updates (Zucchini) fairly recently so it can't be too cheap for them.
Post
Replies:
9
@gabrielesvelto The cost per bit is an invented metric though, isn't it? The cost to Google is in the hardware, which is already spent. Unless they've got caps somewhere that they need to work around, the cost for G to send 4GB vs sending nothing is roughly the same.
I'm no expert, of course...there is technically an upper limit to how much they could send, but I think it's unlikely (with their infrastructure) that they would reach it.
And, with billions bordering trillions of dollars to sink into any given endeavor, it will be some time before they feel the pinch.
As usual, it's the end users that will get screwed, especially if they're on metered connections.
@gabrielesvelto it's also curious that a 4GB model that can run on consumer hardware is useful enough to force onto every user of Chrome, and somehow the AI companies expect everyone to pay them for these services.
@gundersen indeed. But there is nothing rational about this market. It's all C-suite FOMO, vibes, smoke and mirrors.
@gabrielesvelto I think you are absolutely correct!
@gabrielesvelto This download is going to happen every time they update the blob isn't it?
@pwloftus yes. It's basically a bunch of sparse matrixes, that get recomputed every time you re-train the model. It's very unlikely that it will be amenable to binary patching or incremental updates.
@gabrielesvelto I bet it's actually cheap for Google. They have network caches (or used to at least for YT) very close to the ISPs, and this kind of payload is very cache friendly.
