运行本地大语言模型通常会让你陷入硬件困境。NVIDIA 用户生活在 CUDA 生态系统中。Apple 开发者选择 Metal。其他人则寄希望于他们的 GPU 支持 OpenCL，或者干脆退回到 CPU。这种碎片化使得发布桌面级 AI 应用比预想的要困难得多。TensorSharp 通过添加 Vulkan 后端正在逐步解决这个问题，为该引擎提供了一条跨越不同厂商独立 GPU 的可靠路径。

为什么 Vulkan 改变了局面

Vulkan 通常在游戏圈被讨论，但作为一个低开销、跨平台的计算 API，它对于推理同样重要。它能触及 CUDA 忽略的硬件：Intel UHD 和 Iris Xe 集成显卡、较旧的独立显卡，以及没有 NVIDIA 贴纸的廉价 Windows 笔记本电脑。对于本地推理引擎而言，这种覆盖范围就是实实在在的效能。开发者可以发布单一的二进制文件路径，其支持的机器数量将远超仅限 CUDA 的解决方案。

TensorSharp 的 Vulkan 支持最初是通过 GGML 项目推出的。虽然作者计划稍后构建原生的 Vulkan 后端，但目前的集成已经可以投入使用。使用 GGML 作为桥梁是一个正确的过渡举措。它验证了架构，并让测试人员能够立即上手硬件。随后推出的原生后端将消除抽象开销，并让这个以 C# 为核心的引擎能够更精细地控制命令缓冲区（command buffers）和内存屏障（memory barriers）。

目前的测试情况如何

验证工作已经覆盖了两种截然不同的 Windows 配置。开发者在 NVIDIA GeForce RTX 3080 Laptop GPU 和普通的 Intel UHD Graphics 上进行了测试，两者运行良好。这种跨度值得关注。在推理领域，高功耗的独立显卡和基础的集成显卡很少能如此轻易地共享一个理想的测试环境。如果你正在使用没有独立显卡的轻量级笔记本电脑，TensorSharp 现在提供了一条不依赖 NVIDIA 驱动程序的真实加速路径。

矩阵中的空白是 AMD。目前尚未测试过任何 Radeon 硬件。如果你拥有 AMD GPU，该项目需要你的反馈。在 RX 6000 或 7000 系列显卡上的社区验证，是将实验性后端转化为生产级选项的关键。如果运行出错，请提交 Issue；如果运行流畅，也请提交 Issue。任何结果都能推动项目前进。

TensorSharp 不是一个封装层

这一点值得强调。TensorSharp 并不是围绕 llama.cpp 的 C# 绑定。开发者从零开始构建了整个引擎。其 CPU 后端是纯 C# 编写的。当你不在 GPU 上运行推理时，你执行的是托管代码（managed code），而不是通过外部函数接口（FFI）将数据封送到 C++ 二进制文件中。该项目还为 CUDA、Apple 的 MLX 和 GGML 维护了专门的后端。尽管具有这种架构上的独立性，其性能仍能与 llama.cpp 相媲美，而后者仍然是大多数本地推理项目追求的基准。这种对等性是来之不易的，这意味着内存布局、内核调度（kernel dispatch）和张量操作（tensor ops）在真实负载下都能保持稳定。

模型支持涵盖了 Gemma4、DiffusionGemma 和 Qwen3.6。运行时还支持多模态工作。视觉、音频和推理流水线都通过同一个引擎运行。如果你正在原型设计一个能够读取屏幕截图并接受语音命令的桌面助手，你不需要缝合三个独立的运行时，并祈祷它们的内存占用能塞进你的机器里。

平台与 API 的灵活性

TensorSharp 可运行在 Windows、macOS 和 Linux 上。新的 Vulkan 后端可以与现有的 CUDA 和 Metal 路径完美融入该矩阵。引擎还提供了对 OpenAI 和 Ollama API 的兼容性。这种选择消除了集成摩擦。你可以将现有的客户端代码指向本地 TensorSharp 服务器，而无需重写提示词模板或解析新的响应格式。对于已经在内部运行 Ollama 或基于 OpenAI REST 接口进行开发的团队来说，切换到本地 TensorSharp 实例基本上只需更改基础 URL（base URL）即可。

卓有成效的借鉴优化

性能不仅仅取决于哪个 API 与 GPU 通信。TensorSharp 集成了几种在其他生产环境中已被证明有效的优化技术。

借鉴自 vLLM 的分页 KV 缓存（Paged KV cache）可以防止在长对话期间内存占用过度膨胀。引擎不再为每个序列预留一块连续的暂存区，而是按需分配固定大小的页面并进行映射。你可以保持更长的上下文窗口，而无需担心 RAM 使用量激增。

连续批处理（Continuous batching）同样源自 vLLM，能够提高吞吐量。引擎可以将新请求插入到活跃的批处理中，而无需等待当前批次完成。如果一个用户的提示词是 10 个 token，而另一个是 200 个，硬件能保持更高的利用率，且平均延迟会降低。

对于混合专家模型（Mixture-of-Experts），TensorSharp 实现了借鉴自 oMLX 的基于 SSD 的缓存策略。频繁访问的专家权重会预存在快速存储中，而不是与系统 RAM 争夺资源。在内存有限但拥有不错 NVMe 驱动器的机器上，这使得 MoE 架构变得可用。

量化遵循由 llama.cpp 建立的 GGUF 标准。您的 4-bit 和 5-bit 量化模型可以直接加载，无需转换步骤。

核心要点

Vulkan 支持使 TensorSharp 从一个有趣的 C# 实验转变为适用于异构硬件的实用推理方案。路线图非常明确：在 AMD 和 Intel 独立显卡上进行验证，然后通过原生 Vulkan 后端来优化实现。如果您的工作站或笔记本电脑配备了 AMD 显卡，请运行构建并分享您的结果。这种反馈循环是将实验性代码打磨成可交付产品的关键。

您可以在开发者的文章中找到发布详情。如果该项目让您免于在 CUDA 工具包之间周旋或与 macOS 版本锁定作斗争，请在仓库中点个 star。如需进行持续讨论和社区测试，Telegram 群组始终开放。