Abacus.ai:

We recently released Smaug-72B-v0.1 which has taken first place on the Open LLM Leaderboard by HuggingFace. It is the first open-source model to have an average score more than 80.

  • @simple@lemm.ee
    link
    fedilink
    English
    415 months ago

    I’m afraid to even ask for the minimum specs on this thing, open source models have gotten so big lately

    • TheChurn
      link
      fedilink
      445 months ago

      Every billion parameters needs about 2 GB of VRAM - if using bfloat16 representation. 16 bits per parameter, 8 bits per byte -> 2 bytes per parameter.

      1 billion parameters ~ 2 Billion bytes ~ 2 GB.

      From the name, this model has 72 Billion parameters, so ~144 GB of VRAM

            • @Rai@lemmy.dbzer0.com
              cake
              link
              fedilink
              English
              45 months ago

              My 83 was ganked by some kid I knew so my folks bought me a silver. He denied it. I learned that day to write my name in secret spots.

              • 𝕸𝖔𝖘𝖘
                link
                English
                25 months ago

                That kid you knew was a dick. At least he taught you a valuable lesson, I guess.

                • @Rai@lemmy.dbzer0.com
                  cake
                  link
                  fedilink
                  English
                  25 months ago

                  He absolutely was a dick. I stopped being mates with him after that. My school was like “yeah the cameras didn’t work that day actually”

                  • 𝕸𝖔𝖘𝖘
                    link
                    English
                    25 months ago

                    Leads me to believe that the cameras never actually worked.

      • FaceDeer
        link
        fedilink
        85 months ago

        It’s been discovered that you can reduce the bits per parameter down to 4 or 5 and still get good results. Just saw a paper this morning describing a technique to get down to 2.5 bits per parameter, even, and apparently it 's fine. We’ll see if that works out in practice I guess

        • @Corngood@lemmy.ml
          link
          fedilink
          English
          2
          edit-2
          5 months ago

          I’m more experienced with graphics than ML, but wouldn’t that cause a significant increase in computation time, since those aren’t native types for arithmetic? Maybe that’s not a big problem?

          If you have a link for the paper I’d like to check it out.

          • FaceDeer
            link
            fedilink
            125 months ago

            My understanding is that the bottleneck for the GPU is moving data into and out of it, not the processing of the data once it’s in there. So if you can get the whole model crammed into VRAM it’s still faster even if you have to do some extra work unpacking and repacking it during processing time.

            The paper was posted on /r/localLLaMA.

          • @L_Acacia@lemmy.one
            link
            fedilink
            English
            45 months ago

            You can take a look at exllama and llama.cpp source code on github if you want to see how it is implemented.

      • @rs137@lemmy.world
        link
        fedilink
        English
        15 months ago

        Llama 2 70B with 8b quantization takes around 80GB VRAM if I remember correctly. I’ve tested it a while ago.

    • @General_Effort@lemmy.world
      link
      fedilink
      English
      165 months ago

      CUDA 11.4 and above are recommended (this is for GPU users, flash-attention users, etc.) To run Qwen-72B-Chat in bf16/fp16, at least 144GB GPU memory is required (e.g., 2xA100-80G or 5xV100-32G). To run it in int4, at least 48GB GPU memory is requred (e.g., 1xA100-80G or 2xV100-32G).

      It’s derived from Qwen-72B, so same specs. Q2 clocks it in at only ~30GB.