kennylam777

我是在用 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 就是了。

@sampeng 有道理, 即使工作上要 deploy LLM 也應該優先選擇 ChatGPT/Claude API 按量付費。

但對於本來就有 4090 和 3090 用來玩遊戲的我, Local AI 就是用來榨出現有硬件價值的玩法。

我相信 Apple Silicon 的玩法也是一樣的, 本來就會買一台機來用, 看到免費的 LLM 拿來用起碼不必多訂閱一個服務。

@SoulSleep 你這種 use case 是 Ops 選錯方案啦, 租用雲 GPU 不是都為了 fine-tuning 嗎? 用完趕快關掉的那種, 6K 月費夠你買私有硬件了吧。當初沒調研過用量嗎?

@m1nm13 nat1 這種沒標準化過的 jargon 也太欺負 LLM 了吧? Local AI 應該用在 code review 一類 RAG 的用途會比較好。

@spike0100 Apple Silicon + 24GB 應該能跑 GGUF q3 吧, q4 可能也可以但有點勉強