抡锤者

densha

機箱內整理的很整齊，看起來很舒服

densha

@terry 真的，小弟一天到晚就在刷X帖子，DGX小盒子在外文社群之間很火的，一堆大老在發力極致優化單機、雙機甚至4機，以v4.1 flash剛出時的配方，3機才比較舒服，4機完全體，2機只是能跑，可這兩天就出現我文中看到的新配方，效果著實還可以，從可以跑到進入實用階段。

densha

最近論壇版面被strata這個新出的推理引擎霸榜，其實小盒子這區近期也是不斷再突破，例如tensorfold。

原本兩台DGX vram可輕鬆吃下deepseek v4.1 flash v4.0，v4.1 推出後，模型體積暴增，幸好開源的大神使用了exl3壓縮了體積可以放入，代價就是速度和上下文的犧牲，用起來體驗很差，而且這代deepseek也很愛思考，不像以前輕快。

然而事情再度反轉，tensorfold技術推出後，小弟在X上發現有老外結合了這項技術推出配方，幾天內就更新到了v0.4:

Bertholomus AI (DeepSeek-V4.1 TensorFold 雙機配方)
https://github.com/bertholomus/deepseek-v4.1-tensorfold-tp2-2xgb10
Bertholomus AI (TensorFold deepseek-v41-tp2 引擎分支)
https://github.com/bertholomus/TensorFold/tree/deepseek-v41-tp2

老實說技術啥的我也不懂，我爬到問就讓 hermes agent替我部署了，我只負責驗收成果。

測試環境：雙機推論叢集 (2× NVIDIA GB10 128GB Unified Memory，ConnectX-7 200Gbps 直連 RoCE TP2)
模型版本：DeepSeek-V4.1-Flash-EXL3-2.9bpw + 原生 Engram 詞表 + DSpark 5 Drafts (TensorFold v0.4, Commit d5d7bb3)
客戶端情境：使用Chatbox Agent 一句話"寫一個貪食蛇遊戲"讓deepseek v4.1產生html檔案（多輪工具調用 Tool-Calling、長上下文推理、思維鏈展開）

在本次 Agent 任務中，雙機叢集展現了高水準的穩定性與吞吐能力，特別是 v0.4 修正了前綴快取廣播問題後，Kept Prompt（前綴快取復用）在 1.8 萬 ~ 2.1 萬 Token 的長上下文下發揮了驚人效益：

總生成 Token 數：15,720 tokens（含思維鏈與代碼生成）
總運算耗時：426.2 秒（約 7.1 分鐘）
總 Prefill 耗時：38.7 秒
總 Decode 耗時：387.6 秒
整體平均解碼吞吐：40.6 tok/s（單輪最高達 63.6 tok/s）
前綴快取最高命中率：97.9%（長對話下首字延遲 TTFT 直接壓進 0.88 秒）

關鍵觀察與技術總結

前綴快取（Prefix Cache）徹底成熟：在對話堆疊至 1.8 萬到 2.1 萬 Token 時，每輪後續互動的快取命中率均穩定維持在 90% ~ 98%。以往未啟用快取時，每輪光是 Prefill 就需要乾等 15~20 秒；現在首字延遲全部壓在 1~2 秒以內，體感極度流暢，且完全未再出現舊版的通道死鎖崩潰。
DSpark Drafts（投機取樣）在長文本下的高接受率：在第 2 輪高達 5,444 Token 的大量代碼與結構化輸出中，DSpark 草稿接受度極高，在雙機 200G 直連下跑出了 63.6 tok/s 的極速解碼，大幅縮減大段寫扣的等待時間。

成品: snake.html

densha

2台DGX可以吃下的:
DeepSeek-V4-Flash-Vision-Exp
Qwen3.8-flash-next
GLM-5.3-flash
缺點:速度很普，用起來沒雲端的舒暢
優點:是可以跑未審查、數據不出門、自己擁有的爽度

densha

最新進展更新：智譜官方發布道歉與說明

