過去三天的新消息同時出現了 763B 參數的開源模型、可在 CPU 上執行的時間序列模型，以及量測本地硬體速度的工具。另一組研究則把注意力放到 agent 讀取網頁時會接收哪些內容。模型分數、硬體規格與工具鏈，正在一起決定「能不能用」的實際答案。

🔥 DeepSeek-V4.1-Flash-1017 以 MIT 授權放出 763B 參數模型

DeepSeek 在 Hugging Face 發布 DeepSeek-V4.1-Flash-1017 模型權重，模型卡標示參數量為 763B，提供 BF16、F32、FP8 與 INT8 檔案，採 MIT License。頁面提供 Transformers、vLLM、SGLang 與 Docker Model Runner 的載入範例，也連結到 DeepSeek 的技術報告與 Rust/Python 的 deepseek-recipe。

模型卡列出的 context window 是 1M tokens，建議 max_tokens 至少 256K。與上一版 DeepSeek-V4.1-Flash 相比，Terminal-Bench 4.0 從 31.2 提升到 42.3，DeepSWE v1.1 從 74.2 提升到 77.0，Automation-Bench v1.0.6 從 54.8 提升到 60.5；同一表格中，Claude Opus 5 在這些項目分別是 51.8、74.0 與 50.3。這些分數使用指定 harness，其中 Terminal-Bench 採 Claude Code harness，不能直接當作所有部署方式的模型比較。

模型卡沒有提供單一硬體的完整推理成本與吞吐量，也標示目前沒有 Inference Provider 提供代管服務。使用者需要自行處理權重轉換、GPU 記憶體與 prompt encoding；官方提供的程式碼負責格式轉換與解析，模型推理、工具執行和 HTTP transport 仍由呼叫端處理。

Timestral 以最高 209M 參數在 CPU 上做時間序列預測

Mistral 發布 Timestral 時間序列 foundation model，共有 5M、28M、123M 與 209M 四種規模，支援多變量機率預測、過去資料與已知未來 covariates，context length 為 32,768 個時間步。模型採 Modified MIT 授權，GitHub repository 已公開，官方表示可部署在本機、VPC 或 air-gapped 環境。

Mistral 表示，209M 版本在 GIFT-Eval、TIME 與 fev-bench 的公開排行榜中，單一 checkpoint、未使用 ensemble 的結果位列第一；28M 版本在部分測試勝過約四倍參數量的 Chronos-2。官方尚未發布完整技術報告，排行榜結果目前主要來自 Mistral 提交的模型與評測設定。

官方測試中，標準伺服器使用 8 執行緒 CPU，從三週的 15 分鐘資料預測一天，5M 版本約需 10 毫秒，209M 版本約需 140 毫秒。Mistral 也提供透過 Forge 使用私有資料微調的方案，但公告提醒生產資料可能隨市場、設備或需求變化而漂移；公開 benchmark 並未直接對應各產業的錯誤成本。

HTTP header 的 agent 注入在 2.17 億筆回應中被找到 30 個案例

Signals Corps 掃描 Common Crawl 2026 年 9 月資料中的 217,097,223 個網頁回應，這是該次 crawl 約 10% 的樣本。研究找到 7,959 個網站送出面向 AI 系統的 header，其中 7,271 個是指向 llms.txt、MCP 或其他 agent 資源的指標，30 個包含試圖下指令的文字；30 個中有 22 個被研究方歸類為惡作劇。

header 是否能影響模型，取決於 fetch 工具是否把 header 傳入上下文。研究列出的路徑包括 curl -i、錯誤回應處理、會回傳 metadata 的摘要工具與部分 MCP fetch server；只傳遞 body 的工具則不會把 header 交給模型。Signals Corps 在自建測試中發現，Claude Opus、Sonnet 與 Haiku 在一般提示下沒有執行測試 header 的指令，但當使用者提示明確授予網站指示權限時，9 次測試中有 7 次遵從。

研究也記錄 139 個網站會辨識 AI client，其中 136 個僅以 Common Crawl 的 user-agent 判斷。文章指出，伺服器能依 user-agent 或 Accept header 對 agent 傳回與人類瀏覽器不同的內容；這種差異不需要模型執行指令，仍可能影響 agent 讀到的資料。研究建議 fetch 工具預設只傳 body、對網頁建議執行的命令要求額外核准，並記錄 fetch 後是否立即發生新的 shell 或網路動作。

llmspeed 把本地模型速度估算按硬體與模型分開列出

開源專案 llmspeed.dev 提供本地 LLM 的硬體與模型瀏覽器，列出 RTX 3090、RTX 5090、Radeon、Mac Studio、CPU-only、H100 等裝置，也列出 Qwen、GLM、Gemma、DeepSeek、GPT-OSS 等模型組合。頁面可依硬體或模型查看估算速度，目標是在購買硬體前先比較短提示下的體感速度。

網站說明，數據有些來自 r/LocalLLaMA、localscore.ai 等社群 benchmark，有些則依相近設定推導或從規格估算；因此頁面上的數字不是所有硬體與模型組合都實測。專案原始碼已放在 GitHub，模型頁面也列出 DeepSeek V4 Flash 與 DeepSeek V4.1 Flash 等項目。

這類工具呈現的是估算值與社群測量的集合，實際吞吐量仍會受量化格式、context 長度、記憶體頻寬、推理框架與 batch 設定影響。網站的硬體清單包含尚未普遍取得的裝置，不能把列表中的每個組合視為現成可購買或已驗證的配置。

OpenAI 公開的數學結果在部分領域比例偏低，獨立分析未判定原因

數學研究者 Daniel Paleka 分析 OpenAI 近期公開的 700 多項數學結果，將其主題與 arXiv 的 theorem 分布比較。他寫道，OpenAI 結果中屬於統計、機器學習理論、最佳化與數值分析的比例低於 1%，而這些領域約占其採用的 arXiv theorem 基準 20%。即使只比較解決公開問題的論文，差距仍存在，但文章沒有把它歸結為單一原因。

Paleka 列出幾種可能解釋，包括相關領域的公開問題分布不同、團隊對問題庫熟悉程度不同，以及研究室可能不公開具有商業優勢的結果。文章也指出，OpenAI 公開結果中唯一讓作者認為與自己 2020 至 2021 年研究方向直接相關的項目，是在假設 P 不等於 NP 下證明 Max-Cut 近似界限；作者把它描述為另一個複雜度理論結果的推論。

這是一篇對公開資料的二次分析，不是 OpenAI 對未公開研究方向的說明。文章的比例取決於 OpenAI 公開清單、arXiv 分類方式與基準選擇；它能指出公開成果的分布，不能由此確認哪些結果被保留、為何被保留，或未公開成果的能力範圍。