首先是提到很多 bogus reports 的老問題，只用正向的句子表示「歡迎有人類參與的高品質回報」：

Recently the OpenSSH team have received a large number of security bug reports, many of which are findings from AI models or made with AI assistance. While many AI reports are determined not to have security impact when considered in the context of a realistic threat model, we very much welcome these reports, especially when combined with human triage, analysis, test-cases and particularly when accompanied by proposed fixes.

另外是也發現同樣的 security bug 會被不同團隊的人回報，這代表在 LLM 的年代會有其他的團隊，會在差不多時間抓到一樣的 bug，這等於是在還沒修正前，外面有 0-day 在跑，所以之後決定加快 bugfix 的頻率，以降低風險：

We have seen a number of cases where a security bug identified by AI tools is subsequently independently discovered by a different researcher. This suggests that adversaries who do not report bugs to OSS projects are likely to be able to discover these bugs too. Given this, the OpenSSH team will, for now, be making more frequent releases to get bugfixes into users' hands more quickly rather than batching them until the next planned release.

畢竟是對安全特別敏感的 OpenSSH 團隊 (OpenSSL 的文化傳承)，除了 security bug 的 report 本身以外，看起來也針對同樣的 bug 被不同團隊重複回報的特殊現象 (以前沒出現過的現象) 討論過，得到在 LLM 時代不同的 threat model。

看起來是個苦哈哈的 PR 稿啊...

之前是要註冊到不想接名單裡面，現在是預設就是不接，只有在同意的情況下才能打：

Previously in France, people who wanted to avoid marketing calls had to register their number with a government-run service, but consumer groups said some call centers ignored the list.

然後新法的罰款以每一通為單位來罰，最高是台幣百萬等級的，公司則是千萬等級的：

Parliament approved the law last year. An unwanted call faces fines of up to €375,000. Individuals who make illegal calls can be fined up to €75,000 ($87,000) per call. Companies can face fines of up to €375,000 ($435,000) per call. People can report unsolicited calls through a government website.

算是法律層面的成果。

商業模式是直接把 LLM 的 model 計算刻到晶片上面，理論上可以大幅加速 & 省電，但目前技術只能刻小的，像是之前 Taalas 有把 Llama 3.1 8B 弄出來，缺點也很明顯，當有更好的 model 出現時就得換掉硬體。

之前雖然知道這個方法，但印象中反而是因為這樣，才知道比較中間的方案，像是 Cerebras 與 Groq，都是做專門的 inference 加速晶片，專門為 Transformer 架構設計的，而這兩個服務都有 API 可以用...

Taalas 的併購案不知道會不會是 talent acquisition...

另外是後續的版本直接掛西元年份了，以後會是 Django 2028 這樣的版本：

From January 2028, Django will make one feature release a year, giving every feature release the LTS-level three years of support, and version numbers will carry the feature release year: Django 2028, then Django 2029, and so on.

本來的 5.2 LTS 與 6.2 LTS 會繼續照當初承諾的維護。

算是比較少見增加 LTS 頻率的大型 open source project，像是 Linux Kernel 縮過：「Linux Kernel 後續的 LTS 版本將縮短成兩年」，Django 這邊決定增加頻率也反映出目前的社群能量是夠的...

新機房在阿姆斯特丹 (荷蘭)：

We’ve installed our own servers, co-located in a secure facility in Amsterdam, set up by our own engineers.

不過因為目前歐洲沒有其他機房的關係，資料還是會丟到美國機房備份：

Resilient replicas of your data will live in the US (for now). As we only have one location in Europe so far, the geographically separate copy will remain on servers in one of our US locations.

另外 log 也還是以美國為主：

Logs are in the US. All system logs are consolidated into a single place for monitoring system health and to assist with customer support.

但算是跨出去了，後續可以預期當歐洲有第二機房的時候可以再降低對美國機房的依賴性。

看起來過了幾個月 Google 也用內部的 LLM 搞定了：「Stronger with every update: How we’re making Chrome and the web safer in the AI Era (via)」。

可以看到內部掃出來的數量也爆增不少，然後修掉不少，但看起來已經在收斂了？後續應該就是每次 LLM 變強的時候又會再掃出一些，但算是達到某種平衡 (?) 了。

LLM 的成長算是某種 harden 的過程...？

簡單來說就是用隱藏的 prompt (像是白底白字) 跟 AI 說自我複製到其他文件裡面，然後藉此延續下去：

An attacker places hidden instructions in a document that is later used as source material in Copilot for Word. Copilot may interpret those instructions as part of the user’s request, causing it to manipulate the document being drafted or edited. Copilot may then also copy the hidden instructions into the resulting document, turning that document into a new carrier. If the carrier is subsequently used in another Copilot-assisted workflow, the instructions can trigger again and propagate into further documents, even without the attacker’s original document being present.

