服务器太吵了，只开个qwen3.8+hermes也不适合7x24小时不停机，正好苹果发布新品，连夜做了一些功课之后还是押注绿厂了，搞了两台小主机，准备把干活模型升级到DSV4，说干就干。

说全程远程部署着实是标题党，开机之后还是接了键鼠显示器，按照官网指南进行初始化配置连网更新，配置了固定ip就直接把外设包括显示器都拆了，用飞书遥控服务器的hermes远程配置小主机。
得益于qwen3.8-27b着实可靠，过程非常顺利。其中遇到了小主机访问不了外网，自己配置服务器的clash代理给两台小主机更新docker，下载DSV4配方包，再解压配置两台之间的ssh密钥，测试qsfp网速，然后就直接把DSV4开起来了，全程没让我插手。体验简直惊艳。

file:///home/bentonyi/文档/xwechat_files/bentonez_e4c6/temp/RWTemp/2026-09/09fef7517ddb4143df3ea7e81576d5f9.png

同时用DSH和Hermes给他下任务同时跑，性能也是非常不错：

温度和功率倒也不是很高，以后高负载的时候我再更新一个
file:///home/bentonyi/文档/xwechat_files/bentonez_e4c6/temp/RWTemp/2026-09/f5b567aaf4f918ed727170f8aa1e8fac.png

@terry 个人认为与其称之为“性能过剩”的说法，不如还是“和需求不匹配”来的恰当。在这里想较个真哈，纯粹是阐述一下剖析底层需求的逻辑方法，如果能帮到硬件选型的朋友也算歪打正着了：
1，假如像之前想买双DGX Spark的老哥说主要用来跑deepseek-v4-flash辅助写作，那么他需求的吐字速度就是比人眼阅读速度的极限快个2倍就行，因为他是真的要亲自来阅读模型输出的每个字的。他真正迫切的是VRAM要大到能装下聪明（大容量）的脑子，而50tokens/s和400tokens/s对老哥来说其实没有任何差异（心理上更爽带来的提升不算，没有实质命中需求）。
2，举个自己的例子，我自己跑文生图/图生图是依赖comfyUI工作流（ERNIE或者Qwen-Image）的，通常在草稿阶段需要我根据老婆口述的模糊设计，自己写提示词让工作流生成800x800的样稿，然后给她过目再口述怎么改，我再改提示词如此往复，直到老婆大人满意定稿，我再输出高清图或者作为视频的关键帧再去制作视频。这个改稿的过程少则10几次，多则三四十次，偶尔途中可能还会推翻设计。那么20多秒出图就一定比1分钟出图更有效率，每一秒的提升在我这都是实实在在的。
3，用来驱动Hermes跑定时任务or处理日杂事务，驱动claude code用来氛围开发或者像我作为操作Linux的中间层（我自己接触Linux起步较晚并不熟练，cc作为一根“Linux拐杖”简直深得我心，非常满意）。这类智能体会根据你布置给它的任务，从它自身的Harness里按范式一步一步尝试解决，虽然是会越来越聪明但那是在至少以周甚至月为尺度的多次复用情况下的。你临时给一个任务平均它就是要尝试10几次甚至二三十次才能搞定的，这种情况下IT（指令遵循）大模型输出的绝大部分内容都不需要你来阅读，纯属Agent<=>ITLLm之间的交互，你就坐等一个成功or失败的结果。这时候不论是prefill（LLM读）还是decode（LLM写），信我的你一定是希望越快越好，你不会希望给claude code说一句“按照上次的方式再重装一次SGLang框架”，1分钟快到了他才刚刚找到之前的memory开始读skills，你一定会Ctrl+C了自己来的。

情况1就是算力有个保证超过阅读速度的门槛过了就行，往上看VRAM能够到哪个模型就花多少钱，是DGX还是MacStudioUltra256G，甚至10多个收一台512G的跑671B也随你喜欢；
情况2和3就是Vram有个门槛过了就行，比如只跑qwen3.6-27b-q4_K_M@128kContext，但是速度能跑多快给我跑多快，你就挑大于22G显存（举个例子没具体算）的预算内的最好的gpu就行，能折腾想省钱就amd，不想折腾就nvidia；

大概率不会跑偏。

个人看法：就是ai硬件的入门款，以显卡型号来打比方就是：

