本地部署

十月十三日英伟达预告、十五日正式开放下载的 Nemotron 3.5 Bolt 74B-A9B，把一件过去只有数据中心才扛得动的事拉到了消费级桌面：总参数 740 亿，每个 token 只激活约 90 亿，通过 2 bit 量化感知训练（QAT）把权重体积压到约 24GB。这意味着一张 RTX Spark 级别、带 24GB 显存的机器，就能跑一个面向智能体的开放权重模型，而不是只能跑 7B 级别。 2 bit 量化感知训练到底省了多少？ 常规做法是训完之后再做 PTQ 量化，4 bit 已经掉点明显，2 bit 几乎没法看。Bolt 的路子是在训练阶段就把 2 bit 伪量化节点插进去，让模型权重分布在训练中自适应到低比特网格上，推理时直接用 2 bit 权重做矩阵乘。参数量从 74B 降到 24GB 体积，单 token 激活仍是 9B 级别——这是 MoE 的红利：稀疏激活把算力压下来，QAT 把显存压下来。两个压缩叠加，才让 74B 走进了 24GB 盒子。 本地智能体为什么非要 9B 激活？ 智能体不是聊天，是要反复调用工具、读长上下文、在多步循环里保持指令遵循。7B 稠密模型在 tool calling 的格式稳定性上已经吃力，9B 激活的 MoE 配合 NVIDIA 专门的 agentic post-training，在函数调用准确率和长循环不跑偏上能拉出一档差距。24GB 显存同时还要给 KV cache 和 tool result 留空间，这也是为什么 NVIDIA 把目标场景定为 RTX Spark 这类「始终在线智能体」盒子，而不是随便一张游戏卡。 ...

据 10 月 15 日早间报道，阶跃星辰正式开源 Step 5 Preview 的完整模型权重。这是一款稀疏 MoE 架构模型：总参数 6000 亿，单个 token 只激活 270 亿参数，支持 100 万 token 上下文，图文输入兼顾。模型定位聚焦 AI 编程、金融和 Agent 任务，在综合智能指数榜单位列全球开源模型前三。此前九月发布时它只开放了 API，这次是权重首次完整放出。 6000 亿总参但只激活 270 亿，本地跑现实吗？ 不现实，别被「开源」两个字骗了。MoE 的总参数决定了显存占用：即使按 FP8 粗算，6000 亿权重也要 600GB 上下的显存，单卡到八卡消费级配置都吃不消，真正的门槛在数据中心级节点。对个人开发者，正确姿势不是本地跑，而是走两条路：一是等社区 GGUF 量化版流出后在大内存机器上低速跑通，二是直接用阶跃开放平台的 API。官方文档给出的接入方式是安装 StepCode CLI，macOS 和 Linux 一条 curl 命令即可完成，Windows 走 PowerShell 脚本。 编程栈里替换现有模型要注意什么？ Step 5 Preview 此前披露的对标数据是单任务成本约为 Claude Opus 5 的八分之一，这对高频调用的编程场景有直接吸引力。但替换前先做三件事：用你真实的代码库跑一轮基准，MoE 模型在不同语言上的表现方差不小；保留原模型作为 fallback，新模型对长上下文项目的理解方式不同，输出风格突变会让代码审查成本上升；金融场景特别注意，开源权重的模型输出没有官方合规背书，对外服务前要过一遍备案和内容审核链路。 权重开源和 API 便宜是两笔账。前者决定学术界和云厂商怎么二次分发，后者决定普通开发者今天用不用得起。放到国产开源阵营里看，Step 5 Preview 的差异化是「大激活比加百万上下文」这个组合，对需要长代码库整体理解的仓库级任务有实际意义；但和已经发版多代的开源编程模型相比，它的工具调用稳定性还需要社区用两个月时间填坑。建议观望到第一批开源评测出来，再决定要不要把生产流量切过去。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论 ...

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

