一个伪linux粉丝的blog

upgrade buildx

wanjie — Sat, 07 Feb 2026 01:53:08 +0000

背景

几年前折腾过多架构构建的 buildx 一直用着很顺畅，这2天构建镜像，总是遇到这个 error: no active session for ***: context deadline exceeded报错

查了下，可能和 buildx 版本有关，希望升级能解决。

升级步骤

当然是直接更新 buildx 的最新版本, https://github.com/docker/buildx/releases

# 下载并更新
wget -c https://github.com/docker/buildx/releases/download/v0.31.1/buildx-v0.31.1.linux-amd64 -O /root/buildx031
chmod +x /root/buildx031
 cp /root/buildx031 /usr/libexec/docker/cli-plugins/docker-buildx
cp: overwrite ‘/usr/libexec/docker/cli-plugins/docker-buildx’? yes

#  检查下版本
docker buildx version
github.com/docker/buildx v0.31.1 a2675950d46b2cb171b23c2015ca44fb88607531
# 完整路径检查
 /usr/libexec/docker/cli-plugins/docker-buildx version
github.com/docker/buildx v0.31.1 a2675950d46b2cb171b23c2015ca44fb88607531

更新后，继续构建，遇到 api 兼容报错

docker buildx build --platform linux/amd64,linux/arm64 -t cnrock/moltbot:v1 . --push 2>&1 |tee /tmp/bot.log ERROR: failed to build: Error response from daemon: client version 1.52 is too new. Maximum supported API version is 1.43: driver not connecting

意思就是

buildx v0.31.1 使用了API 1.52，而我当前环境的Docker 24.0.6支持的最高API版本是1.43

按提示更新 docker 呗。

yum update 遇到报错了，原因是 vps是甲骨文的，系统是 20年6月的 Oracle Linux Server 7.9

7.9 停更很久了，无法直接更新，提示yum-tokyo... 这里 repo 404

发现这里是一个地区变量，sed 全部替换掉

