WEBVTT
Kind: captions
Language: zh

00:00:00.166 --> 00:00:02.335
OK 今天来讲一下千问 3.8 27B

00:00:02.335 --> 00:00:04.771
这个模型我最近发现了一个新框架

00:00:04.938 --> 00:00:06.139
这个框架叫 NInfer

00:00:06.206 --> 00:00:07.907
在特定的长上下文再加

00:00:07.907 --> 00:00:09.743
上 MTP 的场景里面啊官方和

00:00:09.743 --> 00:00:12.479
社区的测试速度甚至能达到两倍

00:00:12.712 --> 00:00:15.081
那我自己这张 4090 到底能快多少呢

00:00:15.281 --> 00:00:16.249
看到最后你就知道了

00:00:16.416 --> 00:00:17.117
上上个星期我不是

00:00:17.117 --> 00:00:21.154
刚部署好千问 3.8 27B 嘛那时候用
的呢是 llama.cpp

00:00:21.287 --> 00:00:22.889
也是为了优化卯足了劲儿

00:00:22.922 --> 00:00:24.624
十几个小时的矩阵测试

00:00:24.724 --> 00:00:27.260
就是为了得到最好的那一个参数

00:00:27.360 --> 00:00:29.396
啊然后终于搞满意了固定下来了

00:00:29.429 --> 00:00:30.330
200K 上下文

00:00:30.497 --> 00:00:31.664
七八十 tokens 每秒

00:00:31.765 --> 00:00:33.400
那 llama.cpp 在这个阶段呢

00:00:33.400 --> 00:00:36.202
对于我自己的硬件而言基本上是被优化到顶了

00:00:36.469 --> 00:00:38.905
但是呢就在前两天我发现全白测了

00:00:39.005 --> 00:00:41.808
就是在研究 VLLM 或者 SGLang 这些框架的时候呢

00:00:41.808 --> 00:00:43.510
我发现了一个叫做 NInfer 的东西

00:00:43.576 --> 00:00:44.944
看大家的评价是非常的

00:00:44.944 --> 00:00:48.581
疯狂什么直接暴涨两倍的速度四舍九入那将像

00:00:48.581 --> 00:00:49.349
四舍九入

00:00:49.682 --> 00:00:52.585
四舍五入那就相当于多给了我一张 4090
啊

00:00:52.819 --> 00:00:54.454
嗯这还不赶紧部署起来试试

00:00:54.721 --> 00:00:57.557
于是呢我就让 GPT-5.6 Sol 写
了一个详细的方案

00:00:57.590 --> 00:00:59.859
一整套啊包括部署包括测试的方案

00:01:00.126 --> 00:01:03.129
然后把整个 plan 丢给我服务器上的
DeepSeek V4 Flash 去干

00:01:03.329 --> 00:01:05.498
V4 Flash 一个人是吭哧吭哧干了

00:01:05.498 --> 00:01:07.267
五个小时包括配置包括

00:01:07.267 --> 00:01:09.769
对 NInfer 的各种参数进行矩阵测试

00:01:09.836 --> 00:01:11.538
之后再和 llama.cpp 进行矩阵对
比

00:01:11.604 --> 00:01:12.305
我就出了个门

00:01:12.405 --> 00:01:13.873
然后回来他就直接给我

00:01:13.873 --> 00:01:16.509
交付了一份能用的最佳配置和整个对比

00:01:16.509 --> 00:01:17.177
结果的报告

00:01:17.310 --> 00:01:18.711
这感觉太爽了就

00:01:18.711 --> 00:01:20.113
要知道就在四五个月前

00:01:20.113 --> 00:01:23.850
这种事情都是不可能的那时候我是逮着
GPT 对线

00:01:23.850 --> 00:01:25.485
手搓配置 vLLM

00:01:25.518 --> 00:01:27.220
整整搓了好几天才跑起来

00:01:27.353 --> 00:01:30.523
来啊那给不了解的小伙伴先解释一下所谓的
NInfer 其

