> but where's the outcome dataset justifying this? how did they get that probability? what was the specific methodology of the tests? what variables did they account for?
Okay then, what's the answer? You apparently know how to interpret benchmark results produced by a model that shows a very high degree of assessment awareness and a high degree of deception.
So how are you seeing through all of that to get to The Truth that you see so clearly?
Just a hunch, but it might be because of the 51B parameter n-gram embedding. At 125B, you'd expect ~16gigs for a 1-bit quant. Add 51gigs for the n-grams and you're not far off the actual size.
If that's true, it'd scale linearly with number of bits in the quant with an offset of about 51gigs. So Q4 should be a bit bigger than 82gigs, I'd guess in the 90s (as opposed to a ~280gig q4 if the whole 70gigs of the 1-bit quant scaled linearly).
Sorta, but you're off by one layer. You can store the 18B in VRAM and stream the rest from RAM. There's still a performance hit relative to storing it all in VRAM, but it's tolerable.
Generally, for local consumer use, these large MOE models are best for unified RAM systems like DGX Spark or Mac Studio.
Public chargers =/= DC fast chargers (like Tesla superchargers).
I've already seen level 2 chargers that drop down from light posts in my city. Roll those out to every light post near apartment buildings and throw in some curb-side stalls if you need more capacity. Most people won't need to charge every night with 200/300mi+ range, so you won't need a 1:1 mapping of chargers to cars. This way, people charge passively overnight at stations that are cheaper to build than DC fast chargers.
Apparently LED can use less than 100W, and before LEDs streetlights would use 250-400W . The really bright sodium ones were 1000W, but those probably weren't over your neighborhood sidewalk.
Totally agree. I loved how it just showed the difference between a cop going through the motions, and these 2 guys show up months later and solve the thing in the span of 5 mins. "Real police"
Not directly related, but it still enrages me to this day that HBO allowed the two idiots who shall not be named to butcher Game of Thrones. It went from one of the biggest things in popular culture to basically nothing over the span of a few weeks.
As someone who is (Probably a bit more than) a junior dev with no formal education or experience in a team, do you have any suggestions to write better code?
I feel like my code would be considered bad, but I have no idea what good or bad code looks like. Does anyone have some examples and comparisons between good and bad code?
Really depends on the language and paradigm you're using, but the general aim for writing good code is to aim for loose coupling, high cohesion, don't repeat yourself, the single responsibility principle, and the Open/Closed principle (and several other philosophies) in order to maximize code re-usability and reduce maintenance effort.
You should aim to use whatever features your language provides to attempt to enforce the above, by information hiding, encapsulation, avoiding global mutable state as much as possible, and using design patterns to achieve a good balance.
You could give two similarly experienced programmers a fairly trivial problem and they might come up with wildly different solutions, because the best solution is a myth, but we know the wrong solution if we see it (that comes from the experience of making the same mistakes.)
If you give details on the language(s) you're using I may be able to point you to some literature on good design.
It's just high school statistics: https://en.wikipedia.org/wiki/Confidence_interval
It's not a probability. It's essentially an assertion that if the test were run 100 times, the result would be within the interval 95 times.
reply