幾十美元的小盒子，為什麼跑得動大模型

前陣子算過一筆賬：租雲上的 GPU、部署開源大模型、按 token 賣 API，到底能不能賺錢¹。結論是大多數情況下虧錢——市場價壓得太低，一張 H100 每小時幾美元的租金，攤到能賣出去的 token 上就不夠本。

但最近看到另一組數字，初看和上面那筆賬是矛盾的：一臺 16GB 的樹莓派 5，硬體一百二十美元，用 llama.cpp 單機跑 Qwen3-30B-A3B——一個三百億引數的模型——token 生成能到約 8 個每秒²。有人把四臺拼成叢集，也就到 15 個每秒³。

同一個 Qwen3-30B-A3B，兩種硬體

硬體	單使用者速度	大致價錢
樹莓派 5 · 16GB · 純 CPU	~8 tok/s	$120
四臺 Pi 5 拼叢集	~15 tok/s	~$480
NVIDIA H100 · 單卡	—	$27,000

表 0 · 三百億引數的模型，一個一百多美元的小盒子單使用者也跑得動；但四臺拼起來只快了不到一倍

8 token/s 大概是一個人正常讀字的速度，單使用者用起來不算難受。這裡有兩個說不通的地方：

三百億引數的模型，按常理是資料中心 GPU 的活。為什麼一個幾十到一百多美元、連獨立顯示卡都沒有的小盒子，也跑得動？
既然能跑，為什麼四臺拼起來幾乎不變快？多三倍的硬體，速度只漲了不到一倍。
更要緊的是：如果小盒子跑大模型這麼划算，前面那篇”轉賣 GPU 虧錢”的賬又該怎麼理解？同樣是算力和模型，怎麼一個虧一個不虧？

本文就順著這幾個問題往下追。會發現關鍵只有一句話：單使用者、一個 token 一個 token 地生成，瓶頸根本不是算力，而是記憶體頻寬——而小盒子在”單位頻寬的價錢”上，和資料中心的 GPU 其實是同一個量級。

一、單使用者生成，到底卡在哪

現象：算力強得多的卡，單路也快不到哪去

先看一個反直覺的事實。一張 H100，紙面算力是樹莓派的幾千倍。可要是隻有一個使用者、讓它一個 token 一個 token 地生成一個 70B 的模型，它的理論上限也只有每秒二十幾個 token⁴。算力碾壓，單使用者速度卻沒拉開幾個數量級。算力顯然沒用在刀刃上。

原因：生成一個 token，主要時間花在”把權重搬一遍”

大模型生成是自迴歸的：要吐出下一個 token，得讓當前的上下文從頭到尾過一遍網路的每一層。這一步裡，真正耗時的不是乘加運算本身，而是把這一層的權重從記憶體搬進計算單元。

關鍵在於 batch=1（只有一個請求）時的一個比例。每個權重是一個數，按 16 位存就是 2 個位元組；用它算一個 token，大約只做 2 次浮點運算。也就是說，每從記憶體搬 1 個位元組，計算單元只需要做約 1 次運算⁵。而現代 GPU 的算力和頻寬之比（所謂”脊點”）動輒是幾百比一——它期待你每搬 1 位元組就餵給它幾百次運算。單使用者解碼只喂來 1 次，於是計算單元絕大部分時間在等記憶體。

圖 1 · 單使用者生成一個 token ≈ 把權重從記憶體讀一遍；決定速度的是這條"窄通道"的頻寬，不是計算單元有多快

於是單路解碼的速度有一個乾淨的近似：

$\text{每秒 token 數} \approx \frac{\text{記憶體頻寬}}{\text{每個 token 要讀的權重位元組數}}$

這條式子裡壓根沒有”算力”。一臺機器單使用者跑得多快，幾乎只由它的記憶體頻寬、和模型每個 token 要讀多少位元組決定。這就把問題從”小盒子算力夠不夠”，換成了”小盒子的記憶體頻寬值多少錢”。

既然決定速度的是頻寬，那小盒子的頻寬，到底比資料中心的 GPU 貴多少？

二、單位頻寬的價錢，差得沒那麼多

現象：先把市面上的頻寬擺成一條天梯

既然單使用者拼的是記憶體頻寬（第一節），先看看市面上常見硬體的頻寬都在什麼量級：

記憶體頻寬的天梯：從單板機到資料中心 GPU

