TechSeeker (繁體中文)

ThinkingBox 將資料庫狀態檢查用於代理 RL 訓練

Thu, 22 Oct 2026 23:55:55 GMT

微軟與 Hugging Face 已在 GitHub 公開 ThinkingBox-Training，提供代理後訓練所需的資料選擇、rollout 與獎勵流程。
訓練時，系統會檢查後端資料庫的最終狀態來評定結果；多數檢查採確定性測試，少部分需求由 LLM 評審。
Qwen3.8-27B 經過 50 步 GRPO 訓練後，pass@1 平均成功率從 51.70% 提高至 60.78%。
每次測試都成功的任務數從 38 增至 107，但至少成功一次的任務覆蓋率略為下降。
訓練使用基礎策略離線探測後選出的固定 187 項任務，並在未納入訓練的 ThinkingBox-Bench 507 項任務上評估，每項測試 20 次。

本站見解：要把這套方法用於自有代理，團隊必須為工作流程建立可執行的狀態檢查，並維護隔離的後端環境與訓練、評估共用的工具解析方式。文中的成本比較未計入訓練及任務探測費用，因此尚不足以判斷整套流程相較其他後訓練方式的總成本。

來源：

Turning Database Grading into RL Rewards: Post-Training Agents with ThinkingBox · Hugging Face Blog

本文摘要與見解由 AI 自動生成，事實以原文為準。

OpenAI Python SDK 擴充 Decisions 型別

Thu, 22 Oct 2026 23:55:03 GMT

Live response 的 question.instructions 現在可使用字串，或由文字、圖片與 JSON 組成的結構化內容。
Decisions 請求型別增加訊息角色與工具歷程項目；既有的字串 instructions 和 DecisionInputMessageParam 使用者訊息仍可使用。
此版本保留檔案與影片輪詢 helper，也維持上傳 helper 和 Live 連線的預設設定。

本站見解：從 v3.36.1 升級時，應先檢查 instructions 的型別，再呼叫字串專用操作，並更新對請求角色與工具歷程的完整型別比對。由於原有字串輸入仍受支援，遷移重點可放在解析和型別處理，而非全面改寫呼叫端。

來源：

openai-python v3.37.0 · OpenAI Python SDK Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

Amazon Polly 更新生成式語音引擎

Thu, 22 Oct 2026 23:54:45 GMT

Amazon Polly 生成式引擎升級後，語音更自然、富有表現力，並改善數字、地址等內容的朗讀準確度。
此次新增 14 個語音，涵蓋 9 個地區；Hindi 與 Finnish 生成式語音也首次正式推出。
升級後的目錄共有 57 個生成式語音，涵蓋 11 種語言與 25 個地區。
既有生成式語音可直接取得升級，API 呼叫與價格維持不變，應用程式不需修改程式碼。

本站見解：對已使用 Polly 生成式語音的團隊而言，維持原有 API 與價格可降低升級的整合成本。若工作流程需要 speech marks，生成式語音仍不適用；可繼續使用支援此功能的標準或 neural 語音。

來源：

Amazon Polly delivers a major upgrade to its Generative engine · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

SageMaker AI 推出可自訂的無伺服器訓練工作階段

Thu, 22 Oct 2026 23:54:07 GMT

SageMaker AI 的無伺服器模型客製化訓練工作階段已正式推出；使用者可自行撰寫訓練迴圈，AWS 則負責 GPU 配置、分散式執行、故障復原與 checkpoint 儲存。
功能支援 SFT、DPO、RLVR、RLAIF 與多輪 RL，並可選擇 LoRA 或完整微調，也能串接不同技術。
訓練迴圈與 reward function 在使用者環境執行；工作階段中的 sampler 產生回應，trainer 計算梯度並更新模型權重。
費用按 SageMaker AI 處理的 token 計算；reward function 在使用者環境評分期間會暫停計費，且不需預留容量。

本站見解：相較於 SageMaker AI 既有的受管理多輪 RL 技術，training sessions 讓團隊自行定義 loss 與 reward 邏輯，同時免去 GPU 叢集維運。文章未提供 token 價格，也沒有與自管 GPU 成本的比較，因此目前無法估算實際預算差異。

來源：

Announcing new ways to customize models with SageMaker AI, without managing GPUs · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

Amazon SageMaker AI 推出自訂訓練迴圈 API

Thu, 22 Oct 2026 23:53:28 GMT

Amazon SageMaker AI 的 training session API，讓開發者自行編寫訓練迴圈，並由服務管理 GPU 運算與相關基礎設施。
工作階段提供訓練與取樣操作；模型會留在 GPU 上，使用者可逐步呼叫 API，執行 SFT、偏好最佳化或強化學習。
開發者負責資料、迴圈控制與獎勵函式；GPU 操作按處理的 token 計費，執行本機獎勵計算時不會產生 GPU 費用。
隨 API 發布的 cookbook 提供 SFT 與強化學習範例，包括以競賽程式題目和單元測試評分的 Code RL 配方。

本站見解：相較於 SageMaker Training Jobs 或 HyperPod，這種方式減少了團隊自行維運 GPU 叢集的工作，但仍保留自訂演算法的控制權；相較於全代管的 Serverless Model Customization，則需要自行負責訓練迴圈與獎勵邏輯。實際成本是否較低，仍取決於 token 用量、模型與本機評分工作負載；文章未提供 API 的單位價格。

來源：

Write your own training loop — without managing GPUs — with Amazon SageMaker training session APIs · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

LangChain Core 1.7.0 調整工具呼叫串流參數

Thu, 22 Oct 2026 23:53:01 GMT

LangChain Core 1.7.0 將串流中的工具呼叫參數改以 `tool-call-delta` 片段傳送，而非 `block-delta` 快照。
從 `ChatModelStream.tool_calls` 逐筆讀取時，現在取得的是新增的參數片段，不是截至當下的完整快照。
`.tool_calls.get()` 與 `.output` 的行為維持不變；需要保留快照的使用者可固定在 1.7 以下版本。

