剛測了一下, 4090 跑 Qwen2.5 32B coder exl2 4.25b 量化, 速度約 32tokens/s, 配 VSCode Continue 能做不錯的"explain this code to me", Custom OpenAI API

之後用真實的任務試試看, 至少現在知道 4bit 配 Continue 直接能用, 希望有時間能比較一下 8bit 量化的分別

@yanyuechuixue Windows 的 shared VRAM 是能跑 LLM, 但超過了 dedicated VRAM 後性能會大幅下降, 得不償失

@spkingr 淘寶上的 P40 很便宜, 組兩張應該能跑 32B 8bit 量化, 舊 N 卡的量化選擇應該比 Apple Silicon 多, 也可以跑 fine-tuning 雖然比 3090 慢就是了

@ShadowPower 哈哈剛發帖就看到配置了, 雙 3090 跑 8bit 量化感覺 VRAM 很充裕, 多出的 VRAM 就用來撐起 context length,

我記得之前用 Qwen 2.5 32B 8bit 量化, 在雙 3090 設成 20K 也沒問題, 如今 Coder 版應該能盡用更大的 context window

樓主在本地用量化跑吧? 有試過用 Continue 一類 VSCode 插件來用嗎?

PVE 自帶 ACME 本來就十分簡單, 自動維護的, 我實在看不到不設定的理由, 而且好處多多, VNC 連線也比較順利。

況且局域網不是用 DHCPC 分發 DNS 的嗎?都這種規模難道沒有本地 DNS? 為甚麼要手動設定 Host?

而且 PVE 主機的 IP 是固定的, 為甚麼會每個局域網也需要設定一次?

不過近期和一些中國開發者合作, 對方連公網都不用 HTTPS, 甚麼 Nacos 等亂七八糟的東西都直接用公網 HTTP 無加密連線, 就只有一個限制 IP 地址的防火牆, 甚麼 MySQL 密碼的都在國際雲上用 HTTP 直接通過 GFW 連回去中國辦公室的固定 IP 就是了, 這個國家的人似乎特別討厭 HTTPS 似的。

我的 PVE 及 Opnsense 都有正式的證書，因為我就有一個域名，用 ACME + DNS-01 也算方便。

本來就有一堆東西需要內網解析，倒也不難。

@lingerr HostPort 跟 HostNetwork 是兩碼事

HostNetwork 會影響到 networking namespace, 比如說 HostNetwork 的 container 裡面 listen 0.0.0.0:80, 就是用 Host 的所有 IP listen 80, 因為 container 直接用 Host network(名字就說明了), 在 k8s 不定義甚麼也能曝露出去。

但 HostPort 的話, container 裡面仍然是一個帶 Pod IP 的獨立 network interface, HostPort 只是將指定 Pod 端口在 Host 曝露出去。

你的需求是 HostPort 不是 LoadBalancer, LoadBalancer 就是獨立一個 IP 的服務。

MetalLB 有 L2 ARP 及 L3 BGP 的 IP 路由方法, 你完全沒提及過, 恐怕根本不知道 MetalLB 在幹啥。

簡單一點, 用 DaemonSet 跑 Traefik + HostPort 吧......

@mightybruce 其實在正式的 LoadBalancer 上, 也是用 NodePort 的, 不然雲服務商的 LoadBalancer 如何連接到服務上? LoadBalancer 的實作會幫你把 NodePort 至雲上的對應都處理好, 可以看看 aws-load-balancer-controller 的實作。


只是在生產環境上, Node Group 的端口不能直接全開到公網。

@lingerr 自己玩的就直接用 HostPort 吧, 一般 ingress controller 都支持, 這樣最簡單了。

就是內網單 IP 的 QoS 而已

Cangjie 對我來說就是輸入法....

我的心得是, 大型 instances 的 overhead 比小型的好, 所以如果出現 6 台以上的 static node pool, 就是利用率比較固定的那種, 倒是可以看看擴大一倍實例把 node 數量維持在 3 左右, 而 autoscale 的小型 instances 就分開一個 node pool, 控制突發用量的成本。

還有跨 AZ 的問題, Pod 之間的通訊, 如非必要就留在同一個 zone 內, 也可以省不少。