00:01:30.523 --> 00:01:32.926
其实就是类似于 llama.cpp 或者
vLLM

00:01:32.926 --> 00:01:35.595
这种框架但它和那些都不一样啊它

00:01:35.595 --> 00:01:38.731
不是那些的派生而是一个从零写的推理引擎

00:01:38.865 --> 00:01:40.300
它特殊的地方就在于其

00:01:40.300 --> 00:01:42.001
他的框架是要需要考虑

00:01:42.001 --> 00:01:43.736
不同的模型不同的硬件

00:01:43.736 --> 00:01:46.339
怎么兼容而 NInfer 特别的地方就在
于

00:01:46.439 --> 00:01:49.976
它把模型和硬件这一条路径给固定死了

00:01:50.176 --> 00:01:53.146
原版主要盯的就是 RTX 5090 这个
显卡

00:01:53.313 --> 00:01:55.682
模型呢主要就是千问 3.8 这个家族

00:01:55.815 --> 00:01:58.818
后面有大神把它移植到了 3090 上面后
来呢又有人

00:01:58.852 --> 00:02:03.523
根据 3090 做了 4090 的优化那
我这次用的就是这个 4090 fork

00:02:03.590 --> 00:02:04.591
所以基本上就是把

00:02:04.624 --> 00:02:09.162
千问 3.8 27B 这一个模型和
RTX 4090 这一张显卡

00:02:09.195 --> 00:02:11.231
这两个固定下来往死里优化

00:02:11.331 --> 00:02:12.999
它不需要像 llama.cpp 那样去

00:02:12.999 --> 00:02:13.266
考虑

00:02:13.333 --> 00:02:15.101
他拿到一个 GGUF 之后要去看

00:02:15.101 --> 00:02:17.003
一下它的架构是什么再解析

00:02:17.003 --> 00:02:18.705
然后再根据设备去选

00:02:18.705 --> 00:02:20.607
一个后端再去运行这一

00:02:20.607 --> 00:02:24.010
整套啊 llama.cpp 是为了兼容很
多模型和设备嘛

00:02:24.310 --> 00:02:27.213
所以不可避免的会有很多妥协还有一些小
bug

00:02:27.413 --> 00:02:31.117
但 NInfer 就是这样一个极端优化极
端固定的概念就

00:02:31.117 --> 00:02:32.685
一旦这一条路跑通了就

00:02:32.685 --> 00:02:35.788
优化到极致之后就连参数它都基本上不变了

00:02:35.955 --> 00:02:38.858
那我比喻一下啊我又要来了就是一个比喻

00:02:39.025 --> 00:02:41.127
llama.cpp 它就像一辆很优秀的

00:02:41.127 --> 00:02:43.196
丰田 S U V 你把它开去哪里

00:02:43.196 --> 00:02:46.599
都可以啊全世界都有零件你去哪儿都能维修

00:02:46.866 --> 00:02:50.336
雪地沙地山路上都可以啊速度呢也还行

00:02:50.670 --> 00:02:52.405
那 vLLM 呢可以说它像一个

00:02:52.405 --> 00:02:56.042
地铁系统啊它在乎的不是我一个乘客能跑多快

00:02:56.209 --> 00:02:57.977
它在乎的是我每个小时

00:02:57.977 --> 00:03:01.281
的总吞吐量可以把多少人给并行的运起来

00:03:01.447 --> 00:03:03.383
它最经典的技术呢就是
PagedAttention

00:03:03.650 --> 00:03:06.419
把 KV 缓存像虚拟内存一样分页管理啊

00:03:06.419 --> 00:03:07.387
减少显存碎片

00:03:07.520 --> 00:03:08.221
再配合一个

00:03:08.354 --> 00:03:09.589
continuous batching
就是

00:03:09.589 --> 00:03:10.523
连续批处理

00:03:10.557 --> 00:03:12.125
非常适合高并发的服务

00:03:12.492 --> 00:03:13.193
它现在呢也有

