Qwen3.6-27Bのlocal agent実験、計画は有望でも実行にはgateが必要
Original: Replaced Claude with local Qwen3.6-27B in my multi-agent orchestrator for 2 weeks View original →
r/LocalLLaMAに投稿された2週間の実験は、local modelをagentシステムに組み込む際の現実的な境界を示している。投稿者はRTX 3090 24GB上でOllama経由のQwen3.6-27B Q6_Kを使い、lead、manager、sub-agentで構成されるmulti-agent orchestratorのreasoning layerをClaudeから置き換えた。評価は2つの実リポジトリに対する47件のmulti-step coding workflowで行われたという。
良好だったのは計画とレビューだ。Qwen3.6は多段階のplan generationで比較的一貫した結果を出し、prompt調整後にはschema-validな出力が約95%に達したと投稿者は報告している。Mem0風のmemory extractionも機能し、別のQwen instanceによるレビューでは、Claudeが見つけたbugの約60%を検出したという。consumer GPU上のlocal loopとしては十分に意味のある結果だ。
一方で、実行境界は弱かった。Qwen3.6のJSON tool-call outputは47タスクで約12%のformat error rateを示し、同じworkloadでClaudeは約0.5%だったと比較されている。問題はJSONの破損だけではない。field name、type、存在しないtool signatureの生成など、実際のファイル操作や外部tool実行では危険になり得るズレが含まれていた。
長いcontextにも限界がある。14k tokensを超えると過去の決定を誤って記憶し始め、実用上は12k tokens付近でsummarize-and-resetが必要だったという。sub-agentが失敗した後の再計画も安定せず、失敗を成功とみなして次へ進むcascade failureが47回中3回あった。
この実験はlocal agentを否定していない。むしろ、Qwen3.6-27Bはlocal planning layerとして有望だが、ungated execution layerとして扱うべきではないという線引きを示している。plan approval、structured-output enforcement、failure detectionをシステム側で強制する必要がある。
cloudかlocalかという単純な比較より、この境界のほうが実務では重要だ。信頼の設計はpromptではなくarchitectureに置くべきだという教訓が残る。
Source: Reddit r/LocalLLaMA.
Related Articles
NVIDIAは550BパラメータのMoEモデルを、Agent ToolkitやOpenShellと一体で打ち出した。最大5倍の推論速度、最大30%のコスト低下、6月4日の提供開始が焦点になる。
QVAC SDK 0.12.0はTurboQuantをopt-in機能として追加し、ローカルLLMのruntime context memoryを最大5倍削減する。8GB級GPUでも4B modelの262K contextを狙える点が大きい。
大きな反応を集めた理由は古いCPUの意外性だけでなく、LLM inferenceの現実的なボトルネックが見えたことにある。
Comments (0)
No comments yet. Be the first to comment!