我的經驗是, 經過快速擴張後, 坐下來研究一下利用率, 最高能省 80%, 但某程度上是因為之前的 devs 不注重成本效益, 當時公司也不差錢啦。

cert-manager +1

我記得 rancher 現在是 k8s 的吧, 你還要考慮的是 ingress 能不能直接跟據 k8s secret 的 public cert 更新而自動載入, Ingress-NGINX Controller for Kubernetes 是可以的

nginx -s reload 是有缺點的, 畢竟你的證書一直增加上去, 就要經常 reload

在 Ingress-NGINX Controller for Kubernetes 就直接用 Lua 動態載入來解決。

k8s 的問題, 還是用 k8s 的方式解決吧。

香港的業主會帶著你的錢, 感謝有人去接盤而不至於全軍覆沒

@dcoder 我只想說, 沒必要把 k8s 說到一無是處。我看還是很多團隊在用 k8s 堆 GPU, 因為我也是其中之一。

隨便 Google 一下"gpu cluster management"看到不少方案都是 k8s 的, 這沒有甚麼不好吧。

因為直接在現有 k8s cluster 上堆 GPU node pool, 改動很少但就是可以解決問題, Dev 直接用 CUDA runtime docker image 打包過來就能 Deploy, 也不用花時間自行分配哪台 node 多少 GPU, 需求無論是 1 台 GPU 還是 100 台都是一樣的, 才不會跟你慢慢在查系統驅動配置或對齊 Run-time 的, 直接加一句 "nvidia.com/gpu" , 然後 Failover/Scaling 都依照既有的方法去做, 學過的都會。

k8s 的 CNI 才沒很古老好嗎? SDN 的都有相應 CNI plugin 啊, Multus 用過了嗎? Calico 用過了嗎? SR-IOV 用過了嗎? 哪裡慢了? 哪裡 SDN 不能用了? 就是有 CNI 插件設計才能讓各種專業的網絡方案都套進 k8s 啊。

快速 join cluster 的問題其實要處理的是 VM creation 的時間, 然後是 kubeadm join 前的環境安裝, 如果 kubelet/kubeadm/container engine 等等東西都預先打包準備好, 那不可能要 10 分鐘的, 但是在 Cloud Managed k8s 上能調整的東西不多, 例如有些 Cloud k8s 是在 VM 開機時才用 script 安裝 kubeadm/kubelet/containerd 的, 因為這麼做會比直接用包好的 node images 更乾淨也易於更新。有開機時間追求的話請自建 k8s, 只是大部分公司也沒有那種需要, 也沒能力, 才有 Cloud Managed k8s 產品出現。

DevOps/SRE 弄得好, 其他小問題就可以丟給當值的 Junior ops 處理, 而 Devs 也不必參與突發事件, 最後大家也輕鬆一點才是理想的狀態。

不如先看看 https://vast.ai

但最少要求是可靠的 Internet, 家中的就算了, 礦場一類的規模還是有機用的

@dcoder 你考慮的只是開發的日常, 但是真正有規模的系統, 不是單單講求你個人認為的 building processing 有多快, 重點是你熟識的工具, 還是得讓其他人 reproduce 一次。如果是常用的步驟, Docker 加速的方法多的是, 可能是你家 DevOps 太垃圾。

自己寫 Cluster manager 也笑了, k8s 主要能力是通用度, 不管在哪個 Cloud 都是一樣的作法。而且甚麼自己寫 Cluster manager 的出了 AWS 也是一團廢物, 請問一下的 cluster manager 能處理 BGP 嗎?Layer 2 不通只能用 Layer 3 的網絡上能通嗎? Persistent Volume 當你能調用 EBS 而不是 local storage 好了, 能加上 NFS 嗎? 還有 GPU 需要同時分配 nVidia 及 Intel 的方案也請解決一下, 自己寫 GPU manager 喔?

人家就是有全套的解決方案, 對 scaling 速度有要求的更可以不用 AWS EKS 去玩自建的, 整個 Eco system 就擺著任你用。

不肯合作, 自吹自擂的單打獨鬥派, 任你說得自己的方案多好, 沒人跟你用就是了。