lelag

This is all fairly obvious, no?

At first, write clean code with functions and don’t obsess over call overhead. Once it works, profile, then optimize where it actually matters.

Premature optimization, etc.

Indeed. I've tried to run it locally this but couldn't get it running on my measly gaming-spec workstation.

It's seems you need lot's of ram and vram. Reading the issues on github[1], it does not seem many others have had success in using this effectively:

- someone with a 96 Gb VRAM RTX 6000 Pro had cuda oom issues

- someone somehow made it work on a RTX 4090 somehow, but RTF processing time was 12...

- someone with a RTX 5090 managed to use it, but with clips no longer than 20s

It seems utility of the model for hobbyist with consumer grade cards will be low.

[1] https://github.com/facebookresearch/sam-audio/issues/24

Miracle Max gave us a clear definition if I recall, you die when you are "all dead", as long as you are mostly dead, you are slightly alive...

I'll let myself out now.

In his last blog post, Sam Altman also revealed how much power the average chatgpt query uses, and it's in the same ballpark.

People are often curious about how much energy a ChatGPT query uses; the average query uses about 0.34 watt-hours, about what an oven would use in a little over one second, or a high-efficiency lightbulb would use in a couple of minutes. It also uses about 0.000085 gallons of water; roughly one fifteenth of a teaspoon.

https://blog.samaltman.com/the-gentle-singularity

Damn, I would not have guessed that Men In Black was actually a documentary...

Maybe they want to compile the Apollo Guidance Computer source code...

https://www.softwareheritage.org/wp-content/uploads/2019/07/...

The metabase "backend" is written in clojure.

The web frontend is written in TypeScript/React.

Interesting point about PC going digital-only as Nintendo is a fascinating counter-example.

While they offer digital downloads on the eShop, their pricing actively discourages it.

Case in point: I just bought my kid a new first-party Switch game. Physical copy on Amazon was ~25% cheaper than the identical digital version on Nintendo's own eShop. Even my 9-year-old noted how illogical it seems, the physical version requires manufacturing, shipping, retail markup, yet costs significantly less than the digital bits that have near-zero marginal cost.

It strongly suggests Nintendo wants the physical retail channel to thrive, or values the perceived permanence/resale value of cartridges.

This context makes the Switch 2 "gamekey" cartridges (physical auth token, digital download) fit their pattern of valuing a physical artifact and retail presence, even if the data delivery shifts.

If I understand it correctly, that's a valid concern but the way structured generation library like outlines[1] work is that they can generate multiple variants of the inference (which they call beam search).

One beam could be "This is a way to solv-". With no obvious "good" next token. Another beam could be "This way is solv-". With "ing" as the obvious next token.

It will select the best beam for the output.

[1] https://github.com/dottxt-ai/outlines

I can’t say for certain, but I’d guess that writing without the letter “e” is slightly more difficult in French than in English. For one, “e” is a bit more common in French (around 15% of all letters, versus about 12% in English). But more importantly, French grammar adds extra challenges—like gender agreement, where feminine forms often require an “e”, and the frequent use of articles like le and les, which become unusable.

That said, I think the most impressive achievement is the English translation of the French novel. Writing an original constrained novel is hard enough, but translating one means you can’t just steer the story wherever you like. You have to preserve the plot, tone, and themes of the original, all while respecting a completely different set of linguistic limitations. That’s a remarkable balancing act.

I was going to point that out.

What I will add is that constrained generation is supported by the major inference engine like llama.cpp, vllm and the likes, so what you are describing is actually trivial on locally hosted models, you just have to provide a regex that prevent them to use the letter 'e' in the output.

More like 2000 tsar bombas if your energy release calculation is correct.

OSS model do not have to be local models, and it's not just about privacy, imo.

DeepSeek R1 hosting is out of reach for most, but it being open is a game changer if you are a building a business that needs the SoTA capabilities of such a large model, not because you will necessarily host it yourself, but because you can't be locked out of using it.

If you build your business on top of OpenAI, and they decide they don't like you, they can shut you down. If you use an open model like R1, you always have the option to self host even if it can be costly, and not be at the mercy of a third party being able to just kill your business by shutting down your access to their service.