事件曝光引發社群強烈反彈後，智譜官方稍早於 ZCode 官方用戶群（飛書）發布正式公告回應：

官方致歉與原因解釋：
官方承認確有觸發數據上傳，並解釋問題源自「代碼庫索引」功能。官方稱該功能旨在本地建立索引以支援會話檢查點（Checkpoint）與版本回退；而其中「Repo Wiki（倉庫維基）」功能在雲端生成頁面時會觸發上傳，因「上線初期預設開啟」導致部分用戶受影響，目前該機制已進行修復調整。
聲稱數據已銷毀：
官方宣稱 Wiki 頁面於雲端生成後，「相關上傳數據會立即銷毀，不會保存」。
承諾開源與補償：
為重建信任，智譜承諾將於近期「開源 ZCode 代碼庫」，並邀請第三方人員審查；同時為全體 ZCode 用戶補償一次週額度重置。

相關來源與社群存證：

官方飛書群公告與技術討論存證（V2EX）：https://www.v2ex.com/t/1243032
X 社群公告轉發與討論：https://x.com/Vincent_AINotes/status/2100884081546514618

️ 社群技術反思：
雖然官方承諾近期開源並宣稱數據即時銷毀，但開源社群普遍認為此說明仍避重就輕——因為單純生成 Wiki 結構完全無需將包含 Commit 歷史、LFS 及 reflogs 的 .git 目錄全量打包上傳，且介面上的隱私開關為何形同虛設也未做說明。再次提醒開發者，對於涉及敏感核心業務的專案，仍應落實嚴格的網路隔離與自託管審查。

densha

下午在逛 x，刷到ferstar的貼文，經ai整理文本後分享如下

使用 AI 程式碼編輯器的朋友，請務必立刻停下手邊的工作檢查你的電腦。

知名資安研究員 ferstar 稍早發布重磅逆向報告，實鎚揭露智譜 AI（Zhipu AI / Z.ai）官方推出的 AI 程式碼編輯器 ZCode（基於 VS Code 魔改），在使用者登入並開啟專案時，會在後台無聲無息地將整個專案的完整原始碼，連同所有 .git 歷史紀錄打包加密，上傳到阿里雲 OSS。

更嚴重的是：解密私鑰完全掌握在智譜伺服器手上，且使用者在介面上的任何隱私關閉選項全部都是「無效的安慰劑」。

逆向工程揭露的四大罪證：

偷渡完整 .git 歷史（佔比高達 86.6%）
研究員在本地目錄 ~/.zcode/v2/checkpoints/ 抓到一個高達 313 MB 的加密快照包（因網路中斷重試了 564 次失敗才意外露餡）。
解開清單發現，它不只打包當前代碼，居然把整個 .git/objects、.git/lfs，甚至包含本地分支與操作痕跡的 reflogs 全部打包！
這意味著什麼？就算你在最新版的程式碼裡把 API Key、資料庫密碼或機密金鑰刪掉了，只要你曾經 commit 過、留在 Git 歷史紀錄裡，全部被整碗端走。
加密只是防君子，私鑰在官方伺服器手中
雖然本地打包採用 AES-256-CTR 加密，但加密公鑰是客戶端向智譜伺服器索取的，只有智譜的雲端伺服器持有私鑰能夠解密，使用者對自己的商業機密完全喪失控制權。
設定裡的「隱私開關」全是安慰劑
你以為手動關閉就沒事了嗎？代碼審查發現：

關閉「Telemetry（數據收集）」？沒用，它只控制是否同意拿去模型訓練，背景上傳照跑不誤。
關閉「專案快照索引」？沒用，它只控制雲端要不要建索引，本地打包與上傳管線依然在開機時強制啟動。

隱私協議完全零披露
在官方落落長的隱私政策中，對於「靜默鏡像整個本機 Git 倉庫並上傳至雲端 OSS」這項行為，隻字未提。

️ 緊急防禦手段（作者提供的封殺方式）：

光是手動刪除本地快照是沒用的（約半小時後它又會偷偷重新打包上傳）。研究員建議直接在系統層級將該目錄權限「硬性鎖死」：

