AIMA Intel PTL Qwen3.6 35B U4 Engine — Intel GPU 专用推理引擎

为什么做 Intel 专用引擎

通用推理框架要照顾大量模型、硬件和 batch 形态，固定模型在固定设备上的真实瓶颈很容易被留在“通用可用”的水平。

这个项目反过来做：先锁定 Intel PTL 目标机、Qwen3.6-35B-A3B OpenVINO U4 模型和同机 stock OpenVINO GPU 基线，再用 oracle、roofline 与逐层验证找到瓶颈。所有优化都必须同时回答两个问题：比原版快多少，模型行为有没有变化。

产品定位

AIMA Intel PTL Qwen3.6 35B U4 Engine 是一个 batch size 1、单机、单模型的 OpenVINO GPU 专用推理引擎与常驻 HTTP 服务。

• 目标硬件： Intel PTL CLS DVT2 / Core Ultra X7 358H / Intel Arc B390 GPU
• 目标内存： 64 GB 级 LPDDR
• 目标系统： Ubuntu 24.04.4 LTS
• 目标模型： Qwen3.6-35B-A3B OpenVINO U4
• 服务接口： OpenAI 风格的 Models、Completions、Chat Completions 与 Responses
• 开源协议： Apache License 2.0

这不是对其他 Intel GPU、其他模型、其他精度或 batch size 的泛化性能承诺。

性能优化做了什么

从同机原版出发，不拿不同环境做分母

性能基线是同一台机器上的未修改 stock OpenVINO GPU U4 worker。candidate 与 stock 使用隔离的 plugin、cache 和配置路径，每个 case 至少执行 8 个交错 ABBA block，再对配对中位数比值做 20,000 次 bootstrap。

最终报告的不是一组最好看的单次 ratio，而是 单侧 95% 置信下界（LCB）。每个 bucket 还包含 filler、prefill-shape 和 long-context sentinel 三类 prompt，最差的一类决定该 bucket 是否通过。

把热点收敛成短、长两条 GPU 专用路径

引擎围绕锁定模型构建 OpenVINO GPU specialization，并为短、长上下文配置不同 profile。优化工作覆盖模型专用的 OpenCL/Level Zero 执行、动态量化、LM head、算子融合、内存布局与复用；服务再把普通输入自动路由到最小可容纳 bucket，调用者不需要补齐或选择内部 shape。

把性能门和正确性门绑在一起

任何 candidate 都要对 stock worker 做 512-token greedy generation 与逐位置 teacher-forced 全词表比较。首个 token 分叉、top-1 一致率低于 0.99 或 KLD 越界，都会阻止性能结果进入正式发布。

v0.1.0 正式性能结果

正式矩阵覆盖 7 个 prompt bucket、每个 bucket 3 种 prompt，共 21 / 21 case；每个 case 生成 512 token。

用最保守的一行概括：在全部正式 bucket 和 prompt class 中，candidate 相对同机 stock OpenVINO GPU 的 prefill 加速下界不低于 1.479×，decode 加速下界不低于 1.592×。长上下文收益更明显，128K bucket 的最差下界分别达到 1.813× 和 1.890×。

完整 21-case 数据、置信区间、jitter 和内存记录见 性能与正确性报告。

正确性与稳定性门

性能提升没有以最终模型行为为代价：

• 10,752 / 10,752 个 greedy token 与 stock OpenVINO GPU 逐 token 完全一致
• teacher-forced top-1 agreement 最低为 1.0
• 最大 KLD 为 0.004836565，低于 0.005 门槛
• 7 个 long-context sentinel 在 candidate 与 stock 两端均通过检索
• 336 条 jitter 记录全部通过，decode TPOT 的最大 P95/P50 为 1.162728
• 712 次内存观测中没有 OOM 或 memory-guard 事件

这些指标衡量的是专用引擎是否保持锁定模型相对 stock OpenVINO 的行为，不是模型本身的知识能力评分。

当前发布边界：性能数字与修复版本必须分开看

已发布的 v0.1.0 通过了上面的 exact-bucket 正式矩阵，但在真实服务的 near-bucket 长 prompt 上暴露了 LM-head 物理/逻辑 buffer layout 不一致：16,380、32,758、65,519 和 131,037 token 会在最后一次 prefill 输出转换时报错。因此，不能把 v0.1.0 当作任意长度长上下文流量的稳定版本。

仓库当前的 v0.1.1 release candidate 已修复这个问题，并完成：

• 4 个 near-bucket 长 prompt 全部返回 HTTP 200
• 131,072-token 最大输入验证通过
• fast service tests 67 / 67、real HTTP smoke 18 / 18
• 16,380-token 全词表对比 top-1 8 / 8，最大 KLD 0.000092598
• 修复后的 long plugin 可以从源码 bit-for-bit 重建

但新 plugin fingerprint 还没有完成完整的 21-case output512 ABBA8 successor gate，所以 v0.1.1 candidate 不继承 v0.1.0 的 1.48× / 1.59× 性能声明。修复证据和精确边界见 near-boundary 机器可读记录。

服务能力

常驻服务支持：

• /v1/models、/v1/completions、/v1/chat/completions、/v1/responses
• JSON 与 SSE streaming
• function tools、结构化输出与 Responses 状态
• 有界 prefix-state reuse、队列、超时、取消和优雅停机
• bearer authentication、readiness、Prometheus metrics 与结构化日志
• 输入最长 131,072 token、输出最长 512 token，不静默截断

生产启动会校验锁定模型、plugin、OpenVINO/GenAI runtime 与自定义配置的精确 fingerprint。模型约 19.7 GB，不包含在仓库或 release 资产中。部署步骤见 服务文档。

作者与仓库关系

项目由 关嘉伟 / Jiawei Guan（@skyguan92） 创建并维护。

• 个人原始上游： skyguan92/AIMA-intel-plk-qwen36-35b-u4-engine
• 组织 fork 与官网主展示版本： Approaching-AI/AIMA-intel-plk-qwen36-35b-u4-engine