级别（个人）	ai硬件产品线	显卡产品线
入门	RTX Spark（补齐短板）	RTX 5070
进阶	DGX Spark	RTX 5070 nVLink版
高手	RTX Pro5000	RTX 5080 super
大师	RTX Pro6000 Series	RTX 5090

显卡毕竟是设计用来打游戏（处理图像视频）的，那么多的计算单元是为了保障画面渲染的速度和质量。只不过是多年前的一次布局，让这些渲染核心正好也可以做高精度通用计算，由于ai发展相对硬件设计更新实在太快了，用游戏卡充当ai设备不是长久之计，于是开始着急忙慌设计针对个人的低端ai设备，也顺便补齐ai最大卖铲集团的最后一块toC拼图，让更多的想入门本地大模型正持币观望的C端用户进场，也顺便靠这个RTX Spark再拿一些向上的转化率。

huggingface前两天发布了基于LTX2.3的免审查视频模型sulphur-2，今天下来小玩了一下，不论从视频清晰度、语音音色和物理效果方面，完成度都非常高，推荐玩耍。视频无法发到论坛，而且非常敏感，就不做外链了。如果以后有电报群可以共享一下。

模型下载地址：
https://modelscope.cn/models/hf/SulphurAI-Sulphur-2-base

@Tony-Wang 涡轮卡的散热策略偏安静，max-q的出厂设置在300w功耗，温度干到90度的时候风扇也只吹到80%。都是可调整的，up说的不可调整估计是用官方的NVIDIA X Server Settings工具，温控功能确实是置灰的不能调。这个问题当时也是卡了我一下午，问了几个大模型，推荐了若干工具。最后试过一遍之后，LACT工具完美解决，拉一拉曲线都能整，小工具还支持多卡不同曲线。4090+max-q已测试通过非常好用，up也可以试试看

@Dalu-Fama 回你这个显存占用89G的问题，你vLLM启动参数一定没有加 --gpu-memory-utilization 0.50 参数，你不加参数就默认是0.9。划掉你显存的90%给vLLM专用。影响实际显存占用的因素有：
--gpu-memory-utilization 0.50 \ #预设显存池
--max-model-len 131072 \ #上下文长度
--max-num-seqs 2\ #最大并发数
实际上我就是跑的FP8量化，MTP投机种子设4的时候显存占用也就52G，用来跑BF16的Qwen-Image-Edit也不会oom。

论坛上已经有一帖分享 V4.1 flash 配方（Deepseek v4.1 flash , 4台DGX spark GB10, TP=4）基本默认要一台 200G 交换机做四机全互联。我这套是用 4 根 DAC 线把四台 GB10 直接接成一个闭环——没有交换机，对面节点（rank0rank2）互不可直连，通信要靠邻居转发——走的是 SparkRing 的无交换机环（switchless cycle）路线，NCCL 需要打补丁才肯在这种拓扑上起来。

实测结果是可以用，而且不比交换机组网差：单流解码 75–108 tok/s，满并发（8 路）聚合解码 280→703 tok/s，16K 上下文 prefill ≈4.4k tok/s，1M 上下文单流 TTFT 71.6s / prefill 3.58k tok/s。今天把并发 × 上下文的二维矩阵整跑了一遍，数据附在下面。

使用方案：FujitsuPolycom/sparkring（Apache-2.0，自带 NCCL 补丁）的 deepseek-v41-flash-tp4 profile，模型是官方原始权重。

---

DeepSeek-V4.1-Flash TP4（四机环）部署与测试总结报告

---

一、模型与服务基本信息

• 模型名称：DeepSeek-V4.1-Flash（服务名 DeepSeek-V4.1-Flash-TP4）
• 权重版本：官方 checkpoint，pinned revision dba1be0a40aa，48 个 safetensors 分片，476 GiB
• 上游原生路线：github.com/FujitsuPolycom/sparkring — profile deepseek-v41-flash-tp4（recommendation: recommended，装机器镜像 dev-20261013-dcp2prefill-status038-sircl-tp6）
• 推理引擎：vLLM（SparkRing "Kraken" 分支 0.1.dev21553+gab86b7073）+ B12X 内核 + SIRCL 传输插件
• 硬件环境：4× NVIDIA DGX Spark（GB10，aarch64，单机 121 GiB 统一内存）
  • rank0 aitopatom-aca1（技嘉 AI TOP ATOM，Node A / 服务出口）｜ rank1 gx10-white（ASUS GX10）｜ rank2 gx10-black（ASUS GX10）｜ rank3 aitopatom-a9b6（技嘉 AI TOP ATOM）
  • 两家 OEM 的系统版本不同（GX10 = DGX OS 7.2.3 / 内核 6.17.0-1031-nvidia；AI TOP ATOM = DGX OS 7.4.0 / 内核 7.0.0-1019-nvidia），实测混装可以跑通
