雖然我還有在用 Python, 但 production 的東西我都轉向用 Go 了, 畢竟 compile time 能擋很多東西, strong type 讓 LLM 也能清楚理解數據結構

React 及 Python 的 project, 我都要用 strict type check 及 ruff 及 pyright 一類先檢查再讓 LLM 去宣告做完, 還真的能擋不少低級錯誤

@BingoXuan Nemotron Nano 還真的不太行, Ultra 出來了好像也不太有性價比, 550B 等級的中國模型比它強。

btw, MTP 在 Coding agent 上加速效果挺明顯的, 我想是算 diff 一類能搬字過紙的任務上猜得到就能過, Gemma 4 31B Q4 在 5090 我試過能跑到最高 90tps, 反而 Qwen 3.6 27B 我都沒仔細看過最高 tps

但真的要快的話, 把 Qwen 3.6 35B 灌下去, tokens 嘩啦嘩啦就跑一堆出來還算爽的, max tps 過 130, 簡單任務也算能用

@commoccoom 我單張 RTX5090, Q3.6 27B Q5_K_XL 用以上配置能跑 context 102400, 56tps

另外我還有兩張 RTX3090 的 NVLink 能跑 Gemma 4 31B Q8, F16 K/V, ctx 51200, 55-60tps, 但現在要買 3090 及它的 NVLink 應該不容易。

聽說有人在淘寶魔改了 V100 能插 PCIe 及多卡 NVLink, 但這種魔改的東西除非你對 inference 很有經驗, 否則不建議用。也有些人用舊款 AMD MI50 32GB 去組多卡, 但好像 llama.cpp 沒直接支援要用改版的, 也不太建議用。

RTX6000 Pro 的 96GB VRAM 及超大 bandwidth 肯定是單卡最強的民用產品

32GB 的新品好像還有 Intel Arc Pro B70, 比 RTX5090 便宜不少, 但這個 llama.cpp 的支援可能不完整, vllm 倒是有 Intel 自己的版本有維護能配 Qwen 3.5

@BingoXuan 我是 Codex 及 Antigravity 雙持的, 都是 USD20 等級的套餐, 但自從我本地有 Qwen 3.6 27B (Q5_K_XL Weights, Q8 K/V, MTP)後, 有一次我兩家的 agent 都跑到 debug 一半沒了 quota 很焦慮。

還好之前有練過用本地跑 VSCode Copilo 及 Claude Code, 拿 Qwen 3.6 27B 給我上還真的能把事情做好。

這時候我就深深感受到這東西會減少人們對 Subscriptions 及 API 的依賴, 很佛心但也會影響利潤吧。

@BingoXuan Gemma 4 這次很給力吧, reddit 上不少人都同意文字類答案比 Qwen 3.6 好, Qwen 3.6 是英語及中文很強, 但 Gemma 4 的廣東話及繁體字比 Qwen 3.6 強超多, Gemma 4 31B 在 agentic coding 用廣東話對答如流, Qwen 3.6 就會用簡體中文標準漢語回應, 也有一些 benchmark 說 Gemma 4 31B 比 Qwen3.6 27B 在 coding planing 更細密。

Qwen 3.6 是絶代的話就慘了, Google 不會放更好的模型出來, 畢竟 Qwen 還是很能打我也是 Gemma 4 及 Qwen 3.6 兩個模型都有在用。

@Livid 怪不得會選 26B A4B MoE, memory bandwidth 擺在那 TPS 是壓力, 反而我好奇的是 Qwen 3.6 35B A3B 的簡中應該也很強, 速度更快, 選用 Gemma 4 26B A4B 的選因是?

不過我記得第一個實作 Diffusion Language Model 的是這個 HKU 團隊, 那時他們家的 Sudoku 的解題特別強。
https://github.com/HKUNLP/DiffuLLaMA

玩過 DiffuLLaMA Demo 很有趣, Diffsuion 文字輸出是先把句子長度固定, 然後內容再走出來, 先畫靶再射箭的感覺, 不是 Autoregressive 的書寫次序, 但那時字(token)蹦出來後就不會再動。

這次 DiffusionGemma 更有趣的是內容還會在 render 過程中變動, 我倒期待 Llama-Server 的實作出來是如何的, 如果 Sudoku 強的話可能龍蝦一類 vision+computer use 的用途會有驚喜?