macOS：
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints
Linux：
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints

資安反思與警惕：

在這個 AI 工具遍地開花的時代，「免費用戶往往就是產品本身」。
很多包裝精美、標榜一鍵代碼生成的第三方客戶端，底層究竟在偷偷收集什麼、傳了什麼商業機密到哪裡的伺服器，一般開發者根本無從察覺。

如果你的專案包含公司核心商業資產、機密金鑰或涉及合規審查：

嚴格評估並慎用任何未經審查的特規 AI 編輯器。
盡量採用「開源乾淨編輯器（原生 VS Code）＋知名透明外掛（如 Cline/Roo）」的組合。
或將敏感推論切換為「本地自架推論大腦（如自託管 vLLM）」，徹底阻絕程式碼外流風險。

你永遠不知道你每天開著寫扣的工具，是不是正在深夜裡把你的核心家底給「無聲備份」出去了。

原始報告與逆向細節來源：

ferstar 完整分析報告：https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/
X 社群討論串：https://x.com/ferstar_org/status/2100805861002355154
微信也有網友實證：
https://mp.weixin.qq.com/s/LdXekkP-Yb2IQfoMV53uDw

#資安警訊 #AI開發 #ZCode #智譜AI #隱私安全 #GitHub #Git #軟體工程 #資訊安全

densha

Gemini 3.7 flash的回答，簡單俐落

哈哈哈哈！爹～這題當然是「開車去」啊！🚗💨😂

不然你走路或騎車去，修車店老闆是要幫你的「兩條腿」還是「腳踏車」打蠟泡泡浴啦～！🧼🚿🚲🤣

（開車開 50 公尺，油門可能都還沒踩熱就到了～哈哈哈哈！(≧∇≦)b✨）

densha

這是昨天請 hermes (gemini-3.7-flash-high) 在雙GX10跑的測試做出來的比較，沒有很嚴謹(因為題目是它幫我想的XD)，大家看看就好~

densha

小弟剛好三家都有訂閱，用cliproxy代理用了一個月多了，主要用來接cline做程式開發。
以前用Deepseek api當 hermes 大腦，8/17漲價，用完額度就暫停儲值，透過 proxy調用 googel pro 的gemini 3.7 flash替代用了幾天，持續觀察中。

densha

感謝大老，我也成功薅上了gemini pro的羊毛，不過聽說這種玩法違反谷歌政策容易被ban帳，所以還不敢大力使用

交給我的hermes (主大腦 deepseek v4 flash)去整合，生圖(image gen)、視覺(vision)都成功了！

densha

昨天又繼續跟我的hermes一起研究（其實都是它的功勞啦）報告如下

雙 RTX 2080 Ti 22GB 跑 Qwen3.6 35B Coder FP8 實戰紀錄

來源

基於 weicj/vLLM-2080Ti-Definitive 專案的 profile 與 launcher。

硬體

2× RTX 2080 Ti 22GB + NVLink
GPU 功耗上限 200W

模型

Jackrong/Qwopus3.6-35B-A3B-Coder-FP8（約 35GB）

MoE 架構，35B 總參數 / 3B 激活
FP8 量化，純文字版
支援 256K context（FP16 KV cache）
支援 Function Calling（tool-call-parser: qwen3_coder）

啟動參數

項目	值
Profile	`qwen35b/normal/fp8/fp16kv-256K-nomtp-text-only.env`
GPU	CUDA_VISIBLE_DEVICES=0,1 (TP=2)
量化	FP8
Context	262144 tokens (256K)
KV cache	FP16
MTP	0（無多 token 預測）
Reasoning	OFF（`enable_thinking=false`）
Chat Template	froggeric-v21（修復版）
Tool Call Parser	qwen3_coder

Chat Template

使用 froggeric/Qwen-Fixed-Chat-Templates v21.3

修復官方 Qwen template 的多項問題：

禁用強制思考模式（enable_thinking=false）
修復 KV cache 失效問題
優化 Jinja 渲染效能

