模型越来越大，为什么我们还需要切 GPU？

大模型越来越大，和 GPU 切分越来越重要，这两件事完全可以同时成立。

梁胜问了我一个问题

今年 9 月，我在北京参加 GPUStack 生态大会，晚宴的时候跟他们的 CTO 梁胜聊了一会儿。他问了我一个问题：大模型时代，GPU 虚拟化和切分还有那么重要吗？

这个问题问得挺客气的，但对我这个做 HAMi 社区和商业化的人来说，相当扎心。潜台词大家都懂：模型大到一张卡都装不下了，你们还琢磨怎么把一张卡掰成几瓣，是不是在给马车轮子做空气动力学优化？

我当时打了个太极，回来之后越想越觉得这个问题值得认真写一篇。恰好 9 月中旬 TypeSafe AI 发布了 Jev，一个不会聊天的模型，把这个问题变得更有意思了。这篇文章就是我的正式回答。

Jev：一个不会聊天的模型

先说说 Jev 是什么。TypeSafe 把它叫作 System One Model：输入是非结构化的 state 加一组类型化问题，输出不是自由文本，而是三种预定义类型：Choice（从选项里挑一个）、Score（在档位上打个分）、Noul（是或否），每种结果都附带概率分布和 confidence。

为什么说它“不会聊天”？想想我们现在怎么用大语言模型（LLM）判断“这张工单是不是 billing”。让大模型干这事，有点像请一位普利策奖得主来做选择题：他一定会先给你写一段声情并茂的短文，然后你再用正则表达式从里面把答案抠出来。为了让他说“是”，我们先教会他写一切，再用 JSON mode 把他按在椅子上，最后还得写个 parser 提防他发挥。

Jev 把这套流程整个砍了。它不做自回归生成，直接返回代码能消费的类型化结果。而且多个问题可以放在一次调用里，针对同一份 state 并行评估，官方文档的说法是“加问题几乎不增加响应时间”，因为每个问题独立评估，不会互相污染上下文。

一个类比：大型 LLM 像能读材料、写报告的高级顾问，Jev 像公司里的实时审批节点。它不会替你写报告，但每秒能处理大量“通过 / 拒绝”“A/B/C”“风险 0 到 10”这样的判断。你不会雇一个小说家来管门禁系统，但很多公司现在的架构就是这么干的。

照例泼两盆冷水。第一，“Jev cannot hallucinate”要降噪理解：类型安全保证的是输出不会超出预定义 schema，不是业务判断一定正确，一个类型完全合法的 high_risk 一样可能是误判。第二，官网首页的“快 193.6 倍、便宜 444.6 倍”来自他们自己团队设计的工作流评测，官方自己也承认属于收益的高端区间。这些数字说明的是新范式有多大的优化空间，不是“Jev 比 GPT 快 200 倍”。另外一个容易看错的数字：250,000 tokens/s 是 API rate limit，不是单卡实测吞吐，API 吞吐、模型吞吐、GPU 吞吐从来不是一回事。

亲手试一把

光看介绍没用，跑一下才知道是什么手感。console.typesafe.ai 已经开放注册，进去建一个 API key，然后：

pip install typesafe-sdk
export TYPESAFE_API_KEY=你的key

官方文档的示例就是一个客服工单分类器，一次调用问三个问题：

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

with TypeSafeClient() as client:
    response = client.system_one(
        state={"document": "I was charged twice. Please fix this ASAP."},
        questions={
            "billing": Noul(instructions="Is this ticket about billing?"),
            "tone": Choice(
                instructions="What is the customer's tone?",
                criteria={"calm": None, "frustrated": None, "angry": None},
            ),
            "urgency": Score(
                instructions="How urgent is this ticket?",
                criteria=["can wait", "this week", "today"],
            ),
        },
    )

print(response.nouls["billing"].noul)   # 是/否判断
print(response.choices["tone"].choice)  # 选中的选项
print(response.scores["urgency"].score) # 评分档位

注意这个 API 的形状：没有 prompt，没有 temperature，没有 system message。你提交的是问题和选项，拿回的是类型和概率。写惯了 LLM 应用的人第一次看会觉得少点什么，仔细想想，少的那些东西本来就不该在。

生态起来的速度也超出我预期。除了官方 Python 和 TypeScript SDK，Rust 社区有了 typesafe_ai_rs，Pydantic 的文档里已经出现 TypeSafeModel 集成，还有人做了 Jev 的 MCP server。不想直接注册的话，OpenRouter、Cloudflare Workers AI、Vercel AI Gateway 也都能调到 Jev。国内公众号上介绍它的文章也多起来了，热度是实打实的。

开源世界也没闲着

更有意思的是，这个思路已经可以自己开源复现了。Bespoke Labs 的 Nimble 就是一个例子：在 Qwen3.5-9B 上训的 LoRA 适配器，只有约 165 MiB，Apache 2.0 协议。它的做法很直白：对允许的答案 token 直接打分，推理过程不生成任何自由文本。

from inference import NimbleModel

model = NimbleModel("nimble-model")
result = model.score(
    context="The store accepts returns within 30 days. "
            "This item was bought 12 days ago.",
    schema={
        "eligible": {
            "type": "boolean",
            "description": "Is this item within the store return window?",
        }
    },
)
print(result["fields"]["eligible"]["probabilities"])

当然有约束：每个字段最多 26 个选项，超过 2048 token 的输入直接拒绝而不是截断，跑起来需要 CUDA GPU。但它的存在说明了一件事：所谓 System One 范式并不是什么黑魔法，拿一个通用模型，约束它的输出空间，直接对候选答案打分，一个 LoRA 的成本就能得到七八成像的东西。这反过来也让 Jev 的定价显得很值得研究：每百万输入 token 0.042 美元、输出不收费，官网还特意标注了比某前沿模型便宜 238 倍，竞争压力估计会来得比想象中快。

