ローカルLLMで読める記事は書けるのか — 6モデル比較してみた
※ この記事は執筆中（v14 まで完了、v15/v16/v17 結果は追記予定）
はじまりは Mac の乗り換え
これまで Intel 最終世代の MacBook Pro 16 を使ってきた。日常用途には十分だったのだが、VSCode + Claude Code を複数立ち上げて、ついでに YouTube で音楽を流しながら作業していると、しばしばフリーズ気味になるのが気になっていた。SSDアクセスや Chrome のメモリ食いが嵩むと、入力が数秒遅延する、IME が固まる、ファンが轟音を上げる、というやつ。
Apple Silicon 移行から数年経って、M1 Max / 64GB の中古相場が落ち着いてきたので機を見ていた。タイミングよくフリマで MacBook Pro 16 (M1 Max / 64GB) の未使用品が格安で出ていたので購入。
乗り換えてみると、当然ながらフリーズは消えた。だが代わりに新しい問題というか「機会」が生まれた：「64GB のメモリと M1 Max の GPU、何に使えば最大限活かせるんだ？」 という贅沢な悩み。
普段の業務では 32GB も使い切らない。残り 30GB+ を遊ばせるのはもったいない。そこで思い出したのが、自分が運営している Draft（記事プラットフォーム）の AI 週刊ニュース自動生成パイプラインだ。これまでは qwen2.5:72b (47GB) で動かしていたが、世代も古いし、もっと新しいモデルや異なるベンダーのモデルで試してみたら何が起きるのか、ずっと気になっていた。
「64GB あるなら、6モデルくらい順番に走らせて記事の出来を比べられるじゃないか」 — これがこの記事の出発点。
突き詰めると、問いはひとつだ：ローカル LLM を使い倒したら、人間が読みたい「読み物」になるのか？
自分なりの「ニュース」とは何か
そもそも「読み物」を作るためには、何を「ニュース」と呼ぶかを先に決めないといけない。候補を整理した：
- RSS の羅列 — ニュースサイトの見出しを並べるだけ。これはニュースの「目次」であって、ニュースそのものではない。
- SNS 発言の収集 — 速報性はあるが、数字の裏付けのない個人の感情・憶測になりがち。トレンド感は出るが、信頼に足る分析にならない。
- 自前のデータ収集基盤 + LLM 加工 — RSS、株価、規制情報、ファンディング情報を自分で集めて、データに裏付けて提示する。
3つ目を採用する。ただし、出来事を並べるだけでは「整理されたデータ」止まり。事象と事象を結びつけて、何が起こっているのかを示すことが「読み物としてのニュース」の条件だと思う。
例えば：
AI データセンターの建設需要が高まる → インフラ・エネルギー企業の株価が好調
このレベルの「点と点をつなぐ」分析が出せるなら、読者にとって価値がある。逆に出せないと、ただの「今週の出来事リスト」になる。
最終的にこのパイプラインを商用 API（Claude / GPT-4 等）に置き換える選択肢は残している。でも今回は 「個人が頑張れば手の届くローカル LLM」でどこまで行けるか を試したい。理由はシンプルで、API 課金前提だと「読者がつかなくても払い続ける固定費」が発生する。ローカルなら一度ハードを買えばランニングはほぼ電気代だけ。実験段階・低トラフィック段階で身軽にいられる。
TL;DR
- 同じ AI ニュースデータ（Phase A/B/C 共通）を、6つのオープンウェイトLLMに渡して、Phase D 以降（Headlines / Deep Dives / Stories / Takeaways）のみを書かせて比較した
- すべて Mac M1 Max 64GB + Ollama で完結。クラウド API ゼロ
- 結論：qwen3.6:35b-a3b-q8_0 MoE (38GB / 10.6分) が「数字密度 × 速度 × Stories 因果」で総合勝者。書き手の熱意が伝わる文章になる
- 大失敗：qwen3-next:80b (50GB MoE) — 64GB Mac では物理限界、思考型モデルの罠
- 副産物：MLX 派生モデル、Wired roundup記事、thinking モードなど、ローカル LLM 運用の落とし穴を多数発見
ベースラインの状態と残課題
これまで使ってきた qwen2.5:72b (47GB) のパイプラインで、Draft 公開クオリティの週刊記事は出るようになっていた。ただし読者目線で残る不満は3つあった：
- 読んでて単調 — Headlines → Deep Dives → Takeaways と並ぶが、強弱が伝わらない
- Bottom line が抽象論に逃げる — 各セクションの締めが「reshaping the industry」「a new era of...」など定型句に
- モデル世代が古い — qwen2.5 は1年以上前のシリーズ。Qwen3.6 / Llama3.3 / Gemma3 等の新世代を試してない
1, 2 は プロンプト改善 で対応した（Hook + Editor's Pick 追加、Takeaways の命令調→提示形変更、Bottom line 禁句リスト等）。残る 3 が今回の実験のスコープ。
パイプラインの構成（Phase A〜G）
各記事は以下の7フェーズで生成される。各フェーズが独立した役割を持ち、間に JSON で中間データを保存することで、後段だけ走らせる resume 実行が可能。
Phase A: データ収集
- RSS フィード 9本（Wired AI / TechCrunch AI / The Verge AI / MIT Tech Review / Hugging Face Blog / Google AI Blog / Ars Technica / etc.）から先週分の記事を取得
- 各記事は trafilatura で本文抽出（HTML → クリーンなテキスト）
- mini サーバの Trade2 DB から S&P500 の株価・出来高データ
- GovTrack / OpenStates から AI 関連法案
- ファンディングラウンド情報
Phase B: テーマ抽出
- LLM 1コールで「今週の3〜4個の主要テーマ」を JSON 出力
- 各テーマには narrative / evidence / market_impact / so_what / key_facts を持たせる
- 「同じ業種・同じ買い手のニュースだけを束ねる」プロンプトでグルーピング精度を上げている
Phase C: テーマ深掘り研究
- 各テーマについて LLM が「足りない情報」を質問（C2）
- DuckDuckGo で Web 検索して回答を取得（C3）
- 結果を統合して enriched 分析を作る（C4）
- LLM が「もう情報足りた」と判断するまで反復（最大3周）
Phase D: 記事執筆 ← モデル差分
- D0: Hook + Editor's Pick（1文の掴み + 今週の必読1件）
- D1: Headlines（全ニュースを1行ずつ箇条書き、opinion 記事は除外）
- D2: Deep Dives（テーマごとに3-4段落の深掘り、4テーマ並行）
- D3: Stories（テーマ間に関連性があれば 🔗 Connecting the Dots を書く、関連薄ければ省略）
- D4: Takeaways（観察・示唆形の箇条書き、命令調禁止）
Phase E: セルフレビュー + リバイズ
- LLM がレビュアー役で「重複 / 捏造 / 汎用フレーズ / 命令調」をチェック
- 別 LLM コールで指摘事項を反映してリバイズ
Phase F: 最終ポリッシュ + 公開
- 文法・トーン整え + 内部参照削除
- programmatic に「禁句リスト」（"reshaping the industry" "a new era of" 等）を機械的削除
- Draft API に POST して公開
Phase G: 日本語翻訳（今回追加）
- 英文 article_final.md を MoE モデルに渡して日本語化
- 「だ・である」調、固有名詞・数値の完全保持を厳守
- 平均 3.8分で1記事翻訳完了（後述）
検証構造
今回の実験では、Phase A/B/C 出力を凍結して、Phase D〜F のみ各モデルで走らせた。resume_en_from_d.py というスクリプトで、保存済み JSON を読み込んで Phase D から実行可能にした。これで「同じ素材を渡して書き手だけ変える」公平な比較になる。
試したモデル
| Ver | モデル | サイズ | アーキテクチャ | pull 元 |
|---|---|---|---|---|
| v11 | qwen2.5:72b | 47GB | dense | Ollama |
| v13 | qwen3.6:27b-q8_0 | 30GB | dense Q8 | Ollama |
| v18 | qwen3.6:35b-a3b-q8_0 | 38GB | MoE 35B (活性3B) Q8 | Ollama |
| v14 | llama3.3:70b | 42GB | dense Q4 | Ollama |
| v15 | gemma3:27b | 17GB | dense | Ollama |
| v16 | mistral-small3.2:24b | 15GB | dense | Ollama |
| v17 | deepseek-r1:70b | 42GB | thinking型 | Ollama |
| ❌ v12 | qwen3-next:80b | 50GB | MoE thinking型 | 失敗（後述） |
結果一覧
| Ver | モデル | サイズ | 実行時間 | 文字数 | 一言 |
|---|---|---|---|---|---|
| v11 | qwen2.5:72b | 47GB | 50分 | 10,461 | ベースライン（旧世代） |
| v13 | qwen3.6:27b-q8_0 | 30GB | 27.4分 | 13,633 | MBA論文調、安全運転の優等生 |
| v18 | qwen3.6:35b-a3b-q8_0 | 38GB | 10.6分 | 16,489 | 数字を使い切る編集者、最速 |
| v14 | llama3.3:70b | 42GB | 158.3分 | 13,169 | 70Bの威厳ゼロ、残念な巨人 |
| v15 | gemma3:27b | 17GB | 25.3分 | 17,457 | 饒舌な分析官、数字をそっと盛る |
| v16 | mistral-small3.2:24b | 15GB | 15.6分 | 12,648 | ソツなくまとまる中堅 |
| v17 | deepseek-r1:70b | 42GB | 239.6分 | 10,686 | 思考型、Headlines/Phase E/F全TIMEOUT失敗 |
注目すべき数字
- MoE は本当に速い: v18 (35B-A3B) は活性 3B なので、dense 27B (v13) より 2.6倍速い
- 量子化のロスは想像より小さい: v13 (Q8) と v11 (Q4) では 27B vs 72B の容量差にも関わらず、文章の自然さで v13 が勝った
- 70B クラスでも CPU spillover に注意: v14 llama3.3:70b は KV cache (CONTEXT 131072) で 102GB と表示され、48% CPU / 52% GPU でメインメモリにスピルオフ。実行時間が3倍に膨れた
失敗事例 1: qwen3-next:80b の落とし穴
最も期待していた qwen3-next:80b (50GB MoE) は、結局動かなかった。これは 64GB Mac で 80B クラスのオープンウェイト LLM を動かす上での重要な学びだった。
試行 1: think:False（v12b）
Ollama の API で "think": false を指定。狙いは「思考プロセスを生成せず、直接最終応答を吐かせる」こと。
結果：思考プロセスが response にそのまま流れ出る。記事冒頭がこれ：
Okay, let's tackle this. The user wants me to final proofread and output
the corrected full text. But first, I need to understand what exactly
needs to be done. Looking at the user's message, they provided a task:...
22,773文字の article_final.md が、ほぼ全部 LLM の独白。qwen3-next の chat template が <think> タグで思考を分離する設計になっておらず、think:False 指定が効かない仕様だった。
試行 2: think:True（v12c）
「じゃあ思考を有効化して、thinking フィールドに分離させればいい」と思って "think": true に変更。
結果：Mac の Jetsam が Python を SIGKILL。
具体的には：
- qwen3-next:80b モデル本体: 50GB
- Ollama の KV cache（思考プロセス分も含む）: +9GB
- GPU が 59GB 使用（wired_limit 60GB に対してギリギリ）
- OS / Python / Ollama サーバ用に残るメモリ: 5GB → Pages free 65MB
- macOS の Jetsam（メモリプレッシャー時の OOM killer 相当）が Python プロセスを exit 144 で kill
64GB Mac で 80B + thinking モデルは物理的に厳しい。最低 96GB は欲しい。
教訓
- thinking モデルは KV cache が膨らむので、見た目のモデルサイズ + 余裕 10〜15GB は必要
- Ollama の
thinkパラメータの挙動はモデル依存（qwen3-next と qwen3.6 で別物） - 64GB マシンの実用上限は 50GB クラスのモデルまで（KV cache 込み）
失敗事例 2: MLX bf16 の罠
「せっかく M1 Max なんだから Apple MLX の bf16 で動かせば最高精度では？」と思って qwen3.6:27b-mlx-bf16 (55GB) を試した。
試行 1: Homebrew Ollama 0.20.5
Error: 500 Internal Server Error: mlx runner failed:
MLX not available: failed to load MLX dynamic library
Homebrew 版 0.20.5 は MLX library を持っていなかった。
試行 2: Homebrew Ollama 0.21.2 にアップグレード
brew upgrade ollama で 0.21.2 + mlx + mlx-c が入った。再試行：
panic: mlx: There is no Stream(gpu, 1) in current thread.
at mlx-c-0.6.0/mlx/c/transforms.cpp:73
mlx-c 0.6.0 のバグで panic。
試行 3: Ollama 公式 .pkg 版に切替
公式版は別ビルドの MLX (0.31.1-23-g38ad257) を同梱しており、panic は出なかった。だが、プロンプト処理が壊滅的に遅い：
- 14 トークンのプロンプト処理に 90秒（5分後にも 13/14 で止まったまま）
- 41分経過しても「say pong」テストが完了せず
bf16 は精度を優先した結果、推論速度が実用に耐えない。M1 Max では諦めた。
教訓
- MLX bf16 は「速い MLX」ではなく「精度重視で遅い MLX」
- ローカルLLM ベンチマークでサイズだけ見て選ぶと罠
- 公式 .pkg 版と Homebrew 版でバンドル MLX が違う（同じ Ollama バージョンでも）
失敗事例 3: Wired Weekly Roundup 記事
Phase D の Deep Dive で、Wired AI の「It Takes 2 Minutes to Hack the EU's New Age-Verification App」記事を渡したら、生成された Deep Dive がEU age-verification ハックの話ではなく、Section 702（米盗聴権限）/ Meta Ray-Ban / Deepfake の話になった。
原因は単純：Wired のこの記事が 週次ニュースまとめ で、本文5000文字のうち EU hack の話は冒頭わずか、残り4000文字に他のトピックが詰め込まれていた。LLM は本文全体を読んで、後半の他トピックの方をメインに書いてしまっていた。
対処
extract_title_relevant_text() という関数を作って、本文を段落単位で走査し、タイトルキーワードを含む段落だけ抽出するようにした。具体的には：
- H2見出し検出: タイトル相当の短い段落（H2見出しを兼ねる）を検出し、そこから次の H2 までを抜き出す
- キーワード段落フィルタ: タイトル由来の単語を含む段落を残し、含まない段落が 2 連続したら打ち切り
- フォールバック: 抽出が短すぎる場合は冒頭をそのまま返す
これで Wired roundup 記事も Section 702/Meta/Deepfake の混入ゼロに。Round-up 系記事を扱うパイプラインでは必須の前処理だと感じる。
失敗事例 4: deepseek-r1:70b の thinking モードが量産用途では地雷
最後の比較対象として deepseek-r1:70b（思考型モデル）を試した。期待は「深く考えて、より深い洞察を出してくれる」こと。結果は逆だった。
起きたこと（v17）
実行時間 239.6分（4時間） で「完走」したが、内訳が深刻：
| Phase | 結果 |
|---|---|
| D0 Hook + Pick | ✓ 取得 |
| D1 Headlines | ❌ TIMEOUT 失敗（30分超過、空応答） |
| D2 Deep Dives 4本 | ✓ 各 15-20分かけて取得 |
| D3 Stories | ✓ |
| D4 Takeaways | ✓ |
| Phase E review | ❌ TIMEOUT 失敗 |
| Phase E revise | ❌ TIMEOUT 失敗 |
| Phase F polish | ❌ TIMEOUT 失敗 |
つまり最終 article_final.md は「Phase D の生ドラフトが Phase E/F の処理を素通りしたもの」+「Headlines セクション欠落」。比較対象として成立していない。
原因
deepseek-r1 は thinking 型で、応答前に内部で長文の思考プロセスを生成する。今回のパイプラインでは：
- Headlines は14記事それぞれを1行要約する大量タスク → 14記事分の思考連鎖で 30分の TIMEOUT 超過
- Phase E review は記事全文を読んで重複・捏造を全部洗い出す検証タスク → 思考が膨らみすぎてタイムアウト
- Phase F polish も同様
deep dive のような「1テーマ1段落」の小タスクは何とかこなすが、「並列・大量・全網羅」が要求されるタスクで思考の連鎖が自爆する。
Deep Dive の中身は意外と良かった
実は完走した Deep Dive 部分は質が高かった。Bottom line も具体的：
Cerebras's IPO filing and multi-billion dollar deals with AWS and OpenAI position it as a formidable competitor to Nvidia in the high-performance AI hardware market.
Hugging Face's Nemotron OCR v2, trained on 12 million synthetic images, reduces NED scores for non-English languages to as low as 0.035, demonstrating the transformative potential of synthetic data in multilingual OCR.
数値の使い方は v18 並み、論理構造は v13 並み。もし Headlines と Phase E/F が動いていれば、上位グループに食い込んだ可能性は高い。
教訓
- 思考型 LLM は「並列大量タスク」が苦手。Headlines のような「N 個の項目を一括で 1 行ずつ要約」が致命的に重い
- TIMEOUT を 30分→2時間に伸ばせば動くかもしれないが、1 記事に 8 時間かけるパイプラインは現実的でない
- deepseek-r1 を使うなら、タスクを「1コール=1テーマ深掘り」レベルに分解する設計が必要。今回のような汎用的な記事生成パイプラインには不向き
- スピード比 = v18 (10.6分) vs v17 (240分) で 約23倍。本番運用にはならない
このパイプラインでは deepseek-r1 は採用しない、と確定できた。
5モデル特徴比較表
評価軸別に5段階（★が多いほど良い／「数値捏造リスク」だけは★多い＝低リスク）。
| 項目 | v13 qwen3.6 dense | v18 qwen3.6 MoE | v14 llama3.3 70B | v15 gemma3 27B | v16 mistral-small3.2 24B |
|---|---|---|---|---|---|
| サイズ/速度 | ★★★ | ★★★★★ | ★ | ★★★ | ★★★★ |
| 数値の正確性 | ★★★★ | ★★★★★ | ★★★ | ★★★★ | ★★★★ |
| 文体の自然さ | ★★★★★ | ★★★★ | ★★ | ★★★★ | ★★★ |
| 論理構造 | ★★★★★ | ★★★★★ | ★★ | ★★★★ | ★★★ |
| Hook(掴み) | ★★★★★ | ★★★★ | ★ | ★★ | ★★★ |
| Bottom line具体性 | ★★★★ | ★★★★★ | ★★★ | ★★★★★ | ★★★ |
| 数値捏造リスク（低） | ★★★★★ | ★★★★★ | ★★★ | ★★ | ★★★★ |
| 翻訳しやすさ | ★★★★★ | ★★★★ | ★★★★ | ★★★ | ★★★★ |
用途別ランキング
| 用途 | 1位 | 2位 | 3位 |
|---|---|---|---|
| 読み物として読みたい | v18 | v13 | v15 |
| 数字でガッツリ語ってほしい | v18 | v15 | v16 |
| 速度優先（量産用途） | v18 (10.6分) | v16 (15.6分) | v15 (25.3分) |
| メモリ節約・軽量運用 | v16 (15GB) | v15 (17GB) | v13 (30GB) |
各モデルのクセ・観察
v13 qwen3.6:27b-q8_0 — MBA論文調
- 各 Deep Dive が「事実 → 構造的ドライバ → 戦略的含意」の3段で組まれる
- 数値は原データ完全準拠。知らない数字を作らず "high throughput" "significantly reducing" などに置き換え
- Stories セクションを敢えて省略。プロンプト的に optional なので、無理に書かない判断
- やや硬い文体だが、和訳した時に最も自然
- 引用例:
This direct confrontation with Nvidia's dominance is further evidenced by...
v18 qwen3.6:35b-a3b-q8_0 (MoE) — 数字を使い切る編集者
- 数値の使い方が一番うまい：
$510M / 76% / $237.8M / non-GAAP $75.7M lossをすべて活用 - Connecting the Dots（Stories）の因果が他モデルより構造的
- MoE 活性 3B のおかげで 10.6分という驚異的な速度（dense 27B v13 の 1/3）
- 引用例:
generated $510 million in revenue in 2025, a nearly 76% increase from the prior year
v14 llama3.3:70b — 70Bの威厳ゼロ
- 70B 最大モデルなのに文法ミスが残る。引用例:
Cerebras' IPO filing and its $23 billion valuation **the company to** further challenge Nvidia's（動詞欠落） - Hook が極端に短い：
Cerebras files for IPO amid $15 million cryptocurrency heist.のみ - 段落間の繋ぎが弱く、テーマ間の関係が説明されない
- 158.3分という実行時間は、CPU/GPU spillover（KV cache が VRAM を超えてメインメモリに溢れる）で 3倍に膨れたもの
- 「サイズが大きい＝品質が高い」は成立しない好例
v15 gemma3:27b — 饒舌な分析官、数字を盛る
- 最も饒舌（17,457字）。具体予測まで踏み込む積極性
- しかし数値捏造リスクが最も高い。例：
App releases surged 60% year-over-year in **Q1 2025**← 原データは Q1 2026the EU will likely mandate independent security audits ... **by Q1 2027**← 予測を事実っぽく断定$2.2 billion in Series G and H funding rounds← Series G $1.1B + Series H $1B の合算は原典にない表現
- 17GB で軽量、でも公開前にファクトチェック必須
v16 mistral-small3.2:24b — ソツなくまとまる中堅
- 15GB / 15.6分、最軽量・最速級
- 内容は無難、捏造リスクも低い
- 冒頭に編集者向けメタ漏れ:
"Here is the corrected full text with the requested edits:"がそのまま記事先頭に出る - 構文崩壊もチラホラ：
Anthropic's cybersecurity model could for secure AI applications（動詞欠落） - 後処理で先頭メタ削除すれば、軽量運用には十分
採用方針：qwen3.6:35b-a3b-q8_0 (MoE) 一本化
英文執筆も日本語翻訳も、qwen3.6:35b-a3b-q8_0 (MoE) 一本で行く。
| 工程 | モデル | サイズ | 速度 |
|---|---|---|---|
| 英文記事生成 | qwen3.6:35b-a3b-q8_0 (MoE) | 38GB | 10.6分/記事 |
| 日本語翻訳 | qwen3.6:35b-a3b-q8_0 (MoE) | 同上 | 3.8分/記事 |
MoE を選んだ3つの決め手
最初は v13 dense の「MBA論文調の安全運転」が読み物として正解だと思っていた。だが両方を最終形まで読み比べてみて結論が変わった。MoE の方が「人が熱意を持って書いてる感」がある。
-
数字を逃げずに使い切る v13 は
significant majoritysubstantial portionのように知らない数字をぼかして安全側に倒す。v18 は$510M76% growth$237.8M net incomenon-GAAP $75.7M loss12 million synthetic images34.7 pages/secNED 0.035–0.069を全部使い切る。同じ素材から、明らかにv18 の方が情報密度が高い。 -
Stories（🔗 Connecting the Dots）に因果がある v13 はこのセクションを丸ごと省略する判断をした（プロンプト的には optional）。v18 は「ハードウェア投資の急増 → 計算資産を守るためのセキュリティインフラへの依存上昇 → Anthropic の cybersecurity モデルへの市場期待」と3テーマを跨ぐ因果鎖を提示する。読者が「ふーん」で終わらず「なるほど」になる。
-
速度が 2.5倍 v13 27分 vs v18 10.6分。週1更新でも本数を増やしたくなった時の余地が違う。
翻訳でも MoE が圧勝
英文と同じ MoE で翻訳もできる。同じ v13 の英文記事を両モデルで日本語訳した実験で：
- dense は数値を圧縮する（"12 million" → 「数百万」と丸めた）
- MoE は数値完全保持（5億1,000万ドル / 1,200万枚 / NED 0.035-0.069 等、すべて原文通り）
- MoE は 2.6倍速（dense 9.8分 vs MoE 3.8分）
英文執筆と翻訳が同じモデルで完結するので運用がシンプル。モデル切替コストもメモリ占有も一本分で済む。
dense の格調 vs MoE の熱量
dense の唯一の強みだった「文章の格調」も、MoE と読み比べると数字に支えられた論述の方が説得力が高いことに気づいた。文体の柔らかさより、データドリブンな熱量。MoE 35B 活性 3B というアーキテクチャは「同じパラメータ規模での品質を保ちつつ推論を高速化する」設計で、ニュース記事生成という「論理構造 + 数値正確性 + 速度」を求められるタスクと特に相性が良かった。
用途別おすすめ（参考）
| 用途 | 推し | 理由 |
|---|---|---|
| 読み物として読みたい | v18 qwen3.6 MoE | 数字密度 + 因果 + 速度、書き手の熱を感じる |
| 文体の格調重視 | v13 qwen3.6 dense | MBA論文調、ぼかしで安全だが情報量は劣る |
| 軽量運用・ハード制約 | v16 mistral-small3.2 | 15GB / 15.6分、後処理スクリプト前提 |
今回採用しなかったモデル
- v14 llama3.3:70b — サイズ・時間・品質すべてで凡庸（70B なのに文法ミスが残る）
- v15 gemma3:27b — 捏造リスクが高くファクトチェックの労力が浮かない（"Q1 2025" を "Q1 2026" と間違える等）
- v16 mistral-small3.2:24b — メタ漏れで本番未満（"Here is the corrected text..." が記事冒頭に残る）
- v17 deepseek-r1:70b — thinking 型がパイプライン構造とミスマッチ（Headlines / Phase E/F が全 TIMEOUT）
「サイズ」「ベンダー」「世代」のどれもが品質を保証しない、というのが最大の収穫。実際に同じデータで走らせて並べないと、ベンチマークの数字だけでは選べない。MoE という比較的新しいアーキテクチャが、用途次第で dense を逆転することも実体験できた。
教訓まとめ
モデル選定
- 64GB Mac の実用上限は 50GB モデルまで（KV cache 込み）
- 70B+ thinking モデルは 64GB マシンには重い（96GB 推奨）
- MoE は活性パラメータ分の速度。35B-A3B なら 3B 相当の推論速度が出る
- Q8 量子化は精度ロス小さい。bf16 にこだわる必要なし
Ollama 運用
- Homebrew 版と公式 .pkg 版でバンドル library が違う
think:True/Falseの挙動はモデル依存（qwen3-next は両方ダメ、qwen3.6 は False で動く）- モデル切替時は
ollama stopで明示アンロードしないとメモリリーク iogpu.wired_limit_mb=61440で M1 Max の GPU メモリ上限を 60GB に拡張（再起動でリセットされる）
ニュース記事生成パイプライン
- Wired/Verge の週次まとめ記事は本文に他トピックが混在 → タイトル関連段落だけ抽出する前処理必須
- Phase B の narrativeは具体事実を圧縮しがち → key_facts フィールドで重要数字を保持する設計が有効
- 「partners with」を使う前に出典確認する Headlines プロンプトが必要（LLM はすぐ「提携」と言いがち）
- Bottom line の禁句リストを作らないと「reshaping the industry」「a new era of」が連発される
- Takeaways の命令調（「Watch X」「Evaluate Y」）は和訳すると「〜せよ」になり説教臭い → 「観察」「示唆」形に強制
- 翻訳プロンプトに「数値を勝手に丸めない」を明記しないと、dense モデルは "12 million" を「数百万」に圧縮する
おまけ: Draft 限定公開機能を実装した
各モデルの記事全文を読みたい人向けに Draft で限定公開 する形で URL を貼った（下記）。一覧には出さず、URL を知ってる人だけ読める形。
実は Draft（自分が作っているプラットフォーム）にはこの「限定公開（unlisted）」機能が無かったので、この比較記事のためにサーバ + CLI に追加実装した。status enum に 'unlisted' を追加して、一覧クエリは既に status='published' 限定だったので追加除外ロジック不要。記事詳細表示は if status in ('draft','pending_review','blocked') でブロック → unlisted はリストに無いので誰でも見える分類に自動で入る。最小2ファイル変更で済んだ。
CLI 側は draft publish --unlisted フラグを追加。
draft publish # 通常公開（一覧に出る）
draft publish --unlisted # 限定公開（一覧非表示、URL直接アクセスのみ）
各モデルの記事全文（英文 + 日本語訳）:
- v13 qwen3.6:27b-q8_0 (dense): English / 日本語
- v18 qwen3.6:35b-a3b-q8_0 (MoE) ← 採用: English / 日本語
- v14 llama3.3:70b: English / 日本語
- v15 gemma3:27b: English / 日本語
- v16 mistral-small3.2:24b: English / 日本語
- v17 deepseek-r1:70b（部分失敗の参考）: English / 日本語
English version of this article: Can Local LLMs Write Articles Worth Reading? — A 6-Model Comparison
作業ログ：2026-04-25 〜 2026-04-26、Mac M1 Max 64GB / Ollama 0.21.2 公式版