檔位	大致記憶體頻寬	典型代表
單板機 LPDDR4X	~10–30 GB/s	樹莓派 5、RK3588
手機 / 輕薄本 LPDDR5X	~50–130 GB/s	旗艦手機、超極本
桌面雙通道 DDR5	~70–100 GB/s	普通桌上型電腦
Apple 統一記憶體	120–546 GB/s	M4 / M4 Pro / M4 Max
伺服器多通道 DDR5	~300–900 GB/s	單 / 雙路、8–12 通道
消費級 GPU GDDR6X / 7	~1,000–1,800 GB/s	RTX 4090 / 5090
資料中心 GPU HBM	3.35–8 TB/s	H100 / H200 / B200

表 1 · 從單板機到資料中心 GPU，記憶體頻寬跨約三個數量級；單使用者的解碼速度基本就跟著這一檔一檔走（數值為該檔常見範圍，非單一型號）

從一塊幾十美元的單板機，到一張資料中心 GPU，記憶體頻寬跨了大約三個數量級——十幾 GB/s 到幾 TB/s，每往上一檔大概 2–5 倍⁶⁷⁸。單使用者的解碼速度基本就跟著這條天梯走：頻寬幾 TB/s 的 H100，單路也會比十幾 GB/s 的樹莓派快上幾百倍。

這些頻寬數字是怎麼量出來的？持續頻寬的事實標準是 STREAM，它跑 Copy / Scale / Add / Triad 四個簡單向量核，報告能穩定達到的頻寬——文章裡樹莓派那 ~11 GB/s 就是它測的⁹¹⁰。x86 平臺上更全面的是 Intel 的 MLC，頻寬、延遲、滿載行為一起測，不過在虛擬機器裡摸不到底層暫存器，延遲數會不準¹¹。想快速粗測，可以用 mbw 或 sysbench memory（後者偏樂觀，容易被快取抬高）。而跟大模型最對口的是一種間接測法：直接用 llama.cpp 的 llama-bench 跑一個已知模型，拿「每秒 token 數 × 每個 token 讀取的位元組」反推有效頻寬——測出來的正是你真正關心的那個數。沒有工具時，也能按「通道數 × 位寬 × 資料率」估個理論上限（比如雙通道 DDR5-6000 ≈ 96 GB/s），實測一般落在理論值的六到八成。

價錢：頻寬差三個數量級，每單位頻寬卻差不了多少

頻寬既然差了三個數量級，那”每單位頻寬的價錢”是不是也該差出三個數量級？把其中幾種裝置折算一下，結果出人意料。這裡要比的不再是”誰頻寬大”，而是”每單位頻寬花了多少錢”——因為單使用者要的就是頻寬這一樣東西：

每單位記憶體頻寬的價錢

裝置	記憶體頻寬	大致價格	每 GB/s 成本
樹莓派 5 · 16GB	~11 GB/s	$120	~$11
Mac mini M4 · 16GB	120 GB/s	$599	~$5
H100 SXM · 80GB（二手）	3,350 GB/s	~$18,000	~$5.4
H100 SXM · 80GB（新卡）	3,350 GB/s	~$27,000	~$8

表 2 · 價錢差兩百倍的裝置，折算到"每單位頻寬"後都落在每 GB/s 五到十一美元，同一個量級（頻寬：STREAM / 官方規格；價格為 2026-10 各渠道估值）

一臺 120 美元的樹莓派，和一張兩萬多美元的 H100，整機價錢差了兩百倍；可折算到”每 GB/s 記憶體頻寬的錢”，都落在每 GB/s 五到十一美元這個窄窄的區間裡。有意思的是，Mac mini 這類消費級統一記憶體裝置，單位頻寬的價錢甚至比 H100 還低一點¹²（二手 H100 隨新卡鋪開也在往下走¹³）；樹莓派反而不是最便宜的——它贏在絕對價格和功耗，不在單位頻寬。

原因：GPU 的價錢，大部分不是在買頻寬

為什麼會這樣？因為一張 H100 賣兩萬多美元，買到的是三樣東西打包：很高的記憶體頻寬、很大的 HBM 視訊記憶體容量、以及海量的算力。而單使用者解碼，只用得上其中的頻寬——算力幾乎全程閒置（第一節），容量也只需要裝下一個模型。