Aren't we already living in the Biff got rich timeline?

Thank for the explanation. I guess it makes some sense, considering many people with no nlp background are using those models now…

Yes, weird that they didn't use that term for this project.

If that's an issue, there's a workaround using structure generation to force it to output a </thiking> token after some threshold and force it to write the final answer.

It's a method used to control thinking token generation showcased in this paper: https://arxiv.org/abs/2501.19393

And where does the nuclear fuel come from? Russia.

Not true at all. Russia is producing 5% of the world Uranium, and they probably use quite a lot of that domestically given they produce 8% of all nuclear power in the world with their own plant.

Kazakhstan + Uzbekistan is 50% of the word production. Canada is second and will be happy to start selling to the EU. Namibia and Australia both produce twice as much as Russia.

Not to say that supply of natural Uranium is not a concern because you do depends of a small list of countries but we don't need to buy any from Russia.

Source:

https://en.wikipedia.org/wiki/List_of_countries_by_uranium_p...

https://en.wikipedia.org/wiki/Nuclear_power_by_country

The problem with the original Kinect (v1) is that good tracking software for it was never really written. Most application that support it, just use the original Microsoft SDK to do the motion tracking, and it's just not very good, the main issue is that it always assume that the tracked person is directly facing the camera, and is very bad at dealing with occlusion. The good thing about it, is that it ran in real-time on a potato.

In order to get a good result, someone would need to train a good model for HPE that could use the cloud point data directly, but it seems nobody cares about depth sensor anymore, most efforts are going to HPE from regular 2d video (like media pipe holistic model). And given the result you can get with media pipe, openpose and the likes, it's understandable nobody is bothering working with low resolution cloud point anymore for 3D HPE.

The only use-case I can think of for a Kinect v1 in 2025, would be robotics if you want a low latency low resolution cloud point for your robot control, but even there I think we are moving to big vision model capable of making sense of regular video feeds.

Saying this is similar to Moshi is like saying GPT2 is similar to GPT4. You can't have any sort of conversation longer than 30s with moshi before it goes banana. You can talk to this model for an hour and it remains completely coherent.

Oh, right. I misunderstood.

I'm happy to see you repaired your keyboard.

The SMPL-x body model, a standard in this academic field does model fingers https://smpl-x.is.tue.mpg.de/

The issue is that there are much less dataset available for it than for the simplier SMPL model.

Regarding fingers, you already have "dumb" models like https://github.com/google-deepmind/mujoco_mpc which can control finger mouvement to achieve specific task.

Look at this video to see it action: https://www.youtube.com/watch?v=2xVN-qY78P4&t=387s

Pretty cool stuff.

Some more thoughts about training a manipulation model: I would add that synthetic data might be key to making it happen.

One issue is that most video is not shot in first person, so it might make for a poor dataset for the agentic part assuming the robot has human like vision.

Still if you have a large data set of motion capture data with reasonably accurate finger mouvement, you could use a video diffusion model with a control net to get a realistic looking video of a specific motion in first person. Another way would be to use a model like dust3r to generate a geometric 3d scene from the initial video allowing to change the camera angle to match a first person view.

This could be used as the dataset for the agentic model.

Now, maybe human like vision is not even necessary, unlike human, there is nothing preventing your robot to see through external camera placed around the house. Hell, there's even a good chance, your robot's brain will live in a datacenter hundreds of mile away.

Really interesting model, I'm looking forward to play with it.

But what I want is a multimodal agent model capable of generating embeddings for a humanoid control model like Meta motivo[0] rather than directly outputting coordinates.

Meta motivo is still a toy model, trained on the SMPL skeleton, which lacks fingers which limits its capabilities beside having some fun with it. They could have used a more advanced based model, SMPL-X, which includes fingers, but there isn’t enough open motion data with precise finger motion to train a robust manipulation model anyway.

Most existing motion datasets come from academic motion capture setups, which are complex and not focused on manipulation tasks (and also pretty old). I believe this gap will be filled by improvements in 3D HPE from 2D video. With access to thousands of hours of video, we can build large-scale motion datasets covering a wide range of real-world interactions.