• 高速网络互连：无交换机环形拓扑，4 根 QSFP DAC 直连（p0 → 下一台 p1，无对角线），每台 2 个 CX7 200G 端口（每个端口两个 Socket Direct 功能，共 4 个 fabric netdev），整环 8 条逻辑通道
  • 环序：aitopatom-aca1 → gx10-white → gx10-black → aitopatom-a9b6 →（回到 aca1）
  • fabric 地址段 198.18.0.0/21，每根缆两个 /24；控制面走 WireGuard sr-control（10.253.255.1–4）

权重存储与挂载：环上没有贯通全环的 NFS 通路（对面节点不直连），所以四台各存一份完整 476 GiB 权重，本机 NVMe 直读；四机 × 48 分片全量 sha256 比对一致（192/192）。这跟交换机组网"HEAD 挂 NFS 给 worker 只读"的做法不同，是环拓扑的硬约束，也是安装前要预留 ~620 GB/台 空间的原因。

---

二、核心规格与配置参数

核心参数	数值 / 设定	说明
Context Length	1,048,576（1M tokens）	模型原生完整长度，本次部署跑满 1M
Max Running Requests	8	--max-num-seqs 8，CUDA Graph 捕获尺寸覆盖到 96
KV Cache Pool	12,715,913 tokens（可用 KV 显存 15.89 GiB）	1M 上下文时可支撑 12.13 路并发；FP8
静态显存比例	0.83（≈100.9 GiB / 121.6 GiB）	每 rank 权重常驻 74.4 GiB，服务中每机仍余 9–10 GiB
分块预填充	--max-num-batched-tokens 8192 + chunked prefill	抑制长上下文 attention logits 峰值张量，500K+ 不 OOM
前缀缓存 / 调度	prefix caching + async scheduling	同一前缀重复请求命中即省 prefill
推测解码	DSpark，num_speculative_tokens 5、概率式草稿、块级拒绝、自适应验证	引擎实测：平均接受长度 3.65、平均草稿接受率 61.0%、逐位接受率 0.851 / 0.684 / 0.546 / 0.463 / 0.392
Engram 卸载	table_memory=disk + disk_resident_scales	两张 FP8 n-gram 表（各 ~94.6 GiB）不占显存，按 token 需要从本机 NVMe 直读——这是 4 台能装下 1M 上下文的关键
环网传输	SIRCL（SIRCL_FABRIC=ring:4、SIRCL_GROUPS=tp、NCCL never）	补齐的 NCCL 2.32.3 提供 NCCL_SWITCHLESS_RING_ONLY=1，跳过 tree/PAT 建链（环上对面 rank 无直连）
多模态视觉	原生支持，limit-mm-per-prompt {"image":4}	256×128 测试图消耗 202 vision tokens
思考控制	默认 on · high；级别 low / high / xhigh(mx) / 1–100	可请求级关闭（chat_template_kwargs: {"thinking": false}）；默认开启且思考链吃 token，max_tokens 给小了会返回空 content
工具 / 推理解析器	deepseek_v41（tool-call + reasoning）+ auto tool choice	支持强制工具调用
端点	http://192.168.10.10:8015/v1	无鉴权（不带 key 与带假 key 都返回 200）：方便接线，但别把它暴露到局域网之外
启动耗时	热重启 4 分 29 秒（22:58:47 起容器 → 23:03:16 API 就绪）	权重 50.4 s 载完（74.4 GiB/rank），引擎 init 150 s；首次冷装（含校验 + 编译内核）约 20 分钟

---

三、验证与测试数据

测试口径（全部一致）：

• 每档输出 128 tokens，填充文本带唯一 nonce + 递增编号 → 不命中 prefix 缓存；温度 0.6
• 单流 pp/tg = 各请求均值；聚合 pp = Σprompt / max(TTFT)；聚合 tg = Σcompletion / (max 总时长 − max TTFT)
• 并发 1/2/4/8（8 = 本部署的并发上限），上下文档位 1K → 512K