00:03:13.193 --> 00:03:16.596
prefix caching 啊就是可以
把以前算过的前缀直接复用

00:03:16.896 --> 00:03:18.798
然后呢就是 SGLang 这个是特别

00:03:18.798 --> 00:03:20.333
强调复杂工作流里面的

00:03:20.333 --> 00:03:22.068
缓存复用比如说他会去

00:03:22.068 --> 00:03:23.836
考虑哪些货物可以共享

00:03:23.836 --> 00:03:25.672
路线啊哪些可以缓存哪

00:03:25.672 --> 00:03:28.508
些可以有共同的 prefix 怎么复用这
些状态

00:03:28.708 --> 00:03:31.544
所以呢它可能就像一个智能物流中心

00:03:31.744 --> 00:03:32.679
它很有代表性的技

00:03:32.679 --> 00:03:35.281
术叫做 RadixAttention 粗
略理解一下它

00:03:35.281 --> 00:03:38.284
就是把大量的请求的 prefix 组成一
棵树

00:03:38.551 --> 00:03:40.987
然后呢重复的 prefix 它就不重复计
算了

00:03:41.354 --> 00:03:43.289
所以它对于 agent 的 loop 来
讲有很

00:03:43.289 --> 00:03:45.158
多东西都是重复的嘛非常有效

00:03:45.391 --> 00:03:47.493
那那最后就是我这回尝试的 NInfer

00:03:47.627 --> 00:03:49.262
它呢就是一辆 F1 赛车

00:03:49.395 --> 00:03:52.532
你赛道就是这一个赛道发动机就这一台发动机

00:03:52.699 --> 00:03:54.334
轮胎我都是这一组轮胎

00:03:54.434 --> 00:03:56.135
变速箱悬挂什么的都不变就

00:03:56.135 --> 00:03:57.971
就连天气啊我都给它固定住了

00:03:58.037 --> 00:04:01.040
所有的都是已知条件然后就往死里去刷圈

00:04:01.407 --> 00:04:02.442
这样极端优化的

00:04:02.442 --> 00:04:03.576
结果呢就是我这样

00:04:03.576 --> 00:04:06.145
一张 4090 24GB 的卡
NInfer 可以

00:04:06.145 --> 00:04:09.916
把整个 256K 的模型原生上下文啊全都
塞进去

00:04:10.049 --> 00:04:12.585
而且生成速度可以达到平均一百
tokens 每秒

00:04:12.719 --> 00:04:14.988
关于速度啊这些测试我后面会再展开讲一下

00:04:15.388 --> 00:04:18.591
啊其实千问 3.8 27B 这个模型它本
身也比较特殊啊它

00:04:18.591 --> 00:04:20.093
它不是每一层都有巨大

00:04:20.093 --> 00:04:22.028
的 KV 缓存它是一个混合架构

00:04:22.128 --> 00:04:23.863
所以才能在 24GB 级别的卡上

00:04:23.896 --> 00:04:27.533
把 256K 的上下文给开满就放在以前想
都不敢想

00:04:27.867 --> 00:04:29.302
但这个缓存呢并不是就

00:04:29.302 --> 00:04:34.340
说原始精度而是量化后的 Q4 呃但又不是
普通的 K4V4

00:04:34.340 --> 00:04:37.010
而是 RK4V4-E8

00:04:37.176 --> 00:04:38.378
那这个参数具体是什么

00:04:38.378 --> 00:04:39.579
意思呢我就不展开讲了

00:04:39.579 --> 00:04:42.515
讲了你也听不懂啊主要是因为呢我也看不懂

00:04:42.682 --> 00:04:44.050
啊反正就是一种比普通

00:04:44.050 --> 00:04:45.785
压缩精度要更好一点的

00:04:45.818 --> 00:04:49.455
旋转跳跃的压缩方式它前面那个二代表的是
rotate 嘛

00:04:50.023 --> 00:04:50.056
啊

00:04:50.256 --> 00:04:51.557
所以可以在精度损失很

