riknos314

How much of that revenue is usage from hosting partners (AMZN, M$, etc) who have a vested interest in using Anthropic instead of open weights though?

Back when I was at Amazon they used Anthropic models almost exclusively. Not sure how much that's changed in the last year.

From their own inference framework docs: "A single cluster currently serves 155 trillion tokens per day, with overall revenue of US$38 per GPU-hour (at valley pricing)."

https://github.com/deepseek-ai/DeepInfer/blob/main/doc/infer...

So this implies they actually hit about double that during peak pricing.

Great question. Nobody knows.

The cool thing about models designed for cheaper inference is that post-training (which often requires inference as a part of the feedback loop) becomes cheaper as well, so almost certainly cheaper than models that are less optimized.

Deepseek prices their models based on a 10 month hardware payback period. They report ~$38 revenue/GPU-hour on V4.1-Flash clusters.

Inference is clearly profitable. The question is whether it's profitable enough to justify the training research costs.

> I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.

He's still quite correct. I generally see a machine as being "programmed in" whatever is tracked in source control. So as long as your git repo is tracking changes in Java, that's still programmed in Java, even if the Java was generated with the assistance of LLMs. I may consider the thesis of this article invalidated only when the majority of repos start tracking natural language rather than programming languages as the primary artifacts defining behavior of the software.

> And we should also ban user tracking for advertising purposes, obviously.

One of the biggest metrics businesses track is repeat purchases. They don't want to give up that info because it tells them if their product is good enough to retain customers.

So the token must have some means of connecting purchases for a user across time (at least per merchant) or businesses will never adopt.

My car doesn't require a dedicated team of engineers to start and has a trunk to hold groceries :P

The question isn't really if the speed is bad, it's what tradeoffs you need to make to realize it. The F1 car has a very narrow operating condition and so can make tradeoffs that are completely unreasonable for vehicles that need to do other things.

From what cloudflare is claiming, Tsrs gives me more speed without tradeoffs I care about, so why not have the free speed?

That strategy only works for model generations that are released with open weights. If Kimi K4 is proprietary, then China has the newer weights and the EU does not.

It's also worth noting that more post-training does not change the model architecture. No amount of post-training on deepseek v4-flash will ever make it as efficient as deepseek v4.1-flash because 4.1-flash uses a fundamentally different architecture. Being stuck on an older base model means you don't keep up with these architectural improvements that unlock significant gains in speed / efficiency.

> This is just higher performance.

More performance from the same hardware means better margins. Deepseek just gave every third-party inference provider a more efficient stack for free. They also get the whole provider community working with them to make inference even more efficient.

*on one set of private benchmarks

Artificial analysis has them benching similarly on intelligence, but with deepseek 4.1-flash having a decisive victory in time-to-first-output-token and end-to-end-response-time [1].

Combined these make the interactive experience of using deepseek 4.1-flash significantly more enjoyable than haiku IMO.

[1] https://artificialanalysis.ai/models/deepseek-v4-1-flash-101...

Both the free (seems limited to ~200k context) and metered variants in opencodego show the release date as 1788998400000 → 2026-09-10, which implies they're not the newer checkpoint

This strategy only works as long as China continues publishing weights. Domestic training capabilities are one way of mitigating that risk.

Good! The goal isn't preventing chatting, it's providing separation from "the algorithm" (a dopamine casino, where you lose attention instead of money)

> that allows us to compare their performance. Opus is considerably better.

In coding? Software architecture? Math? General knowledge?

The diversity of model use-cases is so broad that comments about "model x is better" without any context are largely useless

Initial impression is that the currency selection didn't work (changing between USD/EUR on the selector didn't change the currency being displayed in PLN)and I quickly lost interest due to lack of monetary context

LLM seems to have become synonymous with Generative Transformer architecture.

While this model may share much with GPT-style models on the encoder side, it clearly has a different decoder architecture. So is a high-parameter count language model an LLM even when it doesn't have a GPT-style decoder? The definitions are in flux.

Has LLM become so synonymous with Generative Transformer that other high-parameter count models that interpret language need a different name?

For all we know this might be a non-language-generative transformer e.g. a transformer where the decoder produces confidence scores rather than language. Please provide more likely architectures if you know them, I'm genuinely curious.

This is likely still an LLM (in the purest definition of a language model with relatively many parameters) since the inputs are natural language, just not a generative LLM as the output is something other than more language.

Public communications from government entities really should be legally required to be disseminated on public forums (ideally properly hosted on .gov domains for easy verification, with RSS feeds) Cross-posting on other platforms should be allowed (with backlink to the .gov), but the .gov should be authoritative.

At least in the US most places that sell gift cards require ID when purchased in cash

Halved would be a 50% percent reduction.

0.15/0.22 ≈ 0.68, meaning a roughly 32% reduction on inputs. The 50% reduction is only outputs and cached inputs.

The author misses the difference between cashflow and profit entirely.

Selling a car today gives Tesla the full profits of that hardware production today. Running that car as a robotaxi means that Tesla eats the costs of the hardware today in exchange for a larger total profit collected over several years.

So operating a fleet gives the company access to more long-term profits at the cost of decreasing the bank balance today (negative cash flow), where selling the cars lets the company fill the bank account right now (positive cash flow) at the cost of limiting long-term profitability.

The decision to prioritize immediate cash flow vs long term profits depends on the financial position and overall strategy of the company.

also seeing 404

I'm not sure if the website allows for diffs against arbitrary tree states, but if it does than the diff space is completely unbounded, and the ram demand is theoretically infinite.

The amount of memory required to cache all possible diffs (defined as an ordered pair of commits) would likely be in the exobytes. At current ram prices that's easily a trillion dollars of ram to run that cache lol. Git focuses on making diff calculations efficient largely because the space of possible diffs is very expensive to enumerate.

The following from Claude: """ A diff between two randomly chosen commits usually spans years of history, so it's not a few KB — the tree itself is ~1.5 GB of text, and a multi-year span rewrites a large slice of it. Call it 100–200 MB per pair on average: 8.5×10¹¹ pairs × ~2×10⁸ bytes ≈ 10²⁰ bytes, or ~150 exabytes """

For anyone interested in the differences between dynamo (the early internal-only KV store described in this paper) and DynamoDB (The AWS service), Marc Brooker has an excellent writeup https://brooker.co.za/blog/2025/08/15/dynamo-dynamodb-dsql.h...

I'm curious if this stems from the focus on token efficiency. My thinking is that in order to use fewer tokens the model must converge to a likely path faster, meaning it must be more confident in making assumptions quickly and not second-guessing them.

Time to market also matters a ton. If they can start shipping chips <1 month after the weights drop that's much more compelling than if it's a 6+ month development pipeline.

Kimi K3 is a 2.8T model that's available at about 1/4-1/3 the cost of Fable from multiple providers on openrouter. The math doesn't seem wildly off.