有種 AI 時代文藝復興的感覺：「Morris worm」，這個是 1988 年發生的事情 (快 40 年了)。

不過作者是在 Microsoft Copilot 上面 PoC 的，眾所皆知 Microsoft 的 LLM 能力... 但這個應該會隨著後續 LLM 的成長而慢慢消失？然後有種 COVID-19 當時 R 值的感覺...

這邊講的 monotonic 是指 monotonic function，函數是遞增或是遞減，像是維基百科給的兩個範例：

而不會是偶而升又降的情況：

這邊講的 log() 的 monotonic 問題是對底數的部分，在純數學上，底數愈大，值就會愈小：

If and , you can prove that . (As a reminder, denotes the value such that .)

但作者就提出可以在 PHP 或是 Lua 中會遇到底數變大，值卻變大的例子：

<?php
$x = 2.93;
$a = 10 + 2 ** -49;
$b = 10;
assert($a > $b);
var_dump(log($x, $a) < log($x, $b));
var_dump(log($x, $a) == log($x, $b));

這邊的原因出自於 10 這個特別的底會走 libm 的 log10，而 10 + 2 ** -49 這邊會走一般的換底公式不同，導致產生底變大，但是值卻變大的問題，所以不能直接假設 monotonic。

不知道數值分析的課會不會教到這個...

裡面提到有 spec：

In May, OCI launched support for AWS Interconnect in public preview and became the latest CSP to adopt the open specification that powers the service. With today’s GA launch, AWS customers can now rely on the same consistent, simple experience to interconnect their workloads on OCI and Google Cloud. Microsoft Azure will launch later in 2026.

其中的 spec 提到是 L3 對接：

Describes the OpenAPI 3.0 specification of the symmetric API to be used to coordinate managed L3 connectivity.

以 AWS 的領先地位，看到這篇，蠻有趣的...？

所以在看到有貨的時候就買了張回來...

不過一開始不是很順，裝在第二個 PCI-e 後機器直接開不起來，連 BIOS 畫面都沒出現：(當時把 B70 寫成 B90...)

後來 Plurk 上面有人建議 BIOS 升級與一些設定 (https://www.plurk.com/p/3iyyjs1l75)，結果才發現我機器的 firmware 是 2021 年的，已經很久沒動過了：

升級上去後另外依照 LLM 搜尋 forum 得到的指示，關閉 CSM，然後開 Above 4G Decoding 與 Re-size BAR support，設定完後至少過了開機這關，後續就是 OS 這邊要弄了。

我是跑 Debian 13，然後希望同時有 4060 Ti 與 B70，所以就折騰的一陣子... 首先是 Debian 13 目前是 6.12 的 kernel，而 B70 需要 6.17 以上的 kernel 才支援，但 Nvidia 的 DKMS 不支援目前 trixie-backports 裡面的 7.1，所以就只好去找 6.18 LTS 來跑了。

再來是 llama.cpp 可以編 SYCL，但掛 Qwen3.6 的 GGUF 上去的時候會出現 unsupported feature 的錯誤，用了幾個 workaround 都沒用，就放棄回 Vulkan 了，至少是跑的起來的。

跑起來的感覺跟預期的接近，這種大 VRAM 但計算力沒有很強的顯卡會比較適合 MoE 類的 model，目前用 unsloth/Qwen3.6-35B-A3B-GGUF:UD-Q4_K_XL 跑在 Vulkan 環境下測起來有大約 30 tokens/sec，如果再架幾個 MCP 服務掛進去讓 LLM 玩玩看 (至少掛 WebSearch & WebFetch 進去，內建推薦的 Exa 問題超多)，來看看可以在本機跑做到什麼程度...

Update：後來用 nvtop 才發現跑錯 device 了，跑到 4060 Ti 上面去了... 後來用 GGML_VK_VISIBLE_DEVICES=1 加上 nvtop 確認後，如果是 B70 的話大約 70 tokens/sec 左右。

另外一個也想看看的方向，是看看可不可以用 vLLM 來跑，據說速度會再好一些？

另外測了不怎麼吃 VRAM 的 KataGo，看起來只能用 OpenCL 接，速度反而沒 4060 Ti 跑 TensorRT 快，不過這樣的好處是 llama.cpp 在跑的時候也不用顧慮 KataGo 吃 VRAM 的問題了...

如過要下一步，會是客製化的 Mac Studio 嗎，看起來可以上到 512GB？不過大模型就算是 MoE 計算量還是很大，應該不會是可用的速度？也許 96GB 的版本是個還不錯的平衡點？之後再研究看看好了...