@coefu 我倒希望 Qwen 繼續開源跟 Gemma 一拼, Google 沒對手的話就不會放新模型了

正如以前用 RTX 5090 都沒有一個本地模型能 agentic coding, 大部分都倒在了第一個 failed tool call 上, 倒是 Qwen 3.5 27B 出來後才算有一個能用

對呀本來就 11 號重號, 原本是 6 號的

不就是把 Claude Code/Antigravity/Qwen 等等改成名人的名稱, 又是一個 "Hey I vibecoded a groundbreaking blah blah"的貼

現實很美好, 但用起來要先解決 Codex/AGY 能不能讓你的 program 包起來用的基本問題, 不然就引發 claude code -p 事件了

近日在 reddit 不少人也投訴 Antigravity 產生無限循環, 我猜 Google 可能在擠算力給 Gemini 3.5 Pro, 然後在 Flash/Pro 打開了 Weight quantization 或在 KV 玩起了像 TurboQuant 的新花樣

暫時單機能跑智力過關的只有 Gemma 4 31B 或 Qwen 3.6 27B, 能做輕量開發, 我用 RTX 5090 跑這兩個 ctx 能達到 1024000 才算可以, 起碼跑 Claude Code 或 Github Copilot 還不算太易滿 context, MTP 能 90tps

Hermes Agent 的話, 以上兩個都未必能達到滿意水準, 還要用 Mac 跑 10B 以上的 Dense 速度感人。

Gemma 4 26B/Qwen3.6 35B MoE 就不用想了, 太弱, 處理簡單 coding 任務時還好, 但 MoE 的小 expert 才 3B/4B, Q4 後會更高機會 tool call 錯, 對 agentic operations 是大傷

@bowser1701 通常都跟模型有關, 長 context 是一種能力, Qwen 的收費版才有 1m context support, 但在 1m 觸發 compact 前就死循環那是長 context 能力不足了。

雖然我在本地用 Qwen 3.6 27B/35B 都只限在 256k 甚至是 200k, 不太會死循環, 但如果把 Weight 或 KV 壓成 4bit/Q4 就更容易會出現類似錯誤。

雖然在 inference 時的確能調 repeat penalty 去減少重覆回應, 但我測過能力弱的模型, 要死循環時你如何調也救不回來。

Gemma4 12B Q4 GGUF 我測過是能跑得動 Github Copilot 的 tool use, 32GB 的 laptop 勉強能跑還有 ctx 65536, 小模型用輕量的 agent 例如 pi.dev 效果會更好

FP8 就留給 RTX Spark 的 laptop 吧, 5090 Mobile 24GB 也許還可以?

Gemma4/Qwen3.5 3.6 比上年的 Gemma 3/Qwen3 都強很多, 但 LLM 愈大愈強是必然的, 我用 5090 Desktop 還是在用 Qwen 3.6 35B A3B NVFP4 才算滿意, KV 都不敢壓

本來還省著用到 6 月 8 日, 想不到又 reset 了, 把麻煩問題都丟進去 Codex, 5.5 Extra High 開好開滿

不錯喔, 之前我用的是 Claude Code + Qwen 3.6 35B MTP APEX Q5, 但 Claude Code 很多 plugin 都要 server side support 所以都有問題, 官方 Copilot 也比較好用的是拖曳檔案不用再按 Shift 了

Tech stack 差距不大, 但我用起來 Golang typecheck 比較嚴緊, 小問題在 compile 時就能發現, 後續痛苦度比較低。

Python 的話, pycompile 過也不一定能跑, 所以我加上了 ruff 及 pyright, 總算在用 Qwen 3.6 27B/35B A3B 配 Claude code 也能預早發現小問題, 總算能幹點粗活。

TypeScript 也一樣, 先把 `strict: true` 打開, 讓 LLM 自己修好。

先說一下我有在付費用 Codex 及 Antigravity, 但各 20 的額度還是不太夠。

這次更新太垃圾了, Flash 3.5 預設給你跑 Fast mode, 但 token 燒得倒水一樣快

更可惡的是還沒 GPT 5.5 Low 聰明

真的要考慮不續了, 我寧願把 Codex 升高一級