kennylam777

@gxt92 散熱倒是簡單, 我的 3090 及 4090 都配上了 Bykski 水冷頭 , 4090 是首發買的, 兩個月後就有 Bykski 水冷頭在賣了。

當然買啊。

先前 RTX3090 缺貨, 推出一年後才購入, 結果用了一年多就推出了 4090 。

幸好 4090 在首發期間買入, 用了兩年多才推出 5090, 反正 90 不會大幅降價, 趁早購入才划算。

順帶一提, 我用單張 4090 已經能跑 Qwen2.5 72B 的 ExLlamav2 量化轉換程式(convert), 4/5/6bits 等等模型檔在本地隨便生成, Huggingface 上也有很多已經量化好的 exl2 模型

單機的話直接用 ExLlama2 呀, 量化有 2/3/4/5/6/8 bit, 簡單支援多卡, 自動或手動調整 VRAM 分配, 測試時用 text-generation-webui, 生產環境用 TabbyAPI 即可有 OpenAI compatible API, Concurrent inference with asyncio 能同時處理多個請求增加吞吐量。

我就在用單機配兩張 3090 跑 Qwen2.5 32B 8bit 量化, 32K context window 全開也足夠了, 8 張 4090 應該能直接跑 72B 不量化吧, 但 PCIe 頻寬會有問題。

我是在用 kubernetes-sigs 的 kubespray, 但因為有 GPU 節點, 所以都在用 Ubuntu, nVidia 的支援是第一考量

@ser3w 3 個 service 的方法就是我說過的 1, 但問題還是 2 的 load balancing 。

其實我自己有這種 hash 指定 backend 場景, 解決方法也很簡單, 沒有用多個 service 這麼麻煩, Istio 會參考 service 的配置但不觸及 ClusterIP, 這個我研究過。

直接上 Istio, EnvoyFilter 用 lua 加一個"x-hash-key"的 HTTP header, 然後在 DestinationRule.spec.trafficPolicy.loadBalancer.consistentHash.httpHeaderName 設成"x-hash-key"就好

ChatGPT 就能給出代碼細節。

反正都 hardcode 的 nginx config, 即是 3 個副本是固定數量的。

1 的 504 問題很簡單, 三個副本獨立各自有 ClusterIP 的 service 即可解決問題, ClusterIP 是固定 IP 不會跟隨 Pod IP 變動。


2 的 hash 問題, 我是用 Istio 解決的, Istio 有自己的 resolving 機制不跟隨 k8s services 做法, 它會自行更新 Pod IP 比較有彈性。

@yanyuechuixue 不同量化方案各有千秋, 主要分別是硬件支援, 表現也各有不同。

例如 exl2 是我用過最快的方案, 而且量化選擇比較多. 4bit 以外還有 5/5.5/6bit 等等, 對我來說比較容易選一個剛好塞進 4090 的配搭。問題是, 快是很快, 但只限 CUDA only 及 RTX30x0 以上的 GPU, 而且支援軟件不足, 也不能配 PEFT, 所以只能用來跑推理。

GPTQ 是只有 4bit 和 8bit 兩個選擇, VRAM 利用率不及 exl2, 速度也慢, 但 GPTQ 的好處是支援軟件比較多, 而且能直接用 PEFT 做 LoRA 微調。

GGUF 沒用過, 但我知道 Apple Silicon 的用家都是靠它的量化。

其實還有 bitsandbytes 的量化, 直接載入原 model 時的 4bit/8bit 量化, 推理效果不及 exl2/GPTQ/GGUF 好, 但要跑 qLoRA 微調的話, bitsandbytes 還是最通用的方案。

@yanyuechuixue 你是問 exl2 的量化吧? 我用這個, bartowski 家的 exl2 量化很多。
https://huggingface.co/bartowski/Qwen2.5-Coder-32B-Instruct-exl2

這種 model 應該大家都用的 Instruct 版, Base model 沒 SFT 過應該不好用。

@glcolof 我在 Windows 跑 4.25b 量化, 20K 是沒問題的, 節省其他開銷的話可能 30K 也行, 但我也沒調過 YARN 就是了。