抡锤者

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

下午在逛 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

小弟是個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

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

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

densha

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

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

我是老特的台灣youtube潛水觀眾，看到這篇快笑死了，也太佩服站長，太有才了，論壇居然還可以接入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

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

抡锤者

densha

帖子