技术/工具

大模型服务上线最尴尬的时刻，是你满心欢喜部署了新模型版本，一次重启把在线请求全部打断，半小时后发现效果还不如旧版。用 HuggingFace TGI 做生产时，正确姿势不是停旧起新，而是金丝雀：先放一小部分流量到新模型，观察无误再全量。 金丝雀发布的架构怎么搭？ 起两个 TGI 实例：旧版本占主端口，新版本占另一个端口。前面放一层极薄的路由，例如 Nginx、Caddy 或任何支持按比例分流的网关，按权重把小部分流量导到新实例。关键是两个实例用不同的模型缓存目录，避免抢同一份权重文件。 放量时该盯哪几个指标？ 金丝雀不是只看延迟。至少盯三个：首 token 延迟、输出合格率（用一个小黄金集跑自动判定）、以及错误率。新模型可能更快但开始胡言乱语——只看延迟会翻车。建议每隔一段时间自动跑一批固定问题，对比新旧两版的回答质量。 发现问题怎么快速回滚？ 回滚要快。网关把权重拨回全部走旧实例只需改一行配置；新实例保留但不删，方便对比。切忌金丝雀发现问题后原地调试——把流量切走，在隔离实例上慢慢改。 TGI 有什么特有的坑？ TGI 加载大模型到显存需要时间，金丝雀切流前要确认新实例已经预热——空缓存的第一次请求会慢得离谱，让你误以为新模型崩了。等它跑完几批预热请求再放量。 流量比例该怎么逐级放？ 别从极小比例直接跳到全量。按五、二十、五十、一百这个梯度逐步放，每一档至少观察一个完整业务高峰再进下一档。很多问题只在高峰并发下才暴露——平峰看着一切正常，一到白天流量上来就崩。观察期内务必保留一键回滚的能力，真出问题时这比任何事后排查都值钱。 模型上线怎么才能不再赌一把？ 模型迭代越来越快，「每次上线都赌一把全量重启」的模式迟早出事。用 TGI 双实例加一层按比例路由，把金丝雀做成日常，上线风险就从一次赌博变成可控的小步实验。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：TGI金丝雀发布

提到本地跑大模型，多数人直接上通用框架或图形化工具。但在「多卡、长上下文、量化模型、要 OpenAI 兼容接口」这个组合下，ExLlamaV2 配 TabbyAPI 往往更省显存、启动更快。本文记录一套可用的多卡配置。 多卡启动要调哪些关键参数？ 用 TabbyAPI 起服务，核心是指定模型路径、量化档位、GPU 切分方式。多卡时指定模型，并把不同层映射到不同卡。长上下文场景重点调三个：最大序列长度按业务设，位置编码缩放配合长上下文，缓存类型选分页或低比特量化以省 KV 显存。 它凭什么比别的框架更省显存？ ExLlamaV2 的长上下文实现对 KV cache 做了量化与分页，同样的长上下文，它吃的显存常比裸跑高精度 KV 小一截。代价是吞吐略低于高端数据中心卡上的顶级框架表现——但在消费级多卡上，这点差距远不如「能装下」重要。 它和高吞吐框架怎么分工？ 经验是：对外高并发在线服务用高吞吐框架；本地开发、长文档分析、个人多卡工作站用 ExLlamaV2 加 TabbyAPI，显存优先。两套都提供 OpenAI 兼容接口，上层代码不用改，切换只换一个 base URL。 自动兜底有什么隐患？ TabbyAPI 的量化格式支持有边界，不是所有 GGUF 都能直接跑，遇到加载报错先查模型文件是否兼容。另外，多卡切分时别让某一张卡承担过多层，用显存监控观察满载分布，必要时手动调整切分比例。 什么场景别勉强用它？ 它省显存的另一面是吞吐天花板。如果你要对外同时扛几百路并发，这套本地方案会先顶不住，那是数据中心级框架的主场。它的最佳定位是：一个人或小团队，在一块到几块消费级显卡上，处理一批可以容忍几秒延迟的长文档任务。把它塞进对延迟敏感的高并发产品，等于用错了工具。另外，第一次在新卡上跑通后，记一份参数备忘——哪张卡切几层、最大上下文设多少，下次直接抄，别重新踩一遍坑。 消费级多卡到底该选哪套？ 工具没有绝对优劣，只有场景匹配。在消费级多卡上跑长上下文，ExLlamaV2 加 TabbyAPI 是被低估的一套——它不会给你最高的每秒 token 数，但常常是「唯一能把这个模型塞进显存」的那条路。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：ExLlamaV2多卡

