332451b

I assume this is idealized somehow, given how close it is to DeepInfer numbers at 100% utilization. My point was more that there is seemingly a lot of margin to absorb underutilization, outages and other costs.

Yes, I would not be shocked either.

Sonnet 5.5 is 16x more expensive at $10 per million output tokens. Kimi K3.1 is also $10 per million output tokens, and its number of active parameters is only 6.5x larger than V4.1 Flash (104B compared to 16B). These things are not directly comparable of course, but just to give an idea.

Even if inference of those models needs 16x, 32x, or 48x the number of GPUs compared to V4.1 Flash, still seems like potentially great revenue per GPU.

DeepSeek claims $38 of revenue per GPU, per hour for Flash V4. That is $332,880 per GPU, per year. This matches their DeepInfer numbers: 25,600 output tokens/s per GPU sold at $0.60 per million -> $55 minus some other overhead to arrive at $38.

For the bigger Anthropic and OpenAI models (and associated higher prices) there are many unknown factors. But presumably they also work hard on optimizations, and it's not so crazy to think they had or still have a lot of wiggle room to adjust prices.

"More tool work per model turn" could reduce the number of cache reads (or even cache misses) and associated cost?

For me it's hard to imagine not starting on the second PR after submitting the first one, regardless of AI or stacked PRs. For focused work I find it important to avoid context switching, stay in the zone and keep everything in my head. Wasted work in comparison feels less significant to me.

If review is fast I'd be switching back and forth between tasks throughout the day. If review is slow I might end up implementing a feature over the course of two weeks rather than two days. With reviewers in different time zones, limited time or doing their own focused work, it adds a lot of latency going back and forth for every PR rather than iterating on a stack of PRs.

Personally I find the biggest benefit is that it lets both the author and reviewers work at the pace that works for them, with reduced context switching and latency.

I'm curious how you got the energy consumption for 8 hours of use.

I would imagine there's a huge spread there too. Depending on hardware, size of the model, requests being batched and queued rather than occupying a whole GPU or TPU, or if you are running an agent loop for 8 hours straight or spend most of the time reviewing results.

I think initiatives for forge federation are trying to do too much. When running a forge for a project, I'd don't want to be dealing with spam or large amounts of data from other instances. And people should be able to report bugs and upload attachments, without having to give permission to share those with other instances.

A good system to download and migrate issues and pull requests is important, but that doesn't require federation.

I would love to see a smaller scoped federation of:

  - Forks across instances, including for the purpose of PRs (Git)
  - Activity feeds and notifications (Activity or ATproto)
  - Authentication and some user settings (OAuth)

Yes, a big problem is indeed API documentation and making it easier to follow best practices.

Regarding angles, users want to see degrees in the UI, but the python functions like math.sin and math.cos and basically any other graphics code you find uses radians. Whatever solution is chosen is always going to make someone unhappy.

Blender 2.5 has changed the UI significantly from the original commercial version, and most comments I read about it say that it has improved significantly. Blender the open source project has changed and grown so much bigger than Blender the commercial product that they are totally different.

Regarding hotkeys, there were some major changes for 2.5 along with other UI changes, but after that the default have barely changed, just additions and minor changes when the underlying features change.

Making hotkeys remappable was in no way a solution to that "problem", it's a standard feature in other 3D software that a lot of users requested, especially those who wanted to make the hotkeys compatible with Maya and 3ds Max.

The mouse focus issue is more related to missing APIs. If you call operators (tools) from Python they do indeed depend on context, just like they would if you use them from a toolbar, menu or shortcut key. These are not intended to be used for scripting really, but they are available and sometimes the only way to do things because there is no equivalent API function available.

I agree it's possible to do better than forward path tracing, but a big part of why nearly everyone switched to it was that it significantly reduces artist time, is a lot less painful and requires fewer hacks than the methods used before it.

The state of the art keeps improving but I've never heard any call the switch to forward path tracing a painful disaster, quite the opposite.

Just one nitpick, Arnold supports the same BSSRDF profiles and has been used for realistic skin rendering in movies. The gaussian profile is actually suitable for rendering realistic skin, by using a combination of multiple gaussians you can very accurately match measured human skin profiles.