Mercury 2.5 LLM hits 770 tokens per second

The speed means absolutely nothing when it is finishing almost dead last when compared to the frontier AI companies.

• copperx · 9 hours ago

  Ah, the old "good, fast, or cheap; pick two" proves true once again.

  • downrightmike · 9 hours ago

    Give it a few months.

• glouwbug · 9 hours ago

  Some of us want fast food

• voiceeh · 8 hours ago

  Not if your use case needs speed. For one of my products I can't use an LLM that has a p99 of >700ms for TTFT.

  • hansvm · 8 hours ago

    If it could output 1k tokens per second but needed 4 seconds to produce the first batch of 4k, would that not be viable?

• timClicks · 7 hours ago

  It means something, because it an iterative workflow. If you're willing to burn tokens, it's possible for weaker models to implement tasks by incrementally improving drafts.

Pricing at $0.25 and $0.75 already puts its cost well above reasonably reputable inference providers for deepseek v4 flash or qwen 3.8-flash-next or similar class of open weight LLMs that fit in under 170GB of RAM, so I don't see the point. I think this is probably also stupider than laguna s 2.1 which can also be very cheap to serve.

• RussianCow · 7 hours ago

  The point is the speed.

  • _aavaa_ · 6 hours ago

    If the model provides me with bad results because it's dumb, I don't care how quickly it does it.

    • hermannj314 · 5 hours ago

      Is it possible to construct a control system where bad, fast and cheap can become good, fast, and cheap through repeated sampling and a strong spec/eval harness? I am trying to keep an open mind with AI, but I also have little understanding of control theory, trying to learn.

      • freakynit · 5 hours ago

        Smaller models seems to get stuck in "loops" when you try to "handle" them this way.

      • calgoo · 37 minutes ago

        You can, but you need to break the problem into much smaller tasks, then check those answers, and finally have a harness that handles all the context, task breakup, task definitions, and validations each round.

    • RussianCow · 3 hours ago

      But there are lots of use cases where a relatively "dumb" model is good enough.

If you care about speed Cerebras gpt-oss-120b is 1400tk/s and "just as smart" in ranking. I've used it on a few for fun projects and its decent but the speed is crazy to watch.

• ford · 7 hours ago

  Also kimi 2.6 at 1000tps (as of may), though when we reached out they had a >12 month waitlist and minimum 7-8 figure annual token spend. [0] https://www.cerebras.ai/blog/cerebras-kimi-k2-Enterprise

  • sharktheone · 7 hours ago

    yeah. K2.6 can run on insane speeds. So sad that they don't have K3 yet. But it can apparently also run 5.6 Sol

    • eli · 6 hours ago

      Yeah but at “call to discuss pricing” rates

  • walrus01 · 5 hours ago

    7-8 figures annual spend will buy a hell of a lot of capable local inference hardware you can own, though it won't be at the absurd token/s rate, you'll be able to run almost anything on it... And it'll still have a good residual resale value after 4 years the way things are going now.

    • podocarp · 1 hour ago

      Feel like you could spend 6 figures building out a team and the rest renting compute for a whole year, and get the team to create a local inference solution with that kind of budget…

• scosman · 7 hours ago

  Or better: Qwen 2.8 27b

  • RussianCow · 7 hours ago

    Unfortunately, the lack of an input cache discount makes it prohibitively expensive for most use cases that aren't one-shot prompts.

    • scosman · 4 hours ago

      well same applies to GPT OSS 120. Qwen is just the much smarter model of the 2 public options on Cerebras.

• LoganDark · 7 hours ago

  Please do not try to use gpt-oss-120b over Cerebras. It is broken, screws up tool calls most of the time, forgets to end thinking blocks and has all sorts of other issues. The speed is amazing but it is absolutely not worth it, especially at that quite incredible cost. Think: $5–10/minute levels of cost with a single agent, because Cerebras also offers no cache pricing for input tokens at all.

  • eli · 6 hours ago

    Which is wild because it does, in fact, do caching

    • fakwandi_priv · 2 hours ago

      > There is no additional fee for using prompt caching. Input tokens, whether served from the cache or processed fresh, are billed at the standard input token rate for the respective model. So what he’s saying is correct, there is no separate cache pricing, which by normal standards should be 10% of the cost, which can become exceedingly expensive for anything other than single turn. The way they are stating this is of course strange..

  • shard972 · 5 hours ago

    Yea i had some pretty meh results using gpt-oss-120b it in my evals where it should have benefited speed alot but it really under performed what i was expecting.

