ansk

That paper is great work. This qwenputer stuff is slop. The problem is that HN can't tell the difference.

This work, and the original qwenputer work it builds on, are both technically uninteresting slop. HN eats it up though.

This perspective -- that the burden of proof is on the experts to disprove the slop -- is exactly what I think is unsustainable.

I don't know enough about the specific models they're comparing against to say this definitively, but it looks to me like they're comparing their pre-trained models with others' post-trained models.

The metric upon which their 10x claim is based (bits-per-byte) is exactly the metric which is optimized during pre-training. Post-trained models are fine-tuned to optimize other metrics, which is known to be detrimental to performance on bits-per-byte evaluations. So bits-per-byte evaluations will always make a pre-trained model look favorable in comparison to a comparable model which has also undergone post-training.

Can someone confirm whether the models they are comparing against (DeepSeek V4, Kimi K2, and Nemotron 3 Ultra) have been post-trained?

I can see how LLMs may make compiler development seem futile when it comes to optimizing the local graph structure (ie kernel-sized chunks of the computation).

But optimizing the global structure -- things like defining the boundaries between kernels, the lifetimes of allocations (or when/how to reuse buffers), and scheduling/parallelizing operations -- seems inextricably tied to the type of traditional program analysis used by compilers.

Even tiling/layout decisions, which you mentioned can be optimized by hand or by an LLM in the context of a single kernel, must be optimized in the broader context of the computation to minimize copies/relayouts between kernels.

I think part of the problem is that massive models make the compiler problem much less interesting, since global program optimization reduces to local kernel-level optimization.

This kind of sounds like just giving up on making the compiler better.

I skimmed the doc and my impression is that your second listed interpretation -- DeepSeek is pausing investment because of a leak -- is the more correct one.

There's quite a bit of confidential information in the doc about the company and how it's positioning itself going forward to compete with US labs. I'd imagine they're not happy at all with this being leaked and are withholding investment as a punitive measure.

Not to mention the other interpretation seems illogical -- why would you pause fundraising if your perception was that you lacked resources compared to your competitors?

I've found breathing exercises to be effective for the duration of the exercise, but I'm more interested in the possibility of training myself to adjust my respiration patterns over sustained durations. Would it be beneficial -- or even possible at all -- to adjust my body's default/subconscious breathing patterns to match those mentioned in the article?

Tangentially related, are there any wearable devices that allow for high resolution respiration monitoring? I'm imagining some measurement of lung expansion over time (probably at least 10 Hz) so that I can quantify the deepness/shallowness of my breaths as well as the phase of inhalation/exhalation cycles.

Kind of a backwards take, both in your interpretation of this announcement and the company in general.

The point of this announcement is to draw attention to the fact that the currently hyped topic is what they have been working on since their inception. If anything, it gives off a Schmidhuber-esque 'actually it was me who invented that' vibe. But trying to retroactively claim credit for the hype is nowhere near the same as following the hype.

As for your impression that the company is more generally hype-chasing, I'm really not sure how you would come to that conclusion. At the time of their founding, chatbots were the hype on the product side and model scaling was the hype on the research side -- topics they have largely eschewed. They instead were founded with a focus on evolutionary and collective intelligence and have maintained a fairly cohesive research direction ever since.

I can assure you that a fully deterministic and equally effective claude is possible to build. And yes, that would mean identical prompts would yield 100% identical output 100% of the time. It would still make the occasional logical or factual error, but it would do so deterministically. Would this solve any of the problems with building reliable programs using LLMs?

I see what you're getting at, but determinism isn't the right word either. LLMs are fundamentally deterministic -- they are pure functions which output text as a function of the input text and the network parameters[1]. Depending on your views on free will, it could be effectively argued that humans are deterministic as well.

The concept you're touching on is the idea that LLMs (and humans) are functions which are inscrutable. Their behavior cannot be distilled into a series of logical steps that you can fit in your head, there are no invariants which neatly decompose their complexity into a few interpretable states, and the input and output spaces are unstructured, ambiguous, underspecified, and essentially infinite. This makes them just about impossible to reason about or compose using the same strategies and analysis we apply to traditional programs.

[1] Optionally, they can take in a source of entropy to add nondeterminism, but this is not essential. If LLM providers all fixed their prng seeds to a static value, hardly anyone would notice. I can't imagine there are many workflows which feed an LLM the exact same prompt multiple times and rely on the output having some statistical distribution. In fact, even if you wanted this you may just end up getting a cached response.

The guy writing a thumbnail pipeline isn't getting petabytes (exabytes?) of storage to cache all videos from the past week in their entirety. If this quantity of data is being stored, it's being stored deliberately and at significant cost.

The other explanations here don't explain the long delay between the start of the investigation and the release of the footage. Yes, storing customer data is what we'd expect from Google and yes, the FBI can coerce Google to provide this data for their investigations. But it does not take a week for Google to find a file on their servers.

My hunch is that Google initially tried to play dumb to avoid compliance, as to not reveal they do in fact retain customer data. They had a plausible excuse as well -- the owner had no subscription so they don't store the data -- and took a gamble that this explanation would suffice until the situation resolved itself. I suspect that authorities initially took Google's excuse at face value, since they parroted this explanation to the public as well. As pressure mounted on authorities to make some headway on the case, they likely formally exercised whatever legal mechanisms they have at their disposal to force Google's hand, and only then was the footage released.