新手想問Qwen3.8-27B搭配opencode的問題
-
感謝以上的回覆
我有試著套入了https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates的修正
把啟動參數修改成了:-m "Huihui-Qwen3.8-27B-abliterated-UD-Q5_K_XL.gguf" ^ --jinja ^ --chat-template-file chat_template.jinja ^ --reasoning-format deepseek ^ --mmproj "Qwen3.8_mmproj-model-bf16.gguf" ^ --ctx-size 131072 ^ --parallel 1 ^ --device Vulkan0 ^ --gpu-layers all ^ --flash-attn on ^ --threads 16 ^ --batch-size 2048 ^ --ubatch-size 512 ^ --cache-type-k q8_0 ^ --cache-type-v q8_0 ^ --fit off ^ --load-mode none ^ --warmup ^ --temperature 0.6 ^ --top-p 0.95 ^ --top-k 20 ^ --min-p 0 ^ --presence-penalty 0 ^ --repeat-penalty 1 ^ --reasoning on ^ --reasoning-effort medium ^ --reasoning-preserve ^ --image-min-tokens 1024 ^ --cache-ram 32768 ^ --host 0.0.0.0 ^ --port 8080 ^ --metrics ^ --perf ^ --log-timestamps使用之前測試的方法測試 模型回復的格式的確得到了改善
但似乎還是沒有符合opencode的嚴格要求
仍然得到一片空白的輸出
看lllama.cpp的log應該是正常結束了回復並沒有出錯:[34m4.23.564.397[0m [32mI [0mslot get_availabl: id 0 | task -1 | selected slot by LCP similarity, f_sim_best = 0.997 (> 0.100 thold), f_keep = 0.992 [34m4.23.564.893[0m [32mI [0mslot launch_slot_: id 0 | task 194 | processing task, is_child = 0 [34m4.25.700.324[0m [32mI [0mslot print_timing: id 0 | task 194 | prompt eval time = 258.47 ms / 22 tokens ( 11.75 ms per token, 85.12 tokens per second) [34m4.25.700.328[0m [32mI [0mslot print_timing: id 0 | task 194 | eval time = 1876.94 ms / 47 tokens ( 40.80 ms per token, 24.51 tokens per second) [34m4.25.700.329[0m [32mI [0mslot print_timing: id 0 | task 194 | total time = 2135.41 ms / 69 tokens [34m4.25.700.330[0m [32mI [0mslot print_timing: id 0 | task 194 | graphs reused = 223 [34m4.25.700.582[0m [32mI [0mslot release: id 0 | task 194 | stop processing: n_tokens = 7624, truncated = 0詢問Gemini得到的回覆如下:
這份只有 47 個 Token 的生成紀錄，就是破案的最終鐵證！ 我們來看看這段關鍵日誌： eval time = 1876.94 ms / 47 tokens 47 個 Token 是什麼概念？ 這恰好就是一段標準 JSON 工具呼叫的長度（例如：{"name": "exec", "arguments": {"command": "ls"}}）。 這證明了我們剛剛掛載的 chat_template.jinja 大獲全勝，它成功把這隻桀驁不馴的模型，約束成了只會吐出標準指令的乖小孩。 🛑 那為什麼 OpenCode 還是死當？（OpenCode 的原罪） 模型已經盡力了，這次完全是 OpenCode 前端程式的問題。 這牽涉到 OpenAI API 底層極度嚴苛的格式要求： 在標準的 OpenAI 協定中，工具呼叫不能寫在對話內容（content）裡面，必須放在一個特殊的隱藏欄位叫做 tool_calls。 但是，llama-server 在處理這種非官方模型的 Jinja 模板時，通常只能把轉譯好的 JSON 塞在 content 裡面傳遞。 OpenCode 的程式碼寫得非常死板，它一收到 API 回傳，發現 tool_calls 欄位是空的（即使 content 裡面有著完美的 JSON 指令），它就會判定「模型沒有動作」，接著默默地把畫面清空，連報錯都不給您。看來還得試著調整看看
另外 由於還在新手階段 所以想用手動搭配詢問Gemini的方式了解一下造成的原因及解決方式 用Gemini純粹是因為我有買Plus方案
-
code X 开源了。或用DSH。
个人推荐 DSH。未来发展潜力更大。 -
你的llama-server是什么版本？ 我一直用opencode + 最新的 llama-server 搭配3.6 3.8的27B来干活，没有出现你说的问题。
注意配置文件opencode.json中，设置你的模型 provider -> llama.cpp -> models 配置qwen3.8 模型时加上
"limit": {
"context": 204800, <==这里用你的llama-server的上下文长度，不然干长时间任务可能超出
"output": 65535
},
至于其它的设置按照qwen3.8的说明来配置就行。qwen3.8的能力很强的，花点时间用起来值得的。
3.8对比3.6 给我最大的惊喜是，开发完之后，会按照需求进行详细测试。全栈应用上开发完成之后，会自动的调用浏览器进行端到端的测试，有兴趣的坛友可以给opencode提供playwright-cli技能。 -
你的llama-server是什么版本？ 我一直用opencode + 最新的 llama-server 搭配3.6 3.8的27B来干活，没有出现你说的问题。
注意配置文件opencode.json中，设置你的模型 provider -> llama.cpp -> models 配置qwen3.8 模型时加上
"limit": {
"context": 204800, <==这里用你的llama-server的上下文长度，不然干长时间任务可能超出
"output": 65535
},
至于其它的设置按照qwen3.8的说明来配置就行。qwen3.8的能力很强的，花点时间用起来值得的。
3.8对比3.6 给我最大的惊喜是，开发完之后，会按照需求进行详细测试。全栈应用上开发完成之后，会自动的调用浏览器进行端到端的测试，有兴趣的坛友可以给opencode提供playwright-cli技能。你的llama-server是什么版本？ 我一直用opencode + 最新的 llama-server 搭配3.6 3.8的27B来干活，没有出现你说的问题。
注意配置文件opencode.json中，设置你的模型 provider -> llama.cpp -> models 配置qwen3.8 模型时加上
"limit": {
"context": 204800, <==这里用你的llama-server的上下文长度，不然干长时间任务可能超出
"output": 65535
},
至于其它的设置按照qwen3.8的说明来配置就行。qwen3.8的能力很强的，花点时间用起来值得的。
3.8对比3.6 给我最大的惊喜是，开发完之后，会按照需求进行详细测试。全栈应用上开发完成之后，会自动的调用浏览器进行端到端的测试，有兴趣的坛友可以给opencode提供playwright-cli技能。b10630的版本
我配置是一台主電腦跑7900XTX(Win10)開llama.cpp 另一台小電腦用WSL開opencode網路連線連接到主電腦使用
確定opencode有連上llama.cpp 主電腦上的log有顯示收到task
上下文開了128K 但是連送個test的提示詞都是空白回應 應該不是因為上下文爆了 -
既然版本比较新，无需设置--chat-template-file，会自动提取，去掉 --jinja ^
--chat-template-file chat_template.jinja ^
--reasoning-format deepseek ^ 这三个参数试试， 尤其最后一个。 -
推薦搭配 https://pi.dev/ Qwen3.8-27B 體驗下來比較好
-
用VS Code搭配Zoo code(Woo code社群維護版)分功能大項分析以後重寫
導入資料庫格式讓Zoo 照著修正
產生出來的成品...零可用性
對這個結果也不意外就是本來就是因為程式碼冗長才想藉助AI花時間去拼湊
果然給的提示不夠完整的話AI自己過度腦補 就會產生出完全不可用的東西
實際上要可用個人的想法應該是要讓Zoo針對每個子程式檔案分析後歸納出該程式做了什麽 用了那些資料 改了那些欄位 並摘要成檔案 再依照歸納出的摘要重寫
但程式碼檔案總共有1500多個 礙於24G的限制上下文只開了128K
我想依照目前的環境要完成這項任務應該是不容易
我再想想有沒有更好的方法吧