NVIDIA 官方反复强调，GB300 NVL72 那 $0.123/百万 token、约 116 TPS/用户的数字，是用 Dynamo 加 TensorRT-LLM 打出来的，不是开箱即用的通用框架。TensorRT-LLM 的核心动作是「先编译 engine，再加载服务」——这和一条命令拉起的范式完全不同。想在自己的 Blackwell 卡上逼近官方数字，就得过 build engine 这一关。 TensorRT-LLM 为什么要先编译后运行？ 第一步，把开源模型转成中间 checkpoint，再 build 成针对你这套 GPU 拓扑优化的 engine。关键编译参数包括：最大批大小、最大序列长度、张量并行度、是否开启分页 KV cache。这些参数一旦定死，engine 就定型了，改任何一个都要重新编译。第二步，用编译好的 engine 起推理服务，这时你会发现启动快得多——因为重活已经在 build 时干完了。 哪三个参数最容易踩错？ 最大序列长度设太大会让 engine 体积暴涨、显存预留过多；按业务真实 P99 长度设，不要拍脑袋给一个远超需要的值。张量并行度要和你实际卡数一致，八卡机器别 build 成四路并行。分页 KV cache 的块大小影响显存碎片，默认值通常够用，但长上下文场景值得微调。 编译报错该怎么一步步排查？ build 阶段最常见的错是模型与算子不兼容——某些自定义算子在新架构上需要最新版 TensorRT-LLM。遇到算子不支持，先查版本，别急着改模型。另一个坑是 build 很吃磁盘和显存，build 时最好独占机器，别和别的任务抢显存。 编译耗时和版本升级要注意什么？ 要有心理准备：编译 engine 在大模型上可能要几十分钟甚至更久，这是一次性成本，但团队会因此倾向于少改配置。建议把常用配置固化成脚本和模板，build 过程放进缓存——同一套参数、同一版本工具链，不必每次重编。另外，工具链小版本升级后，旧 engine 未必能加载，升级前先在测试环境重新编译一遍验证，别在生产上原地升级，否则一次启动失败就是全站事故。 什么场景才值得用 TensorRT-LLM？ TensorRT-LLM 的性能上限确实高，但它把灵活性换成了「编译期定型」。对追求极限单 token 成本、流量波形平稳的在线服务，值得投入；对需要频繁换模型、频繁调参的研发环境，通用动态框架仍然更顺手。选哪个，看你是要稳态产能还是要迭代速度。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：TensorRTLLM部署

跑 MoE 模型的人都见过一个怪现象：模型总参数巨大，但每个 token 只激活一小部分，GPU 利用率却上不去。NVIDIA 技术博客点破了原因——高交互场景下，MoE 的执行时间被专家权重加载时间卡住，而不是被矩阵乘法本身。这就是 WideEP（Wide Expert Parallel）要解决的问题。 decode 阶段的带宽地狱 生成阶段每一步，路由器只挑出少数几个专家（比如 671B 里激活约 37B）。问题是：被选中的专家权重要从显存里读进来，才能做这一步计算。专家越大、越分散，每一步的权重读取量就越接近「把整个模型读一遍」。 换句话说，MoE 在 decode 阶段退化成了内存带宽问题：算力（FLOPS）严重闲置，时间全花在把专家权重从 HBM 搬到计算单元上。 WideEP 的解法 传统专家并行把所有专家放在一组卡上，每个 decode step 要跨这组卡集体通信。WideEP 反过来：把专家切分到 NVL72 机架内更多节点上并行，缩短单个专家的加载路径，用机架级 NVLink 的高带宽抵消跨卡成本。配合前面提到的 EP64DP3 这类配置，专家被摊得足够开，每步加载时间显著下降。 为什么 2026 年才规模化 这不是算法创新，是基础设施创新。没有 NVL72 这种把几十张卡做成一个统一域的机架、没有 HBM4 的容量、没有 Dynamo 把 prefill/decode 拆开各自配拓扑，WideEP 就是纸上谈兵。MoE 模型（DeepSeek-V4、Qwen3.8 这类）与机架级硬件是同步成熟的。 给实践者的提醒 如果你在自建 MoE 服务，监控面板里别只看 GPU 算力利用率，要看 decode 阶段的显存带宽饱和率。如果带宽先打满、算力空着，说明你需要的不是更多卡，而是更合理的专家切分拓扑。 另一个实务建议是按请求类型分流。计算密集的批量任务与带宽敏感的交互式生成，最好路由到不同拓扑的资源池，而不是挤在同一批卡上互相抢带宽。这与 Dynamo 的分离式思路一脉相承：把负载画像摸清楚，再决定怎么切专家。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：MoE 专家并行