本站見解：若應用程式會呈現或記錄尚未完成的工具參數，串流處理器必須能累積片段，才能重建目前狀態。相較於仰賴完整快照的做法，這會增加串流消費端的狀態管理工作；改用既有存取器則不受此變更影響。

來源：

langchain-core==1.7.0 · LangChain Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

以 Kokoro TTS 為 AI 代理串流語音

Thu, 22 Oct 2026 23:52:40 GMT

AWS 示範讓代理每完成一句話，就送往 SageMaker AI 上的 Kokoro-82M 合成語音，不必等整段回覆生成完畢。
範例以 SageMaker AI 即時端點提供單次請求與雙向串流兩種路徑；雙向連線可在同一工作階段處理多則訊息。
將音訊以 base64 放進 SSE 會增加約三分之一的傳輸量，且接收端須緩衝資料，避免切分位置落在 MP3 音訊框中間。
測試中，逐句輸入使 TTS 傳輸的首個音訊位元組平均等待時間改善 52.4%；完整代理案例的 bidi 模式也比 batch 模式更快。

本站見解：若現有前端已採用 SSE，base64 方案可沿用既有管線，但必須處理額外負載與音訊框重組。改用雙向二進位傳輸需要前端支援相應的連線與訊息處理；而 AgentCore 的 JSON 輸出限制仍使回傳給使用者的音訊需要 base64。

來源：

Stream low-latency speech from AI agents using Kokoro TTS on Amazon SageMaker AI · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

用 NVIDIA KvikIO 確認資料是否直達 GPU 記憶體

Thu, 22 Oct 2026 23:52:16 GMT

NVIDIA GPUDirect Storage（GDS）可讓支援的儲存裝置直接將資料送入 GPU 記憶體，省去經過主機記憶體中轉，並降低 CPU 使用量。
KvikIO 位於 cuFile 之上，提供 Python 與 C++ 介面；它可選擇呼叫 cuFile，或改走會經過主機記憶體的 POSIX 相容路徑。
使用 cuFile 不代表傳輸一定採用 GDS 加速路徑，因為 cuFile 會依系統支援、檔案系統與設定選擇實際路徑。
教學以 1 GiB 的 CuPy GPU 緩衝區讀取為例，並透過 cuFile 統計與 gds_stats 查看操作走 nvfs 或 posix 路徑。
KvikIO 與 cuFile 各自的設定會影響 I/O 請求的拆分與執行方式；教學也要求使用支援 GDS 的 Linux、GPU、儲存裝置與檔案系統組態。

本站見解：部署時，單看 KvikIO 讀取成功不足以判斷是否避開了主機記憶體中轉，這會影響 CPU 負載評估；應在目標儲存與 GPU 拓撲上檢查實際計數。KvikIO 改走 POSIX 路徑會略過 cuFile，而只要求 KvikIO 使用 cuFile 仍不能保證 GDS 生效，因此兩層設定都需驗證。文章未提供效能提升幅度，也未說明其他硬體與檔案系統組態的結果。

來源：

How to Read Data into GPU Memory in Python with NVIDIA GPUDirect Storage · NVIDIA Developer

本文摘要與見解由 AI 自動生成，事實以原文為準。

AWS 示範以實測資料設定 SageMaker AI 語音合成自動擴縮

Thu, 22 Oct 2026 23:51:41 GMT

AWS 在 Amazon SageMaker AI 即時端點以自訂容器部署 Kokoro-82M，並用兩項端點實測取代猜測式的自動擴縮設定。
方法先測出單一執行個體在符合延遲目標時可承受的併發量 Q_max，再測量新增容量開始服務健康流量所需的時間 T_total。
範例測得 Q_max 為 50，T_total 約為 320 秒；工具據此計算擴縮門檻與冷卻時間。
部署政策使用 SageMaker AI 發布的 ConcurrentRequestsPerModel 指標，並設有檢查，避免未經實測的設定啟用自動擴縮。

本站見解：相較於沿用為其他工作負載設計的推論設定，自訂容器讓團隊能加入佇列限制並依併發量調整容量，但也增加了容器與部署流程的維護責任。這次測量中，執行個體佈建和映像檔下載佔主要擴容時間，因此縮小映像檔或採用暖容量可能比優化合成程式碼更直接。範例還使用有已知安全公告的舊版 PyTorch，正式部署前應先檢視並更新相依套件。

來源：

Stop guessing auto scaling targets for TTS on Amazon SageMaker AI · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

NVIDIA 展示 8 節點 DGX Spark 叢集

Thu, 22 Oct 2026 23:50:43 GMT

8 台 DGX Spark 可提供 1 TB 統一記憶體，讓完整的 GLM 5.3 753B 模型能在本機載入。
在 4 節點 NVFP4 測試中，Spark 專用通訊後端的 prefill 吞吐量約增加 5%，decode 約增加 21%。
4 節點推論可採用直接環狀連線；若要擴至 8 節點或拆分叢集，則需要交換器。
Switchyard 將請求分流至不同模型，在測試中相較於僅使用 Qwen，整體吞吐量約可達 1.5 倍或 3 倍，取決於分流比例。
nanochat 從頭預訓練時，8 節點達到 7.79 倍加速與 97.4% 效率。

本站見解：RoCEnante 針對交換器連接、低併發的小訊息情境降低通訊延遲，但 NCCL 仍是預設選項，且更適合大型叢集與高併發負載。部署時可先依模型分片需求選擇環狀或交換器拓撲；若採用多模型分流，則需預留交換器連線與調整路由政策的工作。

來源：

Running Frontier-Class AI Models Across 8 NVIDIA DGX Spark Nodes · NVIDIA Developer

本文摘要與見解由 AI 自動生成，事實以原文為準。

OlmoEarth v1.3 提供全球衛星嵌入向量與互動式探索工具

Thu, 22 Oct 2026 19:00:48 GMT

