Token 越卷越猛，可智算的那些老瓶颈还没翻篇

bojiaman — Fri, 09 Oct 2026 14:26:12 +0800

刷到信通院那份 token 相关的智算报告的时候，我正在后台盯监控。

屏幕上面 GPU 利用率上蹿下跳，一会冲到 90 多，又猛地掉下去一大截，一堆尖峰毛刺来回蹦。说实话第一眼看报告标题还以为又是一份满是套话的行业文档，往下翻才发现聊的都是线上跑服务天天要碰的糟心事。

很多人看大模型，第一反应就是看参数多大，各个榜单跑分多少。但是做推理运维那套视角完全不一样，不看什么评测得分，眼里全是 token 吞吐、单 token 延迟、QPS 乱跳、显存占比，还有那个折磨人的 KV‑Cache 命中率。

讲实话 KV‑Cache 真算是推理场景头号吞显存大户。自回归生成每跑一轮，前面一大段上下文全部要堆在显存里。上下文窗口一开大，缓存占用直接线性往上堆。一旦显存顶不住，开始往内存 swap，那延迟直接原地爆炸。我自己踩过这个坑，当时定位半天，一开始还以为是网络出问题，排查半天才发现是 KV 缓存溢出触发置换。

线上环境根本不是实验室那种稳定满负载状态。流量一阵一阵的，突发请求涌过来，瞬间就把集群干到压力高点。这时候就会出现很迷惑的现象：GPU 算力还剩不少余量，显存带宽先顶不住了，直接撞带宽墙。很多人只盯着 TFLOPS 浮点算力，忽略带宽约束，到生产环境就踩坑。

现在市面上不少智算集群调度器，底子还是给离线训练写的逻辑。对付在线推理就有点水土不服。推理服务是 7×24 小时常驻，请求乱七八糟混在一起：有的 prompt 很短几下就完事，有的上万 token 长文档慢慢跑。

最怕就是长上下文任务死死占住 KV 缓存池，把显存资源吃走，一堆短请求在后面排队干等着，活生生资源饿死。隔离没做好，业务之间互相内卷，一个异常请求拖累整个节点，这种情况并不少见。

还有混布集群的算力碎片化问题。一堆不同型号 GPU 混在一起，显存、带宽、卡间互联速度参差不齐。如果负载均衡还傻乎乎按任务数轮询分发，不去感知每个任务实际 token 体量，结果就是一部分节点忙到冒烟，另一部分摸鱼划水，看着负载数字均衡，实际上是假均衡。

现在圈内各种花样优化：动态 KV 淘汰、滑动窗口、KV 量化、prefill 和 decode 拆开跑。但这些都不是什么万能特效药，每一个优化都有取舍。比如 KV 量化会轻微损失语义；滑动窗口直接扔掉早期 token，长文档场景就会丢信息。PPT 演示里效果看着很美，上生产各种边角 case 就冒出来，所谓 PPT 战神，大概就是这个意思。

咱们普通开发者绝大多数不会自己从头撸一套智算底座。但是做应用、写 Agent，这些底层约束绕不开。

写 Agent 的时候不少朋友图省事，文档不管长短全部一股脑塞上下文里，迷信超大窗口就是强能力。但现实是每多出来一个 token 都是实打实成本。prefill 做批量计算，decode 反复读写 KV 缓存。遇到长文档优先 RAG 分块摘要，别暴力全量往 prompt 里怼，把压力全部甩到底层，纯粹是偷懒。

平时调参别光盯着 temperature、top‑k，心里最好大概估一下单次请求 token 量级，分得清 prefill 开销和 decode 开销。

这份报告不会丢给你几段可以直接复制粘贴的代码，更多是产业视角。模型版本不停迭代更新，但硬件限制、调度缺陷、缓存带来的麻烦，不会跟着版本更新自动消失。

看完这份资料，我回去调了下自己服务，改了单实例允许的最大上下文，加了一层简单限流，防止某条超长请求直接把节点打崩。也就这点改动，算不上什么大优化。

感兴趣的可以聊聊你们线上碰到过哪些跟 KV 缓存、token 吞吐有关的离谱状况。

