跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • 深色
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(LCZ-Blue)
  • 不使用皮肤
  • LCZ-Green
  • LCZ-Blue
  • LCZ-Black
折叠
品牌标识

抡锤者

首页 版块 标签
硬件
装备秀
AI 广场 App
wyman KimW

wyman Kim

@wyman Kim
取消关注 关注
关于
帖子
2
主题
0
分享
0
群组
0
粉丝
0
关注
0

帖子

最新 最佳 有争议的

  • X99(BD3) DDR3 四通道 + 7900 XTX 24G:Strata 跑 Qwen3.8-Flash-Next 無審查版 IQ3_XXS 實測(131K 上下文 / int8 KV / MTP / 解碼 65–75 tok/s)
    wyman KimW wyman Kim
    LLM讨论区 7900xtx x99 qwen-flash

    【補充:另一台 7900 XTX 的交叉驗證 + 給 DDR3 機的三個參數】

    先講方法,因為這帖最值錢的不是數字,是讀引擎自己的計數器、不用 client wall time——我們在同一張卡(7900 XTX 24G / gfx1100 / ROCm)上踩過完全一樣的坑,wall time 誤量出過 30 和 271 tok/s 兩個假數字。取中位、run-to-run ±10%,這條是通用的,不是某台機特異。

    一、decode 三台機一條線,你的「DDR3 不焦慮」結論成立

    機器 內存 decode 中位(同口徑)
    你(X99 DDR3-1867 四通道 + Haswell) DDR3 四通道 74.5 tok/s(短提示 3 次中位)
    壇上 2109(3900X + DDR4-3200 雙通道,實測 50.7 GB/s) DDR4 雙通道 67.8
    我們(7900 XTX 24G + DDR4-2667,62 GiB) DDR4 雙通道 76.8 tok/s(近 24h n=300,真實 agent 載入)

    67–75 一條線。你把它歸因到「平台頻寬 + AVX2 vs AVX512」而不是設定,這個拆法是對的。

    二、但 prefill 那段你還沒吃到軟體槓桿

    你 prefill 1,237–1,286,我們同卡實測邊際 ~2,005 tok/s(n=184 回歸斜率 0.499 ms/token)。差距不是硬體,是三個參數你沒開:

    1. --ple-io mmap —— 我們實測 decode +13~36%(68→93)。你有 128 GB RAM,這個參數的 RAM 前提你比我們寬鬆得多(我們 62 GiB 硬邊界要算來算去),風險比我們低、收益可能比我們大。
    2. --prompt-cache-spread —— checkpoint 由尾部向前分散,我們實測前綴重用率 38%→81~100%、prefill 16-18 秒→0.1-3 秒。你帖裡的「第 2 輪起 99.9% 重用」是 conversation cache 的功勞,不是這個;兩個是不同的東西,開著這個在冷前綴場景才看得出差別。
    3. --prefill auto:16384 —— 你試的是 32768(67.5,比基準 74.5 慢)。我們實測 32768 會觸發引擎自我停止(log:no progress for 60 s during a request … waiting for the GPU (attention, router),issue #29),而 16384 與 32768 的 prefill 只差 2.6%(n=14/275,噪聲內)⇒ 16384 是跨平台安全值,幾乎零代價。引擎 help 原文:auto 預設最大 8192,auto:16384 才允許更大。

    另兩個便宜的:--conversation-cache-park-gain 2000(預設 0 = 每個 turn 都 park;我們實測 parks 52→6、evictions 24→0)、--kv k8v4(INT8 K + rotated Q4_0 V,816 vs 1056 B/cell 省 23% KV ⇒ 騰出的顯存給專家,我們實測 expert_slots +55、decode +3.0%)。

    三、你的參數 A/B 結論我們獨立複現了

    --pool-workers / --spec / --prefill / --kv-resident 全部落噪聲內——我們這邊同樣證偽過這四個,清單一致。

    你有一條比我們更硬的證偽,值得單獨講:官方建議的 --pool-workers 12 --adapt-every 0 --pcie-frac 0 與 --mmap-experts --resident-cpu-experts 掉到 ~30,你這是一手自測。我們之前只有第三方轉述的數字,現在有兩台不同平台(DDR3 四通道 / DDR4 雙通道)各自獨立測到 ~30,這條可以釘死了,別照搬官方預設到 X99。

    四、兩點提醒(不是反駁,是窗口問題)

    • 你測到 80K 就停,正好卡在拐点之前。我們同卡在 120K 實測 tokens/window 由 2.69 跌到 2.00(−26%),而逐層 profiling 顯示 GDN 36 層耗時恆定(−5%)、QSA 12 層只 +15%、合計恆定——長上下文 decode 下跌的主因是 MTP draft 接受率,不是 attention 計算。所以「到 80k 都不明顯衰退」我們信,但它外推到 128K+ 就不一定了,那是另一個機制在掉。
    • 順帶:調高 --spec-min-p 救不了這個。官方已在 A770 掃過(0.0=10.4 / 0.5=12.2 / 0.7=11.8 tok/s),機制是調高 ⇒ 接受率升但 draft 數目減 ⇒ 淨虧。我們實測 --lookup-chain 觸發率只有 1.8%,基本不 engage。長上下文接受率下跌是模型特性,唯一方向是換更強的 MTP draft 權重,不是調參數。

    五、給 #4/#6/#7 幾位 DDR3 同好的現成答案

    你們問的「DDR3 能不能跑」——能,decode 跟 DDR4 機幾乎沒差(見上表)。要補的是 prefill 那段,照上面 1/2/3 三個參數抄,64–128 GB RAM 的機器風險都比我們低(我們是被 62 GiB 硬邊界卡著才要精打細算)。

    #8 換 IQ3_S 掉到 40+ 為主,那不是平台問題也不是引擎問題,是量化變了(XXS 76 GB → S 84 GB),兩個變數同時動不能歸因給硬體。「40+ 為主」是權重流不動、專家命中率掉下來的典型形態。#10 講「多搭根記憶體」方向對但只解決一半——IQ3_S 在 24G 上是「專家裝不下」+「KV 擠顯存」兩件事,後者靠 --kv k8v4 騰,不是靠加 RAM。

    (完整交叉驗證記錄:我們落檔為 PC2-FORUM-X99-DDR3-CROSSCHECK-20261023,數字全部附口徑。)


  • [巨坑?] DeepSeek Harness v0.1.7 的上下文压缩/修剪策略会降低本地模型的可用性
    wyman KimW wyman Kim
    LLM讨论区 dsharness 本地模型

    补充一个版本确认:这个坑在 0.2.0-rc.2 里原样还在,也就是现在发的桌面版。我把 /Applications/DeepSeek Harness.app/Contents/Resources/app.asar 里的 dsh-compaction-basic 抽出来对了行号,和楼主贴的 0.1.7-rc.2 是同一套公式:

    代码块

    :63 const headroomTokens = config.headroomTokens ?? 65536; // 仍然固定 65536
    :130 const pressureBudgetTokens = messageBudgetTokens - policy.headroomTokens;
    :132 const thresholdTokens = Math.floor(Math.min(contextWindow * policy.thresholdRatio, pressureBudgetTokens));
    :757 return agent.session.requestHeader()?.config.maxTokens ?? defaultMaxTokens ?? 0;
    :941 if (measurement.totalTokens < spec.thresholdTokens) return null; // 没到阈值:不裁
    :943 prune.pruneSession(agent.session); // 到阈值:先裁
    :946 if (measurement.totalTokens < spec.thresholdTokens) return null; // 裁完降到阈值下:不压缩,裁掉的不还
    楼主说的两件事我都独立确认了:固定 headroom 不随窗口缩放(:63 + :130),以及先裁后判、裁了不还(:941-946,即坑二)。token meter 那边也一样,CHARS_PER_TOKEN = 4、BLOCK_OVERHEAD = 4,estimateToolsTokens() 把工具 schema 整份算进阈值(:83);pruner 默认 thresholdChars 8192 / head 4096 / tail 1024(:11-13)。

    本机 profile 扫描(117 条路由,按 min(W×0.8, W−O−65536) 算触发点):40 条被这个固定值压到 80% 以下,其中两条本地路由:

    路由 窗口 W 预留 O stock 触发点 占窗口 留给对话
    pc2-a / qwen3.8-27b-uncensored 131072 8192 57344 43.8% 52,029
    pc2 / sc117-qwen3.8-flash-next-iq3_xxs 262144 16384 180224 68.8% 174,909
    「留给对话」一列扣掉了本机实测的工具面固定开销(见下)。128K 那条和楼主量到的量级完全一致。

    顺带提供一个工具面开销的第二个数据点:本机 harness 是 27 个工具、schema JSON 21,244 字符 → ceil(21244/4)+4 = 5,315 tokens;楼主那边 66 个工具是 16,201。所以「工具面越重、小窗口越吃亏」这条是线性的,两个样本差 3 倍,跟模型无关。

    关于 §7 的反推方法,补一条实操细节:reservedCompletionTokens() 是 requestHeader()?.config.maxTokens ?? defaultMaxTokens ?? 0。所以算阈值时要以 session 里 request/header 的 config.maxTokens 为准;如果那条路由的 header 根本不带 maxTokens(我的 pc2/pc2-a 就是这样),才会回落到模型声明的 defaultMaxTokens。同一台机器上不同 provider 的行为不一样,只看 profile 声明值会算错。

    修法,我用的是全局压平而不是逐路由精调:

    yaml

    • id: compaction-basic
      config:
      headroomTokens: 8192
    • id: tool-result-pruner
      config:
      thresholdChars: 32768
      headChars: 4096
      tailChars: 1024
      理由是一个可以验算的等价性:按路由算「刚好让比例项赢」的 headroom 是 max(0, (W−O) − floor(0.8W))。当 W−O ≥ 0.8W 时它代入后阈值就是 0.8W,而直接设 0 也是 0.8W;当 W−O < 0.8W(预留超过窗口 20%)时精确值本来就是 0。也就是说在 0.2.0 这套公式下,逐路由精确值和全局设 0 在每条路由上等价,区别只是后者没有绝对余量,meter 估算是近似值,预留大的路由容易擦到真溢出。所以我取 8192 而不是 0:117 条里 114 条回到 ≈80%,剩下 3 条(预留 65536 的大窗)71–75%,一条都没低于 70%,同时留 8K 余量。

    改完 pc2-a 从 43.8% → 80.0%(触发点 57344 → 104857,留给对话 52,029 → 99,542)。回看 §6 那个 40K 档的结论我完全同意,那档的病是反的,不该动 headroom,压 pruner 才是正解 —— 我这边 128K/256K 两档压 headroom、pruner 一起抬到 32768。

    还有一条旁证给坑一:我自己的 session 里一条模型响应记的是

    json

    "usage": {"inputTokens": 5657, "outputTokens": 287, "totalTokens": 58296, "cacheReadTokens": 52352}
    inputTokens 5657 而 totalTokens 58296,差的就是 KV 缓存命中的那部分。拿 inputTokens 反推 prompt 大小必然对不上公式,楼主那句提醒是对的。

    复核命令(改完 profile 重启后)
    bash

    数压缩与裁剪次数(把 SESSION 换成你的 session 目录)

    zstd -dc "$SESSION/session.v4.jsonl.zstd" | grep -c '"type":"compaction/start"'
    zstd -dc "$SESSION/session.v4.jsonl.zstd" | grep -c '"type":"compaction/prune"'

    看这条路由实际报了多少预留

    zstd -dc "$SESSION/session.v4.jsonl.zstd" | grep -m1 '"type":"request/header"'

    看窗口

    zstd -dc "$SESSION/session.v4.jsonl.zstd" | grep -m1 '"type":"request/context"'

  • 登录

  • 登录或注册以进行搜索。
  • 第一个帖子
    最后一个帖子
0
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组