2025 年 8 月 OpenAI 开放 gpt-oss 系列权重（20b 与 120b）时，行业将信将疑。一年后的 2026 年 10 月回看，判断一个开放权重模型生不生产，标准已经变了：不再是「权重能不能下载」，而是「发布当天有没有推理框架 day-0 支持、有没有微调内核、有没有量化检查点」。gpt-oss 这条线恰好把这条生态链走通了。 三个成熟标志 推理 day-0 化：SGLang 为 gpt-oss 做了 Unified Radix Cache 与 Flex Attention 适配，60K 上下文 BF16 LoRA 训练只要 80GB 显存；新版本 Qwen3.8 发布当天，SGLang 与 Miles 直接给出支持，NVFP4 检查点同日上线。 微调工具链闭环：Unsloth 把 gpt-oss 的 QLoRA 4bit 训练推到 H100 上 290K 上下文，50 万 token 可训，还反过来验证了开源权重的可定制性。 跨硬件扩散：从 NVIDIA Blackwell 到 AMD GPU，gpt-oss 类开放权重都有官方或社区适配，AMD 侧 GRPO 训练显存省约 80%。 为什么这才叫「开源」 过去很多开放权重卡在「下完跑不起来」：量化要自己做、长上下文要自己改、新架构没人支持。2026 年的生态成熟意味着，一个团队拿到权重，当天就能在自己的硬件上跑出接近商用 API 的体验，还能按数据微调。gpt-oss 的意义不是模型本身多强，而是它把大厂开放权重变成了一个可被工程化的生态入口。 ...

10 月 7 日，微软在旧金山发布 Surface Laptop Ultra，售价 2599 美元起，搭载英伟达 RTX Spark 超级芯片，最高 128GB 统一内存，号称本地能跑超过 1200 亿参数的模型。这台机器到底是给哪类人准备的？答案藏在一笔三年总持有成本（TCO）里。 先把两边的价格摆出来 本地侧：机器 2599 美元（约合人民币 17500 元），三年电费忽略不计，折旧后残值按 30% 算，净硬件支出约 1800 美元。换来的是 128GB 统一内存，可以本地跑量化后的 120B 级模型，数据不出本机。 云端侧：OpenAI 10 月 7 日刚把 GPT-6 全量放开，API 价目表里 GPT-6 Luna 输入 0.10 美元、输出 0.50 美元每百万 token，GPT-6 Sol 输入 2 美元、输出 10 美元每百万 token。一个重度开发者一个月烧掉 1000 万输出 token 用 Sol，就是 10 美元；若走 Luna 则不到 1 美元。 盈亏平衡点在哪 粗算：如果一个开发者每月云 API 支出稳定在 50 美元以上，三年就是 1800 美元，刚好覆盖这台机器的净硬件成本。也就是说，每月在 API 上花 50 美元以上、且工作负载可以本地化的人，买这台机器在经济上说得通。 ...

10 月 8 日，微软推出搭载英伟达 AI 芯片的 AI 笔记本，2599 美元起，主打本地 AI 性能对标 MacBook Pro。在云端 API 已经便宜到近乎白送的 2026 年，花大价钱买「本地跑模型」到底图什么？图的是数据不出机、断网能用、以及长上下文不按 token 计费。问题是：这个价位的机器，本地到底能跑动多大的模型。 算一笔显存账 本地跑模型的硬约束是统一内存（显存），不是 CPU。一个 70B 参数模型： 4-bit 量化（AWQ/GPTQ）约需 35–40 GB 内存； 8-bit 约需 70 GB； 直接跑 FP16 需要 140 GB 以上，轻薄本想都别想。 所以 2599 美元这档机器，现实目标是 7B–14B 的 4-bit 流畅跑，70B 的 4-bit 在 64GB 以上内存机型上「能跑但慢」。吞吐大约在每秒几个 token，适合写文档、做本地知识库问答，不适合高并发。 怎么把它用值 用 llama.cpp 的 server 模式或 ollama 起本地 OpenAI 兼容端点，前端接 Open WebUI，团队共享； 量化选型上，日常问答选 4-bit 已足够，对事实要求高的再上 8-bit； 长文档场景，把上下文窗口调到 16K–32K，别一上来塞满 128K，内存会先顶不住。 判断 这类机器不是给「追求最强模型」的人准备的——那个需求交给云端 GPT-6、Gemini。它真正的客户是：对数据合规有硬要求的团队、经常出差断网的人、以及想把敏感微调数据留在自己手里的开发者。买之前先想清楚你要跑哪个尺寸的模型，别为「本地 AI」四个字付了智商税。 ...

