这周技术群里最热闹的话题翻来覆去其实就三件事国产大模型的能力又往上顶了一截自研芯片在大模型场景里的适配开始从“能跑”转向“好用”AI 应用也从“能聊天”变成了“能干活”。三件事赶在同一个时间点上冒出来对做落地的人来说比看多少场发布会都实在。先别急着讨论“哪个模型更强”“哪块卡更快”我更想聊聊这几件事背后真正改变的东西模型冲高冲的是小参数模型的能力密度芯片冲高冲的是非 N 卡生态的实用程度应用冲高冲的是流式交互和智能体的工程底线。这篇文章我想围绕这三条线把这一周里我最常用的部署方案、微调记录、SSE 流式输出代码和一个智能体小例子完整拆开顺便把踩过的坑一并写出来。适合最近开始接触大模型本地部署、想在自有硬件上跑模型、或者准备把模型接进业务系统的朋友参考。1. 这周被反复讨论的三件事究竟落在哪里1.1 模型侧小参数模型的能力密度在冲高很多人以为“大模型冲高”就是参数规模继续往上千亿狂奔但这周大家讨论最密集的反而是 7B、8B 这类小模型的“能力上探”。拿 Qwen2.5-7B 举例它已经在代码生成、指令跟随、工具调用这些关键能力上逼近了半年前很多几十 B 模型的表现而它的权重只有 14GB 左右BF16 精度一块 24GB 的消费级显卡就能完整跑起来。这意味着什么意味着微调不再是少数有大算力团队的特权。以前你想微调一个行业模型先要解决 A100 集群和分布式训练环境现在你只需要一张 24GB 显卡、一份干净的行业数据就能用 LoRA 方式在几小时内得到一个能用的小模型。这一周我在好几个群里都看到有人晒微调曲线数据格式基本都是“指令 输入 输出”用的也多是 Qwen、GLM 这类开源权重。模型的“能力冲高”其实是把大模型的边际成本打了下来。1.2 芯片侧自研加速卡开始进入主流推理工具链过去聊“自研芯片”大家第一反应是“能不能跑 CUDA”第二反应是“能不能用 PyTorch”。这一周的风向变了讨论重点变成了“自研加速卡在 Ollama 里怎么配置”“ROCm 能不能直接跑 vLLM”“不依赖 CUDA 的推理后端成熟到什么程度”。这是比单纯堆算力更重要的信号生态适配跟上了芯片才有资格谈“使用价值”。我自己的实测印象是OpenCL、Vulkan 这些非 CUDA 后端已经能稳定跑不少量化模型ROCm 在部分消费级显卡上的PyTorch训练也走通了完整流程。加上社区里针对国产加速卡的驱动和算子库迭代得很快很多过去要自己编译的东西现在已经进了官方仓库。芯片侧“冲高”冲的是软件栈的高度不光是硬件本身。1.3 应用侧从 ChatDemo 到生产级流式交互这周还有一个明显趋势大家不满足于“弹出一个对话框聊天”了开始认真考虑“模型怎么接入真实业务”。比如后台管理系统里要实时渲染大模型的回答前端要处理流式输出和中断重连比如旅游推荐、K 线解读、客服工单分类都开始用智能体Agent的方式做。流式输出、函数调用、工具选择这些原本藏在文档里的能力一下子变成了生产环境的刚需。这三件事放在一起看其实就是一条完整的链路国产大模型负责提供“脑力”自研芯片和消费级显卡负责提供“体力”流式交互和智能体负责把脑力“接进业务流程”。“同时冲高”四个字说的是三个环节同时迈过了实用门槛。2. 大模型跑在自研芯片上核心链路怎么拆2.1 从模型权重到 token一条完整链路要理解芯片适配的意义先得知道大模型推理到底干了什么。你可以把模型权重想象成一本巨大的菜谱输入的一句话是“今天想吃鱼”推理过程就是厨师计算单元按照菜谱一步步处理这个请求最后端出一道菜回答的 token。整个链路大致是分词 → 嵌入 → 多层 Transformer 计算 → 采样 → 输出 token然后拿新 token 继续喂回模型直到输出结束标记。这里面每一步都对硬件有不同要求。分词和嵌入是内存密集型Transformer 层的矩阵乘法是算力密集型而自回归生成过程中每一轮都要访问全部权重所以显存带宽非常关键。如果一块卡只在“算得快”上强但显存带宽上不去生成速度一样会被卡住。这就是为什么自研芯片冲高不能只看峰值算力还得看带宽、缓存、驱动和算子库。2.2 显存、带宽、算力哪个才是真瓶颈很多新手第一句话就问“这块卡算力多少 TFLOPS”但实际做部署时最先撞上的瓶颈往往是显存容量然后是显存带宽。显存这块可以简单估算7B 模型用 BF16每个参数占 2 字节加载权重约 14GB。跑 2048 token 的上下文时KV Cache 和激活值还要再占 2~4GB所以 16GB 显卡是“刚好够用”24GB 才比较舒服。如果量化到 4bit权重降到约 4GB8GB 显存的卡也能跑但速度和精度都会有取舍。带宽的影响同样直接。推理时每生成一个 token理论上都要把全部权重读一遍。以 7B 模型、4bit 量化为例每 token 要读约 4GB 数据假设你的显卡显存带宽是 300GB/s那理论上限只有 75 token/s扣除实际开销后大概打六七折。如果模型没有完全驻留显存而走 PCIe 交换速度就会断崖式下跌。所以看到“推理速度慢”先别急着怪算力带宽和显存占用往往才是真凶。2.3 消费级显卡和自研加速卡怎么选这一周很多人纠结“要不要买自研加速卡”。我的建议比较务实先把手上的卡跑通再考虑升级。下面这张表是我在选型时习惯用的对照维度维度NVIDIA 消费卡AMD 消费卡自研加速卡框架支持CUDA 生态成熟几乎通吃ROCm 快速完善中多数需先确认算子库和框架版本软件安装成本低驱动装上就能跑中部分环境要编译中高常要看厂商文档显存容量8GB~24GB 常见8GB~16GB 常见视具体型号而定通常偏大值得参考场景个人开发首选预算敏感或手头已有服务器批量部署、信创环境不是说自研卡不好而是对大模型开发来说生态成熟度直接决定你晚上能不能按时睡觉。如果只是想自己跑通模型、微调一下我建议先用手头显卡把链路打通再评估自研卡的生产适配。等到框架版本、算子库、模型量化工具都对齐了换卡就是一次很自然的硬件升级。3. 模型侧实操从部署到微调的一次完整记录3.1 推理框架选型Ollama、vLLM、llama.cpp 怎么选这一周被问得最多的问题里“到底该用哪个框架跑模型”排前三。我的选择逻辑很简单本地调试和轻量使用用 Ollama服务化高并发用 vLLM极简环境或者 CPU 推理用 llama.cpp。框架优势适合场景注意点Ollama一条命令跑模型有 OpenAI 兼容 API个人电脑调试、内网小工具高并发吞吐一般vLLM连续批处理、高吞吐、支持 PagedAttention生产环境 API 服务显存占用需仔细配置llama.cpp纯 CPU/混合推理、GGUF 量化轻量无独显机器、边缘设备部署门槛略高于 Ollama我自己常用的组合是开发阶段直接ollama run qwen2.5:7b快速验证效果要接业务 API 时把同一个模型放进 vLLM用--max-model-len和--gpu-memory-utilization控制显存占用压测下来吞吐比 Ollama 高不少。如果你只有纯 CPU 的机器llama.cpp 配合 GGUF 格式是最靠谱的选择速度虽然不快但至少稳定可用。3.2 用 Qwen2.5-7B 做一次 LoRA 微调这周我完整跑了一遍 Qwen2.5-7B 的 LoRA 微调环境是单张 24GB 显卡流程比想象中顺利。先把环境准备好conda create -n qwen-lora python3.10 -y conda activate qwen-lora pip install torch --index-url https://download.pytorch.org/whl/cu121 pip install transformers datasets peft accelerate bitsandbytes微调脚本的核心部分如下我调整了几个关键参数你复制时注意根据自己的显存和数据量修改from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import load_dataset model_id Qwen/Qwen2.5-7B-Instruct model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypeauto, device_mapauto, attn_implementationsdpa, ) tokenizer AutoTokenizer.from_pretrained(model_id) tokenizer.pad_token tokenizer.eos_token lora_config LoraConfig( r32, lora_alpha64, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) def format_sample(example): text f指令{example[instruction]}\n输入{example[input]}\n回答{example[output]} return tokenizer(text, truncationTrue, max_length1024) dataset load_dataset(json, data_filestrain.jsonl)[train] dataset dataset.map(format_sample, remove_columnsdataset.column_names) training_args TrainingArguments( output_dirqwen-lora-out, per_device_train_batch_size2, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, lr_scheduler_typecosine, logging_steps20, save_steps500, fp16True, report_tonone, ) trainer Trainer(modelmodel, argstraining_args, train_datasetdataset) trainer.train()几个参数我说下理由。per_device_train_batch_size2是为了控制显存如果直接开 424GB 显存很容易被激活值撑爆。gradient_accumulation_steps8相当于用小批次数凑出大 batch效果更稳。r32是 LoRA 的秩任务简单用 16 就够偏复杂的行业任务用 32 更不容易欠拟合。数据格式也比你想的更关键同一批数据里如果有“指令”和“回答”混着没对齐loss 会假性下降但实际生成效果很怪。3.3 显存不够时的几个应急方案显存不够是本地微调最常见的坑。有一次我在一张 8GB 卡上跑同样的 Qwen2.5-7B直接 OOM换了几个办法才跑起来。按优先级排序先用 4bit 量化加载模型也就是load_in_4bitTrue再把max_length从 1024 降到 512最后把 batch size 降到 1梯度累积调大到 16。QLoRA 模式下7B 模型只要 8GB 显存就能微调速度慢一点但至少能跑。部署阶段也有对应的量化手段。llama.cpp 生态里的 GGUF 格式可以按 Q4_K_M、Q5_K_M 等档位压缩模型质量损失在可接受范围。vLLM 里则可以用--quantization awq或加载已量化的权重。我自己习惯先跑原版 BF16 验证效果确认效果没问题再量化上线避免“一开始就量化根本分不清效果差是模型问题还是量化问题”。4. 应用侧实操SSE 流式渲染与一个智能体例子4.1 SSE 流式输出实时渲染的底层逻辑大模型回答动辄几百字如果等全部生成完再一次性返回用户体验是灾难性的。SSE 的设计思路很直接服务端把生成过程拆成一行行数据通过 HTTP 长连接推给前端前端收到一个 token 就渲染一个 token。前端用 fetch 处理流式响应我通常这样写const controller new AbortController(); async function chatStream(prompt) { const response await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ prompt }), signal: controller.signal, }); const reader response.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { if (line.startsWith(data: )) { const payload JSON.parse(line.slice(6)); renderToken(payload.token); } } } } function stopStream() { controller.abort(); }后端如果用的是 FastAPI最小实现长这样from fastapi import FastAPI, Request from fastapi.responses import StreamingResponse app FastAPI() app.post(/chat) async def chat(request: Request, payload: dict): async def generate(): async for token in call_llm(payload[prompt]): if await request.is_disconnected(): break yield fdata: {json.dumps({token: token}, ensure_asciiFalse)}\n\n return StreamingResponse(generate(), media_typetext/event-stream)这里有个非常容易被忽略的细节前端AbortController中断之后后端的生成循环不会自动停。你必须在后端检查request.is_disconnected()否则用户关掉页面后GPU 还在继续跑白白浪费资源。我见过一个线上事故就是因为没做这个检查几个长请求把一张 A100 的显存占满了。4.2 一个旅游推荐智能体的最小实现智能体的核心不是“聊天”而是让模型学会调用工具。拿旅游推荐来说用户说“帮我规划杭州两天一夜的行程”模型光靠记忆回答是不靠谱的应该让它先调一个“景点搜索”工具拿到实时信息后再组织答案。工具定义用 OpenAI 兼容的 function calling 格式tools [{ type: function, function: { name: search_poi, description: 搜索指定城市的景点或餐厅, parameters: { type: object, properties: { query: {type: string, description: 搜索关键词例如 博物馆}, city: {type: string, description: 城市名称}, }, required: [query, city], }, }, }]调用循环写起来也不难messages [{role: user, content: 帮我规划杭州两天一夜的行程}] for step in range(5): resp client.chat.completions.create( modelqwen2.5-7b, messagesmessages, toolstools, ) msg resp.choices[0].message if msg.tool_calls: messages.append(msg) for tc in msg.tool_calls: args json.loads(tc.function.arguments) result search_poi(args[query], args[city]) messages.append({ role: tool, tool_call_id: tc.id, content: json.dumps(result, ensure_asciiFalse), }) continue print(msg.content) break注意循环次数一定要设上限我设的是 5 步。原因很现实模型有时候会陷入“查了再查”的死循环尤其工具返回数据不理想时它会反复调用同一个工具。限制步数不仅是为了省 token更是为了防止生产环境出现失控请求。这个最小智能体已经够用了如果你想更进一步可以把工具换成股票 K 线读取接口让模型先拉数据再总结走势但所有输出都只能作为参考不能直接当投资建议这个度要把握好。4.3 生产环境还要注意的几个细节流式和智能体都跑通之后距离上线还差几步。超时控制SSE 是长连接但客户端要设置合理的 idle 超时避免连接挂死。限流大模型接口必须做 QPS 和并发限制否则几个大并发请求就能打爆显存。鉴权尽量把模型接口放在网关后面不要直接把内部模型服务暴露出去。可观测性记录每一次请求的 token 数、耗时、工具调用链方便排查。兜底智能体工具连续失败时要有一个“主动放弃并转人工”的退出路径。这些都不是大模型的“高深理论”但每一条都是线上环境教做人的地方。我见过太多项目模型效果调得挺好一上线就被并发和超时搞得焦头烂额问题根子都在工程细节上。5. 常见问题与排查技巧实录5.1 显存不足、OOM排查顺序很重要OOM 出现时最忌讳的就是 “我直接调低 batch size 再试一次”。我的排查顺序是先看显存到底被谁吃了再决定怎么调。nvidia-smi或rocm-smi能看出当前卡上的显存占用但要注意 PyTorch 的缓存机制显存被模型释放后可能还留在缓存里需要在程序里调用torch.cuda.empty_cache()才能真正腾出来。如果是在 vLLM 里 OOM重点关注--max-model-len。默认上下文长度往往偏大而 KV Cache 随长度线性增长把 max length 从 8192 降到 4096显存占用立刻能省下一大块。如果是微调阶段 OOM先试 4bit 量化加载再降序列长度最后再降 batch size。不要把顺序反过来因为降 batch size 对显存的影响往往没有缩短序列长度来得直接。5.2 微调后 loss 下降但效果反而变差这种情况我踩过不止一次。Loss 下降只能说明模型在“记住”训练数据不能说明它学到了泛化能力。最常见的三个原因第一数据格式不统一指令和回答之间的分隔符混乱模型学了个寂寞第二数据里有重复样本模型过拟合到具体句子换个说法就答不上来第三学习率太大导致灾难性遗忘原模型常识被冲掉了。我的对策是微调前先拿原始模型跑一遍验证集记录 baseline微调过程中每个 epoch 都保存 checkpoint而不是只保存最后一步最后用同一批验证集做对比选效果最好的 checkpoint 回滚。如果发现效果差在“刷格式”上还有一个笨但有效的办法训练集里混入 20% 左右的通用对话数据能明显缓解灾难性遗忘。5.3 推理速度不达预期先别急着换显卡推理慢先看几个数据模型是否完全驻留显存、采样参数是否把输出长度顶满、并发请求是否过多、是否走了量化。我遇到过最典型的例子是模型在 8GB 显卡上跑 7B 原版权重要从内存换入换出速度只有 3 token/s。换成 4bit 量化后权重完全驻留显存速度直接翻了好几倍。所以“慢”很多时候是显存容量不够导致的换入换出跟算力没有关系。另一种情况是单请求看起来不慢但并发一大就卡死。这多半是连续批处理没有生效。vLLM 的优势恰恰在这里它会动态合并多个请求的 decode 阶段吞吐显著高于简单开多个线程推理。如果你在用自己的推理脚本接并发一定要检查是否把多个请求放进了同一个 batch否则 CPU 和 GPU 的利用率都会非常难看。6. 这波“同时冲高”对普通开发者的实际影响6.1 工具选型的边界变了先跑通再优化以前做 AI 应用默认前提是“我有 GPU 服务器且大概率是 N 卡”。现在模型侧和芯片侧同时冲高以后这个前提松动了小模型让普通显卡也能跑自研芯片和 ROCm 生态让非 N 卡也有了完整路径应用层则因为 SSE 和智能体成熟可以直接接进业务逻辑。对开发者来说最大的变化不是“能用上多大的模型”而是“可以踏实选择一个不依赖特定硬件的技术栈”。我现在接新需求时会先问三个问题任务真的需要大模型吗需要在什么设备上跑需要多高的并发如果只是内部工具一个 7B 量化模型加 Ollama 就能解决如果要做对外服务再考虑 vLLM 和正式部署。这个决策顺序恰恰是这周“三件事”给我的最大启发。6.2 我个人的几点实在体会最后分享两个小技巧。第一模型部署前先在 CPU 上用 llama.cpp 把推理链路跑通确认模型文件没问题再切到显卡上做性能优化。这一步能帮你把“模型损坏”和“硬件适配”两类问题彻底隔开排查起来省很多时间。第二微调数据不要贪多3000 条高质量、去重后的样本往往比 3 万条凑数的数据更可靠先把这 3000 条做进一个干净的验证集效果稳定了再扩量。这一周模型的进步确实快但落到工程上比的还是谁更能把细节做扎实。无论是芯片适配、量化部署、流式输出还是工具调用跑通只是第一步跑稳才是真正能交付的水平。希望这篇记录能让你少走一些我已经走过的弯路。