AI應用

前言 Microsoft 的 Superintelligence team 在 2026 年 6 月 2 日正式推出了 MAI-Code-1-Flash——一個專為日常開發者工作流設計的高效編碼模型。這個模型由 Microsoft 端到端打造，使用乾淨且具合法授權的資料訓練，目前已開始部署到 GitHub Copilot 的 VS Code 個人版使用者中。 簡單來說，這是 Microsoft 在「讓 AI 真正好用」這條路上又踏出的一步。 三大核心能力 根據官方公告，MAI-Code-1-Flash 主打三個特色： Agentic Coding（智能代理編碼）：模型直接在 GitHub Copilot harness 環境中訓練，能與開發者日常使用的工具和系統無縫協作，不是只在實驗室跑分，而是在真實環境中學習如何寫碼。 Adaptive Thinking（自適應思考）：遇到簡單任務時保持精簡，遇到複雜問題時自動分配更多推理預算。這就像一個懂得看場合的同事——小事不廢話，大事肯花時間。 強指令遵循能力：無論是一次性提問還是多輪對話，都能精準理解並執行開發者的意圖。 為什麼說「為開發者而生，不是為跑分而生」？ 這可能是這篇文章最關鍵的概念。大多數 AI 編碼模型的訓練目標是「在 benchmark 上拿高分」，但 MAI-Code-1-Flash 反其道而行——它在 GitHub Copilot 的生產環境中直接訓練，用真實開發者的使用數據來優化模型。 訓練過程中，團隊評估了核心軟體工程任務、倉庫問答、重構能力，以及從真實 Copilot 使用記錄中提取的遥測數據任務。這種「訓練、評估、生產」三者一致的方法，確保了實驗室裡的改進能真正轉化為開發者的體驗提升。 每個 token 都要花在刀口上 MAI-Code-1-Flash 引入了 自適應解決方案長度控制（Adaptive Solution Length Control） 技術。用白話來說： 簡單任務 → 精簡回答，少花 token 複雜任務 → 深入分析，多花 token 實際效果是：在 SWE-Bench Verified 上，MAI-Code-1-Flash 解決難題時最多少了 60% 的 token 用量。這不僅降低了延遲和成本，更讓互動式工作流變得更順暢——開發者不用等那麼久就能看到有用的輸出。 ...

引言：一台「不該跑 AI」的機器 這篇文章是 point.free 上一篇 Gemma 4 系列的最後一篇——前面兩篇講了怎麼把 Gemma 4 的 MTP drafter 量化、怎麼跟 verifier 配對，而這一篇要回答一個更刁鑽的問題： 「把這些成果丟到一台根本沒有資格跑 AI 的機器上，會怎樣？」 作者的硬體規格聽起來像是一台從墳墓裡挖出來的古董： CPU：Intel Xeon E5-2620 v4（2016 年產，約為當前筆電 CPU 的五分之一慢） 記憶體：128 GB DDR3（頻寬只有最新筆電 RAM 的五分之一到六分之一） GPU：無（連內顯都沒有） 換作一般工具，比如 ollama，直接放棄。但這篇文章的作者說：「等等，聽我說完……」 核心問題：記憶体牆（Memory Wall） 要理解這篇文章的精髓，先搞懂一個概念——LLM 推理的瓶頸不在運算能力，而在記憶體頻寬。 當你使用 ChatGPT 看著文字逐字流出時，你看到的是「decoder pass」。在這個階段，處理器要不斷把龐大的模型權重從記憶體拉進 CPU cache 才能計算下一個 token。處理器的運算速度其實很快，但它大部分時間都在等記憶體傳輸——這就叫「記憶體受限」（memory-bound），而非「運算受限」（compute-bound）。 這就是著名的「記憶体牆」問題。不管你用的是 2016 年的 Xeon 還是最新的 H100，這堵牆都在那裡。 所以，直接拿預設參數跑 llama-cli 在 DDR3 機器上會慢到令人發指。解法是什麼？把 ik_llama.cpp 能用的優化選項全部拉滿。 那串「魔法咒語」 作者甩出了一長串 llama-cli 參數，看起來像中世紀巫師的咒語： llama-cli \ --model gemma-4-26B-A4B-it-Q8_0.gguf \ --model-draft wikitext-2-raw_ik-llama-mtp_drafter-conservative/gemma-4-26B-A4B-it-assistant-Q8_0.gguf \ --spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune \ -cnv --color --jinja --special \ -sm graph -smgs -sas -mea 256 --split-mode-f32 \ --temp 0.7 -t 8 --parallel 8 \ --cpu-moe --merge-up-gate-experts \ --flash-attn on --mla-use 3 \ --mlock --run-time-repack --no-kv-offload 25 個參數，一半沒有文件說明，四分之一會靜默失敗。這就是作者所說的「可用性的護城河」（usability moat）——黑盒工具讓你看不見這些，但也讓你無法優化。 ...

前情提要 過去幾年，OpenAI 的旗艦模型（GPT-4o、GPT-5 系列、o1/o3 推理模型、Codex 程式生成模型）只能透過 OpenAI 自家 API 呼叫。不管你的公司用什麼雲端，只要想用 OpenAI 最強的模型，就得連到 api.openai.com。 現在，這個局面被打破了。 2026 年 6 月 1 日，OpenAI 正式宣布其 frontier models（包含 GPT-5、o3、Codex 等）以及 Codex CLI 開發工具，全面上架 AWS Marketplace。 這聽起來像是「又多了一個呼叫方式」，但實際上，這一步的意義遠比你想像的深。 這次上線了什麼？ 簡單來說，這次 AWS 上架的包含兩大塊： 1. OpenAI 模型作為 AWS Marketplace 產品 你可以在 AWS Marketplace 直接訂閱 OpenAI 的模型，然後透過 AWS 的 API Gateway、Bedrock 或直連方式呼叫。计费走 AWS 帳單，跟其他 AWS 服務（EC2、S3、Lambda）的帳單合在一起。 支援的模型包括： GPT-5 系列（包含不同尺寸與成本效能比的版本） o3 / o4 推理模型（高階邏輯推理、數學、程式生成） Codex 模型（專為程式碼生成與理解優化） 2. Codex CLI 工具 Codex CLI 是 OpenAI 推出的命令列開發助手，可以直接在終端機裡跟 AI 對話、生成程式碼、review PR。現在這個工具也可以透過 AWS 基礎設施運行，對已經深度使用 AWS 生態的開發者來說，整合度更高。 ...