換句話說，買 GPU 的大頭，花在了單使用者用不上的算力和昂貴的 HBM 容量上。真正被用到的那部分——頻寬——按單價算，和便宜盒子上的普通記憶體並沒有拉開量級。小盒子省掉的，正是你本來就用不上的那些。

這也順帶解釋了：為什麼是”記憶體頻寬”而不是”視訊記憶體大小”或”算力”成了單使用者推理的硬通貨。誰的頻寬便宜，誰單使用者跑得就划算。

可頻寬便宜只解決了”跑得快不快”。還有一個更基本的問題沒回答：三百億引數的模型，怎麼塞進一臺 16GB 的小盒子，還能有 8 token/s？

三、MoE：把”裝得下”和”跑得動”拆開

現象：16GB 裝 300 億引數，而且不慢

Qwen3-30B-A3B 是三百億引數。就算壓到 4 位量化，全部權重也有十幾 GB，剛好能擠進 16GB 的樹莓派。可按第一節那條式子，要是每個 token 都得把這十幾 GB 全讀一遍，以 Pi 約 11–15 GB/s 的頻寬，一秒鐘連一個 token 都吐不出來。實測卻有 8 個。中間差了快一個數量級，差在哪？

原因：名字裡的”A3B”——每個 token 只啟用 30 億

差別在模型結構。Qwen3-30B-A3B 是一個混合專家模型（MoE）：它有三百億引數，但被切成了很多個”專家”，每生成一個 token，一個路由器只挑其中幾個專家來算。它的名字 A3B 就是 Activated 3B——每個 token 實際啟用的引數只有約 33 億，其餘二十多億引數這一步根本不讀¹⁴。

這就把兩件一直被捆在一起的事拆開了：

裝得下，看的是總引數。三百億都得在記憶體裡待命，隨時可能被某個 token 用到——這需要容量。而容量恰恰是小盒子便宜的東西：LPDDR、DDR 這類普通記憶體，每 GB 比 GPU 上的 HBM 便宜一兩個數量級。
跑得動，看的是每個 token 啟用多少。只有被啟用的那幾十億引數需要在這一步從記憶體讀出來——這消耗的是頻寬。啟用得少，每個 token 要搬的位元組就少，速度就快。

圖 2 · 同樣一臺 16GB 的盒子、同樣裝著三百億引數：稠密模型每 token 要讀全部權重，MoE 只讀啟用的那一小塊，於是快了約八倍

所以 MoE 對小盒子幾乎是量身定做的：它要的正是小盒子最便宜的那樣東西（大容量的慢記憶體），而它省的正是小盒子最稀缺的那樣東西（頻寬）。近兩年值得一跑的開源模型，大多是這個路子——從 gpt-oss¹⁵ 到 DeepSeek-V3¹⁶，總引數一個比一個大，每個 token 啟用的卻只有一小塊：

幾個 MoE 模型：總引數大，每 token 啟用小

模型	總引數	每 token 啟用	啟用佔比
Qwen3-30B-A3B	30.5B	3.3B	~11%
gpt-oss-20b	20.9B	3.6B	~17%
gpt-oss-120b	117B	5.1B	~4%
DeepSeek-V3	671B	37B	~6%

表 3 · 總引數決定"要多大記憶體裝得下"，每 token 啟用決定"單使用者跑多快"；MoE 讓兩者差出一個數量級（來源：各模型官方 / NVIDIA / Azure）

到這裡，小盒子跑得動大模型的兩個條件都齊了：單使用者只吃頻寬（第一節），小盒子的頻寬單價不貴（第二節），而 MoE 讓”每 token 要讀的位元組”小到這點頻寬也夠用（本節）。

可這就帶出一個尷尬的問題：如果單使用者推理在小盒子上這麼合算，那幾萬美元的 GPU，它的本事到底體現在哪？

四、GPU 的本事，在”一次搬運喂很多人”

現象：同樣的卡，服務一個人和服務兩百人，經濟性天差地別

答案藏在第一節那個”每搬 1 位元組只算 1 次”裡。對單使用者，這是浪費——算力閒著。但如果同一時刻有很多個使用者的請求排在一起呢？

原因：權重只搬一遍，批次裡每個人各拿一個 token

