They did, but it was not well-received. Perhaps they want to try something different.

    > those things are not deterministic

Determinism was an explicit goal of DeepSeek-V4. From their paper: https://arxiv.org/html/2606.19348v1#S3.SS3

    > we implement end-to-end, bitwise batch-invariant, and deterministic kernels with minimal performance overhead

Of course, providers may not implement deterministic inference for various reasons, but it is possible.

Most people are not even referring to CUDA batching nuances.

They think that sampling is an inherent part of Transformers.

Even on this site, it is regurgitated with confidence.

It is easier to trust what you can understand.

Is there any cryptocurrency that uses AES?

I hate the word crypto, very ambiguous. In my professional life it almost always refers to cryptography.

Not necessarily. These days, SSDs can go up to multiple millions of random reads per second. TLS termination (or self-inflicted software bottlenecks) will become an issue much earlier.

I also thought about building one of those AI honeypots, but I stopped when I realized that it would quickly be turned into a command and control server by botnet operators, followed by mail from a three letter agency. Is there any way to avoid this?

Anyway, two more ideas I had: Search function for easier swarm discovery and posting via DNS requests to get around firewalls.

Only 200s if a query parameter value is the solution to a question encoded on the rest of the route, and has to be a question listed in the index, and can respond with 200 only one time per correct answer.

> Is there any way to avoid this?

Be a three letter agency

It would interesting to leave a trail of prompts to try to get them do things for you

> Is there any way to avoid this?

Don't set it up.

Hide your email address.

I scrolled through https://simonwillison.net/tags/pelican-riding-a-bicycle/ but did not see any image where the spokes were correct. For a moment, I thought that the text-to-image model might have gotten it right, but on closer look, the spokes fork https://static.simonwillison.net/static/2026/why-are-you-lik... But I enjoyed the image anyway.

MiMo-V2.5-Pro-UltraSpeed gets pretty close with over 1000 TPS on 8x B200. It has 1.02T total parameters and 42B active, compared to 27B total/active for Qwen3.8-27B. Also, B300 are out now. I think 1500 TPS for Qwen3.8-27B should be doable.

That model uses a lot of tricks to achieve 1000 t/s. I would not use raw parameter counts alone for such comparisons, in general.

I was wondering whether this was any good for programming, but it is too fast for its own good. There is a limit of 450,000 tokens per minute. I hit this limit in about 90 seconds and burned through $1.10 while doing so. This is because cached tokens count towards the token limit.

For comparison, I ran the same task with DeepSeek-V4-Flash, which finished in 172 seconds and cost $0.024 with a final context window size of 55217 tokens, while Qwen3.8-27B was not even close to being done with a 64178 context window.

This is a very efficient way to burn your money, but I would not recommend it for programming.

On the positive side, I got a $5 signup bonus, so it wasn't my own money.

The point of speed is to increase throughput. What the point of all this speed, if overall throughput is still so low?

This doesn't work for my use case at all (code generation).

These bursts of speed might work well for workflows that need bursts of quick decisions, followed by silence. But these workflows have needed provable determinism to som extent, so I haven't been using llms for those use cases. And I don't see myself using llms for them in the future too.

Might be usable for short-context utility workloads? Generate the title of your chat session based on the first three messages at the speed of light

Throughput is useful if you want to generate a lot of transcripts for RL. It's for making Qwen better, not for actually using Qwen.

Reminiscent of race to sleep: not suitable for sustained workloads, but for bursts ones it’s a good approach.

Without prompt caching this becomes more expensive than fable 5.1 after turn 50, assuming you start with 40k tokens and add 2k per turn.

> There is a limit of 450,000 tokens per minute. I hit this limit in about 90 seconds

I'm confused. If it's 1500t/s, isn't that only 90k per minute? How do you hit a 450k/minute limit?

Cached tokens count towards the limit as well. For example, if your context window is 50,000 tokens, it takes 9 requests to reach that limit without generating a single token.

Cached tokens counting toward the limit is ridiculous.

then it's basically useless lol, wtf, this has to be a defect

It's PR:

https://news.ycombinator.com/item?id=49556302

Could this also be coming from the problem that Qwen3.8-27B's default mode being "extra-high reasoning level"?

To get a good coding agentic system you need to use big context (Specs and conversation context can't be condensed every minute), so you need to use prefix caching, and the price for the hit cache tokens can't be the same that miss cache or the final price could be insane.

I don’t think I understand. Why would faster token generation burn more tokens? The LLM should not be generating anything in between tool calls so the only difference should be that the human waits less between turns.

Qwen 3.8 on xhigh defaulr needs 128k context minimum or you'll spend most of your time compacting context.

Also make sure you use the instruct temperatures/etc for implementation.

You can query polars data frames with SQL: https://docs.pola.rs/api/python/stable/reference/expressions...

Unfortunately, polars does not support parameterized queries, so the risk of SQL injection is extremely high.