llama的Qwen3.5大模型单GPU高效部署与股票筛选应用|附代码教程
在AI技术快速迭代的今天，大模型的能力边界不断被突破，但隐私安全、推理成本等问题也随之凸显。对于很多企业和研究者来说，把大模型部署在本地环境，既能保证数据隐私，又能灵活控制推理流程，已经成了刚需。我们团队在近期的一个咨询项目中，就帮客户完成了Qwen3.5大模型的本地化部署，并基于此开发了一款股票筛选工具，整个方案经实际业务验证过关。
本文将从环境准备开始，一步步讲解如何在单GPU上高效运行Qwen3.5，包括llama.cpp的编译、模型下载、服务启动，以及最终的应用开发。希望能为有大模型本地化需求的读者提供一些实用参考。文章内容改编自过往客户咨询项目的技术沉淀，已通过实际业务校验。
全文脉络流程图
Qwen3.5模型概述
Qwen3.5是阿里推出的最新大模型系列，在推理、编程和多模态任务上表现抢眼。独立基准测试显示，Qwen3.5-397B-A17B在LiveCodeBench、AIME26等测试中得分很高，不少类别上已经超过了主流模型，推理吞吐量也比前代提升明显。
硬件与软件要求
要在本地流畅跑起来，得先满足硬件和软件要求。这次用的是一块NVIDIA H200 GPU（141GB显存），搭配240GB系统内存，能高效运行MXFP4_MOE版本的Qwen3.5。
作为参考，Unsloth 4-bit动态量化版本UD-Q4_K_XL大约占214GB磁盘空间，能直接放在256GB的设备上，也能在单张24GB GPU加256GB内存的环境中运行，每秒能生成25个以上token。3-bit量化版本能放在192GB内存里，8-bit版本则需要最多512GB的显存和内存总和。
一般来说，显存加内存的总和最好和量化后的模型大小差不多。如果不够，llama.cpp能把部分模型卸载到SSD，但推理速度会变慢。
软件方面，得安装最新的NVIDIA GPU驱动，以及较新的CUDA Toolkit，保证和llama.cpp、CUDA加速推理兼容。
环境搭建
要在本地运行Qwen3.5，得有一台性能强劲的GPU机器——大多数笔记本和台式机没有足够的显存或内存来跑这么大的模型，所以我们用云GPU虚拟机。
这次用的是Hyperbolic来私密运行模型，当然也可以用AutoDL、恒源云等替代平台。选Hyperbolic主要是因为当前它的GPU实例性价比不错。
先启动一个单H200 GPU的实例。
机器启动后，能看到公网IP地址和连接所需的SSH命令。
连接前，确保本地设置好了SSH，创建虚拟机时添加了公钥。实例准备好后，用带端口转发的SSH连接——这很重要，因为我们要通过8080端口在本地访问llama.cpp推理服务：
ssh -L 8080:localhost:8080 root@129.212.191.53第一次连接时，输入yes确认，然后用SSH密钥认证。
登录后，验证GPU是否正确检测：
nvidia-smi输出里应该能看到NVIDIA H200。
最后，安装下载、编译和运行llama.cpp所需的Linux软件包：
sudo apt update
sudo apt install pciutils build-essential cmake curl libcurl4-openssl-dev -y完成这步后，环境就准备好安装llama.cpp和本地运行Qwen3.5了。
安装llama.cpp
llama.cpp是开源的C/C++推理引擎，能让你用最少的设置本地运行大语言模型，支持CPU和GPU加速。先克隆llama.cpp仓库，然后用CMake配置启用CUDA的构建。我们用-DGGML_CUDA=ON启用CUDA，把CUDA架构设为90a——因为我们用的是NVIDIA H200（Hopper架构），这能让构建生成针对Hopper特性优化的GPU代码。
现在编译服务器二进制文件。llama-server是内置的REST服务器，能把llama.cpp暴露为API端点：
最后，把编译好的二进制文件复制到主文件夹，方便运行。
下载Qwen3.5模型
llama.cpp安装好之后，下一步是下载GGUF格式的Qwen3.5模型权重。这些文件很大，用Hugging Face CLI是最可靠的方法，直接把它们下载到GPU机器上。先安装Python，因为Hugging Face下载工具和认证工具是作为Python包分发的。虽然llama.cpp本身是C++写的，但Python让管理模型下载和传输容易多了。
先安装pip，然后安装Hugging Face Hub客户端和性能辅助工具。hf_transfer和hf-xet能大幅加快下载速度，这在下载数百GB的模型文件时很重要。
现在从Hugging Face下载Qwen3.5模型。这次我们只获取MXFP4_MOE变体，它针对高效的MoE推理做了优化。
下载完成后，模型文件会存储在model_storage/Qwen3.5里，随时可以加载到llama.cpp进行本地推理。
启动推理服务
现在可以用llama-server启动Qwen3.5了。这会给我们一个OpenAI兼容的API端点，能从本地工具和应用调用。我们针对单GPU设置优化了服务器，做了三件关键的事：启用--fit on，让llama.cpp自动在GPU显存和系统内存之间平衡模型，而不是在模型不能完全放进显存时失败；用--ctx-size 16384设置更大的上下文窗口，让服务器能处理更长的提示；启用--jinja并传递--chat-template-kwargs来控制聊天格式，禁用思考模式以获得更快、更直接的响应。
用以下命令运行服务器：
模型加载时，你会注意到它同时使用GPU显存和系统内存——对于大型MoE模型来说是正常的。
加载完成后，服务器可以在以下地址访问：
- 虚拟机上的
0.0.0.0:8080 - SSH端口转发后本地机器上的
http://127.0.0.1:8080
让服务器保持运行。在本地电脑上，打开一个新终端，用SSH端口转发重新连接。然后通过列出可用模型来测试服务器：
如果响应中看到Qwen3.5，说明服务器运行正常，你可以准备从OpenAI SDK和本地应用调用它了。
接口测试
现在Qwen3.5推理服务器运行起来了，需要验证它能和真实的客户端应用正常工作。llama.cpp最大的优势之一是llama-server暴露了OpenAI兼容的API——这意味着你可以使用官方OpenAI SDK而不用改变代码结构。先在本地机器上安装OpenAI Python包，然后运行一个简单的测试脚本，连接到你本地转发的端点http://127.0.0.1:8080/v1。
这里有几个重要细节：
base_url指向你本地的Qwen3.5服务器，而不是OpenAI的API。- SDK仍然需要
api_key，但llama.cpp不强制认证，所以任何占位符值都可以。 model="Qwen3.5"名称和我们启动服务器时设置的别名匹配。
如果一切配置正确，你会从模型得到快速、清晰的响应。
这确认了：Qwen3.5模型加载成功；llama.cpp服务器运行正常；SSH端口转发正常工作；端点与OpenAI风格的应用完全兼容。此时，你可以将Qwen3.5集成到任何已经支持OpenAI API格式的本地工具、智能体工作流或应用中。
股票筛选应用开发
llama.cpp包含一个内置的、ChatGPT风格的WebUI，你可以直接用浏览器与模型聊天，不需要先写任何客户端脚本。因为我们已经设置了SSH端口转发，在本地机器上打开WebUI，它的行为就像服务器运行在你笔记本上一样。默认情况下，WebUI可以在http://127.0.0.1:8080访问。页面加载说明SSH隧道工作正常，Qwen3.5服务器可以在本地访问，同时仍然在GPU虚拟机上私密运行。
进入WebUI后，粘贴提示：目标是让模型同时生成Python代码和简短的使用指南。构建一个简单的Python TUI“股票筛选训练器”，使用rich库运行，输入股票代码列表，选择模式（成长/价值/分红）和风险（低/中/高），从免费来源获取每个股票的基本公开指标，显示实时加载状态，然后渲染表格和“根据我的评分规则的前5名”部分，带有免责声明，并将结果保存到CSV。几秒钟内，Qwen3.5就会生成一个脚本和运行说明。
切换到本地终端，安装生成的应用所需的依赖：rich和yfinance。创建stock_app.py，粘贴模型生成的代码，然后运行。运行后，TUI会正常启动，提示输入股票代码、筛选模式和风险水平。例如，用三只热门股票测试：短暂的加载阶段后，工具返回完整的股票指标表格，突出显示结果，并保存到CSV文件。
这是一个很好的例子，说明Qwen3.5如何仅使用4-bit量化模型端点和简单提示，一次性生成完整的工作应用。
总结
本地运行Qwen3.5是一种强大的方式，可以在保持一切私密和完全控制的同时，访问前沿规模的模型。在本文中，模型托管在单个H200 GPU虚拟机上，使用SSH端口转发从本地机器安全访问，并通过优化的llama.cpp OpenAI兼容端点提供服务。
当然，也有一些实际限制值得注意。因为一切都依赖于活动的SSH隧道，连接需要保持稳定。如果网络中断或会话断开，你会失去对本地端口的访问，通常需要重新连接并重新启动部分工作流。
另一个常见问题是正确构建llama.cpp。如果没有为你的GPU指定正确的CUDA架构标志，编译可能耗时更长，并且可能无法完全针对硬件优化。提前设置正确的架构会在构建时间和性能上产生明显差异。
最后，虽然4-bit MXFP4_MOE量化对于高效运行大型模型非常好，但它并不总是适合智能体编程工作流。在使用Qwen Code CLI、Kilo Code CLI和OpenCode等工具测试时，模型在深度推理方面遇到困难，并且在较长的生成循环中经常失败，有时甚至触发GPU不稳定。更高精度的量化或更小的专注于推理的模型可能更适合可靠的基于智能体的编程。
