llama.cpp icon indicating copy to clipboard operation
llama.cpp copied to clipboard

Alpaca model is running very slow in llama.cpp compared to alpaca.cpp

Open robinnarsinghranabhat opened this issue 1 year ago • 3 comments

Prerequisites

Please answer the following questions for yourself before submitting an issue.

  • [x] I am running the latest code. Development is very rapid so there are no tagged versions as of now.
  • [x] I carefully followed the README.md.
  • [x] I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
  • [x] I reviewed the Discussions, and have a new bug or useful enhancement to share.

Current Behavior

Just yesterday, this migration script was added : migrate-ggml-2023-03-30-pr613.py. So, what I did on top of @madmads11 instructions for using alpaca models was to use this above script and generate the final bin file to work with.

Details :

  • Alpaca Model used : https://huggingface.co/Pi3141/alpaca-lora-7B-ggml
  • Tokenizer used : https://huggingface.co/decapoda-research/llama-7b-hf/blob/main/tokenizer.model

I am using llama.cpp just today to run alpaca model. (was using antimatters alpaca.cpp until now)

This same model that's converted and loaded in llama.cpp runs very slow compared to running it in alpaca.cpp.

How I started up model :

  • ./main -m ./models/alpaca-7b-migrated.bin -ins --n_parts 1

The logs :

main: seed = 1680346670
llama_model_load: loading model from './models/alpaca-7b-migrated.bin' - please wait ...
llama_model_load: n_vocab = 32000
llama_model_load: n_ctx   = 512
llama_model_load: n_embd  = 4096
llama_model_load: n_mult  = 256
llama_model_load: n_head  = 32
llama_model_load: n_layer = 32
llama_model_load: n_rot   = 128
llama_model_load: f16     = 2
llama_model_load: n_ff    = 11008
llama_model_load: n_parts = 1
llama_model_load: type    = 1
llama_model_load: ggml map size = 4017.70 MB
llama_model_load: ggml ctx size =  81.25 KB
llama_model_load: mem required  = 5809.78 MB (+ 1026.00 MB per state)
llama_model_load: loading tensors from './models/alpaca-7b-migrated.bin'
llama_model_load: model size =  4017.27 MB / num tensors = 291
llama_init_from_file: kv self size  =  256.00 MB

system_info: n_threads = 16 / 16 | AVX = 1 | AVX2 = 1 | AVX512 = 0 | FMA = 1 | NEON = 0 | ARM_FMA = 0 | F16C = 1 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 0 | SSE3 = 1 | VSX = 0 | 
main: interactive mode on.
Reverse prompt: '### Instruction:

'
sampling: temp = 0.800000, top_k = 40, top_p = 0.950000, repeat_last_n = 64, repeat_penalty = 1.100000
generate: n_ctx = 512, n_batch = 8, n_predict = 128, n_keep = 2

Additionally, I also used this bin file : https://huggingface.co/Pi3141/alpaca-lora-7B-ggml/blob/main/ggml-model-q4_1.bin that's already migrated for llama.cpp. And even for this, model is running slow with llama.cpp.

One thing I noticed was, while loading between these two model variants, this line is different than on above. llama_model_load: f16 = 3.

Environment and Context

  • Physical (or virtual) hardware :

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  16
  On-line CPU(s) list:   0-15
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
    CPU family:          6
    Model:               158
    Thread(s) per core:  2
    Core(s) per socket:  8
    Socket(s):           1
    Stepping:            13
    CPU(s) scaling MHz:  98%
    CPU max MHz:         5000,0000
    CPU min MHz:         800,0000
    BogoMIPS:            7202,00
Virtualization features: 
  Virtualization:        VT-x
Caches (sum of all):     
  L1d:                   256 KiB (8 instances)
  L1i:                   256 KiB (8 instances)
  L2:                    2 MiB (8 instances)
  L3:                    16 MiB (1 instance)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-15
Vulnerabilities:         
  Itlb multihit:         KVM: Mitigation: VMX disabled
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Mitigation; Clear CPU buffers; SMT vulnerable
  Retbleed:              Mitigation; Enhanced IBRS
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Vulnerable: eIBRS with unprivileged eBPF
  Srbds:                 Mitigation; Microcode
  Tsx async abort:       Mitigation; TSX disabled
  • System info:
- OS : 5.10.148-1-MANJARO
- python version : Python 3.10.9
- g++version : g++ (GCC) 12.2.1 20230201

robinnarsinghranabhat avatar Apr 01 '23 11:04 robinnarsinghranabhat

See #603

MillionthOdin16 avatar Apr 02 '23 13:04 MillionthOdin16

Updated context from #603, sounds like things may have been fixed?


Thank you for this hard work - I missed this regression because I rarely run generations with more than a few tens of tokens. The problem is that the transpose operation for the V matrix is very slow and becomes slower and slower with every new token added.

I think I have provided a fix here: https://github.com/ggerganov/llama.cpp/pull/775

Tested only on M1 so far

Originally posted by @ggerganov in https://github.com/ggerganov/llama.cpp/issues/603#issuecomment-1497569526


#775 was merged pretty quickly, cyyynthia if it's not too much trouble, could you update your pretty graphs with that?

@sw The graphs aren't super pretty this time because I didn't take the time to properly close everything and had a bunch of things open in background while the test was running 😅

That being said, the regression appears to be gone. 🎉 Here's the graphs and the raw CSV: image token_times.csv

Originally posted by @cyyynthia in https://github.com/ggerganov/llama.cpp/issues/603#issuecomment-1498024558


Well I guess that settles it. The Great Wizard Georgi has saved the day! Thanks to @cyyynthia and @KASR for putting in the hard work of tracking this down.

I have opened #790 to track the discrepancy in the different partial times vs total time. I think this issue could be closed. Thanks everyone.

Originally posted by @sw in https://github.com/ggerganov/llama.cpp/issues/603#issuecomment-1498071071

0xdevalias avatar Apr 11 '23 02:04 0xdevalias

This should be resolved with #603 . It's the same behavior I described in the issue.

MillionthOdin16 avatar Apr 11 '23 06:04 MillionthOdin16