Readit News logoReadit News
icyfox commented on Mercury: Ultra-fast language models based on diffusion   arxiv.org/abs/2506.17298... · Posted by u/PaulHoule
chc4 · 2 months ago
Using the free playground link, and it is in fact extremely fast. The "diffusion mode" toggle is also pretty neat as a visualization, although I'm not sure how accurate it is - it renders as line noise and then refines, while in reality presumably those are tokens from an imprecise vector in some state space that then become more precise until it's only a definite word, right?
icyfox · 2 months ago
Some text diffusion models use continuous latent space but they historically haven't done that well. Most the ones we're seeing now typically are trained to predict actual token output that's fed forward into the next time series. The diffusion property comes from their ability to modify previous timesteps to converge on the final output.

I have an explanation about one of these recent architectures that seems similar to what Mercury is doing under the hood here: https://pierce.dev/notes/how-text-diffusion-works/

icyfox commented on Show HN: Iceaxe – A modern, fast ORM for Python and Postgres   github.com/piercefreeman/... · Posted by u/icyfox
odie5533 · 10 months ago
How does Iceaxe compare to SQLModel?
icyfox · 10 months ago
Definitely some similarities!

SQLModel is also based on Pydantic, so the schema definitions that you'll write will look very similar to Iceaxe. Internally however SQLModel is implemented as a wrapper over SQLAlchemy. This is beneficial for support of multiple different database backends (mysql+postgres+sqlite) and for its battle tested track record. But as a drawback it also inherits a lot of the SQLAlchemy baggage like async+sync incompatibility and some funkiness with passing through types.

Since Iceaxe just targets Postgres, it can simplify a lot of those assumptions. It's implemented as async-only, leverages the most recent additions to typehinting in Python 3.12, and bakes in migration support. Documentation can capture explicit best practices for targeting Postgres versus attempting to abstract across every database backend.

It's also a bit different philosophically. It encourages explicit sql when you need to write complex queries; we support programatic joins out-of-the-box, but for more complex SQL (common table expressions for one) I find an ORM can often overly abstract what your engine is actually doing and hide subtle bugs that make their way into production.

I've spent quite some time with SQLModel as part of my Mountaineer web framework. It's great - just targets a broader range of ORM goals. Philosophically I'm trying to keep Iceaxe lean, fast, and Postgres optimized.

u/icyfox

KarmaCake day1327April 6, 2021
About
pierce [at] freeman.vc
View Original