「prefill 与 decode 应该分开跑」在论文里讨论了好几年，但真正把它做成机架级产品的是 NVIDIA Dynamo：1.0 版今年 4 月发布，6 月迭代到 v1.2.0，成为 GB300 NVL72 上拿到 0.123 美元每百万 token 这个数字的关键软件栈之一。为什么概念不新，落地却等到今年？ 混跑为什么不行 一次推理天然分两段：prefill 把整个输入一次性算完，是计算密集；decode 一个 token 一个 token 出，是内存带宽密集。把它们放在同一批 GPU 上混跑，长请求的 prefill 会堵住短请求的 decode 排队，用户感受到的就是「首 token 慢、出字也慢」。 分离式服务的思路是：prefill 一批卡、decode 一批卡，中间靠高速 NVLink 传 KV cache，各用各的最优 batch size。道理简单，难在工程。 2026 年才凑齐的三块拼图 机架内带宽：GB300/Vera Rubin NVL72 的第六代 NVLink，让 KV cache 在 prefill 池与 decode 池之间搬运不成为瓶颈。以前跨机柜 InfiniBand 搬 KV，延迟直接吃掉收益。 路由智能：Dynamo 的分离式路由器要判断请求在远端 prefill 还是本地分块 prefill，v1.2 还专门加了 prefill_load_scale 参数做负载打分。 多模态扩展：9 月文档进一步把 encode 也拆出来，形成 encode-prefill-decode 三段分离，给视觉编码与 LLM 不同资源池。 对部署团队的含义 分离式推理不再是大厂专利。如果你已经在 GB300 这类机架上做生产服务，Dynamo 类方案让你可以按「计算池」与「带宽池」分别扩容，而不是买一个通用大池子盲目堆卡。对自建团队，判断自己是否需要分离式，先看监控里 prefill 与 decode 的排队时间谁长——前者瓶颈在算力，后者在带宽，治理方向完全不同。 ...

当权重被压到 4bit、prefill 被前缀缓存复用之后，推理显存里最贵的那块往往变成了 KV cache。一个长上下文 Agent 会话，几十路并发挂着，KV cache 能吃掉远超模型权重的显存。2026 年围绕 KV 的优化已经形成一套组合拳，值得按场景对号入座。 第一招：KV 量化，从可选变默认 Qwen3 系列本地部署文档里，KV 缓存已经支持把 K、V 缓存量化到 q8_0 甚至更低，配合 f16/bf16 主权重，显存占用直接腰斩，还因为减少了数据搬运而提速。SGLang 在 Hopper 上的 FP8 后端也默认对 KV 做 FP8 处理。 工程含义：KV 量化的代价远低于权重量化——注意力对 KV 低位宽的容忍度更高，是性价比最高的一刀。 第二招：冷热分层，把不活跃的请出显存 SGLang 的 HiCache 把基数树上冷掉的节点卸到主机内存，命中热前缀时再异步取回；Qwen3.8-Flash-Next 甚至把 N-gram 嵌入整个挪到主机内存，靠异步预取隐藏延迟。长会话里真正被反复访问的往往只有最近若干轮，把冷历史卸到 DRAM 而不是 HBM，等于给昂贵显存扩容。 第三招：前缀命中即驱逐 RadixAttention 体系下，驱逐策略要和复用一起设计：被多个会话共享的公共前缀节点永不驱逐，只有叶子端的私有历史可以被回收。这比 LRU 一刀切聪明——保住了缓存收益，又限制了无限膨胀。 组合决策表 高并发短会话：先上 KV 8bit 量化，命中率靠前缀缓存。 超长上下文（10 万 token 级）：量化 + 冷热分层，配合分块 prefill。 多租户 Agent 平台：公共系统提示强制置顶保证复用，私有历史设 TTL 驱逐。 判断 权重压缩的红利在 FP4 那波吃得差不多了，下一年推理成本的下降主要来自 KV cache 的精细化管理。你的显存监控面板里，该把 KV 占用单列出来了。 ...