OlmoEarth v1.3 發布時，同步提供全球預先計算的年度衛星嵌入向量，解析度為 10 公尺，並有 64 維與 128 維版本。
模型整合 Sentinel-1 雷達資料，以及 Sentinel-2 和 Landsat 多光譜衛星時間序列，為地球每個 10 公尺像素產生向量。
在涵蓋六大洲、共 27 項評估中，128 維版本有 20 項表現領先；64 維版本則有 18 項領先。
Embeddings Explorer 可用於比較不同年份、搜尋相似地點、以標記點訓練分類器，並匯出 GeoTIFF；目前 2023 至 2025 年資料涵蓋全球，2017 至 2022 年則涵蓋部分國家。

本站見解：相較於過去主要透過 OlmoEarth Studio 微調模型的流程，預先計算的嵌入向量讓團隊能先用小型分類器在本機測試想法，減少早期 GPU 與衛星影像處理需求。不過，年度資料約 150 TB，且歷史涵蓋範圍不完整；部署前仍應評估儲存與資料可用性，並在自己的區域和任務上驗證效果。

來源：

OlmoEarth v1.3: State-of-the-art embeddings for the whole planet · Hugging Face Blog

本文摘要與見解由 AI 自動生成，事實以原文為準。

ForTy 全球森林分類圖追蹤森林類型變化

Thu, 22 Oct 2026 19:00:23 GMT

Google DeepMind、Google Research、WRI 與 IIASA 發布 ForTy 2020，以 10 公尺網格標示全球土地的森林與土地利用類型。
ForTy 將土地分為六類，包括原始森林、自然再生森林、人工栽植森林、人工林、樹木作物與農林複合利用，以及其他土地。
配套的年度資料追蹤 2017 至 2025 年的變化，呈現自然森林轉為人工林或農地等情況。
相較於先前只標示 2020 年土地是否為自然森林的 Natural Forests of the World，ForTy 進一步區分森林類型並追蹤年度變化。

本站見解：對森林砍伐監測系統而言，這些分類可讓篩選流程區分樹木作物農地與人工林等不同轉變，而不只依賴樹木覆蓋與否。公告未提供準確度或地塊層級驗證資訊，因此不宜單憑地圖分類作為合規判定的確證。

來源：

Beyond tree cover: mapping the world’s forest types · Google DeepMind

本文摘要與見解由 AI 自動生成，事實以原文為準。

IBM Granite 推出四模型時間序列預測集成

Thu, 22 Oct 2026 08:12:14 GMT

Granite Timeseries Ensemble 預設整合四種預訓練 Granite 架構，可在不重新訓練或估算集成權重的情況下產生中位數與分位數預測。
使用者可選擇等權重的 Probabilistic Ensemble，或依預測區間寬度調整權重的 IQR Ensemble；後者會隨樣本、目標與預測步驟改變權重。
在 GIFT-Eval 的 97 組資料集設定中，兩種集成方法的整體 MASE 與平均 MASE 排名都優於四個個別成員；Probabilistic Ensemble 的 MASE 為 0.683，PatchTST-FM-r2 為 0.685。
此配方會在執行時下載四個模型檢查點，推論所需時間與記憶體會高於單一模型；目前各通道獨立預測，不利用通道間資訊。

本站見解：相較於單獨使用 PatchTST-FM-r2，預設集成在該基準的 MASE 僅略有改善，因此是否採用應看重跨序列的穩健性，而非期待大幅降低點預測誤差。部署前應以代表性資料回測，並衡量四個檢查點帶來的推論時間與記憶體成本。

來源：

Ensemble forecasting with IBM Granite time-series models · Hugging Face Blog

本文摘要與見解由 AI 自動生成，事實以原文為準。

OpenAI Python SDK 3.36.1 修正 WebSocket 與瀏覽器呼叫問題

Thu, 22 Oct 2026 08:11:35 GMT

OpenAI Python SDK 3.36.1 修正 API 行為，讓個別呼叫設定的 WebSocket 查詢參數能生效。
範例程式現在會在每次錄音結束後停止麥克風擷取。
瀏覽器呼叫會先完成驗證，再讀取驅動程式狀態。
這次更新釐清了服務帳戶 API 金鑰的刪除說明。
SDK 也開始準備手寫版的分塊上傳與 vector store 輪詢執行階段。

本站見解：若應用程式會依個別 WebSocket 呼叫設定查詢參數，從 3.36.0 升級可減少自行處理此行為的需求。發布說明未指出受影響的參數或執行條件，因此仍需在實際使用的連線情境中驗證。

來源：

openai-python v3.36.1 · OpenAI Python SDK Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

以 AWS PrivateLink 私下連接 Amazon Quick 與企業網路

Wed, 21 Oct 2026 23:56:04 GMT

Amazon Quick 將使用者連線與服務端取資料分開處理：前者透過 AWS PrivateLink VPC 端點，後者則使用 VPC connection。
VPC connection 會在指定 VPC 子網建立 ENI，讓 Quick 連線至可透過 Direct Connect 或 Site-to-Site VPN 到達的內部系統。
建立 VPC connection 需要 Quick Enterprise；管理者也必須準備 IAM execution role、位於不同可用區的至少兩個子網，以及安全群組。
Quick API VPC 端點不支援部分 action connector 與 flow API，因此以程式管理這些功能時，仍須保留通往公有 API 的路徑。

本站見解：這不是只建立單一端點就能完成的私有存取方案；團隊還要分別規劃用戶端入口與服務端 ENI 的網路、DNS 和安全群組。它也不等於完全隔離的部署：使用 IAM Identity Center 登入仍需對外連線，且部分 API 無法經由 API 端點使用。

來源：

Securing Quick access from corporate networks with AWS PrivateLink · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

Deep Insight：將多代理系統部署至正式環境

Wed, 21 Oct 2026 23:55:38 GMT

