Qwen3.8-27B 的 KV 量化矩阵，让 Codex 跑 nvidia-smi 复查：Key 走 TaoToken

Qwen3.8-27B 在 256K 上下文下Q8 权重加 KV q8_0 的显存余量只剩约 7.8G。这个数字不是“还能跑”的安慰而是长输出、双并发、远距 recall 一拥而上时最容易踩穿的边界。想验证它不能只截一张 nvidia-smi 图更靠谱的做法是让 Codex 当复核员帮你生成 NIAH 脚本、采集双卡显存、对照 2×2 矩阵。TaoToken 在这里只承担一件事给 Codex 一条模型通道。Key 从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建Base URL 填 https://taotoken.net/api本地量化和 Ollama 推理仍按原文逻辑走。1. 256K 下那 7.8G 余量Qwen3.8-27B 的 OOM 边界到底窄在哪1.1 Q8KVq8 不是安全牌只是还没跑到长输出原文里最值得盯住的数字是 Qwen3.8-27B 在 256K 上下文、Q8 权重、KV q8_0 时只剩约 7.8G 显存余量。很多人看到“还剩 7.8G”会默认安全但这是静态加载后的余量。模型一旦开始生成KV cache 会随着 token 增长继续占用如果同时来两个长上下文请求每个请求都按 256K 预留或增长余量会被拆得很快。更麻烦的是Ollama 的显存分配和 CUDA 缓存并不总是线性。你会遇到一种情况单请求 256K 能跑NIAH 也能勉强答对但一开长输出或者两个 128K 并发nvidia-smi 里的 free 就从 7.8G 掉到 2G 以下随后直接 OOM。所以原文的 2×2 矩阵不是四组跑分而是四种不同的失败模式。1.2 2×2 矩阵要复现的四个组合这一轮复核的目标很明确把权重和 KV 量化拆开不要混在一起看。组合权重KV cache主要观察Aq4_K_Mq4_0最省显存recall 是否掉点Bq4_K_Mq8_0省权重、保 KV 精度长输出余量Cq8_0q4_0保权重、压 KV256K 是否更稳Dq8_0q8_0原文参考余量约 7.8GOOM 风险最高这里的重点是复查不是背结论。你机器上的卡型、驱动、Ollama 版本、是否开启 Flash Attention都会改变显存曲线。Codex 的价值在于把脚本、表格、报错解释串起来真正执行 nvidia-smi 和 Ollama 的仍然是你本地终端。2. 让 Codex 做复核员Key 走 TaoTokenBase URL 填 https://taotoken.net/api2.1 打开官网创建 Key并确认模型 ID先打开 TaoToken 注册并创建 API Key。Key 只用来让 Codex 对话通道能调模型不参与 Ollama 本地推理。创建完成后把 Key 放进环境变量不要硬编码进脚本export TAOTOKEN_API_KEYYOUR_API_KEY模型 ID 不要凭记忆写。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场看当时列表里可用的 ID再填到 Codex 配置里。本文里统一写成YOUR_MODEL_ID你按模型广场替换。2.2 ~/.codex/config.toml 里加一条自定义 providerCodex 的配置文件通常在~/.codex/config.toml。不要把它和 Claude Code 的 ANTHROPIC_* 环境变量混在一起Codex 走的是自己的 provider 配置。最小可用结构像这样model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY保存后回到终端确认TAOTOKEN_API_KEY已经 export再启动 Codex。Base URL 结尾不要加/v1这里填的是https://taotoken.net/api。如果你把官网地址错填进base_urlCodex 会报 404 或 model not found官网地址只用来注册、创建 Key、看模型广场和看用量。2.3 给 Codex 的复核任务书只生成命令执行留在本机Codex 不能直接替你连本地 Ollama 跑压测也不应该替你在生产机器上执行命令。正确姿势是让 Codex 生成脚本和命令你在本地终端执行再把输出贴回对话。例如可以这样发第一段任务我要复核 Qwen3.8-27B 在 256K 上下文下的 2×2 量化矩阵。 请帮我生成三样东西不要执行 1. 一个 nvidia-smi 双卡采样脚本每秒记录 used/free并输出双卡合计 2. 一个 NIAH 压测脚本调用本机 Ollama 的 /api/generate 3. 一张 CSV 表头字段包含权重量化、KV 量化、上下文长度、recall、耗时、加载后 free、长输出后 free。 脚本里模型名用环境变量 OLLAMA_MODEL不要写死。这样 Codex 产出的是可复核材料而不是替你“远程执行”。你拿到脚本后本地跑、本地看显存、本地复现 OOM再把结果贴回去让它分析。3. Ollama 侧把 KV 量化拆开OLLAMA_KV_CACHE_TYPE 的四个组合3.1 权重 q4_K_M 与 q8_0 的本地准备权重量化按原文思路来Ollama 侧通常是通过不同 tag 或 Modelfile 指定。下面命令里的qwen3.8:27b-q4_K_M只是示例位置你要换成自己实际拉取的 tagollama pull qwen3.8:27b-q4_K_M ollama pull qwen3.8:27b-q8_0 ollama list拉完后不要急着跑 256K。先确认模型确实加载到双卡并且 Ollama 版本支持你要用的 KV cache 类型。OLLAMA_KV_CACHE_TYPE控制的是 KV cache 的量化类型常见值是q4_0、q8_0旧版本 Ollama 可能不识别q4_0先看版本再动手。3.2 256K 上下文的 Modelfile 与启动命令Ollama 的num_ctx是上下文长度256K 大约写 262144。KV 量化类型要在ollama serve启动时通过环境变量指定不是ollama run里临时 export 就能生效。先停掉旧服务再带变量启动pkill ollama OLLAMA_FLASH_ATTENTION1 OLLAMA_KV_CACHE_TYPEq4_0 ollama serve另开一个终端用 Modelfile 固定上下文和 GPU 层数FROM qwen3.8:27b-q4_K_M PARAMETER num_ctx 262144 PARAMETER num_gpu 99 PARAMETER num_thread 16ollama create qwen38-27b-q4km-kvq4 -f Modelfile ollama run qwen38-27b-q4km-kvq4要测 KV q8_0就把OLLAMA_KV_CACHE_TYPEq8_0重启一遍 serve再建一个对应 Modelfile。四个组合要分别重启服务不能只改 run 时参数否则你看到的可能还是上一轮 KV 类型。3.3 NIAH 与远距 recall 的轻量压测脚本NIAH 不需要一上来就跑论文级规模。先让 Codex 生成一个最小脚本覆盖 32K、64K、128K、196K、262K 五档长度在 10%、50%、90% 深度插入一个 UUID 针让模型只回答 UUID。提示词可以这样写请生成 Python 脚本 /tmp/niah_qwen38.py - 调用本机 http://127.0.0.1:11434/api/generate - 模型从环境变量 OLLAMA_MODEL 读取 - 上下文长度列表 [32768, 65536, 131072, 196608, 262144] - 每个长度在 10%、50%、90% 位置插入 UUID - prompt 要求模型只输出 UUID - 记录 total_duration、prompt_eval_count、eval_count - 输出 /tmp/niah_result.csv。 不要执行先把代码给我。你本地运行后把 CSV 贴回 Codex。它帮你判断哪一档 recall 开始掉、哪一档耗时突然抬升。远距 recall 差不一定是权重 q4_K_M 的锅也可能是 KV q4_0 在 256K 下把远距离注意力压得太狠。4. nvidia-smi 双卡余量复查从单卡数字到并发 OOM4.1 采样命令让 Codex 生成读者本地跑原文里“双卡合计记显存”这一步建议改成持续采样。单次 nvidia-smi 只能看到瞬间值长输出和并发时很容易漏掉峰值。你可以让 Codex 生成一个简单循环while true; do nvidia-smi --query-gpuindex,memory.used,memory.free,utilization.gpu \ --formatcsv,noheader,nounits sleep 1 done双卡合计可以用 awk 快速算nvidia-smi --query-gpumemory.used,memory.free \ --formatcsv,noheader,nounits | \ awk -F, {u$1; f$2} END {printf used%.1f GiB free%.1f GiB\n, u/1024, f/1024}把“模型加载后”“256K 首 token 后”“长输出 8K 后”“双并发 128K 后”四个时间点的 free 都记下来。只记一个总数你无法判断是权重占走了还是 KV 在长输出里继续膨胀。4.2 2×2 矩阵显存与速度记录表下面这张表可以直接让 Codex 生成 CSV 表头你本地填。原文给出的 Q8KVq8 约 7.8G 余量放在 D 组作参考其他数字以你机器的实测为准不要照抄别人的卡型。组合权重KV加载后 free256K 首 token 后 free长输出 8K 后 freeNIAH 256K recall速度备注Aq4_K_Mq4_0待填待填待填待填待填最省显存Bq4_K_Mq8_0待填待填待填待填待填KV 精度更高Cq8_0q4_0待填待填待填待填待填权重精度更高Dq8_0q8_0原文参考约 7.8G待填待填待填待填长输出/并发易 OOM速度不要只记 tok/s。把 prompt eval 速度和生成速度分开长上下文下 prompt 处理时间可能远大于生成时间。你如果只记一个总耗时会误以为 KV q4_0 一定更快实际上 KV 量化主要影响显存速度差异要看后端 kernel 和 Flash Attention 是否开启。4.3 长输出和双并发下 7.8G 余量怎么被吃完验证 7.8G 余量是否安全至少做两个动作。第一固定 256K 上下文让模型连续输出 8K token观察 free 是否持续下降。第二开两个并发请求每个 128K 上下文同时问 NIAH。并发脚本也可以让 Codex 生成你本地执行请生成 /tmp/concurrent_niah.py - 用 ThreadPoolExecutor 发两个请求 - 每个请求上下文 131072 - 模型从 OLLAMA_MODEL 读取 - 请求间隔 0.5 秒 - 捕获 Ollama 返回的 error 字段 - 输出两个请求的耗时和是否 OOM。如果 D 组单请求 256K 还有约 7.8G但双并发 128K 直接 CUDA out of memory那就说明余量不是按“总上下文”线性切的。Ollama 在并发时可能各自保留 KV 空间加上 CUDA 缓存碎片7.8G 很快见底。这时候优先降 KV 到 q4_0再考虑降 num_ctx。5. 错填、OOM 与 KV 类型不生效这一轮最容易撞上的三类报错5.1 Codex 侧 401、404 与 model not foundCodex 报 401先看TAOTOKEN_API_KEY是否在当前终端 export再看~/.codex/config.toml里的env_key是否写成同一个名字。报 404最常见的是base_url写成了官网地址或者多加了/v1。正确值只有一个https://taotoken.net/api。报 model not found回模型广场确认YOUR_MODEL_ID不要自己加日期后缀。5.2 Ollama 侧 KV cache type 不识别与显存碎片Ollama 报 unknown KV cache type通常是版本太旧或者环境变量没有传给ollama serve。用ollama --version确认版本重启服务后再跑ollama run。另一个坑是旧进程没被杀掉你以为换了OLLAMA_KV_CACHE_TYPE实际还是旧服务在响应。OOM 时不要只降num_ctx可以先换 KV q4_0再把并发降到 1最后才动权重 tag。5.3 NIAH recall 掉点的排查顺序recall 掉点先看 KV 量化再看权重量化最后看上下文长度。q4_0 在 128K 以内可能看不出差异但到 256K 远距 needle 时容易掉。你可以让 Codex 把 CSV 按长度和深度分组找出是 90% 深度先掉还是整体都掉。如果是整体掉检查 prompt 是否让模型只输出 UUID如果是 90% 深度掉优先怀疑 KV q4_0 的远距压缩。6. 跑完复核后用同一把 Key 对一次用量6.1 模型对话里发一条最小请求脚本和矩阵跑完不要急着拆环境。先在 TaoToken 模型对话 里用同一把 Key 发一条最小消息确认模型 ID、Base URL、Key 三件套没有填错。模型对话走的是云端通道本地 Ollama 的显存数据不会在这里出现但 Codex 这一轮生成脚本、解释输出消耗的 Token 会记在对应 Key 上。6.2 回控制台看这次 Codex 复核消耗如果你准备长期用 Codex 做这类本地压测复核可以打开 Coding Plan 看套餐是否够用Key 的管理和新建在 控制台 API Keys。下次再跑 2×2 矩阵先让 Codex 生成采样脚本本地执行 nvidia-smi 和 NIAH把 free 数值贴回对话让它判断该降 KV 到 q4_0还是该把 256K 拆成两段 128K。