【2026 最新】Flide 教學：同一份文件問多題，Exact State Forking 何時更快？

你有一份客服紀錄，想讓本機 AI 同時判斷「是否急件、該退款還是換貨、要不要交給主管」。Flide 教學要先問的，是這三個問題能否共用同一份輸入；把三份不同紀錄各問一題，則是另一種工作負載。

前半寫給完全沒有技術背景、想讀懂加速原理的讀者；後半給已有 Linux／NVIDIA GPU 環境、願意貼指令的新手。你會學會啟動 API、準備 1／4／16 題對照，並把答案、機率與延遲分開驗收。

本文依 2026 年 11 月 10 日查閱的官方文件、原始碼與論文整理；當日 PyPI 版本為 0.1.11。本次環境是 Apple Silicon Mac，未執行 Flide GPU 推論，以下提供的是操作與測量方法。文中的外部速度數字保留作者的測試條件。

先說結論：讀一次共用材料，每題各走自己的分支

Flide＝共用輸入算一次＋每題獨立分叉＋選項機率輸出。把它想成幾位閱卷員共用一份已讀筆記，但各自回答自己的題目；第一題的推理過程，不應混進第二題的材料。

Flide 是執行模型的推論引擎，模型權重才像閱卷員的知識。換引擎可以改變計算和排程方式；題目是否答對，仍要用你自己的標籤驗收。若還不熟模型、執行層與工具的分工，可先讀 Agent Harness 的白話介紹。

一、Flide 教學先認清五個零件

• ① state「共同材料」：這次要判讀的文件、對話或物件。API 接受 JSON；本篇先用文字。
• ② question「一張判斷卡」：你問什麼、有哪些選項、每個選項代表什麼。問題的 key 是答案名稱。
• ③ 中間狀態「讀完留下的筆記」：模型算過輸入後的內部數值，不是把原文另存成一個檔案，也不是模型學會了永久記憶。
• ④ Exact State Forking「從同一頁各自出發」：共用材料計算後，每一題接回正確的狀態與位置，分支彼此隔離。
• ⑤ batch「一起排進 GPU 的工作」：多題共用 state，和多份請求一起執行，是兩個可以同時存在的層次。

依 官方 API 文件，choice 回傳最可能的選項與各選項機率，noul 回傳敘述成立的機率，score 則以離散等級計算期望值。這篇用 choice，讓你直接看到整個機率分布，而不只看到一個答案字串。

二、它和 Prefix Cache 的關係：都省重讀，切入點不同

Prefix Cache（前綴快取）像保留「開頭已讀過的筆記」。例如 vLLM 的官方說明，介紹如何重用共同前綴的 KV Cache，減少重複處理輸入。KV 是注意力運算留下的中間資料；它不是把整個答案快取起來。

Flide 進一步把一份 state 和多個問題視為一棵樹，再排成 GPU 上的一條運算串流。依 原始論文的機制設計，ForkAttention 指定每個分支能讀取哪些位置；遇到含 Gated DeltaNet 的混合模型，還要讓每題從共享材料結尾的正確循環狀態起跑。白話說，除了共用筆記，還要替每位閱卷員分好工作桌。

因此，別把兩者理解成「有快取」和「完全沒快取」的比賽。比較引擎時，應寫清版本、提示格式、快取開關及預熱方式。相同文字若經過不同模板，實際送進模型的 Token（模型處理文字的小單位）也可能不同。

哪種工作適合先試？一份長紀錄，同時做路由、優先級與條件檢查，很符合共享樹幹的形狀。若每份文件都不同、各問同一題，仍可利用合批執行，但它測到的是另一種收益；不要把「共用題目文字」直接當成「共用完整文件」。想補排程觀念，可接著讀 Continuous Batching 與多槽 Context 教學。

三、9.5 倍應該怎麼讀？先問分母與考卷

官方 互動解說頁把 9.5 倍標在 Qwen3.5-0.8B 的 QuALITY 多題情境；作者在 2026 年 11 月 9 日的 HN 回覆補充，該工作負載平均約 5.8k Token、18 題。論文的測量硬體是一張 H200，單客戶端延遲採中位數，並另外報告併發吞吐。這些是作者報告的條件，不是對每張消費級 GPU 的承諾。

只有一題時，沒有「多個問題共用同一樹幹」這一項收益；仍可能因引擎開銷與 CUDA Graph（預先記錄 GPU 執行流程）而變快。究竟快多少，要回到你的模型、輸入長度和配置。把單題叫作反例，是用來檢查加速來源，不是預先宣布它一定輸。

四、Flide 教學上手：五步留下可比較的紀錄