00:04:51.557 --> 00:04:56.062
小的前提下可以比 Q8 或者 FP16
的 KV 缓存能更省显存

00:04:56.396 --> 00:04:57.530
就它主要的目的其实不

00:04:57.530 --> 00:05:00.366
是提速啊它反而是比 Q8 要慢一点点

00:05:00.466 --> 00:05:01.834
它主要是为了用尽可能

00:05:01.834 --> 00:05:04.103
小的质量代价把 KV 压的更小

00:05:04.370 --> 00:05:07.840
好把完整的 256K 上下文全都塞进
24GB 里面

00:05:08.074 --> 00:05:09.142
所以总结来说啊

00:05:09.275 --> 00:05:11.077
别的框架是要模型和

00:05:11.110 --> 00:05:13.880
硬件向框架妥协以获取兼容

00:05:14.047 --> 00:05:17.283
但 NInfer 呢是把自己改成了
千问 3.8 的那个形状

00:05:17.317 --> 00:05:21.688
特别是 4090 这个 fork 只为
千问 3.8 27B 一个人服务

00:05:21.854 --> 00:05:24.123
这是什么样的硬件榨汁儿行为啊

00:05:24.324 --> 00:05:25.491
所以如果你有对应的九

00:05:25.491 --> 00:05:27.126
零系列的硬件真的可以去尝试一下

00:05:27.360 --> 00:05:31.564
呃我都我想象了一下这个框架用来跑
4090 48GB 哦

00:05:31.731 --> 00:05:33.900
那那应该是一种天下无双的体验

00:05:33.966 --> 00:05:35.368
果如果有优化好的话啊

00:05:35.368 --> 00:05:37.970
他我不知道他有没有单独为了 48GB 版
本优化

00:05:38.004 --> 00:05:40.740
哎如果有大佬试过的话可以来评论区炫耀一下

00:05:41.007 --> 00:05:42.075
让我长长见识

00:05:42.108 --> 00:05:43.643
那 NInfer 整个部署好之后呢我

00:05:43.643 --> 00:05:44.811
首先让它去做了一个小

00:05:44.811 --> 00:05:47.113
任务去修改我的 A I 本地控制台

00:05:47.280 --> 00:05:49.148
让他把自己的 profile 给加进去

00:05:49.315 --> 00:05:50.683
我是做了这样一个网站

00:05:50.683 --> 00:05:51.784
部署在我自己的服务器

00:05:51.784 --> 00:05:53.086
上这样我可以非常简单

00:05:53.086 --> 00:05:54.687
的去切换各种服务各种

00:05:54.687 --> 00:05:56.723
模型或者就监控大模型的流量

00:05:57.156 --> 00:05:58.458
那给我的第一个感受啊

00:05:58.458 --> 00:06:01.694
就是它首 token 变慢了就
llama.cpp 里面

00:06:01.694 --> 00:06:03.463
大概是五秒钟左右就会

00:06:03.463 --> 00:06:06.432
出首 token 它要十二三秒但这

00:06:06.432 --> 00:06:07.533
里得说清楚啊我这里拿

00:06:07.533 --> 00:06:09.535
的是实际 Agent 跑的时候第一

00:06:09.535 --> 00:06:13.005
轮冷请求看到的 TTFT 也就是首
token 延迟

00:06:13.306 --> 00:06:14.607
如果我们真的去做那个

00:06:14.607 --> 00:06:19.112
benchmark 去测试的话呢其实纯
prefill 的吞吐没有慢那么两倍啊

00:06:19.145 --> 00:06:20.947
大概就是落后个两三成左右

00:06:21.214 --> 00:06:22.749
那主要是这种冷启动的

00:06:22.749 --> 00:06:24.417
情况下一次性灌一大堆

00:06:24.417 --> 00:06:26.386
上下文进去的场景它是要慢一点

00:06:26.452 --> 00:06:29.522
后续呢就是缓存命中越来越高之后会越用越低

