跳转至

2026

新闻｜🏆三度蝉联 EdgeX 全球 TSC！亿琪软件获国际认可，硬核赋能 AI 边缘计算

近日，Linux 基金会旗下全球领先的开源边缘计算项目 EdgeX Foundry 正式公布新一届技术指导委员会（TSC）成员名单。

亿琪软件（YIQISOFT）创始人兼 CEO Jieke Choo 凭借在边缘计算领域的持续深耕与卓越贡献，第三次成功当选 EdgeX Foundry 全球 TSC 成员！

零代码、小样本、快速商用：模型训练流水线实战验证

<200 张样本图、半小时内出结果：一块消费级显卡 Intel B580，无需写代码，流水线式炼出商用级模型

我们基于开源口罩识别数据集，仅用 149 张人工标注图片加上 20 余张未标注的背景图片（合计不到 200 张样本），在单块消费级显卡 Intel B580 上，通过一套零代码的训练流水线完成了从数据导入、模型训练到效果评估的完整流程，全程耗时不超过 30 分钟，检测精度从 51% 提升至 83%，跨过了商用级门槛。整个过程中我们先后进行了 6 轮快速迭代，其中两个反直觉的发现格外值得关注：

  • 一是样本量不足时并非模型越大越好，轻量模型（YOLOv8n / YOLO11n）反而凭借更少参数避免了过拟合、表现优于大模型；
  • 二是我们额外加入的未标注背景图片并没有浪费，反而帮助模型学会了区分"哪些是目标、哪些不是"，显著降低了误报。这次验证的意义不止于得到一个可用的口罩检测模型，更在于证明了一件对业务和管理者都有价值的事：当训练模型不再依赖海量数据、昂贵算力与专职算法工程师，而是被压缩成一条半小时可复跑的流水线时，业务的智能化就从漫长的排队等待，变成了可随时就地启动的能力。我们计划将这条被验证过的路径复制到安全帽检测、质检缺陷识别等更多真实业务任务上，并持续公开实测结果。

突破异构算力边界：Gemma-4-26B-AWQ 在 Intel XPU 上的高效部署工程实践

背景

随着 AI 技术的发展，本地算力的需求也随之增长。传统的 AI 部署生态高度依赖 NVIDIA CUDA，这使得开发者在面对 Intel Arc 系列等异构算力资源时，往往面临“有卡可用，但模型难跑”的窘境。

为了打破这一局限，我们尝试在 Intel XPU (如 Intel Arc B580) 上部署具有强大推理能力的 Gemma-4-26B 模型。Gemma-4-26B 作为一个参数量级适中但逻辑能力极强的模型，对于本地 Agent 任务具有极高的价值。然而，直接部署 26B 规模的模型对硬件提出了严苛的要求，这促使我们必须深入探索量化技术与异构加速框架的结合。

核心挑战

在部署过程中，我们遇到了三个层层递进的技术障碍：

  1. 显存墙 (Memory Wall)： Gemma-4-26B 采用 BF16 精度时，模型权重占用约 52GB 显存。对于主流消费级 XPU (如 16GB 显存的 Arc B580) 来说，这不仅是“跑不动”，而是“完全无法加载”。
  2. 算子支持 (Kernel Support)： vLLM 核心的高性能算子（如 PageAttention）最初是为 CUDA 编写的。如何在 Intel XPU 上实现等效的高性能算子替换，并确保数据在 XPU 内存与系统内存之间高效流动，是工程实现的核心难点。
  3. 精度与速度的权衡 (Accuracy vs. Throughput)： 简单的 4-bit 量化（如传统的 GPTQ）虽然能大幅降低显存，但在处理复杂逻辑推理时，模型往往会出现“智商掉线”的情况。我们需要一种能在极低精度下保留模型语义特征的技术。

解决方案：AWQ + vLLM + IPEX

我们最终确定了一套“三位一体”的技术栈：

1. 引入 AWQ (Activation-aware Weight Quantization)

不同于传统的权重感知量化，AWQ 引入了激活感知的概念。它通过观察模型在前向传播过程中的激活值分布，识别出那些“显著权重 (Salient Weights)”。通过对这些关键权重保留更高的精度，AWQ 能够在 4-bit 压缩下，实现几乎无损的推理性能。这对于 26B 这种规模的模型至关重要。

2. 借助 vLLM 的 PageAttention 机制

vLLM 通过将 KV Cache 进行分页管理，极大地提高了显存利用率，减少了碎片化。对于 Intel XPU 而言，这为我们腾出了更多的空间来存放模型权重。

3. 适配 Intel Extension for PyTorch (IPEX)

我们利用 Intel 提供的 IPEX 扩展，为 vLLM 提供了底层算子支持，使得模型能够直接调用 XPU 的矩阵运算单元 (XMX)，实现硬件级的加速。

部署工程实践

1. 准备环境 (环境配置是成功的一半)

部署 Intel XPU 驱动和环境时，建议使用官方提供的容器环境，以规避复杂的依赖冲突。

# 1. 拉取支持 Intel GPU 加速的容器镜像 (示例)
docker pull intel/intel-extension-for-pytorch:latest

# 2. 启动容器并挂载 GPU 设备
docker run -it --device=/dev/dri:/dev/dri -v /your/model/path:/models intel/intel-extension-for-pytorch:latest /bin/bash