两个工具，两种口味 本地跑大模型，新手最先撞上的两个工具是 Ollama 和 LM Studio。它们底层都吃 GGUF 量化模型，差别在交互哲学。Ollama 走极简命令行路线：ollama run qwen2.5 一条命令就下载并开始对话，自带 OpenAI 兼容 API（默认端口 11434），适合脚本、服务集成和服务器上跑。LM Studio 则是图形界面，自带模型浏览器，点几下就能搜、下载、加载、聊天，还能本地起一个 OpenAI 兼容服务器，适合不想碰命令行、想先可视化试模型的人。一句话：要省事集成选 Ollama，要直观摸索选 LM Studio。 选模型的三个实操点 第一，先看量化档位再下载。同一个 7B 模型，Q4_K_M 约 4GB、Q8_0 约 8GB，别下错成 FP16（14GB）把自己显存撑爆。LM Studio 会按你的显卡筛选能跑的模型，Ollama 则默认拉适中档位。第二，上下文长度要手动设。默认上下文 often 偏小，长文档场景要在参数里把 num_ctx 调到 8K、32K——但记住 KV Cache 随长度线性涨，调太大又会爆显存。第三，别用错后端：N 卡走 CUDA，A 卡走 ROCm，苹果芯片走 Metal，装错版本会慢到怀疑人生。LM Studio 安装时会让你选，Ollama 则自动检测。 API 调用与接 Agent 两个工具都暴露 OpenAI 兼容接口，这是它们的关键价值。意味着你可以把本地模型当成「本地版 GPT」，任何支持 OpenAI SDK 的框架改一下 base_url 就能接——LangChain、LangGraph、各类 Agent 框架无缝切换。调试时一个实用习惯：先用命令行或界面把模型跑顺、确认参数对，再切到 API 接业务，避免一上来就在集成层调不出来时分不清是模型问题还是代码问题。 常见坑 一是模型互相占显存：上一个模型没卸载，下一个加载就 OOM。Ollama 会自动卸载，但多开时仍要留意。二是tokenizer 与模板不匹配：手动换模型文件时，用错 chat 模板会让模型输出格式混乱，优先用工具自带的模型库而非自己乱拼文件。三是量化过度：图小选了 IQ2、IQ3 这类极低档位，质量肉眼可见地崩，省显存的代价是变笨，得不偿失。 ...