GPU 生成時，把一層的權重從記憶體搬進計算單元，這一次搬運的成本是固定的。關鍵在於：這一次搬進來的權重，可以同時為批次裡的每一個請求各算出一個 token。批次裡有 1 個請求，這次搬運產出 1 個 token；有 200 個請求，同樣一次搬運就產出 200 個 token——而記憶體只讀了一遍。

圖 3 · 批次推理把一次權重讀的成本攤給整個批次：總吞吐隨批次上升，這正是 GPU 省錢的來源，但每個使用者輪到下一個 token 的間隔也被拉長

這就是資料中心 GPU 真正的本事：它靠把一次權重搬運攤給幾百個併發使用者來省錢。BF16 下，H100 大約要同時服務兩百八十個序列，算力才被餵飽、頻寬也物盡其用¹⁷。到那時，每個 token 的成本被攤薄幾百倍，這才是它比小盒子”便宜”的地方——但便宜的前提是真的有幾百個使用者同時在用。

代價是：批次越大，每個使用者輪到下一個 token 的間隔越長，單使用者速度反而下降。總吞吐和單使用者速度是此消彼長的。

現在回頭看小盒子：它只有一個使用者。GPU 唯一的省錢武器——大批次——在這裡根本使不出來。一個使用者填不滿批次，那幾百倍的攤薄就無從談起。於是單使用者恰好是 GPU 最發揮不出優勢的區間：你要麼為用不上的算力和一張卡付全價（只用了約 1/280），要麼老老實實買一臺只夠一個人用、但頻寬單價差不多的小盒子。

這也正好接回了開頭那個矛盾。

五、同樣一筆賬，為什麼轉賣是虧的、自用不虧

現象：一個結論是負毛利，一個結論是划算

轉賣那篇¹的賬是這麼算的：租一張 GPU，每小時付固定租金，把它產出的 token 按市場價賣出去。算下來多數情況是負毛利——賣價還不夠付租金。可同樣是 GPU 和模型，小盒子自用卻很划算。差別不在硬體，在成本結構。

原因：一個要去市場上拼 per-token 單價，一個不用

轉賣的生意，賣的是 token，要和整個市場拼每百萬 token 的價錢。而市場最低價是誰定的？是規模最大、批次最滿、把第四節那套攤薄做到極致的玩家。一個租幾張卡的散戶，湊不齊那麼多併發使用者，批次填不滿，每個 token 的成本就壓不下來，自然拼不過市場價——這是那篇的核心結論。

自用的小盒子，賬完全是另一套：

它不需要去市場上和任何人拼 per-token 單價。沒有要打敗的賣價，只有”這臺盒子對我一個人夠不夠用”。
它的成本是一次性購置（一百多美元）攤到自己的使用，加上幾瓦電——樹莓派滿載也就不到 9 瓦¹⁸，電費可以忽略。它大部分時間閒著也無所謂，因為它本來就便宜。
GPU 最貴的那部分（HBM 容量、海量算力）對單使用者是純浪費（第二、四節），小盒子直接不買這部分。

兩筆賬的成本結構不一樣

	租 GPU 轉賣 API	小盒子自用
賣給誰	公開市場，很多人	自己一個人
要對的價	市場最低 per-token 價	沒有，只看夠不夠用
靠什麼省錢	大批次攤薄（要幾百併發）	硬體便宜 + 功耗低
用得上 GPU 的批次優勢嗎	要，且很難做到	不需要
成本大頭	每小時租金 × 低利用率	一次性購置，幾瓦電

表 4 · 轉賣要在別人最擅長的"大批次攤薄"戰場上拼單價，自用則繞開了整個戰場——單使用者恰好是 GPU 的批次優勢失效的地方

一句話：轉賣是在 GPU 最擅長的戰場（大批次）上和它拼，自用是在 GPU 最不擅長的戰場（單使用者）上繞開它。同一組硬體事實，站在批次這邊看是”GPU 碾壓”，站在單使用者這邊看是”小盒子夠用且便宜”，兩篇文章並不矛盾。

說到自用，馬上有人會問：那又何必買塊盒子放在家裡？雲上隨手租一個 4 核 8G 的例項，不也是一臺沒有顯示卡、靠 CPU 跑的機器嗎？這個對照值得單拎出來講，因為它能把前面幾節的結論用在一個很實際的選擇上。

六、那不如雲上租個 4c8g？

現象：一個 4c8g 例項，看著和小盒子是一回事