00:06:29.722 --> 00:06:32.091
一开始大概十几秒后面就是能达到几秒

00:06:32.225 --> 00:06:34.293
然后呢就是速度啊用下来之后

00:06:34.293 --> 00:06:37.864
我发现一些小任务能达到
130 tokens/s 左右

00:06:38.030 --> 00:06:40.066
就我按照以前的体感啊给他派一个任务

00:06:40.066 --> 00:06:41.567
然后我自己切去干别的事情了

00:06:41.701 --> 00:06:42.702
结果没过一会儿他跟我

00:06:42.702 --> 00:06:44.470
说干好了我就有点不习惯

00:06:44.570 --> 00:06:46.372
就跟我以前的那个体感不太一样

00:06:46.539 --> 00:06:47.974
然后呢长链开发现在是

00:06:47.974 --> 00:06:49.976
稳定在一百多一点 tokens 啊这

00:06:49.976 --> 00:06:51.310
也是一个非常不错的成绩

00:06:51.577 --> 00:06:52.912
呃因为在上下文稍微长

00:06:52.912 --> 00:06:55.448
一点之后呢 llama.cpp 你是即便
开

00:06:55.481 --> 00:06:59.752
MTP 它的速度大概其实也就五六十个
tokens 每秒了

00:06:59.786 --> 00:07:01.320
好一点的情况也只有七十

00:07:01.587 --> 00:07:04.190
所以基本上就是一个一点五倍的速度提升

00:07:04.357 --> 00:07:05.491
然后在这个速度之外还

00:07:05.491 --> 00:07:06.759
有一点非常牛逼的就是

00:07:06.759 --> 00:07:09.595
呢在 NInfer 框架里面把上下文开到
顶

00:07:09.929 --> 00:07:11.864
也就是 256K 上下文全都塞进

00:07:11.864 --> 00:07:15.802
去的情况下还剩 1.3GB 左右的显存也
就是说啊

00:07:15.802 --> 00:07:17.970
我们可以把视觉模型也同时给开起来

00:07:18.204 --> 00:07:20.306
llama.cpp 呢在我个人的这台机器

00:07:20.306 --> 00:07:23.409
上对最多我是开到 208K 左右的上下文

00:07:23.409 --> 00:07:25.178
然后再开一个视觉基本

00:07:25.178 --> 00:07:26.512
上就是你看到那根红线

00:07:26.512 --> 00:07:29.215
顶着跑了啊跑着跑着就就不太稳定啊

00:07:29.282 --> 00:07:30.850
就是命悬一线那种感觉

00:07:30.950 --> 00:07:33.152
就每次发一个请求我菊花都紧紧的

00:07:33.386 --> 00:07:34.487
生怕它直接爆了

00:07:34.554 --> 00:07:36.856
啊但开 NInfer 之后呢我就直接全上
下文

00:07:36.956 --> 00:07:38.424
然后视觉模型同时开起来

00:07:38.624 --> 00:07:40.126
呃所以总结下来孩子吃

00:07:40.126 --> 00:07:41.894
了 NInfer 粉之后呢显存占用更

00:07:41.894 --> 00:07:44.797
少了上下文更长了速度更快了这有三个优点

00:07:44.964 --> 00:07:48.501
唯一的缺点就是冷 prefill 的速度
要降低百分之二三十

00:07:48.901 --> 00:07:51.771
再然后就是关于功耗啊这个非常的重要啊

00:07:51.771 --> 00:07:53.639
因为我这台机器 decode 的时候

00:07:53.940 --> 00:07:57.243
整机墙上功耗最高是会到五百三四十瓦

00:07:57.543 --> 00:07:59.245
但是 prefill 的阶段呢就没有那么
高

00:07:59.478 --> 00:08:00.847
特别是当缓存命中的时

00:08:00.847 --> 00:08:02.648
候有时候大概是两三百瓦这样

00:08:02.915 --> 00:08:04.350
然啊当然这是我说这套

