[–] 1 point 4 months ago

Anthropomorphising LLMs by saying they think and saying an LLM works in a similar way to the human brain shows how much you know about "AI"

This is just tech oligarch propaganda designed to sell stocks and make it seem like "AGI" is possible via LLMs which it is not.

  • source
  • parent
  • context
  • [–] -4 points 4 months ago* (1 child)

    There is no even agreed upon definition for what "thinking" means. Parroting these anti-AI one-liners isn't productive and doesn't make you look smart.

    LLMs and human brains are both systems capable of processing information. Most reasonable people would count that as "thinking" in everyday conversation.

  • source
  • parent
  • context
  • [–] 4 points 4 months ago

    Usually when you develop something...a product or a service...the outcome is on the board from the beginning. The development process is figuring out how to get from "here" to "there". But "there" is the entire point.

    When you end up somewhere unexpected, it's because you didn't have a clear objective when you started. Or, that outcome simply wasn't possible to begin with.

  • source
  • [–] 4 points 4 months ago*

    make decisions based on reality

    "reality" in the sense that normal people think of it (actual, real reality) doesn't matter to rich people. the only thing that matters is convincing people that their reality isn't real, and that the fantasy bullshit not-reality that the owner class is trying to force-feed everyone is real.

    you see this everywhere you look:

    covid is a hoax
    climate change is a hoax
    AI is good and useful and the best thing possible for the working class
    the economy is doing great

    it goes on and on. but why? MONEY, same reason they do everything they do. it seems like it should be more complicated than that, but it isn't. it's for the money. it doesn't matter that they already have most of it. they want ALL of it

  • source
  • parent
  • context
  • [–] 7 points 4 months ago (1 child)

    What is there to fix? You can't defeat these conversational exploits because this is what LLMs are. They're statistical word predictors, they must, by their design parameters, be able to accommodate anything the user says because that's how conversations work. Eventually, no matter the prompt fixing you do, the user will eventually be able to storytell their way into getting the bot to do what they want.

  • source
  • parent
  • context
  • [–] 3 points 4 months ago (2 children)

    This sounds really bad for companies that have their repos on GitHub?

    They should probably fix that before they get hit with lawsuits after a large scale leak of proprietary code.

  • source
  • Only minor performance degradation with compression, but does the compression also mean the MOE model can run on a GPU with less VRAM? E.g., I don't think I can run GLM 5.2 on my W7900 (48G) even though the experts only take 40G, but would this compression allow it to run?

  • source
  • [–] 2 points 4 months ago

    The paper link above 404s but I think it should be this: https://arxiv.org/abs/2607.05147

    tl;dr DSpark improves the efficiency speculative decoding as it's able to verify longer draft sequences by accounting for inter-token dependencies.

    Speculative decoding accelerates Large Language Model (LLM) inference by decoupling draft generation from target verification. While recent parallel drafters efficiently propose long token sequences in a single forward pass, they suffer from rapid acceptance decay due to a lack of inter-token dependencies. Furthermore, indiscriminately verifying these extended blocks wastes critical batch capacity on tokens with high rejection risks, severely degrading throughput in high-concurrency serving systems. We introduce DSpark, a speculative decoding framework that unifies high-throughput parallel generation with adaptive, load-aware verification. To maintain draft quality, DSpark utilizes a semi-autoregressive architecture, coupling a parallel backbone with a lightweight sequential module, to introduce intra-block dependency modeling and mitigate suffix decay. To optimize system efficiency, DSpark employs confidence-scheduled verification, dynamically tailoring the verification length for each request based on estimated prefix survival probabilities and engine-specific throughput profiles. On offline benchmarks across diverse domains, DSpark substantially improves the accepted length over state-of-the-art autoregressive and parallel drafters. When deployed within the DeepSeek-V4 serving system under live user traffic, DSpark successfully mitigates verification waste. Compared to the established production baseline (MTP-1), DSpark accelerates per-user generation speeds by 60 to 85 percent at matched throughput levels. More importantly, by preventing severe throughput degradation under strict interactivity constraints, it enables performance tiers that were previously unattainable, shifting the Pareto frontier of our serving system

  • source
  • parent
  • context
  • view more: ‹ prev next ›