• conception · 5 hours ago

  It was better when they had gemma at 1k. Inco does DS flash at about 600. A few places will do K3 and GLM in the hundreds. Such a tiny model at that t/s is less impressive than it would have been four months ago.

  • physicallyIllfr · 4 hours ago

    Lighting my codebase on fire at the speed of light. Like microwaving the spaghetti. I genuinly only see these speeds being useful for customer service/transactional workflows. Of which much smaller models can do the job (but those dont make tons of money for companies like Cerebras that need to pay off massive amounts of debt). Nobody needs to code at 600 words per second. Using a 100tps model for an hour or so will leave you with 4-8hrs of code review and revision work.

    • sbierwagen · 2 hours ago

      Human code review? What is this, 2025? The modality today is write with one LLM, review by a different one, (important: two different model families will catch errors one series won't) then deploy right to production.

      • podocarp · 1 hour ago

        And if you tell the reviewer the author is a competitors model it becomes extra snarky and vigilant. Then give the review results to the author and tell it it's from the competition and it will also become slightly outraged.

    • calgoo · 42 minutes ago

      No you dont need to code at 600 w/s BUT at those speeds, you can start doing things like asking multiple different agents the same question and picking the best solution each time without noticing the lag.

    • RugnirViking · 20 minutes ago

      > Nobody needs to code at 600 words per second. I do. I used to use haiku for the speed. Now its just as slow as the rest. Speed is my #1 ranking of how good a model is

• verdverm · 3 hours ago

  if you want to feel the speed without the burn https://kamilstanuch.github.io/LLM-token-generation-simulato...

• kylehotchkiss · 3 hours ago

  I felt happy I could run it at 100tk/s on my new Mac Studio :')

I honestly think the diffusion LLM approach is a dead end It's telling that frontier labs like Google toyed around with it but didn't invest further even for their most speed and cost sensitive small models Still unclear for what, if any use cases this is pareto frontier

• LarsDu88 · 8 hours ago

  You can't think that a small startup versus Anthropic's training setup is anywhere near the same scale to make apples to apples comparisons. Not sure how the Chinese labs pull it off though using autoregressive models. The secret sauce is probably going to be in the training data. The main reason Google hasn't switched over to DiffusionGemma is because serving at larger batch sizes loses the speed gains you get from diffusion, and most of the primary use case is serving many users at once off a single device with a large batch size. If you were to move to on-device low latency... like say in a robot or something, then the story might be different...

• clhodapp · 7 hours ago

  Personally, I think it's more that text diffusion is not the ideal driver of an agentic work loop than that text diffusion is a total dead end. I am still hoping to see how it does on authoring and editing with further scaling and optimization. I think the push for AGI has put a bit too much focus on the idea of one general model doing everything.

• kennywinker · 6 hours ago

  DiffusionGemma was released alongside the other gemma-4 models just a few months ago, so clearly google hasn't abandoned the idea. K2-Horizon-7B has a diffusion and non-diffusion variant, and they claim the same level of intelligence from both models.

• vineyardmike · 6 hours ago

  From what I’ve heard, the issue is more that it’s harder to efficiently share the hardware across diffusion requests, so it’s more expensive to serve. It sounds like there might be opportunities for local models (not open weight, but actually locally run) to use diffusion for faster responses on weaker hardware that doesn’t need to be shared. But yea, it’s still a red-ish flag that big labs haven’t invested much in it. I could see Google/Apple getting value of this sort of local model, but maybe there’s enough research behind traditional models that it’s not worth the distraction at this point in time.

it's stupid fast!

• SwellJoe · 7 hours ago

  It's stupid and it's fast.

  • freakynit · 5 hours ago

    Couldn't have said it better.

    • verdverm · 3 hours ago

      but can it be said in fewer tokens than GGP commenter?

this feels like "we got the same benches as gpt-oss-120b but are also potentially slower while saying it is great"

> Mercury 2.5 is below average in intelligence, but well priced when comparing to other models of similar price. Well priced when compared to other models of similar price, eh? Are we allowed to call this slop, even if the output is not directly from an LLM?

• verdverm · 3 hours ago

  The LLMs learned it somewhere...

At some point the bottleneck becomes tool calling.. and as such, it's preferably if the model is co-hosted (in the same datacenter, at least) with your code repository and all other reference/context it needs (full documentation for most ecosystems, maybe even a copy of common crawl to minimize web fetch usage, etc)

I used this a few days ago and thought something must be wrong with how fast it was responding. "Mercury 2.5 is below average in intelligence, but well priced when comparing to other models of similar price." this is so funny. So when you have a stupid model that is fast - what do you use it for?

I have tried using Mercury 2.5 for a lot of my tasks.. but this model just isn't there. It seems to be on par with any 14B model at max. Even GPT-OSS-20B performs way better than this in my own attempts to use it. I really really wanted to use this because it offers incredible speeds and pricing combinations. But nop.. I still am not using it.. not even for basic tasks.

• nostrebored · 5 hours ago

  Try Celeris-magnus-1. We get similar speeds and it’s much closer to qwen 27B dense models.

  • freakynit · 4 hours ago

    Didn't knew about this. Thanks.. but, according artificialanalysis.ai, it's intelligence is just about like a 14B model (mistral 3 14b)

    • nostrebored · 2 hours ago

      depends on your use case I think. for small, transactional tasks it is quite strong and fast.

Cerebras is fast…?

• Retro_Dev · 4 hours ago

  Yep it's fast alright. I wonder how much faster Mercury would become if hosted on Cerebras.

Chat Jimmy clocks at 17K tokens per sec burning LLM into the Chip - https://chatjimmy.ai/ - Source: https://theashishmaurya.medium.com/taalas-the-startup-that-p...

• econ · 4 hours ago

  Would have made a nice local tool.

I'm still sad that we haven't seen a new Taalas style chip a la https://chatjimmy.ai/ . Smaller models are good enough now to make that insane burst of tokens so useful.

• winwang · 3 hours ago

  Pretty sure context is in SRAM, and then you have that as a blocker for tasks.

  • electroglyph · 13 minutes ago

    way less of a blocker these days due to sparse attention...

My 1k parameter RNN is faster