燧原科技邃思芯片适配：国产AI加速器运行anything-llm实测

燧原科技邃思芯片适配：国产AI加速器运行anything-llm实测

在企业对数据安全与推理效率的要求日益严苛的今天，如何在不依赖公有云服务的前提下，实现大语言模型（LLM）的高效、稳定、本地化部署，已成为智能系统落地的关键瓶颈。尤其是金融、医疗、政务等敏感行业，面对“数据不出内网”的合规红线，传统调用OpenAI或百川API的方式已难以为继。

正是在这一背景下，将开源RAG平台与国产AI加速硬件结合的技术路径，正悄然成为破局之道。我们近期完成了一项实测：在燧原科技的“邃思-220”AI推理卡上，成功部署并运行了轻量级本地LLM应用anything-llm，实现了从文档上传、向量化索引到语义问答的完整闭环。整个过程无需联网，响应迅速，且完全基于国产化软硬件栈——这不仅是一次技术验证，更标志着国产AI基础设施迈向实用化的重要一步。

---

邃思芯片作为燧原科技自研的云端AI加速器，其设计初衷并非简单复刻GPU架构，而是针对深度学习负载特性进行了深度定制。以本次使用的邃思-220为例，它采用领域专用架构（DSA），集成了多个张量处理核心（TPC），支持FP16/BF16/INT8等多种精度运算，并配备高达16GB的HBM高带宽内存，单卡可提供256 TOPS@INT8的峰值算力。这样的配置，足以支撑7B至13B参数级别的大模型进行实时推理任务。

更重要的是，它的典型功耗控制在75W以内，远低于同级别GPU动辄200W以上的能耗水平。这意味着，在边缘服务器、小型机房甚至高性能工控机中，也能轻松部署多张邃思卡，构建低延迟、高密度的私有AI推理集群。

这套系统的“灵魂”则在于其全栈软件生态。从底层驱动、运行时库到自研编译器CloudBlazer，燧原构建了一条完整的工具链。当一个PyTorch模型需要迁移到邃思平台时，首先通过ONNX导出标准化计算图，再由CloudBlazer进行图优化、算子融合和量化压缩，最终生成可在DPU（Deep learning Processing Unit）上原生执行的.dmsumodel文件。整个流程虽需额外转换步骤，但换来的是更高的执行效率与资源利用率。

比如在LLM场景下，编译器可自动识别Transformer结构中的KV Cache机制，并对其进行内存布局优化，显著减少重复计算带来的开销。这一点对于anything-llm这类频繁调用小批量推理的应用尤为重要——用户每次提问都可能触发新的上下文缓存，若处理不当极易造成性能波动。

import torch from torchvision.models import resnet50 # 模拟LLM中Encoder部分的导出过程 model = resnet50(pretrained=True).eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "resnet50.onnx", input_names=["input"], output_names=["output"], dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}}, opset_version=13 )

上述代码展示了将PyTorch模型转为ONNX格式的标准流程。虽然这里用了ResNet50作示例，但在实际适配anything-llm时，我们导出的是BGE嵌入模型和Llama-3-8B的部分子图，尤其是注意力层和前馈网络模块。这些子图经过精心剪裁后输入编译器，确保只保留必要的推理逻辑，避免冗余操作拖慢整体性能。

接下来是关键一步：

cloudblazer_compiler \ --model=llama3_8b_encoder.onnx \ --target=dpuv3-int8 \ --output_dir=./compiled_llm \ --batch_size=4 \ --enable_kv_cache_opt

这条命令启用了INT8量化与KV缓存优化，生成的模型在邃思卡上加载后，推理延迟相比CPU方案下降超过70%。而在服务端集成时，我们采用了类TVM的运行时接口来调用：

from tvm.contrib import dmlc_runtime as rt dev = rt.device("camb", 0) # camb为邃思设备代号 loaded_lib = rt.module.load_module("compiled_llm/llama3.dmsumodel") module = rt.module.GraphModule(loaded_lib["default"](dev)) input_tensor = np.random.rand(1, 2048).astype(np.float32) # 假设输入为上下文向量 module.set_input("input_ids", input_tensor) module.run() output = module.get_output(0).numpy()

