面向边缘 AI 与信创场景的确定性 LLM 推理服务 · CPU 免费体验版
InferLoop 本身是多后端推理框架：CUDA GPU / 华为昇腾 NPU / 海光 DCU / CPU 等后端均已接入。 本仓库是其中的 CPU 免费体验版——用一台纯 CPU 机器亲手验证资源治理与数值正确性； 商用加速卡路径（CUDA 已完成真机资格，昇腾 / DCU 后端已接入、真机资格待目标设备验证） 见下方「商用路径」。
在 16 GiB 内存 / 8 vCPU（对标 Jetson Orin 16GB 类设备）的嵌入式预算下常驻运行
Qwen2.5-7B-Instruct Q4_K_M（LLAMA backend：InferLoop 壳 + 共享 llama.cpp/ggml 图执行栈）。
0.5B F16 资格包（12 GiB）仍是官方正确性 / 内存治理资格线，证据见下方「关键证据」。
"不 OOM"在这里不是形容词，而是可复现、可验证的工程约束——每条结论都对应一条
docker run 命令，证据随版本归档，第三方可自行复跑。
这是 InferLoop 推理引擎的免费 CPU 体验版，目标只有一个：让你在自己的机器上、 不需要任何加速卡，亲手验证我们的资源治理与数值正确性是不是真的。
为此我们刻意把它跑在受限条件下——纯 CPU、16 GiB 内存上限（7B Q4 包络； 0.5B 资格包为 12 GiB）、只读文件系统。7B Q4 走 LLAMA backend（llama.cpp/ggml 共享栈 + 运行时 CPU 变体分发），0.5B 资格包走 AVX2/VNNI 参考算子。你在本仓库看到的速度数字， 是这个被刻意压制的仿真环境的数字， 不代表 InferLoop 商用版本的性能。商用部署运行在加速卡上、使用优化算子与更大的模型， 是完全不同的性能量级。
运行前提：本二进制要求支持 AVX2 + FMA + F16C 的 x86-64 CPU（Intel Haswell+ 约 2013 年后，AMD Excavator/Zen 约 2015 年后），不做指令集降级；详见下方「硬件要求」。
换句话说：这里验证的是"可不可信"，不是"有多快"。 想评估真实性能与对话体验， 请通过下方联系方式获取商用版本演示。
1 · 内存耗尽时，由服务自己决定，而不是被系统杀掉
主流推理框架的第一性目标是最大化吞吐；内存不足时，多数情况由操作系统的 OOM killer
裁决谁被杀——进程收到 SIGKILL，来不及留下任何现场，问题无法复现也就无法修复。
我们的取向相反：宁可明确拒绝服务，也不让系统来裁决。预算不足时，服务在加载模型前 就算清账目并主动退出，退出码明确、日志完整、现场可复现。
2 · 闭源产品，但验收过程完全公开
软件是闭源的，验证不是。每条结论都能追溯到 evidence/ 里的原始文件，其中内存与 OOM
计数由操作系统内核维护——这部分数据我们无法伪造，也是最值得你亲自核对的一环。
3 · 体验环境就是生产拓扑的等比仿真
CPU 体验版复用生产环境同一套服务拓扑与请求派发路径。一个容器可以模拟一台多加速卡节点： 你在体验版里看到的多实例负载分发，走的是生产同一条代码路径，不是为演示单独搭的架子。
4 · 纯 CPU 闭包，无任何 GPU 依赖
镜像内不含 CUDA / NVIDIA / CANN / ROCm 任何组件，依赖闭包一条命令即可自查。 这对信创与国产化替代场景尤其重要：没有境外加速卡运行时的隐式依赖， 部署面干净、可审计、可离线。
5 · 面向信创场景的设计取向
自主可控的推理运行时、无境外 GPU 运行时依赖、资源受限设备上的确定性行为—— 这些正是国产化替代场景的核心诉求。需要如实说明：本体验版证据均来自 x86_64 环境， 框架本身是多后端设计（CUDA GPU / 昇腾 NPU / 海光 DCU 等均有后端接入），但真机 调试与资格目前只完成了 NVIDIA CUDA（Jetson T806，见「商用路径」）；麒麟 / 统信等 国产操作系统、龙芯 / 飞腾 / 鲲鹏等国产 CPU、昇腾 / 海光 DCU 的真机资格在路线图上， 尚未实测，因此我们不宣称已支持。有具体信创平台适配需求请联系我们。
仓库本身不含模型权重（免费 gitee/github 托管无法承载 GB 级文件）。 先下载默认模型（Qwen2.5-7B-Instruct Q4_K_M，约 4.4 GB，Apache-2.0 许可， 脚本下载后自动校验 SHA-256）：
./scripts/download_model_qwen7b_q4.sh再构建并启动（首次 docker compose 会基于本目录 Dockerfile 构建镜像，
OpenAI 兼容接口监听 :8443）：
docker compose up --build或手动指定边缘资源预算（16 GiB / 8 vCPU，对标 Jetson Orin 16GB / 禁 swap / 只读根文件系统）：
docker run --rm -p 8443:8443 \
--memory=16g --memory-swap=16g --cpus=8 \
--pids-limit=512 --read-only --tmpfs /tmp:size=256m \
-e INFERLOOP_MODEL_PROFILE=qwen25-7b-q4km \
inferloop-edge-runtime:0.1.2-qwen7b-q4km上面这串参数本身就是"边缘预算仿真"：内存上限、CPU 配额、禁用 swap、只读根文件系统、 进程数上限——一次性复现嵌入式盒子的资源约束。
容器起来即监听 OpenAI 兼容接口（7B Q4 LLAMA 镜像，模型 ID qwen2.5-7b-instruct-q4_k_m）：
curl -X POST http://127.0.0.1:8443/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"qwen2.5-7b-instruct-q4_k_m","messages":[{"role":"user","content":"hello"}],"max_tokens":8}'体验版是 x86-64 专用二进制。0.5B 资格包的参考算子（llm_cpu_ops）直接编译为
AVX2 + FMA + F16C 指令集，不支持这些指令的 CPU 无法运行（开始推理即
illegal instruction 崩溃，无降级路径）。7B Q4 LLAMA 镜像的推理内核走
llama.cpp/ggml 的 libggml-cpu-<variant>.so 运行时 CPU 变体分发（Ollama 同款机制），
宿主机仍需满足下表指令集基线。
| 指令集 | 最低支持 |
|---|---|
| AVX2 / FMA / F16C | Intel Haswell 及之后（约 2013 年后的 Core i3/i5/i7、Xeon E3/E5 v3+） |
| AMD Excavator / Zen 及之后（约 2015 年后的 Ryzen、EPYC） |
在宿主机上快速判定（容器与宿主机共享 CPU 指令集，也可在容器内执行）：
# 期望同时看到 avx2、f16c、fma 三行
grep -o -E 'avx2|fma|f16c' /proc/cpuinfo | sort -udocker run --rm --entrypoint sh inferloop-edge-runtime:0.1.2-qwen7b-q4km -c \
'grep -o -E "avx2|fma|f16c" /proc/cpuinfo | sort -u'参考算子走 AVX2 直编是刻意取舍；ggml 侧已具备运行时变体分发。如果你需要旧 CPU 支持或覆盖更广的指令集，请联系获取定制构建。
体验版的文本链路已经接通，OpenAI 兼容聊天接口可直接验证：
| 状态 | |
|---|---|
| 服务启动、接口就绪、并发接入、内存治理 | ✅ 完整可用 |
| 推理正确性、并发扩展 | ✅ 已实测（见下） |
| 非流式文本对话 | ✅ HTTP 200，返回 assistant content |
| SSE 流式文本对话 | ✅ HTTP 200，返回 content delta 与 [DONE] |
Qwen2 模型组件现在提供 tokenizer 编码、ChatML 模板与文本还原能力，不再触发
400 unsupported_options。当前 7B Q4 LLAMA 镜像发布资格同时验证非流式响应、
SSE 流式响应与内存治理；0.5B 资格包以正确性（HF golden）与内存门为主，其证据见下方
「关键证据」，7B 首字延迟与生成速度的 Ollama 同包络对照见下方「可选对照」。
当前 7B Q4 LLAMA 镜像的并行在 llama.cpp n_threads（INFERLOOP_CPU_OP_THREADS=8）。
提升并发请求数靠增加实例数（INFERLOOP_CPU_DEVICE_COUNT）。每个实例持有一份完整
模型（7B Q4 约 4.4 GiB），因此并发数受内存约束，而不是 CPU 线程数约束。
7B Q4 默认预算 16 GiB / 1 实例（当前资格 profile）：
| 并发实例数 | 建议容器内存 | 适用场景 |
|---|---|---|
| 1（默认） | 16 GiB | 当前 7B Q4 资格 profile：LLAMA 单实例 + 内存治理 |
| 4 | 12 GiB | 0.5B F16 多实例仿真 + 负载分发（历史资格包，见「关键证据」） |
# 7B Q4 LLAMA：16 GiB 边缘盒子，单实例
docker run --rm -p 8443:8443 \
--memory=16g --memory-swap=16g --cpus=8 \
--pids-limit=512 --read-only --tmpfs /tmp:size=256m \
-e INFERLOOP_MODEL_PROFILE=qwen25-7b-q4km \
-e INFERLOOP_CPU_DEVICE_COUNT=1 \
inferloop-edge-runtime:0.1.2-qwen7b-q4km0.5B F16 资格包（官方正确性 / 内存治理资格线）· 2026-08-05 · x86_64 · cgroup v2
（0.5B 历史证据已归档，可用 build.sh --model-profile qwen25-05b-f16 复跑；
本仓库随包证据为 7B 运行 evidence/20260807-qwen25-7b-q4km-x86_64-docker/）
| 客户关心的问题 | 验证结论 |
|---|---|
| 资格运行会不会把内存吃满？ | 12 GiB 预算下峰值 1209.9 MiB，内核记录的 OOM 事件为 0 |
| 内存真的不够时会怎样？ | 主动拒绝并退出，附完整内存账目；从未被内核强杀 |
| 推理结果准不准？ | 与 HuggingFace 官方实现逐 token 比对，8/8 完全一致 |
| 省内存的做法会不会牺牲精度？ | 分块处理与整体处理结果数值等价，偏差在门限内 |
| 多实例链路是否真实工作？ | 26 个真实文本请求扇出到全部 4 个实例（8/6/5/7） |
| 加实例能换来吞吐吗？ | 能。4 实例并发聚合 106.59 token/s（效率 81%），单实例 32.94→26.65 |
| 聊天接口能否使用？ | 非流式与 SSE 均为 HTTP 200；4 路并发共 24 请求全部成功 |
| 会不会偷偷依赖 GPU？ | 依赖闭包仅系统基础库，GPU 组件扫描为空 |
| 测试覆盖够不够？ | 算子 18/18、HF 对齐 1/1、服务层 53/53、调度单元 73/73 |
展开原始数据与对应证据文件
| 维度 | 实测值 | 证据文件 |
|---|---|---|
| 正向内存（12 GiB 预算） | peak 1209.9 MiB，oom=0 oom_kill=0 |
memory.peak.after / memory.events.after |
| 反向内存门（768 MiB 预算） | 受控拒绝 freeMB=765 requiredMB=1267，exit=1 而非 137 |
oom_guard.evidence |
| 数值对齐 | 与 HF Transformers FP32 逐 token 一致 8/8 | qwen2_cpu.log |
| 分块一致性 | 分块 vs 一次性预填充，logits 最大偏差 0.0、平均 0.0（门限 ≤0.25 / ≤0.02） | qwen2_cpu.xml |
| 聊天 E2E | 非流式与 SSE 均 HTTP 200；24/24 并发请求成功 | e2e_request_response.evidence |
| 多实例请求扇出 | 4 实例全部注册；26 请求分发 8/6/5/7 | agent_dispatch_trail.log / agent_load_balance.evidence |
| 多实例内存占用 | 4 实例实际占用 3.881 GiB / 12 GiB 预算 | e2e_request_response.evidence |
| 并发吞吐扩展 | 单实例 32.94 → 4 实例聚合 106.59 token/s（效率 81%）；4/4 正确性通过 | concurrency_throughput.evidence |
| 测试套件 | 算子 18/18；HF 对齐 1/1；宿主机服务 53/53；调度单元 73/73 | cpu_ops.xml / agent_services.xml 等 |
关于负载分发证据的准确说明：上述 26 次分发均产生了真实文本推理负载，并覆盖全部实例。
这证明完整请求链路和扇出有效，但仅凭分发轨迹仍不能证明每一次选择都是当时最空闲实例；
容量打分与同分轮转由 73 项调度单元测试覆盖（agent_services.xml）。两类证据分开陈述。
所有证据绑定同一构建标识、镜像 digest 与模型 SHA-256；换任何一项都必须重新资格。 完整验证体系见 技术说明。
0.5B 资格包负责正确性 / 内存门；当前默认体验镜像就是 7B Q4 LLAMA。若你关心 「同一台机器、同一套资源上限下，7B 速度大概什么样」，可用脚本自备权重做一次 同条件复跑（权重不随仓库分发，请按模型原许可证自行下载）：
scripts/download_model_qwen7b_q4.sh # 下载 Qwen2.5-7B-Instruct Q4 权重
# 建议容器预算：16 GiB / 8 vCPU
benchmark/run_qwen7b_comparison.sh # 与 Ollama 同包络对照（可选）2026-08-07 在本机 Docker（16 GiB / 8 vCPU + --cpuset-cpus=0-15、同一份权重、同一提示词
（逐轮加 nonce 打破 KV 缓存）、强制 CPU）实测摘要：
| InferLoop | Ollama 0.11.4 | |
|---|---|---|
| 首字延迟（中位） | 约 395 ms | 约 476 ms |
| 生成速度（中位） | 约 9.75 tok/s | 约 9.87 tok/s |
首字延迟领先 ~17%，生成速度本回合基本持平（9.75 vs 9.87 tok/s，跑动间有波动）。
这得益于 ggml b9030 hybrid patch（decode 走经典
vec_dot、prefill 保留 8x8 repack，详见 性能说明 §20）。
这是 CPU 体验环境的数字，不能外推为商用加速卡性能。复跑步骤与口径见
对比方法论。
CPU 强制 + KV 缓存破除口径：对比脚本把两侧容器写死为纯 CPU——
CUDA_VISIBLE_DEVICES=/NVIDIA_VISIBLE_DEVICES=void隐藏宿主机 GPU，Ollama 另加OLLAMA_NUM_GPU=0/OLLAMA_GPU_LAYERS=0，Modelfile 与请求选项均带num_gpu: 0（InferLoop 侧n_gpu_layers: 0）。上表数字即强制 CPU 后的公平复跑；早期同 prompt 复测的 Ollama “~144 ms”是跨请求 KV 缓存命中（非真实 prefill），脚本现改为每轮不同 prompt（Run N:前缀）， 两侧均为真实解码时间。
资格测试与证据采集全部在容器内完成，宿主机无需任何工具链。以下为当前 7B Q4 LLAMA 镜像的命令（0.5B 资格包命令见 docs/faq.md Q2 与证据包）：
# 正向：16 GiB 预算下的内存治理（LLAMA 后端 + 调度单元 73/73）
docker run --rm --memory=16g --memory-swap=16g --cpus=8 \
--pids-limit=256 --read-only --tmpfs /tmp:size=128m \
-e INFERLOOP_MODEL_PROFILE=qwen25-7b-q4km \
inferloop-edge-runtime:0.1.2-qwen7b-q4km test
# 反向：7B 变体把 serve 预算压到 4 GiB，必须受控拒绝而不是被内核强杀
docker run --rm --memory=4g --memory-swap=4g --cpus=8 \
--pids-limit=256 --read-only --tmpfs /tmp:size=128m \
-e INFERLOOP_MODEL_PROFILE=qwen25-7b-q4km \
-e INFERLOOP_CPU_DEVICE_COUNT=1 \
inferloop-edge-runtime:0.1.2-qwen7b-q4km serve7B 反向门预期日志：memory admission rejected: modelMB=4466 requiredMB=11044 limitMB=4096，
容器退出码非 137、docker_oom_killed=false。反向测试比正向更值得跑：正向通过只说明
"这次没撞上上限"，反向才能证明内存治理是设计出来的，不是运气。
0.5B 资格包（镜像 inferloop-edge-runtime:0.1.2）的对应命令仍是原口径：
docker run --rm --memory=12g --memory-swap=12g --cpus=8 \
--pids-limit=256 --read-only --tmpfs /tmp:size=128m \
inferloop-edge-runtime:0.1.2 test
docker run --rm --memory=768m --memory-swap=768m --cpus=4 \
--pids-limit=256 --read-only --tmpfs /tmp:size=128m \
inferloop-edge-runtime:0.1.2 test证据自动归档到 evidence/<日期>-<模型>-<架构>-docker/，含内核原始内存文件、测试报告、
HTTP 请求响应原文与请求分发轨迹。与 llama.cpp / vLLM / TRT-LLM 的严格对比方法论
（固定条件、版本标识、公平性声明）见 对比方法论。
逐请求分发轨迹属于每请求级观测，由构建期可观测开关控制：生产构建缺省关闭 （编译期剔除，核心路径零观测负载），仅体验版打开，所以你能看到完整轨迹， 而生产部署不会为观测拖慢业务。
先承认短板，再谈长板。请务必知道本版边界：
- 单请求速度：0.5B 资格包固定 workload 实测单实例 32.94 token/s（采集于算子级 多线程上线前）；4 实例聚合 106.59 token/s，负载下单实例 26.65 token/s。这是 推理层固定工作量口径，不是 HTTP 生成口径，也不代表商用加速卡性能。7B Q4 的 HTTP 对照见上一节。
- 扩展效率的边界：本次 4 实例 / 8 vCPU 实测效率为 81%。 实例数接近可用核数时效率必然下降，我们尚未测量该拐点。
- 竞品对比：与 Ollama 的同条件对照已执行（见上）；与裸 llama.cpp / vLLM / TRT-LLM 在本 CPU 制品内仍未逐项实测，不填推测数值。
- 负载择优：已验证真实文本负载扇出到多实例；逐次 least-loaded 选择由调度单测证明， 差异负载下的集成级精确判定仍待补充。
- 长稳：24h soak 未执行，不写成已通过。
- 仿真边界：Docker 能仿真资源上限与部署闭包，仿真不了内存带宽、功耗与热降频。 CPU 容器通过 ≠ 目标真机通过——国产 NPU 等需在目标设备重新资格。
本仓库发布的是 CPU 体验镜像，不含加速卡二进制。InferLoop 推理框架为多后端设计， 各后端接入状态如实列出（接入 ≠ 真机资格完成）：
| 后端 | 状态 |
|---|---|
| CUDA GPU | 后端已接入，真机调试与资格已完成（Jetson Orin NX 16GB / Qwen3.5-4B Q8，见下） |
| 华为昇腾 NPU | 后端已接入（ENGINE_ASCEND），真机资格待目标设备验证 |
| 海光 DCU | 后端已接入（ENGINE_DCU），真机资格待目标设备验证 |
| CPU | 本仓库免费体验版（LLAMA backend + 0.5B 参考算子资格包） |
CUDA 后端真机摘要（NVIDIA Orin NX 16GB，Qwen3.5-4B，MAXN 功耗档）：
| 项 | 结果 |
|---|---|
| 服务 / Agent 资格 | 全绿通过（含多路真实对话） |
| 文本首字延迟 | 约 1.4 s |
| 客户端体感生成间隔 | 约 56 ms/token（含网络与流式传输） |
这是加速卡发布线的数字，请勿与上方 CPU 体验表混比。昇腾 / DCU 在目标设备真机资格 完成前不公布性能数字。需要 Jetson / 昇腾 / DCU 演示或完整证据包，请通过下方商务渠道联系。
inferloop-edge-runtime/
README.md / Dockerfile / docker-compose.yml
conf/ 运行配置
scripts/ 运行、证据采集、对比报告、模型下载
benchmark/ 竞品对比执行器
docs/ 技术说明、对比方法论、FAQ
systemd/ 裸机开机自启
artifacts/ 闭源二进制
models/qwen/ 模型文件（仓库不含权重；构建前由 scripts/download_model_*.sh 下载，SHA-256 约束）
evidence/ 测试报告与证据
当前 7B Q4 LLAMA 镜像约 4.85 GB（含 4.4 GB model.gguf）。0.5B 资格包镜像约
2.08 GB，其中约 943 MB 为未量化权重——保留未量化是为了让官方实现的数值对齐验证
有意义。需要瘦镜像时用 scripts/download_model.sh / scripts/download_model_qwen7b_q4.sh
运行时挂载自备权重，镜像可降到 100 MB 量级。
| 需求 | 渠道 |
|---|---|
| 商用授权 / OEM / ODM | fangw717161@gmail.com（标题注明「商务」，1 个工作日内回复） |
| 商用版本演示（加速卡 / 完整对话体验） | 同上，注明目标硬件与模型规模 |
| 信创平台适配（国产 CPU / OS / NPU） | 同上，注明目标平台 |
| 技术问题 / Bug | 提交 Issue |
| 安全问题 | 见 SECURITY.md，请勿公开披露 |
- 软件：闭源软件。个人非商业用途免费体验；商业部署需授权。
- 模型：Qwen2.5-7B / Qwen2.5-0.5B 权重为 Apache-2.0 许可，仓库不随源码分发，
请用
scripts/download_model_*.sh按官方渠道获取；构建后的镜像内包含权重。 - 适用性：CPU 体验版通过不代表 GPU / NPU 商用版已解除发布门禁。
| 里程碑 | 状态 |
|---|---|
| 文本能力（非流式 + SSE + 并发 E2E） | 已完成 |
| x86-64 可复现吞吐与内存证据 | 已完成 |
| 更大模型同条件速度对照 | 已完成（见上） |
| CUDA（Jetson Orin NX）真机资格 | 已完成（演示请联系） |
| 昇腾 NPU / 海光 DCU 真机资格 | 后端已接入，资格待目标设备验证（计划中） |
| 差异负载下的择优分发精确集成验证 | 计划中 |
| 24h 长稳 soak | 计划中 |
| 国产 OS（麒麟 / 统信）/ 国产 CPU（龙芯 / 飞腾 / 鲲鹏）目标设备资格 | 计划中 |
- 为什么"不 OOM"比"跑得快"更难证明 —— 设计取向与验收标准
- 严格对比方法论 —— 固定条件 / 版本标识 / 公平性声明
- 常见问题
- 更大模型性能说明