Is Jev a decoder (e.g., BERT) or is it some kind of encoder (e.g., GPT) that just happens to be trimmed down to only outputting a handful of tokens for the answers and their probability?
15,846 karma · joined March 11, 2013
Website: https://kay.is
Blog: https://fllstck.dev
GitHub: https://github.com/kay-is
Is Jev a decoder (e.g., BERT) or is it some kind of encoder (e.g., GPT) that just happens to be trimmed down to only outputting a handful of tokens for the answers and their probability?
However, it might have fewer restrictions than a BERT and/or is smarter (whatever that means).
Somehow I expected inference engines are generic LLM runtimes that can execute any weight.
So, to get this right.
Someone trains a model.
They release the weights and a reference implementation of the model architecture.
Then a provider has to host this model either by running inference via the reference implementation, an open source implementation, or build their own.
Does this mean, providers don't just differ in quantisation and configuration, but also in inference engine implementation?
I'm using it right now and it's noticeably faster.
I'd also say, it seems smarter, but I think that's because of some harness updates I installed. (I haven't used pi for almost a month)
I was hoping for a bit more, but it's still 100% faster for a very good price, so I won't complain.
I have a Samsung Fold 4. The front screen is too narrow and the folding screen doesn't open all the way anymore.
Not what I expected from a 1400€ phone.
https://www.geeky-gadgets.com/deepseek-v4-1-flash-review/
I hope some of those speed increases will make it to production.
It built this whole IaC plugin from scratch: https://github.com/fllstck/nebius-alchemy
"The Feathers widgets have migrated to BSN, Bevy's next-generation scene system. BSN is a better foundation for widgets than the old spawn-function approach: it reduces boilerplate, lets you compose widgets together, parameterize widgets with SceneComponent props, reference font/image assets, and register observers in the same declaration."
Yet, I wouldn't go so far as to say every novel is one. If you aren't an established author, publishers won't take on your manuscript if it doesn't hook them with the first chapter, better even with the first page.
That doesn't mean that a well written first chapter will hook everyone, though.
I would have taken him for mostly pro LLM.
Checking code is (relatively) easy, you can use static type checks, linters, and execute it to see if it's correct.
Fact checking is harder. A RAG can only check what's in the database, so you have to know what to know beforehand.
Whelp, as with all those aggregators, it was nice while it lasted.
While I'm not so sure about learning a language with content from fictional sources, that should at least make it more relevant for the learners.
And you can use it on podcasts too, where people talk normally.
The biggest hurdle is probably that users need to get hold of the media so they can use it as input.
I once built a Bomberman clone that had control issues.
The first iteration of the controls were clunky, because I only checked if a player was touching a block in the direction they wanted to move and if there was, I reset the position.
Move down, hit block, stop.
After a bit of experimenting I checked if a player was halfway behind or ahead of a block and added perpendicular motion after resetting the position. That way the player would glide around the blocks.
Move down, hit block, stop, move left or right until moved around the block.
That change alone made the game 100x more fun.
I love the freedom.
People were calling the emergency hotline because the wildfires 200km away got so big that their smoke engulfed the city.
LLMs can abstract pretty well. They write quality code for obscure frameworks no problem, as longs as you take the time to set up tight feedback loops.