00:08:04.350 --> 00:08:07.186
NInfer 再加上 4090 的这个配
置的实测

00:08:07.353 --> 00:08:08.654
并不是说所有的或者你

00:08:08.654 --> 00:08:10.590
的机器也是这样你自己也可以实测一下

00:08:10.790 --> 00:08:14.260
你可以看我这个墙上功耗的实测就是用
llama.cpp 那几天

00:08:14.360 --> 00:08:17.263
token 总量这几天用的都是差不多的都
是一个亿左右

00:08:17.363 --> 00:08:21.968
llama.cpp 还要再少一点啊但是呢
一天下来墙上功耗 llama.cpp 是

00:08:22.201 --> 00:08:23.636
六千瓦到七千瓦之间就

00:08:23.636 --> 00:08:26.405
奔着七我感觉它有时候都要破七了

00:08:26.706 --> 00:08:28.474
但换成 NInfer 之后呢我这两天

00:08:28.474 --> 00:08:30.977
大概就是四点五到五千瓦时之间

00:08:31.110 --> 00:08:32.712
所以这个就光电费的区

00:08:32.712 --> 00:08:34.046
别按照我现在的电价来

00:08:34.046 --> 00:08:36.983
粗算一下年化下来是能省一千块钱

00:08:37.149 --> 00:08:38.684
就换了这么个框架而已

00:08:39.051 --> 00:08:41.654
啊当然目前这个样本还比较少没有办法确定说

00:08:41.754 --> 00:08:44.323
但就我体感而言它的那个发热的量还

00:08:44.357 --> 00:08:46.459
还有风扇呼啸的时间都是要更少的

00:08:46.726 --> 00:08:48.728
最后啊总结一下我的体

00:08:48.728 --> 00:08:52.198
验最开始我用的是 llama.cpp 啊
部署完之后用了一阵子

00:08:52.265 --> 00:08:54.533
跟在线 API 比起来就还是

00:08:54.700 --> 00:08:56.002
有一点点慢就有一点点

00:08:56.168 --> 00:08:58.604
比三点六要好很多了但是就还是

00:08:58.771 --> 00:09:00.106
有那么一点点便秘的感觉

00:09:00.239 --> 00:09:02.308
但换成 NInfer 之后这个一百
token 每

00:09:02.308 --> 00:09:04.410
秒的速度啊这就相当可用了

00:09:04.610 --> 00:09:04.977
呀呃因为之

00:09:04.977 --> 00:09:06.812
前的 DeepSeek V4 Flash
呃我

00:09:06.812 --> 00:09:08.447
用 Open Code Go 的那个
plan

00:09:08.748 --> 00:09:11.017
它给到的速度也就是一百到一百五之间

00:09:11.284 --> 00:09:12.485
当然你要跟最新的

00:09:12.485 --> 00:09:17.390
DeepSeek V4.1 Flash
这种复写式生成的速度那肯定是没法比的

00:09:17.657 --> 00:09:19.325
啊但反正啊总之这个优

00:09:19.325 --> 00:09:20.760
化下来我个人是非常非

00:09:20.760 --> 00:09:22.061
常满意的我现在是直接

00:09:22.061 --> 00:09:23.996
把整个生产都切换到了 NInfer 上面

00:09:24.363 --> 00:09:25.398
而且用起来非常稳定就

00:09:25.398 --> 00:09:28.100
没有触发任何问题也没有觉得质量有下降

00:09:28.301 --> 00:09:29.902
反而啊至少在我现在

00:09:29.902 --> 00:09:32.738
这套配置里面 NInfer 是比
llama.cpp 更省心的

00:09:33.105 --> 00:09:34.473
因为它很多容量或者设

00:09:34.473 --> 00:09:35.942
置在启动的时候就已经

00:09:35.975 --> 00:09:38.744
固定和校验好了超过预算就直接起不来

00:09:38.811 --> 00:09:40.746
而不是跑一半突然给你来个 OOM

