Anthropic is incredibly good at avoiding all the useless AI risks, while not doing anything serious about the real risks (that is: uncontrolled growth). I'm as pro-AI as I think that eventually it will remove suffering from humans, and will allow us to prosper more and help us with tons of problems we created. However the problem is not job loss or minors using AI (minors are fucked because of cell phones and social networks), the problem is avoiding extinction. For this position I was accused of AI psychosis multiple times, but I'm in good company (Hinton, for instance), so I bet some comment that trivializes this issue will surely reply to this one, but at this point it is important to see what everyone really believes. Anthropic only touches the surface of AI security, consistently.
That's perfectly wrong. Since strong coding AI, people venture into huge rewrites and other big changes that automatically make sense but otherwise would not.
Yeah it's a bizarre claim. Even better, I've literally taken some of the crappy experimental projects from the pre-Opus 4.6 era, and turned them into real software as models have become smarter.
I would say it's a mixed bag. On the one hand, yes, you can experiment with big changes much more easily, but on the other hand, you can have cruft build up in a big way if you're not actively looking for it and trying to cut it back.
In Debian, often the barrier to change is one or two people actively disagreeing with a change who are in a position to block it through their own action or inaction, so just being able to do more work on the change yourself is not necessarily going to make it easier to change things.
Sol for low level programming is consistently better, can work alone for more time, and is faster. If you think Fable is so superior, you need to work with Sol ways more.
This is simply not true, even if it is commonly repeated among the folks that usually don't really write. Like how reading every source code that comes handy will not turn yourself into a great programmer, to be a good writer you need to: 1. Read selected books, and re-read good books more often then reading new stuff, to understand why they are good. 2. Read, from time to time, some bad book, and understand why it is bad. 3. And obviously you need to write a lot to become good at writing. And writing, in order to improve, is writing remembering, at the same time, the vibrations of the good authors you loved, and especially making the act of choosing of every word you put in the blank page, one after the other.
So you feel that reading being necessary to write well is not true, yet the first 2 points of advice include directions to read, to re-read, to understand what you read, and then to read more. And in your last point, to write while remembering what you read.
Are you sure you actually disagree with the article?
Yes. The article says that you need to read a lot to write well. You actually need to write a lot, and to read carefully, high quality, and potentially low quantity too (to use more time to write).
H3 is quite uncensored, but was not trained on p0rn, so it has no anatomy clues needed to generate that kind of stuff. For softer adult content it is reported to be fine on Reddit.
Other than for pure t2v usage you probably don't need a LoRA for much, I have seen evidence that it is knowledgeable enough that it can handle a fair amount of anatomy looking and behaving reasonably with just relevant cues in control (for the fl2va model) or reference (for the r2va model) images.
And the r2va model can also use video input for motion reference.
This implementation is much faster on my M5 Max, like a few minutes for the same video, but on an M5 Max with 128GB, didn't test on M5 Pro. About memory, could be executed on 64GB with a few changes.
My understanding is that that tends to be more critical with LLMs than image/video gen models, which are relatively more compute vs. memory transfer intensive than LLMs
Performance might still end up being bounded by data transfer speed if SSD streaming is heavily used to make up for limited RAM. By comparison, it doesn't take many parallel-batched sessions to make LLM decode compute-bound on typical hardware (hence seeing very limited gains from even wider batching), but this just doesn't apply when streaming weights from disk, the setting is completely different.
In the AMA Minimax said that H3 could support sparse attention, that would be a huge speedup! I wonder if there are any news on that. H3 is very cool. EDIT: testing a --sparse-attention optional mode based on what they said in the Reddit post.
It's an excellent metric, the amount of applications not viable now due to cost/latency/throughput is vastly bigger than the amount of current use cases. Even current ones do benefit, e.g. it's a great executor subagent.
As an end consumer, I don't care about the number of active parameters. I really do care only about the tracked metric (how well does it do the job, and how much does it cost... ideally also with time included, but that wouldn't fit on a 2D chart)
Chinese labs are the proof that there is no need of big names, but of the right mindset and agility. It's those last things that Google truly misses, but now they are missing for a long time, and outside the AI divisions too, in almost every department of the company.
reply