解决了它，在这个Gist的帮助下。
下面是我如何使用它，沿着一个聪明的“黑客”，以获得实际的文件大小，而不是复制文件到内存第一。哦，它的速度是两倍（显然）。

// Create an instance of our provider.
// See https://gist.github.com/JamesRandall/11088079#file-blobstoragemultipartstreamprovider-cs for implementation.
var provider = new BlobStorageMultipartStreamProvider ();

// This is where the uploading is happening, by writing to the Azure stream
// as the file stream from the request is being read, leaving almost no memory footprint.
await this.Request.Content.ReadAsMultipartAsync(provider);

// We want to know the exact size of the file, but this info is not available to us before
// we've uploaded everything - which has just happened.
// We get the stream from the content (and that stream is the same instance we wrote to).
var stream = await provider.Contents.First().ReadAsStreamAsync();

// Problem: If you try to use stream.Length, you'll get an exception, because BlobWriteStream
// does not support it.

// But this is where we get fancy.

// Position == size, because the file has just been written to it, leaving the
// position at the end of the file.
var sizeInBytes = stream.Position;

瞧，你得到了你上传的文件的大小，而不必复制文件到您的web示例的内存.
至于在上传文件之前**获得文件长度，这并不容易，我不得不求助于一些相当不愉快的方法来获得一个近似值。
在BlobStorageMultipartStreamProvider中：

var approxSize = parent.Headers.ContentLength.Value - parent.Headers.ToString().Length;

这给了我一个非常接近的文件大小，减少了几百个字节（我猜取决于HTTP头）。这对我来说已经足够好了，因为我的配额强制可以接受被削减的几个字节。
为了炫耀一下，这里是内存占用量，由任务管理器中的“性能”选项卡报告。

Before -使用MemoryStream，在上传之前将其读入内存

之后-直接写入Blob存储

我认为更好的方法是从客户端直接访问Azure Blob存储。通过利用Azure存储中的CORS支持，您可以消除Web API服务器上的负载，从而为您的应用程序提供更好的整体可伸缩性。
基本上，你将创建一个共享访问签名（SAS）URL，你的客户端可以使用该URL将文件直接上载到Azure存储。出于安全原因，建议你限制SAS的有效期。有关生成SAS URL的最佳做法指南，请参阅here。
对于您的特定场景，请查看Azure存储团队的this blog，他们讨论了如何使用CORS和SAS来实现此特定场景。此外，还有一个示例应用程序，因此它应该可以为您提供所需的一切。