Pinned Tweet
我真的在家里装了一个数据中心。
Rackmate T1 机柜里放着两台 DGX Spark，再加一台 M4 Mac mini。
256GB 统一内存，TP=2，接近 Opus 的性能。
这几位随时都能听我调遣：
GLM-5.3-Flash EXL3
Qwen3.8-Flash-Next
DeepSeek V4 0731 Flash
没有机房噪音，没有五小时限额，也不会按 token
它们随时接受我的命令，不会因为地区、账号和额度突然拒绝工作，也不会把我的代码、数据和隐私送上云端。
Codex 何时 reset 跟我无关，不用跪求 Tibo。
Claude 何时封号跟我无关，不用看 Dario 脸色。
可以把专注力集中起来， build 自己的东西。
模型出错了我自己修，机器和数据都掌握在自己手里。
从今天起，我的 AI 跑在自己家里。
Rackmate T1 机柜里放着两台 DGX Spark，再加一台 M4 Mac mini。
256GB 统一内存，TP=2，接近 Opus 的性能。
这几位随时都能听我调遣：
GLM-5.3-Flash EXL3
Qwen3.8-Flash-Next
DeepSeek V4 0731 Flash
没有机房噪音，没有五小时限额，也不会按 token
它们随时接受我的命令，不会因为地区、账号和额度突然拒绝工作，也不会把我的代码、数据和隐私送上云端。
Codex 何时 reset 跟我无关，不用跪求 Tibo。
Claude 何时封号跟我无关，不用看 Dario 脸色。
可以把专注力集中起来， build 自己的东西。
模型出错了我自己修，机器和数据都掌握在自己手里。
从今天起，我的 AI 跑在自己家里。
207
41
787
84,169
DGX Spark 和 Mac 怎么选，先看你的活是读得多还是写得多。
同一个 Qwen3.8-27B Q4 文件，llama.cpp，单路，DGX Spark 对 M4 Max 128GB 的 MacBook Pro：
64K 上下文、回答 2K token，Spark 5 分钟、17 kJ，Mac 10 分钟、23 kJ。
4K prompt、回答 8K token，Spark 12 分钟、33 kJ，Mac 7 分钟、19 在每个上下文长度都快 2.7 到 6.5 倍。64K 上下文，Spark 88 秒开始出字，Mac 要 7 分半。
Mac 写得快，32K 以内 decode 快 1.7 倍左右。M4 Max 内存带宽 546 GB/s，Spark 是 273 GB/s，decode 主要吃带宽。
两边同时跑完的回答长度，随上下文变长一路往上走。4K 上下文时 457 token，32K 时 4071，128K 时 5.88 万。到 256K，Spark 每个请求都赢。
跑 agent 写代码，每轮带几万 token 上下文、回答几百到几千 token，这是 Spark 的强项。上下文短、生成长的聊天和写作，Mac 更快也更省电。
这组数据只算了芯片功耗，没算插座。Spark 跑的是 llama-server，Mac 跑的是 llama-bench，配平的重测还在排队。
同一个 Qwen3.8-27B Q4 文件，llama.cpp，单路，DGX Spark 对 M4 Max 128GB 的 MacBook Pro：
64K 上下文、回答 2K token，Spark 5 分钟、17 kJ，Mac 10 分钟、23 kJ。
4K prompt、回答 8K token，Spark 12 分钟、33 kJ，Mac 7 分钟、19 在每个上下文长度都快 2.7 到 6.5 倍。64K 上下文，Spark 88 秒开始出字，Mac 要 7 分半。
Mac 写得快，32K 以内 decode 快 1.7 倍左右。M4 Max 内存带宽 546 GB/s，Spark 是 273 GB/s，decode 主要吃带宽。
两边同时跑完的回答长度，随上下文变长一路往上走。4K 上下文时 457 token，32K 时 4071，128K 时 5.88 万。到 256K，Spark 每个请求都赢。
跑 agent 写代码，每轮带几万 token 上下文、回答几百到几千 token，这是 Spark 的强项。上下文短、生成长的聊天和写作，Mac 更快也更省电。
这组数据只算了芯片功耗，没算插座。Spark 跑的是 llama-server，Mac 跑的是 llama-bench，配平的重测还在排队。
1
0
0
166
完整的打平点表格和两张图：
x.com/danpacary/stat…
x.com/danpacary/stat…
DGX Spark vs Mac
performance as a function of time & energy
64k of context, 2k-token answer:
DGX Spark: 5 min, 17 kJ
MacBook Pro M4 Max: 10 min, 23 kJ
4k prompt, 8k-token answer:
DGX Spark: 12 min, 33 kJ
MacBook Pro M4 Max: 7 min, 19 kJ
same Qwen3.8-27B file, llama.cpp on bothwins one request outright, on the clock and on joules
so i found the line. answer length where the two tie, joules | time:
512 context: 55 | 38 tokens
4k: 248 | 457
16k: 1,071 | 1,809
32k: 1,971 | 4,071
64k: 4,640 | 11.5k
128k: 17.5k | 58.8k
256k: never | never. the Spark wins every request
the Spark reads 2.2-2.8x cheaper and 2.7-6.5x faster at every depth
the Mac writes 1.6-1.9x cheaper up to 64k and ~1.7x faster up to 32k. by 256k the Spark writes faster too
at 64k the Spark starts answering in 88 s. the Mac takes 7.5 min
64k context with an 8k answer is the odd one: the Spark finishes first, the Mac spends fewer joules
chip watts only, Spark GPU module vs Mac SoC. no wall plug yet. and the Spark ran llama-server while the Mac ran llama-bench, matched rerun queued
Qwen3.8-27B UD-Q4_K_XL · llama.cpp · f16 KV · flash attn · DGX Spark GB10 vs M4 Max 128GB
0
0
1
64
比量化版本，tok/s 只是一半，另一半是修好一个 bug 要多少 token、多少分钟。
有一组测试很实在。9 个真实的回归 bug，来自一个 C++/CUDA 推理引擎的私有提交历史，从没公开过。agent 只能读代码找原因、写补丁，不能编译运行，每题跑 3 轮，Claude Opus 5 盲评打分。
本地模型跑在两张 RTX 5070 Ti laude Code。
Qwen3.8-27B 的 3-bit 和 NVFP4 比，分数差 0.05，在误差范围内。可 3-bit 每题多用 40% 的 token。它 decode 更快，153 对 132 tok/s，每题却要 18 分钟，NVFP4 是 13 分钟。其中一部分是 3-bit prefill 慢，修好后重跑还是多 30% 的 token。
Flash-Next 只把专家压到 3 bit，分数差 0.02，token 只多 3%，基本没损失。
和 Claude 放一起，Flash-Next NVFP4 拿 0.50，和 Haiku 5.5 的 0.47 一档，高于 Sonnet 5 的 0.28。Sonnet 5.5 是 0.58，每题只用 8k token、1 分钟左右，Flash-Next 要 53k token、10 分钟。Opus 5.5 拿 0.74，领先所有模型。
只有 9 题，置信区间大约 ±0.2，差距在 0.1 以内基本算打平。
自己挑量化，可以拿手头真实任务记三样：做对没有、用了多少 token、花了几分钟。
有一组测试很实在。9 个真实的回归 bug，来自一个 C++/CUDA 推理引擎的私有提交历史，从没公开过。agent 只能读代码找原因、写补丁，不能编译运行，每题跑 3 轮，Claude Opus 5 盲评打分。
本地模型跑在两张 RTX 5070 Ti laude Code。
Qwen3.8-27B 的 3-bit 和 NVFP4 比，分数差 0.05，在误差范围内。可 3-bit 每题多用 40% 的 token。它 decode 更快，153 对 132 tok/s，每题却要 18 分钟，NVFP4 是 13 分钟。其中一部分是 3-bit prefill 慢，修好后重跑还是多 30% 的 token。
Flash-Next 只把专家压到 3 bit，分数差 0.02，token 只多 3%，基本没损失。
和 Claude 放一起，Flash-Next NVFP4 拿 0.50，和 Haiku 5.5 的 0.47 一档，高于 Sonnet 5 的 0.28。Sonnet 5.5 是 0.58，每题只用 8k token、1 分钟左右，Flash-Next 要 53k token、10 分钟。Opus 5.5 拿 0.74，领先所有模型。
只有 9 题，置信区间大约 ±0.2，差距在 0.1 以内基本算打平。
自己挑量化，可以拿手头真实任务记三样：做对没有、用了多少 token、花了几分钟。
3
0
3
362
8 台 DGX Spark 跑 DeepSeek-V4.1-Flash-1017，单路写代码 99.85 tok/s，比两台还慢。
这组用的是 SGLang，TP8/EP8，200GbE RoCE 互联，配成 1M 上下文。两台 Spark 那份配方单路代码是 118.1，其中一台锁 1,800 MHz 时是 108.1。引擎和量化都不一样，只能看个大概。
多出来的 6 台换来的是并发。8 散文 174.95，这个数含了 prefill 和排队。
单个请求不会因为机器多就变快。我的理解是 TP 切得越细，每层要过网络同步的次数越多，单路速度反而被拖住。
长上下文也一样。100K 的代码上下文，从 4 路加到 8 路，吞吐只多了 6%，首字延迟中位数从 64 秒涨到 114 秒。
单人用的话，两台够了。
这组用的是 SGLang，TP8/EP8，200GbE RoCE 互联，配成 1M 上下文。两台 Spark 那份配方单路代码是 118.1，其中一台锁 1,800 MHz 时是 108.1。引擎和量化都不一样，只能看个大概。
多出来的 6 台换来的是并发。8 散文 174.95，这个数含了 prefill 和排队。
单个请求不会因为机器多就变快。我的理解是 TP 切得越细，每层要过网络同步的次数越多，单路速度反而被拖住。
长上下文也一样。100K 的代码上下文，从 4 路加到 8 路，吞吐只多了 6%，首字延迟中位数从 64 秒涨到 114 秒。
单人用的话，两台够了。
9
0
14
3,083
同一个 GLM-5.3-Flash，两张 RTX PRO 6000 单路跑到 245 tok/s，我两台 DGX Spark 是 62.2。
Mia 这组用的是 TensorFold，4 bpw 的 EXL3，和 Spark 上是同一份量化，两张卡都限在 400W：
1. 单路 245 tok/s
2. 2 路合计 336
3. 4 路合计 436
4. prefill 从 4K 到 64K 大约 6000 tok/s，256K 还有 5503
计 104.6。单路差了将近 4 倍，4 路差 4 倍多。两边测法不完全一样，我这边开了 MTP，看量级就行。
差距主要在带宽。PRO 6000 单卡 1.79 TB/s，Spark 是 273 GB/s，差了 6 倍多。
PRO 6000 我是 9000 买的，两张就是 1.8 万美元，两台 Spark 不到 9000。这 4 倍速度是拿钱换的。
Mia 这组用的是 TensorFold，4 bpw 的 EXL3，和 Spark 上是同一份量化，两张卡都限在 400W：
1. 单路 245 tok/s
2. 2 路合计 336
3. 4 路合计 436
4. prefill 从 4K 到 64K 大约 6000 tok/s，256K 还有 5503
计 104.6。单路差了将近 4 倍，4 路差 4 倍多。两边测法不完全一样，我这边开了 MTP，看量级就行。
差距主要在带宽。PRO 6000 单卡 1.79 TB/s，Spark 是 273 GB/s，差了 6 倍多。
PRO 6000 我是 9000 买的，两张就是 1.8 万美元，两台 Spark 不到 9000。这 4 倍速度是拿钱换的。
5
1
13
2,804
Mia 的数据：x.com/MiaAI_lab/stat…
Run GLM 5.3 Flash on your @NVIDIAAI 2x RTX PRO 6000s with ease, on TensorFold 🔥
These cards are monsters, and it shows. It uses the same 4 bpw EXL3 quant as on the DGX Sparks. All numbers below are at 400W.
ABLIT flag included (gated)!!!
Performance (non-greedy, thinking on):
stream
- 336 tok/s on 2 concurrent streams
- 436 tok/s on 4 concurrent streams
Prompt processing (prefill):
- 4k-64k: ~6000 tok/s
- 128k: 5785 tok/s
- 256k: 5503 tok/s
IMO this is the best thing to run on 2x RTX PRO 6000's. If you increase the watts, prefill will go even more brrrrrr.
Link below.
0
0
0
186
我两台 DGX Spark 都是 $4,499 买的，现在看确实买得早。
Spark 的 273 GB/s 就是这条 8533 MT/s 的 LPDDR5X 撑起来的。本地跑大模型，decode 基本跟着带宽走，同样 128GB 降到 6400，出字就慢四分之一。
这个差价我觉得该花。
Spark 的 273 GB/s 就是这条 8533 MT/s 的 LPDDR5X 撑起来的。本地跑大模型，decode 基本跟着带宽走，同样 128GB 降到 6400，出字就慢四分之一。
这个差价我觉得该花。
Look at this price.
It makes you realize just how crazy cheap the $4k DGX Spark and 128GB MacBook Pro were before the price hike.
DGX Spark runs on that exact LPDDR5X 8,533MT/s memory.
MacBook Pro uses 9,600MT/s.
3
1
0
293
跑 agent 写代码，买机器先算上下文吃多少内存，再算权重。
Qwen3.8-27B 的 64 层里只有 16 层是全注意力，按 config 算，每个 token 的 KV 是 64 KB（BF16）。16 万 token 就是 10 GB 出头，256K 拉满 16 GB，和 4-bit 权重差不多大。
一份 64GB M4 Max 的实测很能说明问题。16 万 token 8 GB，系统只剩 150 MB 左右。权重和 KV 之外，prompt cache 看起来又存了一份上下文，再加上线性注意力的检查点和 prefill 留下的缓冲。
这台机器能用全靠 prompt cache，命中率 93%，每轮只处理 1K 左右新 token。一旦没命中，整段重新 prefill 要 20 分钟。
架构差别也很大。GLM-5.3-Flash 45 层里只有 11 层存 KV，每层只存 512 维，BF16 下每个 token 11 KB，256K 不到 3 GB。
以前说 64GB 是尴尬档位，是按权重算的。agent 会话动不动十几万 token，上下文和权重一样占地方，选机器、选模型都要把这笔账算进去。
Qwen3.8-27B 的 64 层里只有 16 层是全注意力，按 config 算，每个 token 的 KV 是 64 KB（BF16）。16 万 token 就是 10 GB 出头，256K 拉满 16 GB，和 4-bit 权重差不多大。
一份 64GB M4 Max 的实测很能说明问题。16 万 token 8 GB，系统只剩 150 MB 左右。权重和 KV 之外，prompt cache 看起来又存了一份上下文，再加上线性注意力的检查点和 prefill 留下的缓冲。
这台机器能用全靠 prompt cache，命中率 93%，每轮只处理 1K 左右新 token。一旦没命中，整段重新 prefill 要 20 分钟。
架构差别也很大。GLM-5.3-Flash 45 层里只有 11 层存 KV，每层只存 512 维，BF16 下每个 token 11 KB，256K 不到 3 GB。
以前说 64GB 是尴尬档位，是按权重算的。agent 会话动不动十几万 token，上下文和权重一样占地方，选机器、选模型都要把这笔账算进去。
3
1
6
989
5 个 Qwen3.8-27B 分工写算法题，LiveCodeBench Hard 前 10 题跑 5 轮，平均做对 9.8 题，Fable 5 单次调用是 8.0。
每个模型只管一段：
1. 一个做规划
2. 两个各出一种解法思路
3. 一个写代码
4. 跑完样例，一个看结果写修改意见，一个按意见修
件交流。原论文认为提升主要来自这条规矩。
这是 Memdoor 的 team-solve 工作流，8 个 YAML 文件，不用写代码。模型可以换成本地的 Ollama、llama.cpp、vLLM、LM Studio，用 Ollama 要把上下文窗口调到 32K，默认的 4K 不够。
限制也要看清。只测了 10 题，和论文作者自己 harness 的 9.6 在误差范围内。题目是 2025 年春天的，模型可能见过。这次跑在 OpenRouter 上，每题中位 40 分钟、0.39 美元。
有测试能判对错的任务，让小模型多花时间多轮自查很划算。
每个模型只管一段：
1. 一个做规划
2. 两个各出一种解法思路
3. 一个写代码
4. 跑完样例，一个看结果写修改意见，一个按意见修
件交流。原论文认为提升主要来自这条规矩。
这是 Memdoor 的 team-solve 工作流，8 个 YAML 文件，不用写代码。模型可以换成本地的 Ollama、llama.cpp、vLLM、LM Studio，用 Ollama 要把上下文窗口调到 32K，默认的 4K 不够。
限制也要看清。只测了 10 题，和论文作者自己 harness 的 9.6 在误差范围内。题目是 2025 年春天的，模型可能见过。这次跑在 OpenRouter 上，每题中位 40 分钟、0.39 美元。
有测试能判对错的任务，让小模型多花时间多轮自查很划算。
3
0
5
850
Qwen3.8-Flash-Next 的 FP4-Local 跑 tool-eval，104 个场景 87 个通过、10 个部分通过，总分 88。
选工具、填参数、多步调用全满分。扣分在代码模式 66.7% 和安全 73.1%，4 条安全警告把评级压到 Adequate。
给 agent 选量化，总分之外要单看安全这几项。
选工具、填参数、多步调用全满分。扣分在代码模式 66.7% 和安全 73.1%，4 条安全警告把评级压到 Adequate。
给 agent 选量化，总分之外要单看安全这几项。
I'm on the search for the best Qwen3.8-Flash-Next quant. ICurrently using FP4-Local. I ran tool-eval bench on FP4-Local, and I'm not happy with the score.
It has a total of 7 failures. If you know a better quant, let me know!!
2
1
5
1,519
显存装不下的 MoE，让 CPU 分担一部分专家，Qwen3.8-Flash-Next 在一张 4090 上从 29.8 tok/s 跑到了 97.3 tok/s。
这是 tandem.cpp，一组给 llama.cpp 打的补丁，刚开源。测试机是 i5-12400F、64GB DDR4、RTX 4090，模型是 78 GiB 的 IQ3_S 量化，开着 MTP。模型比内存还大，只能边读文件边跑。
快 . llama.cpp 默认怎么放
默认按层分。稠密部分全放 GPU，再把能放下的若干层专家放进显存，剩下那些层的专家留在内存里由 CPU 算。
这个分法是固定的，哪些专家常用、哪些几乎不用，它不管。每生成一个 token，CPU 都要从内存里把用到的专家读一遍，这台机器的内存带宽只有 43 GB/s。
2. tandem 改成缓存
所有专家放内存，显存剩下的空间当缓存，放最近用过的专家。
专家的使用并不平均，常用的那一批会被反复选中，缓存很容易命中。另一组测试里，EPYC 服务器配 RTX PRO 6000 跑 DeepSeek-V4.1-Flash，显存里缓存了 87 GiB 专家，命中率 98.7%。
3. 没命中的专家怎么办
两条路：CPU 直接算，或者经 PCIe 传进显存再让 GPU 算。
tandem 按实测的 CPU 速度和 PCIe 速度，把这些专家分成两份。一份交给 CPU 算，GPU 同时在算缓存里的专家，另一份上传进缓存。两边同时干活，谁都不闲着。
4. 投机解码在这里特别值
MTP 一次猜好几个 token，再让大模型一起验证。几个 token 用到的专家各不相同，验证一次要算的专家就变多了。
专家大多在内存里时，多验证几个 token 的成本和一个个生成差不多。所以在一台 10 核 DDR4 工作站上，llama.cpp 开 MTP 基本没提速。专家大多在显存里，一次验证几个 token 才划算，3.3 倍里很大一部分来自这里。
CPU 太弱也会拖后腿。6 核机器上给 gpt-oss-120b 加 EAGLE3 草稿，两个引擎都变慢了，CPU 要算的专家跟着变多。
5. 结果对不对
关掉默认优化时，计算和 llama.cpp 完全一致。开着默认优化，和整个模型放 GPU 的 llama.cpp 比，KL 散度 0.0093，差别只来自浮点舍入。
代价是 greedy 输出每次不完全一样。缓存里有哪些专家取决于时序，CPU 和 GPU 的舍入也不同，准确率不受影响。它也只为单用户优化，多并发收益小。
6. 什么情况下有用
模型差一点就放得下时收益很小。Qwen3.6-35B-A3B 整个放进 48GB 显卡时只快 4%，显存预算压到 8 GB 就快 44%。
模型比内存还大、要从 SSD 读专家时，现在反而比 llama.cpp 慢，作者说会修。
DGX Spark、Mac 这类统一内存的机器用不上，专家本来就在 GPU 能直接读的内存里。最受益的是一张大显存卡配大内存的台式机和服务器。RTX PRO 6000 加 EPYC 跑 DeepSeek-V4.1-Flash，带上 DSpark 草稿，从 63.0 到 132.4 tok/s。
显存装不下的 MoE，速度取决于常用专家能不能留在 GPU 上，没命中的那部分能不能让 CPU 和 PCIe 一起分担。
这是 tandem.cpp，一组给 llama.cpp 打的补丁，刚开源。测试机是 i5-12400F、64GB DDR4、RTX 4090，模型是 78 GiB 的 IQ3_S 量化，开着 MTP。模型比内存还大，只能边读文件边跑。
快 . llama.cpp 默认怎么放
默认按层分。稠密部分全放 GPU，再把能放下的若干层专家放进显存，剩下那些层的专家留在内存里由 CPU 算。
这个分法是固定的，哪些专家常用、哪些几乎不用，它不管。每生成一个 token，CPU 都要从内存里把用到的专家读一遍，这台机器的内存带宽只有 43 GB/s。
2. tandem 改成缓存
所有专家放内存，显存剩下的空间当缓存，放最近用过的专家。
专家的使用并不平均，常用的那一批会被反复选中，缓存很容易命中。另一组测试里，EPYC 服务器配 RTX PRO 6000 跑 DeepSeek-V4.1-Flash，显存里缓存了 87 GiB 专家，命中率 98.7%。
3. 没命中的专家怎么办
两条路：CPU 直接算，或者经 PCIe 传进显存再让 GPU 算。
tandem 按实测的 CPU 速度和 PCIe 速度，把这些专家分成两份。一份交给 CPU 算，GPU 同时在算缓存里的专家，另一份上传进缓存。两边同时干活，谁都不闲着。
4. 投机解码在这里特别值
MTP 一次猜好几个 token，再让大模型一起验证。几个 token 用到的专家各不相同，验证一次要算的专家就变多了。
专家大多在内存里时，多验证几个 token 的成本和一个个生成差不多。所以在一台 10 核 DDR4 工作站上，llama.cpp 开 MTP 基本没提速。专家大多在显存里，一次验证几个 token 才划算，3.3 倍里很大一部分来自这里。
CPU 太弱也会拖后腿。6 核机器上给 gpt-oss-120b 加 EAGLE3 草稿，两个引擎都变慢了，CPU 要算的专家跟着变多。
5. 结果对不对
关掉默认优化时，计算和 llama.cpp 完全一致。开着默认优化，和整个模型放 GPU 的 llama.cpp 比，KL 散度 0.0093，差别只来自浮点舍入。
代价是 greedy 输出每次不完全一样。缓存里有哪些专家取决于时序，CPU 和 GPU 的舍入也不同，准确率不受影响。它也只为单用户优化，多并发收益小。
6. 什么情况下有用
模型差一点就放得下时收益很小。Qwen3.6-35B-A3B 整个放进 48GB 显卡时只快 4%，显存预算压到 8 GB 就快 44%。
模型比内存还大、要从 SSD 读专家时，现在反而比 llama.cpp 慢，作者说会修。
DGX Spark、Mac 这类统一内存的机器用不上，专家本来就在 GPU 能直接读的内存里。最受益的是一张大显存卡配大内存的台式机和服务器。RTX PRO 6000 加 EPYC 跑 DeepSeek-V4.1-Flash，带上 DSpark 草稿，从 63.0 到 132.4 tok/s。
显存装不下的 MoE，速度取决于常用专家能不能留在 GPU 上，没命中的那部分能不能让 CPU 和 PCIe 一起分担。
5
2
41
4,838
RTX Spark 笔记本拔着电源跑 Nemotron 3.5 Bolt，写代码能到 100 tok/s。
用的是 TensorFold，加上 NVIDIA 的 LiLiCorr 草稿模型，代码最多快 2.8 倍。移植和修 bug 的 PR 还在等合并。
代码里重复的结构多，草稿模型容易猜中，投机解码在写代码时收益最大。
用的是 TensorFold，加上 NVIDIA 的 LiLiCorr 草稿模型，代码最多快 2.8 倍。移植和修 bug 的 PR 还在等合并。
代码里重复的结构多，草稿模型容易猜中，投机解码在写代码时收益最大。
NVIDIA's Nemotron 3.5 Bolt soon to run natively on a Windows laptop. On battery!!
It's TensorFold on an RTX Spark N1X. Add @MiaAI_lab's recipe and NVIDIA's LiLiCorr drafter, and code comes out up to 2.8x faster, at 100 tok/s.
My port and a bug fix are up as PRs. Links below
1
0
3
840