Deep Insight 是開源的資料分析多代理系統，使用者提供 CSV 與自然語言需求後，系統會產生分析結果及含引用的 DOCX 報告。
系統由八個分工代理組成，透過 Strands Agents SDK 的 Graph 流程安排工作，並由 Supervisor 按需呼叫專責代理。
分析開始前，Plan Reviewer 會讓使用者審核計畫並提出修改；驗證代理則會重新計算分析結果，供報告引用。
正式環境部署以 Amazon Bedrock AgentCore 搭配 AWS Fargate，為每個分析工作建立位於私有 VPC 的獨立程式碼執行容器。

本站見解：開發者可沿用相同的多代理架構從自架版本移至託管部署，但執行環境會從本機 subprocess 改為 AWS 上的隔離容器。這能降低直接執行模型生成程式碼的風險；部署成本與維運負擔則需依實際 AWS 配置評估，文章未提供相關數據。

來源：

5 production challenges in multi-agent systems and how Deep Insight solved them · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

LangChain 1.4.7 更新串流事件與追蹤功能

Wed, 21 Oct 2026 23:55:07 GMT

LangChain 1.4.7 加入串流消費端讀取 tool-call-delta 的支援。
LangChainTracer 現在可接受 address。
此版本更新了 certifi、aiohttp 與 mcp 等相依套件。

本站見解：對自行處理工具呼叫串流事件的整合，升級可能減少自訂事件轉換工作；但發布紀錄未說明支援哪些供應商或事件相容性。使用 LangChainTracer 的系統宜先驗證現有追蹤設定如何配置 address，因為紀錄未列出遷移要求。

來源：

langchain==1.4.7 · LangChain Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

Strands Agents 示範本機與雲端混合式代理架構

Wed, 21 Oct 2026 23:54:34 GMT

Adaptive Agentic Intelligence Framework（AAIF）以 Strands Agents 建立三層流程：本機 SLM 判斷請求類型，例行工作交由本機工具，複雜分析則送往 Amazon Bedrock。
IoT 範例使用 Ollama 模型在本機取得裝置遙測資料並分析攝影機影像；需要更廣脈絡與多步推理的工作，則由雲端工具處理。
此架構可用於 Raspberry Pi（8 GB 記憶體）、純雲端或混合式部署，且路由邏輯與處理工具能分開調整。
對完全隔離的環境，文章建議以較大的本機模型取代雲端工具；3B 模型可處理部分中等複雜任務，但最難問題的推理深度可能較低。

本站見解：相較於每項請求都送往 Amazon Bedrock，混合模式可把例行推論移至自管硬體；文章估計約八成流量不必呼叫付費 API，但沒有提供實測成本或延遲數據。採用這種方式也意味著要維運 Ollama 和本機模型；若改為全氣隙部署，則需接受最難請求的推理能力可能較弱。

來源：

Adaptive agentic intelligence framework using Strands Agents · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

在 AWS Trainium 上以 torchtitan 訓練 Qwen3

Wed, 21 Oct 2026 23:54:05 GMT

AWS 示範如何在單一 trn2.48xlarge 上，透過 torchtitan 和 TorchNeuron 訓練 Qwen3；Trainium 會以 PyTorch 裝置的形式提供給 torchtitan 使用。
範例涵蓋 Transformers v5 後端、torchtitan 原生 Qwen3 實作，以及採用 NKI 核心的 MoE 設定，三者沿用相同的啟動方式與設定結構。
使用者可以載入已發布的 Hugging Face 權重，並將訓練結果存為 safetensors；文章也提供自訂 NKI 核心的註冊與替換方式。
自訂核心的範例以數值比對確認輸出一致，但文章指出這是核心整合示範，並未展示效能提升。

本站見解：這讓熟悉 torchtitan 的團隊能在 Transformers v5 與原生模型實作之間選擇，而不必改用不同的啟動流程；保留 Hugging Face 權重格式也有助於沿用既有檢查點。若要評估 Trainium 是否帶來實際速度或成本優勢，仍需自行量測，這篇文章沒有提供效能比較。

來源：

Train Qwen3 on AWS Trainium with torchtitan · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

LangChain Perplexity 1.4.2 修正 Agent API 搜尋結果處理

Wed, 21 Oct 2026 23:53:41 GMT

此版更新模型設定檔資料。
修正 Perplexity Agent API 搜尋結果的保留處理。
Responses API 的快取 token 會映射至 `input_token_details`。
串流期間，`search_context_size` 只會輸出一次。
此版也更新多項相依套件，並修正部分合作夥伴套件的相依性。

本站見解：使用 Perplexity Agent API 的程式可檢查是否能移除自行保留搜尋結果或補齊快取 token 資訊的處理；依賴串流事件數量的程式也應驗證解析邏輯。發布說明未交代相容性變更，或模型設定檔更新是否影響模型選擇，仍需以應用程式的測試確認。

來源：

langchain-perplexity==1.4.2 · LangChain Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

Ollama v0.40.8 加入 Flint 程式碼模型

Wed, 21 Oct 2026 23:53:17 GMT

Ollama v0.40.8 新增 Recursive 的 Flint 程式碼模型，可透過 Ollama 執行。
Flint 支援推理與多輪工具操作，並提供 262K token 的上下文視窗。
這款採用 Apache 2.0 授權的 MoE 模型共有 40B 個參數，每個 token 約啟用 2.5B 個參數。

本站見解：目前 Flint 僅支援 macOS，非 Mac GPU 的部署仍須等待後續版本。團隊若要將它用於程式碼代理工作流程，現在需要先確認 Mac 環境是否符合部署需求；其他 GPU 支援的時間與條件尚未公布。

來源：

ollama v0.40.8 · Ollama Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

GitHub 以逐 reference quorum 擴充 Git 儲存架構

Wed, 21 Oct 2026 23:53:01 GMT

