Horacio

Karma: 3

Horacio 13 Jun 2026 10:35 UTC
1 point
0
on: Stacity: a Lock-In Risk Benchmark for Large Language Models
I’m curious about how this is supposed to work in practice.
Currently we are already in a world in which search algorithms, and indeed whole social networks, are openly pushed towards specific points of view. That lock-in is already happening / has already happened. Those people already create, use and publish their own LLM. MechaHitler already happened, and other slightly less obvious examples also exist.
OK, so now… what to do about it? And how does this benchmark help?

Horacio 12 Jun 2026 15:01 UTC
2 points
0
on: What is Lock-In?
For example, the QWERTY keyboard is commonplace despite being a suboptimal layout for typing in English.
QWERTY being suboptimal has not been actually proven. So any reasoning built on that kind of thinking is dubious.

Nice overview at https://janetakesonhistory.org/2021/10/14/battle-of-the-keys-why-do-we-have-qwerty/ . The money shot:
In 2009, an article in the American Economic Review gave Liebowitz and Margolis empirical support. Tanjim Hossain and John Morgan used experimental economics to determine how likely it is for market participants to continue with an inferior product over time. They found no such examples. Their conclusion:
“While the QWERTY effect is certainly an interesting theoretical possibility, the dearth of examples of the phenomenon, both in the field and now in the lab, leads us to conclude that the danger lies more in the minds of theorists than in the reality of the marketplace.”

Horacio 20 May 2026 12:29 UTC
2 points
0
in reply to: Farhan’s comment on: The case for fine-grained tracking of compute for AI
I meant that there’s a large fraction of the capacity that is up for the taking by a sophisticated actor. E.g., see the PipeFill paper.
In that paper, that actor is the original operator optimizing their workloads. But a different, undeclared workload could be injected to take advantage of the unused hardware: from cryptomining, to training or inference.
I hesitate to suggest scenarios, but I’d imagine that a rogue AI’s first need would be to find hardware to run on. One would think that available GPUs/TPUs/etc aren’t easy to find; but turns out that there’s ~50% of them waiting to be used, and already collocated with the AI!, if only it manages to deal with the complexities.

Horacio 18 May 2026 13:22 UTC
2 points
0
on: The case for fine-grained tracking of compute for AI
Interesting writeup.
I’d suggest that there is another concerning reason why we need to track utilization, not only capacity; you touched on it but I think could be elaborated (and I’m starting to look into it myself): well-optimized workloads using at best 50% of the hardware capacity means that there’s at least another 50% that could be brought online without being reported. I wonder if that 50% could even end up being used by rogue workloads.