[Bug]: Llama 3.1 outputs gibberish when --kv-cache-dtype fp8 but AWQ model works fine

[Nero10578]

Your current environment

Collecting environment information... PyTorch version: N/A Is debug build: N/A CUDA used to build PyTorch: N/A ROCM used to build PyTorch: N/A OS: Ubuntu 22.04.4 LTS (x86_64) GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 Clang version: Could not collect CMake version: version 3.22.1 Libc version: glibc-2.35 Python version: 3.12.4 | packaged by Anaconda, Inc. | (main, Jun 18 2024, 15:12:24) [GCC 11.2.0] (64-bit runtime) Python platform: Linux-6.5.0-44-generic-x86_64-with-glibc2.35 Is CUDA available: N/A CUDA runtime version: Could not collect CUDA_MODULE_LOADING set to: N/A GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3090 GPU 1: NVIDIA GeForce RTX 3090

Nvidia driver version: 550.90.07 cuDNN version: Could not collect HIP runtime version: N/A MIOpen runtime version: N/A Is XNNPACK available: N/A CPU: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 46 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) i7-6900K CPU @ 3.20GHz CPU family: 6 Model: 79 Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 1 Stepping: 1 CPU max MHz: 4200,0000 CPU min MHz: 1200,0000 BogoMIPS: 6411.49 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts vnmi md_clear flush_l1d Virtualization: VT-x L1d cache: 256 KiB (8 instances) L1i cache: 256 KiB (8 instances) L2 cache: 2 MiB (8 instances) L3 cache: 20 MiB (1 instance) NUMA node(s): 1 NUMA node0 CPU(s): 0-15 Vulnerability Gather data sampling: Not affected Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Meltdown: Mitigation; PTI Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Retbleed: Not affected Vulnerability Spec rstack overflow: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Mitigation; Clear CPU buffers; SMT vulnerable Versions of relevant libraries: [pip3] No relevant packages [conda] No relevant packages ROCM Version: Could not collect Aphrodite Version: N/A Aphrodite Build Flags: CUDA Archs: Not Set; ROCm: Disabled

🐛 Describe the bug

Running Meta-Llama-3.1-8B-Instruct full FP16 model cloned from meta repo with below start command will output gibberish:

python -m aphrodite.endpoints.openai.api_server \
--model /home/user/models/Meta-Llama-3.1-8B-Instruct \
--gpu-memory-utilization 0.98 --max-model-len 131072 --port 8000 --kv-cache-dtype fp8 \
--max-num-seqs 20 --served-model-name Meta-Llama-3.1-8B-Instruct --enforce-eager true --tensor-parallel 2

But running Meta-Llama-3.1-8B-Instruct-AWQ-INT4 from huggingquants with below start command will work fine:

python -m aphrodite.endpoints.openai.api_server \
--model /home/user/models/Meta-Llama-3.1-8B-Instruct-AWQ-INT4 \
--gpu-memory-utilization 0.95 --max-model-len 131072 --port 8000 --kv-cache-dtype fp8 \
--max-num-seqs 20 --served-model-name Meta-Llama-3.1-8B-Instruct --enforce-eager true --tensor-parallel 2

Disabling FP8 kv-cache also makes it work fine, but I can't fit full context on 2x24GB 3090. So I have to reduce the context:

python -m aphrodite.endpoints.openai.api_server \
--model /home/user/models/Meta-Llama-3.1-8B-Instruct \
--gpu-memory-utilization 0.98 --max-model-len 8192 --port 8000 \
--max-num-seqs 20 --served-model-name Meta-Llama-3.1-8B-Instruct --enforce-eager true --tensor-parallel 2

Meta-Llama-3.1-70B-Instruct-AWQ-INT4 also works fine with FP8 kv-cache:

python -m aphrodite.endpoints.openai.api_server \
--model /home/user/models/Meta-Llama-3.1-70B-Instruct-AWQ-INT4 \
--gpu-memory-utilization 0.98 --max-model-len 8192 --port 8000 --kv-cache-dtype fp8 \
--max-num-seqs 20 --served-model-name Meta-Llama-3.1-70B-Instruct --enforce-eager true --tensor-parallel 2

[AlpinDale]

Are you on the main branch? The Llama 3.1 RoPE extension method has been added in the rc_054 branch. Please try building that branch.

As for the memory issues, I recommend using --enable-chunked-prefill. It saves more memory for context compared to FP8 KV Cache, but they're mutually exclusive at the moment.

[Nero10578]

Are you on the main branch? The Llama 3.1 RoPE extension method has been added in the rc_054 branch. Please try building that branch.

As for the memory issues, I recommend using --enable-chunked-prefill. It saves more memory for context compared to FP8 KV Cache, but they're mutually exclusive at the moment.

I'm on rc_054 branch, wasn't aware the main branch works with 3.1, but I will do a git pull on rc_054 and try again. Maybe I was behind a few commits. Will try using chunked prefill also.

Also speaking of rc_054, I found a problem that stops it from accepting /chat/completions that I'm not sure if it is on purpose. Line 58 on the serving_chat.py of the openai endpoints:

 # Deal with list in messages.content
        # Just replace the content list with the very first text message
        for message in request.messages:
            if message.role == "user" and isinstance(message["content"], list):
                message["content"] = next((content["text"]
                                           for content in message["content"]
                                           if content["type"] == "text"), "")

Chat completions works if I change it to:

for message in request.messages:
            if message['role'] == "user" and isinstance(message['content'], list):
                message['content'] = next((content["text"]
                                        for content in message['content']
                                        if content["type"] == "text"), "")

[Nero10578]

So just an update chunked prefill works for 2xRTX 3090 24GB NVLink for Llama 3.1 8B FP16 at full 128K context. It outputs normal non-gibberish text. Yay! Thanks alpin.

Performance is also impressively high. I can get just over 2.4Kt/s on just pure token generation with 200 requests.

On another note --load-in-8bit and --load-in-smooth haven't patched to work with Llama 3.1 right? Because that doesn't work.

[AlpinDale]

So just an update chunked prefill works for 2xRTX 3090 24GB NVLink for Llama 3.1 8B FP16 at full 128K context. It outputs normal non-gibberish text. Yay! Thanks alpin.

Performance is also impressively high. I can get just over 2.4Kt/s on just pure token generation with 200 requests.

On another note --load-in-8bit and --load-in-smooth haven't patched to work with Llama 3.1 right? Because that doesn't work.

the automatic quants in the main branch currently do not work in the rc_054 branch. If you really need on-the-fly quantization, you can try:

Non-hopper GPUs:

pip install deepspeed
aphrodite run NousResearch/Meta-Llama-3.1-8B-Instruct -q deepspeedfp --num-deepspeedfp-bits {4,6,8,12}

And for hopper (or other FP8-enabled GPUs), this should work:

aphrodite run NousResearch/Meta-Llama-3.1-8B-Instruct -q fp8

Also, thanks for the chat completions fix. If you have the time, would you mind sending a patch to the rc_054 branch? I don't have the bandwidth to work on the API endpoints these days, so they've been neglected.