1. 基础功能与能力验证（栈自检，本机环上实跑）

测试项	输入	结果	状态
计数	1…20 顺序输出	全对	PASS
算术	17 × 23	391	PASS
代码生成	Python is_prime(n)	完整可用实现	PASS
工具调用	get_weather(Paris)	正确发起 tool call	PASS
强制工具调用	tool_choice=required	正确发起 get_weather(Rome)	PASS
原生视觉	左红右蓝 128×64 PNG	The left half is red and the right half is blue.	PASS
思考开关	关→直答 / 开→带思考链	thinking on 时 391 + 62 字符思考链	PASS
传输层	本次集合通信走哪条路	Transport: sircl, NCCL: absent	PASS
频率	四机 SM 时钟	2483–2522 MHz，无降频事件（仅 idle）	PASS

四机环上自检全绿：All checks passed.

2. 长上下文阶梯压测（并发 1）

目标上下文	实际 prompt tokens	TTFT	单流 prefill	单流解码	墙钟	状态
1K	1,116	0.47s	2,362.7 tok/s	91.0 tok/s	1.9s	PASS
4K	4,070	0.99s	4,118.6 tok/s	96.5 tok/s	2.3s	PASS
8K	7,958	1.76s	4,529.1 tok/s	89.4 tok/s	3.2s	PASS
16K	15,686	3.43s	4,569.8 tok/s	75.1 tok/s	5.1s	PASS
32K	31,741	7.93s	4,001.6 tok/s	74.9 tok/s	9.7s	PASS
64K	63,524	14.35s	4,425.9 tok/s	90.7 tok/s	15.8s	PASS
128K	127,784	32.14s	3,976.0 tok/s	86.7 tok/s	33.6s	PASS
256K	256,355	71.61s	3,579.8 tok/s	107.9 tok/s	72.8s	PASS
512K	513,344	175.55s	2,924.2 tok/s	79.0 tok/s	177.2s	PASS

1M 上下文是配置上限，实跑验证到 512K：512K 单请求 TTFT 175.6s、prefill 2.92k tok/s，全程无 OOM、无换页。

3. 高并发 × 上下文 二维扫描

并发 2

上下文	prompt/请求	TTFT(max)	单流 pp	单流 tg	聚合 pp	聚合 tg	墙钟
1K	1,094	0.64s	1,723.3	55.2	3,443.3	110.4	3.0s
4K	4,154	2.02s	3,029.8	60.3	4,067.2	143.6	3.8s
8K	7,958	3.52s	3,394.1	52.4	4,525.3	135.4	5.4s
16K	15,686	6.92s	3,421.6	44.3	4,579.8	127.8	8.9s
32K	31,094	14.02s	3,239.3	34.1	4,481.6	107.5	16.4s
64K	62,240	28.28s	3,204.5	42.7	4,401.8	153.7	30.0s
128K	125,240	62.84s	2,955.3	36.5	4,026.3	137.8	64.7s
256K	256,355	146.02s	2,640.5	34.6	3,511.3	134.9	148.0s
512K	503,240	349.99s	2,185.7	43.7	2,904.6	171.8	351.6s

并发 4

上下文	prompt/请求	TTFT(max)	单流 pp	单流 tg	聚合 pp	聚合 tg	墙钟
1K	1,094	1.06s	1,036.2	50.5	4,136.7	189.3	3.8s
4K	4,070	3.65s	1,678.6	40.1	4,486.7	199.0	6.2s
8K	8,123	7.02s	2,321.6	30.1	4,580.0	193.3	9.7s
16K	16,012	14.87s	2,235.5	24.5	4,262.4	206.1	17.4s
32K	31,094	28.89s	2,208.7	18.7	4,327.3	185.8	31.7s
64K	63,524	59.54s	2,170.9	18.4	4,202.9	237.4	61.7s
128K	125,240	125.14s	2,023.9	20.9	4,023.6	302.8	126.9s
256K	251,290	288.52s	1,842.5	22.4	3,519.0	339.4	290.1s
512K	513,344	695.75s	1,516.5	24.8	2,922.3	379.3	697.3s