00:09:41.080 --> 00:09:44.483
这个之前我在 llama.cpp 里面经
历过就是在长 session 里面会

00:09:44.483 --> 00:09:46.752
会出现一些显存和 slot 管理上的问题

00:09:46.852 --> 00:09:49.822
因为 llama 如果你默认不去设置
KV slot 你

00:09:49.822 --> 00:09:52.525
你不把它固定在一的话它现在默认是四

00:09:52.525 --> 00:09:54.226
然后用的是 unified KV

00:09:54.293 --> 00:09:56.562
这个功能概念上很好我很喜欢

00:09:56.696 --> 00:09:58.064
但是那个我目前的配置

00:09:58.064 --> 00:10:00.633
好像有点硬件啊可能有点水土不服

00:10:00.900 --> 00:10:03.269
啊反正就是上下文越长越不稳定最后会崩掉

00:10:03.569 --> 00:10:06.372
那么目前啊本地部署对我个人来说

00:10:06.372 --> 00:10:08.808
我觉得还差最后一个问题就是并发

00:10:09.008 --> 00:10:10.543
目前呢我个人是不希望

00:10:10.543 --> 00:10:12.378
损失上下文去搞并发的啊

00:10:12.378 --> 00:10:14.447
因为就 4090 单张卡而言我现

00:10:14.447 --> 00:10:17.016
在把上下文开到 256K 个人是

00:10:17.016 --> 00:10:19.118
非常舒爽的一个状态特

00:10:19.118 --> 00:10:20.720
别是在 agent 搞长链开发的时

00:10:20.720 --> 00:10:22.722
候呢有的人会觉得说一

00:10:22.722 --> 00:10:24.490
百二十八 k 上下文够用但

00:10:24.490 --> 00:10:25.925
我个人啊就是觉得有点

00:10:25.925 --> 00:10:27.293
不够我甚至希望再长一点

00:10:27.727 --> 00:10:29.095
然后在保持这个上下文

00:10:29.095 --> 00:10:32.231
的前提下有办法啊把并发给做起来那是更好

00:10:32.565 --> 00:10:33.933
个啊希望有什么框架可

00:10:33.933 --> 00:10:35.468
以这个打破一下物理定律

00:10:35.735 --> 00:10:38.304
可以让 4090 二十四 G 搞一个啊

00:10:38.304 --> 00:10:41.707
四个左右吧我也不贪心四个长上下文并发啊

00:10:41.774 --> 00:10:45.011
上下文在 256K 左右生成速度都维持在
一百左右

00:10:45.344 --> 00:10:46.178
的哼宛如做梦

00:10:46.479 --> 00:10:47.947
啊但也不是不可能的我

00:10:48.014 --> 00:10:51.217
不是痴人说梦你看现在软件的优化是真的

00:10:51.217 --> 00:10:53.119
翻天覆地前几个月同样

00:10:53.119 --> 00:10:54.553
的硬件更弱的模型就

00:10:54.553 --> 00:10:56.322
千问 3.6 那个版本嘛我

00:10:56.322 --> 00:10:58.157
是开了 MTP 都只有

00:10:58.157 --> 00:11:00.693
40–50 tokens/s 那才过了这
么几个月

00:11:00.960 --> 00:11:02.728
更强的三点八模型更快

00:11:02.728 --> 00:11:05.297
的速度啊原生四五十 MTP 直接破百

00:11:05.431 --> 00:11:06.799
搞得我上个星期跑了十

00:11:06.799 --> 00:11:09.568
几个小时的矩阵测试啊好不容易定下来的参数

00:11:09.635 --> 00:11:10.870
到今天已经没卵用了

00:11:11.070 --> 00:11:12.071
了啊但没关系啊毕竟我

00:11:12.071 --> 00:11:14.206
自己就是非常喜欢折腾这种事情嘛啊多

00:11:14.273 --> 00:11:16.375
多折腾一下也有更多的话题可以跟你们聊

00:11:16.542 --> 00:11:18.244
有空欢迎再来听我唠嗑下期再见