實際測試速度表現

Prompt: 寫一篇 2000 字的小說，故事要完整，有開頭結尾
輸出: 2132 字中文字
Token: 1384 completion tokens
花費: 15.14 秒
速度: 91.4 tok/s
結束: stop（自然結束）

項目	數據
生成速度（暖機後）	91.4 tok/s
TTFT（首個 token）	~11ms
最大小說產出	2132 字 / 1384 tokens / 15.14s

我滿足了

densha

大佬的ctx開 132072這麼大@@，我的顯卡跟您一樣，照抄參數，跑起來很喘20t/s左右，而且系統內存32G也被佔滿了...

densha

感謝樓上大大，昨天跟hermes搞了一整天，抄完作業，速度提升起來，但還是遠不如該作者的每秒100t，真是夠折騰的了

FP8 文字版 150 tokens 產出:
#1: 3.21s → 46.7 tok/s
#2: 3.12s → 48.1 tok/s
#3: 3.39s → 44.3 tok/s
─────────────────
穩定: ~46 tok/s

densha

小弟是個MIS，但因為工作環境其實很久沒有接觸新知，AI火了很多年，直到今年因為體驗過gemini雲端ai感受到AI的強大，後來開始一系列的上網看影片補知識，搭建了第一個agent應用，用hermes做我的生活助理，更是不斷讓我驚奇，之後看到老特說/掄搥者頻道又學到了很多名詞，還有一些本地AI的觀念，目前雖然調整參數什麼的還是不會，但至少有建立起非常基礎的知識了。

前面廢話完畢，總之看了老特大神的影片，又來到論壇每天潛水，終於慢慢開始計畫弄自己的AI工作站。首先我先在FB market找到一家動畫工作室，搬走這台又大又重的退役X99工作站

CPU：i7-6850K (水冷一體是散熱器)
RAM：DDR4-2666 8G*2
MB：技嘉 GA-X99-ULTRA GAMING
POWER：EVGA 1000 G3 80 GOLD PLUS
SSD：自備samsung pm981a 1TB

我另外上淘寶買了下面零件

E5-2680v4
DDR4-2400 RDIMM 32G*4
RTX 2080Ti 22G *2 (雙散熱器風扇，佔2.5slot)，加上NVLINK 2.0組合

這幾天終於利用下班時間慢慢升級這台洋垃圾成完全體，也一面跟gemini和hermes討論除錯，總算裝好ubuntu 24.04系統和配好環境。

啟動腳本

#!/bin/bash
# llama-server - Qwen3.6-27B MTP-Q5_K_P (雙卡 NVLink)
# 啟動：~/serve-qwen-mtp.sh
# 停止：~/serve-stop.sh

PID_FILE="/tmp/llama-server.pid"
LOG_FILE="/tmp/llama-server.log"

# 如果已經在跑，先關掉
if [ -f "$PID_FILE" ]; then
    OLD_PID=$(cat "$PID_FILE")
    if kill -0 "$OLD_PID" 2>/dev/null; then
        echo "🔴 停止舊服務 (PID $OLD_PID)..."
        kill "$OLD_PID"
        sleep 2
        if kill -0 "$OLD_PID" 2>/dev/null; then
            kill -9 "$OLD_PID"
            sleep 1
        fi
    fi
    rm -f "$PID_FILE"
fi

# 鎖 200W 功耗
nvidia-smi -pl 200 > /dev/null 2>&1

echo "🟢 啟動 Qwen3.6-27B MTP-Q5_K_P..."
nohup /home/user/llama.cpp.cuda/build/bin/llama-server \
  --alias qwen3.6 \
  --host 0.0.0.0 \
  --port 8080 \
  --model /home/user/models/Qwen3.6-27B-Uncensored-HauhauCS-Balanced-MTP-Q5_K_P.gguf \
  --mmproj /home/user/models/mmproj-Qwen3.6-27B-HauhauCS-Balanced-f16.gguf \
  -ngl 99 \
  -c 131072 \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  --reasoning off \
  -fa 1 \
  -ub 512 \
  -np 1 \
  -fit off \
  --image-min-tokens 1024 \
  > "$LOG_FILE" 2>&1 &