# 3. 安装适配 vLLM 的 Intel 扩展分支
pip install vllm-intel

2. 部署命令与参数调优

部署 26B 模型时，参数设置直接决定了是否会发生 OOM (显存溢出)。我们使用了以下优化后的命令：

python -m vllm.entrypoints.openai.api_server \
    --model /models/gemma-4-26b-it-awq \
    --quantization awq \
    --device xpu \
    --max-model-len 4096 \
    --gpu-memory-utilization 0.9 \
    --enforce-eager

关键参数解析： * --max-model-len 4096: 限制上下文长度，防止 KV Cache 占用过多显存。 * --gpu-memory-utilization 0.9: 预留 10% 显存给系统和其他进程，防止驱动层面的 OOM。 * --enforce-eager: 在某些 XPU 驱动版本下，使用 Eager 模式比使用 CUDA Graph 模式更具稳定性。

3. 踩坑记录 (Troubleshooting)

在部署过程中，我们遇到了一个典型问题：模型加载成功，但推理时报 RuntimeError: XPU out of memory。

原因分析：这是因为 vLLM 默认会尝试预分配大量的 KV Cache 空间。对于 26B 模型，即使权重被量化了，剩余的显存空间对于默认配置的 KV Cache 来说依然捉襟见肘。 解决方法：通过减小 --max-model-len 或 降低 --gpu-memory-utilization 成功解决。

性能表现

通过实测，我们得到了令人惊喜的数据。

显存占用分析 图 1：AWQ 带来的显存红利。在 4-bit 模式下，显存占用从 50GB+ 骤降至 16GB 左右，完美契合 Arc B580 的规格。

推理速度测试 图 2：推理吞吐量。得益于 IPEX 的加速，Gemma-4-26B 在处理并发请求时表现出了极高的稳定性。

测试总结： - 显存占用：成功将 26B 模型的部署门槛从“专业级工作站”降级到了“消费级桌面显卡”。 - 推理速度：在单并发模式下，Token 生成速度达到了理想的实时交互水平。

落地场景：赋能本地 AI Agent

部署完成后的 Gemma-4-26B 具备了极强的逻辑推理能力，这为我们构建隐私敏感型本地 Agent 提供了可能。

  1. 隐私保护型知识库：无需将敏感文档上传至云端，直接在本地 XPU 上进行 RAG (检索增强生成) 问答。
  2. 本地自动化助手：利用模型的高逻辑能力，驱动本地脚本执行复杂的文件处理或系统操作任务。
  3. 离线智能终端：为缺乏互联网连接的工业或科研环境提供可靠的 AI 决策支持。

总结

通过本次工程实践，我们不仅成功地在 Intel XPU 上跑通了 26B 规模的大模型，更验证了“量化技术 + 异构加速”这一路径在异构算力时代的可行性。随着 Intel 软件生态的不断完善，未来的 AI 部署将不再局限于单一的 CUDA 阵营，异构算力的边界将被不断拓宽。

构建本地化 AI 生产力：基于双 Intel Arc B580 与 QwenPaw 驱动 Gemma-4-26B 的万元级整机方案

在很长一段时间里，大语言模型（LLM）的“高性能”与“本地化”似乎是一对互斥的概念。

当我们谈论像 Gemma-4-26B 这样具备深度逻辑推理能力的模型时，脑海中浮现的往往是昂贵的 NVIDIA H100 集群，或者是动辄数万元的消费级旗舰显卡。这种“算力门槛”无形中划定了一道界限：高性能的 AI 智能体似乎是属于少数人的奢侈品，而普通开发者和企业只能在云端 API 的限制与本地轻量化模型（如 4B、7B）的智力瓶颈之间艰难权衡。

然而，技术演进的魅力往往在于“边界的移动”。

随着 llama.cpp 对多硬件生态的持续兼容，以及 Intel Arc 系列显卡在 OneAPI 架构下的潜力释放，我开始思考一个问题：

如果我们将目光从昂贵的垄断生态转向更具性价比的硬件组合，是否能够通过精妙的软件工程，实现一种“智力与成本”的动态平衡？

这篇技术文章，本质上是我的一次实验记录。

我试图用一套“万元级”的整机方案，通过双 Intel Arc B580 显卡构建起足以支撑重量级模型的显存空间，并利用 QwenPaw 框架将模型的能力从“对话”转化为“行动”。我并不想仅仅展示如何搭建一台机器，我更想展示一种可能性：

通过合理的硬件选型与高效的软件栈组合，我们完全可以在本地，构建起一个既强大、又私密、且具备真实生产力的 AI 智能体中心。

这不仅是一次关于硬件的组装，更是一次关于“如何让高智力 AI 走进现实生产力”的探索。

方案｜在 Intel 双 Arc B580 上使用 vLLM v0.19.1 + FP8 驱动 Gemma-4-E4B-it 为 OpenClaw 提供本地 Token 服务实战

近年来，本地大模型部署越来越受到重视，尤其是希望保护隐私、降低延迟并实现真正自主 Agent 的用户。Gemma-4-E4B-it 作为 Google 推出的高效 4B 参数模型，在 tool calling、指令遵循和多轮对话方面表现优秀，非常适合作为 OpenClaw 这类开源 AI Agent 的后端大脑。