①「我的機器能跑嗎？」先保存環境身分

官方安裝頁列出的環境為 Linux、NVIDIA GPU、Python 3.10 以上與 PyTorch 2.12 以上。以下使用 Python 3.12 與既有的 uv；若還沒有相符 GPU，先完成前面的負載分類即可。RTX 3050 是否放得下你的實際長文件，要看顯存、模型與啟動紀錄，不能只憑卡名判定。

nvidia-smi
python3 --version
uv --version
uv venv -p 3.12
source .venv/bin/activate
uv pip install "flide==0.1.11"
uv pip freeze > environment.txt

這是純文字練習；圖片、影片流程再依官方指引安裝與 torch 同來源的 torchvision。若驅動只支援 CUDA 12，安裝頁另有先裝 cu126 版 torch 的路徑；不要把不相容的 CUDA 13 套件當成模型故障。保存 nvidia-smi 輸出，日後才能比較同一張卡與驅動。

②「從哪個模型開始？」先打通一條最小流程

採用官方 Quickstart 的小型 checkpoint OmniJev/OneJev1.6-0.8B。它適合先檢查 API 是否串通；繁中客服品質要另做標註測試。本篇沒有替它排模型能力名次。第一次啟動會取得模型，先確認網路、儲存空間與該 checkpoint 的模型卡。

flide serve --model OmniJev/OneJev1.6-0.8B --host 127.0.0.1 --port 8000

保持這個終端開著，另開一個終端執行 curl -fsS http://127.0.0.1:8000/health，把輸出存進紀錄；載入中可能回 503。--host 127.0.0.1 把本次服務綁在本機，這是 官方 serve 參數明確提供的設定。

③「每次考卷一樣嗎？」生成固定的 1／4／16 題

下面是我們編寫的合成設備清單：奇數設備 normal，偶數設備 fault。它是容易核答案的短輸入，用來熟悉流程；長文件的效能評估，請再替換成有權使用、移除個資的同一份長文件，並重寫對應題目。不能用這份短清單替代 QuALITY 長文結果。將以下程式存為 prepare.py，執行 python prepare.py。

import json, hashlib
from pathlib import Path
state = "\n".join(
    f"Equipment {i:02d}: {'normal' if i % 2 else 'fault'}."
    for i in range(1, 17))
questions = {
    f"q{i:02d}": {"type": "choice",
        "instructions": f"What status is explicitly reported for Equipment {i:02d}?",
        "criteria": {"normal": "normal", "fault": "fault",
                     "unknown": "status not stated"}}
    for i in range(1, 17)}
rows = []
for n in (1, 4, 16):
    row = {"state": state, "questions": dict(list(questions.items())[:n])}
    Path(f"request-{n}.json").write_text(json.dumps(row))
    rows.append(row)
for key, question in questions.items():
    Path(f"solo-{key}.json").write_text(json.dumps(
        {"state": state, "questions": {key: question}}))
different = [{"state": f"Equipment {i:02d}: normal.",
    "questions": {"status": {"type": "choice",
        "instructions": "What status is reported for the listed equipment?",
        "criteria": {"normal": "normal", "fault": "fault"}}}}
    for i in range(1, 17)]
Path("many-inputs.json").write_text(json.dumps({"requests": different}))
Path("requests.jsonl").write_text("\n".join(
    json.dumps(r) for r in rows + different) + "\n")
Path("manifest.json").write_text(json.dumps({
    "state_sha256": hashlib.sha256(state.encode()).hexdigest(),
    "expected": {f"q{i:02d}": "normal" if i % 2 else "fault"
                 for i in range(1, 17)}}))
print("Prepared requests and manifest.json")

成功後會得到三份共用輸入請求、16 份逐題請求、不同輸入的合批反例，以及 manifest.json。先開 request-4.json：四個 question 各有 key，但 state 只出現一次。雜湊值像文件指紋；換了文字就要另存新一輪紀錄。

④「快的是哪一段？」把整組時間與每題成本分開

for n in 1 4 16; do
  curl -fsS http://127.0.0.1:8000/v1/systemone \
    -H "Content-Type: application/json" \
    --data-binary "@request-${n}.json" \
    -o "response-${n}.json" -w "${n} questions: %{time_total}s\n"
done

第一次先當預熱，不列成績。正式記錄可重複 30 輪、輪換測量順序，把每輪回應另存新檔，保留中位數和較慢那一端的分布。這裡的 time_total 包含本機 HTTP 傳輸與等待；回應的 meta 是伺服器自述的內部分段時間，兩者分開保存。