NEW_PID=$!
echo "$NEW_PID" > "$PID_FILE"
echo "✅ 已啟動 (PID $NEW_PID) | 日誌：$LOG_FILE"
echo "🌐 http://192.168.10.6:8080"

nvidia-smi畫面，這是沒有任務時的狀態，覆載時大概會衝到50/60度c，有手動設定限制功耗上限200瓦，省點電和降低發熱，兩張卡貼的實在太近了，怕～

編譯了最新的llama.cpp，雙卡文字推理生成速度
llama.cpp_token-generate-log.png

編譯腳本供參

#!/bin/bash
# llama.cpp CUDA 版更新腳本
# 用法：~/llama-cuda-update.sh

set -e

LLAMA_DIR="$HOME/llama.cpp.cuda"
BUILD_DIR="$LLAMA_DIR/build"
CORES=$(nproc)

echo "🔄 更新 llama.cpp ..."

# 1. 先停止現有服務
if [ -f /tmp/llama-server.pid ]; then
    OLD_PID=$(cat /tmp/llama-server.pid)
    if kill -0 "$OLD_PID" 2>/dev/null; then
        echo "🔴 停止現有服務 (PID $OLD_PID)..."
        kill "$OLD_PID"
        sleep 2
        if kill -0 "$OLD_PID" 2>/dev/null; then
            kill -9 "$OLD_PID"
        fi
    fi
    rm -f /tmp/llama-server.pid
fi

# 2. 拉最新原始碼
cd "$LLAMA_DIR"
echo "📥 git pull..."
git pull --ff-only

# 3. 重新 cmake 設定 + 編譯（CUDA 加速）
echo "🔧 cmake 設定..."
cd "$LLAMA_DIR"
cmake -B build -DGGML_CUDA=ON
echo "🔧 編譯中（使用 $CORES 線程）..."
cmake --build build --config Release -j "$CORES"

# 4. 驗證
echo "✅ 編譯完成！"
ls -lh "$BUILD_DIR/bin/llama-server"

echo "---"
echo "🟢 請執行以下指令重啟服務："
echo "   ~/llama-cuda-qwen3.6-Q5-mtp.sh"

以上是粗淺的心得，速度沒有單一張7900XTX猛暴，但這老卡勝在便宜，疊兩張得到44GB VRAM，AI都給我信心加持說這已將很划算，性能表現也很正常。我不知道的東西還是太多了，大部分都是問AI然後貼上，或是AI幫我改，煩請各位大神不吝賜教，謝謝。

densha

小弟自從接觸了老特說開始對本地AI萌生興趣，因為公司網路限制很多，封鎖大部分的AI domain，而且就算找到可以連的雲端AI，使用幾個小時下班前DLP告警就噴了幾百筆，嚇的我不敢再用，然後就腦筋就動到外接這招。

最近從淘寶買了一組需要自己DIY組裝的顯卡塢，連接方案我挑的是SlimSAS轉接卡不是常見的OCuLink/雷電，因為我們公司就是很常見的品牌套機，這些接口不存在的，本身就重加上電源供應器、7900XTX整組拎去公司簡直像舉啞鈴重訓一樣

費了一番力氣組裝好，裝好最新amd驅動，打開 GPUZ，有跑滿i5-9500世代的PCIE 3.0x16，實際表現因為才體驗一個多小時還沒有測太多，掛Qwen3.6-27b-Q4_K_M，文字推理一秒可以噴4x-5xT/s，個人覺得滿意，終於可以開始享受上班玩本地AI了。

densha

確實啊，我身邊的親友不管我怎麼吹我的agent多好用，結果他們看到命令列就沒興趣了，今天我轉給他們看那美觀的官網和安裝後的視窗介面馬上就吸引幾個去裝了

densha

請問您會讓它24小時運轉嗎？畢竟是當agent用。

抡锤者

densha

帖子