GitHub 多數儲存庫已有五個副本中的兩個存放在 Azure，Azure 目前處理約一半的 Git 流量。
GitHub 將寫入 quorum 的序列化範圍從整個儲存庫縮小到個別 reference；內部測試顯示，不同 reference 的寫入吞吐量提高 3–4 倍，延遲也較低。
GitHub 把 Azure Blob Storage 納入 quorum，並以 virtual write replica 傳送寫入；只有資料已持久儲存後，寫入才會獲得確認。
GitHub 可按需增加不加入 quorum 的 virtual read replicas，讓它們從 Azure Blob Storage 載入快取並在背景同步狀態。

本站見解：對多個 agent 或開發者各自推送不同分支的工作負載，逐 reference 排序可避開舊有的整個儲存庫寫入鎖；若寫入集中在同一 reference，彼此仍須等待。讀取副本脫離 quorum 後可獨立擴充，但背景同步目前不適用所有讀取類型，完整支援仍需在讀取時追補差異。寫入擴充的瓶頸仍是 quorum，後續還需處理排序與耐久 reference state 等問題。

來源：

The bridge to agent-scale Git infrastructure · GitHub Blog

本文摘要與見解由 AI 自動生成，事實以原文為準。

OpenAI Python SDK 3.36.0 加入 Vertex AI 支援

Wed, 21 Oct 2026 23:52:25 GMT

3.36.0 版讓 Python SDK 的 Responses API 可搭配 Vertex AI 使用。
SDK 新增 30 分鐘區間的快取寫入用量計數。
API 現在會提供 compaction 流程的觸發識別碼。
版本新增自訂語音的同意管理功能。
WebSocket 修正涵蓋連線設定清理、復原中斷與原生選項處理。

本站見解：對已採用 OpenAI Python SDK 的團隊而言，這項更新提供了透過 Vertex AI 部署 Responses API 的路徑。發布說明未交代端點設定方式或功能涵蓋範圍，遷移前仍需確認實際相容性。

來源：

openai-python v3.36.0 · OpenAI Python SDK Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

NVIDIA 推出免訓練的關聯式資料預測模型

Wed, 21 Oct 2026 19:06:25 GMT

NVIDIA 推出 Kumo Relational，可直接對關聯式資料庫執行預測查詢，不必為每項任務另行訓練模型或手動設計特徵。
模型推論時可取用最多 10,000 筆歷史範例作為上下文，並保留資料表之間的關聯，不需先攤平成單一表格。
作者在涵蓋 41 項任務、15 個資料庫的評測中表示，模型勝過監督式關聯模型與專家設計的梯度提升樹流程。
在 SAP SALT 企業基準測試中，Kumo Relational 的 MRR 比 AutoGluon 集成模型高 8%。
模型可透過 NVIDIA 的開源 GPU 原生結構化資料模型函式庫執行，也可部署為 NVIDIA NIM。

本站見解：對維護 XGBoost 預測流程的團隊而言，這種做法可能把部分工作從逐任務設計特徵，轉為資料表與 PQL 查詢整合；但現有結果無法說明特定資料庫上的整體服務成本。程式碼採 Apache 2.0，權重則採 OpenMDW 1.1，封裝或散布部署前應分別確認權重授權條款。

來源：

NVIDIA Kumo Relational Outperforms Supervised Machine Learning on Relational Data, No Training Required · Hugging Face Blog

本文摘要與見解由 AI 自動生成，事實以原文為準。

VocabX 以領域化詞彙降低推論成本

Wed, 21 Oct 2026 19:05:33 GMT

Dharma AI 將 VocabX 用於葡萄牙文作文評分，保留 Qwen3-4B 基礎模型及原有資料與訓練流程，改為領域專用詞彙。
VocabX 同時調整子詞切分並加入短語巨集 token，依提示、輸入與輸出位置的推論成本挑選詞彙，而非只看出現頻率。
在 RTX 5090 與 vLLM 上測試 500 筆請求，平均回覆長度由 350 個 token 降至 101 個，測得成本減少 77%，評分指標則由 0.703 升至 0.810。
在五種公開領域與三個模型家族的 15 組比較中，VocabX 的裁減版本估算推論成本皆優於受測參考方法。

本站見解：與 FVT、MWT 和 in-place BPE 相比，VocabX 把輸出 token 的成本權重納入選擇，並同時處理子詞與重複片段，讓部署團隊能針對生成負載最佳化。巨集 token 若把評分等關鍵決策與格式綁在一起，可能損害品質；實際採用仍須驗證 tokenizer 與模型的搭配及任務表現。

來源：

How Specializing the Vocabulary of SLMs Can Cut Inference Cost by 77% in Real Applications · Hugging Face Blog

本文摘要與見解由 AI 自動生成，事實以原文為準。

IBM 更新 Granite Speech 語音模型系列

Wed, 21 Oct 2026 19:05:03 GMT

IBM 為 Granite Speech 系列新增 granite-speech-5.0-2b，並更新 granite-speech-5.0-470m-turboctc 與 granite-speech-4.1-2b-plus。
granite-speech-5.0-2b 可轉錄英、法、德、西、葡、日語，並支援這些語言與英文互譯；此外也能將英文譯為義大利文與中文。
新版 Turbo CTC 維持 470M 參數規模，加入多語轉錄及原生標點和大小寫處理；在 Open ASR Leaderboard 上達到 19,870 RTFx。
granite-speech-4.1-2b-plus 保留原有架構、提示格式與 API；更新後長篇語音測試的 WER 降低 24%，使用 20 詞關鍵字清單時，相關錯誤下降 45%。

本站見解：已採用 granite-speech-4.1-2b-plus 的團隊可在不改動既有 API 整合的情況下評估新版權重，導入負擔相對有限。相較之下，來源未說明 granite-speech-5.0-2b 是否與舊版 API 相容，替換前仍應確認提示格式與執行環境。

來源：

Granite Speech 5.0: Transcribe, Translate, and Attribute more Accurately and Faster · Hugging Face Blog

本文摘要與見解由 AI 自動生成，事實以原文為準。