并发 8（满并发，= max-num-seqs）

上下文	prompt/请求	TTFT(max)	单流 pp	单流 tg	聚合 pp	聚合 tg	墙钟
1K	1,094	2.27s	883.7	35.0	3,888.2	280.7	5.9s
4K	4,070	7.30s	1,245.4	25.3	4,503.8	256.9	11.3s
8K	8,123	14.24s	1,512.7	16.9	4,565.0	268.7	18.1s
16K	16,012	28.80s	1,519.1	12.6	4,402.4	280.3	32.5s
32K	31,094	57.46s	1,450.2	10.4	4,351.9	335.6	60.5s
64K	62,240	117.68s	1,418.9	9.7	4,252.8	437.9	120.1s
128K	125,240	253.92s	1,340.2	10.8	3,965.8	576.3	255.8s
256K	256,355	571.94s	1,190.9	10.4	3,550.3	574.0	573.9s
512K	503,240	1,396.56s	982.6	12.3	2,904.4	703.5	1,398.4s

4. 汇总对照

聚合解码吞吐（tokens/s）

上下文	并发 1	并发 2	并发 4	并发 8
1K	91.0	110.4	189.3	280.7
4K	96.5	143.6	199.0	256.9
8K	89.4	135.4	193.3	268.7
16K	75.1	127.8	206.1	280.3
32K	74.9	107.5	185.8	335.6
64K	90.7	153.7	237.4	437.9
128K	86.7	137.8	302.8	576.3
256K	107.9	134.9	339.4	574.0
512K	79.0	171.8	379.3	703.5

单流解码吞吐（tokens/s）

上下文	并发 1	并发 2	并发 4	并发 8
1K	91.0	55.2	50.5	35.0
4K	96.5	60.3	40.1	25.3
8K	89.4	52.4	30.1	16.9
16K	75.1	44.3	24.5	12.6
32K	74.9	34.1	18.7	10.4
64K	90.7	42.7	18.4	9.7
128K	86.7	36.5	20.9	10.8
256K	107.9	34.6	22.4	10.4
512K	79.0	43.7	24.8	12.3

聚合 prefill 吞吐（tokens/s）

上下文	并发 1	并发 2	并发 4	并发 8
1K	2,362.7	3,443.3	4,136.7	3,888.2
4K	4,118.6	4,067.2	4,486.7	4,503.8
8K	4,529.1	4,525.3	4,580.0	4,565.0
16K	4,569.8	4,579.8	4,262.4	4,402.4
32K	4,001.6	4,481.6	4,327.3	4,351.9
64K	4,425.9	4,401.8	4,202.9	4,252.8
128K	3,976.0	4,026.3	4,023.6	3,965.8
256K	3,579.8	3,511.3	3,519.0	3,550.3
512K	2,924.2	2,904.6	2,922.3	2,904.4

几条结论：

• Prefill 与并发无关：1K→256K 区间聚合 prefill 基本贴在 4.0k–4.6k tok/s，四档并发几乎重合，直到 512K 才降到 2.9k。说明环拓扑的瓶颈不在 prefill 聚合带宽（8 条 200G 通道够用），而在单请求的长序列 attention。
• Decode 随并发放大：满并发 8 路时聚合解码从 1K 的 280.7 一路涨到 512K 的 703.5 tok/s——上下文越长、每步计算越"重"，批次填得越满，环上 all-reduce 的固定开销被摊得越薄。
• 单流解码 ~75–108 tok/s（与换长上下文无关，1K–512K 都在这个带内）——比交换机组网公开数据的 58–68 tok/s 略高，主要差在推测解码接受率（平均接受长度 3.65 / 接受率 61%）。
• 128 tokens 的短输出会低估真实吞吐：单流 tg 里含首几步的调度开销，实际长任务（几百到几千 token）会明显更好。

5. 与交换机组网公开数据的量级对照

上下文	本机（无交换机环，单流）	论坛交换机组网（单流，64 输出）
32K	TTFT 7.93s / prefill 4,001.6 / 解码 74.9	TTFT 10.02s / prefill 3,271.0 / 解码 67.5
128K	TTFT 32.14s / prefill 3,976.0 / 解码 86.7	TTFT 48.46s / prefill 2,704.8 / 解码 67.5
256K	TTFT 71.61s / prefill 3,579.8 / 解码 107.9	TTFT 87.46s / prefill 2,997.3 / 解码 59.4
512K	TTFT 175.55s / prefill 2,924.2 / 解码 79.0	TTFT 268.94s / prefill 1,859.1 / 解码 58.2（500K）