小模型的位置：判断，不是聊天

现在回到架构层面。我认为这类模型真正的价值，不是用一个 3B 模型替换 70B 模型，而是把过去由一个大模型包办的智能负载拆开。一个企业 Agent 里可能有几十种判断：意图识别、权限分类、文档相关度、内容风险、工具路由、要不要重试、要不要转人工。这些判断不需要每一次都动用 frontier 级别的能力。

更合理的分工是：代码负责确定性逻辑，专用决策模型负责高频判断，小模型负责局部语言任务，大模型只处理真正困难的推理。NVIDIA Research 关于 SLM 与 Agentic AI 的立场论文说的也是同一件事：Agent 内部大量调用是重复而专门化的，异构模型系统比“事事都调同一个大模型”更经济。

拿前面那个工单例子展开：代码先做身份认证和字段校验，然后一次调用问决策模型三个问题，是 billing 吗、语气如何、多紧急。confidence 够就直接路由执行，退款、改数据库这些动作由代码完成；confidence 不够或者进入开放式推理，才升级给大模型。

我喜欢这种架构的原因恰恰是它不“更 AI”，而是把系统控制权还给软件。如果沿着这个方向走，应用里会出现一个独立的判断层：大量低延迟、带 confidence 的判断模型位于代码和大模型之间。API Gateway 决定流量去哪里，判断层决定“这件事应该由谁来想”。Jev 是这个方向的早期实现，传统 classifier、reranker、SLM router，包括上面的 Nimble，也都属于这一层。

回到梁胜的问题

现在可以正面回答了：模型越来越大，GPU 切分还重要吗？

一旦接受“一个应用里同时跑着十几个模型”，GPU 层的问题就变了。一个 frontier 模型可能需要 8 张 H200，但它旁边的 embedding 模型只需要几 GB 显存；reranker、小视觉模型、guardrail、Notebook 各自只消耗一小块 GPU。如果还是用 Kubernetes 传统的整卡语义：

resources:
  limits:
    nvidia.com/gpu: 1

那就等于一个打车的上班族，每天来接他的是一辆 49 座大巴，还不许别人上车。模型小的时候浪费，模型多的时候制造碎片。

“模型越来越大，所以 GPU 切分过时了”这个说法，混淆了资源轴上两个相反的方向。

模型并行解决的是一个 workload 用多张卡。Tensor Parallel、Pipeline Parallel、Ray 分布式推理都属于这一类：单卡放不下就同机多卡，再不够就跨节点。

GPU 切分解决的是多个 workload 共用一张卡。HAMi（已进入 CNCF Incubating）把 GPU 从整数设备变成可以按显存、算力核、设备份额调度的资源，调度阶段就锁定具体哪张卡，MIG 场景还能按算力和显存需求自动匹配模板，并且通过 HAMi-core 在 CUDA 层做实际的资源约束，而不只是调度器账面上的数字。说到底，拆和拼不只是方向问题，能拆到什么颗粒度，才是真正的工程分水岭。

这里有个有趣的事实：梁胜问我的问题，行业已经替他回答了一半。做模型聚合的平台，一边把大模型拼到多张卡上，一边又在同一套产品里提供 GPU partitioning 和 flexible slicing。一边把卡拼起来，一边把卡拆开，这不是精神分裂，这是现实：两个方向的需求同时存在，选边才是错的。

再往后看，异构只会更严重。MoE 让总参数和激活参数脱钩，Qwen3-30B-A3B 有约 30B 总参数，但每个 token 只激活约 3B；4-bit 量化和蒸馏持续把每次请求的真实开销往下压；DistServe、Mooncake 这类工作甚至把 prefill、decode、KV cache 拆到不同的资源域。调度单位会越来越细，而不是越来越粗。

当然，也不要把 GPU 利用率当唯一 KPI。把四个推理实例塞进一张卡，让 nvidia-smi 从 30% 涨到 90%，并不自动等于总拥有成本更好；如果 P99 延迟恶化、故障域扩大，这种利用率没有多少意义。HAMi 适合碎片化明显、多租户、开发测试比例高的 GPU 池；对延迟 SLO 极严、单卡长期打满的服务，独占或者 MIG 这种硬件级隔离更稳。

总结

Jev 的意义不是证明“小模型赢了”，而是证明不是每种智能都需要生成语言。当一个判断模型、一个 LoRA 适配器就能承担应用里一半的“打勾”工作，应用就会从“一个大模型包办一切”变成十几个各司其职的小模型。

大模型继续变大，不会消灭小模型和 GPU 虚拟化；异构模型架构会让同一个集群同时面对“模型太大”和“任务太小”两种资源问题。

所以下一代 AI Infra 的核心能力，不是单纯切 GPU，也不是单纯堆 GPU，而是当 workload 需要时，能够自由地拆分和组合计算资源。一句话：小而碎的切，大而满的拼，高 SLO 的隔离，低利用率的共享。

所以，我的答案是：重要，而且越来越重要。

参考文献

• Introducing System One Models & Jev - TypeSafe AI
• TypeSafe AI Documentation - docs.typesafe.ai
• TypeSafe Python SDK - GitHub
• Bespoke-Nimble-9B - Hugging Face
• Nimble - GitHub
• Small Language Models are the Future of Agentic AI - NVIDIA Research
• HAMi - Project HAMi
• GPUStack - gpustack.ai
• DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving - arXiv
• Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving - arXiv