再以同樣 curl 呼叫 solo-q01.json 到 solo-q16.json，相加 16 次時間，對照 request-16.json 的整組時間；這是「逐題 HTTP」與「一次多題」的端到端比較，包含呼叫次數差異，不能全歸功於 GPU 核心。把 many-inputs.json 送到同一端點，則會從 results 讀取多份結果；它是不同文件合批的對照。

⑤「答案相同就過關嗎？」再查機率與批次一致性

先看回應 answers.q01.choice 是否為 normal，q02 是否為 fault；接著比較同題單問和合問時，probabilities 裡每個選項的差值。選項都沒翻轉，只能證明這批 top answer 相同，不能證明每個機率完全一致，更不能證明它理解了真實維修情境。

用 官方 flide verify做下一層檢查。先結束剛才的服務以釋放 GPU 顯存，再執行以下兩條，分別保存輸出與退出狀態；兩次載入使用同一個模型。

flide verify --model OmniJev/OneJev1.6-0.8B --requests requests.jsonl
flide verify --model OmniJev/OneJev1.6-0.8B --requests requests.jsonl --batch-invariant

verify 會比較分叉與逐題獨立執行，也會改變請求合批方式。依官方判定規則，top answer 翻轉是否計為失敗，還看參考答案前兩個選項的差距；因此讀 PASS 時要連同最大機率差值一起看。--batch-invariant 另檢查逐位元一致，不能把一般模式的 PASS 解讀成所有數字完全一樣。

最後把服務以原命令加上 --batch-invariant 重新啟動，再重做延遲紀錄。官方明示這個選項會付出一些速度代價；你要量的是「所需一致性下的速度」。本輪先維持 session cache 預設關閉；需要測多輪 Agent 歷史續接時，再另外開啟並把顯存預算寫進配置。

五、五個常見坑：把公平比較寫成操作規矩

• 只看一個倍率。每輪同時保存題數、輸入長度、模型 revision、套件版本、GPU、精度和開關，先找相同條件的列。
• 換模型又換引擎。先固定 checkpoint 與提示格式，再改合問／單問；模型品質另開一張考卷。
• 把機率當正確率。高機率是模型的輸出，不是經過真實樣本校準後的成功率。固定人工標籤，另算錯誤類型。
• 只量暖機前的一次。首次模型下載、核心編譯與 CUDA Graph 準備另記；正式延遲要有多輪，請求錯誤也要保存。
• 把不同文件合批當成狀態共用。核對每個 state 的內容指紋。共同系統提示可能仍有快取價值，但完整文件是否相同，是另一個判斷。

若收到 422，先讀 detail 的欄位位置與訊息，再檢查 JSON 形狀、長度或選項數；若只是回答文字寫「出錯」，不要直接判定 HTTP 失敗。這一層可參考 AI 錯誤排查：HTTP、串流、工具與回答文字。

六、FAQ：先給判斷，再說條件

1. 單題一定不會加速嗎？

不一定。單題仍可能受益於較低執行開銷；多題狀態共享則是另一項機制。用自己的單題列作基準。

2. 很多文件各問同一題，可以用嗎？

可以依官方 requests 陣列合批。但應以不同輸入的吞吐與延遲驗收，別沿用一份長文多題的倍率。

3. Exact 代表回答一定正確嗎？

不是。它描述分支計算相對獨立執行的等價性；設備判斷是否符合事實，仍看人工標籤。

4. 一般模式每個機率都逐位元相同嗎？

不能這樣預設。官方 FAQ 明說有浮點捨入差異；對批次負載下的逐位元一致有要求時，另測 batch-invariant。

5. RTX 3050 能直接套用 H200 的數字嗎？

不能直接換算。先檢查顯存與服務啟動，再量相同文件和題數；本篇沒有該卡的實測紀錄。

6. 小模型跑通就能上線繁中客服嗎？

還不夠。這份英文合成清單驗的是資料流；實際語言、模糊敘述與錯誤成本需要自己的樣本。

7. 為什麼不直接把所有問題串成一段？

要先驗證語意是否改了。Flide 的分叉設計讓各題各讀共同材料；普通串接可能讓後題讀到前題，與獨立提問形成不同考卷。

8. 我現在應該選 Flide，還是原本的引擎？

先看負載。長材料有多個獨立分類問題，值得把 Flide 加入候選；主要工作是長篇自由生成時，先以自己的生成需求與既有服務作對照。

給新手的三個重點

第一，畫出「一份材料接幾題」，再談加速。第二，先核對答案，再看機率差值，最後看時間。第三，保留原請求、原回應與環境身分；下次換版本，才能知道變化來自哪裡。把這份小流程接回產品，可參考 建立 Agent Harness 的實作拆解。