这段伪代码虽简洁，却代表了软硬协同的核心思想：不再依赖CUDA生态，而是通过统一抽象层直接操控国产加速器。虽然初期适配需要开发者熟悉新的工具链，但一旦打通，便可获得更可控、更低延迟的服务能力。

---

而anything-llm正是这样一个理想的上层载体。它不是一个简单的聊天界面，而是一个集成了文档解析、嵌入生成、向量检索与对话生成的完整RAG引擎。用户只需上传PDF、Word等文档，系统便能自动将其切分为文本块，经由嵌入模型转化为向量并存入ChromaDB——这个过程完全在本地完成，无需任何外部API调用。

当用户提问时，问题同样被编码为向量，在向量库中通过HNSW算法快速检索最相关的Top-K段落，随后拼接成Prompt送入LLM生成答案。整个流程如行云流水，既保证了语义准确性，又规避了“幻觉”风险。

我们在测试中使用了一份《公司年度报告.pdf》，共约40页。系统将其按512字符窗口切分，生成约300个chunk，每个chunk通过BAAI/bge-small-en-v1.5模型编码为384维向量，耗时不到15秒。查询“去年营收增长率是多少？”时，系统准确命中包含财务摘要的段落，并由Llama-3-8B模型生成：“去年营收增长率为12.5%。” 整个端到端响应时间P95值为1.8秒，其中检索阶段不足200ms，主要耗时集中在模型推理环节。

相比之下，若在纯CPU环境下运行相同模型，仅生成阶段就可能超过5秒；而使用邃思-220后，得益于INT8量化与硬件级矩阵加速，推理速度提升达3倍以上。更重要的是，由于芯片功耗低，长时间运行不会导致散热压力剧增，非常适合7×24小时待命的企业知识库场景。

---

当然，这种软硬结合的部署也并非毫无挑战。我们在实践中总结了几点关键经验：

首先是模型量化策略的选择。虽然INT8带来了显著的速度提升，但对于某些对精度敏感的任务（如法律文书比对），可能出现语义偏差。此时可切换至FP16模式，牺牲部分性能换取更高保真度。建议根据业务需求灵活调整，必要时启用混合精度推理。

其次是内存资源的规划。邃思-220虽有16GB HBM，但同时承载嵌入模型与LLM时仍需谨慎管理并发请求。实验表明，当并发数超过4时，出现OOM（Out-of-Memory）的概率显著上升。因此，在生产环境中应设置合理的批处理窗口与队列机制，防止突发流量压垮服务。

第三是驱动与运行环境的兼容性。我们必须确保camb-driver、tvm-runtime与Python依赖库版本一致。推荐使用燧原官方提供的Docker镜像（如registry.suiyuan.ai/camb/pytorch:2.1-cuda11.8），避免因glibc、CUDA Runtime等底层差异引发运行时错误。

最后是可观测性建设。我们将Prometheus指标暴露端点集成进服务，监控DPU利用率、温度、显存占用及平均延迟。同时将日志输出接入ELK栈，便于追踪异常请求与系统瓶颈。这些措施极大提升了运维效率，尤其在多节点部署时尤为关键。

---

值得强调的是，这项实践的意义早已超出单一项目本身。它证明了国产AI芯片不仅能“跑起来”，更能“跑得好”——不仅支持标准CNN/RNN模型，也能胜任复杂的RAG流水线，涵盖向量计算、动态批处理与长序列推理等高级特性。

对于个人用户而言，这意味着你可以在一台普通台式机或NAS设备上搭建专属AI助手，安全地管理论文、笔记、合同等私人文档；对企业客户来说，则能够构建符合等保要求的知识中枢，实现内部资料的智能检索与辅助决策；而对于整个产业生态，这无疑推动了国产AI从“可用”向“好用”的跨越，促进了上下游软硬件协同发展。

展望未来，随着邃思系列对更大规模模型（如Llama-3-70B）的支持逐步完善，以及anything-llm对异构加速器的原生优化不断增强（例如通过插件机制自动识别DPU设备并加载对应runtime），此类解决方案将在政务、教育、科研等领域发挥更大价值。

某种意义上，这场国产芯片与开源AI的“双向奔赴”，正在重新定义本地智能的边界。