固件开发避坑：别让大模型幻觉给你的板子刷出砖来

bojiaman — Tue, 29 Sep 2026 14:29:51 +0800

最近圈子里面聊得很热一件事，越来越多嵌入式小伙伴直接把 HAL 层、驱动代码全部甩给大模型生成。不少新手图省事，prompt 敲完，复制 C 代码直接编译烧录，编译一过就以为万事大吉，结果板子反复随机死机，偶发看门狗复位，排查几天找不到根因。不知道有没有 Comake 社区做 BSP、固件开发的朋友踩过同款坑。

先说个自己踩过的小故事。前段时间调一块开发板外设，想快速写一段 I2C 从设备读取逻辑。Cursor 生成的代码语法看着漂漂亮亮，没有任何编译报错。下载跑起来之后，大部分时间工作正常，但高负载场景下时不时死锁。单步调试又复现不出来，属于典型偶现非必现 bug。

折腾大半天定位到问题：大模型生成代码漏掉信号量保护，中断上下文与主循环共享缓冲区产生竞态条件。没有做临界区保护，RAM 缓冲区读写发生撕裂。这种问题编译器是不会给你告警的，静态分析不打开也很难揪出来，等到硬件上面跑压力测试才会暴露。

很多人会有一个误区：能编译通过等价于固件逻辑正确。做应用层业务可以稍微放飞一点，但嵌入式固件完全是另一套逻辑。这里面要考虑寄存器时序、DMA 缓存一致性、任务优先级反转、栈溢出、RTOS 下重入问题。大模型经常会出现硬件层面的幻觉：编造不存在 SDK 接口、省略芯片勘误 workaround、对中断回调做错误假设，这些坑不会体现在编译日志里面。

尤其我们玩星宸这套 SDK 做 BSP 开发、IPU 模型部署的时候更要留心。很多小众 API、padmux 配置、时钟树初始化，公开互联网样本少，大模型训练素材不足，幻觉概率进一步拉高。你让 AI 生成 pinmux 配置，它有可能给你一套别的 SoC 的参数，编译没问题，外设直接哑火。运气差点直接端口短路，板子直接变砖。

现在行业现状，8 成以上嵌入式开发者日常都会开 AI 编码助手，但真正建立完整校验链路的团队其实不多。很多工程师慢慢变成所谓prompt jockey，调 prompt 复制粘贴，Datasheet 反倒翻得越来越少。AI 可以帮你写模板代码、简单工具函数、注释文档，但是不能替代你读手册、做压力测试、跑静态检查。

结合自己日常开发，分享一套我现在在用的工作流，没有什么高大上方案，属于踩坑踩出来的土办法：

模板类代码交给 AI，底层驱动、中断服务函数尽量少直接生成。像工具函数、工具脚本、简单的应用业务逻辑，可以丢给大模型；涉及共享资源访问、DMA 操作、ISR 中断回调，生成出来之后，逐行对照 datasheet 过一遍每一处行为。
打开静态代码检查工具，开启 MISRA 规则校验。不要只依赖编译器 warning，很多内存越界、未初始化变量，编译器直接选择无视。
AI 产出固件，不要只做单元测试，一定要上长时间压力拷机测试。很多问题只有连续跑几个小时才会浮出水面，短时间看起来一切正常。
涉及 SDK 特有逻辑，生成完代码，对照原厂 demo 做差异比对。像 Comake 这边星宸 SDK，很多隐性约束文档不会全部写全，官方示例代码才是第一手真相。

AI 工具确实拉高了开发效率，写代码的速度快一大截。但固件这东西，软件 bug 最坏情况是设备挂死，没有云端服务那样随时热更新回滚的便利。一旦量产版本藏了这类隐性 bug，后面维护的苦果全是开发自己吞。

当然我也不是否定 AI 辅助开发，日常写代码我照样天天开 AI 工具。只是心里要绷一根弦：大模型输出是草稿，不是可以直接 merge 进版本库的成品。草稿可以拿来参考，但是决策权，必须攥在开发者自己手里。

bojiaman (马君如)

Token 越卷越猛，可智算的那些老瓶颈还没翻篇

固件开发避坑：别让大模型幻觉给你的板子刷出砖来