一個 4 核 8G 的雲例項，本質上也是一臺沒有獨立顯示卡、靠 CPU 跑模型的小機器。它跑起大模型來遵循的是和盒子一模一樣的那條公式，所以那個”4 核”幾乎不影響解碼速度——真正決定每秒多少 token 的，還是這臺（虛擬）機器的記憶體頻寬，以及 8GB 裝得下多大的模型。兩邊頻寬相近、又都是 8GB，出來的速度就在同一個量級。

換句話說，單論”能不能跑、跑多快”，盒子和 4c8g 例項基本是一回事。真正的差別在別處。

原因：頻寬未必獨佔，8GB 是同一道坎

頻寬是不是你一個人的。 盒子那十幾 GB/s 完全歸你，穩定。4c8g 則是從一臺大伺服器上切出來的一小片，記憶體控制器和同機的鄰居共享。碰上”吵鬧的鄰居”（同一臺物理機上別的租戶在猛讀記憶體），你那一份有效頻寬會被擠，速度跟著抖——這是獨佔一臺盒子時沒有的問題。

8GB 這道坎兩邊一樣。 第三節那個 Qwen3-30B-A3B（Q4）要 16GB 才裝得下，所以 8GB 的盒子和 8GB 的 4c8g 都跑不動它，得換 16GB 的配置。8GB 大概夠一個 7–8B 的稠密模型，或者更小的 MoE。容量這條線上，雲例項並不佔便宜。

解決：按成本結構和用途來選，而不是按”在雲上還是在家裡”

把兩者真正分開的，還是第五節那套成本結構。盒子是一次性一百來美元買斷，之後只有幾瓦電，閒著也不花錢；4c8g 是按小時或按月租，一年算下來幾百美元，而且只要不關機，它 24 小時都在計費。單使用者、長期自用，盒子便宜得多。

小盒子、雲 4c8g（CPU）、雲 GPU 例項

	小盒子（自購）	雲 4c8g（CPU）	雲 GPU 例項
跑模型靠什麼	自己的記憶體頻寬	切片的頻寬，可能被鄰居擠	HBM 頻寬，快得多
8GB 級容量能裝	7–8B 稠密 / 小 MoE	同左	看視訊記憶體，通常更大
單使用者速度	夠用	與盒子同量級	快，但批次能力閒置
成本	一次性約 120 美元 + 幾瓦電	按時 / 按月租，一年幾百美元	按時租，更貴
適合	長期自用、私有	彈性 / 免維護 / 突發	需要快、且能喂滿批次

表 5 · 雲上的 4c8g CPU 例項和小盒子效能同量級，卻要按時付租；它既沒有盒子的成本優勢，也用不上 GPU 的批次優勢

再往深一層看，一個 4c8g 的 CPU 例項，恰恰是這件事裡最不划算的一種選擇：你付了資料中心的租金，卻只拿到一臺邊緣盒子的效能。原因在第四節——單使用者在一個 CPU 切片上，同樣使不出資料中心唯一的那件武器（大批次攤薄）。於是你花了租機器的錢，買到的卻是一臺慢盒子。

那雲到底什麼時候值？要彈性（一小時拉起一百臺、用完就關）、要穩定線上又不想自己管硬體、或者負載很突發、很多人共享的時候——這些正是資料中心擅長的場景。要是就你一個人、穩穩地跑個小模型，那買塊盒子基本等價，還便宜。（注意這裡說的是雲上的 CPU 例項；要是租的是雲 GPU 例項，那又是另一回事：頻寬快得多但也貴得多，而且單使用者照樣浪費了它的批次能力，賬就回到了轉賣那篇。）

不管是買盒子還是租例項，到這裡聊的都還是一臺機器。那要是把一大片這樣的小機器連成一個網路，整體又會呈現什麼性質？

七、一大片小盒子連起來，是什麼形狀

現象：總頻寬很可觀，卻拼不出一臺大機器

把一千臺樹莓派的記憶體頻寬加起來，是 11 TB/s 上下——比三張 H100 的總頻寬還多。聽上去很唬人。但這份頻寬的形狀和資料中心完全不同：它不是一條寬闊的大道，而是一千條互相獨立的窄車道。

原因：機內頻寬和機間頻寬，差著兩個數量級

一臺盒子內部，記憶體到計算單元的頻寬是 11–15 GB/s。可盒子和盒子之間，走的是網路——千兆乙太網也就 0.125 GB/s，比機內頻寬低了約兩個數量級。