口径不完全相同（输出长度 128 vs 64、软件栈不同），仅作量级参考：环拓扑在 TTFT / prefill 上明显更快，解码在一个带内偏上。"不用交换机就跑不动 TP=4"这个结论，至少在这套栈上可以推翻了。

---

除了手动更新机器、组网，环境全由hermes配置，耗时16小时，花销如图。

赶紧搜了一下自己的项目，暂时没有发现。

谢谢大师，应该暂时是不会点这个【检查更新】了

@David-Chen 说:

你說用BF16就算了，還是用量化的，感覺好好的一個機器被糟蹋了

如果成绩好的话他会不用嘛，27b稠密bf16别说m5u了，连pro6000成绩都没法看。苹果选测试对象非常有讲究的。
小盒子2年内赌gb10阵营基本上问题不大。

来自https://spark-arena.com/leaderboard
2 nodes的gb10集群运行FP8量化的0731版dsv4-flash（实际是FP8和NVFP4混合量化）的榜单能到50t/s（极限调教科技与狠活，关闭GUI），且512K可用，1M上下文有衰减。
GB10的社区在持续发力，而且大神不少，让这个小盒子从发布到现在的含金量持续缓缓上升。个人感觉这次苹果发布的macmini/macstudio系列在ai战场略显疲态。

对了，如果有blackwell架构想要极致省显存想选择NVFP4量化的朋友，别选unsloth的版本（截至5月8号），这个版本没有MTP投机权重文件vLLM下无法开启MTP（SGLang可开因为用的是NextN模块）。下右边这个版本就行。

@tony-wang 模型就是Deepseek-ai发布的原生FP8+NVFP4量化模型，模型卡https://modelscope.cn/models/deepseek-ai/DeepSeek-V4-Flash-0731

这是在用hermes一边计划对齐部署glm5.3-flash方案，一边在用DSH做早课的2并发时候的实际场景decode截图，最高单会话能上到76.7t/s，最低也有35+保底。

这是让hermes读魔搭的glm5.3-flash几个不同版本的模型卡页面，pp大概在1600～2500之间浮动。

上图是工作界面，之后会把glm5.3-flash的实际使用评测也发进来。

@怪物 你现在接好了在线模型也做不了@tony-wang 列的这些事。差4根线，长这样：


RJ45网线组不了NCCL网络，万兆也不行

是的。不过个人来说显卡嘛该买就买了，用作生产力工具挣钱的不在意这点成本，当玩具就更无所谓了。关键是美股的ai/半导体相关的标的是千万不能碰了，至少透支了将来10~20年的最佳商业叙事能获得利润的兑现收益。结合老特的最新视频，确实中国现在是以举国之力来对抗美国号称国运行业的阳谋，目前来看这个阳谋还没有什么太致命的弱点。

崩掉倒是不至于，但泡沫无疑是非常大的。
你理解现在的美国是个从前非常厉害的老登，年轻的时候身体强壮（制造业重工业），手里还有美式居合（美金+美军），于是一路打天下，攒下了巨大的家产和江湖地位。但这个老登现在，身体发福（制造业空心化且回归难度空前），以前贼6的美式居合也逐渐玩不灵了（传统工业优势迅速下降，和蓝星军力20强的伊朗打得有来有回），偏偏旁边还来了一个体格越来越壮的年轻人（东大克苏鲁）。他能怎么办？他也得掂量，和美军神话迅速被川普玩坏相比，美元霸权的衰落就没那么快，其实这个老登选择并不多，他现在选择押注ai，并不只是因为“AI很赚钱”这么简单。他更像是在包装一个超级宏大的金融故事：
“下一轮工业革命仍然发生在美国，美国仍然拥有最先进的科技，美国仍然是资本和人才的最终归宿。”
这个故事如果讲成功，那美元资产的吸引力、美国科技公司的估值、全球资本流向，都可以勉强保持下去。于是他至少还能维持住美元的霸权。所以你才会看到一些ai公司（尤其美国ai七子）的商业模式短期甚至不像传统企业——烧钱亏损市值还能疯涨。资本买的不是今天的利润，而是透支未来几十年的想象空间。