sudo sed -i 's/\$ociregion//g' /etc/yum.repos.d/*.repo

再 yum makecache 即可

升级命令

yum update docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

升级前后版本对比

Resolving Dependencies
--> Running transaction check
---> Package containerd.io.x86_64 0:1.6.24-3.1.el7 will be updated
---> Package containerd.io.x86_64 0:1.6.33-3.1.el7 will be an update
---> Package docker-buildx-plugin.x86_64 0:0.11.2-1.el7 will be updated
---> Package docker-buildx-plugin.x86_64 0:0.14.1-1.el7 will be an update
---> Package docker-ce.x86_64 3:24.0.6-1.el7 will be updated
---> Package docker-ce.x86_64 3:26.1.4-1.el7 will be an update
---> Package docker-ce-cli.x86_64 1:24.0.6-1.el7 will be updated
---> Package docker-ce-cli.x86_64 1:26.1.4-1.el7 will be an update
---> Package docker-compose-plugin.x86_64 0:2.21.0-1.el7 will be updated
---> Package docker-compose-plugin.x86_64 0:2.27.1-1.el7 will be an update
--> Finished Dependency Resolution

但这样升级会把 buildx 回退，这2个逻辑有点神奇

docker buildx version

github.com/docker/buildx v0.14.1 59582a8

/usr/libexec/docker/cli-plugins/docker-buildx version
github.com/docker/buildx v0.14.1 59582a8

需要再次更新下

# 下载并更新
wget -c https://github.com/docker/buildx/releases/download/v0.31.1/buildx-v0.31.1.linux-amd64 -O /root/buildx031
chmod +x /root/buildx031
 cp /root/buildx031 /usr/libexec/docker/cli-plugins/docker-buildx
cp: overwrite ‘/usr/libexec/docker/cli-plugins/docker-buildx’? yes

#  检查下版本
docker buildx version
github.com/docker/buildx v0.31.1 a2675950d46b2cb171b23c2015ca44fb88607531
# 完整路径检查
 /usr/libexec/docker/cli-plugins/docker-buildx version
github.com/docker/buildx v0.31.1 a2675950d46b2cb171b23c2015ca44fb88607531

尾声

构建镜像还是遇到这个报错，无解了？

ERROR: failed to build: failed to solve: DeadlineExceeded: failed to push cnrock/openclaw:v1: no active session for x8821klxrbc7g2j3s94ryho4o: context deadline exceeded

清理下缓存看看

docker builder prune -af && docker buildx prune -af

ID						RECLAIMABLE	SIZE		LAST ACCESSED
gedc44uv09brh7k1b5ihcdv7a*              	true 		146.4MB
fyfv6pxd2nu9a7a3rpwbct2je               	true 	0B        	1 second ago
opkb996ch7wdzq5ri28aea96h               	true 	88.16MB   	5 seconds ago
zm924nzc6kf6m6dr2l6t04p1t               	true 	68.4MB    	5 seconds ago
n1mq6swjl2yieubbye1e1dyjg               	true 	0B        	Less than a second ago
wjq8a2e7003ixvqulmwj7w8a5               	true 	3.144kB   	Less than a second ago
wibxmwpekzhzdgf59ltjl7djp               	true 	2.477GB   	59 seconds ago
s2r9rasg75rai76vq1yr57p0h               	true 	107.3MB   	6 seconds ago
8rbg7n8bi8djgd7v4zu274du8               	true 	746.5MB   	23 seconds ago
c84xzuc4cedx9s3wnxuh4ct57               	true 	0B        	Less than a second ago
qbydufcgecvlvff383ptec4ib               	true 	0B        	4 seconds ago
Total:	3.634GB
ID						RECLAIMABLE	SIZE		LAST ACCESSED
ginvvjcmeqo9d1ywai7uniy57               	true 		17.03MB   	8 minutes ago
bfi3nue5fcy98bllqfpjhrnf5*              	true 	4.096kB   	8 minutes ago
xvczyifbxfyt93g3e8wn0hpra               	true 	43.38MB   	8 minutes ago
y8or8ryz0k0hlbzsqtygsz31f               	true 	2.178GB   	8 minutes ago
frhx3okb3yt3a1cx15rh8doij               	true 	522.1kB   	8 minutes ago
jkotdgurx7vjieksh6i8cuedo               	true 	151B      	45 minutes ago
jjntlo74l3ytwnjkfbv469419               	true 	4.511kB   	45 minutes ago
d5h9j2mstr65h10xp6yjg2nzw               	true 	532.6kB   	45 minutes ago
jt54eop4mla5fwsu8cpomzwcx               	true 	32B       	45 minutes ago
ccbgzfwlhfk7effg93tm0hacu               	true 	93B       	45 minutes ago
nsbm1mp4pscqk3c5csmz4fjar               	true 	196.7kB   	45 minutes ago
belnpn9x5hragi7njjzru42dd               	true 	4.288kB   	45 minutes ago
xg5gvoflxc5a051ntlgmiz1rk               	true 	141.8MB   	45 minutes ago
bp1o42065rtiaptvajozssqtq               	true 	4.542kB   	45 minutes ago
bd0z536inzhhoa6brnlzq8907               	true 	6.625MB   	About an hour ago
pyz1arj7tuijmm4hogezi7uqz               	true 	269.1MB   	About an hour ago
037cgb6u7x0mq7dkrixlkv0i2               	true 	60.67kB   	About an hour ago
5o3epn1zatu8gak8ca3v3nuz6               	true 	825.9MB   	About an hour ago
lktznd2lmas9mj45sqt1ibfja               	true 	255.7MB   	About an hour ago
w89z0erggtkwthk4q4082m0hj               	true 	75.09MB   	About an hour ago
rbb6wjhfco7eueu0l4g9tw8wp               	true 	179MB     	About an hour ago
Total:	3.993GB

无解中，放弃buildx 多架构构建了，暂时单独找了amd和arm vps节点真实环境构建后合并。

有空再继续。

openclaw

wanjie — Sun, 01 Feb 2026 02:02:17 +0000

背景

引子：项目名字比代码变得还快

这两周，一个叫做 OpenClaw（或Moltbot，又或者 Clawdbot）的AI Agent突然大火，据说还带动了 Mac mini m4 的销售。客户和领导在群里一句"这个很火，看看能不能上架一个镜像"，我便开始了这段折腾之旅。

首先困扰我的不是技术，而是这项目改名太频繁了——从 Clawdbot 到 Moltbot 再到 OpenClaw。我 git clone 时看名字都觉得是不是自己下错了，而且隔天升级发现又变了一个名字了。我只能安慰自己：名字不重要，重要的是它确实能自动给你打工。

我们的目标是：构建镜像 → 上架算力云平台 → Demo 给客户看。听起来简单，对吧？

折腾过程

第一章：本地安装同时构建镜像

官方提供了三种安装方式，最香的自然是一键脚本 curl -fsSL https://openclaw.ai/install.sh | bash。官方提供了 Dockerfile和docker-setup.sh命令，但是没上架镜像，是不是担心流量太贵，于是我尝试来构建一下镜像。我打的镜像在这里 cnrock/openclaw:2026.1.30

构建搞了2天，主要原因是 vps 内存不给力，切换本地构建嘛，网络不给力。

几个报错

第一个报错 frame too large

ERROR: listing workers: failed to list workers: Unavailable: connection error:
desc = "error reading server preface: http2: frame too large"

解决套路很常规：重启试试。

# 重启 Docker 服务
sudo systemctl restart docker

# 删除现有 Buildx 构建器
docker buildx rm mybuilder 2>/dev/null || true

# 创建新的构建器
docker buildx create --use --name multiarch-builder

# 重新运行构建
docker buildx build --progress=plain --platform linux/amd64,linux/arm64 -f Dockerfile -t cnrock/openclaw:v1 . --push

第2个报错 JavaScript Heap Out of Memory

#21 370.0 FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
370.3  3: 0x1216eb7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
ERROR: failed to solve: process "/bin/sh -c OPENCLAW_A2UI_SKIP_MISSING=1 pnpm build" did not complete successfully: exit code: 134

在构建 ARM64 镜像时，Node.js 默认内存限制在多架构编译压力下直接爆掉：

vps 没个大内存机器真别玩多架构构建。

鉴于节点还是有 swap 内存的，尝试加参数看看，后来没这个报错了

# 设置 Node.js 内存限制
ENV NODE_OPTIONS="--max-old-space-size=4096"

第3个报错 no active session

no active session

找到了这个 issue https://github.com/docker/buildx/issues/456

引出了另一篇，buildx 升级，待后续有空写，暂时放弃buildx 多架构，直接本地docker 构建通过了

ERROR: failed to solve: DeadlineExceeded: failed to push cnrock/moltbot:v1-amd64: no active session for 2n6drhn4mikq0mn14h621ypw7: context deadline exceeded

第二章：安装的"灵魂拷问"

使用很香的一键脚本安装，真正的交互式"盘问"开始了。这安装程序设计得非常"贴心"——贴心到每个步骤都要你确认，仿佛在说：**"你真的知道自己在干什么吗？"**

第一关：安全警告

```
Please read: https://docs.clawd.bot/security
Clawdbot agents can run commands, read/write files...
I understand this is powerful and inherently risky. Continue?
```

翻译一下："这玩意儿能删你根目录，确定要继续吗？" 当然要，来都来了。

### 第二关：模型选择困难症
安装程序列出了一长串模型提供商，从 OpenAI、Anthropic 到国内的 Qwen、MiniMax，甚至还有 Venice AI、Z.AI 这种小众选择。

```
◆ Model/auth provider
│ ● OpenAI (Codex OAuth + API key)
│ ○ Anthropic
│ ○ MiniMax
│ ○ Qwen
│ ○ Moonshot AI
│ ...（还有十几个选项）
```

我先选择了 **Skip for now**，因为后面可以通过配置文件注入，更适合容器化场景。

第三关：Channel 选择

程序问你要连哪些聊天渠道：Telegram、WhatsApp、Discord、Slack、钉钉...足足列出了十几种。我选择了 **Skip for now**（后来手动配置了qwen，这是后话）。

第四关：Homebrew 的执念

程序强烈推荐安装 Homebrew 来管理依赖，甚至给出了安装命令。但在容器里装 Homebrew？但直接安装又告诉你 root 用户别玩 brew。

我选择了 npm 作为包管理器，并跳过了 Skill 依赖安装（后面发现有些功能确实因此受限，这是取舍）。

第四章：网关暴露的"安全悖论"

安装完成后，程序贴心地提示：
Dashboard link (with token): http://127.0.0.1:18789/?token=。。。。。。。 No GUI detected. Open from your computer: ssh -N -L 18789:127.0.0.1:18789 root@10.23.45.67

默认绑定在 127.0.0.1（loopback），意味着只有本机能访问。这对于服务器部署很不友好——我总不能每次看面板都先 SSH 打隧道吧？

于是我想：改成 LAN 模式，监听所有网卡试试：

```bash
clawdbot configure --section gateway
# 选择 LAN (All interfaces)
clawdbot gateway restart
```

改完访问，浏览器给了我一个冰冷的错误：

```
disconnected (1008): control ui requires HTTPS or localhost (secure context)
```

**顿悟时刻**：这是个安全设计！浏览器不允许在非安全上下文（非 HTTPS 或 localhost）中传输敏感 token。这意味着：

1. **本地开发**：用 localhost 没问题
2. **服务器部署**：必须上 HTTPS 证书
3. **直接暴露 IP**：被明确禁止

这也解释了为什么网上有那么多暴露的 OpenClaw 面板被扫描出来——很多人为了图方便，要么用 HTTP 暴露，要么把 token 写死在配置里。设置其他更多的key信息也暴露了。

第五章：使用篇

开始接入国产模型（通义千问）

clawdbot configure --section model

既然要上架国内算力云，用 OpenAI API 不太现实。我接入了阿里云的通义千问：

◆ Model/auth provider
│ ○ OpenAI (Codex OAuth + API key)
│ ○ Anthropic
│ ○ MiniMax
│ ● Qwen (OAuth)
│ ○ Moonshot AI

会让你在线激活

│  Open https://chat.qwen.ai/authorize?user_code=QL8QXQYK&client=qwen-code to approve  │
│  access.                                                                             │
│  If prompted, enter the code QL8QXQYK.

顺便解决

# 重启网关生效
clawdbot gateway restart

这里有个有趣的细节：Qwen 的 API 兼容 OpenAI 格式（compatible-mode/v1），这大大降低了接入成本。国内大模型厂商都在走"兼容 OpenAI 接口"的路线，这是一种务实的选择——既照顾了开发者习惯，又降低了迁移成本。


试玩
Webui 截图



访问看看，如果不带token ，会提示未授权。




bot在自动干活中


尾声：安全的冷思考
在整理这篇文章时，我搜索了一下暴露在互联网上的 OpenClaw/Moltbot 面板，结果触目惊心：

- 大量面板直接使用 HTTP 暴露，token 直接写在 URL 参数里 - 有些甚至配置了允许任意 IP 访问的 CORS - 更严重的，有些实例的.clawdbot 目录权限是 755，其他用户可读


这与各大云厂商（AWS、腾讯云、阿里云）力推"一键部署 Moltbot 云服务"形成了鲜明对比。**矛盾在于**：云服务需要便捷性，往往意味着更宽松的默认配置；而 AI Agent 的权限又极大（能执行命令、读写文件、访问代码仓库）。然后据说云厂商又开始搞各种阉割版。
 
给读者的建议：
没搞懂前千万别图方便随便暴露服务。

1. **永远不要**在没有 HTTPS 的情况下暴露 Control UI 2. **定期运行**clawdbot security audit，关注权限警告例如这个

openclaw security audit

🦞 OpenClaw 2026.1.30 (76b5208) — Your terminal just grew claws—type something and let the bot pinch the busywork.

OpenClaw security audit
Summary: 1 critical · 2 warn · 1 info
Run deeper: openclaw security audit --deep

CRITICAL
models.small_params Small models require sandboxing and web tools disabled
  Small models (<=300B params) detected:
- public/deepseek-r1-distill-qwen-32b (32B) @ agents.defaults.model.fallbacks (unsafe; sandbox=off; web=[web_fetch, browser])
Uncontrolled input tools allowed: web_fetch, browser.
Small models are not recommended for untrusted inputs.
  Fix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"]).

WARN
gateway.trusted_proxies_missing Reverse proxy headers are not trusted
  gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client checks cannot be spoofed.
  Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
fs.credentials_dir.perms_readable Credentials dir is readable by others
  /root/.openclaw/credentials mode=755; credentials and allowlists can be sensitive.
  Fix: chmod 700 /root/.openclaw/credentials

INFO
summary.attack_surface Attack surface summary
  groups: open=0, allowlist=0
tools.elevated: enabled
hooks: disabled
browser control: enabled


3. **使用 sandbox** 模式限制 Agent 的文件系统访问范围

4. **Token 管理**：考虑使用反向代理（Nginx/Caddy）做额外的鉴权层，不要只依赖应用自身的 token
 
结语：追风者的自白
从 "这名字到底叫啥" 到 "这面板千万别乱暴露"，这趟追风之旅充满了技术细节的魔鬼。OpenClaw/Moltbot/Clawdbot 确实是一个强大的工具——它能读代码、改配置、甚至自己 debug，但它也需要使用者有足够的安全意识。
最后附上我的双架构镜像，与官网相比，增加了 Playwright + Chromium 功能，具备浏览外网能力（最近发了10多个版本，随之我也打了10多版镜像，持续更新中吧）：

bash
docker pull cnrock/openclaw:latest
`

或者，如果你也想体验构建过程的"乐趣"，可以从上面的 Dockerfile 开始，记得给 Node.js 多分配点内存。

**毕竟，追风没问题，但别被风刮跑了。**

---

参考资料：

- OpenClaw 官网：https://openclaw.ai/
- Moltbot 项目：https://www.molt.bot/
- AWS 部署指南：https://aws.amazon.com/cn/blogs/china/deploying-moltbot-to-the-cloud/

playwright-waf-bypass

wanjie — Sat, 24 Jan 2026 01:08:24 +0000

背景

某个文档包下载站由于规避 pcdn 用户刷流量原因上了 waf 防护, 以前能直接下载的文件现在会报错 error 468 no description。

正确的解法有2种，1是申请白名单，2是浏览器真实访问下载。作为长期习惯下载命令下载文件的我，肯定不太习惯，于是在 AI 的帮助下，有了这篇使用 playwright 工具来对抗 waf 的文档，这里记录一下。

步骤

先侦查

第一回合，传统方式

改 uA 、上cookies、带 referrer，都无情的被拦截了，于是一点要先搞清 468 报错后面有啥，才能知己知彼, 一番折腾后，查看强行下载的 tar 包文件，发现了这段文字。
"name":"雷池","name_en":"SafeLine","product":"长亭","community":"社区版","link":"https://waf-ce.chaitin.cn/","link_en":"https://waf.chaitin.com/","self":true} 。。。 {en:"Security Detection Powered By",zh:"安全检测能力由"},suffix:{en:"",zh:"驱动"},name:{en:window.product_data?.name_en+" WAF",zh:window.product_data?.name+" WAF"},link:{en:window.product_data?.link_en,zh:window.product_data?.link},decrypting:{en:"Dynamic Decrypting",zh:"网页被保护，正在解密中"},failed:{en:"Decryption Failed",zh:"解密失败"},blocking:{en:"Access Forbidden",zh:"访问已被拦截"},"attack-desc":{en:"Blocked For Attack Detected",zh:"请求存在恶意行为，已被管理员拦截"}, 。。。

下载页面确实被长亭雷池 waf.chaitin.com社区版保护了。

研究对策

几轮测试拿到了这张图片，和前面雷池文字相似，说明有一个悄悄的验证。

第二回合：AI 出场

我边搜资料边问 ai 解法，ai给出了 playwright 这个工具。

AI 给的逻辑是使用 Playwright，加上会“演戏”的浏览器chrome ，配合 Xvfb 虚拟 1920×1080 大屏，24 位真彩，显卡号全配齐。

这样来测试下载。

第三回合：伪装学大师

AI 提示下陆续安装了这些工具
pip install playwright playwright-stealth playwright install-deps playwright install chromium apt-get install -y xvfb libgbm-dev

核心就一句：让浏览器以为自己在“真·有头”模式，实则后台跑在内存里下载。

配合：human_move()，手抖、加速、减速，轨迹，堪比期末考试划重点。
点击方式：9 点矩阵地毯式轰炸，保证“雷池”小按钮无处遁形。

通关

总结，依旧是按照地址列表，走命令行方式完成下载，此处截图一张纪念。

可能问题

当然是之后 waf 拦截方式升级，上验证码或算法之类，我这套办法就要废弃或继续改造了。因此，先低调的用吧。

AI infrastructure experience

wanjie — Sun, 18 Jan 2026 09:29:12 +0000

背景

入行这么多年，一直混迹在网络管理或最近数年K8S 私有化部署的软件层面。这两年虽然也开始折腾大模型，跟英伟达、沐曦、壁仞、燧原、天数（及其各类马甲）GPU 打交道，但主要集中在k8s 、驱动和模型适配的“软”层面上。

没成想，2025年底的最后一个多月，生活给了我一个大惊喜。我不小心一脚跨进了 GPU 硬件基础设施的深水区。正如标题所言，这是一场关于“AI 基础设施体验”的深度体验。

*(注：为了保住饭碗，具体客户和项目名已隐去，以下内容纯属硬核技术流水账)*

第一幕：销售嘴里“半天”的活儿

故事的开始总是极其草率。

某个周四晚上，大概8点半，回家的地铁上，领导电话来了：“郊区机房有批 GPU 集群，你过去支持下性能测试就行，半天，顶多一天。”

我看着手机屏幕，心想：*真的是去机房跑个脚本的事吗？* 领导也表示怀疑，说去现场看了就知道了。

随后发来一张截图，上面列着几个生僻的测试名称和几个模糊不清的压测指标——这就是我当时的全部情报。当晚，我硬是靠着搜索引擎，把这些工具一个个下载下来，折腾到凌晨12点多，才勉强把测试环境包装进U盘。

第二天，揣着那个存满“弹药”的U盘，我满怀信心地杀向机房所在地。

到了现场，发现我前一晚准备的U盘工具白费了，这里基本都有。跟驻场工程师和项目经理一聊，冷汗就下来了。还卡在dhcp 装机这个阶段摸索中，甚至连装机后的 ip地址都不敢固定，结果后面一堆冲突，测试基本是在u盘系统下搞的，这哪是性能测试啊，这分明是从零开始搞基建！

那一刻，我深刻领悟了一个真理：销售的嘴，骗人的鬼。

中午我意识到事情的严重，我厚着脸皮电话把领导请过来支援，第一天，我们直接干到凌晨3点。接下来的周末简直就是噩梦：3天睡了16小时，凌晨的机房边上的小黑屋成了第二个家。周日中午，销售和高层终于拉了个会议，把事情的全貌托盘而出——虽然晚了点，但好歹后方支援团队终于进来了。

接下来的十几天，凌晨1-3点下班是常态，甚至后面客户叫停了几天让我们短暂回血后，又是无休止的现场奋战。

第二幕：机房里的“冰火两重天”与听觉轰炸

虽然大部分时间我都在机房外的工作间里敲键盘，但只要进机房排查网口、模块或线路，那就是一场肉体的修行。

你要问我机房的体感？那是冰火两重天：机器前面吹过来的风是刺骨的冷，机器后面排出来的风是滚烫的热。

你要问我机房的听觉？那是一场无休止的工业噪音。
整个机房的噪音从未低于过 80 分贝，一旦走到机器附近，基本都在 90 分贝上下徘徊。最要命的是某款 B 卡机器，开关机的时候简直像起飞一样，直接干到了 100 分贝以上。

*(此处插入手机分贝计截图为证：app提醒我是“割草机”、“地铁列车”的场景)*

每次进去排查，就像站在地铁隧道里等车。当天回家后我老实了，立马下单了好几副便携式降噪耳塞。后来偶尔进机房，哪怕只待几分钟，我也一定把耳塞塞得紧紧的。

有时候站在那轰鸣的机柜前，我不禁在想：要是这些机器将来交付后满负荷跑起来，这附近的噪音该有多恐怖啊？

第三幕：我在机房干了啥？（AI 也没我想的那么聪明）

这一个多月，我到底在搞什么？看着这张充满错误的 AI 生成示意图（凑合看吧），我把这数百台设备（月底远程支持超数千台）的坑坑洼洼大概梳理了一下。

这张图是ai 画的，有不少错误，仅供参考。

1. 物理装机与“灵魂”初始化

首先是纯体力与脑力的结合。配合完成全部 GPU 服务器的上架、理线、上下电。（其实这部分是服务器厂商和机房运维等工程师干的，这样写，显得自己也吃了体力上的苦）
针对某2款高端卡 H 卡和 B 卡两种机型，因为规格不同，我们对每批机器进行差异化 BIOS 配置、网卡模式切换、启动顺序调整。
后来为了不被累死，眼睛不瞎，我写了几个脚本来采集 BMC 地址和业务网卡 MAC 地址还有其他信息。那一刻，效率提升不说，还没了人工手抄的差错，我觉得我终于开始有些收获了。

2. 网络“迷宫”搭建与玄学排查

接下来是 IB（InfiniBand）网卡和第二业务网的静态 IP 配置。
这块最折腾，特别是那几十台 B 卡机器，IB 卡地址配置后各种报错down。

互换排除法：排查掉卡或 IB 卡不通，很多时候是光纤模块或线的问题。这时候就得像换灯泡一样，在机房里把模块或线拔来拔去，通过互换定位故障点。
重启大法失灵：软件层面上故障，我们没招后一般会重启解决，ib 卡这边不吃这一套，越重启，掉的卡越多。然后又陷入回机房检查模块和线路的循环。
冷重启的魔力：最近发现了几台奇怪的机器，某几个IB 卡down或者 GPU 掉卡，厂商报修换了模块都不行。结果同事试着冷重启主机（完全断电再上电），居然就好了！看来与我们常说的重启大法不一样，硬件有时候也需要“断电重启”这一招大杀法。

最后配合客户做完 GPU 节点的 IB 网络连通性测试和误码率测试或多机测试，针对发现的网段不通问题及时反馈并协助排查。

3. 压测支持与掉卡“惊魂”

早期全程跟进 GPU 集群压测、装机，从单节点到多机分布式。
过程中不仅调脚本，还得处理各种奇葩问题：SSH 连不上、IB 网卡模式抽风、GPU 驱动兼容性冲突。
最惊心动魄的是，临近第一波交付前一个周末，上午过来发现数百台节点有“掉卡” 而且ib卡名也全变了，发现压测的工程师半夜干了一个我至今没搞清具体啥破坏的事，反正我排查的现象是某个服务停了。这可是大事，我立即摇人，排查修复，下午确保集群相关服务正常，ib 卡全部测通，不然验收这关过不了。

4. 自动化“外挂”

为了省事，我定制了几个小镜像，借用 BMC 挂载 ISO 的能力，一口气配置好 2 块业务网卡（后期的存储服务器甚至得配 4 块）。ps. 这2波机器没走pxe 装机，直接用了厂商的u盘装机，没有配置网络。
这一趟下来，大概写了 10 多个大小脚本。坦白说，其中一半的功劳得算在 AI 头上——毕竟我也是边问 AI 边写代码，主打一个“人机合一”。

第四幕：两种“心酸”的碰撞

回想起这两年的技术经历，真是两种不同的折磨：

以前适配国产 GPU 时，心酸在于“脑子累”。
那时候面对的是一个个莫名其妙的驱动报错、框架不兼容。你在屏幕前死磕代码，联系厂商工程师要文档，那种无力感是逻辑层面的。你是在跟软件的缺陷博弈。

现在搞英伟达硬件基建，心酸在于“身子累”。
现在是物理层面的攻击。你要忍受 100 分贝的噪音，忍受忽冷忽热的风，还要在几千根线缆里排查那个松动的模块。虽然英伟达的生态相对成熟，驱动问题少些，但当硬件规模上来后，物理连接、散热、电源、信号干扰……任何一个物理环节出问题，都会让你在机房里走到腿断。

以前是“为什么代码跑不通”的焦虑，现在是“为什么这块灯不亮”的崩溃，更崩溃的是，模块所有灯都正常，为何不通。可以说，一个折磨灵魂，一个折磨肉体。

第五幕：当前卡住的 BOSS（Supermicro SUM vs MFT）

虽然流程基本跑通了，但还留着一个让我头秃的遗留问题，特此记录，恳请各路大神指点：

【场景描述】
H 服务器插了 10 张 CX-7 网卡：

Slot 9 和 11：作为业务网卡；
其他 8 张：给 GPU 用的 IB 卡。

网卡部分架构如下图

【核心痛点】
PXE 装机前，必须先把业务网卡模式和EFI Retry以及业务网卡启动顺序改对，否则装机会卡住，目前是纯人工手动设置的。

【目前的坑】
我研究数天 Supermicro Update Manager (SUM)，发现这玩意儿在 UEFI BIOS 下搞不定这个事。问了几个 AI，它们众口一词：“你自己定制个包含 mft（主要是 mlxconfig）的工具，再加一系列脚本和镜像来实现。”

我这几天在就在这一步死磕摸索中。如果有大佬路过，欢迎不吝赐教！

总结

回想这一个多月，从最初某人口中的“半天兼职”，到现在硬刚几千台设备的 AI 基础设施建设。
虽然过程极其熬人，被噪音轰炸，被冷热交替折腾，看着凌晨三四点的机房天花板和机房外的小黑屋怀疑人生，回家后，发现附近的早餐点都开始营业了，你是啥感受，但看着集群绿灯常亮、压测通过的那一刻，那种成就感也是实打实的。

2025 的结尾，虽然没有诗和远方，但有 GPU、有脚本、有降噪耳塞（顺带最近2周还给老婆和自己各整了一幅降噪耳机），还有一群一起熬夜的兄弟，挺好。

veo3-vs-sora2

wanjie — Sat, 04 Oct 2025 15:25:26 +0000

背景

这次国庆放假没出远门，只在市里转悠，每天早上有一些时间可以玩电脑，赶上sora2 发布，简单和veo 3进行了几组对比测试。sora2 还是强不少，一句话总结，现阶段还是玩具，当然，主要可能是我玩法不对，看网友的整活挺不错的。

对照测试

小朋友投篮

sora2 这边场地非常中式，还有配音，不过关键问题是球没进。

sora2进球动画点这里

veo3 这边是美式人物和球场，但是场地看着像漫画，人是清晰的，球虽然进了，但球框高度有点问题。

veo3 进球动画点这里

sam偷gpu

sora2 截图

sora2 这边有比较有趣，给了监控视频的时间，保安还发现了sam，还有对话。

视频点这个地址

veo3 这边就很呆,只是监控看到sam拿走gpu，无趣。

视频点这里

另外2边都有一些触发版权或限制问题，不一一举例了。

sora 至少让肯尼迪唱了一首中文歌，视频点这里。

Jacky Cheung [60+] World Tour Shanghai Encore

wanjie — Fri, 03 Oct 2025 03:35:29 +0000

背景

9月初的某天老婆说张学友在上海开60+演唱会返场演出，要不要抢票听听，再不听就怕他唱不动了，于是就帮我抢了一下，前3场没抢到，月底9月26的顺利抢到了，当时还诧异这么好抢，后来老婆抢周杰伦的票完全没戏，于是我就去听了。

照片和视频

宣传海报上一张，加开3场。

开场前10分钟的照片，可以看到，我是属于3楼山顶上的朋友，当时还不太清楚为啥2楼右侧感觉没卖完，有不少空位。

今天写这篇博客的时候搜了新闻和看了wiki搞明白了，这次是返场，张学友60+ 演唱会在2024年3月初就来过上海，原来是15场不过中间学友哥中了新冠，没唱完，2024年10月补了9场，2025年9月返场6场，总共20多场，想看的早看了，这么想没卖完也是正常现象。

中间拍过几段视频和照片，刚才回头看，画质很一般，就不放出来了，挑1张照片纪念一下吧。

中途学友哥聊天用上海话开场，介绍自己这是 60+ 演出会系列第3次来到上海，学友哥确实敬业，挨个介绍乐队成员，对每个人都鞠躬，包括每首歌唱完退场都给观众鞠躬，还劈了一个一字，反正我是惊呆了。

看到前面有人拍视频，感觉视角不错，偷感很重，必须偷拍一张，哈哈。

隔天这次现场视频的第284场，发现B站有一个大佬内场拍的很清楚，直接点这个链接可以围观

一点感想

人说上了年纪如果没啥念想，就开始回忆，张学友都64了，我也马上50了，回过来想想，大概是上世纪80年代末，90年代初开始学唱张学友的歌，不敢说是40年，也是30多年，能算上学友哥的老歌迷了，中学听广播和买磁带的日子还是很快乐的，具体有那几张专辑已经记不清了，陆续买的几个磁带机也遗失了，只记得初中有一张草蜢的磁带被混社会的人借走没还，后来初中高中流行CD的时候还多次找一个老友借CD听歌，有印象的是张学友和李克勤。初中高中同学聚会KTV流行唱Beyond 和张学友、张国荣等等。大学后开始听打口碟，听摇滚，中英文都听。然后就突然老了，不咋听歌了。

其实还翻到1张老照片，大概是1986年的，我在辅导我弟弟作业吧，我妈妈在边上备课，确实要40年了。

KubeVirt uses custom virtual machines

wanjie — Mon, 29 Sep 2025 15:01:13 +0000

背景

翻了一下笔记，2023年底接触了kubevirt 这个k8s下的虚拟机项目，当时也只是简单的部署以及使用现有的几个镜像，2024年也断断续续使用过几次，直到今年2025年8月再次接触，制作了自己的镜像才算基本搞通了这个kubevirt 的使用，时间跨度有点大，这里记录一下。

准备工作

kvm 虚拟化

物理机ubuntu 系统

apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils -y

虚拟机 ubuntu 系统

apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager -y

虚拟机 rockylinux 系统

yum install -y qemu-kvm libvirt virt-install bridge-utils

嵌套虚拟化

如果测试机器本身是虚拟机，则还有一个工作，开启嵌套虚拟化。

修改 grub 设置

安装了前面的几个kvm 相关包之后，还需要修改 grub 设置。

vi /etc/default/grub  加上最后1部分
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rl/root intel_iommu=on"

重新生成 GRUB 配置文件

# 对于 BIOS 系统：
grub2-mkconfig -o /boot/grub2/grub.cfg
# 对于 UEFI 系统：
grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg
# 判断是bios还是uefi
ls /sys/firmware/efi  # 如果存在该目录，则为 UEFI

检查 qemu 状态

安装后，使用如下 virt-host-validate qemu 命令检查虚拟化是否正常

virt-host-validate qemu
  QEMU: Checking for hardware virtualization                                 : PASS
  QEMU: Checking if device /dev/kvm exists                                   : PASS
  QEMU: Checking if device /dev/kvm is accessible                            : PASS
  QEMU: Checking if device /dev/vhost-net exists                             : PASS
  QEMU: Checking if device /dev/net/tun exists                               : PASS
  QEMU: Checking for cgroup 'cpu' controller support                         : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support                     : PASS
  QEMU: Checking for cgroup 'cpuset' controller support                      : PASS
  QEMU: Checking for cgroup 'memory' controller support                      : PASS
  QEMU: Checking for cgroup 'devices' controller support                     : PASS
  QEMU: Checking for cgroup 'blkio' controller support                       : PASS
  QEMU: Checking for device assignment IOMMU support                         : PASS
  QEMU: Checking if IOMMU is enabled by kernel                               : PASS
  QEMU: Checking for secure guest support                                    : WARN (Unknown if this platform has Secure Guest support)

正式部署 kubevirt

参考 https://kubevirt.io/quickstart_cloud/，部署过程基本参考前面的官网链接，如下

yaml部署kubevirt

KubeVirt can be installed using the KubeVirt operator, which manages the lifecycle of all the KubeVirt core components.
查看kubevirt 当前最新版本 
export VERSION=$(curl -s https://storage.googleapis.com/kubevirt-prow/release/kubevirt/kubevirt/stable.txt)
echo $VERSION
v1.6.0

# 部署 kubevirt-operator
kubectl create -f "https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-operator.yaml"

# 输出如下
namespace/kubevirt created
customresourcedefinition.apiextensions.k8s.io/kubevirts.kubevirt.io created
priorityclass.scheduling.k8s.io/kubevirt-cluster-critical created
clusterrole.rbac.authorization.k8s.io/kubevirt.io:operator created
serviceaccount/kubevirt-operator created
role.rbac.authorization.k8s.io/kubevirt-operator created
rolebinding.rbac.authorization.k8s.io/kubevirt-operator-rolebinding created
clusterrole.rbac.authorization.k8s.io/kubevirt-operator created
clusterrolebinding.rbac.authorization.k8s.io/kubevirt-operator created
deployment.apps/virt-operator created


# 部署自定义资源
# Again use kubectl to deploy the KubeVirt custom resource definitions:

kubectl create 
-f "https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-cr.yaml"


#检查组件 Verify components
#By default KubeVirt will deploy 7 pods, 3 services, 1 daemonset, 3 deployment apps, 3 replica sets.

kubectl get kubevirt.kubevirt.io/kubevirt -n kubevirt -o=jsonpath="{.status.phase}"

Deploying( 再等等)

Check the components:

kubectl get all -n kubevirt

Warning: kubevirt.io/v1 VirtualMachineInstancePresets is now deprecated and will be removed in v2.
NAME                                READY   STATUS              RESTARTS   AGE
pod/virt-api-67778d48b6-7kjhm       0/1     ContainerCreating   0          19s
pod/virt-api-67778d48b6-z8lrq       0/1     ContainerCreating   0          20s
pod/virt-operator-b87fbb945-n7287   1/1     Running             0          3m35s
pod/virt-operator-b87fbb945-xl7pg   1/1     Running             0          3m34s

NAME                                  TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/kubevirt-operator-webhook     ClusterIP   10.233.48.98           443/TCP   26s
service/kubevirt-prometheus-metrics   ClusterIP   None                   443/TCP   26s
service/virt-api                      ClusterIP   10.233.49.2            443/TCP   26s
service/virt-exportproxy              ClusterIP   10.233.29.96           443/TCP   26s

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/virt-api        0/2     2            0           21s
deployment.apps/virt-operator   2/2     2            2           3m36s

NAME                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/virt-api-67778d48b6       2         2         0       21s
replicaset.apps/virt-operator-b87fbb945   2         2         2       3m36s

NAME                            AGE   PHASE
kubevirt.kubevirt.io/kubevirt   92s   Deploying

9分钟后，部署完成，主要是拉镜像通过了
kubectl get kubevirt.kubevirt.io/kubevirt -n kubevirt -o=jsonpath="{.status.phase}"
Deployed

这样检查也过了
kubectl get all -n kubevirt
Warning: kubevirt.io/v1 VirtualMachineInstancePresets is now deprecated and will be removed in v2.
NAME                                  READY   STATUS    RESTARTS   AGE
pod/virt-api-67778d48b6-7kjhm         1/1     Running   0          5m59s
pod/virt-api-67778d48b6-z8lrq         1/1     Running   0          6m
pod/virt-controller-8c6b9f8f4-4xhgd   1/1     Running   0          4m56s
pod/virt-controller-8c6b9f8f4-jcqzd   1/1     Running   0          4m56s
pod/virt-handler-642df                1/1     Running   0          4m55s
pod/virt-handler-crjvl                1/1     Running   0          4m55s
pod/virt-handler-tbmv7                1/1     Running   0          4m55s
pod/virt-operator-b87fbb945-n7287     1/1     Running   0          9m15s
pod/virt-operator-b87fbb945-xl7pg     1/1     Running   0          9m14s

NAME                                  TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/kubevirt-operator-webhook     ClusterIP   10.233.48.98           443/TCP   6m5s
service/kubevirt-prometheus-metrics   ClusterIP   None                   443/TCP   6m5s
service/virt-api                      ClusterIP   10.233.49.2            443/TCP   6m5s
service/virt-exportproxy              ClusterIP   10.233.29.96           443/TCP   6m5s

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/virt-handler   3         3         3       3            3           kubernetes.io/os=linux   4m56s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/virt-api          2/2     2            2           6m
deployment.apps/virt-controller   2/2     2            2           4m56s
deployment.apps/virt-operator     2/2     2            2           9m15s

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/virt-api-67778d48b6         2         2         2       6m
replicaset.apps/virt-controller-8c6b9f8f4   2         2         2       4m56s
replicaset.apps/virt-operator-b87fbb945     2         2         2       9m15s

NAME                            AGE     PHASE
kubevirt.kubevirt.io/kubevirt   7m11s   Deployed

部署 Virtctl 工具

VERSION=$(kubectl get kubevirt.kubevirt.io/kubevirt -n kubevirt -o=jsonpath="{.status.observedKubeVirtVersion}")
ARCH=$(uname -s | tr A-Z a-z)-$(uname -m | sed 's/x86_64/amd64/') || windows-amd64.exe
echo ${ARCH}
curl -L -o virtctl https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/virtctl-${VERSION}-${ARCH}
chmod +x virtctl
sudo install virtctl /usr/local/bin

部署 kubevirt cdi

https://kubevirt.io/labs/kubernetes/lab2.html

export VERSION=$(basename $(curl -s -w %{redirect_url} https://github.com/kubevirt/containerized-data-importer/releases/latest))
kubectl create -f https://github.com/kubevirt/containerized-data-importer/releases/download/$VERSION/cdi-operator.yaml
kubectl create -f https://github.com/kubevirt/containerized-data-importer/releases/download/$VERSION/cdi-cr.yaml

检查cdi 输出

kubectl -n cdi get all
Warning: kubevirt.io/v1 VirtualMachineInstancePresets is now deprecated and will be removed in v2.
NAME                               READY   STATUS    RESTARTS   AGE
pod/cdi-operator-ccb895984-w4b6n   1/1     Running   0          3m8s

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cdi-operator   1/1     1            1           3m8s

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/cdi-operator-ccb895984   1         1         1       3m8s
[root@gm-10-29-221-9 ~]# kubectl get cdi cdi -n cdi
NAME   AGE     PHASE
cdi    7m15s   Deployed
[root@gm-10-29-221-9 ~]# kubectl get pods -n cdi
NAME                              READY   STATUS    RESTARTS        AGE
cdi-apiserver-6c76687b66-6l7d2    1/1     Running   1 (5m48s ago)   7m11s
cdi-deployment-5f6ff949d7-mlrth   1/1     Running   0               7m9s
cdi-operator-ccb895984-w4b6n      1/1     Running   0               10m
cdi-uploadproxy-b499c7956-lsh5r   1/1     Running   0               7m7s

检查集群确认有 sc

kubectl get sc
NAME                                   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
hwameistor-storage-lvm-hdd (default)   lvm.hwameistor.io       Retain          WaitForFirstConsumer   true                   100d
local-path                  rancher.io/local-path   Delete          WaitForFirstConsumer   false                  100d

测试fedora 镜像，补上 sc 等字段

cat < dv_fedora.yml
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: "fedora"
spec:
  storage:
    resources:
      requests:
        storage: 5Gi
    storageClassName: hwameistor-storage-lvm-hdd
    accessModes:
      - ReadWriteOnce
    volumeMode: Filesystem
  source:
    http:
      url: "https://download.fedoraproject.org/pub/fedora/linux/releases/40/Cloud/x86_64/images/Fedora-Cloud-Base-AmazonEC2.x86_64-40-1.14.raw.xz"
EOF

kubectl create -f dv_fedora.yml

启动一个vm1 虚拟机

wget https://kubevirt.io/labs/manifests/vm1_pvc.yml
cat vm1_pvc.yml

修改前
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  creationTimestamp: 2018-07-04T15:03:08Z
  generation: 1
  labels:
    kubevirt.io/os: linux
  name: vm1
spec:
  runStrategy: Always
  template:
    metadata:
      creationTimestamp: null
      labels:
        kubevirt.io/domain: vm1
    spec:
      domain:
        cpu:
          cores: 2
        devices:
          disks:
          - disk:
              bus: virtio
            name: disk0
          - cdrom:
              bus: sata
              readonly: true
            name: cloudinitdisk
        machine:
          type: q35
        resources:
          requests:
            memory: 1024M
      volumes:
      - name: disk0
        persistentVolumeClaim:
          claimName: fedora
      - cloudInitNoCloud:
          userData: |
            #cloud-config
            hostname: vm1
            ssh_pwauth: True
            disable_root: false
            ssh_authorized_keys:
            - ssh-rsa YOUR_SSH_PUB_KEY_HERE
        name: cloudinitdisk
        

# Generate a password-less SSH key using the default location.
ssh-keygen
PUBKEY=`cat ~/.ssh/id_rsa.pub`
sed -i "s%ssh-rsa.*%$PUBKEY%" vm1_pvc.yml
kubectl create -f vm1_pvc.yml

fedora 起来了

virtctl console vm1 进入这个虚拟机实例

用户是 fedora ,没有密码，ssh fedora@10.233.85.4 前面用了ssk-key

暴露一个nodeport

virtctl expose vmi vm1 --name=vm1-ssh --port=20222 --target-port=22 --type=NodePort

顺利完成第一轮测试，后面自制rocky linux 8.10镜像以及win10-ltsc-2021-6216版本

定制镜像

这次自己打包了2个镜像，rockylinux 和 windows ltsc 2021.

rockylinux 镜像比较简单，rockylinux.org 官方就有 cloud 镜像，下载，重新打包即可。

wget -c https://dl.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-GenericCloud-Base.latest.x86_64.qcow2

vi Dockerfile

FROM scratch
ADD --chown=107:107 Rocky-8-GenericCloud-Base.latest.x86_64.qcow2 /disk/

docker build -t 10.29.221.9/public/rockylinux:v810 .
docker push  10.29.221.9/public/rockylinux:v810

rocky810的镜像构建

首先rockylinux官网下载 Rocky-8-GenericCloud-Base.latest.x86_64.qcow2 云镜像，然后本地构建一下

wget -c https://dl.rockylinux.org/pub/rocky/8/images/aarch64/Rocky-8-GenericCloud-Base.latest.aarch64.qcow2

vi Dockerfile
FROM scratch
ADD --chown=107:107 Rocky-8-GenericCloud-Base.latest.x86_64.qcow2 /disk/

nerdctl build --platform=amd64 -t 10.29.221.9/public/rockylinux:v810  .

处理 rockylinux8 的 datavolume

kubectl get datavolumes.cdi.kubevirt.io  rocky810-rootdisk -oyaml
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  labels:
    kubevirt.io/created-by: 2782666c-6914-4395-8362-0067661a02b0
  name: rocky810-rootdisk
  namespace: default
spec:
  pvc:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
    storageClassName: hwameistor-storage-lvm-hdd
  source:
    registry:
      url: docker://10.29.221.9/public/rockylinux:v810

rocky810 vm 配置

kubectl get vm rocky810 -oyaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  annotations:
    kubevirt.io/latest-observed-api-version: v1
    kubevirt.io/storage-observed-api-version: v1
    virtnest.io/alias-name: ""
    virtnest.io/image-secret: ""
    virtnest.io/image-source: docker
    virtnest.io/os-image: 10.29.221.9/public/rockylinux:v810
  labels:
    virtnest.io/os-family: rocky
    virtnest.io/os-version: "810"
  name: rocky810
  namespace: default
spec:
  dataVolumeTemplates:
  - metadata:
      creationTimestamp: null
      name: rocky810-rootdisk
      namespace: default
    spec:
      pvc:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
        storageClassName: hwameistor-storage-lvm-hdd
      source:
        registry:
          url: docker://10.29.221.9/public/rockylinux:v810
  runStrategy: Always
  template:
    metadata:
      creationTimestamp: null
    spec:
      architecture: amd64
      domain:
        cpu:
          cores: 1
          sockets: 1
          threads: 1
        devices:
          disks:
          - bootOrder: 1
            disk:
              bus: virtio
            name: rootdisk
          - disk:
              bus: virtio
            name: cloudinitdisk
          interfaces:
          - masquerade: {}
            name: default
        machine:
          type: q35
        memory:
          guest: 2Gi
        resources: {}
      networks:
      - name: default
        pod: {}
      volumes:
      - dataVolume:
          name: rocky810-rootdisk
        name: rootdisk
      - cloudInitNoCloud:
          userDataBase64: I2Nsb3VkLWNvbmZpZwpzc2hfcHdhdXRoOiB0cnVlCmRpc2FibGVfcm9vdDogZmFsc2UKY2hwYXNzd2Q6IHsibGlzdCI6ICJyb290OkRhb2Nsb3VkLjIwMjMiLCBleHBpcmU6IEZhbHNlfQoKd3JpdGVfZmlsZXM6CiAgLSBwYXRoOiAvZXRjL3N5c3RlbWQvc3lzdGVtL2RoY2xpZW50LW9uLWJvb3Quc2VydmljZQogICAgcGVybWlzc2lvbnM6ICIwNjQ0IgogICAgY29udGVudDogfAogICAgICBbVW5pdF0KICAgICAgRGVzY3JpcHRpb249UnVuIGRoY2xpZW50IG9uIGJvb3QKICAgICAgQWZ0ZXI9bmV0d29yay50YXJnZXQKCiAgICAgIFtTZXJ2aWNlXQogICAgICBUeXBlPW9uZXNob3QKICAgICAgRXhlY1N0YXJ0PS9zYmluL2RoY2xpZW50CiAgICAgIFJlbWFpbkFmdGVyRXhpdD10cnVlCgogICAgICBbSW5zdGFsbF0KICAgICAgV2FudGVkQnk9bXVsdGktdXNlci50YXJnZXQKcnVuY21kOgogIC0gc3lzdGVtY3RsIGRhZW1vbi1yZWxvYWQKICAtIHN5c3RlbWN0bCBlbmFibGUgZGhjbGllbnQtb24tYm9vdC5zZXJ2aWNlCiAgLSBzeXN0ZW1jdGwgc3RhcnQgZGhjbGllbnQtb24tYm9vdC5zZXJ2aWNlCiAgLSBzZWQgLWkgIi8jXD9QZXJtaXRSb290TG9naW4vcy9eLiokL1Blcm1pdFJvb3RMb2dpbiB5ZXMvZyIgL2V0Yy9zc2gvc3NoZF9jb25maWc=
        name: cloudinitdisk

kubectl apply -f rocky810.yaml

检查一下vm 状态

kubectl get vm -A
NAMESPACE   NAME       AGE   STATUS    READY
default     rocky810   50d   Running   True
default     win10      46d   Running   True

windows 10 ltsc 2021版镜像

然后是这次折腾的重点windows 10 ltsc 2021版镜像

当前大家默认使用的是cloudbase 的win10 专业版镜像，使用上感觉有点卡，于是尝试以前使用的windows 10 ltsc 2021。

先检查之前安装的 kubevirt cdi 服务

kubectl -n cdi get svc -l cdi.kubevirt.io=cdi-uploadproxy
NAME              TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
cdi-uploadproxy   ClusterIP   10.233.7.11           443/TCP   3h24m

然后用virtctl 上传原始ISO镜像，实际名称为

19044.6216.250813-0800.vb_refresh_enterprise_ltsc_2021_x64freo_zh-cn_1b2d3b40.iso，这里改成 win10_ltsc.iso

virtctl image-upload --image-path=win10_ltsc.iso   --storage-class hwameistor-storage-lvm-hdd  pvc iso-win10   --size=7Gi    --insecure --uploadproxy-url=https://10.233.7.11 --force-binds

输出日志为

PVC default/iso-win10 not found
PersistentVolumeClaim default/iso-win10 created
Waiting for PVC iso-win10 upload pod to be ready...
Pod now ready
Uploading data to https://10.233.7.11

4.64 GiB / 4.64 GiB [-------------------------------------------------------------------------------------] 100.00% 42.76 MiB p/s 1m51s

Uploading data completed successfully, waiting for processing to complete, you can hit ctrl-c without interrupting the progress
Processing completed successfully
Uploading win10_ltsc.iso completed successfully

然后用这个 yaml 部署 vm

cat win10.vm.yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: win10
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/domain: win10
    spec:
      domain:
        cpu:
          cores: 4
        devices:
          disks:
          - bootOrder: 1
            cdrom:
              bus: sata
            name: cdromiso
          - disk:
              bus: virtio
            name: harddrive
          - cdrom:
              bus: sata
            name: virtiocontainerdisk
          interfaces:
          - masquerade: {}
            model: e1000
            name: default
        machine:
          type: q35
        resources:
          requests:
            memory: 16G
      networks:
      - name: default
        pod: {}
      volumes:
      - name: cdromiso
        persistentVolumeClaim:
          claimName: iso-win10
      - name: harddrive
        hostDisk:
          capacity: 50Gi
          path: /data/disk.img
          type: DiskOrCreate
      - containerDisk:
          image: dce-boot.io/docker.io/kubevirt/virtio-container-disk
        name: virtiocontainerdisk

kubectl apply -f win10.vm.yaml

然后代理出来，用vnc 工具开始安装

virtctl vnc --proxy-only win10

好几年没搞过 ltsc 安装了，看到多了一个 iot版本 ltsc

默认看不到可用盘

直接确定，选择驱动位置。

选择第二个，和很久以前相比多了直通这一组驱动

这次截图只给了25G磁盘了，后来另一套环境扩到50G了

kubectl get pvc disk-windows -oyaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"disk-windows","namespace":"default"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"25Gi"}},"storageClassName":"local-path"}}
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: rancher.io/local-path
    volume.kubernetes.io/selected-node: gm-10-29-221-9
    volume.kubernetes.io/storage-provisioner: rancher.io/local-path
  creationTimestamp: "2025-08-16T04:04:44Z"
  finalizers:
  - kubernetes.io/pvc-protection
  name: disk-windows
  namespace: default
  resourceVersion: "32202616"
  uid: d06116f4-606e-4567-884f-cb11bb44e8c0
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 25Gi
  storageClassName: local-path
  volumeMode: Filesystem
  volumeName: pvc-d06116f4-606e-4567-884f-cb11bb44e8c0
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 25Gi
  phase: Bound

然后是正常安装

遇到了一次登录交互报错

强制重启后，到了熟悉的界面，海内存知己

隐私网络等设置

第一次画面，地球仪图标打了叉，没有网络。

设备管理这里没有网卡设备，需要安装驱动。

pci 这里打了问号

安装驱动

一路确认即可

看到卡设备了，其他几个问号的pci 依样画葫芦即可。

开启远程桌面

关机，转换当前系统 disk.img 为标准镜像

cd /opt/local-path-provisioner/pvc-d06116f4-606e-4567-884f-cb11bb44e8c0_default_disk-windows/
qemu-img convert -O qcow2 disk.img win10.ltsc.qcow2
得到1个12G的qcow2 格式镜像

# dockerfile构建
FROM scratch

COPY --chown=107:107 --from=build win10.ltsc.qcow2 /disk/win10.ltsc.qcow2

构建并推送
nerdctl build --platform=amd64 -t dce-boot.io/public/win10.ltsc:v1 --insecure-registry .

遗留问题

dce-boot.io/public/win10.ltsc:v1 这个镜像没有经过类似 cloudbase 的优化，印象中不能直接给其他环境使用，直接启动，下次有空再补文档吧。

2025-10-13 更新

今天找环境使用了这个镜像，能直接在虚拟机模块使用，不用用户再次初始化，但是有2个小问题，它会继续更新补丁，这时电脑会很卡，另外据说2025-10-14 后，win10 不再更新。然后磁盘占用比较厉害，30G的盘干掉了20G，需要精简。以后要么直接用精简版开始构建镜像吧。

更新后，系统信息这样的界面，我没看过，截图存档。

参考文档

ClusterLoader2压测K8s的血泪史

wanjie — Thu, 29 May 2025 12:55:37 +0000

背景：

最近接了个POC任务，其中一项是用ClusterLoader2对K8s集群进行压测。本以为是个"常规项目"，结果这玩意儿前前后后折腾了我2周！昨晚终于跑通，现在趁热纪录，给自己和新手避坑~

🚀 极简操作指南

克隆代码（版本要对！）

git clone -b release-1.31 https://github.com/kubernetes/perf-tests.git

本次k8s 环境1.31 , 因此直接clone 这个版本分支

终极启动命令

./clusterloader --masterip=10.29.229.221 --testconfig=config.yaml --provider=local --provider-configs=ROOT_KUBECONFIG=/root/kubeconfig4clusterloader --kubeconfig=/root/kubeconfig4clusterloader --v=5 --enable-prometheus-server=false   --nodes=2 2>&1 | tee output.txt

用到的config.yaml 测试配置文件

name: nginx-pod-latency-test
namespace:
  number: 1

tuningSets:
- name: Uniform5qps
  globalQPSLoad:
    qps: 10
    burst: 10

steps:
- module:
    path: /perf-tests/clusterloader2/testing/load/modules/pod-startup-latency.yaml
    params:
      namespaces: 1
      minPodsInSmallCluster: 10
      image: registry.cn-shanghai.aliyuncs.com/my2021/2048:motd
      resourceLimits:
        - name: cpu
          limit: 1
        - name: memory
          limit: 1Gi

- module:
    path: /perf-tests/clusterloader2/testing/load/modules/reconcile-objects.yaml
    params:
      actionName: "create"
      namespaces: 1
      tuningSet: Uniform5qps
      testMaxReplicaFactor: 1.0
      operationTimeout: "5m"
      deploymentImage: "registry.cn-shanghai.aliyuncs.com/my2021/2048:motd"
      daemonSetImage: "registry.cn-shanghai.aliyuncs.com/my2021/2048:motd"
      bigDeploymentSize: 10
      bigDeploymentsPerNamespace: 1
      mediumDeploymentSize: 0
      mediumDeploymentsPerNamespace: 0
      smallDeploymentSize: 0
      smallDeploymentsPerNamespace: 0
      smallStatefulSetSize: 0
      smallStatefulSetsPerNamespace: 0
      mediumStatefulSetSize: 0
      mediumStatefulSetsPerNamespace: 0
      smallJobSize: 0
      smallJobsPerNamespace: 0
      mediumJobSize: 0
      mediumJobsPerNamespace: 0
      bigJobSize: 0
      bigJobsPerNamespace: 0
      daemonSetReplicas: 0
      CL2_CHECK_IF_PODS_ARE_UPDATED: "true"
      CL2_DISABLE_DAEMONSETS: "true"
      CL2_ENABLE_PVS: "false"

- module:
    path: /perf-tests/clusterloader2/testing/load/modules/reconcile-objects.yaml
    params:
      actionName: "delete"
      namespaces: 1
      tuningSet: Uniform5qps
      testMaxReplicaFactor: 0.0
      operationTimeout: "5m"
      bigDeploymentSize: 10
      bigDeploymentsPerNamespace: 0
      mediumDeploymentSize: 0
      mediumDeploymentsPerNamespace: 0
      smallDeploymentSize: 0
      smallDeploymentsPerNamespace: 0
      smallStatefulSetSize: 0
      smallStatefulSetsPerNamespace: 0
      mediumStatefulSetSize: 0
      mediumStatefulSetsPerNamespace: 0
      smallJobSize: 0
      smallJobsPerNamespace: 0
      mediumJobSize: 0
      mediumJobsPerNamespace: 0
      bigJobSize: 0
      bigJobsPerNamespace: 0
      daemonSetReplicas: 0
      CL2_CHECK_IF_PODS_ARE_UPDATED: "true"
      CL2_DISABLE_DAEMONSETS: "true"
      CL2_ENABLE_PVS: "false"

💥 踩过的深坑

第一个坑，构建二进制文件失败

go build -x -v -o clusterloader clusterloader.go

提示版本报错

go: errors parsing go.mod:
/root/perf-tests/clusterloader2/go.mod:4: invalid go version '1.22.4': must match format 1.23

按照提示，改下即可继续. 同事告诉我go 1.24.3版本构建无需修改这个文件, 升级了节点的go环境，再跑果然正常了。

安装go 1.24版本的2种操作

sudo add-apt-repository ppa:longsleep/golang-backports 
sudo apt install golang-1.24 
echo 'export PATH=/usr/lib/go-1.24/bin:$PATH' >> ~/.profile 
sed -i 's|export PATH=$PATH:/usr/lib/go-1.24/bin|export PATH=/usr/lib/go-1.24/bin:$PATH|' ~/.profile
source ~/.profile
which go
go env GOROOT
cd perf-tests/clusterloader2/cmd/
GOARCH=amd64 GOOS=linux go build -x -v -o clusterloader clusterloader.go

小结：Go版本≥1.24才能丝滑构建

第3个坑：路径玄学

灵异现象：配置文件死活找不到

配置的config.yaml 文件，里面的引用文件居然不能用绝对路径，只能相对它的路径，如下这种格式

- module:
path: /perf-tests/clusterloader2/testing/load/modules/reconcile-objects.yaml

第3个坑 prometheus

参数启用了--enable-prometheus-server=true 时，

会创建一个monitor的ns，和几个pod，以及名为ssd的sc

kubectl get sc |grep ssd
ssd kubernetes.io/gce-pd Delete Immediate false 125m

解决办法自然是不用prometheus ，这里的值改成fasle，或者直接去掉。

调参相关

1, 默认延时问题

这里的值5秒，虚拟环境还真拉不起一个pod，改长点，后来发现物理机可以1-3秒全部跑完，不用改。

{{$podStartupLatencyThreshold := DefaultParam .CL2_POD_STARTUP_LATENCY_THRESHOLD "5s"}} #改到50s

/perf-tests/clusterloader2/testing/load/simple-deployment.yaml

2， configmap和secrets问题

deployment.yaml ，里面调用了 configmap和secrets ，导致big 测试时过不去，注释掉这2个相关设置清净了。

🎉 胜利的曙光

成功压测结果类似如下

......
I0529 20:08:37.024845 1474234 simple_test_executor.go:87] StatelessPodStartupLatency_PodStartupLatency: {
  "version": "1.0",
  "dataItems": [
    {
      "data": {
        "Perc50": 32737.558438,
        "Perc90": 44789.393112,
        "Perc99": 48925.585207
      },
      "unit": "ms",
      "labels": {
        "Metric": "schedule_to_watch"
      }
    },
    {
      "data": {
        "Perc50": 33592.923438,
        "Perc90": 44913.893112,
        "Perc99": 50046.076207
      },
      "unit": "ms",
      "labels": {
        "Metric": "pod_startup"
      }
    },
......
I0529 20:08:37.027944 1474234 reflector.go:319] Stopping reflector apps/v1, Resource=deployments (0s) from pkg/mod/k8s.io/client-go@v0.32.3/tools/cache/reflector.go:251
I0529 20:08:47.083242 1474234 simple_test_executor.go:402] Resources cleanup time: 10.058361346s
I0529 20:08:47.083302 1474234 clusterloader.go:252] --------------------------------------------------------------------------------
I0529 20:08:47.083309 1474234 clusterloader.go:253] Test Finished
I0529 20:08:47.083314 1474234 clusterloader.go:254]   Test: config-5.yaml
I0529 20:08:47.083320 1474234 clusterloader.go:255]   Status: Success
I0529 20:08:47.083326 1474234 clusterloader.go:259] --------------------------------------------------------------------------------

JUnit report was created: /root/junit.xml
I0529 20:08:47.086100 1474234 prometheus.go:331] Get snapshot from Prometheus

补充说明，最终在物理机上测试，平均1-3秒搞定。

参考资料

k8s部署zabbix 6.0并添加监控（监控k8s资源）

https://bingerambo.com/posts/2020/12/k8s集群性能测试-clusterloader/

K8s集群性能测试

metax c500 vgpu

wanjie — Sat, 05 Apr 2025 10:41:00 +0000

背景：

继上次metax c500上跑了deepseek 70b蒸馏模型后，遇到一个新任务，要将卡切分为vgpu模式，也就是metax 的 VF模式，看了资料似乎很简单。安装metax 的 gpu operator ,然后修改driver-config 的 ConfigMap 即可，实际上，这里又卡了我一天。

步骤如下：

1. 安装gpu_sched模块

ubuntu示例
sudo apt update
sudo apt install linux-modules-extra-$(uname -r)
sudo reboot

2. 安装驱动

官网搜索metax-driver-mxc500，比如ubuntu下载metax-driver-mxc500-2.25.0.3-deb-x86_64.run，版本可选
chmod +x metax-driver-mxc500-2.25.0.3-deb-x86_64.run
./metax-driver-mxc500-2.25.0.3-deb-x86_64.run
sudo reboot 重启机器
mx-smi 打印信息，确定驱动安装成功

3.升级vbios

mx-smi -L 查询板卡ID，如MXC550
cd /lib/firmware/metax/mxc500 查看vbios列表，选择一个版本
mx-smi -u /lib/firmware/metax/mxc500/mxvbios-1.20.3.0-645-C500-VF.bin -t 600 升级
sudo reboot 重启机器

实际上就是这步踩了坑, 目录结构中的这些bin文件不理解。以前只知道使用这个 mxvbios-1.20.3.0-645-C500.bin 来升级。请教了沐曦的工程师后才证实了之前的文件名疑惑。

/lib/firmware/metax/mxc500# tree
.
├── mxvbios-1.20.3.0-645-C280-ATS.bin
├── mxvbios-1.20.3.0-645-C280.bin
├── mxvbios-1.20.3.0-645-C280-VF.bin
├── mxvbios-1.20.3.0-645-C290-ATS.bin
├── mxvbios-1.20.3.0-645-C290.bin
├── mxvbios-1.20.3.0-645-C290-VF.bin
├── mxvbios-1.20.3.0-645-C500-ATS.bin
├── mxvbios-1.20.3.0-645-C500.bin
├── mxvbios-1.20.3.0-645-C500-P-ATS.bin
├── mxvbios-1.20.3.0-645-C500-P.bin
├── mxvbios-1.20.3.0-645-C500-P-VF.bin
├── mxvbios-1.20.3.0-645-C500-VF.bin
├── mxvbios-1.20.3.0-645-C500X-ATS.bin
├── mxvbios-1.20.3.0-645-C500X.bin
├── mxvbios-1.20.3.0-645-C500X-VF.bin
├── mxvbios-1.20.3.0-645-C550-ATS.bin
├── mxvbios-1.20.3.0-645-C550.bin
├── mxvbios-1.20.3.0-645-C550-P-ATS.bin
├── mxvbios-1.20.3.0-645-C550-P.bin
├── mxvbios-1.20.3.0-645-C550-P-VF.bin
├── mxvbios-1.20.3.0-645-C550-VF.bin
├── mxvbios-1.20.3.0-645-N260-ATS.bin
├── mxvbios-1.20.3.0-645-N260.bin
├── mxvbios-1.20.3.0-645-N260-VF.bin
├── mxvbios-1.20.3.0-645-N450-ATS.bin
├── mxvbios-1.20.3.0-645-N450.bin
├── mxvbios-1.20.3.0-645-N450-VF.bin
├── vpud0_fw.bin
├── vpud1_fw.bin
└── vpue_fw.bin

4.安装gpu-operator

helm install gpu-operator metax-operator-0.9.0.tgz -n gpu-operator
部分使用的镜像带amd，arm等后缀，但是第一步解压的包不带，手动打tag
缺少部分镜像，比如metax-maca，需要去官网下载系统对应的镜像离线包，比如maca-c500:2.24.0.5-ubuntu22.04-amd64
缺少部分镜像，比如driver-image，需要去官网下载k8s-driver-image.2.24.0.10-x86_64.run脚本，按照脚本提示得到镜像

修改 gpu operator ,然后修改driver-config 的 ConfigMap
node-vfnums 这个部分修改
```
nodes:
  worker-mxgpu01:  # gpu1 节点名
    vfnum: 4       #显卡1分为4
  worker-mxgpu02:  # gpu2 节点名
    vfnum:         2 #显卡1分为2
```
此时在节点上使用 mx-smi 查看，可以发现 vgpu 输出为 40了，或许你会好奇8*4 不是应该32块么。哈哈，这里先卖个小关子。

容器单独调用1张vgpu截图，正常。

观察后发现，前面的数字 40，来源于32个 Metax C500 VF和 8张 Metax C500 PF，编号分别是0～31 和 101～107。

这下算是搞懂沐曦vgpu如何切换了。

biren110e with DeepSeek-R1-Distill

wanjie — Sat, 05 Apr 2025 10:21:30 +0000

背景：

之前提到过，3月简单折腾过3种国产卡，这篇壁仞biren110e的测试其实也是当时做的，昨天补了一个简单压测数据，还是发出来吧。

准备工作

Daocloud k8s 环境

8 块或 4块壁仞 Biren110E （32G版本），驱动已正常安装

1，下载壁仞 birensupa-vllm-25.02.07-C026S001T001B12997.tar 大概 12G

2，下载 DeepSeek-R1-Distill-Llama-8B 模型文件大概 15G , DeepSeek-R1-Distill-Qwen-32B 模型文件大概 71G (modelscope、或 huggingface下载均可)

3，测试目标，单卡8b，4卡32b

部署

脚本

根据卡类型调整里面的参数

kind: Deployment
apiVersion: apps/v1
metadata:
  name: deepseek-r1-8b
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deepseek-r1-8b
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: deepseek-r1-8b
    spec:
      volumes:
        - name: volume-1741680483375
          hostPath:
            path: /br_data/model/model_weitht/DeepSeek-R1-Distill-Llama-8B
            type: ''
        - name: volume-1741684397558
          emptyDir:
            medium: Memory
            sizeLimit: 16Gi
      containers:
        - name: container-1
          image: birensupa-vllm:25.02.07-c026s001t001b12997
          command:
            - /bin/bash
            - '-c'
          args:
            - sleep infinity & wait
          env:
            - name: BRTB_DISABLE_ZERO_WS
              value: '1'
            - name: BRTB_DISABLE_ZERO_OUTPUT_UMA
              value: '1'
            - name: BRTB_DISABLE_ZERO_OUTPUT_NUMA
              value: '1'
            - name: BRTB_DISABLE_ZERO_REORDER
              value: '1'
            - name: BR_UMD_DEBUG_P2P_ACCESS_CHECK
              value: '1'
            - name: VLLM_WORKER_MULTIPROC_METHOD
              value: spawn
          resources:
            limits:
              birentech.com/gpu: '1'
          volumeMounts:
            - name: volume-1741680483375
              mountPath: /br_data/model/model_weitht/DeepSeek-R1-Distill-Llama-8B
            - name: volume-1741684397558
              mountPath: /dev/shm
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: IfNotPresent
          securityContext:
            privileged: true
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      dnsPolicy: ClusterFirst
      securityContext: {}
      affinity: {}
      schedulerName: default-scheduler
      tolerations:
        - key: node.kubernetes.io/not-ready
          operator: Exists
          effect: NoExecute
          tolerationSeconds: 300
        - key: node.kubernetes.io/unreachable
          operator: Exists
          effect: NoExecute
          tolerationSeconds: 300
      dnsConfig: {}
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600

测试

简单压测

容器内部测试脚本

python  /workspace/vllm_tools/vllm/benchmarks/benchmark_serving.py \
    --model DeepSeek-R1-Distill-Qwen-32B \
    --tokenizer /br_data/model/model_weitht/DeepSeek-R1-Distill-Llama-8B \
    --dataset_name random --random_input_len 4096 --random_output_len 1024   --num-prompts 64  \
    --trust-remote-code  --port 8000

首轮测试，效果不理想

============ Serving Benchmark Result ============
Successful requests:                     64
Benchmark duration (s):                  1044.75
Total input tokens:                      262144
Total generated tokens:                  49985
Request throughput (req/s):              0.06
Output token throughput (tok/s):         47.84
Total Token throughput (tok/s):          298.76
---------------Time to First Token----------------
Mean TTFT (ms):                          438997.17
Median TTFT (ms):                        419538.92
P99 TTFT (ms):                           921304.29
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          155.02
Median TPOT (ms):                        153.33
P99 TPOT (ms):                           226.29
---------------Inter-token Latency----------------
Mean ITL (ms):                           155.07
Median ITL (ms):                         124.17
P99 ITL (ms):                            255.33
==================================================

单卡测试

临时启动8b模型（后期可调优，改为自动启动）

......
临时容器内启动命令
python3 -m vllm.entrypoints.openai.api_server --served-model-name DeepSeek-R1-Distill-Qwen-32B  --model /br_data/model/model_weitht/DeepSeek-R1-Distill-Llama-8B  --gpu_memory_utilization=0.8 --block_size=128 --port 8000 --dtype=bfloat16 --tensor-parallel-size 1 --max-model-len 32768 --max-num-seqs 8 --max_num_batched_tokens 8192 --enable_chunked_prefill  --trust-remote-code --device=supa

简单请求

请求命令

curl 'https://ip:8000/v1/chat/completions'   \
 -H "Content-Type: application/json" \
 -H "Authorization: Bearer hello" \
 -d '{
    "model": "DeepSeek-R1-Distill-Qwen-32B",
    "messages": [{"role": "user", "content": "你是谁，听说能边写诗，边做数学题，那么请顺便证明1+1=2"}],
    "temperature": 0.9
 }'

请求返回

{"id":"chat-38d9d3904fe1462396781e3d17c4f632","object":"chat.completion","created":1743581032,"model":"DeepSeek-R1-Distill-Qwen-32B","choices":[{"index":0,"message":{"role":"assistant","content":"嗯，用户问我“你是谁，听说能边写诗，边做数学题，那么请顺便证明1+1=2”。首先，我需要理解用户的需求。看起来用户对我的能力有些好奇，想看看我能不能同时进行诗歌创作和数学证明。所以，我应该展示出我能够在不同领域都有能力表现。\n\n接下来，我要考虑如何回应。用户可能不仅仅是想看到诗和数学证明，而是想看看我是否有广泛的知识和应用能力。因此，我应该先写一首简短的诗，然后再进行数学证明，这样结构清晰，容易理解。\n\n在写诗的时候，我需要选择一个主题，比如自然或者日常生活，这样容易引起共鸣。比如，风、树、叶子这些元素很常见，容易描绘。然后，我要确保诗的结构流畅，有节奏感，同时传达出一种宁静或美好的感觉。\n\n关于数学证明，用户特别要求证明1+1=2，这是一个基本的数学事实，但我需要用一种简洁明了的方式来展示，可能用代数的方法或者逻辑推理。这样不仅证明了结果，还展示了思考过程。\n\n最后，我要总结一下，说明我不仅能写诗，还能进行数学证明，展示我的多功能性。这样用户就能看到我在不同领域的能力，满足他们的好奇心。\n\n在整个思考过程中，我需要确保语言自然，避免过于正式或生硬，让用户感觉到我的亲和力和专业性。同时，保持回答的结构清晰，先展示诗，再进行证明，最后总结，这样逻辑清晰，用户容易理解和接受。\n\n\n好的，我可以边写诗边做数学题。首先，我来写一首诗：\n\n**风的韵律**\n\n风在树梢游荡\n带走了所有的叹息\n叶子轻轻摇晃\n像是在跳一支古老的舞\n\n现在，我来证明1+1=2。\n\n**数学证明：**\n\n我们知道，在数学中，数字是由抽象符号代表的概念。1通常代表一个单位，另一个1同样代表一个单位。将它们相加意味着将一个单位加上另一个单位。\n\n1 + 1 = 2\n\n这是因为当你将一个对象与另一个对象结合时，总数增加了一个单位。因此，1 + 1 = 2。\n\n总结来说，我不仅能够写诗，还能够进行数学证明。希望这对你有所帮助！","tool_calls":[]},"logprobs":null,"finish_reason":"stop","stop_reason":null}],"usage":{"prompt_tokens":31,"total_tokens":608,"completion_tokens":577},"prompt_logprobs":null}

测试过程中，观察容器0里面的卡信息输出记录

基本看到单卡跑8b时 10token/s，gpu压力 94%左右

Every 5.0s: brsmi                                                                             mgt1-10-10-2-12: Thu Apr  3 07:29:08 2025

Thu Apr  3 07:29:08 2025
+------------------------------------------------------------------------------+
| BR-SMI 1.6.6         Driver Version: 1.6.5       SUPA Version: N/A           |
+----------------------------+-----------------------+-------------------------+
|   GPU                 Name |                Bus-Id |    Volatile Uncorr. ECC |
|  Temp  Perf  Pwr:Usage/Cap |          Memory-Usage |    GPU-Util  Compute M. |
|              Persistence-M |                       |                  SVI M. |
+============================+=======================+=========================+
|     0            Biren110E |      00000000:2A:00.0 |                       0 |
|    51    P0      27W / 66W |   27032MiB / 32512MiB |         94%     Default |
|                        Off |                       |                Disabled |
+----------------------------+-----------------------+-------------------------+
|     1            Biren110E |      00000000:2B:00.0 |                       0 |
|    41    P0      13W / 66W |       0MiB / 32512MiB |          0%     Default |
|                        Off |                       |                Disabled |
+----------------------------+-----------------------+-------------------------+
|     2            Biren110E |      00000000:3D:00.0 |                       0 |
|    45    P0      17W / 66W |       0MiB / 32512MiB |          0%     Default |
|                        Off |                       |                Disabled |
+----------------------------+-----------------------+-------------------------+
|     3            Biren110E |      00000000:99:00.0 |                       0 |
|    38    P0      13W / 66W |       0MiB / 32512MiB |          0%     Default |
|                        Off |                       |                Disabled |
+----------------------------+-----------------------+-------------------------+
|     4            Biren110E |      00000000:9A:00.0 |                       0 |
Every 5.0s: brsmi                                                                             mgt1-10-10-2-12: Thu Apr  3 07:29:19 2025

另一种压测脚本

单次请求

nerdctl run --rm registry.cn-shanghai.aliyuncs.com/jamesxiong/model-performance:amd64-v0.1.2  python run.py \
--api_key "asd" \
--model_name "DeepSeek-R1-Distill-Qwen-32B" \
--base_url "http://10.10.2.12:32578/v1" \
--system_prompt "" \
--history '[{"role": "user", "content": "kubernetes是什么？"}]' \
--gen_conf '{"temperature": 0.01}' \
--num_requests 1 \
--print_answer "no" \
--stream "yes"

测试结果

输出基本是12 token/s

[Index]: 0, Start Time: 2025-04-02 07:49:50, End Time: 2025-04-02 07:51:32, First Token Time: 3.29s, Elapsed Time: 101.91s, Think Tokens: 443, Answer Tokens: 862, Total Tokens: 1304, Tokens per second: 12.80

20并发测试单卡8b

nerdctl run --rm registry.cn-shanghai.aliyuncs.com/jamesxiong/model-performance:amd64-v0.1.2  python run.py \
--api_key "asd" \
--model_name "DeepSeek-R1-Distill-Qwen-32B" \
--base_url "http://10.10.2.12:32578/v1" \
--system_prompt "" \
--history '[{"role": "user", "content": "kubernetes是什么？你希望上海还是北京，你能写诗么，请写一首4言绝句"}]' \
--gen_conf '{"temperature": 0.01}' \
--num_requests 20 \
--print_answer "no" \
--stream "yes"

20并发测试结果单卡8b

并发输出为, 高低不等，6～12 token/s 左右

[Index]: 3, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:52:57, First Token Time: 0.43s, Elapsed Time: 43.00s, Think Tokens: 380, Answer Tokens: 167, Total Tokens: 546, Tokens per second: 12.70
[Index]: 1, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:53:09, First Token Time: 0.44s, Elapsed Time: 55.11s, Think Tokens: 533, Answer Tokens: 172, Total Tokens: 704, Tokens per second: 12.77
[Index]: 7, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:53:15, First Token Time: 0.39s, Elapsed Time: 61.22s, Think Tokens: 563, Answer Tokens: 217, Total Tokens: 779, Tokens per second: 12.73
[Index]: 5, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:53:17, First Token Time: 0.41s, Elapsed Time: 63.03s, Think Tokens: 554, Answer Tokens: 247, Total Tokens: 800, Tokens per second: 12.69
[Index]: 4, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:53:18, First Token Time: 0.42s, Elapsed Time: 64.28s, Think Tokens: 565, Answer Tokens: 252, Total Tokens: 816, Tokens per second: 12.69
[Index]: 2, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:53:19, First Token Time: 0.44s, Elapsed Time: 64.99s, Think Tokens: 563, Answer Tokens: 270, Total Tokens: 832, Tokens per second: 12.80
[Index]: 6, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:53:19, First Token Time: 0.39s, Elapsed Time: 65.18s, Think Tokens: 560, Answer Tokens: 266, Total Tokens: 825, Tokens per second: 12.66
[Index]: 0, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:53:24, First Token Time: 0.23s, Elapsed Time: 70.85s, Think Tokens: 687, Answer Tokens: 202, Total Tokens: 888, Tokens per second: 12.53
[Index]: 9, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:54:01, First Token Time: 43.05s, Elapsed Time: 107.38s, Think Tokens: 479, Answer Tokens: 341, Total Tokens: 819, Tokens per second: 7.63
[Index]: 12, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:54:12, First Token Time: 64.98s, Elapsed Time: 118.46s, Think Tokens: 526, Answer Tokens: 165, Total Tokens: 690, Tokens per second: 5.82
[Index]: 8, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:54:13, First Token Time: 55.16s, Elapsed Time: 119.65s, Think Tokens: 566, Answer Tokens: 262, Total Tokens: 827, Tokens per second: 6.91
[Index]: 10, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:54:15, First Token Time: 61.30s, Elapsed Time: 121.09s, Think Tokens: 538, Answer Tokens: 227, Total Tokens: 764, Tokens per second: 6.31
[Index]: 15, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:54:18, First Token Time: 65.18s, Elapsed Time: 124.47s, Think Tokens: 541, Answer Tokens: 214, Total Tokens: 754, Tokens per second: 6.06
[Index]: 13, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:54:20, First Token Time: 64.29s, Elapsed Time: 126.23s, Think Tokens: 550, Answer Tokens: 236, Total Tokens: 785, Tokens per second: 6.22
[Index]: 11, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:54:21, First Token Time: 63.08s, Elapsed Time: 127.33s, Think Tokens: 565, Answer Tokens: 262, Total Tokens: 826, Tokens per second: 6.49
[Index]: 14, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:54:29, First Token Time: 70.80s, Elapsed Time: 134.98s, Think Tokens: 552, Answer Tokens: 278, Total Tokens: 829, Tokens per second: 6.14
[Index]: 19, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:55:04, First Token Time: 119.62s, Elapsed Time: 170.55s, Think Tokens: 497, Answer Tokens: 180, Total Tokens: 676, Tokens per second: 3.96
[Index]: 17, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:55:09, First Token Time: 121.12s, Elapsed Time: 174.78s, Think Tokens: 508, Answer Tokens: 242, Total Tokens: 749, Tokens per second: 4.29
[Index]: 16, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:55:10, First Token Time: 107.41s, Elapsed Time: 176.52s, Think Tokens: 608, Answer Tokens: 298, Total Tokens: 905, Tokens per second: 5.13
[Index]: 18, Start Time: 2025-04-02 07:52:14, End Time: 2025-04-02 07:55:14, First Token Time: 118.51s, Elapsed Time: 179.85s, Think Tokens: 565, Answer Tokens: 267, Total Tokens: 831, Tokens per second: 4.62

有空再调优后测试吧

一个伪linux粉丝的blog

upgrade buildx

背景

升级步骤

尾声

openclaw

背景

引子：项目名字比代码变得还快

折腾过程

第一章：本地安装同时构建镜像

几个报错

第一个报错 frame too large

第2个报错 JavaScript Heap Out of Memory

第3个报错 no active session

no active session

第二章：安装的"灵魂拷问"

第一关：安全警告

第三关：Channel 选择

第四关：Homebrew 的执念

第四章：网关暴露的"安全悖论"

第五章：使用篇

Webui 截图

bot在自动干活中

尾声：安全的冷思考

给读者的建议：

结语：追风者的自白

参考资料：

playwright-waf-bypass

背景

步骤

先侦查

第一回合，传统方式

研究对策

第二回合：AI 出场

第三回合：伪装学大师

通关

AI infrastructure experience

背景

第一幕：销售嘴里“半天”的活儿

第二幕：机房里的“冰火两重天”与听觉轰炸

第三幕：我在机房干了啥？（AI 也没我想的那么聪明）

1. 物理装机与“灵魂”初始化

2. 网络“迷宫”搭建与玄学排查

3. 压测支持与掉卡“惊魂”

4. 自动化“外挂”

第四幕：两种“心酸”的碰撞

第五幕：当前卡住的 BOSS（Supermicro SUM vs MFT）

总结

veo3-vs-sora2

背景

对照测试

小朋友投篮

sam偷gpu

Jacky Cheung [60+] World Tour Shanghai Encore

背景

照片和视频

一点感想

KubeVirt uses custom virtual machines

背景

准备工作

kvm 虚拟化

物理机ubuntu 系统

虚拟机 ubuntu 系统

虚拟机 rockylinux 系统

嵌套虚拟化

修改 grub 设置

检查 qemu 状态

正式部署 kubevirt

yaml部署kubevirt

部署 Virtctl 工具

部署 kubevirt cdi

检查cdi 输出

检查 集群 确认有 sc

测试fedora 镜像， 补上 sc 等字段

启动一个vm1 虚拟机

定制镜像

rocky810的镜像构建

处理 rockylinux8 的 datavolume

rocky810 vm 配置

windows 10 ltsc 2021版镜像

检查集群确认有 sc

测试fedora 镜像，补上 sc 等字段