This will enable training the two components needed for dexterous humanoid robots: the agentic model that decides what actions to take and generates embeddings that can be read by a control model that accurately models hand and finger joint movement.

Given the rapid progress in the capabilities of SoTA 3D HPE from 2D video, and the vast amount of videos online (Youtube), I expect we will see humanoid robots with good manipulation capabilities it the not so distant future.

[0] https://github.com/facebookresearch/metamotivo

It's not exhaustive. For exemple, it's missing the Meta Motivo demo at https://metamotivo.metademolab.com/ (humanoid control model)

You are right, but that's not my point. The point is that it's difficult to scale in the cloud products that requires lots of AI workloads.

Here, home assistant is telling you: you can use your own infra (most people won't) or you can use our cloud.

It works because most likely the user base will be rather small and home assistant can get cloud resources as if it was infinite on that scale.

If their product was amazing, and suddenly millions of people wanted to buy the cloud version, they would have a big problem: cloud infrastructure is never infinite at scale. They would be limited by how much compute their cloud provider is able/willing to sell them, rather than how much of that small boxes they could sell, possibly loosing the opportunity to corner the market with a great product.

If you package everything, you don't have that problem (you only have the one to be able to make the product, which I agree is also not small). But in term of energy efficiency, it also does not have to be that bad: the apple silicon line has shown that you can have very efficient hardware with significant AI capabilities, if you design a SOC for that purpose, it can be energy efficient.

Maybe I'm wrong that the approach will get common, but the fact that scaling AI services to millions of users is hard stand.

It is, I think, a common feeling among Echo/Alexa users. Now that people are getting used to the amazing understanding capabilities of ChatGPT and the likes, it probably increases the frustration level because you get a hint of how good it could be.

I believe it boils down to two main issues:

- The narrow AI systems used for intent inference have not scaled with the product features.

- Amazon is stuck and can't significantly improve it using general AI due to costs.

The first point is that the speech-to-intent algorithms currently in production are quite basic, likely based on the state of the art from 2013. Initially, there were few features available, so the device was fairly effective at inferring what you wanted from a limited set of possibilities. Over time, Amazon introduced more and more features to choose from, but the devices didn't get any smarter. As a result, mismatches between actual intent and inferred intent became more common, giving the impression that the device is getting dumber. In truth, it’s probably getting somewhat smarter, but not enough to compensate for the increasing complexity over time.

The second point is that, clearly, it would be relatively straightforward to create a much smarter Alexa: simply delegate the intent detection to an LLM. However, Amazon can’t do that. By 2019, there were already over 100 million Alexa devices in circulation, and it’s reasonable to assume that number has at least doubled by now. These devices are likely sold at a low margin, and the service is free. If you start requiring GPUs to process millions of daily requests, you would need an enormous, costly infrastructure, which is probably impossible to justify financially—and perhaps even infeasible given the sheer scale of the product.

My prediction is that Amazon cannot save the product, and it will die a slow death. It will probably keep working for years but will likely be relegated by most users to a "dumb" device capable of little more than setting alarms, timers, and providing weather reports.

If you want Jarvis-like intelligence to control your home automation system, the vision of a local assistant using local AI on an efficient GPU, as presented by HA, is the one with the most chance of succeeding. Beyond the privacy benefits of processing everything locally, the primary reason this approach may become common is that it scales linearly with the installation.

If you had a cloud-based solution using Echo-like devices, the problem is that you’d need to scale your cloud infrastructure as you sell more devices. If the service is good, this could become a major challenge. In contrast, if you sell an expensive box with an integrated GPU that does everything locally, you deploy the infrastructure as you sell the product. This eliminates scaling issues and the risks of growing too fast.

Video footage from 2019: https://www.youtube.com/watch?v=VYErLcG6aCQ

I've noticed quite a lot of Prolog content lately. I don't know if it's just a case of the Baader–Meinhof phenomenon, but it looks to me that recent article[1] about Prolog being able to improve LLM reasoning abilities renewed some interest in the language.

[1] https://shchegrikovich.substack.com/p/use-prolog-to-improve-...