NVIDIA Kumo Forecast 結合時序預測與歷史資料檢索

Wed, 21 Oct 2026 14:21:42 GMT

Kumo Forecast 使用 MOMENT-1-large 產生時序表示，再由預測頭轉換成指定預測期的數值。
DARR 會從歷史資料中以近鄰方式擷取相關型態，並將檢索資訊與模型的直接預測結合。
程式庫提供以 DataFrame 為主的介面；啟用 DARR 時，歷史情境資料可透過獨立的 context_df 傳入。
解釋功能可提供各預測期的落後值與特徵歸因等資訊，並搭配預測結果輸出。
Kumo Forecast 採用 Apache 2.0 授權。

本站見解：相較於只使用直接預測，DARR 多了一條歷史資料檢索路徑，因此部署端需準備獨立的 context_df，並確認其維度符合輸入情境。要判斷檢索是否有幫助，可在相同的保留資料窗與目標預測期上比較兩種設定；來源未提供通用的準確度或執行成本數據。

來源：

NVIDIA Kumo Forecast Combines Pretrained Time-Series Representations with Historical Pattern Retrieval and Interpretability · Hugging Face Blog

本文摘要與見解由 AI 自動生成，事實以原文為準。

NVIDIA Sentry 將 AI 代理防護延伸至硬體隔離層

Wed, 21 Oct 2026 14:20:35 GMT

NVIDIA Sentry 是 NVIDIA OpenShell 參考架構的一部分，使用 BlueField-4 在主機之外監控 AI 代理，並管控代理對模型、工具與資料的存取。
DOCA Flow 在 BlueField-4 上限制代理的網路目的地；通過的流量再交由 DOCA Tower 檢查應用層內容與授權。
DOCA Argus 不需在主機安裝代理程式，即可透過記憶體檢視取得執行環境資訊，並追蹤程序與系統資源之間的關係。
Sentry 可結合 DOCA Tower 的網路資訊與 DOCA Argus 的執行環境脈絡來評估存取要求，並保存具竄改可察覺性的活動紀錄。

本站見解：相較於 OpenShell 在軟體執行環境中隔離代理，Sentry 把監控與執行政策移至 BlueField-4 的獨立信任領域；若主機端防護遭突破，仍可保有一層控制。這種設計也讓部署依賴 BlueField-4，並需要將既有政策與身分系統接入 Sentry；來源未提供硬體成本或導入工作量，尚無法判斷其實際營運負擔。

來源：

Inside NVIDIA Sentry: Secure AI Agents at Runtime · NVIDIA Developer

本文摘要與見解由 AI 自動生成，事實以原文為準。

NVIDIA OpenShell：在代理執行環境中落實安全與治理

Wed, 21 Oct 2026 14:20:03 GMT

NVIDIA OpenShell 是開源執行環境，透過基礎設施限制 AI 代理可存取的系統與資料，並在執行期間將代理工作負載視為不受信任。
OpenShell 由 Gateway、Supervisor、Sandbox 和 policy prover 組成，分別管理沙箱與政策、檢查對外請求、隔離工作負載，以及驗證權限是否符合組織設定的上限。
管理者可用 Supervisor middleware 檢查、封鎖或修改網路內容，也能透過 Gateway interceptors 加入部署專屬治理，而不必修改 Gateway。
參考架構以 Vera CPU 執行 OpenShell；若需額外防護，BlueField-4 與 NVIDIA Sentry 可在代理之外監控行為並以硬體執行政策。

本站見解：對沿用 x86 的團隊而言，文章所列 Vera 效能數據尚未提供測試配置或獨立驗證，不能直接換算成所需伺服器容量。OpenShell 提供政策執行點，但身分、授權、資料保護與稽核仍須由組織整合既有系統。

來源：

How NVIDIA OpenShell Reference Architecture Secures and Governs AI Agent Workloads at Scale · NVIDIA Developer

本文摘要與見解由 AI 自動生成，事實以原文為準。

LiteLLM v1.103.7 修正計費追蹤並提供映像簽章驗證

Wed, 21 Oct 2026 14:19:03 GMT

LiteLLM v1.103.7 的 Docker 映像可透過 cosign 驗證，文件提供以固定 commit 或發行標籤取得公鑰的方式。
此版本將 Bedrock Mantle 的 count_tokens 備援修正回補至 1.103.x 穩定分支。
Proxy 的 spend tracking 修正也回補至 1.103.x。
批次功能則回補了成本計算、定價與翻譯相關修正。

本站見解：部署流程可加入 cosign 驗證，並以固定 commit 取得公鑰，降低對標籤保護機制的依賴。從 v1.103.6 升級時，建議回歸測試批次費用與 Proxy 支出追蹤；發行說明未列出受影響的具體情境。

來源：

litellm v1.103.7 · LiteLLM Releases
litellm v1.105.3 · LiteLLM Releases
litellm v1.106.2 · LiteLLM Releases
litellm v1.107.0 · LiteLLM Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

NVIDIA 展示代理輔助的 AI 工廠數位孿生流程

Wed, 21 Oct 2026 14:18:32 GMT

NVIDIA Omniverse DSX Blueprint 以 OpenUSD 和 Omniverse 程式庫為基礎，提供建立 AI 工廠數位孿生所需的參考資產與工作流程。
示範流程將場址資料、工程文件和設備資訊整合成可編輯的園區模型，供團隊檢視配置並準備工程審查。
代理可透過工具連接建模與分析操作，協助組合或修改場景；工程師仍須檢查尺寸、假設及模擬所需資料。
SimReady 規格可用來檢查資產是否具備特定分析所需的幾何、屬性與連接資料；SimReady Central Library 提供超過 2,000 個 OpenUSD 資產。

本站見解：對已使用 CATIA Magic 或 Windchill 的團隊，代理工作流程的實用性取決於需求和 CAD 資料能否透過支援的介面供工具存取；缺少這些連接時，場景仍可能無法追溯到工程依據。將修改保存在獨立 USD 圖層，可讓團隊檢視與迭代新設計，而不直接改動原始資產。

