Show HN: ML Blocks – Deploy multimodal AI workflows without code • Hacker News Board

Re: Show HN: ML Blocks – Deploy multimodal AI workflows without code

#31

Post by soulofmischief » Fri, Feb 02, 2024, 1:29 AM UTC

starwaver wrote: post #3

I like the idea of node based image editing. It reminds me of when learning how to write shader code for games and GLSL was waaaay too over my head until I discovered node based shaders, and I didn't have to wrangle with coding and instead focusing experimenting with different nodes. However soon creating a "shader that works" was no longer an issue but how to create X effect using shaders was my next blocker, and lu…

I prototyped a system one year ago which created node-based, editable scene graphs in-browser with the help of an LLM-powered agent. It allowed the user to quickly construct complex 3D scenes.

It was some amazing tech with a ton of applications, but sadly leadership had other plans and pivoted to a highly derivative, slapped-together AI sex bot.

Re: Show HN: ML Blocks – Deploy multimodal AI workflows without code

#32

Post by neilxm » Fri, Feb 02, 2024, 4:55 AM UTC

moralestapia wrote: post #29

Hey, this is really cool! A small suggestion, I don't think ML is a memorable term for non-technical people. I would prob. try a different name.

Thanks! We'll ponder over this one :)

Re: Show HN: ML Blocks – Deploy multimodal AI workflows without code

#33

Post by neilxm » Fri, Feb 02, 2024, 4:59 AM UTC

sgrove wrote: post #30

Interesting! Always interesting to see the ideas in the air at the same time! https://linzumi.com/ Definitely think this sort of idea could become the "serverless" equivalent for ml-using apps. I'm curious what you think re: versioning, consumption from various client languages, observability/monitoring/queueing, etc.? Feels like it could grow into a meaningful platform.

Yes! That's where our heads are at as well. The reality with a lot of multimodal / image proc style code is that it's never truly serverless - image manipulation in node.js is tragically bad so you always end up needing python endpoints to do it.

Re: version / client languages etc - right now we don't have block versioning but it's definitely going to be required. As of now the blocks are each their own endpoint, by design. We're thinking about allowing people to share their own blocks and perhaps even outsource compute to endpoint providers, while we focus on the orchstration laters.

Better observability and monitoring is definitely on the docket as well. Especially because some of these tasks take a really long time - some times even going past the expiry window of the REST api. We'll be switching over to queued jobs and webhooks