那么问题来了。东大一拍大腿，故事不错，但是他怕什么给丫安排什么：从政府给梁文锋站台到梁对投资人的4小时内部讲话，说deepseek只“赚取合适的利润”，到现在kimi K3的比肩顶级闭源ai的实力（八九成fable5的功力只收十几分之一的价格并且K3将在几天后开源），都无疑给了美国ai金碧辉煌的商业故事沉重一击，而且东大说我保证这样的事情以后冷不丁什么时候就出现一个……

这阳谋一出，你让资本怎么办，资本天生最怕不确定性，这样一折腾资本不得不理性下来。说穿了东大的阳谋是逼迫AI行业开始经历一次从“淘金热”迅速转变到“淘金公司开始算账”的过程。19世纪淘金热的时候，真正发财的不一定是挖金矿的人，而是卖铲人。而当淘金公司开始算账了，铲子也就不会无限涨价。

ai是未来大概率是真的，现在中美的这些ai公司都在卖一张通往未来的门票，但哪张门票能值回票价，真的只能交给时间。

之前还真的研究过cc通过mcp访问blender建模，但是说实话尝试了三四次之后得出结论就是完全不可用。正经的工作流还是在“文/图生图”阶段尝试和打磨，确定图片之后用混元3D工作流直接以图建模。

这个问题也是我这两天一直在折腾的问题，现在已经初步有了个眉目。先说结论：
结论是可以，架构是vLLM + qwen3.6-27b-NVFP4（3并行）+ ComfyUI（Qwen-Image-Edit-BF16)
或者vLLM + qwen3.6-27b-FP8（2并行）+ ComfyUI（Qwen-Image-Edit-FP8)

我的提示词是这样的：
我现在要在本地部署vLLM运行qwen3.6-27b来推理Hermes也就是你。在飞书远程工作的同时，还要用到本地的ComfyUI工作流进行文生图或者图改生图，大多是Qwen-Image-2512，少量用到Qwen-Image-Edit，这些模型都在/home/bentonyi/ComfyUI-master/models/unet，你可以自己看。目前的qwen3.6-27b模型情况是有一个NVFP4量化，一个FP8量化。
以上是具体现状，我的底线要求是：
1，任何条件下不能触发把KV Cache放到内存里交换让CPU跑的情况；
2，上下文128k满载、并发2倍冗余以内、mtp种子为4的极端情况下vLLM不得oom；
3，在qwen3.6-27b和comfyUI工作流并行任务期间，假设一旦出现显存吃紧或者占满，崩溃运行失败的只能是comfyUI，vLLM不得受到任何影响（因为我要远程处理，vLLM和hermes必须在线）；
你给我推荐一个建议运行的qwen3.6模型版本，以及相对应vLLM的运行参数（尤其是留足comfyUI工作显存后的推荐并发上限）

这是智力密集型的plan类工作，我直接祭出了deepseek-v4-pro连hermes。中间查硬件，查模型，查量化版本以及把量化的详细过程算给我看的过程就省略了，各位可以以自己的实际情况对应的提示词去deepseek在线问。最后hermes给出了最前面的结论。还给我画了显存分配明细： │
而且已经经过底线验证：

• 不触发 CPU swap — KV Cache 全在 GPU，48 层 SSM 不吃 KV
• 128K × 6 并发 × MTP=3 → KV 24 GiB < 预算 30 GiB，不会 OOM
• ComfyUI 先崩 — 它的 43 GiB 上限比 vLLM 的 52 GiB 硬限制先到
• MTP=4 对本模型的 KV 影响极小（MTP 只有 1 层额外 full_attn，开销 < 100 MiB）
• Qwen-Image-Edit BF16 只在切换使用 FP8 版本时可保平安

最后这张图是我的实际测试，显存占用和ds说得几乎一模一样。

@八十 和你花费有关，我没孩子也不会生，所以花费少很多。被动收入大于花消就实质退休了，降低物欲，修养身心都算退休路上的正向努力。

无意装逼，请老特先来

看看如今的A股新龙头，市值已经超过Intel。只可惜8块多申购时我没中签，不然

@566656661 赞同。虽然没有600w的卡，有一块450w的设定在320w上限，另一块300w的设定在250w上限。也是觉得人到中年优雅比较重要。