7月11日更新：
最新引擎目前以 Qwen3.5/Qwen3-Next 风格的 GGUF 模型为目标，能够实现从模型加载、分词、24层整数/定点数推理到流式输出的完整流程，并支持多轮对话的会话状态复用。它是 DCA 理论仓库 的工程实践伴侣，旨在将DCA的数学概念转化为可检验的代码，作为一个探索整数优先LLM推理的“实验室”，而非用于生产环境
https://github.com/superalp1985/DCA-Inference-Engine-V1
以下为正文：
最近整理并开源了两个仓库。
DCA 主仓库：
https://github.com/superalp1985/DCA-Discrete-Computer-Arithmetic
DCA 推理引擎仓库：
https://github.com/superalp1985/DCA-Inference-Engine
这篇主要介绍第二个：DCA Inference Engine。
它不是新的大模型，也不是成熟推理框架。目前更准确地说，它是一个 C++17 写的 DCA 推理实验台，用来验证一件事：
LLM 推理能不能按“离散计算机算术”的方式跑通？
也就是尽量把推理过程里的 token、权重、激活、KV cache、采样、会话状态，都放回明确的整数/定点表示里，而不是只把它看成一堆浮点矩阵运算。
1. DCA 是什么？
DCA 是 Discrete Computer Arithmetic，可以粗略理解为：
面向计算机实际运算的离散算术视角。
它不把机器整数、定点数、量化张量、有限状态这些东西临时当成“数学实数的近似”，而是先承认它们本来就是有限对象。
所以在 DCA 里，很多问题会被明确问出来：
字长是多少？
有无符号？
scale 是多少？
溢出是回绕还是饱和？
舍入规则是什么？
状态如何保存？
采样能不能复现？
同一个输入能不能 replay？
DCA 主仓库主要放理论整理、定义、范围、参考资料：
https://github.com/superalp1985/DCA-Discrete-Computer-Arithmetic
而这个推理引擎仓库，就是把 DCA 的想法落到一个具体 LLM 推理路径上：
https://github.com/superalp1985/DCA-Inference-Engine
2. 当前项目做到了什么？
DCA Inference Engine 当前目标不是性能，而是先验证路线能否跑通。
目前已经支持：
GGUF v3 metadata / tensor-info / tensor-data 读取
Qwen 风格 tokenizer
byte-level BPE
special token 处理
整数/定点推理路径
Q8.8 activation
Q16 weight / nonlinear function
整数 RMSNorm
整数 RoPE
finite-table softmax
整数 top-k / top-p / temperature sampler
token 级流式输出
多轮对话
跨轮 session state 复用
冷启动 replay 对比
合成 GGUF fixture
GitHub Actions CI
Apache-2.0 开源协议
换句话说，它已经不是一个文档概念，而是能跑测试、能生成 token、能做多轮对话的原型。
3. 为什么要这样做？
现在 LLM 推理工程已经很成熟，llama.cpp、vLLM、TensorRT-LLM、MLC 等项目都非常强。
但 DCA 关注的是另一个角度：
推理过程能不能更可检查、更可复现、更适合硬件算子逐步对齐？
例如，一个 token 生成出来，我们希望能追问：
它经过了哪些有限状态？
每一步的 scale 是多少？
哪里发生了舍入？
哪里发生了饱和？
采样的随机数状态是什么？
多轮对话复用 cache 后，是否等价于完整 replay？
很多推理引擎当然也能调试这些问题，但 DCA 的做法是把这些约束放到一开始的设计里。
先不追求快，先追求：
表示明确
路径跑通
测试可复现
状态可检查
行为可对比
4. 代码里的 DCA 表示
当前实现里，推理路径尽量使用明确的整数/定点格式：
Q8.8：中间 activation
Q16：权重、非线性函数、部分状态
int8：量化 activation
uint64_t：采样随机数状态
整数 token id：会话历史
Q16 KV cache：多轮状态
Q16 recurrent state：线性注意力状态
非线性函数也尽量避免直接用浮点数学函数，而是使用有限表：
sigmoid: Q16 lookup table
exp: Q16 lookup table
softplus: Q16 lookup table
SiLU: x * sigmoid(x)
采样也不是“随手 float softmax 一下”，而是显式做：
Q16 logits
integer top-k
Q16 temperature
finite exp table
integer top-p
uint64_t xorshift RNG
这些设计不是为了显得复杂，而是为了让每个计算边界都能被说清楚。
5. 多轮对话和 session reuse
当前已经支持多轮对话：
.\build_codex\dca_transformer.exe--model '<model.gguf>'
–chat--max-tokens 64 也支持脚本式测试： .\build_codex\dca_transformer.exe
–model ‘<model.gguf>’--chat-script '.\chat_turns.txt'
–max-tokens 16 `
–compare-session
–compare-session 会比较两种方式：
方式一：复用已有 session state
方式二：冷启动重新 replay 完整上下文
这样可以检查跨轮状态复用是否和完整 replay 保持一致。
示例测试结果：
turn 1: reused prefix tokens 0, reuse time 25.0864s, cold replay 23.7718s, output match yes
turn 2: reused prefix tokens 16, reuse time 20.2476s, cold replay 48.9397s, output match yes
第一轮没有可复用前缀，所以不占优势。第二轮开始，session reuse 已经能明显减少重复计算。
6. 为什么这可能适合国产 AI 加速卡？
这里要先说清楚：
当前项目没有做硬件优化，也没有实现昇腾/CANN 后端。
现在只是 CPU reference。
但 DCA 这种形式非常适合后续硬件适配，尤其是国产 AI 加速卡场景。
原因是它天然把推理过程拆成很多边界清楚的有限算子：
Q4_K / Q5_K / Q6_K packed-weight matvec
Q8.8 activation packing
integer RMSNorm
finite-table nonlinearities
finite softmax
Q16 KV cache update
Q16 recurrent state update
session reuse decode loop
如果后续要做昇腾 Ascend C / CANN 自定义算子，或者其他 NPU 后端，这些 CPU reference 就可以作为逐算子对齐的靶子。
硬件优化最难的地方往往不是写 kernel，而是回答：
这个 kernel 应该和谁对齐？
输入输出格式是什么？
误差边界是什么？
什么时候算一致？
DCA 的好处是，这些东西一开始就要求写清楚。
所以后续路线可以是：
先 CPU reference 跑通
再固定小输入输出 fixture
再逐算子对齐
再单层对齐
再 decode 对齐
最后做硬件 backend
这对昇腾、国产 NPU、自定义 AI Core 算子，可能是一个比较稳的实验路线。
7. 怎么运行？
Windows + MSVC 环境下：
git clone https://github.com/superalp1985/DCA-Inference-Engine.git
cd DCA-Inference-Engine
cmake -S . -B build_codex -G Ninja -DCMAKE_BUILD_TYPE=Release -DCA_BUILD_TESTS=ON
cmake --build build_codex --config Release
ctest --test-dir build_codex --output-on-failure
公开测试不依赖本地模型文件。测试会自动创建一个合成 GGUF fixture，用来验证：
GGUF parser
tokenizer
tensor loading
DCA arithmetic
streaming
session reuse
如果有本地兼容 GGUF 模型，可以设置：
$env:DCA_TEST_MODEL = ‘<path-to-model.gguf>’
.\build_codex\dca_test_e2e.exe
8. 当前限制
必须强调，当前项目还很早期。
它不是：
生产级推理框架
高性能 runtime
llama.cpp 替代品
昇腾适配版
GPU/NPU backend
完整模型生态
当前它只是：
DCA 推理路径验证原型
CPU reference
整数/定点推理实验台
可复现测试框架
代码优化和硬件优化都还没有开始。
现在的目标就是先证明：
这条路能跑通
这条路能测试
这条路能对比
这条路能被别人复现
9. 希望谁来看？
如果你关注下面这些方向，欢迎来看看：
LLM inference
GGUF
Qwen tokenizer
integer inference
fixed-point arithmetic
quantization
KV cache
session reuse
formal verification
国产 AI 加速卡
昇腾 / CANN / Ascend C
NPU 自定义算子
尤其是做硬件和算子的朋友，欢迎从“CPU reference 是否适合做硬件对齐靶场”这个角度拍砖。
项目地址：
https://github.com/superalp1985/DCA-Inference-Engine
DCA 主仓库：
https://github.com/superalp1985/DCA-Discrete-Computer-Arithmetic
目前还只是第一步，但这一步已经从文档走到了可运行代码。下一步，就是继续把测试做扎实，再谈优化和硬件适配。
