零成本起跑Colab 免费 GPU 部署 NVFP4 决策模型从零到第一个决策 API【免费下载链接】GEV-26B-Decide-NVFP4项目地址: https://ai.gitcode.com/hf_mirrors/autotrust/GEV-26B-Decide-NVFP4GEV-26B-Decide-NVFP4 把「跑一个 26B 级开源决策模型」的入场券从 50 GB 显存降到了 17.1 GiB原本需要 80 GB 显存级 A100/H100 才能承载的权重现在一张 24 GB 显卡就装得下。对预算敏感的个人开发者而言这等于把「第一个决策 API」的成本从租大卡变成「用免费或按需的 24 GB 卡跑一条 vLLM 命令」。这篇文章不灌鸡汤先做加法再给命令先把免费 GPU 环境的显存、磁盘、时间配额一笔一笔算清楚免费 T4 为什么装不下、L4 为什么装得下再基于仓库真实源码serve.sh、serve_decide.py、补丁给出从下载权重到curl /v1/decide返回概率的完整链路最后给免费环境一个务实的落地替代方案。一、先算账免费 GPU 的显存与磁盘配额核对NVFP4 把 50 GB 压到 17.1 GiB这个仓库是 README.md 定义的「GEV-26B-Decide 的 NVFP4 版本」基座是 Gemma-4-26B-A4B30 层 × 每层 128 个路由专家共3,840 个路由专家 MLP其 gate/up/down 投影全部量化为 NVIDIA 的 4-bit 浮点格式 NVFP4FP4 E2M1 数值16 个一组共享一个 FP8 E4M3 缩放因子每张量一个 FP32 缩放其余部分——注意力、每层稠密 MLP、router、视觉塔、lm_head、System 1 adapter、决策头与温度——保持 bf16 原样。激活侧则用 3,072 条 System 1 校准提示词标定的静态缩放见 hf_quant_config.json 与nvfp4_activation_amax.json。效果如何README 的对照表直接给出了答案指标GEV-26B-Decide (bf16)GEV-26B-Decide-NVFP4下载体积权重49.5 GB18 GBvLLM 显存占用51.1 GiB17.1 GiB−66 %GPQA DiamondSystem 1198 题43.9 %44.9 %HLE 文本多选题System 1513 题8.4 %9.7 %GPQA 与 HLE 的差异都在运行噪声范围内198 题约 ±7 个百分点这是「性能几乎无损」这句话的出处。量化配置在 config.json 的quantization_config中quant_method: modelopt、group_size: 16与nvidia/Gemma-4-26B-A4B-NVFP4的排除清单一致因此 vLLM 加载时不需要任何额外 flag。免费 T416 GB为什么装不下免费层最常见的卡是 NVIDIA T416 GB 显存实际可用约 15.3 GiB。对照上面的数字权重本身就占 17.1 GiB还没算 KV cache、激活值与 CUDA 上下文。结论非常明确——免费 T4 单卡物理装不下这个 26B 模型的全部权重这不是调参能解决的问题。这就是「先算账」的价值NVFP4 真正划出的分界线是24 GB。README 的原话是「权重 17.1 GiB整模型放得进一张 24 GB 显卡并给短上下文留出余量」。所以免费 GPU 部署的成立条件是拿到一张24 GB 的卡Colab 免费层默认给 T4部分时段与地区会分配到 L4 24 GB以 Google 实时配额为准Colab 按需计费层与部分云平台可常驻 L4/A10。内核路径也要对应查表README 原文表格GPUNVFP4 运行方式B200 / B300 / GB200SM100原生 W4A4FlashInfer TRT-LLM NVFP4 MoE 内核仓库实测于 B200RTX PRO 6000、RTX 5090、DGX SparkSM12x原生 W4A4CUTLASS / FlashInfer CUTLASS FP4 MoE 内核未实测H100 / H200 / A100SM80–90Marlin W4A16权重 FP4、激活 bf16未实测注意最后一行L4、RTX 4090、RTX 3090 这些消费级/主流 24 GB 卡都在 SM80–90 区间会走 Marlin W4A16 路径仓库未实测——显存装得下但预期性能请以实测为准。磁盘与时间配额这条反而够用磁盘18 GB 下载 解包后权重约 18 GB合计约 40 GB。Colab 免费数据盘约 78 GB、Kaggle 工作盘约 50 GB以各平台实时配额为准都放得下。时间Kaggle 惯例为每周 30 小时 GPU 配额Colab 单次会话约 12 小时。下载 18 GB 权重 首次启动加载在免费网络环境里可能要预留 30 分钟到 1 小时——这也是建议「先在本地或按需卡上验证再进免费环境重放」的原因。二、vLLM 一行命令从仓库代码到第一个决策 API服务长什么样仓库的启动入口是 serve.sh核心逻辑只有几行MODEL_DIR${MODEL_DIR:-GEV-26B-Decide-NVFP4} [ -d $MODEL_DIR ] || hf download autotrust/GEV-26B-Decide-NVFP4 --local-dir $MODEL_DIR exec python3 $MODEL_DIR/serve_decide.py --model $MODEL_DIR --served-model-name autotrust/GEV-26B-Decide-NVFP4 \ --enable-lora --max-lora-rank 32 --lora-modules jev-decision$MODEL_DIR/adapter_vllm \ --logprobs-mode processed_logprobs --max-logprobs 256 --max-model-len ${MAX_MODEL_LEN:-65536} --enable-prefix-caching \ --max-num-seqs 256 --trust-request-chat-template --limit-mm-per-prompt {image: 8} \ ${EXTRA[]} --port ${PORT:-8000}serve_decide.py 是「标准 vLLM OpenAI server 一个POST /v1/decide路由」。它把基座加载一次用 LoRA 实现双系统单引擎普通 OpenAI 端点/v1/chat/completions、/v1/completions走System 2未修改的 gemma-4-26B-A4B-itPOST /v1/decide走System 1请求指定 LoRA 模块jev-decisionadapter_vllm/ 里的 backbone LoRA 以lm_headLoRA 形式挂载的决策头r32、alpha64见 adapter_vllm/adapter_config.json单次前向传播读回每个选项的校准概率。一个必须的前置打补丁Gemma-4 的词表是262,144而 vLLM 默认对 LoRA 场景的词汇量上限是 258,048且其lm_head与输入 embedding 是 tied 的。仓库随附的 patches/vllm-gemma4-lm-head-lora.patch 干了两件事把 LoRA 词汇量上限从 258048 抬到 262144并把lm_head声明为output_embeddings的 embedding 模块让 PEFT 的 lm_head LoRA 能映射到 vLLM 的 logits-processor LoRA 包装回移上游 vllm-project/vllm#39816在激活时对别名模块去重Gemma-4 的model.layers.N与model.self_decoder.decoder_layers.N指向同一物理 LoRA 包装修复 LoRA 权重被静默重置的问题。也就是说需要一个带 Gemma-4 支持、且打了这份补丁的 vLLM 构建仓库实测于 2026 年 9 月的 vLLM 开发构建。补丁可以这样应用git clone https://github.com/vllm-project/vllm cd vllm git apply GEV-26B-Decide-NVFP4/patches/vllm-gemma4-lm-head-lora.patch pip install -e .落地三步下载 → 起服务 → 第一个决策在一张 24 GB 显卡上完整的「零到 API」就是# 1) 拉权重约 18 GB仓库文件与 serve.sh、serve_decide.py 一起打包在 HF 仓库里 hf download autotrust/GEV-26B-Decide-NVFP4 --local-dir GEV-26B-Decide-NVFP4 # 2) 起服务vLLM 监听 :800024 GB 卡建议先收紧上下文 MAX_MODEL_LEN16384 MODEL_DIRGEV-26B-Decide-NVFP4 bash GEV-26B-Decide-NVFP4/serve.sh # 3) 第一个决策请求 curl localhost:8000/v1/decide -H Content-Type: application/json -d { kind: choice, state: A bat and a ball cost $1.10 in total. The bat costs $1.00 more than the ball., question: How much does the ball cost?, options: [$0.10, $0.05, $1.00, $0.55], thinking: auto}MAX_MODEL_LEN默认 65536基座原生上下文 262,14424 GB 卡上 17.1 GiB 权重 长 KV cache 会互相挤兑所以要么如 README 建议的设到 32768要么更保守一点再配合--gpu-memory-utilization一起调。响应会直接返回options、probabilities、choice、choice_index、usage以及开启 thinking 时的thinking字段used/think_tokens/think_seconds/finished_within_budget。决策 API 的形状来自源码的字段表POST /v1/decide的请求体serve_decide.py 的DecideRequest字段取值kindnoul是/否、score0–5 打分、choice2–256 个选项state决策对象字符串、JSON 对象或文本/图片混排的列表{image: https://… 或 data:…}question针对 state 的一个问题options仅choice2–256 个字符串thinkingoff默认纯 System 1、auto自适应、on总是思考仅noul/choice支持thresholdSystem 1 置信度低于该值默认 0.8才触发 System 2think_budget思考 token 上限默认不限评测用 8,192strategy超 16 选项时tournament默认、single、permutereturn_reasoning/debug返回思考文本 / System 1、2 的分布System 1 的提示词模板是[kind] … [state] … [question] … [options] A) … [decision]:前置于bosGemma 配置见 judge_config.json 与decision_head.json的template_version: bare-v1。末 token 的 final-norm 隐藏态hidden 2,816过一个 fp32 线性头24 个槽位noul 2 个、score 6 个、choice 16 个见 adapter_vllm/decision_head.json按 30 软上限截断、除以每类温度calibration.jsonnoul 1.003 / choice 1.017 / score 0.999后 softmax——不生成任何 token。这就是「概率即答案」的工程实现。Python 客户端同样三行README 原样import requests def decide(kind, state, question, optionsNone, thinkingauto): body {kind: kind, state: state, question: question, thinking: thinking, **({options: options} if options else {})} r requests.post(http://localhost:8000/v1/decide, jsonbody).json() return dict(zip(r[options], r[probabilities])), r.get(thinking, {}).get(used) decide(noul, John was born on 29 February 1996., Was Johns 7th birthday celebrated on a 29 February?)System 2 则是标准 OpenAI 端点requests.post(http://localhost:8000/v1/chat/completions, json{ model: autotrust/GEV-26B-Decide, messages: [{role: user, content: In one sentence, what is safety stock?}], max_tokens: 200, chat_template_kwargs: {enable_thinking: False}})性能基线B200 实测其余按档折算README 的实测单 B200、vLLMSystem 1单请求中位45 ms64 并发下257 决策/秒与 transformers 引擎的最大概率差均值 0.015300 条留出样本。自适应思考不开思考时零开销开启后约每 250 thinking token 增加 1 秒。十个 Knowledge Reasoning 基准共 33,856 条请求、65.9% 触发了思考reports/adaptive_latency_summary.json中位延迟13.4 sp90 32.9 s。投机解码MTP1 bash …/serve.sh挂上 Google 的 0.9 GB 草稿模型gemma-4-26B-A4B-it-assistantSystem 2 提速约1.8–1.9×247 → 438 token/s且不改变输出分布思考类任务中位延迟降到7.7 s。免费 T4 拿不到这些数字但 24 GB 的 L4/A10/4090 上 System 1 的「单次前向传播出概率」形态决定了它依然是亚秒级——这正是决策模型与生成模型在低端卡上体验差异最大的地方不吐 token没有逐 token 生成延迟。三、免费环境跑决策模型的天花板与替代方案免费 T416 GB的能 / 不能清单免费 T4 上能做免费 T4 上不能做下载并校验 18 GB 权重、核对完整性装下 17.1 GiB 权重 15.3 GiB 可用编译带补丁的 vLLM、起服务OOM 前完成配置验证跑通满血 26B-A4B 的单请求推理用同族更小模型跑通/v1/decide协议承载 256K 上下文或长思考系统本身就不够写客户端、做评测脚本、攒部署清单获得 45 ms 级的 System 1 延迟路线 B先在免费层「跑通协议」再无缝换卡关键事实serve_decide.py 的 docstring 写得很清楚——同一份服务器代码同时服务 JEV-27B / JEV-27B-VLQwen3.8与 GEV-26B-A4BGemma-4/v1/decide的请求/响应形状在整个模型家族内完全一致。这意味着在免费 T4 上用同族更小的模型把同一套POST /v1/decide协议、三种kind、thinking: auto的触发逻辑全部跑通写出你的「决策 API 客户端」与评测循环换卡时只需把MODEL_DIR指向 NVFP4 权重、端口不变客户端一行不用改。这就是「零成本起跑」的完整含义模型权重免费adapter、决策头与校准文件 Apache-2.0基座按 Gemma 4 条款、整套服务代码在仓库里、协议跨家族统一——你花掉的只有时间。真正要花钱或自有卡的地方本地 24 GB 消费卡RTX 3090 / 4090SM80–90走 Marlin W4A16 路径未实测。按需云卡L4 24 GB、A10 24 GB 一类约 $0.15–0.4/小时Colab 按需计费层可自选 L4/A100。短租几小时完成「第一个 API」验证成本通常低于一杯咖啡。上限形态B200 级SM100原生 W4A4 内核才是 README 实测的满血状态——45 ms System 1、257 决策/秒、投机解码下思考中位 7.7 s。务实的推进顺序建议是本地 24 GB 卡或几小时的按需 L4验证 45 ms 决策闭环 → 把客户端与评测脚本写好 → 免费 T4 上重放协议验证与文档化 → 需要吞吐或长上下文时再上 B200 级。NVFP4 的真正贡献是让这条链路里「最贵的一环」从 80 GB 企业卡变成了你手边或按需可得的 24 GB 单卡。【免费下载链接】GEV-26B-Decide-NVFP4项目地址: https://ai.gitcode.com/hf_mirrors/autotrust/GEV-26B-Decide-NVFP4创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考