它为什么能加速又不掉质量 自回归解码有个天然瓶颈：生成第 N 个 token 必须等第 N-1 个算完，一步一步串行，GPU 大量算力在干等。投机解码（speculative decoding）绕过这个瓶颈：先让一个小而快的 draft 模型一口气猜后面 8 到 16 个 token，再让主模型用一次批量前向同时验证这一串猜测——猜对的直接采纳，猜错的从错处重算。关键在于验证用的是主模型同分布的采样规则（拒绝采样），所以输出和主模型逐字生成完全等价，质量不掉，速度却能提升。这是它比量化之类有损加速更迷人的地方：无损提速。 两条路线：独立 draft 与自带 MTP 2026 年的生态里，投机解码分两路。一路是经典 draft 模型：从同一个模型家族里挑一个更小的兄弟当 drafter，比如用 Qwen2.5-0.5B 配 Qwen2.5-7B，在 llama.cpp 里用 --spec-draft-model 指过去。另一路是自带的多 token 预测头（MTP）：像 DeepSeek V4 附带的 DSpark drafter、Qwen4Exp、Kimi K3，把草稿模块直接训进了权重，不用你另找小模型，开箱即用——而且同分布，接受率天然高。llama.cpp v0.6.0 已经把 Qwen4Exp 的 MTP 投机解码纳入稳定支持。 命令行怎么开 llama-server 里典型的开法是： llama-server --model target-Q4_K_M.gguf \ --spec-draft-model draft-Q4_K_M.gguf \ --spec-type draft-simple \ --spec-draft-n-max 8 \ --n-gpu-layers 99 --spec-draft-n-max 控制一次猜几个（默认约 16，太大反而拖慢）。跑起来后 stderr 会打印 accepted / rejected 的比例，这是你判断效果的唯一硬指标。 ...

AMD 卡跑模型的真相 很多人以为「AMD 显卡跑 AI 全是坑」，其实坑不在 AMD，而在 ROCm 版本和你的显卡型号是否匹配。NVIDIA 那套 CUDA 生态确实成熟，但同显存档位的 AMD 卡（比如 7900 XTX 24GB、RX 7900 GRE）价格明显低一截，跑 GGUF 量化模型完全够用。关键是别拿「通用版 ROCm」硬套，要先确认你的卡在支持列表里。 先查你的卡在不在名单 ROCm 对消费级显卡的支持是逐步放开的。截至目前，官方正式支持较好的是 RDNA3 架构（RX 7900 系列、RX 7800 XT 等）以及部分 RDNA2。老卡或太新的卡可能要靠社区补丁。动手装之前，先去 ROCm 官方文档查 GPU 支持矩阵，确认你的型号和 Ubuntu 版本（ROCm 对 Linux 支持最好，Windows 上走 DirectML/Vulkan 是另一条路）组合在列。装错版本，症状就是：装得上、跑不起来、报 HIP 错误。 三条落地路径 路径 适合 特点 ROCm + Ollama（Linux） 主流推荐 Ollama 官方 ROCm 版自动调用 GPU ROCm + llama.cpp 要精细调参 编译时 HIP_HSA=1 启用 AMD 后端 Windows DirectML 不想折腾 Linux 兼容性广但速度一般 最省事的是 Linux 上直接装带 ROCm 支持的 Ollama：装好后 ollama run qwen2.5:7b，再用 rocminfo 或 ollama ps 确认任务真的跑在 GPU 上而不是 CPU——很多人「感觉变慢了」，其实是退回 CPU 推理了，白装 ROCm。 ...

Ollama 的定位：一行命令的本地运行时 相比 LM Studio 的图形化，Ollama 走的是命令行极简路线：装完之后，ollama run qwen2.5 一条命令就把模型下载、加载、对话全搞定。它特别适合服务器、无人值守环境、以及要写脚本自动化的场景——没有界面，纯靠命令和 API，反而最容易嵌进流水线。 高频命令速查 命令 作用 示例 ollama run 拉取并进入对话 ollama run qwen2.5:7b ollama pull 只下载不对话 ollama pull gemma2:9b ollama list 看本地已有模型 ollama list ollama ps 看当前加载在内存的模型 ollama ps ollama rm 删除模型释放磁盘 ollama rm qwen2.5:7b ollama serve 启动 API 服务 ollama serve 默认情况下，装完 Ollama 它会自动在后台起服务，监听 http://localhost:11434，而且这个 API 也是 OpenAI 兼容的（路径在 /v1 下）。也就是说，你可以像调云端一样调本地： from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "用一句话解释什么是RAG"}] ) 模型名就用 ollama list 里显示的那个（带冒号版本号）。 ...