Cloudflare 延攬 Ensemble AI 核心團隊，強化 Workers AI 推論效率
Cloudflare Blog · 2026-06-15
Cloudflare 宣布將 Ensemble AI 的核心成員納入旗下，以深化其 AI 推論基礎設施的技術厚度。Ensemble AI 成立於 2023 年，專注於在不犧牲模型品質的前提下，讓大型模型跑得更快、參數更少、部署成本更低。此次人才整合並非一般意義上的品牌收購，公告中 Cloudflare 聚焦在「讓這批工程師加入」這件事本身，而非取得任何現成產品。
背景
Ensemble AI 的核心研究圍繞著 transformer 推論的效率問題。他們開發出名為 NdLinear 的架構層，可以直接替換 transformer 中的標準 linear layer，差異在於它不會先把多維 activation 攤平成一維向量，而是在原始結構上直接運算。這樣做保留了空間或序列維度的內部結構，同時減少參數數量與計算量。
與此配套的是 NdLinear-LoRA，針對微調場景設計，同樣以更少的可訓練參數達到接近完整微調的效果。這兩項技術與量化（quantization）及向量量化（vector quantization）並用，形成一套從參數到記憶體都能壓縮的工具鏈。Ensemble AI 的立場是：模型效率不是可選的最佳化，而是讓 AI 應用得以大規模部署的先決條件。
核心改動
Cloudflare 將這批人才整合進負責 Workers AI 的工程團隊。Workers AI 是 Cloudflare 的無伺服器 GPU 推論平台，跑在全球分散的邊緣節點上。Cloudflare 明確指出推論成本是 AI 應用難以規模化的最大障礙之一，而 Ensemble AI 的技術正好針對這個瓶頸。現有的效率工具包括推論引擎 Infire 與張量壓縮工具 Unweight，新成員將在這個技術脈絡下繼續發展。
整合方向涵蓋多個工作負載類型：AI agent、多模態模型、個人化應用，以及微調服務。每一類都對 GPU 記憶體與延遲有不同的要求，而 NdLinear 類型的架構層能在模型設計階段就降低這些需求，而非只在部署層面做補救。這是在推論路徑的更上游進行干預。
影響範圍
對開發者而言，短期內最直接的影響是 Workers AI 上可用模型的參數效率提升，以及 GPU 利用率改善。從更長的時間軸來看，若 NdLinear 的方法被整合進 Cloudflare 自己訓練或託管的模型，相同的推論品質將能以更低的計算預算達成。Cloudflare 在 AI 基礎設施的佈局向來以邊緣推論為主軸，這次人才引進讓模型壓縮的能力內化成組織自身的工程資產，而非依賴外部供應商。
原始來源：Cloudflare Blog — Growing the Cloudflare AI team with talent from Ensemble AI
Visual Studio 2026 開放 Fluent 色彩 token 逐項自訂，不再需要安裝擴充功能
Microsoft Dev Blogs · 2026-06-15
Visual Studio 2026 版本 18.7 在選項頁面新增了一個介面，讓開發者可以直接搜尋並修改 Fluent 主題中的每一個色彩 token，無需手動編輯 JSON 或安裝第三方擴充。過去要微調 IDE 外觀，唯一的官方路徑是使用 Color Theme Designer 擴充，現在這個能力被直接嵌入設定頁面本身。
原本的問題
Visual Studio 在移往以 WinUI 為基礎的 Fluent 設計語言後，外觀由數百個具名色彩 token 構成，每個 token 負責 UI 中一個特定的視覺角色。問題在於這些 token 的清單從未有可互動的瀏覽介面——開發者要改某個顏色，必須先知道 token 叫什麼名字。最常被提到的需求之一，是希望分開設定分頁標籤和視窗標題列的顏色，讓它們與 shell chrome 有所區別，這在之前根本沒有原生支援。
另一個長期痛點是主題自訂跨越 IDE 重啟後的保存方式。既有的 JSON 覆寫機制需要重新啟動 Visual Studio 才能生效，且檔案命名與路徑並不直覺。開發者普遍反映，他們希望有類似 VS Code 的「Inspect Editor Tokens and Scopes」功能，可以點選畫面上的任何一個元素來查看它對應的 token 名稱。目前這項功能在 18.7 尚未實作，但已被微軟列入回饋追蹤項目。
採用的方法
新的選項頁面位於 Tools > Options > Environment > Visual Experience > Theme colors，呈現為一個可搜尋的格狀清單，列出當前主題下全部可用的 Fluent 色彩 token。修改會即時套用，不需重啟，且儲存範圍是個別主題，意味著切換到深色主題和淺色主題時各自帶有獨立的自訂設定。
若有分享或版本控制的需求，自訂資料儲存為 JSON 檔案，路徑在 %LOCALAPPDATA%\Microsoft\VisualStudio\18.0_xxxxxxxx\ColorThemes。檔案命名規則是 主題名稱.json，例如 cool-breeze.json 會覆寫名為 Cool Breeze 的主題設定，其他主題不受影響。透過 JSON 途徑套用的設定才需要重啟。
實際效果
此次更新也一併新增了數個先前缺少的 token，其中最受使用者關注的是分頁標籤與視窗標題列的獨立著色能力。微軟在公告中稱這讓使用者能打造「經典復古感」的外觀，這是對 Visual Studio 6 時代深色標題列懷舊需求的直接回應。
對於企業環境，統一的 JSON 格式也讓組織內標準化 IDE 外觀成為可能——只要透過部署腳本把 JSON 檔案分發到對應目錄即可，不需每台機器手動操作。整體而言，18.7 把一個過去需要查閱文件才能完成的任務，降低成了一個可以在選項面板中即時探索的互動行為。
原始來源：Microsoft Dev Blogs — Make Visual Studio look the way you want
Dropbox 用 MCP 與 Dash 銜接資安設計評審與程式碼實作之間的落差
dropbox.tech · 2026-06-12
Dropbox 的資安工程團隊發現一個系統性問題：威脅模型與安全設計評審文件在完成後，往往與實際的程式碼實作脫鉤——開發者提交 PR 時並不會主動回頭參照當初的安全要求。他們對內部資料做的分析顯示，只有 12% 的實作 PR 明確連結回原本的安全評審，而超過 54% 的程式碼在安全評審完成後超過一個月才被提交，中位數延遲約五週。這個時間差讓安全需求在設計與實作之間悄悄消失。
原本的問題
傳統的解法是在 PR review 流程中加入人工安全審查，但這在速度與覆蓋率上都有明顯上限。核心難點在於「語意連結」——安全評審文件用的是設計語言，PR 用的是程式碼語言，兩者之間沒有自然的索引關係，關鍵字搜尋幾乎找不到對應的文件。Dropbox 測試發現，在分析的 150 份安全設計評審中，69% 的關聯只能透過語意搜尋才能找到，無法用明確的關鍵字或文件連結方式重建。
換言之，即使組織擁有完整的威脅模型文件，若沒有能夠在程式碼提交時主動取用這些文件的機制，那些文件就只是靜態的存檔，對實際的安全把關毫無貢獻。這個問題在工程師換手、功能跨越多個 sprint 交付、或威脅模型在實作期間更新時會特別嚴重。
採用的方法
Dropbox 的解法結合了三個層次：Dash（Dropbox 的 AI 索引與跨系統內容連結平台）、MCP（Model Context Protocol，讓 AI agent 透過標準介面存取外部資料來源的協定）、以及大型語言模型作為比對引擎。具體流程是：當 PR 被提交時，agent 透過 Dash 的 MCP server 進行語意搜尋，找出與這次程式碼改動最相關的安全設計評審，再用 LLM 比對評審中列出的安全控制要求與 PR 實際的程式碼，標記出缺漏或矛盾之處。
系統設計上有幾個刻意的取捨。每一條發現都必須對應到實際的程式碼，不允許純文件面的推測。大多數發現以建議形式呈現，而非阻擋 PR 合併的硬性封鎖。這個選擇反映了一個判斷：若把 AI 產出的安全建議設計成合併擋門，開發者的第一反應往往是繞過它，而非認真對待它。此外系統也考慮了需求演進的情況，不會把六個月前的威脅模型當成不可更動的金科玉律來執行。
實際效果
在 150 份安全設計評審的驗證集上，語意搜尋成功將 80% 的設計評審連結到對應的實作程式碼。在測試過程中，系統找到了若干在沒有威脅模型脈絡下根本不會被發現的安全問題，包括遺漏的存取控制以及與設計規格相矛盾的實作行為。
Dropbox 也指出這個模式不限於資安應用。相同的架構可以讓隱私團隊在 PR 階段自動比對資料分類要求，讓平台團隊檢查 API 合約相容性，或讓法遵團隊追蹤跨司法管轄區的法規要求是否被實作。MCP 在這裡扮演的角色是降低接入成本——任何已經被 Dash 索引的文件，都能在不需要客製化整合的情況下被 AI agent 取用，這讓同一套機制可以橫向複製到不同的工程治理場景。
原始來源：dropbox.tech — How Dropbox uses MCP and Dash to close the design-to-code security gap