
用 ASP.NET Core 给大模型做 token 流式输出，最常见的三个焦虑是：**每次 flush 是不是很贵、能不能扛几百个并发连接、慢客户端会不会把内存吃穿**。这三个都在本机实测了一遍，结论和直觉都不太一样。

## 结论

- **每帧 flush 一点都不贵**：24 字节的 SSE 帧逐帧 flush，单连接 **0.141~0.151 µs/帧**（660~710 万帧/秒），改成 100 帧 flush 一次只快 **1.5~1.7 倍**。一次 2000 token 的回答，服务端推流总成本约 **0.2 毫秒**。
- **并发不线性**：200 条并发连接的总吞吐只到单连接的 **7.7 倍**（4100~5650 万帧/秒），单连接 p50 延迟从 0.3~0.4 ms 涨到 **5.4~7.6 ms**（约 18 倍）。
- **`Results.Stream` 零成本**，和手写 `Response.Body` 完全等价；`IAsyncEnumerable<string>` 每帧快 40%，但它输出的是 JSON 数组，字节数多 44%，而且你控制不了帧格式。
- **慢客户端不吃内存**：读端每 1KB 停 1ms，服务端耗时从 27 ms 拉长到 **7.8 秒**，但 GC 堆恒定 15.5 MB、进程 RSS 恒定 116 MB、全程额外分配 0.3 MB。写操作被背压挡住了，不是排队缓冲。
- 真正该防的是**连接数**和**首字节时间**，不是 flush 频率。

## 测试方法

环境：.NET 10.0.5 / Apple M4（4P+6E）/ macOS 26.7.1 / Release / Kestrel，客户端与服务端同机走 127.0.0.1 回环。**这个前提很重要——回环没有网络 RTT，下面的绝对值只代表服务端推流成本，不要当成公网性能。**

被测帧是固定 24 字节的一帧 SSE：

```text
data: {"i":0,"t":"tok"}\n\n
```

服务端三个端点，分别是手写流、`Results.Stream` 包装、`IAsyncEnumerable<string>`：

```csharp
app.MapGet("/raw/{batch:int}/{n:int}", async (HttpContext ctx, int batch, int n) =>
{
    ctx.Response.ContentType = "text/event-stream";
    var body = ctx.Response.Body;
    for (int i = 0; i < n; i++)
    {
        await body.WriteAsync(Frame);                 // 复用同一个 byte[]
        if ((i + 1) % batch == 0) await body.FlushAsync();
    }
    await body.FlushAsync();
});
```

客户端用 `HttpCompletionOption.ResponseHeadersRead` 拿到流后死读，记录首字节耗时和读完耗时。

**样本稳定性踩了坑**：第一版每项只测一次、窗口 2 万帧（1~10 ms），同一配置两轮之间能差 5 倍，完全是调度噪声。改成窗口 50 万帧、每项测 3 次取中位数之后，两轮偏差收敛到 10~15%，下面的数字都来自两轮中位数。

## 一、每帧 flush：1.5~1.7 倍，不是 100 倍

单连接 50 万帧，只改 flush 频率：

| 每 N 帧 flush 一次 | 每帧耗时 | 吞吐（帧/秒） |
|---|---|---|
| 1 | 0.141 / 0.151 µs | 710 万 / 661 万 |
| 5 | 0.105 / 0.100 µs | 954 万 / 1002 万 |
| 20 | 0.097 / 0.087 µs | 1029 万 / 1148 万 |
| 100 | 0.094 / 0.087 µs | 1064 万 / 1143 万 |

逐帧 flush 比攒 100 帧只慢 1.5~1.7 倍。这个量级说明 `FlushAsync` 的成本**不是一次 write 系统调用**（那通常是微秒级起步），而是管道提交：数据交给 Kestrel 的响应管道，真正的 `writev` 由传输层在事件循环里批量做掉。所以「每个 token 都 flush」并不像很多人担心的那样昂贵。

反过来看更有用：**帧数才是成本主项**。0.1 µs/帧意味着一次 2000 token 的回答只花 0.2 ms 推流；哪怕你每帧都 flush 也就 0.3 ms。这点开销相比一次模型推理可以忽略。

首字节时间单连接在 **88~126 µs**，这部分和 flush 频率基本无关，取决于请求进入 Kestrel 到第一次写出的固定路径。

## 二、并发：200 连接只有 7.7 倍吞吐

固定每 10 帧 flush 一次，每连接 2000 帧：

| 并发连接 | 总吞吐（帧/秒） | 单连接 p50 | p95 | 首字节 p50 |
|---|---|---|---|---|
| 1 | 548 万 / 718 万 | 0.4 / 0.3 ms | 0~1 ms | 90~103 µs |
| 10 | 1895 万 / 2372 万 | 1.1 / 0.6 ms | 1 ms | 0.5~0.9 ms |
| 50 | 2749 万 / 4659 万 | 4.0 / 1.8 ms | 2~4 ms | 1.7~3.8 ms |
| 200 | 4147 万 / 5651 万 | 7.6 / 5.4 ms | 6~11 ms | 5.3~7.4 ms |

连接数 ×200，吞吐只有 ×7.7，单连接延迟涨约 18 倍。原因是这些连接共享同一条内核套接字路径和同一批 CPU 核，抢的是同一份上下文切换与内存带宽预算，TCP 缓冲区再大也换不来线性扩展。200 连接下 4100 万帧/秒 × 24 字节 ≈ **1 GB/s**，已经贴着回环的搬运上限。

