With AES-GCM, may I use multiple tags per key? In my implementation of AES-GCM, the key might change only once per minute.  However, I wish to calculate a new tag every 6us, to reduce latency (since you have to buffer up a GCM "packet" before checking the tag and releasing it).  


May I keep the same key and generate millions of tags using the same key, as long as the GCM counter increments for every 128-bit block?
Do I need to restart the tag computation process (i.e., clear accumulators) for each tag?
Or, must I change the key once a tag is computed and transmitted?
In a related question, can I use an IV of fewer than 96 bits? 


Normally there is an IV of 96 bits and a 32-bit counter, but at my data rates (400Gbps) I'll burn through the 32-bit counter in less than 1.5 sec, and I don't want to have to update the key every second.


Could I use, say, an 84-bit IV with a 44-bit counter?
I thought I'd update this with what I learned designing my ASIC.  I found the literature and terminology very ambiguous, even McGrew &amp; Viega's paper on GCM.  Thanks to Poncho and others for their answers.  Here are some notes from my code:

************************* Nonce Format *****************************

|&lt;--            Counter Block (CB) (128 bits)                   --&gt;|
|&lt;--            Nonce (96 bits)                   --&gt;|
                                  |&lt;-  Invoc Cntr  -&gt;|
                      Salt[56:63] |&lt;--&gt;| 
+-----------------+---------------+------------------+-------------+
|   salt[0:31]    |  salt[32:55]  |       SEQ        |   Blk Ctr   |
+-----------------+---------------+------------------+-------------+
|&lt;--    32      -&gt;&lt;--    24     -&gt;&lt;-      40       -&gt;&lt;-   32     -&gt;|

Salt:  64-bit value used to form the nonce.  This is unique to each
       key.  It should be true-random but need not be secret.
       RFC-4106 recommends that only salt[0:31] be used and that 
       salt[32:63] be left at 32'b0.  salt[56:63] will be XORed 
       with the leftmost 8 bits of SEQ.
SEQ:   Extended sequence number, aka invocation counter.  This is 
       called the IV (Initial Vector) in RFC-4106.  This normally
       starts at 0 with a new key and increments every frm.
Blk Ctr:  This starts at 32'd2 on every frame and increments for
       every 128-bit block of cryptext.
-------------------------------------------------------------------


In my case, I start with a key/salt pair, which should be updated every 8 hours. (I generate a new tag every ~6$\mu$s, and the NIST recommends not using more than $2^{32}$ tags per key.)

Much of the terminology (e.g., "IV") is ambiguous.  The terms I use are not completely standardized.  There is a unique "nonce" for each "frame", where each frame has a tag.  The nonce format is shown above.  The "salt" is normally 32 bits but can be up to 64 bits.  It changes when the key does.

When the key/salt changes, the 40-bit sequence counter SEQ is reset to 0.  SEQ increments for every "frame", each of which is terminated with a tag.  In my case, "frames" have about 20e3 128-bit AES blocks.  SEQ should not exceed $2^{32}$ to prevent tag forging.

The 32-bit block counter starts at 2 at the beginning of each "frame".  It increments for each 128-bit block up to about 20e3 and then resets for the next frame (after a tag is generated). 

I don't have to worry about collisions because only one chip is encrypting with a given key, so there will be no nonce reuse.