两年前谈量化，聊的是 GPTQ、AWQ、GPTQ-for-LLM 这些在权重训练完之后「再压一遍」的离线技巧。2026 年这条线换了赛道：NVIDIA 在 Blackwell 与 Rubin 上把 FP4 做成硬件原生格式，SGLang 直接支持 FP4/FP8/INT4 量化路径，Unsloth 在 Blackwell 上针对 NVFP4 优化，Qwen3.8-Flash-Next 发布当天社区就放出 RadixArk/NVFP4 量化版。为什么说今天要重新看量化？ 后训练量化与硬件原生是两回事 GPTQ/AWQ 时代，4bit 是「软」压缩：权重存成 4bit，计算时还要反量化回高精度，靠近似误差换显存。它的收益主要在显存容量，速度提升有限，且需要逐模型校准。 NVFP4/MXFP4 是「硬」格式：GPU 的张量核心原生支持 4bit 矩阵运算，DeepGEMM 内核直接在 4bit 上做矩阵乘，不需要反量化回传。收益从「省显存」变成「真实吞吐翻倍」——Vera Rubin NVL72 的 3.6 EFLOPS，本身就是按 NVFP4 算的。 生态正在一天内成熟 看三个信号： SGLang 在官方文档里把 FP4/FP8/INT4/AWQ/GPTQ 并列为支持的量化格式，FP4 已不是实验项。 Unsloth 与 NVIDIA 合作博客明确：Blackwell 上单卡可微调到 40B 级模型，且针对 NVFP4 精度优化。 Qwen3.8-Flash-Next 发布当天，RadixArk 就放出 NVFP4 检查点，等于「模型发布即 FP4 可用」。 这意味着量化正在从「部署时的最后一道工序」前移到「模型出厂预设」。未来的权重发布很可能默认附带 FP4 版本。 给实践者的建议 如果你的目标硬件是 Hopper（H100/H200），FP4 没有原生支持，仍以 FP8/INT8 为主；如果已经上 GB300 或未来的 Rubin，直接评估 NVFP4 检查点，并用自己的评测集（而不是厂商跑分）验证精度损失。跨硬件迁移时，量化格式要和算力一起选型，不能事后再压。 ...

在 vLLM 与 llama.cpp 之外，SGLang 是 2026 年生产环境里增长最快的开源推理引擎之一：8 月版本 0.5.17 发布，先后为 Qwen3.8（8 月 12 日）、Qwen3.8-Flash-Next（8 月 26 日）提供 day-0 支持，还把全套特性搬到了 Google TPU 上。它的核心武器是 RadixAttention——用一棵基数树自动跨请求复用 KV cache。这套机制在 Agent 时代突然变得关键，原因值得讲清楚。 一次对话里藏着多少重复 prefill 传统推理引擎把每个请求当成独立任务：用户每多发一轮，系统提示、工具描述、历史对话都要重新算一遍 prefill。一个十轮的 Agent 会话，系统提示可能被完整计算十次。 RadixAttention 的做法是：把每个请求的 token 前缀组织成基数树（radix tree），树上每个节点对应一段连续 token 的 KV cache。两个请求共享同一个前缀，就直接复用同一块 GPU 显存里的 KV，跳过重复计算。多轮对话、RAG 的固定系统提示、Agent 重复挂载的工具清单——这些天然共享前缀的场景，命中之后 prefill 成本直接归零。 2026 年的进化：从全注意力到混合架构 SGLang 今年的两次升级更说明方向。4 月支持 DeepSeek-V4 时提出 ShadowRadix：混合注意力（滑动窗口 + 压缩状态）下，用虚拟全 token 坐标系统一把 KV 与循环状态都索引进基数树。8 月支持 Qwen3.8 时又推出 Unified Radix Cache，同时管理全注意力 KV 与 Mamba/GDN 递归状态。HiCache/HiRadixTree 进一步把冷数据卸到主机内存。 ...

