本地部署提速最怕的不是慢而是不知道先动哪层。换引擎、改量化、试剪枝有人快有人慢差别不在技巧而在动的是哪一层。为让 Codex 逐层对表我先把底座换成 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end再让 Codex 按四层判据问下来。下面照那篇总纲的顺序走先说清慢在哪再给四层结论然后把 Codex 接到 TaoToken之后一层一层核对——最后你会得到一句明确的“先动哪一层”而不是又一篇云里雾里的理论。1. 本地推理慢在哪显存带宽墙和四层判据1.1 慢的本质是“搬不动”不是“算不动”大模型是一个字一个字往外蹦的。生成第 N 个字之前模型要把自己从头到尾跑一遍。这一遍下来GPU 大部分时间不是在算而是在读把几十亿个参数从显存里搬进计算单元乘一遍写回去再读下一个字。以 H100 为例它的算力高达 990 TFLOPS显存带宽却只有 3.35 TB/s。一字一句生成时算力大量闲置数据搬运才是瓶颈。所以有个粗糙但好用的近似生成速度约等于显存带宽除以模型体积。模型体积小一半速度就差不多快一倍。沿着这个公式所有提速手段归根到底只有三条路把要读的数据压得更小量化、剪枝、低比特把数据放到更快的存储器里显存卸载、MoE 专家分置一次多算几个字批处理、投机解码、前缀复用。先记住这三条路再去看网上那些“提速 N 倍”的说法你就能立刻判断它到底切不切你的场景。1.2 四层判据就是让 Codex 拿着核对的那张地图那篇总纲把所有提速手段按“动手的深度”分成四层判据只有一句话你动的是程序、是摆法、是文件还是文件里的数。工具层换跑模型的程序模型一个字节没动。Ollama、llama.cpp、vLLM、SGLang 都在这层。调度层改模型往哪放、活怎么排。上下文长度、显存卸载、批处理、前缀复用、投机解码都在这层。架构层换一个模型文件。MoE 稀疏激活、GQA、MLA、混合注意力架构都属于这层。权重层改手里这个文件里的数值。量化、剪枝、稀疏化都在这里。Codex 不需要连你的 GPU也不读你的显存它只需要按这张地图问四个问题你的引擎是什么上下文开了多少激活参数是多少已经量化到哪一档问完之后逐层判断该先动哪。但要让它稳定干活先得保证它有一条能通的模型通道。下一节就把这件事做掉。2. 把 Codex 的 Base URL 指到 TaoTokenconfig.toml 里改两行官方额度紧、多 Key 轮换、不同供应商配置来回切这些都会打断“逐层核对”的思路。我的办法是把 Codex 的 Base URL 统一指到 TaoToken只留一个 Key后面所有核对对话都走同一条通道。2.1 拿 Key 的动作统一去官网完成打开 TaoToken注册、创建 API Key、看模型广场都在这一页完成。模型 ID 不用急着背配置之前打开模型广场把你要用的模型 ID 复制下来就行。用途地址注册、创建 Key、看模型广场、看用量https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end填进 Codex 的 Base URLhttps://taotoken.net/api官网落地页和接口地址是两回事落地页只用来拿 Key、挑模型、看用量真正填进 Codex 的 Base URL 是 https://taotoken.net/api末尾不要加 /v1也不要填成官网首页。2.2 Codex 的 config.toml 配置示例Codex 的配置文件在 ~/.codex/config.toml按下面这样改。model 那一行先别照抄打开模型广场看当前支持的模型 ID替换掉 YOUR_MODEL_ID。model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY然后导出环境变量export TAOTOKEN_API_KEYYOUR_API_KEY三个容易错的位置Base URL 是 https://taotoken.net/api不是官网落地页也不带 /v1模型 ID 必须是模型广场里真实存在的名字YOUR_API_KEY 换成从官网创建的那个 Key。2.3 第一次验证让 Codex 回一句固定文本配置好之后在 Codex 对话框里输入“只回复通道通。”如果它正常返回说明请求已经走到 TaoToken 的 API 通道一次调用完成。如果提示 401多半是 TAOTOKEN_API_KEY 没导出或者 Key 复制漏了字符。如果提示 model_not_found去模型广场核对 YOUR_MODEL_ID。这一关过了后面四层核对才有意义。3. 核对第一层引擎选对了吗让 Codex 先问三个问题工具层是所有提速手段里零风险的一层模型没有任何改动只是换了个程序跑它。但“换引擎”不是越换越快关键取决于你装不装得下。3.1 工具层真正的分水岭装得下和装不下同一张卡、同一个模型装得下和装不下时最优引擎不是同一个。权重全在显存里时调度越简单越快装不下时怎么往内存卸、什么时候搬专家才是胜负手。这就解释了为什么有人从 Ollama 换到 vLLM 反而变慢有人换到 SGLang 却快了一截。给你一个核对参照单机独占、快速试模型Ollama 和 llama.cpp 最省事多人共用一个盒子或对外提供 APIvLLM 的连续批处理是事实标准Agent、RAG 这类前缀重的场景SGLang 的前缀复用更能打模型真的装不下时才需要去看 KTransformers、FreeToken 这类把调度玩到极致的工具。它们不是“更快的引擎”是“装不下时才能体现价值的引擎”。3.2 给 Codex 的核对提示词把下面这段话直接丢给 Codex它就会按工具层判据来问问题而不是甩一堆无差别推荐把自己当成本地推理提速顾问。先不要给任何建议按顺序问清1我现在用哪个推理引擎2模型文件多大显存多大模型是否完整塞进显存3是单机独占还是多人共用。问完之后只告诉我应该优先用哪种引擎并说明为什么当前场景应该留下或换掉。不要改动任何配置文件。这里要划一条边界Codex 只负责按判据问问题、给出引擎建议真正去装引擎、更换命令、跑基准对比的是你在本地操作。它不会替你去动机器也不需要它动。4. 核对第二层上下文长度和 --n-cpu-moe 才是零成本大头调度层最容易被忽略但它一分钱不花、不伤模型还常常是收益最大的一层。它有两半一半是往哪放一半是怎么排。4.1 先砍上下文再谈卸载很多人算显存只算权重结果一开长对话就爆。因为模型每生成一个字都要回顾前面所有字为了不重复计算KV cache 会随对话长度线性膨胀。它的开销大约可以这样估算2 × 层数 × KV 头数 × 头维度 × 每元素字节数。拿 Llama-3 70B 来算80 层、8 个 KV 头、头维度 128、FP16 存储大约每 token 要吃掉 320KB。于是 4K 上下文约 1.3 GB32K 约 10 GB128K 能奔着 40 GB 去而且这是按每一条对话单独算的。所以核对第二层时第一问不是“该不该做显存卸载”而是“上下文长度真的需要那么长吗”。先砍到一个够用的值再一档一档调卸载参数。让 Codex 帮你做这件事时可以这么问我的显存是 X GB模型是 Y平时对话上下文开到 Z。请先帮我判断是 KV cache 占显存太多还是权重装不进显存如果先砍上下文建议砍到多少列出计算过程再给结论。4.2 -ngl 与 --n-cpu-moe 卸的不是一回事如果确实装不下就需要往内存卸。llama.cpp 里有两个容易混的参数-ngl 是把前 N 层整个搬进显存剩下的留 CPU--n-cpu-moe 只把 MoE 的专家部分挪去 CPU注意力、路由、共享专家都留在 GPU。同样模型同样显存选哪个更快取决于你的模型是不是 MoE。这里的关键知识是Transformer 的一层里塞了注意力和前馈网络两部分注意力小、每个字都要用前馈网络大、在 MoE 模型里大部分时间闲着。整层卸载会把注意力一起搬走而注意力恰恰是你最搬不起的部分。很多“卸载太慢”的抱怨其实是用 -ngl 硬卸本来没必要的层。Codex 在这里的价值是帮你把参数对齐到硬件告诉它模型是稠密还是 MoE、显存差多少、PCIe 是几代它给你输出一段针对性的启动参数建议。你复制到本地命令里跑把 t/s 结果贴回对话让它继续调下一档。这就是“逐层核对”里最实在的闭环。4.3 连续批处理和前缀复用你的场景能不能开多人共用一个盒子时连续批处理能让 GPU 几乎不空转每轮迭代都能进人出人vLLM 靠它把并发场景的利用率顶上去。Agent 和 RAG 场景快不快则看前缀复用同一段系统提示词和检索文档是被反复计算还是直接复用缓存。Codex 核对第二层时会问你三条是不是多人在线、每条请求是不是都带着同一段长提示词、单条对话到底多长。根据答案告诉你该开哪一组开关。5. 核对第三层看激活参数而不是总参数MoE 尤其如此架构层是收益最大、也最反直觉的一层。它和第四层的分界线只有一条文件换没换。换一个 MoE 版本、换一个原生小模型是第三层把手里这个文件做量化是第四层。5.1 两个数字的差别决定“快不快”MoE 模型里有两个数字总参数决定文件多大、占多少显存激活参数决定每生成一个字实际有多少参数下场干活这个才决定速度。一个 35B-A3B 的 MoE 模型每字只激活约 3B 参数一个 27B 稠密模型每个字都要把全部参数过一遍。前者的总参数更多速度反而可能快一个量级。所以看模型先看激活量别看总参数——这一条能帮你省下最多决策时间。核对时让 Codex 把“显存能装下多大的总参数”和“算力能喂饱多大的激活参数”分成两个问题来问。很多人拿着一颗 70B 的模型问为什么 8G 显存跑不动就是没意识到这两件事是独立的。总参数管装不装得下激活参数管跑多快。5.2 KV cache 架构也要问GQA 和 MLA 怎么选长对话场景里真正决定显存天花板的不只是权重还有 KV cache 怎么压缩。GQA 是现代开源模型的事实标准几乎免费MLA 则是把 K/V 压成低维潜向量用的时候再还原官方口径能把 KV cache 降到标准多头注意力的大约 5% 到 7%。如果你绝大多数时间都在跑长上下文第三层核对的结论往往不是“换更大的模型”而是“换一个 KV cache 更省的新架构模型”。Codex 能把上下文长度、显存预算、候选模型三个变量放在一起算然后给你几个模型 ID 去模型广场确认。真正下载、跑测试还是你在本地做。6. 核对第四层量化到 Q4_K_M 就停剪枝别指望提速第四层是动模型文件本身。这里的每一刀都是拿一点智商换体积或速度区别只在划不划算。6.1 量化档位的黄金点量化就是让每个参数少用几个位来存。4 bit 是甜点区体积省四倍质量损失通常能接受收益最大。再往下到 3 bit 开始明显掉质量到 2 bit 是普通训练后量化的悬崖除非是专门训练出来的低比特模型。有个经验法则很值钱同样显存下大模型的低精度版几乎总是打赢小模型的高精度版。Q4 的 70B 在多数测试里能打赢 FP16 的 13B。所以正确顺序是先挑显存装得下的最大参数量再把省下来的显存花在更好的量化档或更长上下文上而不是反过来追求小模型的高精度。低位宽时还要注意 imatrix。它会先跑一遍校准文本看清楚哪些参数重要量化时优先保它们。Q4 档可有可无Q3 及以下基本是必需品。6.2 剪枝买的是显存不是速度剪枝最容易被人误解成提速手段。MoE 模型剪掉一半专家每个字要激活的参数量一个没少——省的是仓库面积不是每次出工的人数。所以剪枝买的是“装得下”不是“跑得快”。想靠剪枝兑现成速度必须配合少卸几层到 CPU才能间接省出显存带宽。让 Codex 核对第四层时一句关键提示先问“当前是否已经量化到 Q4_K_M”和“显存是差一点装得下还是差得远”。如果已经 Q4 还装不下再谈剪枝或换架构如果还在 FP16直接压到 Q4 往往是最快见效的一步完全不必动刀剪枝。6.3 留给 Codex 的“停手问题”把下面这段话贴在每次动权重之前问 Codex我准备对模型做量化或剪枝。请先核对当前模型是否已经量化当前量化档位是多少如果继续压到更低 bit预计收益和风险哪个更大如果目标只是装进 X GB 显存应该先调整上下文和卸载档位还是直接换一个更小的模型文件这个“停手问题”能把第四层的冲动拉回前两层的低成本路线。Codex 的答案如果指向“先砍上下文”说明你根本还没到动模型那一步。7. 叠加顺序与三个误区从一次完整核对对话看结果那篇总纲给出的顺序建议是先榨干上两层再考虑动下面。头两层不要钱、不伤模型不满意随时撤回后两层改的是模型本身下错手就要重下一个大文件。这个顺序同样应该写进 Codex 的默认核对流程。7.1 四层叠加顺序怎么读完整跑一遍对话时Codex 应当按这个顺序逐层盘先确认工具层场景单人还是多人、装得下装不下再压调度层上下文长度、卸载档位、批处理开关然后看架构层激活参数、KV cache 架构最后才轮到权重层量化档位、剪枝。如果 Codex 一上来就建议剪枝你要警惕它是不是跳过了调度层那些问题把它拉回来继续核对上下文和卸载。7.2 三个最容易串的误区核对过程中最容易出现三个偏差。第一以为剪枝能提速实际上它省的是显存不是算力。第二以为显存塞得越满越快实际上有拐点过了拐点多塞一层显存涨了速度不动。第三以为模型支持长上下文就能同时开很多条长对话实际上 KV cache 按每条对话单独算8 条 32K 对话就能吃掉几十 GB 显存。把这些误区提前写进给 Codex 的核对要求里它就不会给你出“剪枝换速度”这种荒唐方案。7.3 回到官网看用量完成这次核对闭环等你和 Codex 跑完一轮“我该从四层中哪一层开始提速”的完整对话回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的用量页应该能看到这次核对产生的请求记录。看到记录说明通道真实工作Codex 给你的建议也建立在一次真实调用之上不是离线瞎编。接下来就是把你选中那一层改到位引擎参数、上下文长度、卸载档位、模型文件或量化档先动一个。回到 Codex 对话里把前后 t/s 贴给它让它判断下一刀该往哪里落。四层不一定都要动但每一层最好在 Codex 这边留一次“核对结论”在本地那边留一条能复现的启动命令。这样下次再有人告诉你“剪枝能提速”你就能直接打开文件看他指的是哪一层然后告诉他要不要先回来把上下文砍到 16K。