來源：

Developing an AI Factory Digital Twin with an Agent-Assisted Workflow · NVIDIA Developer

本文摘要與見解由 AI 自動生成，事實以原文為準。

Pydantic AI 2.59.0 修補 web_fetch 安全問題並擴充代理功能

Wed, 21 Oct 2026 06:52:22 GMT

Pydantic AI 2.59.0 修補一項高風險問題：web_fetch_tool 處理含大量元素的攻擊者控制 HTML 時，可能拖慢同一個程序中的其他工作；v1.107.9 也包含修補。
新增 DaytonaSandbox，讓工作區可在 Daytona 沙箱中使用 Coder、Shell、FileSystem 及其他 harness 能力。
新增 ElevenLabsRealtimeModel，支援 Eleven Realtime 語音轉語音模型。
新增跨供應商的模型錯誤類別，並讓 TemporalDurability 可設定哪些類別不應觸發重試。
SummarizingCompaction 現在會跳脫摘要器的對話紀錄，避免工具輸出偽造訊息。

本站見解：若工作流程會透過 web_fetch 讀取不可信 HTML，從 v2.58.0 升級有直接的安全理由；仍使用 v1 系列的團隊也可採用 v1.107.9。公告未說明觸發延遲的元素數量門檻，也未提供效能數據，因此應以實際抓取內容驗證風險，不宜將此修補視為普遍的延遲改善。

來源：

pydantic-ai v2.59.0 (2026-10-20) · Pydantic AI Releases
pydantic-ai v1.107.9 (2026-10-20) · Pydantic AI Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

Anthropic Python SDK v1.17.0 更新 API 與用戶端標頭處理

Wed, 21 Oct 2026 06:51:38 GMT

此版本為 API 新增組織 webhook 端點，以及使用者個人資料強制執行事件。
Admin API 新增 RBAC Group 擁有者存取錯誤碼，並補充 plugin uploads 的 unsupported_charset 錯誤碼文件。
Bedrock 與 Mantle 用戶端會保留 default_headers 中的 workspace ID。
Google Cloud 用戶端會保留 default_headers 中的 workspace ID 與 user profile ID。

本站見解：對使用 Bedrock、Mantle 或 Google Cloud 用戶端的整合而言，保留這些標頭中的識別資訊，有助於請求持續帶有 workspace 或使用者個人資料脈絡。發布說明未交代自訂標頭是否受影響，也未說明是否需要調整既有整合。

來源：

anthropic-sdk-python v1.17.0 · Anthropic Python SDK Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

i14 在 AWS Trainium2 訓練與部署線性注意力模型

Wed, 21 Oct 2026 06:51:14 GMT

i14 的 Laplace 3B 使用 Gated Linear Attention，讓每個序列的循環狀態固定為 29.5 MB，不隨上下文長度增加。
i14 與 AWS 將 GLA 實作改為標準 PyTorch 運算，透過 TorchNeuron Native 在 Trainium2 上執行，並保留 GLA 架構與 Muon optimizer。
在單一 trn2.48xlarge 上，Laplace 3B 訓練吞吐量約為每秒 120,000 個 token，並維持至第 84,210 步。
使用未修改的 vLLM 引擎時，單一 trn2.48xlarge 可在 1,280 個並行序列下，達到每秒 11,544 個輸出 token。

本站見解：相較於 softmax attention 模型會隨上下文累積 KV cache，Laplace 3B 的固定狀態可讓長上下文服務的記憶體用量較容易預估；但壓縮歷史可能影響檢索品質，仍須依工作負載驗證。部署也需要 Trainium2 與 TorchNeuron Native 的支援，且文中數據來自單一 trn2.48xlarge，尚不能據此判斷與 GPU 部署的成本或效能差異。

來源：

Beyond the KV cache: Training and serving i14’s Laplace 3B linear attention model on AWS Trainium2 with native PyTorch · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

LiteLLM v1.106.1 修正多項代理與向量儲存問題

Wed, 21 Oct 2026 06:50:17 GMT

LiteLLM 修正 Anthropic 多輪請求中 signed thinking blocks 和 `thinking.block_binding` 遺失的問題。
使用 gpt-5.4+ 模型時，Chat completions 的工具呼叫錯誤出現在 `choices[1]`，此版已修正。
團隊金鑰使用者取回、取消或下載自己的批次作業時遭遇 403 的問題已排除。
此版修正向量儲存庫更新中繼資料時的 HTTP 400；升級前建立的儲存庫還須執行 `db_scripts/strip_vector_store_internal_metadata.py`。
Token 計數問題涵蓋 PDF、system prompts 與工具；Google `countTokens` 請求遭拒的狀況也已修正。

本站見解：這次升級除了更新 LiteLLM，也需要安排既有 vector stores 的修復作業。發布說明未交代腳本是否需要停機或如何回復，部署前宜先在測試環境驗證並確認維護窗口。

來源：

litellm v1.106.1 · LiteLLM Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

NVIDIA 推出以臨床手術資料訓練的生成式模擬器

Wed, 21 Oct 2026 06:49:33 GMT

Cosmos3-H-Dreams 使用 CMR Surgical Versius 平台的臨床膽囊切除手術影片與機器人運動資料進行訓練，並支援即時動作控制。
模型根據器械動作生成手術場景，目標是呈現組織形變、遮蔽與反射等變化，同時維持解剖結構和器械外觀的一致性。
系統提供四步與兩步去噪的模型檢查點；較少去噪步驟可加快推論，但視覺品質較低。
這是供研究使用的模擬器，並非經驗證可用於病患照護的系統；研究方向包括外科醫師評估及結合數值模擬。

本站見解：相較於明確建模幾何與組織力學的數值模擬，這種方法直接學習視覺動態，但逼真的畫面本身不能證明生物力學正確。要移植到其他資料集或控制器，團隊仍須提供同步影片與動作資料，並對齊訓練時的動作慣例和正規化方式。