做内容分析、课程整理、或者把播客变成可检索文档时，第一步总是绕不开「把视频里的话变成文字」。找在线服务又慢又要传文件，其实本地两条开源命令就能搞定：yt-dlp 负责下载，faster-whisper 负责转写。这条流水线完全离线，数据不流出机器。 两步走 第一步，下载音频。yt-dlp -x --audio-format mp3 <视频地址> -o input.mp3——直接抽音频轨，比下完整视频再转码快得多。 第二步，转写。faster-whisper 是 OpenAI Whisper 的加速重实现，pip install faster-whisper 之后，用 faster-whisper input.mp3 --model large-v3 --output_format srt，它会按时间轴吐出 .srt 字幕文件，带每句话的起止时间。 有 GPU 就指定 --device cuda，一段半小时的播客几分钟就能转完。没有 GPU 用 CPU 也能跑，只是慢些，模型选 small 或 medium 平衡速度与准确率。 怎么再往上叠 拿到带时间轴的文字稿，后面能接的就多了：按时间戳切分喂给 RAG 做知识问答、让模型提取摘要和待办、或者把字幕对齐双语翻译。转写只是入口，文字稿才是原料。 判断 视频是最不结构化的信息载体，转写工具的价值就是把它变成可检索、可分析的文本。在大模型都能看视频的 2026 年，这套本地流水线依然有它的位置：便宜、离线、可复现。要批量处理一批内部会议录像，这是最省事的起点。 补两个提升准确率的细节。第一，转写时给提示词传入上下文——比如专业术语、人名，faster-whisper 支持初始提示，能显著减少同音错字。第二，中英文混读的视频，指定语言检测比让它自动猜更稳；自动猜在中英夹杂时容易整段判错语种，输出一堆乱码。拿到字幕后，再用一个大模型做标点与分段后处理，可读性会再上一个台阶。 把视频转成带时间轴的文字稿，它才从「只能看」变成「能检索、能分析」的资产；后续做知识库、做摘要、做多语翻译，都建立在这层干净的转写之上，一步先通，后面才能节节顺。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：视频字幕

提示词工程有个隐性痛点：它一直被当作文档，而不是代码。改一句系统提示、换一个 few-shot 示例，往往是「我觉得更顺了」就上线，没人知道这次改动是不是把某个边缘问题改坏了。promptfoo 要补的就是这个洞——它把提示词连同一组测试用例，变成一个能在命令行重复跑、能接进 CI 的评测脚本。 它怎么工作 写一个配置文件，列三件事：要测哪些提示词变体、一组输入样例、以及判定标准（正则包含、JSON 字段校验、或让另一个模型打分）。然后跑一行命令：npx promptfoo eval，它把每个提示词在每个样例上都跑一遍，输出一张对照表。 再用 npx promptfoo view 打开本地界面，就能并排看：旧提示词和新提示词，在这 50 个用例上分别答成什么样。 接进 CI 的价值 把这一步挂进 GitHub Actions：每次有人改提示词文件，自动跑评测，失败率上升超过阈值就拦住合并。提示词从此有了「测试套」——改坏了能立刻发现，而不是靠用户反馈。 判定标准别贪多。一开始只测硬指标：输出能不能被你的下游 JSON schema 解析、关键事实有没有出现。软的「答得好不好」交给人工抽检，否则你会陷入给模型打分的模型打分。 判断 2026 年做 AI 应用，提示词已经是生产代码的一部分。既然是代码，就该享受代码的待遇：版本控制、评审、回归测试。promptfoo 这类工具把「凭感觉改提示词」变成「带着测试改提示词」，这是从玩具走向产品的必经一步。 补充一个实践点：测试用例要从真实失败里积累。每次用户反馈答得不好，就把那个问题和期望答案补进 promptfoo 的用例库。半年下来，你的测试套就是一份「我们踩过的坑清单」，提示词改动再也不会重蹈覆辙，新成员接手也能一眼看懂这条提示词经历过什么。 提示词是生产代码，就该享受版本控制和回归测试的待遇。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：提示词测试