2026 年 9 月，一位使用 RTX 3090、128GB RAM 的玩家想跑 Qwen3.8-Flash-Next GGUF，留言裡有人建議研究 FreeToken。真正值得學的不是照抄別人的 tok/s，而是先回答四個問題：模型格式支不支援、權重與執行期記憶體放不放得下、PCIe 與 RAM 頻寬適合哪個 backend，以及長 prompt 時結果會不會翻盤。這篇 FreeToken 教學就把判斷變成可重跑流程。
先交代證據邊界：本文撰寫環境是 macOS arm64，沒有 NVIDIA GPU、CUDA 13 與 128GB RAM，因此無法產生 AlphaLab 自己的 RTX 3090 跑分。下文的版本、指令與機制均以 FreeToken v0.1.2 官方原始碼交叉校對；效能部分提供你能在 Linux／RTX 3090 重跑的驗收方法，不把官方或 Reddit 數字冒充本站實測。
先說答案：手上是一般 GGUF，尤其是 Qwen3.8 的 UD-Q4_K_XL，先留在 llama.cpp；要測 FreeToken，改用它支援的 Hugging Face safetensors checkpoint，並先在同一份權重內比較 offload、cpu、hybrid。auto 只適合當候選設定，不是免驗收的裁判。
FreeToken 教學先看結論：後端不是速度排行榜
- 格式先決：v0.1.2 直接讀 Hugging Face safetensors；官方支援表只把 Gemma-4 列為 native GGUF 路徑。一般 GGUF 不該硬塞進 FreeToken。
- 容量再決：MoE 每個 token 只啟用部分 experts，不代表整個 expert pool 不必放在 RAM、VRAM 或可搬運的位置。
- 頻寬只給假設：
ft bench bw量 CPU 與 PCIe 路徑，讓auto決定是否從 offload 升到 hybrid；它沒有跑你的真實 prompt。 - 任務才是裁判：固定模型、prompt、context、輸出長度與併發，至少記 warm TTFT、prefill、client-visible decode、RAM、VRAM、輸出 hash 與任務正確性。
- 跨引擎別偷換命題：如果 FreeToken 與 llama.cpp 使用不同格式或量化，結果只能回答「哪條路在我的任務比較好用」，不能證明引擎本身快多少。
如果你還不熟 KV cache、量化與 CPU offload，先讀 本機 LLM 顯存決策樹；想分清 vLLM、llama.cpp 與其他 runtime 的定位，則可搭配 LLM 推論引擎完整教學。
FreeToken 是什麼？用倉庫理解 MoE Offload
把 MoE 想成一座有很多專科倉庫的工廠。每次生成 token，路由器只叫少數 experts 工作；這能降低當下計算量，但所有倉庫仍要放在某處。RTX 3090 的 24GB VRAM 放不下大型 MoE 的全部權重時，FreeToken 會把 expert pool 留在主記憶體，GPU 保留一部分 expert cache；遇到 cache miss，再決定「經 PCIe 搬到 GPU」或「直接交給 CPU 算」。
FreeToken 論文把 prompt prefill 與逐 token decode 分開處理：長 prompt 可能在短時間內碰到很多 experts，decode 則是一連串稀疏 miss。這也是短對話快，不代表 50K、100K context 仍快的原因。你需要同時看「第一個 token 等多久」和「之後每秒吐多少 token」。
四種 FreeToken backend 各做什麼？
下列是 CLI 提供的選擇，不代表每種 checkpoint／quantization 都能使用全部 backend；CPU／hybrid 需要對應的 CPU weight path，fused 也受 dtype 與 VRAM 限制。讓 load-time validation 決定相容性，不要繞過錯誤硬開。
- fused：experts 常駐 GPU，最吃 VRAM，而且官方明確說它不會被
auto選中。 - offload：experts 留在 host RAM；GPU LRU cache miss 時，經 PCIe 把 expert 搬到 GPU。
- cpu：miss 不搬到 GPU，改在 CPU 計算。
- hybrid：同一步裡，一部分 misses 走 PCIe，一部分在 CPU 計算，兩條路重疊執行。
- auto：dense 模型選 fused；MoE 預設 offload，只有已保存的頻寬 profile 建議時才升成 hybrid。這是 v0.1.2 官方定義，不是一張普遍效能保證。
FreeToken 教學第 0 步：先判斷 RTX 3090 能不能跑
不要先下載模型。先在 Linux 主機執行以下盤點，把結果存成第一張 receipt：
mkdir -p freetoken-lab/receipts
cd freetoken-lab
date -Iseconds | tee receipts/system.txt
uname -a | tee -a receipts/system.txt
python3 --version | tee -a receipts/system.txt
nvidia-smi --query-gpu=name,memory.total,driver_version,pci.bus_id \
--format=csv | tee -a receipts/system.txt
nvcc --version | tee -a receipts/system.txt
free -h | tee -a receipts/system.txt
lscpu | tee -a receipts/system.txt
df -h . | tee -a receipts/system.txtv0.1.2 的 安裝文件要求 Linux x86_64、NVIDIA GPU、r580 以上驅動（CUDA 13）與 Python 3.10 以上；第一次用到 JIT CUDA kernel 時，還要 PATH 裡找得到 CUDA 13 的 nvcc。少任何一項，先停止，不要把安裝失敗誤判成模型不支援。
RAM／VRAM 預算怎麼算？
初步預算可以寫成兩條式子：
RAM 下限＝模型權重映射／常駐部分＋模型專用資料＋runtime 工作區＋作業系統餘裕。
VRAM 下限＝非 expert 常駐權重＋expert cache＋KV cache＋CUDA graph／kernel buffer。
不要把「active parameters」當成檔案大小，也不要把 safetensors 總和直接當成精準峰值 RAM。以 2026 年 9 月 7 日的官方 Hugging Face 檔案清單計算，Qwen3-30B-A3B 的 safetensors 約 56.9 GiB；Qwen3.8-Flash-Next-NVFP4 約 125.9 GiB。這兩個數字是下載 artifact 規模，不是執行期 RAM 公式。
Qwen3.8 更能說明為何不能相加猜 RAM：FreeToken main 的 models.md 還寫著 47.7 GiB PLE table 會 pin 在 host RAM，但 commit 4c0bad3（PR #311）已把預設改為 --ple-backend disk，按需從 checkpoint 讀 rows。runtime 原始碼與說明文件目前有落差，所以 125.9 GiB artifact 不能直接宣判 128GB 主機通過或失敗。想學穩定版 FreeToken，先用 v0.1.2 明列支援、容量較可控的 Qwen3-30B-A3B；想跑題目來源裡的 Qwen3.8 UD-Q4_K_XL，先照 Qwen3.8 GGUF 四關驗收留在 llama.cpp 路線。
第 1 步：安裝穩定版 FreeToken，不混用 main 文件
截至 2026 年 9 月 7 日，PyPI 最新穩定版是 0.1.2。main branch 已加入 Qwen3.8 等較新的文件與程式，但還不是同一個穩定發布物。初學者應固定版本，否則很容易拿 main 的參數去跑 0.1.2 wheel。
cd freetoken-lab
uv venv --python 3.10
source .venv/bin/activate
uv pip install "freetoken[accel]==0.1.2"
ft --version | tee receipts/freetoken-version.txt
python -c "import sys; print(sys.version)" | tee -a receipts/freetoken-version.txt若你不用 uv，官方說一般 pip + venv 也可以。安裝後，ft --version 必須顯示 0.1.2；不一致就不要繼續抄下面指令。
第 2 步：用支援矩陣選 checkpoint，再做最小啟動
這次用 Qwen/Qwen3-30B-A3B 當教學 checkpoint，原因只有兩個：它在 v0.1.2 的 known-good 表內，而且權重規模比 Qwen3.8 NVFP4 小。這不是「RTX 3090 最佳模型」推薦；下載前仍要確認 RAM、磁碟與授權符合你的用途。
export FT_MODEL="Qwen/Qwen3-30B-A3B"
/usr/bin/time -v ft serve \
--model "$FT_MODEL" \
--host 127.0.0.1 \
--port 1919 \
--moe-backend auto \
--memory-ratio 0.90 \
2>&1 | tee receipts/auto-server.logv0.1.2 官方 CLI 文件與本次檢視的 server 參數未提供內建 API authentication 設定，因此本文按未認證服務處理；除非前面已有具認證的 reverse proxy，否則只綁 127.0.0.1，不要直接暴露到區網或公網。第一次啟動會下載權重並可能 JIT 編譯，不能拿這段時間當 TTFT。另一個終端機先做健康檢查與最小請求：
source .venv/bin/activate
ft ctl --json health | tee receipts/auto-health.json
curl -sS http://127.0.0.1:1919/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model":"Qwen3-30B-A3B",
"messages":[{"role":"user","content":"只回答 READY"}],
"temperature":0,
"max_tokens":16
}' | tee receipts/auto-smoke.json
ft ctl --json stats | tee receipts/auto-stats.json
ft ctl --json cache | tee receipts/auto-cache.jsonsmoke test 只證明 API 能回應，還沒證明 backend 合理、長 prompt 能跑或回答正確。先在 log 裡找實際解析出的 MoE backend、模型 dtype、cache 尺寸與 OOM；不要只看你輸入了 auto。
第 3 步：跑頻寬校正，但不要盲信 auto
關閉 server 後執行：
ft bench bw 2>&1 | tee receipts/bench-bw.txtv0.1.2 會用真實 CPU／offload MoE kernels 量 host RAM 與 PCIe 路徑，並把 profile 寫入 $XDG_CACHE_HOME/freetoken/benchbw.json；未設定 XDG_CACHE_HOME 時才回到 ~/.cache/freetoken/benchbw.json。預設判定是 CPU bandwidth 超過 PCIe 兩倍時建議 hybrid。請把這個 JSON 與輸出一起保存；它回答的是「兩條資料路徑的相對頻寬」，不是「你的模型＋prompt 在 hybrid 一定較快」。
這個提醒不是杞人憂天。仍開放的 issue #151 中，回報者在 2×RTX 3090、DeepSeek-V4-Flash、一次短 prompt／60-token completion 上，先得到會推薦 hybrid 的頻寬結果；實際指定 hybrid、使用預設 23 個 CPU threads 時約 0.58 tok/s，forced offload 約 5.58 tok/s，把 hybrid threads 固定為 44 時才是 0.67 tok/s。貼文把 profile 寫到自訂檔名，卻沒展示 bare auto 如何讀到該檔，因此這裡只採用明確的 forced backend A/B，不把 auto 載入步驟當成已完整重現。這也不是單卡 3090 或官方 benchmark，同串另一位 4090／Gemma 使用者的差距就小得多。開放且尚未合併的 PR #278主張頻寬 profile 的 expert geometry 可能與實際模型不符；在修補正式發布前，最穩妥做法就是把 auto 當假設，再跑實際 checkpoint。
第 4 步：固定同一任務，分兩層做 A/B
公平比較要拆兩層。第一層只在 FreeToken 內更換 backend，模型權重完全相同，能回答 offload、cpu、hybrid 哪個適合這台機器。第二層才拿勝出的 FreeToken 設定和 llama.cpp 比「使用者體驗」；若兩邊格式或量化不同，務必把結論限制在這個任務。
A. FreeToken 內部：用官方 serving-path benchmark
官方 repo 內的 bench_decode_moe.py 會替每個 backend 開一個 server，以同一 prompt warm-up 後透過串流 API 量 cache-warmed TTFT 與 client-visible decode，並記 prompt／completion tokens、VRAM 與輸出 SHA-1。先把程式固定在同一 tag：
git clone https://github.com/FlashML-org/FreeToken.git
cd FreeToken
git checkout v0.1.2
git rev-parse HEAD | tee ../receipts/freetoken-commit.txt
printf '%s\n' '{"problem":"閱讀以下固定測試文件後，列出三個可驗收結論。文件：把你真正會使用的長文件貼在這裡。","answer":""}' \
> ../fixed-task.jsonl
for order in \
offload,cpu,hybrid \
hybrid,cpu,offload \
cpu,offload,hybrid \
hybrid,offload,cpu \
offload,hybrid,cpu
do
CUDA_VISIBLE_DEVICES=0 PYTHONPATH=python:. \
python benchmarks/bench_decode_moe.py \
--model "$FT_MODEL" \
--backend "$order" \
--aime ../fixed-task.jsonl \
--decode 256 \
--greedy \
--json ../receipts/freetoken-backends.jsonl
done請把占位文字換成你的真實短任務。官方 script 把 server 的最大序列固定為 8192 + --decode，所以它是短 context 初篩，不可拿來跑 50K／100K fixture。它對每個 backend 只做一次 warm-up 與一次 measured request；上面的順序輪替讓每個 backend 測五次，避免永遠由同一個設定先承受冷機或熱機狀態。--json 寫的是一行一個物件，因此副檔名用 .jsonl。若輸出 hash 不一致，先判為「結果不可直接比較」，不要急著排序速度。
ttft_ms 包含 chat template、queue 與 prefill，且是 warm 路徑；它不能直接除以 prompt tokens 就命名為純 prefill tok/s。這支 script 使用隨機 private port，取得 stats 後就關閉 server，而且輸出只保留 VRAM，不會讓你事後再用 ft ctl 抓 prefill。長 context 與 prefill 要改用下面的「自行管理 server＋同一 client」流程；測試期間每秒輪詢 ft ctl --json stats，因為其中 prefill_tps 只是五秒滑動視窗，閒置後會歸零。
單卡 RTX 3090 issue #306的一組 Qwen3.8 NVFP4、75,665-token prompt、三輪 offload 測量中，client median 是 12.6 tok/s，scheduler mean 則是 21.3 tok/s；後續另一套雙 RTX 6000 Ada／較新程式碼沒有重現同等落差。這些回報都不能外推成普遍缺陷，卻足以要求我們把 client 與 server 口徑分欄。
B. FreeToken 對 llama.cpp：同任務，不宣稱同引擎條件
llama.cpp 的 -ngl 控制最多多少 layers 放進 VRAM，-ncmoe 把前 N 層 MoE weights 留在 CPU，-c 固定 context。這些是 2026-09-07 commit 的官方參數；不同 build 的預設可能改變，所以收據一定要存 commit。
git -C llama.cpp rev-parse HEAD | tee receipts/llamacpp-commit.txt
./llama.cpp/build/bin/llama-server \
-m /models/your-model.gguf \
--host 127.0.0.1 \
--port 8080 \
-ngl auto \
-c 32768 \
2>&1 | tee receipts/llamacpp-server.log不要拿 llama-bench 的 prompt processing／generation 數字直接對比 FreeToken serving-path script；llama-bench 文件明說它量的是 benchmark 路徑，範圍不同。較公平的做法，是讓兩個 server 都走 OpenAI-compatible /v1/chat/completions，用同一個 client、同一 prompt、temperature 0、context 與 max tokens，warm-up 一輪後測五輪。llama.cpp response 另有 timings.prompt_per_second 與 predicted_per_second，可當該 server 的內部欄位，但最終仍以 client 看到的 TTFT／總耗時和任務驗收為準。
把下面存成 bench_chat.py。它只用 Python 標準函式庫，先丟棄一輪相同 prompt 的 warm-up，再以 SSE token 到達時間計算 cache-warmed TTFT 與 client decode；若 server 沒回精確 completion token count，或提前停止，就直接失敗，不會拿字數假裝 token：
import argparse, hashlib, json, time, urllib.request
from pathlib import Path
def once(url, model, prompt, max_tokens):
body = json.dumps({
"model": model,
"messages": [{"role": "user", "content": prompt}],
"temperature": 0,
"max_tokens": max_tokens,
"ignore_eos": True,
"stream": True,
"stream_options": {"include_usage": True},
}).encode()
req = urllib.request.Request(
url.rstrip("/") + "/v1/chat/completions",
data=body, headers={"Content-Type": "application/json"})
start = time.perf_counter()
first = last = None
chunks, usage, timings = [], {}, {}
with urllib.request.urlopen(req, timeout=1800) as response:
for raw in response:
if not raw.startswith(b"data:"):
continue
data = raw[5:].strip()
if data == b"[DONE]":
break
event = json.loads(data)
usage = event.get("usage") or usage
timings = event.get("timings") or timings
choices = event.get("choices") or []
if not choices:
continue
delta = choices[0].get("delta") or {}
text = (delta.get("reasoning_content") or "") + (delta.get("content") or "")
if text:
now = time.perf_counter()
first, last = first or now, now
chunks.append(text)
end = time.perf_counter()
tokens = usage.get("completion_tokens")
if first is None or last is None or tokens != max_tokens:
raise RuntimeError("missing timed text or exact fixed completion_tokens")
span = last - first
return {
"ttft_ms": round((first-start)*1000, 1),
"wall_s": round(end-start, 3),
"prompt_tokens": usage.get("prompt_tokens"),
"completion_tokens": tokens,
"client_decode_tps": round((tokens-1)/span, 2) if tokens > 1 and span > 0 else None,
"server_prompt_tps": timings.get("prompt_per_second"),
"server_decode_tps": timings.get("predicted_per_second"),
"output_sha256": hashlib.sha256("".join(chunks).encode()).hexdigest(),
}
p = argparse.ArgumentParser()
p.add_argument("--url", required=True)
p.add_argument("--model", required=True)
p.add_argument("--prompt-file", required=True)
p.add_argument("--max-tokens", type=int, default=512)
p.add_argument("--runs", type=int, default=5)
p.add_argument("--warmups", type=int, default=1)
a = p.parse_args()
prompt = Path(a.prompt_file).read_text(encoding="utf-8")
for _ in range(a.warmups):
once(a.url, a.model, prompt, a.max_tokens)
for run in range(1, a.runs + 1):
print(json.dumps({"run": run, **once(a.url, a.model, prompt, a.max_tokens)},
ensure_ascii=False), flush=True)先從各 server 的 /v1/models 取得實際 model ID，再各跑一次；不要同時開兩個會爭用 RTX 3090 的 server：
python bench_chat.py \
--url http://127.0.0.1:1919 \
--model Qwen3-30B-A3B \
--prompt-file fixed-prompt.txt \
--max-tokens 512 --runs 5 \
| tee receipts/freetoken-client.jsonl
python bench_chat.py \
--url http://127.0.0.1:8080 \
--model your-llama-server-model-id \
--prompt-file fixed-prompt.txt \
--max-tokens 512 --runs 5 \
| tee receipts/llamacpp-client.jsonl長 context 測試時，先重開一個由你管理、--max-running-requests 1 的 FreeToken server，分別明確指定 offload 與 hybrid；fixture 不得超過 checkpoint 宣告的最大序列。每個 backend 先用 --warmups 0 --runs 1 留一張 cold receipt，再用預設 warm-up 測五輪。另一個終端機在請求期間每秒輪詢 stats；按 Ctrl-C 停止後，保留帶時間戳的輪詢 log：
while true; do
date -Iseconds
ft ctl --json stats
sleep 1
done | tee receipts/freetoken-stats-poll.log
# fresh server 的第一次 long-context 請求
python bench_chat.py \
--url http://127.0.0.1:1919 \
--model Qwen3-30B-A3B \
--prompt-file long-prompt.txt \
--max-tokens 512 --warmups 0 --runs 1 \
| tee receipts/freetoken-long-cold.jsonl這份 stats poll 的 prefill_tps 是五秒滑動視窗，只能和同一 FreeToken 版本、同一輪詢方式比較；llama.cpp 的 server_prompt_tps 則來自它自己的 response timings。兩者都放進收據，但跨引擎勝負仍以同一 client 的 TTFT、wall time、輸出與任務通過率為主。server 結束後，再從 /usr/bin/time -v log 取 peak RSS；VRAM 使用量則保存 FreeToken stats 或 llama.cpp server log。
若你想排除「換量化後模型變笨」，把回答再送進 本機 LLM 五關 A/B Test 的固定測例；若還在 Q4、Q5 間猶豫，先看 GGUF 量化選擇指南。速度快但任務失敗，不是勝出。
第 5 步：怎麼讀結果？用停損順序，不看最高 tok/s
- 先排錯：任一 backend OOM、輸出空白、hash 漂移或任務錯誤，就不能靠高 tok/s 過關。
- 再看容量：記錄 server 穩定後與長 prompt 峰值的 RAM／VRAM。VRAM 靠近上限時，不要直接把
--memory-ratio拉滿；要替桌面、driver 與波動留空間。 - 再看等待：互動用途先看 warm TTFT 與 p95；批次用途再提高 decode／throughput 權重。
- 比較中位數：至少五輪取 median，也保存最慢一輪。長 context 常由尾端延遲而不是漂亮平均值決定體感。
- 最後才選路：offload 若明顯穩定勝出，就明確指定；hybrid 只有在真實 checkpoint、短長 prompt 都過關時才採用；兩者接近時選較簡單、較容易重現的設定。
如果你讀完只記得一句話，就是：backend 選擇＝格式可用 × 容量安全 × 同任務正確 × 等待可接受。頻寬是原因之一，不是唯一成績。
FreeToken 錯誤樹：看到症狀先查哪裡？
Unsupported model／載入時就失敗
- 先比對「已安裝版本」的 models.md，不要比對 main。
- 確認輸入是完整 HF checkpoint 或 FTW，不是一般 GGUF 改副檔名。
- Qwen3.8 在 2026-09-07 的 main 文件已出現，但 PyPI 0.1.2 支援表沒有；想測 unreleased code，應另開隔離環境並固定 commit，不能把結果寫成穩定版行為。
啟動 OOM／跑到長 prompt 才 OOM
- 啟動即 OOM：降低 expert cache、確認沒有其他 GPU process，並檢查非 expert 常駐權重是否已超過 24GB。
- 長 prompt 才 OOM：KV cache 與併發通常是第一批嫌疑；先把
--max-running-requests降到 1、縮短 context，再逐項加回。 - Host RAM 不足：換較小 checkpoint 或增加 RAM。swap 也許避免立刻 crash，卻可能讓互動延遲失去意義，不能當成容量通過。
prefill 很慢／decode 還可以
先用短、長 fixture 判斷是否只在 prompt 變長時惡化，再看 PCIe link width、RAM channel／NUMA、expert cache 與 prefix cache 命中。MoE 的長 prompt 可能觸及更廣的 expert 集合；不要用「短 prompt decode 很快」否定 prefill 瓶頸。想補記憶體頻寬原理，可讀 AI 推理的記憶體瓶頸。
auto 選 hybrid，但 forced offload 更快
先保存 bench profile、server log 與真實 checkpoint 名稱，重跑至少五輪；再檢查是否只在某個 prompt 長度翻盤。若結果穩定，直接指定 --moe-backend offload，並把 auto 視為未通過。你也可以參考 Magnitude 本機模型推薦教學的共同原則：自動推薦是在縮小候選，不是在替你的任務簽收。
RTX 3090 最後決策：FreeToken、Hybrid 還是 llama.cpp？
- 選 llama.cpp：你已經有 GGUF、模型不在 FreeToken 穩定版矩陣、需要成熟的 GGUF 量化與 layer／MoE CPU placement 控制。
- 選 FreeToken offload：checkpoint 受支援、RAM 足夠，而且同權重測試顯示 PCIe 搬運路線穩定、正確、延遲可接受。
- 選 FreeToken hybrid：頻寬 probe 只是第一票；實際模型在短、長 prompt 的五輪中都勝過 offload，RAM／VRAM 與輸出也通過，才算第二票。
- 維持 inconclusive：兩邊用了不同模型／量化卻想宣稱引擎倍數、只跑一次、只看 scheduler tok/s、或長 prompt 沒測。這時不是「平手」，而是證據不足。
FreeToken 最有意思的地方，是它把消費級 GPU 跑大型 MoE 的問題重新寫成「GPU、CPU、RAM、PCIe 怎麼協作」。但這也表示答案不可能只由顯卡型號決定。RTX 3090 是同一張卡；不同主機板 PCIe、記憶體通道、CPU、checkpoint geometry 與 prompt，仍可能得到相反 backend 結論。把收據留下，才有資格談優化。
FreeToken 常見問題
RTX 3090＋128GB RAM 能跑 Qwen3.8-Flash-Next 嗎？
不能只憑兩個容量數字回答。題目中的 UD-Q4_K_XL 是 GGUF，走 llama.cpp；FreeToken main 列出的 NVFP4 artifact 約 125.9 GiB，對 128GB 主機幾乎沒有安全餘裕，而且尚未進入 PyPI 0.1.2 的支援表。先選較小的穩定支援 checkpoint，或增加 RAM，再做實機驗收。
跑完 ft bench bw，可以直接用 auto 嗎？
不建議。它只校正 CPU／PCIe 路徑，沒有測你的實際模型與 prompt。先記錄 auto 解析結果，再用 forced offload、cpu、hybrid 做同 checkpoint A/B。
為什麼不直接公布「3090 應該有多少 tok/s」？
因為模型、量化、PCIe、RAM 頻寬、CPU、cache、context、併發與計時邊界都會改變結果。沒有完整 receipt 的單一數字，無法安全移植到另一台 3090。
FreeToken 和 llama.cpp 哪個比較快？
沒有脫離模型與工作負載的答案。先在 FreeToken 內用同權重比較 backend；跨到 llama.cpp 時固定任務與 client，並清楚標註格式、量化不同。最終比較的是等待時間、資源與任務通過率，不是一張最高 tok/s 排名。
想繼續建立本機 AI 的完整理解，可瀏覽 AlphaLab AI 專區；需要從基礎開始，也可進入 免費課程。
接著閱讀
左右滑動查看更多推薦