這個落差決定了這片網路”能做什麼、不能做什麼”：

不適合把一個大模型拆開跑（模型並行）。要把一個模型切成幾段分到不同盒子上，每生成一個 token，中間結果就得跨網路在盒子間傳一次。機內搬權重只要毫秒級，跨機傳一次卻慢上百倍，於是整體速度被最慢的那段網路鎖死。這正是開頭那個現象的答案：四臺 Pi 拼叢集，只從 8 到 15 token/s，沒有翻兩番——多出來的頻寬大半耗在了盒子之間的通訊上。
適合很多互相獨立的小模型各跑各的（資料並行）。每臺盒子完整跑一個模型、服務一個使用者或一個任務，盒子之間幾乎不用通訊。這種”各管一攤”的活，一千臺就是一千份吞吐，線性地疊加，網路落差完全不礙事。

圖 4 · 資料中心把頻寬集中起來，低延遲地服務一個大模型；一片小盒子把頻寬攤成很多條慢車道，適合很多互不相干的小任務，卻拼不出一臺低延遲的大機器

所以這片網路的”自然形狀”是吞吐導向的，而不是延遲導向的：

總吞吐隨盒子數量線性增長，適合那種可以拆成大量彼此獨立的小任務、又不在乎單個任務要等多久的活（離線批處理、各自獨立的推理請求）。
單個請求的延遲，被最慢那條車道鎖死。想讓某一個請求更快，唯一的辦法是換更快的單臺，而不是堆更多臺；想靠堆機器加速一個大模型，反而會因為跨機通訊變得更慢。

這恰好是資料中心的映象。資料中心把頻寬聚在一起，用大批次低延遲地把一個大模型服務給很多人；一片邊緣小盒子把頻寬攤開，各自慢慢地服務很多個小模型。兩者不是誰強誰弱，而是形狀相反、各有擅長的活。想用一片慢車道去幹資料中心那條大道的活（跑一個需要低延遲的大模型），就會處處彆扭——這也是為什麼開頭那四臺 Pi 拼起來幾乎不變快。

小結

回到開頭那幾個問題，這條鏈是這樣連起來的：

單使用者生成卡在哪？ 卡在記憶體頻寬。一個 token 的時間約等於把啟用的權重讀一遍，算力幾乎閒置；速度 ≈ 頻寬 ÷ 每 token 讀取位元組。
小盒子的頻寬貴多少？ 折算到每單位頻寬，一臺一百多美元的樹莓派和一張兩萬多美元的 H100 都落在每 GB/s 五到十一美元，同一量級——因為 GPU 的價錢大部分買的是單使用者用不上的算力和 HBM 容量。
三百億引數怎麼塞進 16GB 還跑得動？ 靠 MoE 把”裝得下”和”跑得動”拆開：總引數需要便宜的大容量記憶體，每 token 只啟用其中一小塊，所以低頻寬也夠快。
GPU 的本事在哪？ 在大批次——一次權重搬運喂幾百個併發使用者，把每 token 成本攤薄幾百倍。單使用者填不滿批次，用不上這個優勢。
為什麼轉賣虧、自用不虧？ 轉賣要在 GPU 最擅長的”大批次攤薄”戰場上拼 per-token 單價；自用繞開了市場，成本只是一次性購置加幾瓦電，恰好站在 GPU 優勢失效的單使用者區間。
那不如雲上租個 4c8g？ 一個 4c8g 的 CPU 例項和盒子效能同量級（都吃記憶體頻寬、都卡在 8GB），但它既沒有盒子一次性買斷的成本優勢，又用不上資料中心的批次優勢——等於花租金買邊緣效能。雲真正值的是彈性、免維護和共享突發負載。
一片小盒子連起來是什麼形狀？ 聚合頻寬可觀，但碎成很多條慢車道：適合很多互相獨立的小模型、總吞吐線性疊加，不適合拆一個大模型（跨機網路比機內頻寬慢兩個數量級）。和資料中心正好相反。

說到底，“小盒子能跑大模型”不是因為它偷偷變強了，而是因為單使用者、一個 token 一個 token 的推理，恰好是把 GPU 所有長處都用不上的那個場景——在這個場景裡，大家拼的只是記憶體頻寬的單價，而這件事上，便宜盒子並不吃虧。