前言
原本打算采购一台能装7块GPU的机器。
想在本地跑一个前沿级别的编程 agent，机箱至少要能扩展到4块GPU。旁边还要同时跑图像生成、视频生成、TTS、口型同步。这样一算，消费级PC的扩展槽位根本不够，最后锁定到了带7个GPU插槽的工作站级机器。
然而，那种配置所需内存的零售价，比消费级贵得离谱。我联系了厂商，写这篇文章的时候，对方还没回复。
在等待的这段时间里，前提本身先崩了。
在一块 RTX PRO 6000 Blackwell Max-Q 上跑 poolside 的 Laguna S 2.1 NVFP4，官方基准显示它具备 DeepSeek V4 Pro 级别的编程 agent 性能，我手头的仓库修复任务它也完整跑通了。而且因为是 MoE，速度还很快。
本来在想“4块GPU怎么塞下一个LLM”，结果变成了另一个问题：“1块GPU就能跑完的LLM，该怎么和语音、批处理生成隔离开”。
这篇文章与其说是介绍一个新模型，不如说是记录模型的进步如何改变了硬件采购计划本身。
验证日期为2026年7月23日。Laguna S 2.1 刚发布不久，验证过程中 checkpoint 本身也在更新。这里的数字未来可能会变。
为什么一开始觉得非7块GPU不可
Kotonia 不是只跑一个聊天用的LLM。
- 用于角色对话和编程 agent 的LLM
- 基于 Qwen3-TTS 的流式语音生成
- 基于 Ditto 的实时数字人（talking head）
- HiDream 系列的图像生成与编辑
- LTX-2 系列的视频生成
- 实验中模型和生产环境备用模型的存放位
目前的机器配置是 GPU 0 为 96GB 的 RTX PRO 6000 Blackwell Max-Q，GPU 1 为 24GB 的 RTX PRO 4000 Blackwell。即便在生产环境待机状态下，GPU 0 侧的图像/视频/本地LLM也占用约72.8GiB，GPU 1 侧的语音相关占用约19.2GiB。
关于96GB上要常驻什么、把什么交给API，我在之前的《96GB GPU 运行记录》里写过。那时候，设计核心也不只是VRAM容量，而是按角色划分负载。
如果想在此基础上再加一个前沿级LLM，就得默认模型要拆到多块GPU上。一旦为LLM预留至少4块GPU，再想把其他生成类负载也物理隔开，最后落到7个GPU插槽也不算是什么突兀的结论。
单一机箱确实也有好处：GPU间高速互联、共享存储、统一电源管理。如果未来要用 tensor parallel 跑更大的模型，我觉得这现在仍是正确选项。
只是，这个判断前提是“想要的LLM性能，1块GPU装不下”。
总参数117.6B，每个token实际激活的却只有8.5B
Laguna S 2.1 是一个 MoE 模型，总参数117.6B，每个token的激活参数是8.5B。NVFP4 checkpoint 本体约67GiB，96GB的GPU连KV cache都能一并单卡启动。
这次用的配置如下。
| 项目 | 配置 |
|---|---|
| GPU | RTX PRO 6000 Blackwell Max-Q 96GB / SM120 |
| 模型 | Laguna S 2.1 NVFP4 |
| vLLM | 0.25.1 |
| PyTorch | 2.11.0+cu130 |
| FlashInfer | 0.6.13 |
| context | 64K |
| 最大并发数 | 4 |
| MoE backend | FLASHINFER_CUTLASS |
| attention decode | flashinfer-native |
| KV cache | FP8 E4M3 |
我没有动现有生产环境的 vLLM 0.24.0，而是为 Laguna 单独准备了一个 venv，跑 0.25.1。以官方 vLLM recipe为基准，只是这块GPU上指定的是 sm_120a，而不是面向 DGX Spark 的 sm_121a。
权重加载到GPU上大约15秒，但首次engine初始化花了957.49秒——其中约811秒是 Blackwell 内核的 profiling 和冷启动 JIT。一旦有了cache，用同样的64K、4并发配置重启，就缩短到了47.35秒。
也就是说，装完之后“怎么半天启动不了”并不是故障。但这和每次都丢弃容器、频繁更新环境的运维方式不太合得来。
官方基准真的能信吗
模型卡上截至2026年7月21日的主要 agent 类基准如下。
| Benchmark | Laguna S 2.1 | DeepSeek V4 Pro Max |
|---|---|---|
| Terminal-Bench 2.1 | 70.2 | 64.0* |
| SWE-bench Multilingual | 78.5 | 76.2 |
| SWE-Bench Pro | 59.4 | 55.4 |
| DeepSWE | 40.4 | 9.0* |
| SWE Atlas | 46.2 | 27.2* |
| Toolathlon Verified | 49.7 | 55.9* |
* 表示并非模型提供方自己给出的数字，而是第三方评测结果。Laguna 这边还公开了执行轨迹（trajectory）。
单看这些数字确实很惊人，但如果理解成“Laguna 在任何意义上都和 V4 Pro 一样聪明”就危险了。这些数字主要说明的是读代码、用工具、多步骤修复仓库的能力。
所以我在本地把短答题、严格格式、长文检索、tool call、代码生成、CLI agent 修复真实仓库这几项分开测了。
我自己的轻量基准
对比对象是之前一直用作本地LLM的 ThinkCap。两者都通过 vLLM 起成 OpenAI 兼容 API，喂同样的 prompt。
速度
| 任务 | ThinkCap | Laguna S 2.1 |
|---|---|---|
| code-chat | 111.0 tok/s / TTFB 87ms | 97.5 tok/s / TTFB 26ms |
| character-chat | 65.1 tok/s / TTFB 91ms | 99.8 tok/s / TTFB 31ms |
| studio-enhance | 104.1 tok/s / TTFB 87ms | 98.1 tok/s / TTFB 30ms |
| concurrent x4 | 185.5 tok/s aggregate | 267.9 tok/s aggregate |
| concurrent x4 median TTFB | 3356ms | 50ms |
单发 code-chat 的话，ThinkCap 反而略快一点。但在角色对话和4并发场景下，Laguna 明显拉开了差距。尤其是4并发的 aggregate 267.9 tok/s 和 median TTFB 50ms，完全不是一个总参数117.6B的模型该有的表现。
MoE 需要把整个模型都放进VRAM，但每个token并不需要计算全部参数。VRAM 很重，但计算很轻。配上96GB的GPU，这个特性原原本本地体现了出来。
能力
| 评测 | ThinkCap | Laguna S 2.1 |
|---|---|---|
| 轻量任务 | 5/6 | 6/6 |
| 扩展能力基准（严格评分） | 19/28 | 12/28 |
| 长文needle | 2/2 | 2/2 |
| tool use | 3/3 | 3/3 |
| 代码生成 | 2/3 | 3/3 |
| kotonia-cli 仓库修复（含隐藏测试） | 11/12 | 12/12 |
乍一看，扩展能力基准的12/28相当难看。仔细看内容，其实是两类失分。
一类是格式违规：明明答案本身是对的，题目要求“只输出整数”，它却附带了解释。开了 reasoning 的4道题在语义上全对，但严格精确匹配下变成了0/4。另一类是真正答错——代码追踪、组合计数、状态管理之类。
因此，光凭格式违规就判定整个模型弱不对，只按语义正确算满分也不对。这个结果说明的是，Laguna 并不是一个擅长短指令跟随的全能模型，而是一个能力偏向代码生成、tool use、长链路 agent 任务的模型。
在 kotonia-cli 上拿到了满分
我最看重的是把一个有各种坑的小型 Python 仓库交给 kotonia-cli，让它修复多个文件。
这个任务埋了这些坑：
- SKU 的去空格和大小写归一化
- 多行归一化后变成同一个SKU时的库存合并
- 整个预订流程的原子性
- 销售汇总的排序和并列判定
- 折扣边界值的闭区间判断
- 用 round-half-up 而不是银行家舍入
agent 能看到的测试有6项。加上事后追加的隐藏测试，合计12项。
ThinkCap 拿到11/12。它没能提前把归一化后变成同一SKU的多笔预订合并，在库存不足时的原子性上丢了一分。
Laguna 用了10次迭代、91秒拿到12/12。它甚至用上了 Decimal 和 ROUND_HALF_UP，连隐藏测试里重复SKU的那道也通过了。
一个小任务当然不能一概而论。但一个在短答基准上笨拙的模型，在CLI agent任务上明显赢了。看到这个结果，我判断官方的编程agent基准，至少在“这个模型擅长什么”这一点上，是相当可信的。
36K context 和长 prefill
从1200条记录里找出指定ID的needle任务，输入36,079 tokens下成功了，整个请求耗时3.17秒。
单看数字已经够快了。但如果要和实时语音同居，重要的不是平均速度，而是 prefill 瞬间的负载。
像角色对话这种短历史，Laguna 大约30ms的TTFB基本可以忽略。但读入新仓库、追加超大文件、conversation 在 compaction 之后重建，这些场景都会产生长 prefill。
在 prefix cache 生效的 agent 连续轮次里，并不是每次都要重新计算全部历史。但 cache miss 不会消失。编程需求增多时，它有可能让 Qwen3-TTS 的流式输出瞬间卡顿。
这次没用 DFlash
Laguna 还带了一个约2.1GiB的 DFlash draft model。在15个 speculative tokens、64K、4并发下做了对比，结果如下。
| 任务 | base | DFlash | 差值 |
|---|---|---|---|
| code-chat | 97.5 tok/s | 124.1 tok/s | +27% |
| character-chat | 99.8 tok/s | 55.0 tok/s | -45% |
| studio-enhance | 98.1 tok/s | 93.9 tok/s | -4% |
| concurrent x4 | 267.9 tok/s | 236.7 tok/s | -12% |
DFlash 在单发 code-chat 上确实有效，但在短回复和并发场景下，draft 的开销反而占了上风。VRAM 也涨到约91.4GiB，几乎没有余量再同居其他服务。
至少对 Kotonia 目前的负载来说，DFlash 默认关闭才是正确答案。speculative decoding 不是“新功能所以更快”，得连同输出长度、并发数、draft 接受率、同居服务一起测。
与其买7GPU机箱，不如再买一台PC
单独跑 Laguna，把 gpu_memory_utilization 设成0.9，理所当然会占掉96GB的大部分。这种状态下，想把现有约19GB的语音栈整个塞进去同居是不现实的。
但如果关掉 DFlash，压低 context 和并发数，把 Laguna 的 GPU memory utilization 调到0.78～0.80左右，情况就不一样了。粗略估算，可以把 Laguna 压到76～78GB左右，放下 Ditto 约3GB和主力TTS约7GB，还能留出7～10GB左右的余量。
这还只是一个尚未实测的假设，不过第二块 RTX PRO 6000 已经下单了。到货之后的候选配置是这样的。
| 角色 | 常驻内容 |
|---|---|
| 实时GPU | Laguna + Ditto + 主力 Qwen3-TTS |
| 批处理GPU | 图像生成 + 视频生成 |
| 现有24GB GPU | 备用TTS、退避目标、轻量服务 |
| 外部API | 轻量Vision、长prefill的临时退避、frontier review |
图像理解本来就不是 Laguna 的主战场，用一个轻量 Vision API 当 sidecar 就够了。Kotonia 这边其实已经有了一套机制：在停掉本地图像/视频生成做GPU实验期间，Studio 会显示维护提示，只把安全的部分切换到API上。
如果能这样彻底分离，管理一台巨大的7GPU机箱，反而不如再准备一台消费级PC来得干净。
- CUDA、vLLM、FlashInfer 的依赖可以按机器分开
- 图像/视频的批处理负载能和实时语音物理隔离
- 实验失败或重启的影响半径更小
- 只开需要的那台机器就行
- 因为模型单卡就能装下，不需要跨机箱的GPU间互联
当然，这也有代价：网络故障、模型cache重复、需要监控的对象变多。如果未来又出现一个单卡装不下、需要 tensor parallel 的模型，7GPU机箱的价值也会重新回来。
不过现在的问题已经不是把GPU高速连接起来了，而是别让延迟需求不同的负载互相打架。
真正可怕的不是VRAM，而是语音的p99
模型在GPU上同时不OOM，和这些服务真的能同居，是两码事。
LLM、TTS、Ditto 共享 SM、显存带宽、cache 和 scheduler。哪怕平均利用率看起来不高，一旦长 prefill 和 TTS 生成撞上，流式语音的chunk间隔就会乱掉。即便 Qwen3-TTS 的平均实时率小于1，只要有部分chunk延迟，用户听到的就是“卡顿”。
接下来该测的，不是单纯的 tokens/s 或者平均 RTF。
- TTS 的 time to first audio
- 语音chunk间隔的 p95 / p99
- 可播放音频时长和到达时刻之间的差值
- 播放缓冲区underrun次数
- Ditto 的最低fps和帧延迟
- Laguna decode期间 vs 长prefill期间的差异
条件也要按 TTS单独、TTS + Ditto、TTS + Laguna decode、TTS + Laguna long prefill、全部同时的顺序逐步叠加。
300～500ms左右的 audio lookahead buffer 能吸收一些小抖动，但对话延迟也会因此变大。语音流式进行中，也可以考虑只把短的角色对话走本地，比如超过8K tokens的新编程 prefill 转发到外部API——这种 admission control 也是一个候选方案。
这部分等第二块 RTX PRO 6000 到货之后再实测。
结论：不要让模型替你提前决定该买哪台机器
这次的 Laguna S 2.1，至少在编程和 tool use 用途上相当强。
- 约67GiB的NVFP4权重，单卡96GB就能装下
- character-chat 约100 tok/s，4并发达到267.9 tok/s aggregate
- 通过了36K tokens的长文needle测试
- kotonia-cli 的仓库修复含隐藏测试拿到12/12
- 另一方面，严格的短指令跟随只有12/28，不是一个全能模型
- DFlash 在这次的负载下综合更慢，VRAM也更重
官方 agent 基准的数字，至少在“这个模型擅长代码和工具使用”这个意义上相当可信。但不能把它延伸到通用智能或者所有对话质量上。
而这次最大的收获，其实不是模型的分数。
我本以为要拿到 V4 Pro 级别的 agent 性能，至少需要4块GPU。基于这个前提去找7GPU机器，被工作站级配置的价格卡住了。结果因为 MoE 的进步，问题被压缩进了1块GPU。
一旦到了这一步，要优化的对象就不再是GPU密度，而是故障隔离、语音的尾延迟、和批处理之间的边界。一台大机器，或许还不如两台分离开的小机器。
厂商先回复报价，还是第二块GPU先到货、我先测完同居基准，现在还不知道哪个先来。
不过，能在下单7GPU机器之前，前提就先自己消失了，大概算是运气好。
下一步是让 Laguna、Qwen3-TTS、Ditto 同时跑起来，测一测长 prefill 到底能把语音的 p99 拖垮到什么程度。