标签: 大模型推理
权重不再搬家：MRAM 存算融合能否改写大模型推理的带宽瓶颈
寒序科技公布的 uHBM 与 uLPU 路线，把 MRAM、片内高带宽访问和矩阵—向量计算放在同一套推理架构中，提出首代 uHBM 片内读取带宽 24 TB/s、面向 4B 多模态模型超过 2000 token/s 的目标。数字很醒目，真正值得讨论的却是其技术逻辑：大模型解码阶段为何受权重搬运约束，非易失性 MRAM 如何承担权重驻留，存内或近存计算能节省哪些数据流，又会引入怎样的容量、精度、良率、散热和软件适配问题。现阶段公开数据主要来自企业披露，尚不足以证明其可替代 HBM 与 GPU，但它提供了一条值得验证的专用推理路线。
按下回车之后：一条大模型请求如何穿过上下文、显存与推理引擎
聊天窗口给人的感觉很简单：输入一句话，稍作等待，答案便逐字出现。服务器内部处理的对象却远不止这句话。系统提示词、工具定义、历史对话、长期记忆、检索资料和本轮输入会先被拼成一份临时文档，经过安全检查和分词后进入共享推理集群。模型随后依次完成预填充与解码，推理引擎还要处理连续批调度、KV Cache 分配、前缀缓存与流式输出。理解这条链路，有助于解释几个常见现象：同一个模型为什么在不同产品中表现不同，长对话为什么越来越慢，工具调用为什么明显增加延迟，以及企业部署大模型时为什么不能只关注模型参数量。
大模型服务崩一次为什么要几分钟才能回来：NVIDIA“影子引擎”把 283 秒恢复压到 7.3 秒
大模型线上服务的可靠性问题，过去很容易被“多部署几个副本”掩盖。真正到了大规模推理集群，副本并不能消除故障成本：一个 worker 进程崩溃以后，剩余 worker 要立刻承接流量，首 Token 延迟升高，单用户生成速度下降；如果模型有数百 GB 权重，还要重新从存储加载、建立通信器、完成编译和 autotune、重新捕获 CUDA Graph，冷启动可能持续几分钟。对于面向 Coding A
OpenAI 自研推理芯片 Jalapeño：当大模型公司开始自己设计硅片，GPU 的护城河会松动吗？
2026 年 8 月 25 日，SemiAnalysis 公布了对 OpenAI 首款自研推理芯片 Jalapeño 的现场测试和架构分析。两个月前，OpenAI 与 Broadcom 已经正式宣布这款芯片，并明确把它定位为面向大语言模型推理的专用加速器。官方当时给出的信息相对克制：Jalapeño 从零开始设计，重点优化模型推理中的计算、内存移动、网络和服务调度，工程样片已经能够以目标频率和功
从Kimi K3到MiniMax-H3：国产大模型竞争进入“推理系统战”
SGLang v0.5.17为Kimi K3与MiniMax-H3提供day-0部署支持，推理框架、内核、缓存、并行策略和硬件适配正在成为模型商业化的主战场。