來源：

NVIDIA Cosmos3-H-Dreams: Bringing Clinical Surgery to Life Through Generative Simulation · Hugging Face Blog

本文摘要與見解由 AI 自動生成，事實以原文為準。

Smartsheet MCP Server 串接 Amazon Quick 與 Kiro

Wed, 21 Oct 2026 06:48:57 GMT

Smartsheet MCP Server 已正式推出，透過 MCP 提供 40 多項工具，可讀取、建立及管理工作表、資料列、欄位與自動化流程。
Amazon Quick 可讓使用者以自然語言查詢或更新 Smartsheet；Kiro 則能在程式開發流程中引用專案資料，並透過 hook 更新任務狀態。
伺服器提供包含資料列關係、欄位類型、儲存格歷史與留言的結構化內容，避免直接回傳原始 API 資料。
驗證方式支援 OAuth 2.0 或個人存取權杖；代理程式遵循使用者在 Smartsheet 的資料權限，管理員也能控管 AI 功能及寫入權限。

本站見解：若要在組織內統一提供存取，Amazon Quick 的預建連接器與 OAuth 流程可減少個別開發者設定；Kiro 則把連線放在 IDE 工作區，需處理設定檔與權杖。文章提到結構化內容可降低成本與延遲，但沒有提供量化數據，部署前仍需自行驗證效益。

來源：

Work management context for AI agents with Smartsheet MCP on AWS · AWS Machine Learning
Workflow context for AI agents with Smartsheet MCP on AWS · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

Anthropic Python SDK v1.16.0 更新

Wed, 21 Oct 2026 06:48:17 GMT

Analytics 報表分頁新增資料更新時間與是否還有更多結果的欄位。
Admin API 新增工作區速率限制更新功能。
User Profiles 已正式推出。
Python 用戶端現在會傳遞名稱未識別的伺服器傳送事件。
Google Cloud 整合改用 v1 端點，並新增組織端點。

本站見解：傳遞未識別的伺服器傳送事件，可降低應用程式因新增事件名稱而必須等待 SDK 更新的依賴；不過，應用程式仍需決定如何處理不認識的事件。此次更新也調整了多項 API 與 Google Cloud 整合，但來源未說明相關變更是否需要使用者修改程式碼。

來源：

anthropic-sdk-python v1.16.0 · Anthropic Python SDK Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。

Amazon Bedrock 在加拿大開放 OpenAI GPT 模型跨區域推論

Wed, 21 Oct 2026 06:47:48 GMT

加拿大中部與加拿大西部（卡加利）區域可透過 Amazon Bedrock 跨區域推論使用 OpenAI GPT-5.6、GPT-6 與 GPT-6.1 模型。
這些模型可透過 OpenAI Responses API、Chat Completions API，以及 Amazon Bedrock Converse API 呼叫。
US geographic inference profile 將請求路由至加拿大與美國；global profile 則可使用模型部署所在的支援商業 AWS 區域。
Bedrock 會自動快取符合條件且至少 1,024 tokens 的提示前綴；後續讀取快取 tokens 可享折扣，且不計入 tokens-per-minute 配額。

本站見解：選擇 US geographic 或 global profile，會影響請求可處理的區域範圍與可用容量；對區域限制較嚴格的工作負載，前者較符合需求。採用跨區域推論時，資料靜態保存於來源區域，但標記為濫用的內容可能在目的區域保留最多 30 天，部署前應納入合規評估。

來源：

Access OpenAI GPT models on Amazon Bedrock from Canada with cross-Region inference · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

AWS Agent Registry 支援代理程式執行時探索工具

Wed, 21 Oct 2026 06:47:12 GMT

AWS Agent Registry 是受管目錄，可註冊並搜尋 MCP 伺服器、代理程式與代理技能。
執行時，協調器可搜尋已核准的紀錄，並依 MCP 或 A2A 描述資料建立用戶端；搜尋結果不含呼叫能力所需的憑證。
範例透過 Amazon Bedrock AgentCore Gateway 提供 MCP 伺服器，並在 AgentCore runtime 執行協調器與兩個 A2A 代理程式。
手動核准設定下，紀錄須依序經過 DRAFT、PENDING_APPROVAL、APPROVED；只有核准紀錄能透過 Registry 資料平面探索。

本站見解：相較於把工具寫死在協調器中，執行時探索可讓相容且已核准的新紀錄不必搭配工具專屬程式碼變更發布。不過，這種做法也增加搜尋、審核及個別能力驗證身分的整合工作；固定流程或規模小且穩定的目錄，仍可能適合明確連接工具。

來源：

Discover tools at runtime with AWS Agent Registry · AWS Machine Learning

本文摘要與見解由 AI 自動生成，事實以原文為準。

DeepSpeed v0.19.8 擴充 AutoTP、AutoEP 與加速器支援

Wed, 21 Oct 2026 06:46:28 GMT

DeepSpeed v0.19.8 為 AutoTP 加入詞彙平行 LM head 與 Embedding，並強化 tied model 和 row-parallel output head 訓練支援。
AutoEP 新增跨 MoE layers 共用 DeepEP buffer、選擇性區域編譯與融合運算等功能，也調整 checkpoint placement 和 dispatch replay。
此版本為 NPU 加入 graph operations、FusedLion、FusedLamb 與 Quantizer 運算，並新增 KLXPU 加速器。
DeepSpeed 移除 elastic training、Progressive Layer Dropping 與 graph harvesting，並將 APEX amp 列為棄用功能。

本站見解：若工作流程仰賴已移除的功能，升級前需先調整訓練設定或評估是否暫留舊版；APEX amp 也應納入後續遷移規劃。發布說明沒有指出這些功能的替代方案，因此具體遷移方式仍待確認。

來源：

DeepSpeed v0.19.8 Patch Release · DeepSpeed Releases

本文摘要與見解由 AI 自動生成，事實以原文為準。