对做 LLM 网关的人来说这条最实用：**并发这一维不要靠加连接数换吞吐**，它只会把每个用户的出字延迟一起拖慢。要做的是限制单实例并发、把连接分片到多进程/多机。

## 三、三种写法：`Results.Stream` 白送，`IAsyncEnumerable` 是另一个东西

20 万帧，单连接：

| 写法 | 每帧耗时 | 收到字节 |
|---|---|---|
| 手写 `Response.Body` + flush | 0.097 / 0.107 µs | 5,000,000 |
| `Results.Stream(...)` | 0.093 / 0.105 µs | 5,000,000 |
| `IAsyncEnumerable<string>` | 0.057 / 0.059 µs | 7,200,001 |

两个结论：

- `Results.Stream` 没有额外开销，和手写等价。它值得用，因为能统一返回类型、方便挂过滤器。
- `IAsyncEnumerable<string>` 每帧快 40%，但那是**假快**：它吐的是 JSON 数组的流式序列化结果，字节数多 44%（引号和逗号），而且前端拿到的不是 `text/event-stream` 的 `data:` 帧。**只要有 SSE 协议要求，就别图省事直接 `yield return` 字符串。**

## 四、慢客户端：不炸内存，但把 27 ms 拖成 7.8 秒

20 万帧（约 4.8 MB 数据），逐帧 flush，快读 vs 每读 1KB 停 1ms 的慢读：

| 客户端 | 墙钟 | 服务端额外分配 | GC 堆峰值 | 进程 RSS 峰值 |
|---|---|---|---|---|
| 快读 | 27~29 ms | 0.0 MB | 15.5 MB | 116 MB |
| 慢读 | 7837~7846 ms | 0.2~0.3 MB | 15.5 MB | 116 MB |

耗时差 290 倍，**内存却一个字节没多**：GC 堆和 RSS 两轮完全一致。这是 Kestrel 响应管道的有界 `pause/resume` 机制在起作用——管道积压超过 pause 阈值，`WriteAsync` 就真的 `await` 住，直到读端消费到 resume 阈值以下。也就是说：

- 慢客户端**不会**让服务端把 4.8 MB 积压塞进内存，写端直接被阻塞；
- 但它会**长期占住一条连接和一个异步状态机**，这才是真风险。

所以生产上的防线不在内存，在连接生命周期：`RequestAborted` 要真的传下去、给流式响应设总时长上限、客户端断开要能把上游推理一起取消。否则 200 个半死连接就能把你的实例连接数配额占满，而监控上内存一片平静。

## 落到生产的三条

1. **别纠结 flush 频率**。逐帧 flush 每帧也就多 0.05 µs，体验优先就逐帧 flush。要省 CPU 就攒 5~20 帧，收益基本吃满，再往上攒没意义，只会让首字变慢。
2. **并发靠分片，不靠加连接**。单实例 200 连接时每用户 p50 已经 5 ms 以上；要更多用户，走多实例 + 前置分流。
3. **慢客户端按连接超时治理，不按内存治理**。背压已经帮你挡住了内存增长，你要补的是超时、取消和连接数上限。

## 复现

```bash
mkdir SseLab && cd SseLab
dotnet new web -f net10.0
# 把上面的三个端点和客户端压测代码写进 Program.cs
dotnet build -c Release
dotnet bin/Release/net10.0/SseLab.dll server   # 一个终端
dotnet bin/Release/net10.0/SseLab.dll bench    # 另一个终端
```

两个进程要分开跑，压测端在同一进程里会和服务端抢核，数字会整体偏移。测之前记得先预热（我这里是每个端点跑 3 次 1000 帧），否则测到的是 JIT 分层编译的过程，不是稳态。


用 ASP.NET Core 给大模型做 token 流式输出，最常见的三个焦虑是：每次 flush 是不是很贵、能不能扛几百个并发连接、慢客户端会不会把内存吃穿。这三个都在本机实测了一遍，结论和直觉都不太一样。

ASP.NET Core 推 LLM token 流实测：每帧 flush 只花 0.14 微秒，200 并发却只快 7.7 倍

编程语言

实测：逐帧flush单连接0.141µs/帧，攒100帧只快1.5倍；200并发吞吐仅7.7倍提升，单连接延迟涨18倍；Results.Stream零开销等价手写，IAsyncEnumerable每帧快40%但字节多44%且非SSE格式；慢客户端拖慢290倍但内存恒定116MB，背压阻断写入。真正瓶颈是连接数与首字节，非flush频率。

代码解释

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

实测：逐帧flush单连接0.141µs/帧，攒100帧只快1.5倍；200并发吞吐仅7.7倍提升，单连接延迟涨18倍；Results.Stream零开销等价手写，IAsyncEnumerable每帧快40%但字节多44%且非SSE格式；慢客户端拖慢290倍但内存恒定116MB，背压阻断写入。真正瓶颈是连接数与首字节，...

ASP.NET Core 推 LLM token 流实测：每帧 flush 只花 0.14 微秒，200 并发却只快 7.7 倍-腾讯云开发者社区-腾讯云

ASP.NET Core 推 LLM token 流实测：每帧 flush 只花 0.14 微秒，200 并发却只快 7.7 倍

ASP.NET Core 推 LLM token 流实测：每帧 flush 只花 0.14 微秒，200 并发却只快 7.7 倍

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